Your primary internet circuit goes down. The firewall switches to the backup. Both connections are unavailable because the two providers’ cables pass through the same damaged conduit outside the building.
Two provider names do not establish two independent paths. Before buying a backup internet circuit, ask how each service reaches your site, where the routes converge and which equipment both connections depend on. Then test whether the applications that matter can work on the backup.
A second circuit can still be worthwhile when some infrastructure is shared. The purchasing decision should reflect the failures it can cover and the ones it cannot.
Separate provider diversity from route diversity
Provider diversity means buying service from different providers. Physical route diversity concerns the actual paths between locations. A retail provider may use another company’s local facilities, and two services may share a building entrance, pole line, trench, bridge crossing or carrier facility.
CISA’s Route Diversity Project fact sheet identifies the local-access connection as a vulnerable part of communications continuity. It distinguishes alternate physical paths from duplicate assets. That distinction belongs in an ordinary business connectivity purchase too.
Consider a hypothetical office with fiber from two brands. If both services enter through one riser, an incident in that riser can affect both. If their outside paths separate but they terminate on one unprotected firewall, that firewall remains a shared dependency. The two observations lead to different improvements.
Start by naming the outage you want to survive: a local cable cut, one provider’s failure, a building power interruption, equipment failure or loss of access to a particular cloud service. A design cannot be evaluated clearly while “redundancy” means something different to each person in the meeting.
Ask for evidence before signing
Give both providers the same questions. Request written answers from someone who can verify the service design, including any underlying local-access carrier. Sales coverage maps and speed tests do not establish physical separation.
| Ask about | Evidence to request | Decision it supports |
|---|---|---|
| Local-access ownership | Who owns and operates the facilities used to reach this address? | Whether two brands rely on the same access network |
| Outside route | Route review or a written diversity statement identifying shared segments and exclusions | Exposure to a common cable cut or local incident |
| Building entrance and riser | Demarcation locations and verified entrance paths | Whether separation continues inside the property |
| Carrier facilities | Available confirmation of shared aggregation or other convergence points | Which upstream failures may affect both circuits |
| Future route changes | What notice or revalidation the agreement provides | Whether the original diversity assumption will stay current |
Providers may limit detailed route disclosure. Ask what they can attest to, under what confidentiality terms, and whether an engineering review is available. Record an unanswered question as unknown. Do not turn “we cannot provide the map” into an assumption that the routes are separate.
Have procurement capture the agreed scope and limitations in the service documents. “Diverse from our other circuit” needs a defined reference circuit and a defined portion of the route. Review any proposed service commitment with the people responsible for the contract.
Walk the path inside your own building
Your team controls dependencies that a carrier proposal may not cover. Walk from each demarcation point to the equipment that uses the connection. Include patch panels, media converters, switches, firewalls, power supplies and the network path to critical users.
Look for a common outlet, UPS, cabinet, cooling problem or physical hazard. Check whether a power interruption leaves the carrier equipment running while the firewall shuts down. Confirm who can enter the telecom room during an after-hours outage.
Draw a simple path for each circuit and circle the components they share. You do not need a polished network diagram to discover that both “independent” links use the same small switch. Use the diagram to decide which shared points are acceptable and which need work.
Include the services that make connectivity usable. Name resolution, identity services, VPN gateways and cloud security controls may depend on a different site or connection. An internet link can pass traffic while staff still cannot sign in to the application they need.
Choose the backup for the work it must carry
A different access medium can change the failure pattern. Cellular or fixed wireless may avoid the same last-mile cable route, but still depends on coverage, power, upstream connectivity and available capacity. A second fiber circuit may offer more capacity while requiring more work to establish route separation.
Ask what happens during local congestion and a prolonged outage. Review data allowances, throttling terms, antenna placement, installation access and any restrictions on addressing or inbound connections. Obtain the current service terms instead of assuming that a successful demonstration represents every operating condition.
Define the minimum workload. A clinic may prioritize scheduling, essential cloud applications and business calls. A government office may prioritize a few public-service systems. Those choices determine capacity and traffic priorities more clearly than a request to keep “everything” working.
If the backup uses a different public IP address, check applications that rely on source-IP allowlists or fixed endpoints. Confirm how remote-access VPNs, site-to-site tunnels and inbound services recover. Some services may need reconnection even when the network switches automatically.
Test an outage beyond the unplugged cable
Schedule testing with the network team and affected service owners. Establish the maintenance window, recovery procedure and a person authorized to stop the test. Keep emergency or other critical communications under their own approved continuity procedures.
Removing the primary cable can test one failure condition. It does not show how the firewall responds when the Ethernet link stays up but the provider stops reaching the internet. Review health-check targets and test supported failure scenarios with your provider or integrator.
For each test, record:
- The failure simulated and the detection time.
- When the backup became usable for each priority application.
- What happened to an active call, meeting, VPN session and new sign-in.
- Whether alerts reached the responsible team with the correct circuit identified.
- What happened when the primary returned, including any second interruption during failback.
Measure application recovery separately from the firewall’s route change. An existing meeting may drop while a new meeting starts successfully. That is a result to plan around, not a reason to declare the entire backup successful or useless.
Test under a representative workload. A quiet afternoon speed test cannot establish how the backup will handle a busy service desk plus video meetings. Agree in advance which traffic should be limited while the organization is on backup service.
Leave a usable outage record
Keep the circuit identifiers, provider contacts, escalation process, demarcation locations and test results together. Include known shared infrastructure and unresolved questions. Note the last date on which route diversity was confirmed.
Review the design after construction, a provider change, equipment replacement or a major change in application use. Staff should know how to recognize that the site is running on backup and which activities may be restricted.
For a public building, connect this work to the guest Wi-Fi plan. Decide how visitor traffic behaves during an outage before it competes with the services staff need to maintain.
Put the two proposals on the same diagram
VIcom can help you review network and IT requirements alongside the AV and communications services that depend on them. Bring both circuit proposals, your current network diagram and the applications you need during an outage. The next step is to identify shared dependencies and agree on a test your team can witness.
Connect with VIcom by filling out the form below.