VRRP链路跟踪原理与配置，解决主备切换脑裂和高可用故障

做网络运维十几年，要说最让我心里发毛的故障，不是设备烧毁，而是所有设备指示灯全亮、CPU正常、日志干净，但业务流量说断就断。前几天帮一个客户排查两台核心交换机的诡异丢包，就是典型的VRRP脑裂：两台设备都认为自己是虚拟网关的主角色，都在回ARP、都在转发，结果接入层的MAC表在两个端口之间来回答荡，整个办公网上线上线断断续续。最后定位到根因，其实跟VRRP本身的报文协商没关系，而是出在上联链路状态没有关联到VRRP抢占据点上，也就是说缺了VRRP链路跟踪。今天这篇文章，就围绕这个坑把VRRP、链路跟踪、脑裂和高可用网络完整串一遍，给正在被主备切换折磨的朋友一个可以照抄的排障和配置思路。

1. 想搞懂链路跟踪，先得知道VRRP在防什么

1.1 高可用网关这件事，VRRP只干了半截

VRRP全称是Virtual Router Redundancy Protocol，虚拟路由冗余协议，本身解决的是一个很朴素的单点问题：用户的网关只有一个IP、一台设备，设备坏了所有人上不了网，所以需要把两台真实路由器对外伪装成一个虚拟路由器，虚拟IP作为默认网关，平时由主设备（Master）转发，备设备（Backup）在后台等。

协议里最核心的动作就是Master周期性地向Backup发通告报文，Backup如果连续一段时间收不到这个通告，就判断Master出事了，于是切换成Master继续接管虚拟IP。这样的机制确实可以对付“设备整台死掉”“断电”“进程崩溃”这类硬故障，因为设备不转发VRRP报文了，备份设备迟早会上位。

但你注意我的用词：能对付硬故障，却对付不了“软故障”。什么叫软故障？设备本身还在运行、VRRP进程还在发通告、接口的状态还是UP，可它通往外部网络的那条路已经断了。比如核心交换机主设备的上联口连着出口路由器，出口路由器那一侧断电，或者两台设备之间的光模块衰减严重导致流量半通，核心交换机本地接口可能依然是UP状态。它仍然正常发送VRRP通告给备份，所以备份永远等不到超时，虚拟IP也就永远留在了一个无法正常出局的设备上。这就是VRRP只干了半截活：它保证了网关不因为设备宕机而失效，却没保证网关一定有一条可用的上行路径。

所以如果你只配置了VRRP而没做链路跟踪，高可用程度大概只能算完成了一半。评估一个高可用网络是否合格，不能只看“主设备死了切不切”，更要看“主设备虽然活着但出口废了，虚拟IP能不能赶紧搬家”。

1.2 脑裂的锅，大多不是VRRP协议本身

提到脑裂，很多人第一反应就是双Master。现在分布式系统、集群软件里都有这个说法，VRRP场景下的脑裂，本质上是两台设备都认为自己才是虚拟IP的唯一持有者。这里有个容易被误解的地方：VRRP协议本身其实是非常讨厌“双主”的，设计上已经尽量避免了同时响应虚拟IP的可能，因为它用组播报文做保活、用优先级选主、用固定虚拟MAC做转发。

但协议再严谨，也架不住外部网络割裂。主备两台设备之间如果VRRP报文互通不了，那协议就没有办法维持“一个主一个备”的共识。常见的原因包括两台核心之间互联的二层链路中断、中间设备上的ACL把组播过滤了、Trunk端口没放通VRRP所属VLAN、端口安全策略把组播源MAC隔离了，等等。一旦双方互相收不到通告，Backup会严格按照超时时间升为Master，而原来的Master因为还活着，不会主动退出，于是两台设备同时对外宣称“我是网关”。

换句话说，脑裂的根本原因是“保活链路失效”，链路跟踪并不能直接解决这个保活失效的问题。链路跟踪解决的是另一个前因后果：主设备向备份通了信，但主设备的上行对外路径已经失效。如果不把这两类故障场景分开，很多人会把链路跟踪当成脑裂的万能药，结果保活链路本身断了，两台设备照样脑裂。先把这套逻辑理顺，配置的时候你才知道每一条命令在防什么。

2. 链路跟踪到底在跟踪什么，怎么解决“假活”

2.1 上联断了，设备为什么还在硬撑着当主

