项目标题给了VRRP6 配完之后 ping 不通虚拟网关这一句话正文、关键词、摘要全是空的。这种标题放在网络运维的语境里基本可以断定是个真实踩坑现场协议起来了状态也显示 Master但下游主机把默认网关填成那个虚拟 IPv6 地址之后就是不通。我这些年处理过太多次同类问题最难的地方不是没有工具而是看起来一切正常假象太多——display vrrp ipv6显示 Master、虚拟地址也是 Up可主机侧ping6就是超时。下面把我自己的一套拆解逻辑和排查链路完整写出来涉及 VRRP6 的虚拟 MAC、虚拟链路本地地址、NDP 应答、回程路由、双 Master 这些关键点适合已经能配出 VRRP6 但卡在验证不通这一步的同行对着现场一步步走。1. 先搞清楚 IPv6 里的虚拟网关是由三个身份拼出来的很多人栽在第一步把 IPv4 的直觉直接搬到 IPv6 上。IPv4 里 VRRP 虚拟地址就是一个 IP主机 ARP 一下、设备回个 MAC通了。IPv6 里这套东西被拆成了三个互相绑定的身份任何一个对不上ping 就不通而状态显示依然是 Master。1.1 虚拟MAC、虚拟链路本地地址、虚拟全球地址缺一不可一个 VRID 对应的虚拟路由器在 IPv6 世界里至少有这样三样东西虚拟 MAC固定规则00-00-5E-00-01-{VRID}VRID 是 1 到 255 的十六进制。VRID1 时就是00-00-5E-00-01-01。这个 MAC 由协议强制规定不能自己改。虚拟链路本地地址由上面那个虚拟 MAC 经 EUI-64 推导出来的fe80::地址VRID1 时是fe80::200:5eff:fe00:0101。它承担了 IPv6 里这个虚拟路由器在链路上是谁的角色VRRP6 的邻居发现、NDP 应答全靠它。虚拟全球单播地址也就是你手工配在 VRRP 组里的那个业务网关地址比如2001:db8:10::1。主机默认网关填的是它。主机要 ping 通2001:db8:10::1完整过程是主机先发 NS 请求解析2001:db8:10::1的链路层地址 → 持有该虚拟地址的 Master 必须用虚拟 MAC回应 NA → 主机把报文发到虚拟 MAC → Master 的转发面把虚拟 MAC 和虚拟地址关联起来收包、回 ICMPv6 Echo Reply。这条链上任何一环断了现象都是ping 不通但故障点完全不同。我见过最典型的误判是只看了虚拟全球地址在不在没看虚拟链路本地地址是不是符合推导规则。地址确实配上了协议也确实在跑但 ND 应答环节设备内部对不上号报文进了转发面找不到归属。1.2 fe80 开头的虚拟地址为什么必须绑接口才 ping 得动这条在 IPv6 里是硬规则不是设备实现问题。链路本地地址不携带路由信息同一台设备上多个接口的fe80::地址可能完全一样所以协议栈必须靠出接口才能确定下一跳。你在设备上直接敲ping ipv6 fe80::200:5eff:fe00:0101大概率直接报需要指定出接口或者干脆没有应答这属于正常行为不是故障。正确写法是带接口ping ipv6 fe80::200:5eff:fe00:0101 -i Vlanif100不同平台语法略有差异有的用-i有的用%后缀拼接比如ping6 fe80::200:5eff:fe00:0101%eth0。这一点一定要在排查开始时先确认清楚否则你会把一个命令用法问题当成设备故障查上半天。我早期就干过这事从一台路由器上 ping 对端 VRRP 组的虚拟链路本地地址怎么都不通后来发现只是没指定接口加上-i立刻通。而对于主机侧主机 ping 默认网关那个fe80::虚拟地址时源地址选择也有讲究。主机的默认网关一般建议填虚拟全球地址而不是虚拟链路本地地址后者要求每台主机都明确知道出接口跨平台行为不一致Windows、Linux、各类嵌入式系统的处理方式都有差别运维成本高。1.3 状态显示 Master 只说明协议跑起来了不说明转发通了这是 IPv6 场景下最容易骗人的地方。VRRP6 的状态机由 Advertisement 报文驱动只要收到的通告符合规则、优先级比较通过设备就会进入 Master 状态并把虚拟地址置为可用。但协议状态为 Master和转发面正确把虚拟地址绑定到虚拟 MAC是两件事中间隔着控制面到转发面的下发过程有时候还有 NDP 代理开关、ICMP 响应策略、ACL 这些额外关卡。判断方法很直接看主机侧的邻居表有没有学到虚拟地址对应的虚拟 MAC。学到了说明 ND 这一层是通的问题在后面学不到说明 Master 根本没应答 NS。Linux 上用ip -6 neigh show dev eth0Windows 上用netsh interface ipv6 show neighbors如果邻居表里2001:db8:10::1对应的 MAC 是00-00-5e-00-01-01说明 ND 正常如果显示INCOMPLETE或者干脆没有这条说明 NS 没人应答或应答被丢。这个分叉点能把排查范围砍掉一半建议每次开工先做这一步。2. 虚拟链路本地地址与虚拟MAC不匹配是最常见的一处暗坑我处理过的 VRRP6 不通案例里占比最高的一类就是虚拟链路本地地址被人为改掉。改的人往往出于好意fe80::200:5eff:fe00:0101这种地址太难记改成fe80::1多清爽。IPv4 时代虚拟地址可以随便起IPv6 时代这个直觉会直接把你带沟里。2.1 EUI-64 推导过程拆开看以 VRID1 为例虚拟 MAC 是00-00-5E-00-01-01推导链路本地地址的步骤是步骤操作结果1取 48 位虚拟 MAC00-00-5E-00-01-012中间插入FF-FE00-00-5E-FF-FE-00-01-013翻转第一个字节的 U/L 位第 7 位取值 0x0202-00-5E-FF-FE-00-01-014按 16 位分组前面补fe80::fe80::200:5eff:fe00:0101第三种的翻转之所以是02是因为0x00的二进制是0000 0000第 7 位从 0 开始数也就是次低位的那个本地/全局标志位置 1 后变成0000 0010即0x02。VRID2 时虚拟 MAC 末字节是02推导结果就是fe80::200:5eff:fe00:0102VRID255 则是fe80::200:5eff:fe00:01ff。所以这个地址是能算出来的不需要背。RFC 5798 里对虚拟链路本地地址的定义是由虚拟 MAC 经 EUI-64 生成同时也允许实现支持手工指定一个非派生的地址。问题就出在这个允许上——支持归支持但不同平台对这种非派生地址的处理策略差异极大有的能正常工作有的会在 ND 应答、源地址校验、回程路由上出各种怪问题。2.2 手工改成好记地址后现场会发生什么我见过的一个现场是这样的两台核心设备做 VRRP6 主备虚拟全球地址2001:db8:10::1虚拟链路本地地址被人改成了fe80::10:1。协议状态正常主备切换也正常主机侧邻居表能解析到虚拟 MAC但 ping 就是不通。排查过程如下主机侧抓包能看到 NS 发出、NA 回来Target 是2001:db8:10::1NA 的源 MAC 是虚拟 MAC看起来完全正常Master 侧抓包能看到 ICMPv6 Echo Request 到达但没有 Echo Reply 发出。也就是说请求进了设备回复没出来。问题定位在转发面对虚拟地址的归属判断上。该平台内部维护地址 → 虚拟 MAC的绑定表这个表的索引键部分依赖虚拟链路本地地址的推导关系。地址被改成非派生值之后绑定表里出现了一条孤儿条目报文进来了但匹配不到正确的出口逻辑于是被静默丢弃日志里什么都没有。改回fe80::200:5eff:fe00:0101立刻通。这条经验我总结成一句话除非你确切知道目标平台怎么处理非派生虚拟链路本地地址否则不要碰它用默认推导出来的那个。它的可读性差一点但它和虚拟 MAC 是配套的改一个不改另一个就是在给自己埋雷。2.3 不同实现对非派生虚拟地址的容忍度对比我手上接触过几类平台的实测情况简单列一下具体行为随版本变化仅供参考平台类型非派生虚拟链路本地地址现象主流企业级路由器 A 平台配置可下发协议可收敛主机 ping 虚拟全球地址不通转发面丢弃主流企业级交换机 B 平台配置时报错要求符合 EUI-64无法配成非派生值反而最安全虚拟化环境软路由 C支持但需额外开 NDP 代理不开代理则 NS 无人应答部分嵌入式/轻量实现忽略该配置强制用派生值配置看起来生效了实际用的是派生值这张表的意义在于不要拿一个平台的经验去套另一个平台。我在 A 平台上踩过的坑在 B 平台上根本复现不了因为 B 直接在配置阶段就把路堵死了反过来B 平台的安全也意味着你在它上面永远遇不到这个故障于是就没有排查经验换到 A 平台立刻懵。一个更稳妥的验证方法不要去猜平台行为直接看主机侧学到的 MAC 和设备侧转发面是否一致。主机侧邻居表里虚拟地址对应的 MAC 是虚拟 MAC设备侧抓包看到 Echo Request 进来但没有 Reply 出去就基本能锁定地址归属绑定不上这一类问题。3. 协议层没真正收敛的几种伪装第二大类故障是协议本身没跑对但状态显示让你以为跑对了。VRRP6 的状态判断依赖 Advertisement 报文只要报文在某些条件下被接受或被误接受状态机就会给出误导性的结果。3.1 双 Master从 MAC 表震荡倒推双 Master 是经典问题IPv4 时代就常见IPv6 时代因为多了层 MAC 映射症状更隐蔽。成因通常是两端 VRID 不一致、虚拟地址配置不一致、认证参数不匹配、组播报文被单向丢弃、链路中间有二层设备做过滤。表现是两台设备都认为自己是 Master都对外宣告虚拟 MAC。从主机侧看最直观的症状是时通时不通因为交换机 MAC 地址表在两个端口之间反复学习同一个虚拟 MAC流量来回切换。看交换机的 MAC 表show mac address-table address 0000.5e00.0101如果这个 MAC 在两个不同端口之间切换或者干脆看到两条记录那基本可以确认双 Master。另一种情况是端口安全Port Security限制了单端口可学的 MAC 数量虚拟 MAC 作为第 N1 个 MAC被直接丢弃主机侧就表现为完全不通而且抓包能看到 NA 发出但回程没有。排查双 Master 的关键是抓 Advertisement 报文。VRRP6 的通告目的地址是ff02::12源地址是发送接口的链路本地地址注意不是虚拟地址Hop Limit 必须是 255。抓包过滤tcpdump -i eth0 -nn icmp6 and ip6[40] 112112 是 VRRP 的 ICMPv6 类型号。正常情况下应该只看到一个源在持续发包如果看到两个源交替发且各自都宣告同一个 VRID那就是双 Master。同时配合看优先级字段谁的优先级高谁应该赢赢不了说明报文没被对方接受。3.2 Hop Limit 与版本号这两个硬门槛VRRP 报文有个强制规则Hop LimitIPv4 里是 TTL必须为 255收到不为 255 的直接丢弃不产生任何日志。这条规则的目的是防止报文被路由穿透保证协议只在本链路生效。问题在于某些虚拟化环境、容器网络、隧道封装会把 Hop Limit 减一或者中间的二层设备做了奇怪的改写。结果就是两端互相收不到对方的通告各自成为 Master而从配置上看一切正常。这种场景在物理网络里少见在叠加了虚拟交换、overlay 的环境里相对多一些。判断方法还是抓包看收到的 VRRP 报文的 Hop Limit 字段tcpdump -i eth0 -nn -v icmp6 and ip6[40] 112输出里hlim应该显示 255。如果显示 254 或更小报文会被协议栈直接丢弃表现就是对端设备明明在发包我这边却收不到。这个坑我吃过一次在一套叠加了隧道封装的测试环境里查了两天才发现是封装层减了 Hop Limit。版本号问题是另一回事。VRRP 有 v2 和 v3 两个版本IPv6 只支持 v3。有些平台的配置命令里vrrp和vrrp ipv6是两套独立配置如果只在 IPv4 那边配了vrrp vridIPv6 那边没有单独配那么 IPv6 的 VRRP 根本没启动但接口上可能因为其他配置显示了个虚拟地址容易误判。配置完一定要用专门的 IPv6 查询命令确认show vrrp ipv6 detail确认输出里能看到 VRID、状态、虚拟地址列表、优先级、通告间隔这些字段而不是只看接口的 IPv6 地址列表。3.3 优先级、抢占延迟和 Track 联动优先级配置错了导致的不通其实很少见因为优先级只影响主备选举不影响单台设备能否响应。但如果配置了抢占延迟和 Track 联动会出现另一类问题上行链路故障后优先级下降本该切主但因为抢占被关闭或延迟太长一直没切结果虚拟地址还挂在一条已经不通的路径上。排查时关注三点抢占preempt是否开启默认在很多平台上是不开启的需要显式配置。抢占延迟是否设得过长切换窗口内业务中断时间会被拉长。Track 跟踪的对象是否正确跟的是上行接口的物理状态还是路由可达性。配置示例语法示意各平台不同vrrp ipv6 vrid 1 preempt-mode timer delay 10 vrrp ipv6 vrid 1 track interface GigabitEthernet0/0/1 reduced 30reduced 30表示跟踪对象失效时优先级减 30。如果原优先级是 120减完变成 90低于备机的 100就会触发切换。这里有个容易忽略的点减完之后必须仍然高于备机优先级才能完成切换如果减太多导致低于备机还行但如果两台设备优先级设置相同减完可能还是相等那就永远切不过去。3.4 抓包只盯三个字段就够定位大半问题我不建议一上来就全量抓包分析信息太多反而干扰判断。VRRP6 抓包只需要盯三样源地址和目的地址目的必须是ff02::12源应该是接口链路本地地址。如果看到源是虚拟地址说明实现不标准或者配置有误。Hop Limit必须是 255否则被丢弃。优先级和 VRID同一 VRID 下应该只有一个源在持续宣告优先级高的是 Master。把这三样确认完协议层的问题基本能排掉八成。剩下的两成交给 NDP 和路由层去查。4. NDP 环节地址还在但没人应答 NS协议层没问题、状态也正常主机就是不通这时候重点转向 NDP。IPv6 的地址解析靠 NS/NA 完成虚拟地址的 NS 应答责任归属是个容易出错的环节。4.1 虚拟地址的 NS 到底该由谁来回答按 RFC 的定义虚拟地址不属于任何一个物理接口它属于虚拟路由器。所以应答 NS 时NA 报文必须满足源 MAC 是虚拟 MAC不是物理接口 MAC。Target Address 是虚拟地址本身。目的地址是发起 NS 的主机的链路本地地址或 solicited-node 组播地址。标志位里 Solicited 位和 Override 位按规范设置。大多数企业级平台会自动处理这些但有些平台需要显式开启 NDP 代理或者虚拟地址应答功能。配置项名称五花八门常见的有nd proxy、vrrp ipv6 nd respond、ipv6 nd proxy之类。如果你在虚拟化软路由或者开源的软实现上做 VRRP6这一项几乎是必查项。有个细节值得注意有些实现默认会应答但应答时用的源 MAC 是物理接口 MAC 而非虚拟 MAC。这种情况下主机的邻居表里虚拟地址对应的是物理 MAC报文会发到物理 MAC 上Master 也能收到并回复表面上能通。但一旦发生主备切换新 Master 的物理 MAC 不一样主机的邻居缓存还指向旧 MAC就会中断直到缓存老化。这种能通但有隐患的配置比彻底不通更难查。验证方法主机侧看邻居表虚拟地址对应的 MAC 是不是00-00-5e-00-01-{VRID}。如果不是说明应答用了物理 MAC需要修正配置。4.2 RA 与 DHCPv6 抢走主机默认网关主机侧的问题经常被忽略。IPv6 里主机获取默认网关的途径不止一条静态配置、RA 通告、DHCPv6。如果网络里同时有 RA 通告了别的默认网关主机的路由表里可能会有多条默认路由选择哪一条取决于优先级和度量值。Linux 上查看ip -6 route show default如果看到多条 default 路由且其中一条指向的不是虚拟网关那 ping 不通虚拟网关就很正常了——主机根本没往那边发。Windows 上用netsh interface ipv6 show routeRA 的 M 标志和 O 标志也会影响主机行为。M1 表示用 DHCPv6 获取地址O1 表示用 DHCPv6 获取其他配置包括 DNS有些实现里还包括网关。如果网络里既有 VRRP6 的虚拟网关又有另一台设备在发 RA 通告主机可能优先采用了 RA 里的网关。这种情况的处理方式是明确网络里的 RA 发放策略要么只让 VRRP6 的 Master 发 RA要么统一由核心设备发避免多个源同时通告。RA 的抑制在 VRRP6 里通常有对应配置Backup 设备不应该发 RA。4.3 ping 不通有时是回程路由没写对最后一种情况请求到了回复出不去。这在跨网段 ping 虚拟网关时特别常见。主机 A 在网段 X虚拟网关在网段 Y 的设备上A ping 虚拟地址请求能到因为 A 的默认路由指向虚拟网关但回复需要设备知道怎么回到 A 所在的网段。如果回程路由缺失或者指错了接口Echo Reply 就发不出去。判断方法在 Master 设备上抓包看是否有 Echo Request 进入、是否有 Echo Reply 生成。如果只有 Request 没有 Reply查路由表show ipv6 route 2001:db8:aa::/64确认回程路由的出接口和下一跳正确。另一个常见的坑是源地址选择错误设备回复时选的源地址如果不是虚拟地址而是某个物理接口地址主机侧会因为回复源地址与请求目的地址不一致而丢弃严格模式下表现也是不通。抓包能看到 Reply 发出了但源地址不对。5. 一次完整的现场排查链路复盘上面讲的是分类实际现场是按顺序走的。我把自己的排查顺序整理成一条链路从主机侧一路往上收每一步都有明确的判断依据。5.1 从主机侧确认报文出门第一步永远在主机上做不要一上来就登设备。主机侧要确认三件事默认网关是不是虚拟地址有没有被别的路由覆盖。邻居表里虚拟地址解析到了什么 MAC。ping 的时候报文有没有真的发出去。Linux 上一条命令搞定邻居表ip -6 neigh show | grep 2001:db8:10::1如果显示INCOMPLETE说明 NS 发出去了但没有 NA 回来问题在设备侧大概率是 NDP 应答或虚拟地址归属。如果显示了一个 MAC 且是虚拟 MAC说明 ND 层通了问题在转发或回程。如果显示的是物理 MAC说明设备用物理 MAC 应答了能通但有切换隐患。再配合抓包确认报文出门tcpdump -i eth0 -nn icmp6 and ip6 host 2001:db8:10::1能看到 Echo Request 发出、没有 Echo Reply 回来就可以确定问题不在主机侧的应用层或防火墙。5.2 到 Master 上看三层与二层的落点第二步登 Master 设备按三层到二层的顺序看检查项命令示意期望结果VRRP6 状态show vrrp ipv6 detail本机为 Master虚拟地址列表正确虚拟地址可达性show ipv6 interface brief虚拟地址出现在接口地址列表中邻居表show ipv6 neighbors能看到主机的链路本地地址和 MAC接口统计show interface counters入方向无丢弃出方向无队列溢出ACL 命中show ipv6 acl counters无隐式拒绝命中这里有个细节虚拟地址在有些平台上不会显示在接口的地址列表里而是单独在 VRRP 状态里体现。所以接口地址列表里看不到虚拟地址不等于故障要看 VRRP 状态输出里的虚拟地址字段。如果 Master 侧抓包能看到 Echo Request 进来但没有 Echo Reply 出去且接口统计没有丢弃那问题多半在转发面对虚拟地址的处理上回到第 2 节去查虚拟链路本地地址和虚拟 MAC 的绑定关系。5.3 回程与切换瞬间的验证第三步验证回程。在 Master 上直接 ping 主机ping ipv6 2001:db8:aa::100能通说明回程路由没问题。不通就查路由表和源地址选择。第四步验证切换。手动把 Master 的 VRRP 关掉或者降优先级观察主机侧的表现邻居表里的虚拟 MAC 有没有变不应该变虚拟 MAC 是固定的。切换过程中丢几个包。切换后多久恢复。正常情况下切换丢包在 1 到 3 个通告周期内如果配了快速通告可以更短。如果切换后完全不恢复说明新 Master 没有正确接管虚拟地址或者没有发出免费 NA 刷新主机的邻居缓存。免费 NA 的作用是主动告诉链路上的所有主机这个虚拟地址现在在我这里MAC 是虚拟 MAC避免主机继续用旧缓存。有些平台需要在 VRRP 配置里显式开启免费 NA 或者快速通告vrrp ipv6 vrid 1 timer advertise 100 vrrp ipv6 vrid 1 gratuitous-nd enable具体命令名称各平台差异很大建议查对应版本的配置手册确认。这一项不开切换后主机侧可能长时间不通直到邻居缓存老化默认几十分钟现场表现就是切换失败了其实协议是切成功的。5.4 排查顺序速查表把上面几步压缩成一张表现场可以直接照着走顺序检查位置判断依据指向问题1主机默认路由是否只有一条指向虚拟网关多网关抢路由2主机邻居表虚拟地址对应的 MAC无记录→NDP物理MAC→应答方式3主机抓包是否有 Echo Reply无→设备侧有但不通→源地址或防火墙4Master VRRP 状态是否 Master、虚拟地址是否正确状态错→协议层5Master 抓包VRRP 通告 Hop Limit 与源非 255→被丢弃多源→双 Master6Master 转发面Echo Request 入、Reply 出入不出→虚拟地址归属7路由表回程路由与源地址缺路由→回程不通8切换测试丢包数量与恢复时间不恢复→免费 NA 未发这张表的顺序是从便宜到贵主机侧的命令最轻量设备侧的抓包最重按这个顺序走能最快收敛范围。6. 几个不值得花时间但很容易被带偏的方向排查过程中有些方向看着可疑实际上大概率不是根因浪费时间。我把这几个列出来遇到时可以先跳过。6.1 双栈防火墙与 ACL 的默认动作IPv6 的 ACL 默认动作在不同平台上不一样有的默认放行有的默认拒绝。如果设备上配了 IPv6 ACL 但没放行 ICMPv6Echo Request 会被静默丢弃表现和虚拟地址不通一模一样。但这里有个反直觉的点ICMPv6 在 IPv6 里的地位比 ICMP 在 IPv4 里重要得多ND、PMTU 发现、RA 全靠它。所以大多数平台的 IPv6 ACL 会对必要的 ICMPv6 类型做隐式放行比如 NS/NA、RA、Packet Too Big。Echo Request 不在隐式放行列表里所以如果 ACL 是默认拒绝ping 不通但业务正常是常见现象。判断方法很简单看 ACL 的命中计数。如果 Echo Request 对应的规则命中数在增长说明被 ACL 挡了。如果没有命中计数说明报文根本没走到 ACL 这一层问题在前面。我的经验是如果业务流量正常、只有 ping 不通先怀疑 ICMP 响应策略而不是 ACL。很多设备对虚拟地址默认不响应 ping需要单独开启。这个设计意图是减少攻击面但对排障很不友好因为状态显示一切正常。6.2 虚拟地址与物理地址撞车虚拟地址不能和任何一台成员设备的物理接口地址相同。如果撞了有的平台配置阶段就报错有的平台允许配但运行时行为异常DAD 检测到地址冲突虚拟地址被标记为 tentative 或者直接不可用。另一种撞车是虚拟地址和网络里其他设备的地址相同比如某台服务器手工配了2001:db8:10::1。这种情况下主机会收到两个 NA邻居表里同一个地址对应两个 MAC来回切换表现是时通时不通。排查方法在主机侧连续多次查看邻居表看同一个虚拟地址的 MAC 有没有变化。如果有变化说明链路上有地址冲突用 DAD 或者扫描工具找出来。ip -6 neigh show | grep 2001:db8:10::1连续执行几次MAC 稳定不变才是正常的。6.3 切换瞬间丢几个包属于正常现象最后一条是心态问题。VRRP 的切换不是零丢包的通告间隔、抢占延迟、免费 NA 的传播都需要时间。默认通告间隔 1 秒的情况下切换丢 1 到 3 个包是正常的。如果业务对丢包极度敏感需要做的是调小通告间隔、开启快速通告、优化抢占延迟而不是追求零丢包。但要注意区分短暂丢包和长时间不通。切换后 5 秒内恢复属于正常超过 30 秒还不恢复就要查免费 NA 和邻居缓存了。我在现场见过一次切换后 20 分钟才恢复的案例最后发现是主机侧的邻居缓存老化时间被调得特别长而且 Master 没发免费 NA主机一直往旧 MAC 发包直到缓存过期。调小通告间隔的代价是协议报文变多链路上每秒都有组播包对低带宽链路和大量 VRRP 组的场景要权衡。一般业务网段用默认 1 秒就够金融交易这类场景可以调小到几百毫秒但需要先确认设备支持的最小值。我个人在这些年折腾 VRRP6 的体会是这类问题的难点从来不在技术深度而在现象和原因之间的距离太远。IPv4 时代 ping 不通虚拟网关查 ARP、查状态、查路由三步基本能定位IPv6 时代中间多了虚拟 MAC、虚拟链路本地地址、NDP 应答、免费 NA 这几层任何一层出问题表面现象都是同一句ping 不通。所以我现在养成了一个习惯不管现场多急先花两分钟在主机侧看邻居表学到的 MAC 对不对这一步做完后面该往哪个方向查基本就清楚了。另外配置 VRRP6 的时候虚拟链路本地地址一律用默认推导值不去改它能省掉后面一大半的麻烦。真遇到改过这个地址的存量配置我的建议是趁着维护窗口改回默认值别指望它一直能用——它现在能跑只是还没到出问题的时候。 
长河君 · 2026/10/27 4:25:56 · 阅读 1.2k VRRP6虚拟网关ping不通：虚拟MAC、NDP与双Master排查
项目标题给了VRRP6 配完之后 ping 不通虚拟网关这一句话正文、关键词、摘要全是空的。这种标题放在网络运维的语境里基本可以断定是个真实踩坑现场协议起来了状态也显示 Master但下游主机把默认网关填成那个虚拟 IPv6 地址之后就是不通。我这些年处理过太多次同类问题最难的地方不是没有工具而是看起来一切正常假象太多——display vrrp ipv6显示 Master、虚拟地址也是 Up可主机侧ping6就是超时。下面把我自己的一套拆解逻辑和排查链路完整写出来涉及 VRRP6 的虚拟 MAC、虚拟链路本地地址、NDP 应答、回程路由、双 Master 这些关键点适合已经能配出 VRRP6 但卡在验证不通这一步的同行对着现场一步步走。1. 先搞清楚 IPv6 里的虚拟网关是由三个身份拼出来的很多人栽在第一步把 IPv4 的直觉直接搬到 IPv6 上。IPv4 里 VRRP 虚拟地址就是一个 IP主机 ARP 一下、设备回个 MAC通了。IPv6 里这套东西被拆成了三个互相绑定的身份任何一个对不上ping 就不通而状态显示依然是 Master。1.1 虚拟MAC、虚拟链路本地地址、虚拟全球地址缺一不可一个 VRID 对应的虚拟路由器在 IPv6 世界里至少有这样三样东西虚拟 MAC固定规则00-00-5E-00-01-{VRID}VRID 是 1 到 255 的十六进制。VRID1 时就是00-00-5E-00-01-01。这个 MAC 由协议强制规定不能自己改。虚拟链路本地地址由上面那个虚拟 MAC 经 EUI-64 推导出来的fe80::地址VRID1 时是fe80::200:5eff:fe00:0101。它承担了 IPv6 里这个虚拟路由器在链路上是谁的角色VRRP6 的邻居发现、NDP 应答全靠它。虚拟全球单播地址也就是你手工配在 VRRP 组里的那个业务网关地址比如2001:db8:10::1。主机默认网关填的是它。主机要 ping 通2001:db8:10::1完整过程是主机先发 NS 请求解析2001:db8:10::1的链路层地址 → 持有该虚拟地址的 Master 必须用虚拟 MAC回应 NA → 主机把报文发到虚拟 MAC → Master 的转发面把虚拟 MAC 和虚拟地址关联起来收包、回 ICMPv6 Echo Reply。这条链上任何一环断了现象都是ping 不通但故障点完全不同。我见过最典型的误判是只看了虚拟全球地址在不在没看虚拟链路本地地址是不是符合推导规则。地址确实配上了协议也确实在跑但 ND 应答环节设备内部对不上号报文进了转发面找不到归属。1.2 fe80 开头的虚拟地址为什么必须绑接口才 ping 得动这条在 IPv6 里是硬规则不是设备实现问题。链路本地地址不携带路由信息同一台设备上多个接口的fe80::地址可能完全一样所以协议栈必须靠出接口才能确定下一跳。你在设备上直接敲ping ipv6 fe80::200:5eff:fe00:0101大概率直接报需要指定出接口或者干脆没有应答这属于正常行为不是故障。正确写法是带接口ping ipv6 fe80::200:5eff:fe00:0101 -i Vlanif100不同平台语法略有差异有的用-i有的用%后缀拼接比如ping6 fe80::200:5eff:fe00:0101%eth0。这一点一定要在排查开始时先确认清楚否则你会把一个命令用法问题当成设备故障查上半天。我早期就干过这事从一台路由器上 ping 对端 VRRP 组的虚拟链路本地地址怎么都不通后来发现只是没指定接口加上-i立刻通。而对于主机侧主机 ping 默认网关那个fe80::虚拟地址时源地址选择也有讲究。主机的默认网关一般建议填虚拟全球地址而不是虚拟链路本地地址后者要求每台主机都明确知道出接口跨平台行为不一致Windows、Linux、各类嵌入式系统的处理方式都有差别运维成本高。1.3 状态显示 Master 只说明协议跑起来了不说明转发通了这是 IPv6 场景下最容易骗人的地方。VRRP6 的状态机由 Advertisement 报文驱动只要收到的通告符合规则、优先级比较通过设备就会进入 Master 状态并把虚拟地址置为可用。但协议状态为 Master和转发面正确把虚拟地址绑定到虚拟 MAC是两件事中间隔着控制面到转发面的下发过程有时候还有 NDP 代理开关、ICMP 响应策略、ACL 这些额外关卡。判断方法很直接看主机侧的邻居表有没有学到虚拟地址对应的虚拟 MAC。学到了说明 ND 这一层是通的问题在后面学不到说明 Master 根本没应答 NS。Linux 上用ip -6 neigh show dev eth0Windows 上用netsh interface ipv6 show neighbors如果邻居表里2001:db8:10::1对应的 MAC 是00-00-5e-00-01-01说明 ND 正常如果显示INCOMPLETE或者干脆没有这条说明 NS 没人应答或应答被丢。这个分叉点能把排查范围砍掉一半建议每次开工先做这一步。2. 虚拟链路本地地址与虚拟MAC不匹配是最常见的一处暗坑我处理过的 VRRP6 不通案例里占比最高的一类就是虚拟链路本地地址被人为改掉。改的人往往出于好意fe80::200:5eff:fe00:0101这种地址太难记改成fe80::1多清爽。IPv4 时代虚拟地址可以随便起IPv6 时代这个直觉会直接把你带沟里。2.1 EUI-64 推导过程拆开看以 VRID1 为例虚拟 MAC 是00-00-5E-00-01-01推导链路本地地址的步骤是步骤操作结果1取 48 位虚拟 MAC00-00-5E-00-01-012中间插入FF-FE00-00-5E-FF-FE-00-01-013翻转第一个字节的 U/L 位第 7 位取值 0x0202-00-5E-FF-FE-00-01-014按 16 位分组前面补fe80::fe80::200:5eff:fe00:0101第三种的翻转之所以是02是因为0x00的二进制是0000 0000第 7 位从 0 开始数也就是次低位的那个本地/全局标志位置 1 后变成0000 0010即0x02。VRID2 时虚拟 MAC 末字节是02推导结果就是fe80::200:5eff:fe00:0102VRID255 则是fe80::200:5eff:fe00:01ff。所以这个地址是能算出来的不需要背。RFC 5798 里对虚拟链路本地地址的定义是由虚拟 MAC 经 EUI-64 生成同时也允许实现支持手工指定一个非派生的地址。问题就出在这个允许上——支持归支持但不同平台对这种非派生地址的处理策略差异极大有的能正常工作有的会在 ND 应答、源地址校验、回程路由上出各种怪问题。2.2 手工改成好记地址后现场会发生什么我见过的一个现场是这样的两台核心设备做 VRRP6 主备虚拟全球地址2001:db8:10::1虚拟链路本地地址被人改成了fe80::10:1。协议状态正常主备切换也正常主机侧邻居表能解析到虚拟 MAC但 ping 就是不通。排查过程如下主机侧抓包能看到 NS 发出、NA 回来Target 是2001:db8:10::1NA 的源 MAC 是虚拟 MAC看起来完全正常Master 侧抓包能看到 ICMPv6 Echo Request 到达但没有 Echo Reply 发出。也就是说请求进了设备回复没出来。问题定位在转发面对虚拟地址的归属判断上。该平台内部维护地址 → 虚拟 MAC的绑定表这个表的索引键部分依赖虚拟链路本地地址的推导关系。地址被改成非派生值之后绑定表里出现了一条孤儿条目报文进来了但匹配不到正确的出口逻辑于是被静默丢弃日志里什么都没有。改回fe80::200:5eff:fe00:0101立刻通。这条经验我总结成一句话除非你确切知道目标平台怎么处理非派生虚拟链路本地地址否则不要碰它用默认推导出来的那个。它的可读性差一点但它和虚拟 MAC 是配套的改一个不改另一个就是在给自己埋雷。2.3 不同实现对非派生虚拟地址的容忍度对比我手上接触过几类平台的实测情况简单列一下具体行为随版本变化仅供参考平台类型非派生虚拟链路本地地址现象主流企业级路由器 A 平台配置可下发协议可收敛主机 ping 虚拟全球地址不通转发面丢弃主流企业级交换机 B 平台配置时报错要求符合 EUI-64无法配成非派生值反而最安全虚拟化环境软路由 C支持但需额外开 NDP 代理不开代理则 NS 无人应答部分嵌入式/轻量实现忽略该配置强制用派生值配置看起来生效了实际用的是派生值这张表的意义在于不要拿一个平台的经验去套另一个平台。我在 A 平台上踩过的坑在 B 平台上根本复现不了因为 B 直接在配置阶段就把路堵死了反过来B 平台的安全也意味着你在它上面永远遇不到这个故障于是就没有排查经验换到 A 平台立刻懵。一个更稳妥的验证方法不要去猜平台行为直接看主机侧学到的 MAC 和设备侧转发面是否一致。主机侧邻居表里虚拟地址对应的 MAC 是虚拟 MAC设备侧抓包看到 Echo Request 进来但没有 Reply 出去就基本能锁定地址归属绑定不上这一类问题。3. 协议层没真正收敛的几种伪装第二大类故障是协议本身没跑对但状态显示让你以为跑对了。VRRP6 的状态判断依赖 Advertisement 报文只要报文在某些条件下被接受或被误接受状态机就会给出误导性的结果。3.1 双 Master从 MAC 表震荡倒推双 Master 是经典问题IPv4 时代就常见IPv6 时代因为多了层 MAC 映射症状更隐蔽。成因通常是两端 VRID 不一致、虚拟地址配置不一致、认证参数不匹配、组播报文被单向丢弃、链路中间有二层设备做过滤。表现是两台设备都认为自己是 Master都对外宣告虚拟 MAC。从主机侧看最直观的症状是时通时不通因为交换机 MAC 地址表在两个端口之间反复学习同一个虚拟 MAC流量来回切换。看交换机的 MAC 表show mac address-table address 0000.5e00.0101如果这个 MAC 在两个不同端口之间切换或者干脆看到两条记录那基本可以确认双 Master。另一种情况是端口安全Port Security限制了单端口可学的 MAC 数量虚拟 MAC 作为第 N1 个 MAC被直接丢弃主机侧就表现为完全不通而且抓包能看到 NA 发出但回程没有。排查双 Master 的关键是抓 Advertisement 报文。VRRP6 的通告目的地址是ff02::12源地址是发送接口的链路本地地址注意不是虚拟地址Hop Limit 必须是 255。抓包过滤tcpdump -i eth0 -nn icmp6 and ip6[40] 112112 是 VRRP 的 ICMPv6 类型号。正常情况下应该只看到一个源在持续发包如果看到两个源交替发且各自都宣告同一个 VRID那就是双 Master。同时配合看优先级字段谁的优先级高谁应该赢赢不了说明报文没被对方接受。3.2 Hop Limit 与版本号这两个硬门槛VRRP 报文有个强制规则Hop LimitIPv4 里是 TTL必须为 255收到不为 255 的直接丢弃不产生任何日志。这条规则的目的是防止报文被路由穿透保证协议只在本链路生效。问题在于某些虚拟化环境、容器网络、隧道封装会把 Hop Limit 减一或者中间的二层设备做了奇怪的改写。结果就是两端互相收不到对方的通告各自成为 Master而从配置上看一切正常。这种场景在物理网络里少见在叠加了虚拟交换、overlay 的环境里相对多一些。判断方法还是抓包看收到的 VRRP 报文的 Hop Limit 字段tcpdump -i eth0 -nn -v icmp6 and ip6[40] 112输出里hlim应该显示 255。如果显示 254 或更小报文会被协议栈直接丢弃表现就是对端设备明明在发包我这边却收不到。这个坑我吃过一次在一套叠加了隧道封装的测试环境里查了两天才发现是封装层减了 Hop Limit。版本号问题是另一回事。VRRP 有 v2 和 v3 两个版本IPv6 只支持 v3。有些平台的配置命令里vrrp和vrrp ipv6是两套独立配置如果只在 IPv4 那边配了vrrp vridIPv6 那边没有单独配那么 IPv6 的 VRRP 根本没启动但接口上可能因为其他配置显示了个虚拟地址容易误判。配置完一定要用专门的 IPv6 查询命令确认show vrrp ipv6 detail确认输出里能看到 VRID、状态、虚拟地址列表、优先级、通告间隔这些字段而不是只看接口的 IPv6 地址列表。3.3 优先级、抢占延迟和 Track 联动优先级配置错了导致的不通其实很少见因为优先级只影响主备选举不影响单台设备能否响应。但如果配置了抢占延迟和 Track 联动会出现另一类问题上行链路故障后优先级下降本该切主但因为抢占被关闭或延迟太长一直没切结果虚拟地址还挂在一条已经不通的路径上。排查时关注三点抢占preempt是否开启默认在很多平台上是不开启的需要显式配置。抢占延迟是否设得过长切换窗口内业务中断时间会被拉长。Track 跟踪的对象是否正确跟的是上行接口的物理状态还是路由可达性。配置示例语法示意各平台不同vrrp ipv6 vrid 1 preempt-mode timer delay 10 vrrp ipv6 vrid 1 track interface GigabitEthernet0/0/1 reduced 30reduced 30表示跟踪对象失效时优先级减 30。如果原优先级是 120减完变成 90低于备机的 100就会触发切换。这里有个容易忽略的点减完之后必须仍然高于备机优先级才能完成切换如果减太多导致低于备机还行但如果两台设备优先级设置相同减完可能还是相等那就永远切不过去。3.4 抓包只盯三个字段就够定位大半问题我不建议一上来就全量抓包分析信息太多反而干扰判断。VRRP6 抓包只需要盯三样源地址和目的地址目的必须是ff02::12源应该是接口链路本地地址。如果看到源是虚拟地址说明实现不标准或者配置有误。Hop Limit必须是 255否则被丢弃。优先级和 VRID同一 VRID 下应该只有一个源在持续宣告优先级高的是 Master。把这三样确认完协议层的问题基本能排掉八成。剩下的两成交给 NDP 和路由层去查。4. NDP 环节地址还在但没人应答 NS协议层没问题、状态也正常主机就是不通这时候重点转向 NDP。IPv6 的地址解析靠 NS/NA 完成虚拟地址的 NS 应答责任归属是个容易出错的环节。4.1 虚拟地址的 NS 到底该由谁来回答按 RFC 的定义虚拟地址不属于任何一个物理接口它属于虚拟路由器。所以应答 NS 时NA 报文必须满足源 MAC 是虚拟 MAC不是物理接口 MAC。Target Address 是虚拟地址本身。目的地址是发起 NS 的主机的链路本地地址或 solicited-node 组播地址。标志位里 Solicited 位和 Override 位按规范设置。大多数企业级平台会自动处理这些但有些平台需要显式开启 NDP 代理或者虚拟地址应答功能。配置项名称五花八门常见的有nd proxy、vrrp ipv6 nd respond、ipv6 nd proxy之类。如果你在虚拟化软路由或者开源的软实现上做 VRRP6这一项几乎是必查项。有个细节值得注意有些实现默认会应答但应答时用的源 MAC 是物理接口 MAC 而非虚拟 MAC。这种情况下主机的邻居表里虚拟地址对应的是物理 MAC报文会发到物理 MAC 上Master 也能收到并回复表面上能通。但一旦发生主备切换新 Master 的物理 MAC 不一样主机的邻居缓存还指向旧 MAC就会中断直到缓存老化。这种能通但有隐患的配置比彻底不通更难查。验证方法主机侧看邻居表虚拟地址对应的 MAC 是不是00-00-5e-00-01-{VRID}。如果不是说明应答用了物理 MAC需要修正配置。4.2 RA 与 DHCPv6 抢走主机默认网关主机侧的问题经常被忽略。IPv6 里主机获取默认网关的途径不止一条静态配置、RA 通告、DHCPv6。如果网络里同时有 RA 通告了别的默认网关主机的路由表里可能会有多条默认路由选择哪一条取决于优先级和度量值。Linux 上查看ip -6 route show default如果看到多条 default 路由且其中一条指向的不是虚拟网关那 ping 不通虚拟网关就很正常了——主机根本没往那边发。Windows 上用netsh interface ipv6 show routeRA 的 M 标志和 O 标志也会影响主机行为。M1 表示用 DHCPv6 获取地址O1 表示用 DHCPv6 获取其他配置包括 DNS有些实现里还包括网关。如果网络里既有 VRRP6 的虚拟网关又有另一台设备在发 RA 通告主机可能优先采用了 RA 里的网关。这种情况的处理方式是明确网络里的 RA 发放策略要么只让 VRRP6 的 Master 发 RA要么统一由核心设备发避免多个源同时通告。RA 的抑制在 VRRP6 里通常有对应配置Backup 设备不应该发 RA。4.3 ping 不通有时是回程路由没写对最后一种情况请求到了回复出不去。这在跨网段 ping 虚拟网关时特别常见。主机 A 在网段 X虚拟网关在网段 Y 的设备上A ping 虚拟地址请求能到因为 A 的默认路由指向虚拟网关但回复需要设备知道怎么回到 A 所在的网段。如果回程路由缺失或者指错了接口Echo Reply 就发不出去。判断方法在 Master 设备上抓包看是否有 Echo Request 进入、是否有 Echo Reply 生成。如果只有 Request 没有 Reply查路由表show ipv6 route 2001:db8:aa::/64确认回程路由的出接口和下一跳正确。另一个常见的坑是源地址选择错误设备回复时选的源地址如果不是虚拟地址而是某个物理接口地址主机侧会因为回复源地址与请求目的地址不一致而丢弃严格模式下表现也是不通。抓包能看到 Reply 发出了但源地址不对。5. 一次完整的现场排查链路复盘上面讲的是分类实际现场是按顺序走的。我把自己的排查顺序整理成一条链路从主机侧一路往上收每一步都有明确的判断依据。5.1 从主机侧确认报文出门第一步永远在主机上做不要一上来就登设备。主机侧要确认三件事默认网关是不是虚拟地址有没有被别的路由覆盖。邻居表里虚拟地址解析到了什么 MAC。ping 的时候报文有没有真的发出去。Linux 上一条命令搞定邻居表ip -6 neigh show | grep 2001:db8:10::1如果显示INCOMPLETE说明 NS 发出去了但没有 NA 回来问题在设备侧大概率是 NDP 应答或虚拟地址归属。如果显示了一个 MAC 且是虚拟 MAC说明 ND 层通了问题在转发或回程。如果显示的是物理 MAC说明设备用物理 MAC 应答了能通但有切换隐患。再配合抓包确认报文出门tcpdump -i eth0 -nn icmp6 and ip6 host 2001:db8:10::1能看到 Echo Request 发出、没有 Echo Reply 回来就可以确定问题不在主机侧的应用层或防火墙。5.2 到 Master 上看三层与二层的落点第二步登 Master 设备按三层到二层的顺序看检查项命令示意期望结果VRRP6 状态show vrrp ipv6 detail本机为 Master虚拟地址列表正确虚拟地址可达性show ipv6 interface brief虚拟地址出现在接口地址列表中邻居表show ipv6 neighbors能看到主机的链路本地地址和 MAC接口统计show interface counters入方向无丢弃出方向无队列溢出ACL 命中show ipv6 acl counters无隐式拒绝命中这里有个细节虚拟地址在有些平台上不会显示在接口的地址列表里而是单独在 VRRP 状态里体现。所以接口地址列表里看不到虚拟地址不等于故障要看 VRRP 状态输出里的虚拟地址字段。如果 Master 侧抓包能看到 Echo Request 进来但没有 Echo Reply 出去且接口统计没有丢弃那问题多半在转发面对虚拟地址的处理上回到第 2 节去查虚拟链路本地地址和虚拟 MAC 的绑定关系。5.3 回程与切换瞬间的验证第三步验证回程。在 Master 上直接 ping 主机ping ipv6 2001:db8:aa::100能通说明回程路由没问题。不通就查路由表和源地址选择。第四步验证切换。手动把 Master 的 VRRP 关掉或者降优先级观察主机侧的表现邻居表里的虚拟 MAC 有没有变不应该变虚拟 MAC 是固定的。切换过程中丢几个包。切换后多久恢复。正常情况下切换丢包在 1 到 3 个通告周期内如果配了快速通告可以更短。如果切换后完全不恢复说明新 Master 没有正确接管虚拟地址或者没有发出免费 NA 刷新主机的邻居缓存。免费 NA 的作用是主动告诉链路上的所有主机这个虚拟地址现在在我这里MAC 是虚拟 MAC避免主机继续用旧缓存。有些平台需要在 VRRP 配置里显式开启免费 NA 或者快速通告vrrp ipv6 vrid 1 timer advertise 100 vrrp ipv6 vrid 1 gratuitous-nd enable具体命令名称各平台差异很大建议查对应版本的配置手册确认。这一项不开切换后主机侧可能长时间不通直到邻居缓存老化默认几十分钟现场表现就是切换失败了其实协议是切成功的。5.4 排查顺序速查表把上面几步压缩成一张表现场可以直接照着走顺序检查位置判断依据指向问题1主机默认路由是否只有一条指向虚拟网关多网关抢路由2主机邻居表虚拟地址对应的 MAC无记录→NDP物理MAC→应答方式3主机抓包是否有 Echo Reply无→设备侧有但不通→源地址或防火墙4Master VRRP 状态是否 Master、虚拟地址是否正确状态错→协议层5Master 抓包VRRP 通告 Hop Limit 与源非 255→被丢弃多源→双 Master6Master 转发面Echo Request 入、Reply 出入不出→虚拟地址归属7路由表回程路由与源地址缺路由→回程不通8切换测试丢包数量与恢复时间不恢复→免费 NA 未发这张表的顺序是从便宜到贵主机侧的命令最轻量设备侧的抓包最重按这个顺序走能最快收敛范围。6. 几个不值得花时间但很容易被带偏的方向排查过程中有些方向看着可疑实际上大概率不是根因浪费时间。我把这几个列出来遇到时可以先跳过。6.1 双栈防火墙与 ACL 的默认动作IPv6 的 ACL 默认动作在不同平台上不一样有的默认放行有的默认拒绝。如果设备上配了 IPv6 ACL 但没放行 ICMPv6Echo Request 会被静默丢弃表现和虚拟地址不通一模一样。但这里有个反直觉的点ICMPv6 在 IPv6 里的地位比 ICMP 在 IPv4 里重要得多ND、PMTU 发现、RA 全靠它。所以大多数平台的 IPv6 ACL 会对必要的 ICMPv6 类型做隐式放行比如 NS/NA、RA、Packet Too Big。Echo Request 不在隐式放行列表里所以如果 ACL 是默认拒绝ping 不通但业务正常是常见现象。判断方法很简单看 ACL 的命中计数。如果 Echo Request 对应的规则命中数在增长说明被 ACL 挡了。如果没有命中计数说明报文根本没走到 ACL 这一层问题在前面。我的经验是如果业务流量正常、只有 ping 不通先怀疑 ICMP 响应策略而不是 ACL。很多设备对虚拟地址默认不响应 ping需要单独开启。这个设计意图是减少攻击面但对排障很不友好因为状态显示一切正常。6.2 虚拟地址与物理地址撞车虚拟地址不能和任何一台成员设备的物理接口地址相同。如果撞了有的平台配置阶段就报错有的平台允许配但运行时行为异常DAD 检测到地址冲突虚拟地址被标记为 tentative 或者直接不可用。另一种撞车是虚拟地址和网络里其他设备的地址相同比如某台服务器手工配了2001:db8:10::1。这种情况下主机会收到两个 NA邻居表里同一个地址对应两个 MAC来回切换表现是时通时不通。排查方法在主机侧连续多次查看邻居表看同一个虚拟地址的 MAC 有没有变化。如果有变化说明链路上有地址冲突用 DAD 或者扫描工具找出来。ip -6 neigh show | grep 2001:db8:10::1连续执行几次MAC 稳定不变才是正常的。6.3 切换瞬间丢几个包属于正常现象最后一条是心态问题。VRRP 的切换不是零丢包的通告间隔、抢占延迟、免费 NA 的传播都需要时间。默认通告间隔 1 秒的情况下切换丢 1 到 3 个包是正常的。如果业务对丢包极度敏感需要做的是调小通告间隔、开启快速通告、优化抢占延迟而不是追求零丢包。但要注意区分短暂丢包和长时间不通。切换后 5 秒内恢复属于正常超过 30 秒还不恢复就要查免费 NA 和邻居缓存了。我在现场见过一次切换后 20 分钟才恢复的案例最后发现是主机侧的邻居缓存老化时间被调得特别长而且 Master 没发免费 NA主机一直往旧 MAC 发包直到缓存过期。调小通告间隔的代价是协议报文变多链路上每秒都有组播包对低带宽链路和大量 VRRP 组的场景要权衡。一般业务网段用默认 1 秒就够金融交易这类场景可以调小到几百毫秒但需要先确认设备支持的最小值。我个人在这些年折腾 VRRP6 的体会是这类问题的难点从来不在技术深度而在现象和原因之间的距离太远。IPv4 时代 ping 不通虚拟网关查 ARP、查状态、查路由三步基本能定位IPv6 时代中间多了虚拟 MAC、虚拟链路本地地址、NDP 应答、免费 NA 这几层任何一层出问题表面现象都是同一句ping 不通。所以我现在养成了一个习惯不管现场多急先花两分钟在主机侧看邻居表学到的 MAC 对不对这一步做完后面该往哪个方向查基本就清楚了。另外配置 VRRP6 的时候虚拟链路本地地址一律用默认推导值不去改它能省掉后面一大半的麻烦。真遇到改过这个地址的存量配置我的建议是趁着维护窗口改回默认值别指望它一直能用——它现在能跑只是还没到出问题的时候。