1. 先把“ping 不通”这件事拆开来看

上周有个做园区网运维的朋友找我，说他们新上一套 IPv6 网关冗余，VRRP6 主备状态显示得漂漂亮亮，display vrrp6里 Master、Backup 一目了然，可偏偏拿笔记本接上去ping6虚拟网关就是不通，改 ping 物理接口地址秒回。他一度怀疑是设备固件的问题，准备提工单换版本。我让他先把“ping 不通”这四个字拆开——是虚拟地址不响应 NS，还是响应了但回包走错路，还是压根没收到 echo request？三分钟后定位到问题：虚拟链路本地地址配了，但设备侧对虚拟地址的 ND 应答没生效，主机发出去的 NS 没人应，邻居表里始终是INCOMPLETE。

VRRP6 环境下虚拟网关 ping 不通，是 IPv6 网关冗余部署里出现频率最高的“入门级拦路虎”。它牵扯的东西比 IPv4 时代的 VRRP 多得多：ND 邻居发现、链路本地地址、ICMPv6 类型过滤、组播 ff02::12 的通路、虚拟 MAC 在交换侧的落点，任何一环掉链子都表现为同一个症状。这篇就把我这些年踩过的坑、验证过的排查顺序、以及能直接抄的配置骨架整理出来，适合刚接触 IPv6 冗余网关的运维、正在做 IPv6 改造的网络工程师，也适合被这个问题卡了半天想找根因的老手。

1.1 三种“不通”背后是三条完全不同的故障链路

很多人一上来就怀疑 VRRP6 协议本身没起来，其实协议状态和可达性是两条独立的路。我习惯先把现象分成三类，分类做对了，后面能省一大半时间。

第一类是邻居都学不到。主机上ip -6 neigh看虚拟地址，状态长期停在INCOMPLETE或者根本没有表项，抓包能看到主机在发 NS，但收不到 NA。这类问题基本锁定在应答侧：虚拟地址没被设备当成“可应答地址”，或者应答报文被安全策略拦了。

第二类是邻居学到了但 echo 不回。ip -6 neigh里虚拟地址对应着00:00:5e:00:01:xx这个虚拟 MAC，状态REACHABLE，但 ping 一直超时。这时候问题往往在 ICMPv6 Echo 的处理上——设备收到了，但没往协议栈上层送，或者回包的源地址选了物理地址、目的地址对不上会话。

第三类是能通但时通时断。ping 几包通几包，或者主备一切换就断几十秒。这类最常见的原因是双主（两边都认为自己是 Master）、抢占延迟没配好、或者回程路由的下一跳写死成了某台设备的物理地址。三类现象对应的排查入口完全不同，混在一起查只会越查越乱。

提示：先在主机侧抓好包再动手改配置。抓包位置选在主机接入口，能看到 NS 有没有发出去、NA 有没有回来、echo request 有没有回应，这三个信息比在设备上翻十页日志都管用。

1.2 VRRP6 与 IPv4 VRRP 在应答机制上的关键差异

IPv4 的 VRRP 里，虚拟 IP 不通，大家习惯性想到的是“允许 ping 虚拟 IP”这个开关没开，或者虚拟 MAC 没被交换机学习到。到了 IPv6，情况复杂了一层，因为 IPv6 的地址解析不再用 ARP，而是 ICMPv6 承载的 ND。

IPv4 的 ARP 是独立的三层半协议，广播请求、单播应答，设备只要愿意代理，回一个 ARP reply 就行。IPv6 的 NS/NA 是 ICMPv6 报文，走的是组播 solicited-node 地址（ff02::1:ffxx:xxxx），应答的 NA 必须携带目标链路层地址选项。这意味着设备要应答虚拟地址的 NS，必须在 ICMPv6 层面把“这个虚拟地址归我管”这件事表达清楚，而不是像 ARP 那样简单回一个帧。

更关键的是链路本地虚拟地址。VRRPv3 for IPv6（RFC 5798）明确要求每个虚拟路由器必须配置一个链路本地虚拟地址，通常在fe80::/10范围里手工指定。原因很实际：IPv6 主机通过 RA 学到的默认网关是链路本地地址，如果虚拟路由器只有一个全局虚拟地址而没有链路本地虚拟地址，主机根本没法把流量交给它。所以配置时全局虚拟地址和链路本地虚拟地址必须成对出现，少一个都会出问题——有的设备会直接报错拒绝，有的设备允许配但不生效，后者更坑。

