组播地址与 TTL 校验
VRRP 通告报文以组播方式发送，IPv4 使用 224.0.0.18，IPv6 使用 FF02::12，IP 协议号固定为 112，TTL 固定为 255。接收端会校验 TTL：只有值为 255 的报文才被接受，因为任何正常的三层转发都会让 TTL 减 1，这个规则把伪造通告和跨网段通告直接挡在门外。因此 VRRP 天然只能在同一二层域内运行，跨网段无法用 VRRP 打通。
基本信息
| IPv4 组播 | 224.0.0.18 |
|---|---|
| IPv6 组播 | FF02::12 |
| IP 协议号 | 112 |
| TTL | 255，接收端强制校验 |
| 封装 | VRRPv2 直接封装在 IP 之上，不使用 TCP/UDP |
| 运行范围 | 仅限同一二层域 |
报文要点读法
| 要素 | 取值 | 作用 | 异常表现 |
|---|---|---|---|
| 组播地址 | 224.0.0.18 | 标识 VRRP 协议报文 | 被过滤时双方收不到通告 |
| 协议号 | 112 | ACL 放行与抓包过滤的依据 | 被拦截会造成长期双主 |
| TTL | 255 | 防止跨三层伪造与转发 | 经三层转发的报文会被丢弃 |
| 源地址 | 接口实地址 | 接收方据此判断发送者身份 | 源地址异常说明有设备伪造通告 |
| 发送周期 | 通告间隔，缺省 1 秒 | 维持主备状态同步 | 周期抖动会引发误切换 |
抓包过滤
抓包过滤
# Wireshark 显示过滤
vrrp # IPv4 与 IPv6 的 VRRP 报文
ip.src == 10.1.10.2 # 只看某台设备的通告来源
# tcpdump 命令行
sudo tcpdump -i eth0 vrrp # 抓取 VRRP 报文
sudo tcpdump -i eth0 'ip proto 112' # 按协议号 112 过滤
sudo tcpdump -i eth0 -c 20 vrrp # 取 20 个样本观察发送周期典型使用场景
- 验证主备关系：在镜像口抓包，确认只有 Master 在周期性发送通告
- 排查双主：确认两端是否都能收到对方的通告，单向可达问题一目了然
- 检查下发间隔：对照通告周期是否稳定，抖动明显时说明链路或设备负载异常
- 核对 ACL 放行：确认安全设备是否放行了协议号 112 与组播地址
- 审计伪造风险：抓包看是否存在源地址不在规划内的 VRRP 通告
中间设备放行不完整时，两端互相收不到通告，现象是长时间双主：网关地址在两个设备上同时存在，终端行为随机。检查 ACL、防火墙与安全策略是否放行协议号 112 与组播地址 224.0.0.18，并确认 VRRP 报文没有被三层设备跨网段转发。
经过三层设备转发过来的 VRRP 报文会因 TTL 校验被丢弃，这是协议设计而不是故障。反过来说，如果抓到跨网段来的 VRRP 报文，说明它已经被丢弃，不要试图用这种方式扩展 VRRP 的作用范围。