Building automatic failover between fibre and Starlink

The problem

The office ran on a single fibre connection. When the line was cut — which happened often enough to matter — everything stopped: the ERP system, email, the CCTV uplink, and any engineering work that depended on file access.

Recovery meant someone physically switching over to a backup connection. That person was usually me, and it was rarely convenient. The gap between a link failing and someone noticing was often longer than the switchover itself.

TODO: add how frequently outages occurred and roughly what they cost in lost working hours. Concrete numbers make this section land.

Why not just buy a second fibre line

A second fibre run from a different provider would have been the textbook answer, but both would likely share physical infrastructure for part of the route, so a single backhoe could still take out both. It was also the more expensive option.

Starlink solved the shared-path problem completely. A satellite uplink fails for entirely different reasons than a buried fibre line does, which is the property you actually want in a backup.

How the failover works

The design runs on a MikroTik CCR2004 under RouterOS 7.x. Both WANs terminate on separate ports, with the fibre link carrying all traffic by default and Starlink held as a standby route at a higher distance.

Health checking is the part that matters. Watching whether the interface is up is not enough — a fibre link can stay electrically up while passing no traffic. Instead the router probes a target beyond the ISP's own equipment, so the check fails when real connectivity fails rather than only when the cable is cut.

When probes fail, the backup route takes over and traffic continues over Starlink. When the primary recovers and stays stable, traffic returns automatically.

TODO: describe your actual check interval, failure threshold and probe target. This is the detail an interviewer will ask about.

Segmentation and shaping

Failover alone would have been a false economy. Starlink has less headroom than the fibre line, so moving everything across unshaped would degrade the ERP system while CCTV footage saturated the uplink.

Traffic is split across VLANs — staff, ERP, CCTV and guest — with queues that protect the ERP and staff traffic when the network is running on the backup link. Guest and camera traffic yield first.

TODO: your actual VLAN numbering and queue limits.

What I would do differently

The configuration lives on the router and is backed up, but it is not version-controlled or reproducible from scratch. If the hardware died, rebuilding would mean restoring a backup file rather than applying a known-good configuration from source.

Monitoring is also thinner than I would like. The failover works, but I find out about it by noticing, not by being told. An alert on state change would close that gap cheaply.