凌晨两点多手机响。接起来是某园区网管打来的语气比窗外温度还低“全楼断网了核心网关设备起不来。”赶到现场那台单跑网关的旧交换机是真的起不来了。这个场景做网络的老哥估计都不陌生——链路层面的冗余做了一大堆汇聚交换机双上联、跨机框堆叠可到头来网关地址就孤零零落在某一台设备上。设备一挂整网瘫痪。那次之后我把园区每个VLAN的网关全部改造了一遍核心用的就是VRRP协议。VRRPVirtual Router Redundancy Protocol虚拟路由冗余协议解决的就是这么一个问题在多个三层设备之间虚拟出一个“共用网关”正常情况下由主设备承担流量主设备故障时备用设备自动接管整个过程对终端完全透明。这篇文章不打算把RFC条文念一遍而是结合我实际部署和踩坑的经验把它怎么工作、怎么配置、哪些地方容易翻车一次讲透。1. 一次断网事故复盘网关为什么成了全网最“单”的点1.1 网络里最常见的隐形单点扯到高可用大多数人的第一反应是链路冗余。两台接入交换机分别上联到两台汇聚链路聚合一打听着挺稳。可往上走到三层就尴尬了一个VLAN的网关地址一般只能配在一个三层接口上。链路没问题但那台设备本身崩溃、重启、电源故障的时候整个VLAN的用户就拿不到默认网关内网通、外网断表现就是“上不了网”。这种故障表现为例恰恰是VRRP协议的典型应用场景三层设备自身失效而不是链路断开。链路断了上层路由协议还能收敛设备死了普通静态默认路由根本没法自动切换。1.2 两台设备不等于双机热备不少人有个误区我机房里放了两台三层交换机一台主一台备这不就是高可用了问题是怎么让备份的那台知道“该我上场了”如果只是把网关配在主设备上备份设备上配个空接口那叫冷备主设备挂了还得人来改配置。VRRP把这些事情自动化了把所有三层设备放进一个虚拟路由器组对外只暴露一个虚拟IP终端把网关指到这个虚拟IP上。主设备周期性地发送VRRP通告报文告诉其他成员“我还活着”。如果备份设备连续一段时间收不到主设备的通告就自动把自己的接口状态提升为主状态开始接管虚拟IP。整个过程对终端无感不需要改任何终端的网关配置。2. VRRP核心原理拆解虚拟IP、状态机与虚拟MAC2.1 虚拟IP网关从“一台设备”变成“一个角色”VRRP协议和HSRP这类私有协议最大的不同在于标准化——它是IETF定义的公开协议不同厂商的设备可以互组VRRP组。一个VRRP组由VRID虚拟路由器ID标识范围1到255每个VRID关联一个虚拟IP。比如VLAN 10的网关是192.168.10.254这个IP可以同时配置在Master设备的物理/逻辑接口上但同一时间真正回包、转发数据的只有一台Master设备。这里有个容易混淆的点VRRP只解决网关冗余不解决路由协议冗余。它本质上是“对默认网关的高可用封装”至于VLAN间路由如何选择路径那是OSPF、BGP这些动态路由协议的事两者各管一段但经常需要配合。2.2 主备状态机Master和Backup的几个关键状态VRRP的状态机并不复杂主要三个状态Initialize、Master、Backup。Initialize设备刚启动或接口还没就绪时的初始状态此时不参与转发。Master当前承担虚拟IP转发职责的设备。它周期性地向组内组播发送VRRP通告报文默认间隔1秒。Backup监听Master通告的设备收到通告后重置定时器不转发虚拟IP的业务流量。一旦超过Master_Down时间一般为3倍通告间隔就切换到Master。这个切换时间就是高可用方案的关键指标。默认配置下Master故障到Backup接管大约需要3秒加上网络设备本身的路由收敛时间整体切换在5秒量级。很多业务对这个中断时间不满意所以后文还会讲到如何用BFD加速。2.3 虚拟MAC和ARP一台“逻辑上存在”的设备怎么工作VRRP的核心机制之一是所有VRRP组成员共享一个虚拟MAC地址。标准规定以VRID生成虚拟MAC形式为00-00-5E-00-01-XXXX为十六进制VRIDVRRP v3还支持IPv6场景下的另一种MAC格式。为什么需要虚拟MAC因为终端发往网关的帧目标MAC必须一致。假设终端发出ARP请求“192.168.10.254的MAC是谁”Master设备会用自己的虚拟MAC来回应而不是物理接口MAC。这样即使Master设备重启Backup接管后继续使用同一个虚拟MAC终端的ARP缓存完全不用刷新对端交换机上的MAC表项也无需重新学习切换对二层网络是平滑的。这一点是VRRP和单纯“把浮动IP在两个设备之间漂移”的实现最大的区别也是实际生产环境能够无感切换的基础。2.4 优先级、抢占与定时器三个必须理解的参数优先级决定谁当Master取值范围1到254默认100。数值越大优先级越高如果组内没有其他成员优先级255的设备可以拥有虚拟IP而且255不参与抢占协商。**抢占模式Preempt**决定备份设备能否在Master恢复后重新夺回Master身份。默认开抢占意味着高优先级备机一旦上线会立刻把Master角色夺回来。这个机制设计初衷是让高配设备回归后恢复设计角色但生产中必须谨慎频繁抢占会导致网关在短时间内切换多次业务抖动一串。很多运维团队直接关掉抢占让当前Master一直跑到故障为止。Master_Down定时器决定切换多快。默认等于3倍通告间隔即3秒。实际网络里我会根据链路质量和冗余需求调低通告间隔到200毫秒左右配合BFD切换时间可以压到1秒内。3. 核心网络VRRP落地配置从设计思路到完整实例3.1 先设计再动手明确主备角色、故障切换范围以某园区网核心为例共两层核心设备记为SW-A、SW-B核心下面挂若干接入交换机业务VLAN网关放在核心上。改造前的默认路由指向出口防火墙。那么VRRP各组的设计思路如下将核心上所有业务VLAN的网关地址迁移为虚拟IP。将SW-A和SW-B分别作为不同VLAN组的Master这叫“负载分担”式设计两个核心都被利用起来而不是白白空闲一台。三层互联部分保留端口IP地址做OSPF动态路由或静态路由配合BFD。注意同样一台物理设备其三层接口可以同时属于多个VRRP组。在VLAN 10组里是Master在VLAN 20组里也可以是Backup这就是VRRP最大的优势之一设备利用率高。3.2 以某主流厂商核心交换机为例的完整配置示例下面用类命令行风格的配置示例来演示关键配置具体语法在不同厂商设备上有差异但逻辑是一致的interface Vlan10 ip address 192.168.10.253/24 vrrp 10 virtual-ip 192.168.10.254 vrrp 10 priority 120 vrrp 10 preempt-mode enable vrrp 10 timers advertise 1SW-B的配置类似但优先级改成默认100且同一VLAN10的VRRP组里虚拟IP相同interface Vlan10 ip address 192.168.10.252/24 vrrp 10 virtual-ip 192.168.10.254 vrrp 10 priority 100 vrrp 10 preempt-mode disable有人会问接口物理IP为什么不用和虚拟IP一样原因很简单虚拟IP是VLAN内终端使用的网关物理IP则用于设备间的路由、网管、管理平面交互。两者可以相同把物理IP直接写成虚拟IP但绝大多数生产环境会分开避免管理流量和设备间流量共用同一个IP排查问题时分不清。配置完成后在终端上用arp -a查看网关地址会看到ARP表项对应的MAC是00-00-5E-00-01-0A假设VRID10而不是SW-A或SW-B的物理MAC。看到这个MAC基本就可以确认VRRP已经在正常工作了。3.3 上联链路故障为什么传统VRRP会失效VRRP只能检测三个层面接口状态、VRRP组内协商状态、以及设备本身死活。它看不到“上联出口链路”。假如SW-A是Master但它的上联防火墙接口光纤断了SW-A的下联VLAN接口仍然是Up的VRRP认为一切正常继续由SW-A承担网关角色。结果就是终端的流量能到达网关但从网关出去的路却断了全网“假活”。这种问题的常规解决方案是VRRP与上行链路状态联动当上行接口Down时自动降低本机VRRP优先级如减去40让对端优先级更高的Backup抢占成为Master。配置要点是把上行物理口加入一个“跟踪对象”优先级下降值需要比对端优先级差距设计否则会切不过去。3.4 结合BFD与静态路由让上行故障在毫秒级被发现更理想的方案是放弃纯静态默认路由核心和出口之间跑OSPF/BGP同时用BFD检测链路。BFD是一种快速检测转发路径的机制检测时间可以做到几百毫秒甚至几十毫秒。配置思路上核心与出口设备之间建立BFD会话。OSPF开BFD联动链路故障时路由秒级收敛。出口方向的路由收敛后整个网络的数据路径从“核心A-出口A”切换到“核心B-出口B”VRRP甚至不需要切换网关角色业务就能恢复。我自己实际调下来BFD单跳检测时间配到300毫秒结合1秒的VRRP通告间隔整网切换基本可以控制在2秒左右比默认的3秒强太多。不过这种优化要谨慎BFD检测太灵敏偶尔的光纤抖动就会触发路由振荡反而影响稳定性。生产环境宁可慢一点也不要天天翻来覆去。4. 版本演进与协议差异从v2到v3、从IPv4到IPv64.1 v2和v3的主要差异VRRP v2是IPv4时代的老版本支持IPv4虚拟IP通告报文默认IPv4组播地址224.0.0.18。VRRP v3则在v2基础上做了几个重要改进同时支持IPv4和IPv6地址IPv6组播地址为FF02::12。通告间隔单位从1秒细化到毫秒级支持更快的切换。对报文格式做了扩展增加了一些可选字段认证功能也有了改进。实际选型上只要设备支持我都会优先用v3即使是纯IPv4环境。原因无他切换速度更快而且在双栈环境下不用以后再做一轮改造。少数老旧型号不支持v3的就只能在v2下工作这时候通告间隔别调太短兼容性问题容易出现。4.2 IPv6场景下的注意点IPv6环境下VRRP v3需要为每个VRRP组同时配置虚拟IPv6地址通常还伴随虚拟链路本地地址。在IPv6双栈网络里终端发出的Router Solicitation消息由Master设备响应从而获得默认网关信息。即使物理设备切换虚拟链路本地地址保持不变终端IPv6的默认路由也不会过期。有个坑值得提醒部分设备在IPv6 VRRP生效时会对接口的ND邻居发现报文处理有一些特殊逻辑如果设备型号较老可能需要额外打开一个“支持IPv6虚拟网关NS/NA报文”的开关否则终端会学到物理接口的IPv6 MAC导致组播地址解析失败。这个故障很隐蔽特征是IPv6地址能Ping通但业务流量走的不是预期路径。遇到这种问题优先查看设备的VRRP v3状态和ND表项。5. 高可用方案里的那些“暗坑”抢占、脑裂与安全问题5.1 抢占模式到底该开还是该关前面提过抢占模式这里再展开讲一下决策逻辑。结论先说无特殊需求建议关闭抢占。为什么设想一个场景SW-A是主设备某次机房改造把SW-A的电源断了一次SW-B接管了网关。等SW-A恢复上线如果开启抢占且SW-A优先级更高它会在启动后夺回Master身份。闸刀切换一次VLAN下的交换机重新学习MAC、终端重新解析ARP表现为网络会有明显的抖动。若网络里有视频会议或语音业务这个瞬间的用户体感就很差了。除非有明确理由让某台设备长期作为主比如主设备性能明显高于备设备或核心业务依赖主设备的某些服务否则我都建议把抢占关掉。主设备起来了之后作为Backup待命等下一次主设备故障再切换。这样至少保证日常网络是稳定的切换次数最小化。5.2 两台设备“看起来都在跑”实际可能是“假高可用”VRRP最怕的是两台设备互相认为自己是Master这种情况称为“VRRP脑裂”。造成脑裂的典型原因是两台设备之间的VRRP组播报文被阻断或者配置了不一致的认证方式导致彼此收不到通告。此时两台设备都用同一个虚拟IP和虚拟MAC对外转发二层交换机MAC表在两个端口间乒乓切换全网丢包率肉眼可见地升高。排查手段并不复杂在两台设备上分别查看VRRP组状态若看到两个Master立刻怀疑通信中断。检查两个三层接口之间是否被防火墙、ACL拦截了组播报文。检查VRRP配置的认证类型和密码是否完全一致包括大小写、超时字符。在接入层抓包看VRRP通告报文的源MAC和到达端口确认通告是否正常收到。生产上防脑裂的根本措施除网络设计外还要确保两台设备间的三层链路是真正冗余的最好有两条以上直连链路避免一条线出问题后VRRP组播直接断掉。5.3 安全与认证VRRP也不是毫无风险这是很多人忽略的一点。VRRP v2的默认认证方式非常弱甚至可以不认证。攻击者如果进入到二层网络可以伪造更高优先级的VRRP通告报文直接把Master角色抢走然后把虚拟IP引导到自己控制的设备上做中间人这是很典型的二层攻击手法。v3干脆移除了简单的明文认证转而使用IPv6的AH认证头或干脆不认证。在实际网络安全加固时通常这样处理在二层交换机上限制VRRP组播报文的来源端口只允许VRRP成员端口收包。在接入交换机端口上开DHCP Snooping和动态ARP检测DAI抵御伪造通告。如果设备支持开启增强认证并配置强密钥。核心设备之间建议使用独立的专用互联VLAN不要和业务VLAN混在一起。不夸张地说网关安全是内网安全非常关键的一层VRRP组播不受控等于给懂点网络的人留了条通往核心的后门。6. 高可用切换验收别等真故障才做第一轮验证6.1 常规测试项目与预期结果改造完VRRP不可能等到半夜断网才知道好不好用。建议按下面清单做一轮灾备演练每项都记录实际切换时间Master设备进程重启手动重启SW-A观察SW-B是否在预期时间3秒内切换为Master虚拟IP是否可达。拔掉Master上联口验证上行联动和BFD是否生效观察出口路由是否切换。拔掉Master下联口验证接口Down对VRRP状态的影响以及Backup接管后二层MAC表是否正常收敛。Master整机断电最贴近真实故障观察业务中断时长和恢复速度。Master重新上线验证抢占关闭情况下SW-A回归后是老老实实当Backup还是去强抢Master。我的实测经验是只要配置合理默认参数下整机断电到业务恢复大约3到5秒如果接入了BFD和路由联动普遍可以压到1到2秒。如果你测出来超过5秒大概率是通告间隔和定时器没有按预期工作或者OSPF消沉太慢需要进一步查。6.2 验收中容易被忽略的三个细节第一切换后一定要去终端上Ping网关和远端地址不要只看VRRP状态变了就算过。很多时候状态已经切过去了但二层MAC表还在老化中首次访问会漂移一下。连续Ping几十次观察丢包率比看状态靠谱得多。第二抓包看虚拟IP是否真的由新Master回应。在Master切换后立即在接入交换机上抓ARP请求和VRRP通告报文确认虚拟MAC和虚IP的应答来自新Master。第三别忽略恢复测试。业务恢复后原Master重新上线。若关闭抢占确认其回到Backup状态不至于再次引发切换若开启抢占则要评估它对业务的影响程度尤其在有语音、视频业务的网络中优先考虑关闭抢占。6.3 日常监控怎么盯VRRP最后说监控。VRRP的高可用状态要纳入日常监控不然哪天设备悄悄切了一次你都不知道等用户投诉才发现。日常我会让人在监控系统里抓这些关键指标每个VRRP组当前Master是谁、状态持续时间。通告报文的接收次数是否稳定是否有超时。虚拟IP的连通性每30秒Ping一次。CPU负载和内存使用率出现异常波动时重点排查。用脚本在核心设备上定期抓show vrrp结果并比对一旦出现“Backup设备长时间收不到Master通告”或“组内出现双Master”立刻告警。这套配合做下来网关侧的故障大多能在用户感知之前就被发现。我个人的体会是VRRP这个东西原理讲起来不难真正的门槛不在配置而在对故障场景的理解深度。多花点时间把状态机、定时器、联动机制吃透再配合几轮故障演练比看多少篇文档都管用。希望这篇从断网教训出发的拆解能帮你把网关冗余这块短板补上。
