Site to Site Circuit Redundancy: MPLS, DIA, and Broadband Backup Design

The redundancy decision usually gets made before anyone treats it as a design problem. A site needs to stay online, procurement orders a second circuit, and the network team wires it in as a backup with a static route that nobody has tested since installation day. The result is a connectivity setup that looks redundant on paper but is not redundant in practice, because two circuits are only redundant when they fail independently, and most pairs of circuits fail together far more often than the design assumes. A backhoe cuts the single conduit that carries both the MPLS handoff and the broadband drop into your building, because they enter through the same point. A nationwide carrier outage takes down both of your DIA circuits, because your two different providers lease the same last mile fiber from a third party. Circuit redundancy is not a procurement checkbox. It is an architecture decision about failure domains, failover mechanics, and honest capacity planning, and it deserves the same discipline as routing design or security architecture.

The options themselves are well understood. MPLS gives you a carrier managed private WAN with class of service and strong SLAs, at the price of long lead times, multi year contracts, and premium per megabit costs. Dedicated internet access (DIA) provides guaranteed bandwidth and BGP peering over the public internet, with faster provisioning and more flexible terms. Business broadband is cheap and installs in days, but it is best effort, asymmetric, and carries no service level agreement. Cellular LTE and 5G backup lines deploy in days, need no local loop at all, and work anywhere with coverage, but they are capped and their latency varies with the tower and the network. This article covers how to combine these options into a redundancy design that survives real failures: what diversity actually requires, the standard pairing patterns for branches, offices, and data centers, how failover genuinely happens at the routing layer, how to size a backup path honestly, what the whole thing costs, and how to keep the design from decaying the way most redundancy designs do.

At a Glance: Site Connectivity Options

What Redundant Connectivity Actually Requires

Two circuits are redundant only when they occupy separate failure domains, and achieving that is harder than it sounds. Provider diversity is the weakest form: different carriers frequently lease the same last mile fiber from a common wholesaler, so the two providers you signed with can fail together when that shared segment is cut. Technology diversity is stronger, because a terrestrial fiber circuit and a wireless LTE circuit fail under completely different conditions. The strongest arrangement is full path diversity, where the circuits differ in provider, access technology, physical routing, and building entry point. The practical rule is to look for diversity at the point of failure you are actually trying to survive: a construction dig up, a provider outage, a building event, or a hardware failure. Each failure mode is defeated by a different kind of independence, and a design that ignores this distinction produces redundancy that only exists in the diagram.

The most commonly ignored failure domain is the last mile near your own building. Two circuits that terminate in the same demarcation room, run through the same conduit, or enter through the same wall penetrations are one physical event away from failing together no matter how different the carriers are. Asking carriers for diversity documentation, walking the building entry points yourself, and recording where every circuit actually enters is the only way to verify the claim that a pair of circuits is diverse. A network topology view that shows every circuit terminating at a site, alongside the devices they connect to, makes shared entry points and shared handoffs visible in a way that a spreadsheet of circuit IDs never will.

Diversity does not end at the building entrance. Two circuits that terminate in the same router, share the same power feed, or run through the same rack are one equipment failure away from being redundant in name only. A backup circuit that depends on the same uninterruptible power supply, the same switch stack, or the same demarcation room as the primary does not protect you from the events that actually take sites down. The discipline is to define, for every site, which single points of failure remain even with two circuits installed, and to either eliminate them or accept them consciously as part of the design.

The Standard Redundancy Patterns

Most sites fit into one of a few well established patterns. The smallest is the branch office with a single DIA circuit and a broadband or cellular backup, which adds $50 to $300 per month to the connectivity bill and covers the most common failure modes: a provider outage, a failed router port, or a cut local loop. For branches whose traffic is mostly internet bound and tolerant of a short interruption, a broadband primary with a cellular backup is a defensible design, because the cost difference between the dedicated and best effort path is large and the branch rarely needs the dedicated path’s guarantees.

Regional offices and sites that carry latency sensitive or revenue critical traffic typically pair a dedicated primary circuit, MPLS or DIA, with a broadband backup, and increasingly run both through an SD-WAN edge that uses them actively rather than holding one in reserve. The SD-WAN layer adds subsecond failover and lets the backup contribute bandwidth during normal operation instead of sitting idle, but it cannot compensate for a backup that shares physical infrastructure with the primary, which is why the diversity checks above still apply even when the failover is automatic.

Data centers and headquarters get the most elaborate designs. The common pairings are MPLS plus DIA, two DIA circuits from different providers, or MPLS plus DIA plus a cellular third tier for the sites where an outage is genuinely unacceptable. Two MPLS circuits from the same carrier are rarely justified, because they share the carrier’s backbone and double the cost without doubling the failure independence. Whatever pattern you choose, it should be driven by the site’s recovery time objective and the traffic it carries, and it should be recorded as part of your multi site network design so that a future change to one circuit does not silently break the pairing.

How Failover Actually Happens

Two circuits do not fail over by themselves. Something at the routing layer has to notice the failure and shift traffic, and the mechanism you choose determines how long the outage lasts. A static default route with tracking, using IP SLA or a similar probe, gives failover in roughly thirty to sixty seconds, which is fine for branches and tolerant workloads but painful for voice or transactions. BGP multi-homing, where your site advertises its prefix to two providers, converges far faster and supports true active-active operation, but it requires an autonomous system number, an IP block to advertise, and the discipline to tune local preference and MED values so path selection behaves as designed.

