A second internet circuit is one of the easiest resilience purchases to make and one of the easiest to get wrong. The failure mode is consistent: an organisation buys a backup link and finds out during an outage that both circuits went down together. Redundancy is not a count of contracts, it is a count of components whose failure stops traffic, and every component the two links share cancels out the second one.
What two circuits from one provider share
Two circuits from the same provider share several layers, in roughly this order of likelihood.
The access tail is first. Whatever runs from the provider’s aggregation point to your building is usually one physical route, and the second service is delivered over the same strand on a different wavelength or VLAN. A contractor cutting a duct two streets away takes both down in the same second.
The duct and the building entry come next. Even when two distinct fibres exist, they frequently share a run and enter through one riser. Logical separation without physical separation does not survive civil works.
Transit is third. Your provider buys capacity from one or two larger carriers. If that transit degrades, or a route leak in the provider’s own network sends traffic somewhere it should not go, both services are affected identically regardless of how separate the last mile is.
The operational failure domain is fourth and, in practice, the largest. Most long outages come from configuration changes, BGP announcement errors and management plane failures rather than damaged cable, and those affect everything a single operator runs.
Verifying a path diversity claim
Every provider will tell you the route is diverse. The claim only becomes information when you ask questions with checkable answers, in writing, before signing.
Where does the fibre enter the building, and is there a second, physically separate entry point? Which ducts does each route follow to the first aggregation node, and where do the two routes converge? In which facility does each circuit terminate, and is that equipment shared between them? Which upstream carriers does each of your two providers buy from?
That last question is skipped most often, and it matters more than the first three. Two different regional providers can both buy transit from the same national carrier, which gives you diversity up to a point and a shared failure domain beyond it. Peering at the same internet exchange helps latency and local traffic. It is not a substitute for independent international transit.
Ask for the change notification terms too: routes that are separate on installation day can be consolidated after a network rebuild nobody tells you about.
Three products that get sold as the same thing
Dual-WAN failover with NAT detects the loss of the primary circuit and moves traffic to the secondary. Existing sessions break because the public source address changes, and anything you publish becomes unreachable at its old address. For an organisation whose traffic is mostly outbound to SaaS, that is often enough.
SD-WAN holds sessions together by tunnelling both circuits to a hub or a cloud gateway. The address the outside world sees belongs to the hub, so failover is invisible to your partners. The dependency moves to that hub, which then has to be redundant itself, and to the overlay vendor’s control plane.
Multi-homing means your own autonomous system number and your own provider-independent address space, announced to two providers at once. Your addresses never change, inbound and outbound traffic both continue over the surviving circuit, and the failover happens in the global routing system rather than in a box on your premises. It is the only option where a provider failure produces no externally visible change at all.
The first two are configuration. The third is an ongoing operational commitment, which is the part that gets underestimated.
What multi-homing actually requires
An AS number comes from your regional registry, RIPE NCC across Europe and the Middle East, either through direct membership or via a sponsoring member. That part is paperwork.
Address space is the constraint. For IPv4 you need a /24 as a practical minimum, because most networks filter announcements longer than /24 and a /25 will not propagate globally no matter how correctly you announce it. New allocations come from a waiting list in limited quantity, so acquisition through the transfer market is often the realistic route. IPv6 does not have the same problem, and if you are building an addressing plan now it should be IPv6 first.
Beyond that you need routers that can hold the sessions and the memory to match, or a deliberate policy of partial routes plus a default. You need registry objects and RPKI ROAs covering your prefixes, because an increasing share of the internet drops routes that fail validation. And you need someone who understands the configuration at three in the morning. An autonomous system you cannot operate is a new way to fail, not insurance against failure.
The failover you have not rehearsed
Failover works, and then a list of things stops working. The list is predictable.
Long-lived TCP sessions reset when the source address changes: database replication, SSH, large file transfers, thick clients that hold a connection open all day. Recovery is rarely clean and often needs a restart.
IPsec VPN tunnels carry the peer address in configuration at both ends. Change yours and the remote side refuses to negotiate until someone edits it, which is a problem when the remote side is a customer with a change process. FQDN-based peers with dynamic updates, or address space that never changes, are the two ways out.
Source address allowlists at partners are the most common surprise. Banks, payment processors, government platforms and customer APIs filter on your source IP, and adding your backup address takes days of ticket handling. It has to be done before the incident.
DNS does not fail over as fast as its TTL claims. If your plan for published services is to change a record, expect a share of resolvers and browsers to keep using the old address well past the TTL you set.
Mail is affected twice. A backup address has no sending reputation, so messages sent through it are treated with suspicion, and if your SPF record does not include it they are rejected outright. The backup address also needs correct reverse DNS, or a portion of recipients will not accept delivery at all.
Inbound and outbound do not have to agree
Outbound traffic follows your routing decision. Inbound traffic follows decisions made by every other network, based on your announcements and their own policy. There is no requirement that the two match.
The practical consequence is a flow that leaves over circuit A and comes back over circuit B. A stateful firewall drops the return packet because it has no matching session. Provider anti-spoofing filters drop packets whose source address does not belong to them, so traffic leaving one provider’s circuit with the other provider’s addresses disappears without an error.
Without BGP, the fix is policy routing: replies leave through the interface the session arrived on. With BGP, inbound direction is influenced indirectly through AS path prepending or communities agreed with the provider, and neither gives precise control. Plan for asymmetry rather than assuming you can engineer it away.
Multi-site and cross-border cases
Distributed organisations have options a single site does not. A company with offices in several countries can use the sites as each other’s backup path, tunnelling a failed site’s traffic through a healthy one, which is cheaper than a second high-quality circuit at every location. The trade-off is that a site’s connectivity now depends on the inter-site links and on whoever provisions them.
The same applies to a nearshore delivery centre. If engineering happens in one country and the systems being worked on are elsewhere, connectivity between the two is production infrastructure and deserves the same diversity analysis as the main site, not the treatment given to office internet.
One caution for cross-border designs: announcing one autonomous system from several countries is fine technically, but contractual data location terms follow the traffic path. Check them before routing one country’s traffic through another jurisdiction.
Monitoring for degradation
A ping check that asks whether the circuit responds detects one failure type, and it is the rarest one. Circuits usually degrade instead: a few percent packet loss, doubled latency, jitter that ruins voice, an MTU problem that silently blackholes some flows, or a BGP session that re-establishes every few minutes.
Useful monitoring measures loss and latency per circuit independently, against several external targets, tests at the application layer rather than only at the packet layer, tracks BGP session state and received prefix counts, and triggers failover on quality thresholds rather than only on loss of response. Just as important, test the failover deliberately in a planned window. A failover path that has never been exercised is an assumption.
Cost tiers, and what each one buys
A 4G or 5G backup on a dual-WAN router is the cheapest option. It fails over in minutes, changes your public address, has limited capacity and data allowance, and keeps card payments, mail and cloud applications working.
A second fixed circuit from a different provider with verified path diversity, managed by dual-WAN or SD-WAN, costs a second subscription plus equipment. This covers most real requirements.
Full BGP multi-homing adds registry membership, address space acquisition, two routers that do not share a power feed, two transit contracts and, mostly, the expertise to run all of it. The step up in cost is substantial and it is justified by what it prevents, not by how the diagram looks.
When multi-homing is not the answer
If everything you publish already sits in a cloud or behind a CDN, and your users only need to reach outward, a well-built dual-WAN or SD-WAN design gives you most of the benefit for a fraction of the operational load.
It becomes justified when you host services that must keep the same address, when partners allowlist your source addresses, when you run your own mail infrastructure, when you owe contractual availability to your own customers, or when an hour of downtime clearly costs more than a year of running an AS properly. For a large number of companies the correct answer is a second circuit from a second provider, on a verified route, with the failover tested on a schedule.
Where to start
Disconnect the primary circuit on purpose, in a planned window, and write down what stops working. That list is the project plan.
We design and operate redundant connectivity, including BGP multi-homing, as part of advanced networking, and the wider question of which failure domains your architecture depends on belongs to infrastructure architecture.