再一个差异是协议号和组播地址。VRRP6 报文封装在 IPv6 里，Next Header 是 112，目的地址固定ff02::12，源地址必须是接口的链路本地地址，跳数限制 255。IPv6 ACL 默认策略如果是拒绝，这条组播很容易被顺手拦掉，表现出来就是主备都变 Master，或者 Backup 一直收不到通告。IPv4 时代大家还会记得放行协议 112，IPv6 下这个意识反而弱了。

1.3 影响范围与优先级判断

虚拟网关 ping 不通，影响面要看它处在什么位置。如果这套 VRRP6 是终端网关，那所有依赖它做默认网关的主机全部断网，这是 P1；如果只是运维习惯性拿虚拟地址做探活，实际业务走的是别的路径，那可能只是监控误报，先放着也行。

判断方法很简单：在任意一台下游主机上ip -6 route看默认路由的 next-hop 是不是那个虚拟链路本地地址。如果是，且虚拟地址不可达，主机就是全面断网状态；如果默认路由指向的是设备的物理链路本地地址，那说明 RA 里的网关地址压根没换成虚拟地址，这本身就是个配置问题——冗余没生效，只是碰巧现在主设备活着。

还有一种隐蔽的影响：虚拟地址 ping 不通但业务通。这种情况常见于上游回程路由指向虚拟网段、转发平面正常，只是控制平面对 ICMPv6 做了限制。这种“假故障”不用急着改配置，但要在监控上把探活方式换掉，否则天天告警。

2. 虚拟地址为什么“不该由它自己回答”

这个标题有点反直觉，但确实是理解 VRRP6 应答机制的关键。虚拟地址在物理上不存在于任何一台设备的接口上，它是被“声明”出来的。设备要替它回应 NS 和 Echo，靠的不是地址配置，而是一套代理逻辑。搞不清这一点，配置改多少遍都是碰运气。

2.1 虚拟 MAC、ND 应答与 accept 模式

VRRP6 沿用 IPv4 VRRP 的虚拟 MAC 规则：00-00-5E-00-01-{VRID}，VRID 范围 1 到 255，最后一个字节就是 VRID 的十六进制。VRID 为 10 时虚拟 MAC 是00:00:5e:00:01:0a。这个 MAC 不会作为任何报文的源 MAC 出现，它只出现在两个地方：Master 发送 VRRP 通告时报文的目的 MAC，以及回应虚拟地址 NS 时 NA 报文里的目标链路层地址字段。

主机要访问虚拟地址，流程是这样的：主机算出发往虚拟地址的 solicited-node 组播地址，发 NS；Master 设备收到 NS，判断这个地址归自己代理，回一个 NA，NA 里的目标链路层地址填虚拟 MAC；主机把虚拟 MAC 写进邻居表，后续流量二层目的 MAC 就是虚拟 MAC。交换机上如果没有这个虚拟 MAC 的表项，流量会被泛洪到 VLAN 内所有端口——小网络无所谓，大网络里这种泛洪会带来额外压力和 MAC 表异常。

这里就引出第一个大坑：很多设备默认不对虚拟地址做 ND 应答。IPv4 时代有个“允许 ping 虚拟 IP”的开关，IPv6 下类似的功能叫法五花八门，有的叫虚拟地址 ND 应答，有的归在 accept 模式里。不开这个功能，设备认为虚拟地址“不是我的接口地址”，收到 NS 直接忽略，主机邻居表永远 INCOMPLETE。

第二个坑是地址拥有者（address owner）与备份设备的差异。如果某台设备的接口地址恰好就是虚拟地址，它的优先级自动是 255，此时它对这个地址是“真拥有”，ping 一定通。这就造成一种迷惑现象：主设备上测一切正常，一切换到备设备就不通了。排查时一定要在备设备升主之后测，或者在两台设备上分别验证应答逻辑，别被“当前主设备正常”骗过去。