很多刚接触VRRP的工程师会问：上联都断了，设备为什么不能自己感知一下，然后主动放弃主角色？因为VRRP标准协议里根本没有这个信息源。它只能看到一个抽象的虚拟路由器和一组VRRP状态机，它知道自己是Master、知道要发通告，但不知道“Master这台设备通往其他网络是不是还有出路”。

咱们拿生活的例子类比。假设你公司有个客服热线，主客服生病了，你马上可以让备客服接听；但主客服只是被客户投诉了导致渠道暂停，人还坐在工位上敲键盘，系统并不知道他已经没法对外服务。你可能要等很久，甚至要客户打第二个电话才发现问题。VRRP就是这个系统，它只能通过“热线一直有人接”（通告活着）来判断主客服健康，而不能通过“客户真正的问题有没有被解决”（上行流量是否通）来判断。链路跟踪，就是主动给系统加一个监督员：盯着主客服对应的业务渠道，渠道出问题，立刻把他的“接听权优先级”降下来。

从实现层面说，VRRP选主靠的是优先级。默认情况下优先级高的做主，如果优先级相同，则比较接口IP大小，但不能依靠这种偶然。链路跟踪正是在优先级上做文章：它把一个被监控对象的状态映射成优先级降低值，状态一变坏，Master的优先级就下降，Backup的优先级相对变高，从而在协议层触发抢占。

2.2 链路跟踪的原理：把“外联状态”折算成“优先级”

链路跟踪的原理可以拆成三环。第一环是监视对象，最常见的是物理接口，比如GigabitEthernet0/0/1。第二环是Track对象，它把接口的物理协议状态翻译成一个统一的“好/坏”状态。第三环是VRRP和Track的绑定，在VRRP组里配置：如果某个Track坏了，本设备的优先级自动降低多少。配置好之后，当上行接口的状态从UP变成DOWN，Track变成DOWN，VRRP优先级直接从120降到80。由于Backup的优先级是100，原来处于劣势的Backup现在反而更高，于是Backup发起抢占成为新主。整个过程不需要人的参与，也不需要把主设备彻底关掉。

这里有个必须强调的细节：下降值的设计决定了切换逻辑是否成立。你想要让备份设备胜出，就必须让主设备在故障后的实际优先级低于备份设备。比如主设备初始120，备份100，那么降值至少是21，但考虑到可能存在多个Track对象叠加，我一般习惯把降值配成40，这样即使两个Track同时降也只是从120降到80，备份依然是100，逻辑上还能稳定胜出。如果你把降值配成10，那么主设备故障后优先级是110，依然高于备份的100，备份永远抢不到主，配置等于白做。

还要注意，链路跟踪不是只能监视接口。在很多组网里，关键路径故障并不表现为本端接口down，而是远端设备掉线或中间路由中断。这时候需要用BFD会话或者NQA探测作为监视对象。BFD能在毫秒级发现双向转发检测失败，NQA可以定期探测对端IP的ICMP或TCP端口通断，把这些探测结果绑定到Track上，跟踪能力就从“物理接口”扩展到了“端到端路径”。

2.3 链路跟踪的两个进阶版本：NQA和BFD

先说BFD，也就是双向转发检测。它的机制是在两台设备之间建立会话，两边以极快的周期互发检测报文，一旦连续几个报文没有收到，立即判定链路故障。它本身不是一个路由协议，也不参与选路，就是一台“快速心跳机”。把BFD会话绑定到VRRP Track后，原本只能靠VRRP通告超时等3秒左右的切换，可以缩短到几百毫秒甚至更快。当然，生产环境不建议把检测时间调到极端，因为网络拥塞时可能导致误判，一般配置在300毫秒或500毫秒比较稳妥。

再说NQA，它更像一个业务级的探针。比如上行链路实际是通的，但上游设备上的某条路由丢了；或者中间防火墙把某些协议拦截了，导致业务不通。NQA可以构造ICMP请求、TCP连接请求等真实探测流，去测试一个业务IP和端口。只要探测失败，就认为路径质量不满足要求，同样可以把Track置为DOWN并触发VRRP切换。这种用法的核心是：你监控什么，就代表你在意什么；如果你只在上联口做物理Down检测，那么对端单板故障这种“接口还UP但路由已经没了”的场景必然漏报。

