VRRP advertisements — packet format, IP protocol 112, multicast 224.0.0.18

The VRRP advertisement is the heartbeat that tells the network which router is master. Each advertisement is an IP packet with protocol 112, addressed to multicast group 224.0.0.18, containing the master router’s priority and the virtual IP addresses. Every backup router listens for these advertisements; when they stop arriving, the backup takes over.

The advertisement format is simple but precise. The protocol fields encode the version, the VRRP group ID, the priority, and the virtual IPs. A packet capture reveals everything about the protocol state — and almost everything about a misconfiguration.

This lesson covers the packet format, the multicast destination, the IP protocol number, and how to read a packet capture for diagnostics.

IP protocol number and multicast destination

VRRP uses IP protocol number 112 — a dedicated protocol number, not TCP or UDP. VRRP packets are encapsulated directly in IP: there is no transport-layer header. The IP header has:

• Source IP: the real interface IP of the sending router (not the virtual IP). The virtual IP is in the VRRP payload, not the IP header.
• Destination IP: 224.0.0.18 (the VRRP multicast group).
• Protocol: 112 (VRRP).
• TTL: 255 (RFC requirement; prevents the packet from being forwarded past the local subnet).
• DSCP: typically CS6 (48) or BE (0).

IP header
  src: 192.168.1.254       (R1's interface IP)
  dst: 224.0.0.18          (VRRP multicast group)
  proto: 112               (VRRP)
  ttl: 255
  length: variable

VRRP payload
  version: 3               (or 2 for VRRPv2)
  type: 1                  (1 = advertisement)
  vrid: 1                  (VRRP group ID)
  priority: 200            (master's priority)
  numips: 1                (number of virtual IPs)
  interval: 100            (centi-seconds; 1 second)
  ips: 192.168.1.1         (virtual IP)
  checksum: ...            (IPv4 pseudo-header checksum)

The multicast destination 224.0.0.18 is reserved by IANA for VRRP. Routers should not forward packets with this destination (TTL is also capped at 255, further confining the packet to the local subnet). A switch that receives the multicast forwards the frame out all ports in the same VLAN — this is how all VRRP routers on the LAN receive the advertisements.

Packet format (RFC 5798)

The VRRPv3 packet format (from RFC 5798):

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type  |   Virtual Rtr ID   |   Priority   | Count IP   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Max Adver Int  |   Checksum            |reserved             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   IP Address (1)              |              ...              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   IP Address (n)              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The fields:

• Version (4 bits): 3 for VRRPv3, 2 for VRRPv2.
• Type (4 bits): 1 for advertisement, 3 for leave (used to signal fast shutdown).
• Virtual Rtr ID (8 bits): the VRRP group ID (1-255).
• Priority (8 bits): 1-255 (with 255 reserved for IP owner).
• Count IP (8 bits): number of virtual IP addresses (1-255).
• Max Adver Int (8 bits): the advertisement interval in centi-seconds (default 100 = 1 second).
• Checksum (16 bits): IPv4 pseudo-header checksum.
• IP Address (32 bits each): the virtual IP addresses.

VRRPv3 also includes fields for IPv6 support: the IP Address entries can be IPv6 addresses (using a different packet format with an Address Family field). The IPv4 form is most common in production deployments.

A capture in practice

A real packet capture of VRRP advertisements on a VyOS host:

$ tcpdump -ni eth0 'ip proto 112' -c 4
12:34:56.789012 IP 192.168.1.254 > 224.0.0.18: VRRPv3, Advertisement, vrid 1, prio 200, authtype none, intvl 100cs, length 36
12:34:57.789234 IP 192.168.1.254 > 224.0.0.18: VRRPv3, Advertisement, vrid 1, prio 200, authtype none, intvl 100cs, length 36
12:34:58.789456 IP 192.168.1.254 > 224.0.0.18: VRRPv3, Advertisement, vrid 1, prio 200, authtype none, intvl 100cs, length 36
12:34:59.789678 IP 192.168.1.254 > 224.0.0.18: VRRPv3, Advertisement, vrid 1, prio 200, authtype none, intvl 100cs, length 36

The capture shows four advertisements, each one second apart. The fields visible:

• Source IP 192.168.1.254: R1’s real interface IP (the master).
• Destination 224.0.0.18: VRRP multicast.
• VRRPv3, vrid 1: protocol version and group ID.
• prio 200: the master’s priority.
• intvl 100cs: the advertisement interval in centi-seconds (100 = 1 second).
• length 36: packet length.

A diagnose uses these fields:

• If the source IP changes, the master changed (e.g., from R1 to R2).
• If the priority changes, the master changed (different router has a different priority).
• If the interval changes, the configuration changed.
• If the version changes (v2 vs v3), there is a version mismatch.

The discipline: tcpdump on a monitor port or directly on a VRRP router can reveal the master transitions and the protocol state. A capture that shows multiple sources for the same group indicates split brain.

$ tcpdump -ni eth0 'ip proto 112' -c 4 -vv

12:34:56.789012 IP (tos 0xc0, ttl 255, id 0, offset 0, flags [none], proto VRRP (112), length 56)
  192.168.1.254 > 224.0.0.18: VRRPv3, Advertisement, vrid 1, prio 200, authtype none, intvl 100cs, length 36
    192.168.1.1

Failure patterns visible in captures

A captures a network engineer can recognise in tcpdump:

• No advertisements: the master is down or the LAN is partitioned. tcpdump shows nothing; this is itself diagnostic.
• Multiple sources for the same group: split brain. tcpdump shows advertisements from two different source IPs.
• Version mismatch: one router sends VRRPv2, the other sends VRRPv3. They do not participate in the same group.
• Interval drift: the interval is not the configured value (e.g., configured 1s, observed 10s). A misconfiguration or hardware limitation.
• Authentication mismatch: with VRRPv2’s simple text authentication (deprecated), the auth string in the packet does not match; the receiver ignores the advertisement.
• Checksum errors: a corrupted packet; the receiver drops it. Rare in modern networks.

The packet capture is often the fastest way to diagnose VRRP problems. A 30-second capture shows the source IPs, the priorities, the intervals — and any mismatch between the configuration and the on-the-wire behaviour.

Configuration and validation

The configuration of the advertisement interval on VyOS:

configure
# Set the advertisement interval to 1 second (default)
set high-availability vrrp group 1 advertisement-interval 1000

# Or to 100 milliseconds
set high-availability vrrp group 1 advertisement-interval 100

# Set the protocol version
set high-availability vrrp group 1 version 3

commit

Validation:

# Inspect the interval and version
show vrrp
# "Advertisement interval: 1s" and "Version: 3"

# Verify on the wire
tcpdump -ni eth0 'ip proto 112' -c 4 -vv
# Confirms the interval and version match

# Inspect the virtual IPs in the payload
show vrrp detail
# Lists the virtual IPs and their addresses

A clean validation: the configured advertisement interval and version match the on-the-wire captures; the virtual IPs match the configuration; the priority values are correct.

Production failure modes

Advertisements dropped by a firewall

The LAN has a stateful firewall between the two routers that drops the VRRP multicast. The backup never sees the master’s advertisements and either stays as backup (if it never received any advertisements) or both become master (split brain).

Diagnostic: tcpdump on the backup’s LAN interface shows no advertisements from the master.

Fix: configure the firewall to allow VRRP multicast (protocol 112, destination 224.0.0.18).

Router cannot handle the configured interval

The operator sets advertisement-interval 100 (100ms) but the router is too slow. The actual interval is 1s (the protocol floor). tcpdump shows the actual interval; show vrrp may show the configured value (or fall back).

Diagnostic: tcpdump shows 1s intervals despite the 100ms configuration.

Fix: upgrade the hardware or accept the default interval.

Multicast disabled on the switch

The LAN switch has multicast disabled (broadcast/multicast filtering enabled). The VRRP advertisements are dropped. Both routers cannot see each other’s advertisements.

Diagnostic: tcpdump on each router shows the router’s own advertisements but not the peer’s.

Fix: enable multicast forwarding on the switch (or enable IGMP snooping properly).

Authentication mismatch (VRRPv2)

The two routers have different authentication strings. The receivers drop advertisements with the wrong auth string. Both become master (split brain).

Diagnostic: tcpdump shows advertisements but the receivers do not enter master state. The router logs may show “authentication failure” messages.

Fix: align the authentication strings, or upgrade to VRRPv3 (no authentication, more secure).

Rollback

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

# Compare
compare

# Remove the advertisement change
delete high-availability vrrp group 1 advertisement-interval
delete high-availability vrrp group 1 version
commit

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

The rollback removes the explicit interval and version; the protocol falls back to the defaults (1s interval, version 2 for backward compatibility, but most modern operators set version 3 explicitly).

Production discipline

Cross-course references

• Part I-03 (I-VyOS-Foundations / TCP, UDP, ICMP) covers the IP protocol field and how it relates to TCP/UDP.
• Part XL-01 (XL-VyOS-VRRP / VRRP concept) covers the protocol basics and the virtual MAC.
• Part XL-02 (XL-VyOS-VRRP / priority and skew) covers the priority field that is encoded in the advertisement.
• Part XI-06 (XI-VyOS-IPv6 / IPv6 troubleshoot) covers the IPv6 multicast address (ff02::12) used for VRRP in IPv6 deployments.

Quiz