还有一类是 accept 模式的连带影响。部分设备默认不接受目的地址不是本接口地址的报文，虚拟地址的 Echo Request 进来后直接被转发平面丢弃，连 CPU 都上不去。开启 accept 模式后，设备才会把发往虚拟地址的报文当成本机报文处理。这个开关和 ND 应答是两个独立的东西，ND 通了但 Echo 不回，八成就是它。

注意：验证 ND 应答是否生效，最直接的办法是在主机上清掉邻居表后 ping，同时ip -6 neigh show反复刷。如果状态在INCOMPLETE和REACHABLE之间反复跳，说明 NS 发出去了、NA 偶尔回来但被丢弃；如果一直INCOMPLETE，就是压根没回 NA。

2.2 链路本地虚拟地址是硬门槛而非可选项

前面提过链路本地虚拟地址的必要性，这里展开讲讲为什么它经常是故障的直接原因。

主机通过 RA 学习默认网关，RA 报文的源地址必须是链路本地地址（fe80::/10），这是 IPv6 的硬规定，全局地址做 RA 源是不合法的。所以主机路由表里默认网关那一栏填的一定是fe80::xxxx。如果 VRRP6 只配了全局虚拟地址，主机学到的网关仍然是某台设备的物理链路本地地址，主备切换时这个地址跟着设备走，主备倒换后主机网关直接失联。

更麻烦的是，有些设备在配置 VRRP6 时，如果不显式指定链路本地虚拟地址，全局虚拟地址的 ND 应答也会受影响——因为应答 NS 时需要用链路本地地址做源，没有链路本地虚拟地址就得借用物理的，某些实现下会直接放弃应答。

配置上通常是这样一对：

# 通用化片段，不同设备命令字面有差异，逻辑一致 interface Vlanif10 ipv6 enable ipv6 address 2001:db8:10::1/64 vrrp6 vrid 10 virtual-ip 2001:db8:10::fe vrrp6 vrid 10 virtual-ip fe80::10 link-local vrrp6 vrid 10 priority 120 vrrp6 vrid 10 preempt-mode timer delay 20

链路本地虚拟地址建议全网统一规划，比如每个 VLAN 固定用fe80::{vlan号}，好记、好排障、好写文档。别用随机值，半年后没人记得住。

还有一个细节：链路本地地址冲突检测。fe80::10这种地址如果另一台设备也配了，DAD 会检测出来，接口地址进入 duplicate 状态。虽然虚拟地址的 DAD 行为各设备实现不一，但一旦撞上，表现就是时通时不通，非常难查。

2.3 组播 ff02::12 与协议号 112 的通路

VRRP6 通告报文的目的地址是ff02::12，源地址是接口链路本地地址。这个组播是链路本地范围（scope 是 link-local），不会被路由器转发，但会被交换机的各种组播控制功能影响。

常见拦截点有这么几个：IPv6 ACL 里没放行协议 112；安全策略把 VRRP 报文当未知协议丢弃；交换机开了组播风暴抑制，ff02::12被限速；某些接入层设备对ff02::/16做了特殊处理。

判断方法很直接：在备设备上抓包看有没有收到源地址为主设备链路本地地址、目的ff02::12的报文。收不到，就在链路上逐跳查；收到了但状态还是 Backup，那看优先级和抢占配置。

同时别忘了 ICMPv6 本身。主机的 NS/NA 是 ICMPv6 type 135/136，RA 是 133/134，Echo 是 128/129。IPv6 ACL 如果写成“只放行 TCP 8080”这种，ND 直接瘫痪，表现出来就是“网络时好时坏”。IPv6 环境下的安全策略，ICMPv6 基础类型必须无条件放行，这不是可选项。

3. 五层定位法：从地址规划查到回程路径

排查顺序很重要。我见过有人一上来就怀疑安全策略，翻了半小时防火墙日志，最后发现是虚拟地址和接口地址配在同一台设备的同一个网段但地址写错了。按层往下查，每层都有明确的“通过/不通过”判据，比凭感觉猜高效得多。

3.1 第零层：虚拟地址规划与 DAD 自检

动手改任何配置之前，先把地址规划表拉出来对一遍。检查三件事：全局虚拟地址是否与接口地址同网段且不冲突；链路本地虚拟地址是否全网唯一；虚拟地址有没有被别的设备手工配过。

