Resilient branch connectivity without a single point of failure

A backup circuit is useful only when it does not fail for the same reason as the primary circuit. Two contracts, two cables in one duct and one router still form a single point of failure. Resilience therefore starts with physical routes, access equipment, power, addressing and the actual failover scenario.

For every office, first identify the processes that must continue during an outage: voice, terminal access, payment terminals, VPN, video meetings, CRM or central database exchange. This determines the required capacity, latency and switching time.

What needs to be redundant

The communication chain includes:

1. the building entry point;
2. the last mile to the carrier node;
3. access equipment;
4. router or firewall;
5. power and UPS;
6. tunnel to the central environment;
7. DNS, identity and other shared services;
8. the central site or cloud environment.

If only the carrier is redundant, another component may still stop both circuits. Two providers connected to one switch, for example, are both lost when that switch fails.

Carrier and route independence

Different carrier names do not prove physical diversity. One carrier may lease the last mile from another, while both cables enter the building through the same chamber.

Before connection, ask for:

• building-entry details;
• last-mile ownership;
• carrier-network termination points;
• possible shared route sections;
• incident escalation process;
• target restoration times;
• emergency contacts.

Where a detailed route cannot be disclosed, diversify the access technology. A primary fibre circuit can be complemented by radio or mobile access. The backup may offer less stable capacity, but is more likely to survive a cable cut.

Active standby or active active

Model	Behaviour	Best fit
Active–standby	Backup waits for primary failure	Simple, predictable switching
Active–active	Both links carry traffic	Capacity utilisation and flexible routing

Active–active designs need control of asymmetric routing, session state, application priority and degraded-link behaviour. For a small office, dependable active–standby often provides more value than complex balancing that nobody tests.

Failover can use dynamic routing, SD-WAN or controlled health checks. A check should confirm that a business service works, not merely that the nearest router interface responds.

Protect the narrow backup circuit

The backup path is often smaller than the primary. During failover, restrict:

• workstation updates;
• large archive synchronisation;
• streaming video;
• background backups;
• guest networks;
• non-critical cloud services.

Give priority to voice, transactions, remote access and customer-facing systems. Prepare the policy before an incident rather than changing it manually during one.

Avoid a single central termination point

A resilient branch still fails when both tunnels terminate on one gateway in one data centre. Critical designs use at least two termination nodes, separated by equipment, power and, where required, site.

Verify that:

• a branch can establish a tunnel to both nodes;
• access policies remain consistent;
• addressing survives switching;
• the backup does not depend on an unavailable controller;
• DNS and identity continue to work;
• return routing is correct.

Connectivity must align with the disaster recovery plan and service RPO/RTO.

Observe the switch, not only link status

Measure:

• packet loss;
• latency and jitter;
• available capacity;
• disconnect count;
• tunnel state;
• failure-detection time;
• actual switching time;
• application errors after a route change.

Bring these signals into the shared observability layer. Our infrastructure observability guide explains how to connect metrics, logs and traces.

Test failure deliberately

Acceptance should include controlled tests:

1. disable the primary port;
2. remove power from the primary device;
3. simulate lost upstream connectivity with the local interface still up;
4. test degradation, not only a complete cut;
5. confirm sessions recover within an acceptable time;
6. restore the primary path and check for flapping;
7. record observed timings and every manual action.

Repeat tests after hardware, routing or software changes. Critical branches need an exercise calendar and an owner for each unresolved risk.

Launch checklist

• Carriers and physical routes are genuinely independent.
• Building entries and access equipment are separated.
• Routers, firewalls and power are redundant.
• Critical traffic is separated from background traffic.
• Health checks reflect the business service.
• The central site is not a single failure point.
• Switching metrics are collected automatically.
• Emergency contacts and escalation are documented.
• Complete failure and degradation have been tested.
• Test results meet business requirements.

How we can help

Logic Telecom can help inventory failure points, design primary and backup paths and prepare a test scenario. A practical first step is one critical branch and the full chain from building entry to business application.