Circuits, Diversity, and Failover

Every district eventually buys a second internet circuit, and most of them discover during the first outage that both circuits were the same circuit wearing two invoices.

Diversity is a physical property, not a contract line. This article is about what to ask for, what you actually get, and how to prove the failover works before 900 students find out it does not.

The circuit types

Type	Typical	Behavior
Dedicated fiber	100 Mbps–10 Gbps	Symmetric, SLA-backed, expensive
Broadband (cable/DSL)	100 Mbps–1 Gbps	Asymmetric, best effort
Fixed wireless	10–200 Mbps	Weather-sensitive, low latency if close
LTE / 5G	10–100 Mbps	Metered, variable, good last resort

The district's primary is fiber; the backup is usually broadband or LTE. That combination is fine, as long as you understand which failures it covers.

What "diverse" must mean

Shared element	Covers
Same conduit	Nothing — one backhoe takes both
Same ISP	Almost nothing — one outage takes both
Same POP	Little — one router failure
Same power feed	Nothing — one electrician takes both
Same building entry	Little — one fire, one flood

True diversity means separate physical paths, ideally separate providers, entering the building at different points, on different power. That is expensive, and most districts cannot justify it for every site.

The honest approach: document what is shared, state which failures the design survives, and stop claiming more.

Failover mechanisms

Mechanism	Detects	Speed
BGP withdraw	Link or session down	Seconds to minutes
Floating static	Next hop unreachable	Seconds
SD-WAN probe	Path quality below threshold	Sub-second to seconds
Manual	A person notices	Whatever the ticket queue says

The mechanism matters less than the detection. A floating static that watches a next hop cannot tell a dead ISP router from a live one that has lost its upstream.

Worked example: fiber primary, LTE backup

Item	Primary	Backup
Circuit	1 Gbps fiber	LTE, 50 Mbps
Addressing	Static /29	CGNAT
Failover	BGP default from ISP	Floating static, distance 250
Uses	All traffic	Staff only, no student video

The backup is deliberately restricted: 50 Mbps cannot carry a district's student traffic, and pretending otherwise turns a degraded state into a total outage as the link saturates.

Policy during failover:

• Staff and administrative traffic allowed.
• Student devices blocked or throttled.
• Video conferencing deprioritized.
• A banner on the intranet explaining the degradation.

That last item saves the help desk a hundred calls.

Test it like it matters

Test	Frequency
Pull the primary, watch the backup take over	Quarterly
Confirm DNS still resolves	Quarterly
Confirm voice still works, or fails loudly	Quarterly
Measure time to full function	Quarterly
Confirm the primary returns without manual action	Quarterly

If nobody has pulled the cable in a year, the failover is a hypothesis.

What breaks in production

• Both circuits in one conduit. The most common and most expensive surprise.
• DNS hosted only at the primary's ISP. The backup comes up and nothing resolves.
• A floating static that never installs because the next hop is still reachable through a broken path.
• NAT or port forwards configured only on the primary, so published services vanish during failover.
• No capacity policy, so the backup collapses under load.
• No notification, so the district runs on LTE for three weeks.

Checklist

1. Every shared element between circuits is documented.
2. You can state which failures the design survives, and which it does not.
3. DNS works from both paths.
4. Port forwards and published services exist on both, or are deliberately primary-only.
5. Failover is tested quarterly, including the return.
6. Capacity policy during failover is written and enforced.

Next

Failover is a mechanism. Continue with BGP at the Edge for the protocol that makes multi-homing work.