3. 从零配置VRRP链路跟踪，一步都不踩坑

3.1 先画一张不出错的组网球，再动手

配置之前我习惯先花五分钟把拓扑画准。假设一个很常见的场景：两台核心交换机C1和C2，其中C1是主设备，C2是备设备；它们之间有一条专门的互联链路，用于VRRP报文的互通；用户网关放在C1和C2的同一个三层接口（比如VLANIF10，网段192.168.10.0/24）；C1和C2分别用上联口接到出口路由器R1和R2，R1和R2再分别接运营商或者防火墙。注意，我特意说专用互联链路，是因为VRRP报文的安全性优先性很高，如果和业务流量挤在同一条很拥塞的链路里，可能导致通告丢失进而误切换。当然如果你用的是两台核心之间的物理直连端口，性能一般不成问题。

这个拓扑里，链路跟踪要监控的对象非常明确：C1监控自己的上联口（去R1的接口），C2监控自己的上联口（去R2的接口）。两者不要搞反，更不要监控和对面核心互联的心跳口，否则你监控的链路断了，恰恰说明心跳也没了，这时候再去降低优先级，只会让局面更乱。我见过不少把Track挂到心跳口的实例，结果心跳抖动一次，两台设备来回抢主，比不配还惨。

3.2 核心交换机上的VRRP加Track配置实例

下面以华为VRP设备为例给一套配置。C1上的网关接口配置大概是这样：

interface Vlanif10
ip address 192.168.10.2 255.255.255.0
vrrp vrid 10 virtual-ip 192.168.10.1
vrrp vrid 10 priority 120
vrrp vrid 10 preempt-mode timer delay 20

C2上的对应接口配置则是：

interface Vlanif10
ip address 192.168.10.3 255.255.255.0
vrrp vrid 10 virtual-ip 192.168.10.1
vrrp vrid 10 priority 100
vrrp vrid 10 preempt-mode timer delay 20

这里我把虚拟IP当成网关，VRID选10，C1优先级120，C2默认100。两台都开启了抢占，并且设置了20秒抢占延时，目的是防止上联链路抖动时主备角色频繁切换。接着在C1上创建Track监视上联口，假设C1的上联口是GigabitEthernet0/0/1：

track 1 interface GigabitEthernet0/0/1 line-protocol

然后在Vlanif10下面把Track绑定到VRRP：

interface Vlanif10
vrrp vrid 10 track 1 reduce 40

这样当GigabitEthernet0/0/1的线路协议变为DOWN时，C1的VRRP优先级由120降为80。C2原本优先级100，在收到C1通告变化后就能通过抢占成为Master。思科设备上的写法也类似，比如track 1 interface GigabitEthernet0/1 line-protocol，然后在接口Vlan10下配置vrrp 10 track 1 decrement 40。不同厂商命令关键字不同，但思路完全一致，换到H3C、锐捷等设备，只要找到接口跟踪和VRRP priority reduce关键字就能举一反三。

3.3 优先级和降低值怎么定才不出逻辑漏洞

优先级配置看似简单，里面藏着三处容易忽视的点。第一，降值必须大于主备优先级差。我习惯把主设备设成120、备份设100，降40，逻辑余量充足。如果你把主设成110、备份设100，降值只用20，那么主故障后优先级变成90，备份100可以上位，也没问题，但余量变小了，万一还存在其他叠加降值，就可能出现备份上不了位的情况。第二，要提前想清楚多个Track同时故障时的最终优先级。比如主设备同时跟踪上联口和出口路由器的BFD会话，两个Track分别降20和30，一旦两个都坏，优先级可能从120降到70，仍然低于备份100，这没问题；但如果备份也有一个Track，它坏的时候备份优先级也会降低，最终谁主谁备要靠退化后的数值比较来决定，所以一定要列出所有组合，确保任意组合下都有一台设备明确胜出。第三，抢占延时不能只图短。20秒适合大多数办公网，但对要求快速切换的生产网，可以把延时调到5秒甚至3秒，同时配合BFD快速检测。太长的延时会让业务中断感受很明显，太短的延时又会让一次十几毫秒的抖动触发十几分钟的振荡，这个尺度需要按业务实际流量特征去调。

3.4 验证配置：模拟故障并不是拔线就可以

