The “track-host” option is typically used for determining the primary static route (or PBR route), by pinging the tracked host IP in a configurable tracking interval. Typically the tracked host is an upstream IP address (eg. ISP router IP or a known stable Internet IP, eg:

If the tracking fails, it means upstream is unreachable via this path, the router will remove this route, so that it will failover to a secondary route (eg. backup connection). Once the tracking succeeds again, it will add back the route so the connection will fall back to the primary route.

ip route nexthop track-host 3 max 50 10 preempt-delay 300 backup wwan0
ip route nexthop wwan0 distance 200 track-host 60 max 200 50

Using the above config as an example:

  1. The default primary path is via (fixed line), and it tracks at 3s interval, with maximum allowable latency of 50ms at 10% packet loss.
  1. The default secondary patch is via wwan0 (4G), which is configured with a higher admin distance (200), and it tracks at 60s intervals, with maximum allowable latency of 200ms at 50% packet loss therefore it’s less preferred (backup) when the primary is active.
  • If tracking to fails or latency is higher than the 50ms or packet loss is more than 10% (either due to cable failure or upstream link quality issues), whichever condition triggers first, the router will withdraw the primary route and the backup route will become active, eg. all connection will failover to 4G; if tracking to succeeds/recovers, it will add back the primary route and traffic will fall back to the primary path again (via
  • The “preempt delay” timer is an optional setting to delay fallback, eg. waits for up to the configured timer (in seconds) before it adds back the primary route, to prevent flapping situations for the primary path. Note this timer will count from the latest recovery. eg. if tracking fails again within the delay timer window, the fallback will happen from the last recovery.
  • The “backup” is another optional setting to prevent undesirable failover, When a WAN/primary failover connection is met (eg. WAN link failure, or especially high latency on WAN), we want to make sure the 4G/5G connection is stable before failing over to 4G. The objective is to avoid failing over to another bad backup connection when the primary is degraded but still usable.

For example:

Stable fallback scenario: (fail…recover) + 5 mins –> fallback to primary
Flapping fallback scenario (x is less than 5 mins): (fail…recover) + 2 mins + (fail….recover) + x mins + (fail_n….recover_n) + 5 mins —> fallback to primary