同网段这一条看着废话，实际踩坑不少。有人把虚拟地址配成2001:db8:20::fe/64，接口地址是2001:db8:10::1/64，设备不一定报错，但主机侧根本不会为这个地址发 NS——因为它不在链路上。这种配置属于“设备显示正常、业务完全不通”的典型。

DAD 自检可以在设备上临时把虚拟地址配到某个测试接口上，看是否报冲突；也可以在下游主机上对整个网段做一次邻居扫描，看有没有重复。更省事的办法是用ping6虚拟地址的 solicited-node 组播地址，如果除了 Master 之外还有别的设备回应，说明存在冲突。

规划层面还有一个容易忽略的点：虚拟地址不要用网段的第一个或最后一个可用地址。IPv6 没有广播地址的概念，这个约束不存在，但运维习惯上还是会留出低位地址做网关，方便记忆和文档化。

3.2 第一层：VRRP6 状态与通告报文

状态机这一层要看的信息包括：VRID、优先级、当前状态、虚拟地址列表、通告间隔、抢占配置。确认两边 VRID 一致、虚拟地址列表一致、通告间隔一致。VRID 不一致是最常见的低级错误，两台设备各配各的，都觉得自己是 Master，表现出来就是双主、时通时断。

通告间隔和 Master_Down_Interval 的关系要心里有数：Master_Down_Interval = 3 × Advertisement_Interval + Skew_Time，其中Skew_Time = (256 − Priority) / 256秒。优先级 120、通告间隔 1 秒时，Skew_Time 约 0.531 秒，Master_Down_Interval 约 3.53 秒。如果两台设备配了不同的通告间隔，收敛时间会算错，切换时出现短暂双主。

看报文的话，正常应该每秒一次，源地址是主设备的链路本地地址，目的ff02::12，Next Header 112。备设备侧如果完全看不到，问题在二层通路或 ACL；如果看得到但状态不变，看优先级和抢占设置。

3.3 第二层：ND 表项与虚拟 MAC 的落点

这一层是 ping 不通问题的核心战场。检查顺序是：主机邻居表里有没有虚拟地址、对应 MAC 是不是虚拟 MAC、交换机 MAC 表里有没有这个虚拟 MAC。

主机侧ip -6 neigh show如果显示虚拟地址对应00:00:5e:00:01:0a，状态REACHABLE，说明 ND 通了，问题在 ICMPv6 Echo 处理；如果显示INCOMPLETE或<incomplete>，说明 NA 没回来；如果显示的 MAC 是某台设备的物理 MAC，说明有设备在用物理地址代答，这会导致主备切换后流量仍发往原设备。

交换机侧查虚拟 MAC 有没有学到。正常情况下学不到——虚拟 MAC 从不做源 MAC。所以回程流量到虚拟 MAC 时会被泛洪。如果 VLAN 内端口很多，或者配了端口安全、IPSG 之类的绑定检查，虚拟 MAC 可能直接被判非法丢弃。解决办法是在交换机上静态绑定虚拟 MAC 到上行口，或者在安全特性里给虚拟 MAC 开白名单。

3.4 第三层：ICMPv6 与安全策略放行

到这一层要确认的是：Echo Request 到没到设备、设备有没有回、回包有没有被丢。

设备侧如果有抓包工具，直接抓虚拟地址相关的 ICMPv6 报文最准。看不到 Echo Request，说明上游或本机转发面丢了；看得到请求看不到回复，说明应答逻辑或安全策略拦了；两者都有但主机收不到，说明回程路径有问题。

安全策略要放行的清单：ICMPv6 type 128/129（Echo）、135/136（NS/NA）、133/134（RS/RA）、1/2/3/4（差错报文，尤其 type 2 Packet Too Big 必须放，否则大包不通小包通）、协议号 112（VRRP6）。IPv6 环境下差错报文被拦是“能 ping 通小包、ssh 连不上”这类怪问题的常见根因。

另外注意虚拟地址有没有被纳入安全区域。防火墙类设备上，虚拟地址如果不是任何接口的地址，可能落在“未指定区域”，默认策略直接拒绝。需要手工把虚拟地址加入对应区域或策略。

