Internet Redundancy: Multi-ISP Designs That Actually Fail Over

Two circuits is not redundancy

The most common internet-redundancy mistake is buying a second circuit and calling the problem solved. Redundancy is not the count of circuits on the invoice; it is the absence of a shared failure between them. We regularly audit "dual-ISP" sites where both circuits ride the same fiber into the building, terminate in the same carrier hotel, or — worse — belong to the same provider who quietly resells the same last mile under two brands. When the backhoe finds that one conduit, both go dark together, and the org discovers it paid twice for a single point of failure.

Genuine internet redundancy requires diversity you can prove, not diversity a sales order asserts. Walk it from the outside in and interrogate every shared element:

• Provider diversity. Two different autonomous systems, not two products from one carrier. Ask each provider for their AS number and confirm they differ.
• Last-mile diversity. The last mile — the physical run from the carrier's network to your demarc — is where most "diverse" designs collapse. Two circuits entering the same building lateral or the same conduit share fate no matter how independent the upstream networks are.
• Media diversity. Pairing fiber with a genuinely different transport — fixed wireless, cable, or bonded LTE/5G — protects against a whole class of physical cuts and construction accidents that a fiber-plus-fiber design does not.
• Path and building-entry diversity. Ideally the two circuits enter opposite sides of the building on separate laterals and reach different central offices or points of presence. Insist on written path documentation and audit it; carriers reroute over time and "diverse" circuits drift onto shared infrastructure.

Choose an architecture that matches the risk

Once you have two independent circuits, you have to decide how they carry traffic. There are three common designs, and they are not interchangeable — each buys a different grade of resilience at a different cost and complexity.

Figure: an SD-WAN overlay orchestrates multiple circuits centrally, steering each application to the healthiest path instead of waiting for a hard link-down.

• Simple dual-WAN. A single edge firewall or router with two WAN ports and basic "if primary goes down, use secondary" logic. It is cheap and better than nothing, but it fails on two fronts: the single device is itself a point of failure, and the trigger is usually link-state — the circuit has to go fully down before anything happens. It also breaks inbound connections and changes your public IP on failover, which matters for anything hosted on-site.
• BGP with provider-independent address space. You obtain your own IP block and autonomous system number, then advertise it to both ISPs. Now the same public addresses are reachable through either provider, inbound and outbound survive a circuit loss without renumbering, and routing converges automatically. This is the gold standard for organizations that host services on-premises, but it demands routing expertise, provider-independent space, and disciplined configuration to avoid leaking routes or blackholing traffic.
• SD-WAN overlay. An encrypted fabric abstracts the underlying circuits and steers traffic per-application based on real-time performance. It delivers most of BGP's automatic resilience for outbound and site-to-site traffic with far less routing expertise, adds active-active load sharing across links, and — critically — fails over on measured quality, not just link state. Our SD-WAN designs use this to run both circuits hot and shift sessions mid-flight when one degrades.

For most multi-site organizations the practical answer is SD-WAN for the branch overlay plus BGP at data-center or headquarters locations that publish inbound services. The global networks we operate for clients combine both so that no single carrier event takes down connectivity anywhere.

Active-active or failover — and why brownouts break naive designs

Active-passive keeps one circuit idle until the primary fails. It is simpler, but the standby is a path whose health you are only guessing at, and it introduces a detect-and-switch delay. Active-active runs both circuits in production and lets the survivors absorb load when one drops — which has the underrated benefit that you are continuously proving both paths work, because neither is ever idle.

Whichever you choose, the failure mode that defeats most designs is the brownout, not the blackout. Circuits rarely die cleanly. Far more often they degrade: latency climbs, packet loss creeps to five or ten percent, jitter wrecks voice and video — while the link stays administratively "up." A design that only fails over on link-down will happily pin every user to a circuit that is technically alive and practically unusable.

Health-based failover fixes this by deciding on measured quality:

1. Probe continuously. Send synthetic probes across each path and measure latency, loss, and jitter every few seconds — not once a minute.
2. Set application-aware thresholds. Voice tolerates far less loss and jitter than a file sync. Steer each traffic class on thresholds that match it.
3. Fail over on degradation, not just death. When a path crosses its loss or latency threshold, move traffic before users file tickets.
4. Damp the flapping. Use hysteresis so a path has to be healthy for a sustained window before traffic returns, or you will oscillate on a marginal circuit.

Do not forget inbound and DNS

Most redundancy conversations only cover outbound traffic — users reaching the internet. If you host anything that the outside world reaches — a VPN concentrator, a mail gateway, a public application — you also have to make the inbound path survive a circuit loss, and that is a different problem.

• BGP handles inbound natively. Because your provider-independent block is advertised through both ISPs, the internet simply reaches you over whichever path is up. No DNS change, no propagation delay.
• Without BGP, DNS is your inbound failover. You publish records that can be repointed to the surviving circuit's public IP, but you are then at the mercy of TTLs and resolver caching. Keep TTLs low enough to fail over in minutes without hammering resolvers, and automate the record change from your health monitoring so it does not wait on a human at 3 a.m.
• Make DNS itself redundant. DNS is one of the most overlooked single points of failure on the internet. Run at least two DNS providers on independent infrastructure so a provider outage cannot make your name unresolvable while your servers sit perfectly healthy.

A failover you have never triggered is a theory

Redundant circuits that have never carried traffic in anger are a hypothesis, not a safeguard. The recurring failures are consistent: the backup was misconfigured months ago and nobody knew, a firewall rule blocked the failover path, DNS never repointed because the TTL was a day, or the switch took eight minutes instead of the assumed thirty seconds. Every one of these is invisible until you test.

• Pull the primary on purpose in a maintenance window and watch what actually happens — announced first, then eventually unannounced.
• Inject latency and loss, not just hard downs, to prove health-based failover fires on brownouts.
• Time the recovery and confirm sessions survive. A failover that drops every connection is only half a success.
• Test inbound too. Verify that external users, VPN clients, and inbound mail keep working over the surviving path, not only that your staff can browse out.
• Track findings like incidents and close each gap before the next drill.

None of this works blind, so per-path infrastructure monitoring that alerts on degradation — not just outage — is the prerequisite for both automatic failover and honest testing.

Redundancy that holds on the bad day

Internet redundancy is worth exactly what it delivers during a failure, and that value is decided long before the outage — in the diversity you proved, the architecture you matched to the risk, the health-based logic that catches brownouts, the inbound path you remembered, and the tests that turned theory into muscle memory. Circuits will fail; whether your business notices is a design choice. intSignal designs, builds, and operates multi-ISP connectivity as part of the business continuity foundations our clients depend on — and we prove it holds under real failure, not just on paper. Talk to our network team to map your circuits, find the shared fate you are paying twice for, and design it out.