Wheelhouse docs

Two routers, one virtual address#

You will end up with two routers sharing a virtual address on a segment, one of them holding it at a time, and clients pointing at that address rather than at either router. keepalived does the election; Wheelhouse drives it through high-availability vrrp and shows keepalived's live per-group state beside the configuration.

Before you start#

  • The operator role and a licence on both routers.
  • Two routers on the same segment, each with its own real address on that interface.
  • A virtual address on that subnet that nothing else uses.
  • A VRID — a number from 1 to 255, unique on that segment. The page suggests a free one.

Step 1 — Create the group on the first router#

Network → High availability → VRRP → + Add group.

set high-availability vrrp group lan interface eth0
set high-availability vrrp group lan vrid 10
set high-availability vrrp group lan address 192.0.2.1/24
set high-availability vrrp group lan priority 200
set high-availability vrrp group lan description 'lan gateway'

The panel writes priority only when it is not 100, advertise-interval only when it is not 1 second, and each virtual address as its own line.

Step 2 — Create the matching group on the second router#

Same VRID, same interface, same virtual address, lower priority.

set high-availability vrrp group lan interface eth0
set high-availability vrrp group lan vrid 10
set high-availability vrrp group lan address 192.0.2.1/24
set high-availability vrrp group lan priority 100

The higher priority wins and holds the address. With no-preempt, a router that comes back does not take the address off the one currently holding it:

set high-availability vrrp group lan no-preempt

Or delay the takeover instead:

set high-availability vrrp group lan preempt-delay 30

The panel offers these as either/or, because a delay on a group that never preempts is meaningless.

Step 3 — The two extras the panel offers#

Authentication, which stops anything on the segment from advertising a higher priority:

set high-availability vrrp group lan authentication type plaintext-password
set high-availability vrrp group lan authentication password 'the shared secret'

It is a plain-text password on the wire; it prevents a mistake, not an attacker.

Unicast peers, for a segment where multicast is unreliable or filtered:

set high-availability vrrp group lan peer-address 192.0.2.3

RFC 3768 compatibility is the third checkbox, for interoperating with implementations that need the older behaviour.

Step 4 — Group several addresses into a sync group#

If a router should hold the LAN address and the DMZ address together — never one without the other — put both groups in a sync group:

set high-availability vrrp sync-group HA member lan
set high-availability vrrp sync-group HA member dmz

The page's sync-group panel takes the members as checkboxes and stages one line each.

Step 5 — Commit on both routers, one at a time#

Commit on the intended primary first, confirm it holds the address, then commit on the secondary. Committing both at once and then debugging is a worse afternoon than doing them in order.

Connection state across a failover#

Without it, every existing connection breaks when the address moves. service conntrack-sync copies the connection table between the pair over a dedicated interface.

Network → High availability → Conntrack sync.

set service conntrack-sync interface eth3
set service conntrack-sync failover-mechanism vrrp sync-group HA
set service conntrack-sync accept-protocol tcp

Use an interface that carries nothing else — the state table is not small, and it is not authenticated by this configuration.

Check it worked#

Both routers agree on who is master. The VRRP page shows each group with keepalived's live state from the router's own show vrrp, its priority, its sync group and whether it is disabled. When keepalived reports that data is not available, the page says the state is not running rather than inventing one.

bash
show vrrp
ip addr show eth0        # the master has the virtual address, the backup does not

Two masters is the failure to look for. It means the two routers cannot see each other's advertisements — a firewall rule, a switch, or a VRID that does not match.

Then fail it deliberately. Disable the group on the master:

set high-availability vrrp group lan disable

The page's Disable stages that. The backup should take the address within a couple of advertisement intervals, and a client pinging the virtual address should lose at most a packet or two. Re-enable and watch it come back, or stay put if no-preempt is set.

What you still have to do twice#

Everything else. Firewall rules, NAT, DHCP, DNS records, port forwards, accounts, API tokens, backups. Two routers in a VRRP pair are two routers.

Config as code with agent.yaml is the honest way to keep them in step: one file, applied to both, with a reconcile loop or a scripted apply. That is a convention you maintain, not a feature of VRRP.

Undoing it#

delete high-availability vrrp group lan
delete service conntrack-sync

On the backup first, then the master, so the address never has two claimants and never has none.

See also#


Checked against ui/src/pages/Vrrp.tsx · ui/src/pages/Ha.tsx · agent/gaps.go

Updated 2026-09-02 vrrp ha keepalived