3.5 第四层：源地址选择与回程路由

最后一层是路由。ping 虚拟地址时，源地址选谁很关键。从同网段主机 ping，源自动选同网段接口地址，没问题。从远端 ping，源可能选了 loopback 或管理口地址，如果那条路径上没有回程路由，请求到了、回复出不去，表现就是不通。

指定源地址测试是个好习惯：

ping6 -I 2001:db8:99::1 2001:db8:10::fe -c 4

回程路由方面，上游设备指向这个网段的路由，下一跳建议写虚拟地址而不是某台设备的物理地址。写物理地址的话，主备切换后回程流量还往原设备送，虽然 ping 虚拟地址可能还通（因为请求到了新主、回复走原路），但业务流量会出现单向不通。这个坑我在割接时遇到过，现象是“能 ping 通但下载卡死”，查了两小时才发现是上游静态路由写死了下一跳。

4. 一套可直接套用的配置框架与参数计算

理论讲完，落到配置。下面这套骨架是双机主备的最小可用集，逻辑通用，不同设备的命令字面会有差异，但每一项的作用是一致的。

4.1 双机主备的最小配置骨架

主设备（优先级更高）：

# 设备 A interface Vlanif10 ipv6 enable ipv6 address 2001:db8:10::1/64 ipv6 nd ra-interval 30 vrrp6 vrid 10 virtual-ip 2001:db8:10::fe vrrp6 vrid 10 virtual-ip fe80::10 link-local vrrp6 vrid 10 priority 120 vrrp6 vrid 10 preempt-mode timer delay 20 vrrp6 vrid 10 timer advertise 1 vrrp6 vrid 10 track interface GigabitEthernet0/0/1 reduced 30

备设备（默认优先级 100）：

# 设备 B interface Vlanif10 ipv6 enable ipv6 address 2001:db8:10::2/64 vrrp6 vrid 10 virtual-ip 2001:db8:10::fe vrrp6 vrid 10 virtual-ip fe80::10 link-local vrrp6 vrid 10 preempt-mode timer delay 20 vrrp6 vrid 10 timer advertise 1 vrrp6 vrid 10 track interface GigabitEthernet0/0/1 reduced 30

几个必须成对出现的点：VRID 两边一致；虚拟地址列表两边完全一致（包括链路本地虚拟地址）；通告间隔一致；抢占延迟一致。少一个都可能出现双主或切换异常。

RA 这一块要特别注意。如果设备同时承担 RA 下发，RA 里通告的默认网关地址应该是虚拟链路本地地址，而不是物理接口的链路本地地址。有些设备需要额外配置才能让 RA 使用虚拟地址作为源，有些默认就是虚拟地址。这个点没确认，冗余等于没做——主机学到的网关永远指向当前主设备，一切换就断。

4.2 优先级、抢占延迟与 Track 的计算

优先级取值范围 1 到 254，255 保留给地址拥有者。规划上我一般这样分配：主设备 120，备设备默认 100，Track 联动降 30。这样上行链路故障时主设备降到 90，备设备 100 接管，故障恢复后主设备优先级回升到 120，等 20 秒抢占延迟再切回来。

抢占延迟设 20 秒不是拍脑袋。要点是它必须大于“上行链路故障检测时间 + 路由收敛时间 + 会话表同步时间”。如果上行跑的是 BFD 加路由协议，收敛通常在秒级，20 秒足够；如果只是接口 down 检测，可能更快。设太短会出现链路抖动导致主备来回切，设太长则故障时业务中断时间变长。

Track 的降幅也要算。降 30 的含义是主设备 120 降到 90，比备设备的 100 低才触发切换。如果只降 10 变成 110，还是比 100 高，根本切不过去。这是新手最容易犯的错之一：配了 Track 但降幅不够，故障时状态纹丝不动。

Master_Down_Interval 的默认值基于通告间隔和优先级算：优先级 120 时约 3.53 秒，优先级 100 时约 3.61 秒。如果对收敛有更高要求，可以把通告间隔调到 200 毫秒甚至更低，但要注意设备 CPU 压力和链路上 VRRP 报文密度。我一般不调，1 秒够用，网络里多几百个会话也就那样。

4.3 接入交换机侧要配合的两件事

