Internet Redundancy with Dual ISPs: When the Fiber Gets Cut

The day a road-works excavator digs through the fiber outside your office, everything stops: email, Microsoft 365 or Google Workspace, cloud accounting, QR payments, the online meeting with a client. The ISP promises a fix "today". In Vientiane that might mean a few hours. In the provinces it can mean a few days.

Cut cables, failed provider equipment, a power cut at the exchange: you can't control any of that. What you can control is whether a second line is ready to take over.

What one line costs you

Do the arithmetic before you argue about budget. A fiber service that is up 99.5% of the time sounds good. It still means about 44 hours of outage a year, and those hours don't arrive spread evenly. They come as one bad afternoon in the rainy season and a two-day wait for a provincial repair team.

Add a second line that fails for completely different reasons, also at 99.5%, and the chance of both being down at the same moment drops to roughly 0.0025%, about 13 minutes a year. That only holds if the two links really are independent. Put them on the same pole and the math falls back to one line.

Three ways to use two links

A common misunderstanding: two 100 Mbps fiber lines won't download a single file at 200 Mbps. Session-based load balancing spreads connections across the links. Fifty people in an office get better aggregate performance, but one big download still runs over one link.

Two links that fail together aren't two links

This is the most important part of the article. Real redundancy needs diversity at every layer:

• Different providers. Not two packages from the same company
• Different cable paths. Ask each provider how their fiber enters the building, ideally from different sides. Then go outside and look at the poles. We regularly find two "different" providers whose cables climb the same pole in front of the building
• Different technologies. Fiber plus 4G/5G, or fiber plus microwave, can't both be cut by one excavator
• Different upstream networks. Ask whether both providers lease the same backbone route

For a 4G/5G backup, pick a mobile operator that isn't the same company as your primary fiber.

Equipment you need

A firewall or router with at least two WAN ports and proper health checks: ping or HTTP to several external targets, not just the provider's gateway. The fault may be further upstream, and if you only ping the gateway the firewall will think everything is fine.

For 4G/5G: a business-grade router or modem, with an external antenna where indoor signal is weak. A pocket Wi-Fi from the phone shop that overheats and reboots itself every two hours is not a backup link.

And UPS power for the firewall, both providers' modems/ONTs and the core switch. The ONT is often mounted wherever the ISP technician found convenient, not in the rack, and plugged into an ordinary wall socket. One flicker and your primary link is gone.

How big must the backup be? A worked example

The backup doesn't need to match the primary. It needs to carry the work that can't stop. Take a 40-person office on a 200 Mbps fiber line with a 4G backup:

A business 4G connection with a good external antenna can usually carry that. What it can't carry is everyone's OneDrive or Google Drive sync, Windows updates and YouTube on top. So write a backup-mode policy on the firewall: when traffic is on the backup link, limit or block updates, file sync and streaming, and give voice and business apps priority.

Watch the upload figure. Video meetings and cloud backup lean on upload, and mobile links are usually much weaker upstream than down. If a site runs a nightly cloud backup, pause it while on the backup link, or one night can use up a month's 4G package.

How fast is "automatic"?

Failover isn't instant. The firewall first has to decide the primary is dead, and the health check settings decide how long that takes:

Then sessions rebuild on the new IP. In practice, web and email users notice a pause of 10–30 seconds, and VoIP calls in progress drop and must be redialled. Faster probes catch faults sooner but can flap on a noisy link, so set a failback delay: the primary must stay clean for one to two minutes before traffic moves back. Without it, a link that drops for a second every minute will bounce everyone back and forth all day.

Things to plan for

Public IPs and inbound services. If you run staff VPN or publish servers, your public IP changes when traffic fails over. Plan DNS (short TTLs or two records), or configure VPN to accept connections on both IPs.

Branch VPNs. Build tunnels over both links, or use SD-WAN.

Open sessions. On failover, existing connections drop and have to reconnect because the source IP changes. That's normal. Tell users in advance so nobody panics.

Your own IP block and BGP. Organizations whose inbound services must keep the same addresses after failover can get their own public IP block and AS number and announce them to both providers with BGP. The outside world then follows whichever path is up. It needs ISPs that offer BGP to customers, a router that can take the routes, and someone who understands it. For most offices under a few hundred people, DNS and a VPN that accepts both IPs are enough.

Mistakes we see

• Two links from the same provider on the same fiber
• Health checks that only ping the gateway
• A backup 4G SIM with no credit or an expired package on the day it's needed. Set up auto-renewal or put it in the calendar
• No alerting. We have seen sites run on their 4G backup for weeks without anyone noticing, until the bill or the data cap arrived
• Forgetting UPS for an ONT that sits away from the rack

Testing failover so you know the result

Clicking "disable" in the GUI isn't a test. Real cable cuts don't look like that.

1. Warn users in advance and pick a low-impact window
2. Keep a VoIP call, a video meeting and a large download running during the test
3. Physically unplug the primary WAN and time how long until internet returns
4. Confirm branch VPNs, email and critical systems recover
5. Confirm the alert reached the IT team
6. Reconnect the cable and confirm traffic fails back to the primary
7. Record the results and adjust configuration if needed

Do it every quarter. Firewall configs change, ISPs swap equipment, SIMs expire. A backup you haven't tested is a backup you're only hoping will work.

What's different in Laos

• Rainy season is outage season. Landslides and floods cut provincial fiber routes, and repair crews can't always get through quickly. If a branch outside Vientiane depends on one route, expect multi-day outages a few times a year and plan the backup for days, not minutes.
• 5G is still mostly a Vientiane story. The main mobile operators run 5G in parts of the capital. In most provinces, plan the backup on 4G, and measure signal at the exact spot where the router will sit, not in the car park.
• Lightning finds the ONT. Fiber doesn't carry surges, but the ONT's power adapter and any copper Ethernet run to the rack do. Feed the ONT from the UPS with surge protection, and keep a spare adapter on site.
• Satellite options keep changing. What can be ordered and used in Laos has been shifting. Before planning a satellite backup for a remote site, check what is actually on sale when you order, and plan the terminal's power and mounting like any other outdoor equipment.
• Get repair terms in writing. Ask each ISP what repair time they commit to for your service type, and whether that changes outside Vientiane.

By type of site

In every case, send alerts to the IT team via LINE, WhatsApp or email the moment either link goes down.

Wondering how fast the backup needs to be to keep essential work going? Try our bandwidth calculator.

We'll test it in front of you

If you already have two links but have never tested them, book us for an after-hours failover test with the cable physically pulled. You'll see the actual switchover time and get a list of what needs fixing.