A VRRP Active Router loses its only uplink but stays Active and black-holes traffic; how do priority tracking and preemption fix it, and how can they flap?
answer
- VRRP sees only the LAN side
- lower priority when the uplink dies
- decrement must cross the peer
- the peer needs preemption on
- interface up is not routes ready
basics
~20 sVRRP sees only LAN advertisements, so a router with a dead uplink stays Active. Tracking, an implementation feature, cuts its priority below the Backup's; with preemption on, the Backup takes over. A flapping uplink then moves the role back and forth.
solid answer
~50 sRFC 9568 elects on priority alone and detects failure only by missing advertisements, so an Active Router whose upstream link died keeps advertising and keeps attracting traffic it cannot deliver. **Tracking** is an implementation feature, not part of the RFC: it watches an interface, a route or a probe and lowers the router's VRRP priority when that object fails. Two conditions make it work. The decrement must push the Active's priority **strictly below** the Backup's, because a Backup accepts equal-priority advertisements and never preempts on a tie. And the Backup must have `Preempt_Mode` True, so it ignores the lower-priority advertisements and takes over when its `Active_Down_Interval` expires. The risk is flapping: an unstable uplink, or a router that reclaims the role as soon as its interface returns but before its routes are relearned, moves the gateway repeatedly. Implementations add a preemption delay; tracking a learned route rather than interface state also helps.
go deeper
Remember that VRRP only checks whether the Active Router is alive on the LAN; something extra, called tracking, is needed to react when its uplink dies.
Explain how tracking lowers the advertised priority, why the drop must go strictly below the Backup's, and why the Backup needs preemption enabled.
Show the production judgment: track routes rather than interfaces, size the decrement against the priority gap, and delay preemption so a recovering router does not black-hole traffic.
Weigh deterministic gateway placement against flap risk, and decide where failure detection belongs: tracking, faster liveness protocols, or a design that removes the single uplink.
## Why VRRP alone misses this failure VRRP watches exactly one thing: whether advertisements from the Active Router keep arriving on the LAN. RFC 9568 elects the Active Router by **priority**, and a Backup takes over only when its `Active_Down_Timer` expires. An Active Router whose upstream link to the core or the WAN has failed is still perfectly healthy on the LAN side. It keeps sending advertisements, keeps answering ARP for the virtual IP, and keeps receiving every host's off-subnet traffic, which it can no longer deliver. The standby router a few metres away has a working uplink and never gets used. ## Tracking: what it is and whose it is **Tracking** is not in RFC 9568. It is a feature implementations add, and its behaviour, its syntax and its defaults are each implementation's choice. The common shape: - the router watches an **object**: an interface's state, the presence of a route in its table, or the result of a reachability probe; - when the object goes down, the router **lowers its own VRRP priority** by a configured amount; - when the object comes back, the priority is restored. Tracking only changes the number in the advertisement. Whether the role actually moves is decided by the protocol's ordinary rules, so the configuration has to satisfy them. ## The arithmetic that makes it work Take router A as Active at priority 110 and router B as Backup at priority 100, advertisement interval 1 s, with A tracking its uplink. | Decrement | A's priority after uplink loss | B's Preempt_Mode | Outcome | |---|---|---|---| | 10 | 100 | True | **no change**: B accepts an equal-priority advertisement | | 20 | 90 | True | B ignores A's advertisements and becomes Active after about 3.61 s | | 20 | 90 | False | **no change**: B accepts advertisements of any priority | | any | A is the address owner | n/a | outside the RFC: the owner's priority must be 255 | So the rules are: the decrement must take the Active **strictly below** the Backup, the Backup must **preempt**, and the virtual IP should not be owned by either router. ## Walking the failover 1. A's uplink fails; the tracked object goes down after whatever detection delay the implementation has. 2. A starts advertising priority 90 instead of 110. 3. B, at 100 with preemption on, discards each of those advertisements, so its timer is no longer reset. 4. After `Active_Down_Interval = 300 + (156 x 100) / 256 = 360.94` centiseconds, about 3.61 s, B becomes Active, advertises priority 100 and announces the virtual MAC. 5. A hears a higher priority and drops to Backup. Traffic is lost from the uplink failure until step 4. Faster interface or route detection, or a liveness protocol such as BFD feeding the tracked object, shortens step 1; step 4 is VRRP's own timer. ## Preemption flapping and its cures Preemption is what lets tracking move the role, and it is also what moves it back. When A's uplink returns, A's priority returns to 110, and A, now a preempting Backup, takes the role back after its own down interval. Problems appear when that happens at the wrong moment: - **Flapping uplink**: each down/up cycle moves the gateway twice, and every move costs a takeover window and a burst of MAC relearning in the switches. - **Interface up, routes not ready**: the link comes up seconds before the routing protocol has relearned its routes, so A reclaims the gateway and black-holes traffic until routing converges. - **Reboot**: a rebooted higher-priority router preempts as soon as VRRP starts, again possibly ahead of its routing. The usual cures, all implementation features: 1. A **preemption delay**, so a recovered router waits before reclaiming the role. 2. **Tracking a learned route**, such as the default route from upstream, instead of interface state: priority returns only once the path really exists. 3. **Dampening** or hold-down on the tracked object, so a bouncing link counts as down until it has been stable for a while. ## Design checklist - Use a virtual IP that neither router owns, with priorities in 1-254. - Make the decrement larger than the priority gap. - Enable preemption on every router that should be able to take the role. - Delay preemption long enough for routing to converge.
- Why is tracking a route learned over the uplink better than tracking the uplink interface's state?Interface state says the link is up, not that it delivers: it can be up while the upstream router or its routing session is dead, and after a repair it comes up seconds before routes are relearned. Tracking a default or summary route learned from upstream lowers the priority whenever the router really has no path, and restores it only once the path exists again.
- What happens if the VRRP Backup has preemption off when the Active Router's tracked uplink fails?Nothing moves. In the Backup state with `Preempt_Mode` False, RFC 9568 accepts every advertisement whatever its priority and keeps resetting the down timer, so the lowered priority is ignored and the router with the dead uplink stays Active. Tracking and preemption only work as a pair.
saying these in an interview costs you the question
- Tracking is defined in the VRRP specification, so every implementation behaves the same.
- Lowering the Active's priority until it equals the Backup's is enough to move the role.
- Preemption is needed only on the router whose priority is being tracked.
- When the uplink dies, VRRP fails over by itself after three missed advertisements.
- Preemption should be on everywhere with no delay, since the best router must always forward.