配置写完必须验证。很多人喜欢直接拔上联口的网线，这样做只能模拟物理接口down，并不能验证Track和BFD的完整链路。我建议分三档来测。第一档，在C1的上联口执行shutdown，确认接口状态down，然后观察display vrrp输出的优先级变化和Master角色切换，这一步验证物理接口跟踪。第二档，把C1和出口路由器之间的BFD会话手动操作shutdown，看Track是否跟动，优先级是否变化，这一步验证端到端检测。第三档，把C2的上联口也shutdown，模拟主备的上行链路都不可用，看最终会不会出现都没有Master的情况——正常情况下至少应该有一台是Master，因为有一条路径可能仍然通过其他方式可达，但如果你的Track配置导致两台都降级，说明逻辑有漏洞，赶紧回去改。

查看状态的命令也很简单。华为设备用display vrrp vrid 10查看Master、Backup、Priority、Preempt等关键信息，用display track 1查看Track当前状态。思科用show vrrp和show track。我在实际验证时还会同时打印两端状态，确认“原主变Backup、原备变Master”这种角色反转确实发生了，而不是只看一台设备。

4. 脑裂问题排查实录：从“双主”到“恢复”

4.1 脑裂出现时，网络会呈现什么状态

脑裂现象非常典型。你怎么会意识到网络不对劲？往往不是看核心交换机日志，而是用户反馈上网特别慢、视频会议不断卡顿、访问内部系统有一阵子通一阵子断。到接入交换机上看，网关的MAC地址对应的端口在C1和C2两个上行口之间来回刷新，有时一条静态MAC刚学完马上被另一条覆盖，这就是典型的网关mac在多个端口漂移，说明两台核心都在响应这台虚拟IP的ARP。

再往核心上查，两台的display vrrp结果都显示自己是Master。这里有个很容易犯的错：有人看到两台都是Master，第一反应是“赶紧重启其中一台”，这当然能让业务恢复，但只是临时止损，不解决根因。真正要做的是搞明白为什么它们互相收不到VRRP通告，否则下次任何一根抖动又能触发双主。

4.2 排查顺序：先看状态、再看报文、后查策略

我按照定位效率从高到低说。第一步，在两台核心上同时查看VRRP状态和Track状态。如果看到双Master，先把其中一台的VRRP优先级手动降低或者直接重启一台？不，应该在保证配置理解的前提下用命令重新建立状态，比如在备设备上执行interface vlanif10下再敲一次vrrp vrid 10 priority 100，让它主动放权。但这是应急，不能算排查。第二步，在两台设备和中间链路上抓VRRP公告报文，目的组播地址通常是224.0.0.18，协议号112，确认从C1发出的报文能不能到达C2，从C2发出的能不能到达C1。如果一方完全收不到，问题基本锁定在二层互通或者组播过滤。第三步，顺着VRRP报文不通的方向检查中间的Trunk配置、ACL策略、端口安全、STP阻塞状态。很多时候是中间交换机只放通了业务VLAN，忘了放通管理VLAN或VRRP所在VLAN。第四步，回头检查Track和抢占配置是否生效，因为即使原来正常，配置变更时优先级被改掉也可能引出问题。

4.3 链路跟踪失效的几种隐蔽陷阱

我在排障时发现，链路跟踪失效往往不是因为没配，而是配了但没达到预期。第一个陷阱是监控了业务下行口而不是上联口。很多人把Track挂到接用户的下联口上，下联口断说明用户侧断了，这跟上联出口一点关系都没有，当然不会触发切换。第二个陷阱是监控了聚合口成员而不是聚合口本身。上行口如果是以太网聚合Eth-Trunk，你需要track Eth-Trunk接口，而不是随便选了其中一个成员口；只track成员口，成员口down时聚合口可能还有别的成员在工作，业务没断，优先级却被误降了，从而引发无谓切换。第三个陷阱是设备上开了抢占但抢占延时被设得极大，比如60秒，故障后切换确实会发生，但业务已经中断了一分钟，看起来像没生效。第四个陷阱是主备优先级差和降值设计成“刚好”，比如降值等于差值，两个数值一样时VRRP会通过IP地址大小来破平，结果不可控，可能导致备设备抢不过主设备或者角色反转不彻底。把这些陷阱写进你的检查清单，能省下不少凌晨的排障时间。

4.4 脑裂故障排查速查表

