A backup internet link is one of the most frequently bought and least frequently tested forms of redundancy. Contract signed, cable plugged into the router’s second port, budget line justified. The first test happens on the day the primary link fails, and that is when it turns out the switchover did not happen, happened after twenty minutes, or happened but the VPN to the other office still does not work.
Two links are not the same as two contracts
Redundancy exists when the links share no point of failure. Two links from the same provider often enter the building through the same cable and terminate in the same node. Two fibre links from different providers are sometimes routed through the same duct, cut by the same excavator.
A sensible minimum for a small company: a wired primary link and a backup link of a different type, radio or cellular, from a different provider. The backup’s bandwidth can be lower; it is meant to keep critical services running, not comfort.
Detecting the failure
The router or firewall decides to switch based on link monitoring. The most common mistake: monitoring by polling the provider’s gateway. The gateway answers when the failure is further inside the provider’s network, so no switchover happens and the internet does not work.
Monitoring should check targets beyond the provider’s network: two or three public addresses of different organisations, through the given link. Failover occurs when most targets stop responding for a defined time, for example three consecutive attempts every ten seconds. Too short a time means flapping back and forth on momentary glitches; too long means minutes without internet.
Failing back to the primary link after it recovers also has a delay, longer than the failover: a link that has been back for thirty seconds may disappear again.
What will not switch by itself
Switching outbound traffic is the easy part. Several things need a separate plan:
- Services exposed to the internet on the primary link’s public address. After failover that address is unreachable. Options: services behind an external provider (proxy, cloud), dynamic DNS record updates with a short TTL, or a conscious decision that these services have no redundancy.
- Site-to-site VPN tunnels established to specific addresses. The other side must know both public addresses and have two tunnels configured, or one tunnel with automatic selection.
- SPF records, if mail leaves directly from the site. The backup link’s address must be in the record, otherwise mail ends up in spam after failover.
- Allow lists at partners and in cloud services that restrict access to the company’s public address.
- Filtering and logging that runs on the primary link and was skipped on the backup because “it is only for emergencies”.
Priorities on the backup link
Lower bandwidth requires deciding what matters. Traffic shaping rules on the backup link: voice, video and VPN first, then cloud office services, then everything else. System updates and cloud backups are paused while running on the backup link.
The test
Once a quarter, during business hours, after a warning: unplug the primary link’s cable. Not disabling the interface in the configuration, because that tests a different scenario. Measure: how long until traffic flows through the backup, what stopped working, whether anyone noticed. After plugging the cable back in: did traffic return and how quickly. Results recorded, discrepancies fixed before the next test.
The failover event raises an alert. Running on the backup link for a week without the team knowing is more common than it seems.
Summary
Link redundancy means an independent medium and provider, monitoring of targets beyond the provider’s network, a plan for inbound services and tunnels, traffic priorities on the lower-bandwidth link, and a quarterly test by pulling the cable. A second link without these elements is a budget line, not a safeguard.