VRRP preemption — higher priority takes over, and when to disable it

Preemption is the lever that decides what happens when the original master recovers after a failure. With preemption enabled (the default), the higher-priority router takes over the master role as soon as it comes back online. With preemption disabled, the lower-priority router (which became master during the outage) stays as master until it itself fails.

The choice seems trivial, but it has significant production implications. A failed-and-recovered router that pre-empts the master can cause an asymmetric-traffic failure mode during the takeover, especially if the network has stateful firewalls in the path. Operators who leave preemption enabled without thinking about the implications will see traffic interruption during recovery events.

This lesson covers what preemption does, how preemption delay tunes the behaviour, the production trade-offs of enabled versus disabled, and the failure modes that arise from each choice.

What preemption does

When the master router fails and a backup takes over, two things can happen when the original master recovers:

• Preemption enabled (default). The recovered master sends advertisements with its higher priority. Within a few seconds, the new master (the backup) sees the advertisements, recognises that a higher-priority router is available, and steps down to backup. The original master becomes master again. The hosts see a brief interruption during the transition.
• Preemption disabled. The recovered master sends advertisements with its higher priority, but the current master (the original backup) ignores them. The current master stays as master; the original master remains in backup. The state has flipped compared to the original configuration.

The choice is policy: should the network return to its original state after a failure, or should it stay in whatever state the failure produced?

sequenceDiagram
  participant OM as Original Master priority 200
  participant OB as Original Backup priority 100
  participant LAN as LAN
  Note over OM,OB: Initial state: OM master
  OM->>LAN: advertisements at priority 200
  Note over OM: OM fails
  OB->>OB: detects failure in 3s plus skew
  OB->>LAN: gratuitous ARP
  OB->>LAN: advertisements at priority 100
  Note over OM: OM recovers
  alt Preemption enabled
    OM->>LAN: advertisements at priority 200
    OB->>OB: detects higher priority and steps down
    OM->>LAN: gratuitous ARP
    Note over OM,OB: OM is master again
  else Preemption disabled
    OM->>LAN: advertisements at priority 200
    OB->>OB: ignores because no preemption
    Note over OM,OB: OB remains master
  end

The preemption behaviour is configurable per VRRP group. Some operators enable it everywhere (because the production network should return to its designed state); others disable it (because the asymmetry during a takeover is worse than the asymmetry of having the “wrong” router as master).

The preemption delay

When preemption is enabled, the recovered master does not take over immediately. The protocol requires the recovered master to wait a configurable delay (in centi-seconds) before announcing itself as master. The delay exists to prevent flapping during the recovery window — the master waits long enough for any transient issues to settle before taking over.

The default delay is 0 centi-seconds (no delay). Many operators set a small delay (e.g., 100 = 1 second) to give the network a moment to stabilise.

# Enable preemption with a 1-second delay
set high-availability vrrp group 1 preemption delay 100

# Disable preemption entirely
set high-availability vrrp group 1 preemption disable

# Default (preemption enabled, no delay)
delete high-availability vrrp group 1 preemption

The delay is local to the recovered master: when the master recovers, it waits delay centi-seconds before announcing itself. The wait happens regardless of whether the current master is sending advertisements (the recovered master still has to wait before it can announce its higher priority).

Trade-offs: enabled vs disabled

The choice between preemption-enabled and preemption-disabled is not arbitrary. Each option has trade-offs.

Preemption enabled (default):

• The network returns to its designed state after recovery.
• The “right” router is the master again (the one the operator configured to be master).
• The cost: a brief traffic interruption (1-3 seconds) during the takeover.
• The risk: asymmetric traffic during the takeover if the master-to-backup transition moves traffic to a different path in the network.
• The flapping risk: if the recovery is not stable (e.g., the master is recovering from a CPU issue), preemption can cause rapid master/backup transitions.

Preemption disabled:

• The network stays in whatever state the failure produced.
• The “wrong” router remains master; the original master is backup.
• The cost: the routing paths may not match the design. Traffic that was meant to go through R1 (master) now goes through R2 (master).
• The benefit: no traffic interruption during recovery. The state is stable until the next failure.
• The use case: when the asymmetry of a takeover is worse than the asymmetry of having the wrong master.

The choice depends on the network design. A symmetric network (where both routers have the same upstream path) does not care which is master; preemption is fine. An asymmetric network (where each router has a different upstream) needs careful thought — sometimes it’s better to leave the master as-is.

Configuration and validation

configure
# Enable preemption with a 5-second delay (allows STP to converge)
set high-availability vrrp group 1 preemption delay 500

# Or disable preemption entirely
set high-availability vrrp group 1 preemption disable

commit
save

Validation:

# Check the preemption setting
show vrrp
# "Preemption: enabled, delay 500ms"
# or "Preemption: disabled"

# Verify the master state
show vrrp
# Shows Master/Backup/Initialize for each group

# Trace advertisements to see when the master changes
tcpdump -ni eth0 'ip proto 112' -c 4
# Capture shows the priority in each advertisement

A clean validation: the preemption setting matches the design (enabled delay X or disabled); the master state is consistent with the configured priorities.

Production failure modes

Flapping during recovery

The recovered master pre-empts, but its advertisements are not yet reaching the backup (e.g., STP is blocking the port). The backup thinks the master has failed and takes over. The recovered master then succeeds. The routers alternate master/backup rapidly.

Diagnostic: show vrrp state transitions; tcpdump on the LAN shows alternating sources of advertisements.

Fix: increase the preemption delay (e.g., to 30-60 seconds) to allow STP to converge.

Asymmetric traffic at pre-emption

The master changes from R2 to R1 during recovery. The upstream stateful firewall (where the return traffic was flowing through R2) loses state for the new traffic.

Diagnostic: hosts work after recovery but upstream services fail (stateful firewall drops the SYN-ACK).

Fix: disable preemption (or align the routing so both routers have the same upstream path).

Preemption never takes effect

The operator configures preemption with a long delay (e.g., 60000 centi-seconds = 10 minutes), then expects the master to take over after a recovery. The router waits 10 minutes, then takes over. The operator is confused why the takeover is so slow.

Diagnostic: show vrrp on the recovered master — preemption enabled, delay = 60000 centi-seconds. The wait matches the configured delay.

Fix: reduce the delay.

Preemption disabled but master recovers as backup

The operator disables preemption; the recovered master remains as backup; the original backup stays as master. The operator expects preemption to be enabled because the configuration “looks” enabled.

Diagnostic: show vrrp on both routers; recovered router shows Preemption: disabled.

Fix: re-enable preemption if it was meant to be enabled.

Rollback

# Capture the running configuration
show configuration commands | grep vrrp | save /tmp/vyos-vrrp-preempt-backup.txt

# Compare
compare

# Remove the preemption change
delete high-availability vrrp group 1 preemption
commit

# Or restore a previous configuration
load /tmp/vyos-vrrp-backup.conf
commit

The rollback removes the explicit preemption setting; the protocol falls back to the default (enabled, delay 0). The state returns to default VRRP behaviour.

Production discipline

Cross-course references

• Part XL-02 (XL-VyOS-VRRP / priority and skew) covers the priority field that drives preemption behaviour.
• Part XL-04 (XL-VyOS-VRRP / advertisements) covers the advertisement format and the priority field within advertisements.
• Part XL-05 (XL-VyOS-VRRP / tracking) covers how link failures influence priority and therefore influence preemption decisions.
• Part XXXIX-04 (XXXIX-VyOS-MultiWAN / policy routing) covers the asymmetric-routing complications that interact with VRRP preemption.

Quiz