做网络运维十几年要说最让我心里发毛的故障不是设备烧毁而是所有设备指示灯全亮、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变成DOWNTrack变成DOWNVRRP优先级直接从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/24C1和C2分别用上联口接到出口路由器R1和R2R1和R2再分别接运营商或者防火墙。注意我特意说专用互联链路是因为VRRP报文的安全性优先性很高如果和业务流量挤在同一条很拥塞的链路里可能导致通告丢失进而误切换。当然如果你用的是两台核心之间的物理直连端口性能一般不成问题。这个拓扑里链路跟踪要监控的对象非常明确C1监控自己的上联口去R1的接口C2监控自己的上联口去R2的接口。两者不要搞反更不要监控和对面核心互联的心跳口否则你监控的链路断了恰恰说明心跳也没了这时候再去降低优先级只会让局面更乱。我见过不少把Track挂到心跳口的实例结果心跳抖动一次两台设备来回抢主比不配还惨。3.2 核心交换机上的VRRP加Track配置实例下面以华为VRP设备为例给一套配置。C1上的网关接口配置大概是这样interface Vlanif10ip address 192.168.10.2 255.255.255.0vrrp vrid 10 virtual-ip 192.168.10.1vrrp vrid 10 priority 120vrrp vrid 10 preempt-mode timer delay 20C2上的对应接口配置则是interface Vlanif10ip address 192.168.10.3 255.255.255.0vrrp vrid 10 virtual-ip 192.168.10.1vrrp vrid 10 priority 100vrrp vrid 10 preempt-mode timer delay 20这里我把虚拟IP当成网关VRID选10C1优先级120C2默认100。两台都开启了抢占并且设置了20秒抢占延时目的是防止上联链路抖动时主备角色频繁切换。接着在C1上创建Track监视上联口假设C1的上联口是GigabitEthernet0/0/1track 1 interface GigabitEthernet0/0/1 line-protocol然后在Vlanif10下面把Track绑定到VRRPinterface Vlanif10vrrp 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 脑裂故障排查速查表故障现象可能原因处理建议两台设备都显示Master主备之间VRRP报文不通放通组播、检查Trunk和ACL网关上MAC漂移、时通时断两台设备同时响应虚拟IP先恢复单一Master再排查保活链路上联接口down但VRRP不切换Track未绑定或降低值不够检查track状态、优先级差值、抢占配置切换后马上又切回来上联链路抖动或抢占延时太短加长preempt delay检查物理链路BFDTrack显示down但VRRP没切换Track与VRRP绑定漏配确认vrrp vrid下引用了该Track两台设备都是Backup双侧track同时降级、无人能做主重新设计优先级和降值保证至少一台胜出表格只是速查千万别对着表格瞎改配置。每一个现象都要配合状态显示和抓包去验证改完一项再回归一项别一次性动多个参数。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小时内切换次数。哪一项异常都需要立即告警。巡检脚本几十行就能搞定但很多团队懒得上结果脑裂发生了一个多小时才被用户投诉炸出来这是最不该发生的。我自己的习惯是每次新上线一个VRRPTrack组网都会把标准故障演练做一遍先模拟上行接口down再模拟对端设备不可达再模拟主备心跳中断记录每次的切换时间、丢包数和日志输出。基线数据留着后续任何一次配置变更都能对照着快速判断有没有引入新问题。高可用不是配置完那一刻的事而是每一次变更、每一次演练积累出来的可信度。最后说一点个人体会。VRRP链路跟踪不是一个冷冰冰的命令它本质上是在回答一个问题这台设备就算活着还该不该继续当家做主。回答这个问题需要把物理链路、对端可达性、优先级、抢占延时和监控全部串起来缺一个都可能在实际故障时掉链子。我做排障这些年见过太多配置完VRRP就高枕无忧最后被一个上联口抖动打脸的案例。希望这篇文章里的原理和排障细节能在你下次改配置之前先帮你把“该不该切换”这件事想清楚。