表格只是速查，千万别对着表格瞎改配置。每一个现象都要配合状态显示和抓包去验证，改完一项再回归一项，别一次性动多个参数。

5. 高可用网络不是配个VRRP就完事，架构还要这样搭

5.1 链路跟踪只解决局部问题，别当万金油

链路跟踪是个好功能，但它解决的始终是“主设备活着但路径废了”这一种故障模式。VRRP脑裂可能来自保活链路断裂，上联故障可能来自对端设备掉线，业务中断还可能来自一次STP收敛、一次路由振荡、甚至一次下联聚合口的闪断。指望一条Track解决所有问题，是不现实的。我在实际网络里看到不少反例：大家把注意力全放在VRRP高可用上，结果两台核心在同一个机柜里，电源取自同一个PDU，空调上方漏水直接一起泡了，这种架构上的单点，任何协议都救不回来。

所以做高可用网络，格局要大一点。VRRP只是网关层面的手段，你还需要考虑链路冗余、设备冗余、路由协议、监控告警和故障演练。链路跟踪的价值是能把“路径感知”嵌入到VRRP切换逻辑里，让网关具备最基本的自愈能力，但它不应该代替你思考：备份设备的上联链路是否真的可用？主备之间的心跳链路是否够独立？万一网络出现环路或组播风暴，VRRP会不会被波及？

5.2 上行链路的冗余设计，比延长探测时间更重要

如果你的主备两台核心共用一条上联光缆，那链路跟踪配置得再完美也只是心理安慰。因为无论谁当Master，上联一旦断掉，虚拟IP都会落在一个没有出口的设备上。可靠的架构建议做到几件事：第一，主备设备各自独立上联到不同的出口设备，物理路径也分开，避免同沟同管导致的光缆单点。第二，核心到出口路由器之间不要只靠一条静态默认路由，有条件的话启用OSPF或者BGP，跟Track联动，让路由协议自己去感知路径故障。第三，接入侧要避免把主要的业务流量全部压在一条链路里，用多链路上联并开启聚合，配合生成树协议做冗余。第四，主备两台核心之间的心跳链路要尽量独立，最好单独使用一个VLAN并且不做任何策略控制，保证VRRP报文优先互通。

有人为了减少切换频率，会把抢占延时调到很大甚至关掉抢占。这不是高可用的思路，而是把故障时间人为拉长。真正靠谱的做法是：用BFD加快故障检测，用合理的抢占延时过滤抖动，保证主备切换“该快的时候快，该稳的时候稳”。

5.3 快速检测、抢占策略与状态监控要成套

最后说三个必须配套起来的东西。快速检测层面，我建议主干链路的BFD检测时间设置在300毫秒左右，配合VRRP通告间隔，让端到端故障的感知时间控制在秒级以内。抢占策略层面，两台设备都要开启抢占，但主备使用不同的抢占延时，主设备可以设长一点比如30秒，备设备设短一点比如5秒，这样主设备在链路恢复后能重新夺回主角色，而不会和备份设备在恢复瞬间来回扯皮。状态监控层面，SNMP或专用巡检脚本最少要采集三个指标：VRRP状态是否双Master、Track状态是否异常、Master角色在24小时内切换次数。哪一项异常，都需要立即告警。巡检脚本几十行就能搞定，但很多团队懒得上，结果脑裂发生了一个多小时才被用户投诉炸出来，这是最不该发生的。

我自己的习惯是，每次新上线一个VRRP+Track组网，都会把标准故障演练做一遍：先模拟上行接口down，再模拟对端设备不可达，再模拟主备心跳中断，记录每次的切换时间、丢包数和日志输出。基线数据留着，后续任何一次配置变更都能对照着快速判断有没有引入新问题。高可用不是配置完那一刻的事，而是每一次变更、每一次演练积累出来的可信度。

最后说一点个人体会。VRRP链路跟踪不是一个冷冰冰的命令，它本质上是在回答一个问题：这台设备就算活着，还该不该继续当家做主。回答这个问题，需要把物理链路、对端可达性、优先级、抢占延时和监控全部串起来，缺一个都可能在实际故障时掉链子。我做排障这些年，见过太多配置完VRRP就高枕无忧，最后被一个上联口抖动打脸的案例。希望这篇文章里的原理和排障细节，能在你下次改配置之前，先帮你把“该不该切换”这件事想清楚。