How does a floating static route back up a BGP-learned default route, and which failures will it fail to catch?

## The idea: a route that waits A **floating static route** is an ordinary static route with one twist: it is given a deliberately **worse** source preference (administrative distance, an implementation feature) than the dynamic route it backs up. Routers choose between routes for the same prefix by that preference, lower being better, so the static route loses while the dynamic route exists and 'floats' above the table, configured but not installed. When the dynamic route disappears, the static is the best remaining candidate and is installed. The typical design: a site has a primary link to provider X, which sends a default route `0.0.0.0/0` over external BGP, and a cheaper backup link toward `198.51.100.2`. ## How it works, step by step 1. The operator configures `0.0.0.0/0` via `198.51.100.2` with a preference worse than external BGP's. In one widely used family of defaults, external BGP is 20, so 200 or 250 are common choices; the numbers are implementation defaults, not protocol values. 2. While the BGP session is up, both routes exist for `0.0.0.0/0`. BGP's wins; the static stays out of the forwarding table. 3. The BGP session fails, or the provider withdraws the default. The BGP route leaves the table. 4. The static route is now the most preferred candidate for `0.0.0.0/0` and is installed; traffic moves to the backup link. 5. When BGP relearns the default, it wins again and the static floats back out. Nothing is relearned during the switch: each source keeps its route, and the router only reinstalls whichever is best. ## RFC 1812's version of the same idea RFC 1812, the IPv4 router requirements, predates the name but describes the need. Section 7.4 says whether a static route is preferred over a dynamic one SHOULD be configurable per static route, and gives a use for comparing metrics between static routes: a primary static route over one interface and a secondary over another, failing over to the alternate path if the primary's interface fails. Its administrative-preference scheme (section 5.2.4.4) runs from 0, most preferred, to 254, with **255 reserved to mean the route is never used**, so a floating static must sit below 255. ## What it cannot see | Failure | Why the floating static misses it | |---|---| | Provider keeps advertising a default it cannot deliver | The BGP route is never withdrawn, so the static never installs | | BGP is slow to notice a dead peer | RFC 4271's suggested hold time is 90 seconds; failover waits for it | | Backup link dead beyond a working local interface | A plain static route checks only its local interface and next hop, so it installs and black-holes traffic | | Inbound traffic | The static changes only this router's outbound choice; the outside world still routes toward the primary until its announcements change | Closing these gaps takes evidence about the path itself. Many implementations can make a static route depend on a periodic reachability probe to a far-end address, an implementation feature rather than a protocol; a dedicated fast failure-detection protocol can shorten detection of a dead BGP peer. ## The prefix trap Preference only compares routes for **exactly the same prefix**. Longest match is applied first, so: - a backup static for `203.0.113.0/25` beats an OSPF `203.0.113.0/24` for addresses in the `/25`, however high its preference; - a static default backs up only the default: if the primary also delivers more specific routes, those keep attracting traffic toward the primary until they too are withdrawn. A floating static must therefore match the prefix of the route it backs up, and its preference should be chosen against every source that might carry that prefix, not only BGP's, or it may displace an interior default it was never meant to beat. ## Checking the design before it is needed A backup that has never carried traffic is a guess. Before relying on one: 1. Confirm the static route is configured but not installed while the primary is up, so it really is floating. 2. Withdraw the primary deliberately, in a maintenance window, and watch the static install and traffic move to the backup link. 3. Restore the primary and confirm the static floats back out, so the site does not stay on the slower link. ## Where designs go wrong - Setting the backup's preference lower than BGP's, so it is installed permanently. - Using 255 and wondering why it never takes over. - Assuming the backup reacts to problems inside the provider's network. - Forgetting that the backup path must be tested on its own, before the day it is needed.