Runbook: Configure VRRP

VRRP is the only change in this toolkit where doing half of it produces something that looks finished. Configure one router, and you get a working virtual gateway address: hosts resolve it, traffic flows, show vrrp says Master. What you do not get is redundancy — and nothing on the page says so. The pair is the unit of work here, and the runbook is written for two operators on two routers in one window.

The second thing to hold onto: VRRP protects the host-to-router hop and nothing else. It moves a gateway address between two routers on the same segment. It does not choose a path, it does not know whether the router that wins the election can actually reach the Internet, and it will cheerfully keep a master that has lost its uplink. Making it react to that is the tracking decision, and it is the difference between VRRP as redundancy and VRRP as decoration.

When this runbook applies

• A LAN segment is getting a redundant default gateway across two VyOS routers for the first time.
• A second router is being added to a segment that currently has one.
• An existing VRRP group is being extended with tracking, or having its priority or preemption policy changed.

When it does not apply

• You need redundancy between routers, not for hosts. VRRP is first-hop redundancy. Path redundancy between routers is what OSPF and BGP are for, and reaching for VRRP there produces a design that fails in ways neither protocol was meant to handle.
• The two routers are not on the same Layer 2 segment. VRRP advertisements are multicast to 224.0.0.18 with TTL 255 and do not cross a routed boundary. If the routers cannot see each other’s advertisements, both become master.
• The pair is already up and misbehaving. Two masters, a failover that never fires, or traffic that dies after a failover are diagnoses. Use the VRRP troubleshooting runbook.
• The virtual address is currently a live gateway on one router. Converting a real gateway address into a virtual one is a higher-risk change than this runbook covers: for a period, two things on the segment want to answer for the same IP.

Blast radius

Every host on the segment that uses this address as its default gateway.

That is the number for the ticket. Not “two routers” — the count of hosts whose off-network traffic stops if this goes wrong. It is also the reason the failover test is not optional and not free: the test is a deliberate, short outage for all of them, and it needs the LAN owner’s agreement before the window, not during it.

The three decisions to make before the window

Priority, with the tracking decrement in mind

The higher priority wins the election; ties break on the higher IP address. The default is 100, and a typical pair uses 200 and 100.

The number that actually matters is the effective priority once tracking applies. If the master is 200 and tracks its uplink with a decrement of 150, its effective priority when that uplink dies is 50 — comfortably below the backup’s 100, which is the point. Choose the decrement so the result genuinely crosses the backup’s priority; a decrement that leaves the master still on top is a tracking configuration that does nothing at all.

Work out what happens when both tracked objects fail, too. The priorities collapse together, the election falls back to the tie-break, and whichever router wins has no working uplink either. That is not a bug you can configure away — it is the honest answer that the LAN has lost both paths — but you should know which router you will find as master when it happens.

Preemption: return to the design, or stay put

Enabled (the default), a recovered master takes the role back, which returns the pair to its designed state at the cost of a second short interruption. Disabled, the survivor stays master and the pair is left in the state the failure produced.

The argument that settles it is upstream symmetry. If both routers reach the outside world the same way, preemption is harmless and returning to the design is worth having. If each router has its own upstream and there is a stateful firewall anywhere in the return path, preemption moves live sessions to a path that has no state for them, and the recovery of the master becomes a second outage. In that estate, disable it.

Tracking: what should cost this router the master role

Without tracking, a master whose uplink has failed keeps advertising at full priority and keeps attracting all the LAN’s traffic into a blackhole. Interface tracking is the cleanest form because a port that goes down is an unambiguous event. Route tracking suits an upstream that is learned dynamically, where the failure shows up as a route disappearing rather than a link dropping. Remote-IP tracking is for where neither is true, and it needs a threshold so a single lost probe does not move the gateway.

Prove the way back in, on both routers

show version
show interfaces

Two routers, two console sessions, both open for the whole window. A VRRP change that goes wrong does not take one router away — it takes the segment’s gateway away.

Capture the baseline, including what the hosts use today

show vrrp
show vrrp detail
show configuration commands | grep vrrp
show interfaces

Then record, from the LAN side, what the hosts currently use as their default gateway. This is the thing you have to be able to put back, and it is not visible from the router.

Confirm the virtual address is free. Nothing on the segment may already answer ARP for it, and it must not be a real address on either router — unless IP-owner mode is the deliberate design, in which case the router that owns it takes priority 255 and always wins. Priority 255 on a router that does not hold the address as a real interface address is the misconfiguration to avoid: the router insists on being master without being able to own the address, and the result is erratic transitions.

Build the group on the intended master

configure

set high-availability vrrp group 1 interface eth0
set high-availability vrrp group 1 virtual-address 192.168.1.1/24
set high-availability vrrp group 1 priority 200
set high-availability vrrp group 1 advertisement-interval 1000
set high-availability vrrp group 1 version 3
set high-availability vrrp group 1 preemption delay 0