BGP is the standard for multi-homed DIA because it gives you control over path selection instead of hoping the network picks a sensible route. The public IP block and ASN that make it work are assets that need tracking of their own, because losing track of which prefix belongs to which circuit and which provider is how peering configurations get corrupted over time. An IP address management practice that records the public allocations for each DIA circuit, alongside the BGP neighbors and ASNs, keeps the failover design reproducible rather than dependent on someone’s memory of the router configuration.

The right mechanism depends on the tolerance of the traffic. A point of sale system that fails a transaction after ten seconds cannot wait for a static route timer, so it belongs on a BGP or SD-WAN design. A file sync branch that can buffer a few minutes of traffic is well served by the cheap static route approach. What is never acceptable is a failover that depends on a human noticing the outage and changing configuration, because the humans are usually busy being on the outage call. If the design requires manual intervention, it is a runbook, not a redundancy design.

Right Sizing the Backup Path

A backup circuit is sized for what must survive an outage, not for what the primary circuit normally carries, and the difference is usually large. A branch with a 1 Gbps DIA primary does not need a 1 Gbps backup; it needs enough capacity for voice, point of sale, monitoring, and a degraded remote work experience. Broadband’s asymmetry makes the sizing question sharper, because a connection with 300 Mbps down and 10 Mbps up cannot carry the upload dependent traffic that some applications generate, and a backup that cannot carry your voice traffic is not a backup for your office.

Duration matters as much as throughput. A backup that carries thirty percent of normal traffic for three days is worth far more than one that carries the full load for twenty minutes, because carrier restorations for damaged fiber routinely stretch into days. If the backup runs through an SD-WAN overlay, it can also contribute bandwidth during normal operations, but the overlay cannot create capacity that the underlying link does not have, so the honest exercise is to list the critical applications, estimate their aggregate bandwidth, and size the backup for that number with headroom.

The backup circuit needs the same utilization monitoring as the primary, because a backup that is never exercised can die quietly. Utilization data is also what makes right sizing possible at renewal time: a broadband backup that has consistently sat at two percent utilization may be overprovisioned, while one that hits its cap during every monthly failover test is underprovisioned. Either way, the data has to be collected before the renewal conversation starts, or the carrier is the only one who knows what the circuit actually needs.

The Cost Question

The pricing gap between the tiers is the reason the patterns above exist. MPLS circuits typically run from $300 to $1,500 per month depending on bandwidth, distance, and contract term, with provisioning lead times of four to twelve weeks and three to five year commitments. DIA sits in a similar range, $300 to $1,500 per month, with faster two to six week installs when the building is on net. Business broadband costs $65 to $500 per month and can be live within days, and a cellular backup line runs $50 to $250 per month with no local loop and no installation window to speak of. A dedicated path is five to ten times the price of a best effort path, which is exactly why the backup tier is almost always best effort.

Dedicated circuits still earn their premium where the guarantees matter. If a site runs real time applications with strict latency and uptime requirements, or sits in a region where the local internet options are poor, an MPLS or DIA primary is the right call and the SLA is worth the price. If the site’s traffic is internet bound and latency tolerant, a well designed pair of best effort circuits delivers most of the reliability at a fraction of the cost. The decision should be driven by what the network audit shows about the actual traffic, not by habit or by what the previous site happened to order.

Contract alignment is the hidden cost trap in redundancy design. Backups that outlive their primaries, or primaries that auto renew while the design changed, quietly inflate the bill and complicate the failover story. Aligning contract terms across the circuits that form one design, and reviewing them together rather than circuit by circuit, keeps the redundancy architecture and the budget from diverging.

Failover Drills and Design Documentation

Redundancy designs decay faster than they are built. A circuit gets replaced during a migration, the broadband backup is moved to a different port, the SD-WAN controller is reconfigured, and nobody updates the design record, so the next outage exercises a design that no longer matches reality. The only defense is testing. A quarterly failover drill that pulls the primary and observes the backup taking over, with a documented expectation of how long the shift takes and what degrades, is the difference between a design that works and a design that is believed to work.

The drill should verify more than connectivity. It should verify that the backup has the capacity the design assumed, that the failover mechanism converges within the target window, and that the monitoring, remote access, and carrier escalation paths all function when the primary is gone, which is exactly the moment they are needed. Every drill produces findings, and those findings need to land somewhere that the team actually looks when a circuit is replaced or reconfigured.

That somewhere is the circuit documentation itself. If the design record for each site states which circuit is primary, which is backup, in what order failover happens, what capacity the backup is expected to carry, and which carrier contacts apply, then a future change to the network either preserves the design or visibly violates it. A redundancy design that is not documented at the point where the circuits are managed is a redundancy design that will be silently broken within two change windows.

Circuit Redundancy Design with Obelinf

Obelinf models circuits as first class records with provider, type, group, and status fields, which gives a redundancy design a concrete home. The pairing that forms a site’s redundancy architecture is represented by circuit records that share the same two sites, one marked active and one standing by, and hierarchical groups make the design legible at a glance: a group for WAN primaries, a group for broadband backups, a group for cellular third tiers, nested the way your actual structure works. When a circuit changes status or a new one enters provisioning, the design record reflects it immediately instead of waiting for someone to remember to update a diagram.

The VLAN and subnet management context rides on each circuit record, so an engineer troubleshooting a site connectivity issue can trace from the circuit to the routing context it belongs to, and the changelog records every modification with a timestamp and identity, keeping the design history auditable. The same topology view that makes shared entry points visible shows which circuits terminate at a site and which devices they feed, so a design review before a change is a question of looking, not of archaeology. That is what redundancy design documentation should feel like: the answer to what happens when a circuit fails is one search away, and it is already written down.