Fourteen ships, one network: LEO and GEO satellite at sea, 5G in port, and a card-data segment that stays clean
A cruise line operating from US Atlantic and Gulf ports, a leader in its segment.
- Scale
- 14 ships, 3,000 to 5,000 guests each, 2 LEO terminals + 1 GEO terminal per ship, 5G and fiber in port, 2 shore hubs
- Engagement
- Design, fleet rollout during scheduled dry-docks, and operation
The challenge
A ship is a small city that drives away from its own internet. Guests expect streaming and video calls, crew need payroll and scheduling, shops on board take card payments, and the bridge and engine systems must never share a wire with any of it. The line ran one geostationary link per ship, so every screen shared a half-second delay and a single point of failure.
A cruise ship is a small city that moves, and its internet is the thing most likely to disappoint it. The line ran one geostationary satellite link per ship. That link has a round-trip delay near 600 ms, and every guest, crew member and payment terminal shared it. Video calls stuttered, point-of-sale batches ran late, and one dish failure or one funnel blocking the sky took the whole ship offline. The brief was a network that behaves the same at sea, at anchor and in port.
We designed it in three layers. At sea, two low-earth-orbit terminals carry most traffic at about 25 to 60 ms round trip, with a geostationary Ku-band terminal as the fallback. On top, an SD-WAN edge pair measures every path for loss, latency and jitter several times a second and sends each application to the best one: voice and payments to the lowest-latency path, bulk traffic to whatever is cheap. Each ship holds IPsec tunnels (IKEv2, AES-GCM) to two shore hubs in separate datacenters and runs BGP across them, so routes follow whichever path is alive.
Port is where the economics change. When a ship docks, a policy moves everything that is not urgent to the 5G and fiber links: point-of-sale batches, crew training video, backups and software updates. The satellites are left to guests and operations, and the ship stops paying satellite rates for traffic that can wait four hours. The same policy runs in reverse as the ship leaves, with sessions held across the switch.
Onboard retail made segmentation a design requirement. The shops, spa and bars take cards, so point-to-point encrypted terminals sit in their own VRF behind a firewall that allows only the payment processor, which keeps the card-data environment small and easy to scope under PCI DSS 4.0.1, including the annual segmentation test. Guests, crew, hotel systems and the bridge each have their own segment. Navigation and engine networks send a one-way, read-only feed to fleet monitoring and accept nothing back.
We rolled out ship by ship during scheduled dry-docks, with a lab replica of a ship's rack to rehearse the cutover. Testing was physical: we unplugged each terminal in turn and watched calls survive, then blocked the sky to simulate a funnel shadow. Under test, a path failure was detected and traffic moved in well under a second; sessions on the surviving paths did not drop. The result is a fleet that the shore team can monitor on one screen, with a design that scales to the next ship by copying a template.
What our team delivered
- A dual-orbit design: two low-earth-orbit (LEO) terminals for low latency, about 25 to 60 ms round trip, and one geostationary (GEO) Ku-band terminal as the fallback, with a round trip near 600 ms
- SD-WAN edge pairs on every ship that probe each path for loss, latency and jitter several times a second, steer each application to the best path and hold a session through a path change
- IPsec tunnels (IKEv2, ESP with AES-GCM) from every ship to two shore hubs in separate datacenters, with BGP between ship and hub so routes follow whichever path is alive
- A 5G and fiber policy for port calls: when the ship docks, bulk traffic such as point-of-sale batches, crew training video, backups and software updates moves to the cheap, fast shore link and leaves the satellites free
- Guest, crew, hotel-system, point-of-sale and bridge networks in separate VRFs and VLANs, with a per-guest rate limit and DSCP (RFC 2474) marking so voice and operational traffic win under congestion
- Onboard retail terminals in a segmented card-data environment: point-to-point encrypted terminals, tokenized receipts and a firewall that allows only the payment processor, designed to PCI DSS 4.0.1 scoping
- A one-way, read-only feed from the navigation and engine networks to fleet monitoring, with no route back
Result
Every ship holds a session through a loss of any one link, port calls offload the bulk of non-urgent traffic, card data sits in a small segment that is simple to scope and test, and the bridge is isolated from everything guests touch.
Failover in under a second
ISP A fails at 300 ms. BFD (RFC 5880) with a 50 ms interval and multiplier 3 declares the session down 150 ms later, BGP withdraws the routes, and the forwarding table repoints to ISP B. Traffic is back at full rate in well under a second; without BFD the router would wait for the 90 s BGP hold timer. Illustrative figures.
One overlay over three very different links
The SD-WAN overlay runs over MPLS, business broadband and LTE or 5G at once. Probes measure latency, jitter and loss on every path, and each application follows its own policy: when the MPLS path degrades, voice moves to the healthier link in moments while backups stay on the cheap one.
One private network on four continents
Every site talks directly to every other site over WireGuard, so traffic never detours through a hub. Each business unit gets its own overlay, and IPsec tunnels carry traffic to partners and carriers.
Separate by region and by business unit
Each business unit lives in its own VRF and VLAN in every region, so a problem in retail cannot reach finance. Traffic between units has to pass a firewall that denies by default and allows only what is written down.
Facing something similar?
Tell us about your environment. We will tell you plainly what we would do and what it would take.