# React to the uplink, not just to the router being alive
set high-availability vrrp group 1 track interface eth1 priority-decrement 150

compare

Read the compare output for the fields that have to be identical on the backup: the group id, the interface, the virtual address, the version and the advertisement interval. Priority is the only field that is supposed to differ — plus the tracked interface name, if the two routers track different uplinks, which they usually do.

Commit the master first

commit-confirm 10
exit

show vrrp
show vrrp detail

Order matters. Whichever router you commit first becomes master, because nothing else is advertising yet. Committing the intended backup first means the pair comes up inverted and then has to transition once the master appears — an extra, avoidable state change on a live segment.

Confirm the virtual MAC while you are here. For IPv4 it is 00:00:5E:00:01:XX, where the last byte is the group id in hex: group 1 is 00:00:5E:00:01:01, group 10 is 00:00:5E:00:01:0A. That OUI is reserved, so it can never collide with a real NIC — which means an ARP entry showing it is unambiguous evidence that the host is talking to the virtual router.

Build the backup

configure

set high-availability vrrp group 1 interface eth0
set high-availability vrrp group 1 virtual-address 192.168.1.1/24
set high-availability vrrp group 1 priority 100
set high-availability vrrp group 1 advertisement-interval 1000
set high-availability vrrp group 1 version 3
set high-availability vrrp group 1 preemption delay 0
set high-availability vrrp group 1 track interface eth1 priority-decrement 150

compare
commit-confirm 10
exit

Read back what the daemon actually has

show vrrp
show vrrp detail
show vrrp track
show vrrp summary

show vrrp detail is the one that matters, because it reports what the daemon is using rather than what you typed. Timer units are the commonest place for a VRRP change to be quietly wrong — treat a difference between the value you set and the value reported here as a stop condition and resolve it before the failover test, not after.

show vrrp track confirms the tracked objects loaded and are up. A tracking stanza that committed but shows nothing here is a tracking configuration that will not fire when you need it.

Confirm the wire agrees with both routers:

# Substitute your own values before running:
LAN_IF=eth0

sudo tcpdump -ni "$LAN_IF" 'ip proto 112' -c 10 -vv

Exactly one source address should be sending advertisements. The capture is the arbiter when the two routers disagree: configuration can be wrong, daemon state can be stale, but the segment shows what is really happening.

Prove the failover

A VRRP pair that has never failed over has not been verified. This is the step that gets cut when the window runs short, and it is the step that decides whether the pair works when it matters.

Fail the tracked uplink, not the router. That is the better test for two reasons: it exercises the tracking path, which is the part most likely to be misconfigured, and it leaves you logged into the master so you can watch the transition and reverse it.

# Admin-down the uplink at the far end, or unplug it. Then, on the master:
show vrrp
show vrrp track

While it is failing over, measure three things from a host on the segment: how long traffic stops, whether it comes back on its own, and whether the host’s ARP entry still points at the virtual MAC. The third is what tells you the failover happened at the VRRP layer rather than the host re-resolving. Record the recovery time in the ticket; it is the number someone will ask for during the next incident.

Expect the recovery to take longer than the protocol timers suggest. The switch also has to relearn which port the virtual MAC lives on, and the gratuitous ARP the new master sends is what prompts it. On a large segment that relearn is a visible part of the total.

Then restore the uplink and confirm the pair settles the way the preemption decision says it should: back to the original master if preemption is enabled, staying put if it is not. A pair that does something else has a preemption setting that does not match the ticket.

Confirm both routers, or hold both

configure
confirm
save
exit

Both routers. A confirmed master with an unconfirmed backup reverts to a single router the moment the backup’s timer expires, and it does so quietly — the pair was working when everyone stopped looking.

Holding is a first-class option, and here it is symmetric. If anything failed, let both timers expire so the segment goes back to the gateway it had this morning. Leaving one router configured is the worst of the three states: it looks like redundancy, and it is not.

Rollback

configure
delete high-availability vrrp group 1
commit
save
exit

Roll the backup back first, then the master. The other order hands the virtual address to a router you are about to strip it from.

Removing VRRP removes the virtual address from the segment. Every host pointing at it as a default gateway loses its gateway at that instant, so restoring the LAN to a real router address is part of the rollback, not a follow-up. And hosts that cached the virtual MAC keep sending to it until the entry ages out, so recovery is not instantaneous even once both routers are clean.

Common patterns

Provenance

This runbook has not been executed end to end against a live router pair, which is why last_verified reads pending rather than carrying a date. Its command set comes from the course’s own VRRP lessons — vyos-xl-01-vrrp-concept, vyos-xl-02-priority-and-skew, vyos-xl-03-preemption, vyos-xl-05-vrrp-tracking and vyos-xl-06-vrrp-troubleshoot — the telemetry material in vyos-xlix-04-vrrp-telemetry, and the commit discipline in vyos-vi-02-commit-confirm. No command output is reproduced here, because none of it was captured.