How long does VRRPv3 take to declare a silent Active Router down, and what do sub-second advertisement intervals buy and risk?
answer
- three intervals plus skew
- skew shrinks as priority rises
- centiseconds in a 12-bit field
- queueing delay mimics failure
- VRRPv2 counts whole seconds
basics
~20 sA VRRPv3 Backup declares the Active down after 3 x interval + Skew_Time, about 3.61 s at the 1-second default for priority 100. Centisecond intervals cut that below 40 ms, but risk false failovers under queueing delay and complicate mixed VRRPv2 operation.
solid answer
~50 sRFC 9568 carries the interval in centiseconds in a 12-bit field, default 100 cs (1 s). A Backup waits `Active_Down_Interval = 3 x Active_Adver_Interval + Skew_Time`, where `Skew_Time = ((256 - Priority) x Active_Adver_Interval) / 256`: for priority 100 that is 300 + 60.94 = 360.94 cs, about 3.61 s, and at priority 200 about 3.22 s, so the best Backup's timer fires first. A 10 cs interval brings detection to about 361 ms, and the RFC says convergence is configurable below 1/25 s. The costs: the Active must send every advertisement on time, so egress queueing or a busy control plane can delay one past the down interval; a Backup promotes itself and steps back when the late packet arrives, a flap the RFC warns about. VRRPv2 peers count whole seconds, and the failover only helps if upstream routing converges as fast.
go deeper
Remember the default: VRRPv3 advertises once a second and a Backup gives up on a silent Active after roughly three and a half seconds.
Compute Skew_Time and Active_Down_Interval for a given priority and interval, and explain why the skew lets the highest-priority Backup win.
Weigh sub-second intervals against false failovers from queueing, control-plane load and VRRPv2 interoperation, and know when to hand detection to BFD or tracking instead.
Set the gateway's failover target inside an end-to-end convergence budget, deciding which layer should detect failure fastest and what each choice costs.
## The two formulas RFC 9568 defines every VRRPv3 timer in **centiseconds**. The advertisement interval travels in the 12-bit **Max Advertise Interval** field of each advertisement; its default is 100 centiseconds (1 second) and its largest value is 4095 centiseconds, about 40.95 seconds. A Backup Router copies the interval it hears from the Active Router into `Active_Adver_Interval` and derives two values from it: - `Skew_Time = ((256 - Priority) x Active_Adver_Interval) / 256` - `Active_Down_Interval = (3 x Active_Adver_Interval) + Skew_Time` The Backup's `Active_Down_Timer` is reset to `Active_Down_Interval` by every accepted advertisement. If it fires, the Backup becomes Active. ## Worked numbers | Interval | Backup priority | Skew_Time | Active_Down_Interval | |---|---|---|---| | 100 cs (1 s) | 100 | 60.94 cs | 360.94 cs, about 3.61 s | | 100 cs (1 s) | 200 | 21.88 cs | 321.88 cs, about 3.22 s | | 100 cs (1 s) | 254 | 0.78 cs | 300.78 cs, about 3.01 s | | 10 cs (100 ms) | 100 | 6.09 cs | 36.09 cs, about 361 ms | | 1 cs (10 ms) | 100 | 0.61 cs | 3.61 cs, about 36 ms | The last row is what RFC 9568 means when it says election convergence is under 4 seconds with the default interval and configurable to under 1/25 second (40 ms). A graceful shutdown is faster still: an Active Router that sends priority 0 makes Backups wait only `Skew_Time`, about 0.61 s for priority 100 at the default interval. ## Why the skew exists Without skew, every Backup would time out at the same instant and several would go Active together. The skew is **smaller for higher priorities**, so the best Backup's timer fires first; its advertisement then reaches the others before their timers expire, and they stay Backup. RFC 9568 adds that priorities should differ by enough that lower Backups do not go Active before they hear the new Active Router. ## What a sub-second interval buys 1. **Faster detection** of a dead Active Router, from seconds to hundreds or tens of milliseconds. 2. **Less traffic lost** per unplanned failover, which matters for voice, storage and transactions that time out in seconds. 3. Faster discovery of a peer that has come back and should preempt. ## What it risks - **False failover from queueing.** RFC 9568 section 2.5 describes it: when a router generates more packets than it can transmit, advertisements wait in an egress queue for longer than the down interval. A Backup decides the Active is dead and promotes itself; the delayed advertisement then arrives and it steps back, and this can repeat many times per second. The RFC suggests prioritising VRRP packets on egress queues and logging the condition. - **Control-plane load.** Each virtual router at 1 cs is 100 advertisements a second to send, and Backups must process them; multiplied across many VLANs, that competes with everything else the router does. - **Version mixing.** VRRPv2 (RFC 3768) carries its interval in whole seconds. RFC 9568 makes interoperation optional, meant only for upgrades: a VRRPv3 Active sending at centisecond rates could overwhelm a VRRPv2 Backup, and a VRRPv2 router should not be given a higher priority than a sub-second VRRPv3 peer. - **Mismatched intervals.** A higher-priority Active advertising more slowly than its Backups is unstable, since a faster Backup joining the LAN may go Active before it hears from it. Receivers SHOULD check that the received interval matches their configuration and log a mismatch. ## Where the timer sits in the budget VRRP detection is only the first hop of the recovery. Once a Backup becomes Active, switches must relearn the virtual MAC and the new Active Router must have upstream routes, or the fast failover simply moves the black hole. Many designs therefore keep VRRP at a moderate interval and let a dedicated liveness protocol such as BFD, or priority tracking of upstream routes, drive the decision where it matters.
- Why does a VRRP Backup compute its down interval from the Active Router's advertised interval rather than its own setting?The Backup sets `Active_Adver_Interval` from the Max Advertise Interval in each advertisement it accepts, so its timeout always scales with how often the current Active actually sends. Using its own faster setting would declare a slower Active dead between packets. RFC 9568 still recommends logging a mismatch, because a slow high-priority Active is unstable whenever a faster Backup joins the LAN.
- If sub-second VRRP timers are risky, how else can a gateway pair fail over quickly?Keep VRRP at a moderate interval and let a dedicated liveness check drive it: many implementations can lower a router's VRRP priority from a failed BFD session or a missing upstream route. Make sure upstream routing converges as fast as the first hop, because a sub-second failover onto a router without routes only moves the black hole.
saying these in an interview costs you the question
- VRRP declares the Active Router dead after a single missed advertisement.
- Every Backup waits exactly the same time, whatever its priority.
- VRRPv3 intervals are whole seconds, so one second is the shortest possible.
- Shorter advertisement intervals cost nothing beyond a little extra bandwidth.
- After a priority-0 advertisement, Backups still wait the full three intervals.