Redundancy on the Invoice, Not in the Ground

SSee · Trace every dependency

Two providers is a contract fact. Two routes is a physical fact.

Start by drawing what the network really depends on, not what the diagram says. That means the firewall and switches at the edge, the SD-WAN or router that chooses between circuits, each circuit and its building entry, the paths those circuits take once they leave the building, and the cloud applications the business runs on top.

In this scenario, Provider A and Provider B enter the building separately and look independent on every drawing and invoice. Follow the cables outside, though, and both climb the same pole line and meet at the same aggregation point. Each provider's service description only covers its own network, so neither shows this.

• Two contracts — two invoices, two support lines, two service levels. This is real, and it is where most diagrams stop
• One pole line — for the middle of the route both circuits are on the same poles, so a single pole or vehicle strike reaches both
• One aggregation point — both circuits terminate at the same provider-side hub, which is a shared fault domain of its own
• Edge and LAN count too — firewall, switches and the SD-WAN unit sit in one room on one power feed and are part of the failure surface

2 → 1providers versus physical routes — illustrative scenario

AAssess · The business consequence

One cut turns a redundancy line item into a total outage.

If both circuits fail together, everything that depends on the internet goes with them: cloud applications, voice and contact-centre calls, card and payment terminals, branch connectivity and remote access. The cost is the business activity that stops, plus however long it takes to get a repair crew to a pole.

The shared route is only one way the second circuit can fail to help. Assessment also asks whether the backup can carry the load, whether anyone has ever tested the switch-over, and whether the edge equipment survives a power cut.

• Shared segment — same duct or pole line and the same aggregation point. One physical event is a single point of failure for both circuits
• Capacity limits — the standby circuit is often smaller and cheaper. If it cannot carry peak demand, failover works on paper and the business still crawls
• Untested failover policy — default routing timers and unvalidated SD-WAN policy can take tens of seconds or more to switch, long enough to drop calls and sessions
• Edge power — firewall, switch and router on a single feed with no UPS go dark in a utility outage, however many circuits are connected

3failure domains shared by both circuits — route, aggregation hub, edge power (illustrative)

VValidate · Cut it on purpose

Prove it by cutting at the right place and measuring the application, not the link light.

A failover test that unplugs the cable at the router checks the router. It says nothing about the pole line, the duct or the aggregation point. A useful test injects a fault at the shared segment that route records and physical verification identified, while a synthetic transaction runs against the critical application.

What gets measured is the application: did the session survive, how many seconds until it worked again, and could the standby circuit carry the load. Link-up status is a weak proxy, because both links can read healthy right up to the moment they are not.

• Where you cut matters — a cut at the router passes in both designs. Only a cut on the shared segment exposes a shared route
• Measure the application — synthetic sign-ins, test calls and session counts show what users feel. Link monitors only show what the interface thinks
• Failover time is a design choice — fast fault detection can cut switch-over from tens of seconds to a few, but only if it is configured and tested
• A simulated cut does not prove diversity — provider route records and physical verification establish where the cables run. The test shows what happens when they fail

38 s vs 3 sswitch-over time, default timers versus tuned — synthetic values; the session tolerance in this demo is 15 s

EEvolve · The better outcome

Verified route diversity, tested failover, an edge that stays powered, and monitoring of the application.

The improved design has four parts. Circuits with documented, physically verified diversity: separate building entries, separate duct or pole routes and, where it matters, separate aggregation points. A failover policy that has been tuned and tested against the applications that matter. Edge equipment on protected power. And monitoring that measures application experience over both paths, so a quiet degradation shows up before a cut proves it.

Some of that is re-contracting or re-routing what is already being paid for; some needs new circuits or power equipment. That is why the cost of getting there is a decision to be made with evidence, not an assumption.

• Verified route diversity — route records checked, shared segments eliminated or consciously accepted and documented
• Tested failover — the switch-over tested by fault injection on a schedule, with application results kept as evidence
• Resilient edge power — firewall, switch and SD-WAN unit on protected power, sized for the time it takes to ride out a short outage
• Application-level monitoring — synthetic checks from the edge to the critical cloud applications over each circuit

≈ 3 sapplication outage on a pole-line cut — illustrative design target, not a customer result

Outcomes shown are illustrative and not verified customer results. The topology, failover times, session tolerance and repair time are synthetic. Real route diversity must be confirmed from provider route records and physical verification, and a real fault-injection test is planned around your network, approvals and change windows.