VRRP#

The second tab of High availability, at /ha?tab=vrrp. It owns the high-availability vrrp subtree. Two routers share a virtual address; the one with the higher priority answers for it, and the other takes over when the first stops advertising. This tab configures the groups and shows what keepalived says about each of them right now.

VyOS runs keepalived for this. Wheelhouse configures it through the config tree and reads its state through show vrrp; nothing here is Wheelhouse's own daemon.

Where the data comes from#

GET /api/vrrp, polled every 10 seconds, returns four things — agent/gaps.go (handleVRRP):

{
  "config": { "vrrp": { "group": { "LAN": { "…": "" } } } },
  "conntrack_sync": null,
  "groups": [ { "name": "LAN", "interface": "eth0", "vrid": "10", "state": "MASTER", "priority": "150", "last_transition": "…" } ],
  "running": true,
  "raw": "…"
}

config is the high-availability subtree, groups is show vrrp parsed into rows, and running is false when that command printed not available or nothing at all. conntrack_sync is the service conntrack-sync subtree, which the Conntrack sync tab uses.

One detail worth knowing when you are reading logs: VyOS answers a read of an unset path with HTTP 400 and the words Configuration under specified path is empty. The handler treats that as "no HA configured" rather than as an unreachable router, so a router without HA does not show an error here.

The four tiles#

keepalived: stopped on a router with no groups is normal — the daemon starts with the first group. Stopped with groups configured is a fault.

The group table#

The State column has four possible badges from keepalived — master green, backup blue, fault red, init grey — and three fallbacks when there is no state to show:

• disabled — the group has disable set in the configuration.
• not reported — keepalived is running and did not mention this group. A group that was just added and not yet committed, or a group the daemon refused.
• keepalived not running — show vrrp said nothing.

The group panel#

Clicking a row opens a panel with the full configuration of the group:

The only editor in the panel is Priority, which stages one command:

set high-availability vrrp group LAN priority 150

The footer has Disable / Enable, which stages set or delete of high-availability vrrp group LAN disable, and Delete group, which stages delete high-availability vrrp group LAN.

Everything else — changing the virtual address, the advertise interval, the authentication — is done by deleting the group and adding it again, or from the config tree and the CLI. The add panel is where those fields exist.

Adding a group#

+ Add VRRP group requires a name, an interface and at least one address.

A complete first group:

set high-availability vrrp group LAN interface eth0
set high-availability vrrp group LAN vrid 10
set high-availability vrrp group LAN address 10.0.0.254/16
set high-availability vrrp group LAN priority 150

What must match on both routers, and what must not#

The panel's subtitle says it: The same name, VRID and address go on the partner router, with a different priority.

The virtual address is written with a prefix length, like any other address. Use the prefix length of the segment, not /32.

Preempt#

By default a router that comes back with the higher priority takes the address back as soon as it is able. Never preempt turns that off: the recovered router stays backup until the current master fails. Preempt delay keeps preemption but waits, which is what you want on a router whose uplink takes longer to come up than its LAN interface — otherwise it grabs the address and blackholes traffic while its WAN is still negotiating.

Authentication#

The panel writes plaintext-password when a password is given. That is a shared secret sent in the clear on the segment; it stops an accidental second VRRP speaker, not an attacker on the same wire. It is a password leaf, so GET /api/config blanks it for anyone below admin — agent/security.go.

Unicast peers#

With no peers, VRRP advertisements go to the multicast group. Some virtual switches and cloud networks drop them, and then both routers are master. Listing the partner's real address as a peer sends advertisements unicast instead.

Sync groups#

Two groups on one router — a LAN group and a WAN group — should fail over together, or you end up with a router holding the LAN address and no way out. A sync group ties them:

set high-availability vrrp sync-group HA member LAN
set high-availability vrrp sync-group HA member WAN

+ Sync group asks for a name and a set of member groups, and stages one command per member. The sync-group panel lists each group with its members and a Delete that stages delete high-availability vrrp sync-group <name>.

A sync group is also what Conntrack sync attaches to, and its picker only offers groups that already exist.

What this tab will not do#

• It cannot edit a group in place, apart from the priority and the disable flag.
• It shows no advertisement counters, no transition history and no VRRP debug. The Since column is keepalived's last-transition timestamp, and that is the whole of the history available here.
• There is no IPv6 VRRP support in this page's editors. The address field takes whatever you type and the router validates it, but nothing on the page is v6-aware.
• It does not configure the partner router. Everything here is one box. The CLI tab is the fastest way to get the configuration across.

What breaks if you get it wrong#

• Both routers master. Mismatched advertise intervals, mismatched authentication, or multicast being dropped between them. Two routers answering for one address produces intermittent, direction-dependent failures that look like a bad cable.
• A VRID already in use on the link. VRIDs are per-link, not per-router. Another device using 10 on the same segment collides with yours.
• A virtual address inside a DHCP pool. The pool hands it to a laptop and the address is now in two places. Keep virtual addresses outside every range on DHCP.
• The master holds the LAN address and has no uplink. That is what a sync group is for. Without one, the LAN group has no reason to fail over just because the WAN did.
• Flows drop at every failover. Expected without Conntrack sync; the new master has never seen those connections.

See also#

• High availability — the page this tab belongs to.
• Conntrack sync — keeping established flows alive when the address moves.
• Uplinks (multi-WAN) — the other half: more than one way out.
• Interfaces — the interfaces a group is bound to.
• DHCP — keep the virtual address out of the pool.

Checked against ui/src/pages/Vrrp.tsx, agent/gaps.go (handleVRRP, parseVRRP), agent/parse.go (parseTable), agent/security.go, ui/src/lib/api.ts.