Two connections.
One question.

01 / Look for shared risks

Two services can share one failure point.

Consider a primary and backup connection from different providers. If both enter through the same conduit, a single construction incident could affect both. If they terminate on the same firewall or electrical circuit, a fault there could interrupt both services even when the provider networks remain available.

Engineers sometimes call a common dependency a shared risk. The aim is to understand the failure scenarios that matter to the business, not to assume every component can be made independent.

02 / Physical diversity

Follow the connection to the building.

Ask each provider about the route into the building, the entrance point, the riser to your floor, and the handoff location. Two connections can take different street paths but converge at the same building entrance or equipment room.

Where practical, separate entrances and internal pathways can reduce exposure to a single physical incident. Building design, permissions, available infrastructure, and construction costs determine what is possible. Providers may be unable to disclose or verify every part of another provider’s route.

03 / Inside the office

Check the equipment both links use.

Trace each connection from its handoff through the router, firewall, switches, and power. Separate providers cannot protect against a single device or power source that both services require.

Depending on the business, consider redundant routers or firewalls, separate power supplies and circuits, an uninterruptible power supply, and equipment in different locations. Redundancy adds cost and operational complexity; a second device still needs correct configuration, monitoring, and testing.

Include the office network and Wi-Fi in the plan. Internet failover does not help an employee whose access point, switch, or local device has failed.

04 / Provider & access choices

What does a second provider add?

Different providers may offer operational and network diversity, but different names do not prove different infrastructure. One provider may lease access from another, or both may use the same building facilities, upstream network, or physical route.

Ask where each provider’s service terminates or connects to its network, and whether the two services depend on the same data center, carrier hotel, or other critical facility. A shared facility can introduce common risks, such as an outage affecting its power, cooling, or access. Separate buildings can reduce some shared risks, but do not establish that the paths, power, or upstream networks are independent.

Providers may not be able to disclose every facility or verify another provider’s design. Ask them to describe the relevant shared dependencies and what they can confirm.

A backup using a different access technology, such as wireless, may avoid some wired-path risks. It has its own constraints, including coverage, signal conditions, capacity, power, and service terms. Evaluate the actual design and performance rather than assuming one technology is independent of another.

05 / Moving traffic

What happens when the primary fails?

Some businesses keep a backup idle until it is needed; others use both connections. In either case, the router or firewall must detect the failure and route traffic over the available path. Monitoring should test the right things: a physical link can remain up while a service or destination is unreachable.

Automatic failover is not always instantaneous. Existing calls, VPNs, or application sessions may disconnect or need to reconnect, especially if the public IP address changes. Applications that restrict source IP addresses may also require updates. Test the actual services your employees use.

Depending on the requirements, a design may use device-based failover, software-defined WAN, or BGP routing. BGP and provider-independent addresses can be appropriate in some multihomed networks, but they do not by themselves guarantee seamless failover, physical diversity, or unchanged application sessions. Ask your network team to design and test the approach.

Both connections may also depend on the same DNS service. Our business DNS guide covers resolver dependencies and resilience.

06 / Backup capacity

What must keep working?

The backup does not always need to match the primary circuit. List the applications, users, and locations that must remain operational, then estimate the upload and download capacity they require during an outage. Include VPN traffic, voice and video, cloud applications, and any workloads that cannot be deferred.

If the backup has less capacity, decide which traffic can wait and how essential applications will be protected from congestion. Check the backup’s latency, data limits, service terms, and equipment capacity. See our bandwidth planning guide for a sizing method.

07 / Validate the plan

Test it before an outage.

1. 01

   Agree on the test

   Choose a maintenance window, define success, notify affected teams, and prepare a rollback plan. A test may interrupt active sessions.

2. 02

   Test representative failures

   With the responsible teams, test loss of the primary service and, where appropriate, upstream reachability—not only an unplugged cable. Confirm which condition caused the switchover.

3. 03

   Check the work

   Confirm the backup path, required applications, VPNs, voice, and public-facing services. Record interruption time, capacity, and anything that needs to reconnect.

4. 04

   Restore and document

   Check the return to normal, record the outcome and open issues, and repeat testing after meaningful changes or on an agreed schedule.

08 / Planning checklist

Questions for providers and your IT team.

• Which physical routes, entrances, risers, and equipment rooms are separate? What cannot be verified?
• Do the services share a last-mile provider, upstream network, conduit, or building facility?
• Do they depend on the same data center or carrier hotel? What shared facility, power, or cooling risks can the providers confirm?
• What equipment and power must remain available for each connection?
• What failure does the monitoring detect, and how long did failover take in a test?
• Will public IP addresses change? Which VPNs, allowlists, or applications depend on them?
• Can the backup carry essential upload and download traffic at acceptable latency?
• How are the backup and the return to normal monitored and tested?
• Who owns each part of the design, and whom do we call during an incident?

For a Stealth service discussion, contact sales@stealth.net. Existing customers can contact support at +1 212 232 2020 or support@stealth.net.