设备配好了不代表能通，接入交换机上还有两件事要做。

第一件是虚拟 MAC 的处理。虚拟 MAC 不出现在源 MAC 里，交换机学不到，回程流量泛洪。小网络忍了，大网络建议静态绑定：

# 通用化示意 mac-address static 0000-5e00-010a vlan 10 GigabitEthernet0/0/1 mac-address static 0000-5e00-010a vlan 10 GigabitEthernet0/0/2

绑到两条上行口，主备切换后不需要重新学习。

第二件是安全特性的白名单。端口安全如果限制了每个端口可学的 MAC 数量，或者做了 IP-MAC 绑定检查，虚拟 MAC 和虚拟地址的组合会被判非法。需要在对应的绑定表里加上虚拟地址与虚拟 MAC 的映射，或者在端口安全策略里放行00:00:5e:00:01:xx这段 MAC。

还有 MLD snooping。ff02::12属于链路本地范围组播，正常不会被跨 VLAN 剪枝，但如果交换机开了组播风暴抑制且阈值设得很低，VRRP 报文可能被限速。检查方法是在备设备上看通告报文有没有周期性丢失，丢包率高就要调阈值或者给ff02::12开例外。

5. 速查表与几个反直觉的坑

排查经验最后都会沉淀成一张表。下面这张是我自己用的版本，按现象查原因，命中率还不错。

5.1 故障现象对照速查表

5.2 三个最容易被忽略的细节

第一个是地址拥有者的迷惑性。如果某台设备的接口地址恰好等于虚拟地址，它的优先级自动 255，永远主，永远能 ping 通。这种情况下你测什么都是好的，直到这台设备宕机、备机接管，问题才暴露。所以验证必须在备机升主的状态下做，别偷懒。

第二个是 RA 与 VRRP6 的配合。很多人配完 VRRP6 就以为完事了，忘了 RA 里通告的网关地址还是物理链路本地地址。主机学到的默认网关指向具体设备，主备切换时主机要等 RA 老化重新学习，中间几十秒到几分钟不通。这个坑在割接验证时最容易被“ping 得通”掩盖过去，因为当前主设备活着，一切正常。

第三个是链路本地虚拟地址的作用域。fe80::10这种地址只在链路内有效，不能跨三层。如果网络里有两个 VLAN 都用了fe80::10做虚拟地址，这不冲突，因为它们在不同的链路上。但如果你在文档里只写“虚拟网关 fe80::10”，新人很容易在错误的 VLAN 里配同一个地址，然后在跨 VLAN 测试时发现“地址冲突”。规划时建议带上 VLAN 号，比如 VLAN10 用fe80::10、VLAN20 用fe80::20，一眼能对上。

5.3 上线前的验收清单

配置做完别急着交付，按这个清单走一遍，能挡掉八成返工。

• 两台设备分别单独升主，各自验证虚拟地址 ping 通、ND 应答正常
• 主机侧确认默认网关的 next-hop 是虚拟链路本地地址，不是物理地址
• 主机邻居表里虚拟地址对应的是虚拟 MAC，不是物理 MAC
• 拔掉主设备上行链路，验证 Track 降级、备机接管、业务中断时间在可接受范围
• 主设备恢复后验证抢占延迟生效，没有立即抢回
• 从远端网段 ping 虚拟地址，源地址指定为业务网段地址，验证回程路由
• 大包测试ping6 -s 1400，确认路径 MTU 和差错报文放行
• 交换机侧确认虚拟 MAC 有静态绑定或泛洪可控

我个人在实际操作中的体会是，VRRP6 这类问题的排查成本，八成花在“没先分类”上。拿到故障先把现象归到三类里，再按层往下走，比对着配置文件一行行看快得多。另外一条经验：任何一次 IPv6 网关改造，都别在现网直接改，先在实验室用两台设备加一台主机把主备切换、RA 学习、大包测试跑一遍。实验室里十分钟能发现的问题，现网可能要停业务两小时才能定位。最后一个建议，虚拟地址规划文档一定要写清楚每个 VLAN 的全局虚拟地址、链路本地虚拟地址、虚拟 MAC、对应的 VRID，这四个信息凑齐了，后面接手的人排障能省一半时间。