Your second internet link is not redundancy

A client called us an hour into a total outage. They had paid for redundant internet for six years: two providers, two invoices, two routers in the rack. Both were down.

The cause was a contractor putting a directional bore through a conduit two streets away. Both services ran through it. Nobody had ever checked, because on paper the design looked fine.

This is the most common connectivity finding we make, and it is almost never visible from the paperwork.

The redundancy that is not

Buying two internet services from two companies feels like redundancy. Whether it is depends entirely on what sits underneath, and in Australia the honest answer is often "the same thing".

Most business internet in this country is delivered over infrastructure the seller does not own. Two providers can be reselling the same wholesale product, over the same physical fibre, into the same building lead-in, terminating at the same exchange, with upstream transit bought from the same two or three carriers. You have two contracts and one failure domain.

Redundancy is not a count of services. It is a count of independent ways to fail.

The cruel part is that this design survives every test you are likely to run. Unplug router one and traffic moves to router two. The failover works perfectly, because you tested the layer that was never going to be the problem. The shared layer is the physical path, and you cannot test it by unplugging anything.

How to find your shared fate

Five questions, asked of each provider. Get the answers in writing, because the first response is usually a salesperson's optimism.

1. Whose physical network is this delivered over? Not who bills you, but who owns the fibre. If both answers match, stop here; you do not have redundancy.
2. Where does the cable physically enter the building, and by what route? Two services entering through the same riser or the same pit share a failure. Diverse building entry is a real, purchasable thing, and it costs more for a reason.
3. Which exchange or point of presence does it terminate at? Same exchange means a power or hardware event there takes both.
4. Who do you buy upstream transit from? Two providers with one common upstream will both feel that upstream's bad day.
5. Is the last mile the same technology? Two fibre services sharing a trench fail together. Fibre plus a genuinely separate path, such as a different carrier's fibre, fixed wireless, or 5G, fails independently, even if the backup is slower.

A deliberately slower, genuinely independent second path beats a fast one sharing a conduit. During an outage, degraded service is a completely different conversation from no service.

What real multihoming looks like

The technical piece is straightforward once the physical piece is right. You obtain your own IP address space and your own Autonomous System Number, and you advertise that space to both providers using BGP.

The critical property is that the addresses are yours. They do not belong to either provider. When link one fails, your addresses remain reachable via link two. Nothing renumbers. There is no DNS change and no TTL to wait out. Inbound traffic keeps working: your mail, your VPN, your customer-facing services, the API a partner allowlisted by IP three years ago.

That is the whole point, and it is what the cheaper designs cannot do.

Failover takes seconds to a couple of minutes to propagate, depending on timers and detection. Adding BFD brings failure detection under a second. That is slower than a local failover, but it is global: every network on the internet learns the new path, which is exactly what makes inbound traffic survive.

Do you need your own ASN?

In this region you apply to APNIC for both the ASN and address space, generally through membership. It is an application with a justification, not a purchase. You need to demonstrate you are actually multihoming.

It is worth it when any of these are true:

• You run inbound services: mail, VPN concentrators, customer portals, APIs.
• Partners or customers allowlist your IP addresses.
• An hour of downtime costs more than the annual cost of the second service.
• You expect to change providers and do not want to renumber.

It is not worth it when your internet is genuinely outbound-only: staff browsing and SaaS, nothing inbound, everything cloud-hosted elsewhere. In that case two links with sensible failover are fine, and the IPv4 scarcity premium plus BGP expertise buys you very little. We talk businesses out of this regularly.

One planning note specific to IPv4: allocations are constrained and have been for years. IPv6 has no such problem, and if you are doing this work anyway, doing it dual-stack from day one costs almost nothing extra and saves a migration later.

Where SD-WAN fits, and where it does not

SD-WAN gets sold as the answer to this, and it does solve a genuine problem, very well. It steers outbound sessions across multiple links per application, reacts to latency, loss and jitter rather than just link-down, and handles the "our video calls are terrible but the link is technically up" failure far better than BGP does.

What it does not do is give you provider-independent addressing. If your public IPs come from the provider, they still change when that provider's link fails, and your inbound services still break. SD-WAN cannot fix that, because the problem is who owns the addresses.

The two are complements. A common design we build: your own address space advertised via BGP for inbound reachability and provider independence, with SD-WAN managing outbound path selection and application steering. Each doing what it is good at.

What it costs, honestly

The second service is rarely the expensive part. The costs that catch people:

• Diverse physical path. If genuine diversity requires new civil works, such as a second lead-in from a different direction, this can exceed every other line item combined. Get it quoted before designing around it.
• Hardware that speaks BGP properly. Carrying full internet routing tables needs real memory. Consumer and small-business firewalls will not do it. You can avoid this with default routes plus partial tables, which is the right answer for most businesses and something an engineer should be choosing deliberately.
• APNIC membership and resources. Ongoing, modest, predictable.
• Expertise. BGP misconfiguration is unusually good at causing outages rather than preventing them, including for other people. A mis-scoped advertisement can black-hole traffic that was never yours. This is not the place to learn on production.

Set that against the number nobody wants to calculate: what a day offline actually costs you. Staff who cannot work, orders that do not arrive, the phones if they are VoIP. Most businesses that run the number find the answer obvious in one direction or the other within about ten minutes.

And if you take one thing from this: go and ask your two providers whose fibre they are using. That question is free, and it is the one that would have saved our client their afternoon.