★ FEATURED ARTICLE 做网络这么多年网关冗余这事儿一直是割接和运维里绕不开的坎。设备再稳也怕板卡故障或者上联中断一旦终端网关失效整片业务直接就哑了。VRRP虚拟路由冗余协议就是用来填这个坑的标准方案我这次完整跑了一遍实验把配置、验证、故障切换的细节都做了记录这篇就是完整的实验复盘。如果你是刚接触网络的新人或者正准备在现网部署网关冗余这篇内容可以直接拿来做参考。我尽量把每一步的原理和操作意图都说清楚包括那些配置手册上不会写的坑。1. 实验设计思路与网络拓扑规划1.1 为什么要做VRRP实验网关单点故障的真实痛点先说场景。一个典型的三层组网里终端默认网关一般指向核心设备的接口地址。如果只有一台设备承担网关那这台设备一旦重启、板卡故障或者上联链路中断所有依赖这个网关的终端都会断网。很多小规模网络为了省成本就只放一台核心出问题只能干等设备恢复业务中断时间完全不可控。VRRP的设计目标很明确把多台设备“虚拟”成一个网关终端看到的网关地址是一个虚拟IP实际由其中一台设备Master转发流量另一台或多台设备Backup在Master故障时无缝接替。这个“无缝”并不是绝对意义但切换时间通常可以控制在秒级甚至毫秒级比人工介入快得多。所以实验的核心价值不是“配好能通”而是搞清楚三件事虚拟IP和虚拟MAC是怎么工作的、Master和Backup之间靠什么协议报文维持状态、故障发生时切换和回切的行为到底受哪些参数影响。1.2 实验拓扑两台三层设备做VRRP组这次实验我用了两台三层交换机做网关冗余下接一台二层交换机挂两台PC终端。拓扑结构不复杂但足以验证VRRP的所有核心行为。设备A和设备B分别是两台三层交换机互连接口走三层链路同一个广播域设备A的接口地址规划为192.168.10.2/24设备B为192.168.10.3/24VRRP虚拟组规划为组10虚拟IP为192.168.10.1/24设备A设置优先级120作为Master设备B保持默认优先级100作为Backup终端PC1和PC2的网关都指向192.168.10.1这个设计是典型的“一主一备”模型。有人会问为什么不直接把设备A的物理接口地址192.168.10.2直接配成终端网关因为物理接口挂了网关就没了虚拟IP存在的意义就是网关地址与物理设备解耦。需要注意虚拟IP不能和任何一台设备的物理接口IP重复否则会造成地址冲突。1.3 设备选型和模拟环境说明实验环境可以在真实设备上做也可以用网络模拟器完成。我用的是模拟器环境原因很简单可以随时抓包、反复修改配置测试故障场景而且不会因为误操作影响现网。模拟器对VRRP协议的支持已经相当成熟实验结论可以直接迁移到真实设备。如果手头有真机建议优先用真机跑一遍毕竟真实设备的转发时延、CPU处理能力、协议报文交互的时序都和模拟器有差异。但作为学习和验证场景模拟器足够。2. VRRP核心原理拆解协议机制和参数计算2.1 虚拟IP与虚拟MAC的关系VRRP组会生成一个虚拟MAC地址。标准格式是00-00-5E-00-01-XX其中XX是VRIDVRRP组号的十六进制表示。比如VRID为10虚拟MAC就是00-00-5E-00-01-0A。这个虚拟MAC是终端ARP解析的关键。终端要访问网关时发送ARP请求询问192.168.10.1对应的MAC地址Master设备会响应这个虚拟MAC。这样终端数据帧的目的MAC就是虚拟MAC不管实际转发的是哪台设备二层封装始终不变这就是终端无感知切换的基础。需要注意不同厂商对虚拟MAC的格式定义完全一致因为VRRP是IETF标准协议RFC 3768后续更新为RFC 5798这一点比某些私有协议更有优势跨厂商设备也能组成VRRP组。2.2 VRRP报文与状态机Master和Backup的博弈VRRP报文是IP协议号112的报文目的地址是组播224.0.0.18TTL固定为255。设备通过周期性地发送VRRP通告报文来宣告自己的存活状态。默认通告间隔是1秒。Master每隔1秒发送一次通告Backup接收通告后启动一个Master_Down定时器通常为3倍通告间隔即3秒。如果Backup在3秒内没有收到Master的通告就认为Master故障自己切换为Master。这里有个容易被忽视的细节通告间隔越大消耗的带宽越小但故障切换时间越长。如果现网对切换时间有要求可以通过调整通告间隔来优化。VRRPv3还支持毫秒级通告间隔但过小的间隔会占用设备CPU资源需要权衡。状态机有三种Initialize初始状态、Master主状态、Backup备份状态。设备刚配置VRRP时进入Initialize等待接口UP然后根据优先级选举决定进入Master还是Backup。2.3 优先级与抢占主备是怎么选出来的VRRP优先级范围是1到254数值越大越优先。默认优先级是100通过手动配置可以把某台设备抬高。选举规则简单粗暴优先级高的成为Master如果优先级相同则接口IP地址大的成为Master。比如设备A地址是192.168.10.2设备B是192.168.10.3优先级相同的情况下设备B会赢得选举这一点经常有人搞反。抢占模式默认开启。抢占的意思是如果当前Master的优先级低于另一台Backup优先级高的Backup会主动抢占成为Master。这个特性在生产环境里要小心使用配合上行链路监测时容易造成主备频繁切换。2.4 定时器计算与切换时间评估假设通告间隔为1秒Master_Down定时器 3 × 通告间隔 3秒加上报文发送周期的偏差实际故障感知时间通常在3到4秒之间切换完成后终端ARP缓存中的虚拟IP对应虚拟MAC不变因此无需重新学习ARP流量自动切换到新Master如果希望切换更快可以把通告间隔调到200ms0.2秒Master_Down定时器变为0.6秒。但要注意设备CPU需要处理更频繁的报文且网络拥塞时可能因报文丢失导致误切换。我的建议是生产环境保持默认除非业务有明确的秒级切换SLA要求再做调优。3. 实验环境准备与VRRP配置实操3.1 基础配置接口、VLAN和终端网关先把基础网络打通。设备A和设备B接入二层交换机终端PC也接入同一VLAN。这里的关键是确保两台三层设备的VRRP接口处于同一个二层广播域否则VRRP报文无法正常交互。接口地址配置如下以设备A为例命令风格以某主流厂商为准各厂商命令略有差异但思路一致interface Vlanif10 ip address 192.168.10.2 255.255.255.0设备B的Vlanif10地址配置为192.168.10.3/24。终端PC的网关指向192.168.10.1。基础配置完成后先验证终端之间的三层互通。如果VRRP还没配置终端网关指向物理接口地址也能通但只有配置VRRP后网关才具备冗余能力。3.2 配置VRRP组主设备和备用设备设备A配置VRRP组10虚拟IP为192.168.10.1优先级设为120interface Vlanif10 vrrp vrid 10 virtual-ip 192.168.10.1 vrrp vrid 10 priority 120 vrrp vrid 10 preempt-mode timer delay 0设备B配置同一个VRRP组10使用默认优先级interface Vlanif10 vrrp vrid 10 virtual-ip 192.168.10.1注意两台设备的VRID、虚拟IP必须完全一致否则不会形成同一个VRRP组。虚拟IP配置后接口地址不用再手动添加虚拟IP作为从地址协议会自动处理。配置完成后查看VRRP状态。设备A应该显示Master设备B显示Backupdisplay vrrp正常输出里可以看到VRRP组10的状态、Master设备的实际IP、优先级、抢占模式等信息。3.3 验证终端与网关从终端视角看VRRP终端PC1上查看ARP表网关192.168.10.1对应的MAC应该是虚拟MAC。在命令行下执行arp -a可以看到192.168.10.1对应的MAC形如00-00-5e-00-01-0a。这个MAC就是VRRP虚拟MAC跟实际Master设备的物理接口MAC完全不同。然后用终端持续Ping虚拟网关或者外网地址观察丢包情况。正常稳态下Ping应该零丢包。3.4 配置抓包观察VRRP报文为了更直观地理解VRRP的工作过程我在设备接口上做了抓包。抓包关键点目的地址224.0.0.18的组播报文就是VRRP通告协议字段为112报文中包含VRID、优先级、虚拟IP等信息可以实时观察到Master状态变化捕获到正常情况下Master每1秒发送一个通告报文。如果直接看报文内容能发现通告报文的源MAC就是虚拟MAC这就是为什么终端不需要感知Master切换。4. 故障切换与回切测试实录4.1 Master故障模拟拔线断网模拟故障最直接的办法是把设备A的Vlanif10接口强制关闭interface Vlanif10 shutdown接口DOWN后设备A立即停止发送VRRP通告。设备B在Master_Down定时器超时后将状态从Backup切换为Master开始转发虚拟IP的流量。我在终端上持续Ping虚拟网关观察切换过程中的丢包情况。实测结果终端持续Ping切换发生时出现约3到4个丢包对应Master_Down定时器的3秒等待时间。切换完成后Ping恢复无需在终端做任何操作。这个结果符合预期也验证了切换时间主要由Master_Down定时器决定而不是设备转发性能。4.2 Master恢复回切抢占模式的关键行为故障恢复测试重新打开设备A的接口interface Vlanif10 undo shutdown因为设备A配置了优先级120且抢占模式默认开启所以设备A接口UP后立即抢占成为Master设备B退回Backup。在实际操作中端口恢复后接口需要经历UP和路由收敛过程VRRP抢占会稍微延迟但基本是秒级完成。终端再次Ping虚拟网关整个过程没有丢包因为Master切换时虚拟MAC没有变化终端的ARP缓存和流量转发路径无需更新。这里要重点讲一下抢占模式的坑。如果设备A没有开启抢占模式或者配置了关闭抢占那么设备A恢复后不会自动夺回Master地位设备B会一直保持Master直到它故障或重启。这在某些场景下是故意的设计——避免主备频繁切换导致网络震荡但在另一些场景下会造成流量路径不符合预期。配置前一定要和现网规划对齐。4.3 上行链路故障只断上联不断接口更贴近现网的一种故障设备A的上联链路中断但设备A本身接口还是UP状态。这种情况下设备A仍然是Master但流量其实已经无法转发到上游。VRRP标准协议本身并不能感知这种“接口UP但实际不可用”的状态需要依赖联动功能。常用的方案是配置上行链路监测监控上联接口或特定IP的可达性一旦异常自动降低本设备VRRP优先级让Backup抢占为Master。部分厂商的实现是配置一个“降低优先级”的阈值比如降低40interface Vlanif10 vrrp vrid 10 track interface GigabitEthernet0/0/0 reduced 40如果上联接口DOWN设备A的优先级从120降到80低于设备B的100设备B抢占成为Master。这种设计能真正做到“上联故障自愈”而不仅仅是“设备故障自愈”。4.4 主备同时故障的脑裂防护VRRP还有一个重要特性即使出现极端情况比如Master和Backup之间的链路中断导致双方互相收不到通告也只会出现状态翻转不会出现双主同时转发冲突。因为VRRP报文的目的MAC和IP是组播地址同一广播域内的设备都能收到如果链路断了双方都会认为对方故障但只有优先级高的会先变成Master优先级低的退让。不过在部分厂商实现中如果配置了不同VRID的VRRP组或者使用了不同认证方式就可能在同一个广播域里出现双主这种属于配置错误需要靠规范化配置来避免。5. 常见问题与排查技巧实录5.1 两台设备都显示Master双主故障这是VRRP配置里最典型的故障现象。可能的原因两台设备没有接入同一个二层广播域VRRP报文互不可达两台设备的VRID不一致形成了两个独立的VRRP组认证配置不一致导致报文被丢弃配置了禁止VRRP报文产生的过滤规则比如接口ACL丢包排查思路先在设备接口下抓包确认能否收到对方的VRRP报文再比对两台设备的VRID、虚拟IP、认证参数。双主故障的危害很大因为两台设备都会响应虚拟IP的ARP请求终端的ARP表会在这两台设备的MAC之间震荡导致流量来回窜动甚至丢包。5.2 VRRP配置正确但终端网关不通终端Ping不通虚拟IP但VRRP状态正常Master和Backup各就各位。参考排查路径检查Master设备是否开启了接口的ARP代理或本地代理功能有些情况下需要允许VRRP虚拟IP响应ARP检查Master设备的接口是否配置了过滤策略比如端口安全或MAC过滤可能把虚拟MAC过滤掉了检查终端侧ARP确认学到的是虚拟MAC而非其他设备的物理MAC有一次我排查了很久最后发现是Master设备接口上配置了严格的入方向ACL把VRRP报文也过滤掉了。这种问题链路状态完全正常不看报文根本发现不了。5.3 抢占配置引发的频繁切换现网部署了VRRP后主备可能频繁切换终端侧表现为间歇性丢包或延迟波动。常见原因是上行链路监测的阈值设置太敏感接口短时抖动就触发优先级降低通告间隔配置过小网络拥塞导致通告丢失两台设备的优先级差距太小链路微抖就导致选举结果翻转我的经验优先级差建议在20以上避免微小波动引发主备交替上行链路监测要加延迟抑制比如连续3次检测失败才降低优先级同时设置回切延迟防止接口恢复瞬间立刻抢占。5.4 虚拟IP冲突与误配置如果把虚拟IP配置成了某台物理设备的接口地址或者被DHCP服务器分配给了终端会造成地址冲突。VRRP的丢包现象会特别诡异——时通时不通。配置前一定要确认虚拟IP是独立地址不能和任何网络设备的接口地址重叠。另外如果网络中还有DHCP服务要把虚拟IP排除出地址池。5.5 常见问题速查表故障现象可能原因排查重点双主状态VRID不一致 / 二层隔离 / 认证不一致抓包确认VRRP报文可达性核对两端配置网关不通但VRRP正常接口过滤策略 / DHCP地址冲突 / ARP学习异常检查ACL、ARP表、终端网关配置主备频繁切换优先级差太小 / 链路监测太敏感拉大优先级差加入抑制与回切延迟切换时间长通告间隔过大调整通告间隔检查设备CPU负载6. 实验总结与经验沉淀6.1 从实验到现网的关键认知这个实验做完我最大的感受是VRRP配置本身不难难点全在对协议细节的理解和故障场景的预判上。从原理层面掌握虚拟IP和虚拟MAC的解耦机制才能理解为什么切换对终端是透明的理解了Master_Down定时器才能解释切换耗时的来源理解了抢占模式才能规划出符合业务预期的故障恢复路径。现网部署VRRP时我一般会额外关注几点虚拟IP要提前规划独立出地址段不和设备接口地址、DHCP地址池重叠主备优先级差距拉大避免因链路抖动造成主备翻转上行链路监测必须配合延迟抑制和回切延迟否则监控接口本身就制造了故障部署前先做故障演练至少覆盖接口故障、上联链路故障、设备重启三种场景6.2 回切时机的一个经验细节再分享一个细节配置抢占模式后主设备恢复时虽然有回切抢占但回切过程并不是瞬时的设备之间交互通告、重新选举需要时间。在PC持续Ping的场景下回切一般不会产生丢包但这取决于VRRP组内是否有其他Backup设备以及终端的TCP连接状态。如果现网有长连接业务比如数据库连接、视频流建议回切操作安排在业务低峰期或者干脆关闭抢占保持当前Master继续转发。这没有标准答案完全看你对业务连续性的定义。6.3 后续扩展方向VRRP的应用可以进一步扩展。比如在多个VRRP组里让两台设备互为Master实现负载均衡或者结合监控和脚本实现故障时的自动告警。如果想深入了解建议从VRRPv2和VRRPv3的报文格式对比入手重点理解IPv6场景下VRRPv3的变化。做实验这件事最大的价值在于把协议从“书本上的定义”变成“自己动手验证过的认知”。如果你也在准备部署网关冗余建议抽一个维护窗口把主备切换、上联故障、设备重启这几个场景逐一跑一遍。现网环境越复杂这种提前演练的价值就越明显。
阅读完成 · 觉得有帮助？
