尧图网页设计 
1. 从单网关痛点说起VRRP的虚拟IP与主备决策机制1.1 单网关断网的现实痛点搞网络的人十有八九都经历过这种场景核心交换机或者出口路由器就一台二层交换机、三层网关全部压在它身上。某天凌晨硬件老化或者配置误操作这台设备一趴窝整个网段的PC全部无网络访问权限终端用户第一反应是报障第二反应是问你为什么连个备用网关都没有。说白了局域网里的终端要上网第一步就是找默认网关。网关一旦不可用不管OSPF、BGP这些路由协议跑得多欢终端侧就是断的。这就是网关冗余存在的根本原因——不是给网络工程师自己看的花架子而是终端用户真正能感知到的可用性指标。VRRPVirtual Router Redundancy Protocol虚拟路由冗余协议就是为了解决这个问题出现的。它把两台或者多台三层设备伪装成一台虚拟路由器对外只暴露一个虚拟IP这个IP就是终端配置的网关地址。底层哪台设备真正干活对终端完全透明。这样任何一台物理设备挂了虚拟网关都由另一台设备顶上终端无感知。1.2 虚拟IP、虚拟MAC与三种角色状态VRRP的核心元素有三个虚拟IPVirtual IP对外提供网关服务的IP地址比如192.168.10.1由VRRP组成员共享。虚拟MACVirtual MACVRRPv2版本固定为00-00-5E-00-01-{VRID}VRRPv3固定为00-00-5E-00-02-{VRID}。这个MAC地址跟着虚拟IP走终端ARP表里看到的网关MAC始终是它不会因为主备切换而变化。VRIDVirtual Router ID虚拟路由器编号范围1到255同一广播域里维护同一个虚拟路由器的设备必须配置相同的VRID。每台参与VRRP的设备有三种角色状态。Initialize是初始状态设备刚启动或者VRRP配置尚未生效时处于这个状态它不会参与任何转发和选举。从Initialize出来之后设备会根据自身优先级和收到的通告报文进入Master或Backup状态。Master是当前真正承担转发任务的设备只有Master会响应虚拟IP的ARP请求、转发发往虚拟MAC的数据帧。Backup是候补它持续监听Master发出的VRRP通告一旦发现Master失联或者收到比自己优先级更高且开启抢占的Master通告就会升级为Master。1.3 VRRP报文与主备协商的底层规则VRRP报文是IP协议号112的组播报文组播目的地址是224.0.0.18组播MAC是01-00-5e-00-00-12。Master默认每隔1秒向组播地址发送一次Advertisement通告Backup靠接收通告来确认Master还活着。这里有个很多新手忽略的细节Backup不是说等Master挂了之后立即变成Master而是等一个超时定时器到期。这个定时器叫Master_Down_Timer默认值是3秒计算方式是Master_Down_Timer 3 × Advertisement_Interval Skew_Time其中Skew_Time (256 - Priority) / 256单位是秒。优先级越高Skew_Time越小Backup越早发起切换。也就是说如果你想让某台设备在主设备故障后尽快接管网关就把它优先级调高它在超时竞选中天然占优势。选举规则很简单优先级数值越大越优先范围0到255默认100。255比较特殊它保留给虚拟IP的真实所有者即接口上实际配置了虚拟IP地址的设备它不需要参与选举直接成为Master。优先级0是保留值表示设备放弃选举资格。如果优先级相同则比较接口主IP地址大小大的优先这是RFC规定的tie-breaker。2. 主备模式的反面VRRP负载均衡的真实原理与误区澄清2.1 一台转发一台吃灰主备模式的成本账传统的VRRP部署方式就是主备模式SW1是MasterSW2是Backup。正常运行时所有流量都走SW1SW2只收通告报文数据面完全不干活。很多企业客户采购两台相同规格的核心交换机结果一台在机房里满负荷运转另一台一年到头风扇都不怎么转。这个成本账怎么算都不划算。硬件采购是双份的维护成本是双份的但产出只有一份。更不用说备机长期处于低负载状态电子元器件在温吞水环境下反而更容易出问题——我见过好多次所谓冷备设备在真正需要它接管的时候反而起不来因为它长期不处理数据面流量线卡上积累了未知的软硬件问题关键时刻直接宕机。所以负载均衡这个需求就来了两台设备都花钱了能不能让它们都干活比如VLAN10的流量走SW1转发VLAN20的流量走SW2转发两台设备互为对方的备份。这就是VRRP负载均衡或者说流量分载的本质。2.2 关键澄清VRRP协议本身不做负载均衡这是必须澄清的一个概念误区VRRP协议本身按照RFC 3768和RFC 5798的定义就是一个一主多备的冗余协议协议层面对多台设备同时转发数据并不支持。它不像思科的GLBPGateway Load Balancing Protocol那样在协议层面就通过多个虚拟MAC地址实现多台网关设备同时转发。那么厂商宣传的VRRP负载均衡是怎么来的答案是通过多个VRRP备份组。每台设备在不同的VRRP组里担任Master不同VLAN的用户把网关指向不同VRRP组的虚拟IP这样不同VLAN的流量天然就分流到了不同物理设备上。比如SW1在VRRP组10里是Master、组20里是BackupSW2在组20里是Master、组10里是Backup。VLAN10的PC网关指向组10的虚拟IP流量全部由SW1转发VLAN20的PC网关指向组20的虚拟IP流量全部由SW2转发。如果SW1挂了组10的Master角色由SW2接管VLAN10的流量也跟着切到SW2这就是冗余和负载均衡的结合。2.3 多备份组分担让两台设备同时干活的思路用多VRRP组做负载分担核心是做好网段划分。原则很简单把用户VLAN尽量平均地分配到两台设备上让每台设备的转发量大致均衡。比如一个园区有8个用户VLAN就让SW1做VLAN10到VLAN50的主MasterSW2做VLAN60到VLAN80的主Master。不过要注意VRRP负载分担的关键在于分组设计而不是堆配置。我见过一些人把同一个VLAN里的两个网段分别指向两个不同的虚拟IP结果网关不在同一台设备上跨网段访问对端VLAN时绕了一圈才到达排错的时候把自己都绕晕了。正确的思路是一个VLAN的终端只面向一个虚拟网关负载分担的单位是VLAN组而不是网段。配合上要打好两台设备之间必须保证二层互通VRRP通告报文要能互相收到其次所有VRRP组使用的虚拟IP必须避免和组内设备接口真实IP冲突最后如果设备有多个VRRP组每个组的VRID要全局唯一不能两台设备在同一个VLAN里用相同VRID配置不同虚拟IP这会造成虚拟IP冲突。3. 双VLAN双核心实例华为VRRP负载分担配置与验证3.1 拓扑与地址规划我用一个非常典型的双核心场景来演示。SW1和SW2是两台三层交换机作为整个园区的网关层。下面是VLAN10办公网段192.168.10.0/24和VLAN20服务器网段192.168.20.0/24。两台交换机之间有一条Trunk链路专门用于传递VRRP通告和VLAN间互访流量。规划如下项目VLAN 10VLAN 20用户网段192.168.10.0/24192.168.20.0/24虚拟网关IP192.168.10.1192.168.20.1SW1接口IP192.168.10.2192.168.20.2SW2接口IP192.168.10.3192.168.20.3VRRP组编号VRID 10VRID 20SW1角色Master优先级120Backup优先级100SW2角色Backup优先级100Master优先级120这个规划的精髓在于每个VLAN只在其中一台设备上主导转发另一台设备作为该VLAN的备份。VLAN10的流量正常情况下全走SW1VLAN20全走SW2物理上实现了流量分载。3.2 交换机关键配置先看SW1的核心配置。我以华为V200R系列VRP的命令行举例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 vrrp vrid 10 track interface GigabitEthernet0/0/1 reduced 30 interface Vlanif20 ip address 192.168.20.2 255.255.255.0 vrrp vrid 20 virtual-ip 192.168.20.1SW2的配置正好对称interface Vlanif10 ip address 192.168.10.3 255.255.255.0 vrrp vrid 10 virtual-ip 192.168.10.1 interface Vlanif20 ip address 192.168.20.3 255.255.255.0 vrrp vrid 20 virtual-ip 192.168.20.1 vrrp vrid 20 priority 120 vrrp vrid 20 preempt-mode timer delay 20 vrrp vrid 20 track interface GigabitEthernet0/0/2 reduced 30解释几个关键配置的选择。VRID是虚拟路由器编号必须与所在VLAN对应关系固定SW1和SW2在Vlanif10上都用VRID 10虚拟IP都是192.168.10.1这是同一台虚拟路由器的必要条件。优先级设成120高于默认的100确保SW1在正常情况下是VLAN 10的Master。preempt-mode timer delay 20我认为是生产环境必配的。默认情况下华为设备抢占延时为0秒也就是说高优先级设备一旦恢复就立刻抢回Master角色。如果设备刚恢复、VLANIF接口刚起、路由表还没完全收敛这时候抢回Master会造成一次不必要的流量闪断。配置20秒抢占延时给新恢复的设备留出稳定时间。track interface的配置是为了处理接口物理Down但设备本身还活着的场景。比如SW1的上行接口GigabitEthernet0/0/1挂了VRRP通告照常发但它已经失去了到出口的路径终端流量进来也是黑洞。Track检测到接口Down后把优先级降30SW1在VLAN10里从120降到90SW2的100就赢了触发切换流量改由SW2转发。这个机制实际比单纯检测设备故障要重要得多。3.3 配置后验证与流量路径分析配置完成后先看VRRP状态display vrrp brief在SW1上应该看到VRID 10处于MasterVRID 20处于BackupSW2恰好相反。再看主机侧PC ping网关192.168.10.1能通arp看网关MAC是00-00-5e-00-01-0a末尾的0a就是VRID 10的十六进制表示。验证流量的分载效果可以分别在SW1和SW2上看接口流量计数。VLAN10的PC持续下载SW1对应的接口流量明显增长VLAN20的PC持续下载增长的是SW2接口。这就是不同用户的流量走向各自对应的Master设备的直观证据。如果VLAN20的PC ping不通网关先不要查主机先上交换机display vrrp brief确认VRID 20在SW2上是Master。如果发现两台设备在同一个VRID上都是Master几乎可以断定是组播报文或二层路径有问题优先排查Trunk链路VLAN放行和PVID配置。4. 故障切换实战优先级、抢占延时与上行链路监测4.1 从Master Down到新Master的切换过程主设备真正故障时切换是这样发生的Backup设备持续监听Master的通告假设通告间隔是1秒Backup的Master_Down_Timer就是3秒加Skew_Time。3秒内一个VRRP通告都没收到Backup就认为Master失联状态迁到Master然后发送免费ARP通告全网让所有终端的ARP表里网关MAC更新到新Master的虚拟MAC。需要注意的是这个3秒对于用户来说是可以感知的。终端ping网关时切网瞬间会丢两三个包这是VRRP机制本身正常的切换代价。如果业务对丢包零容忍就要考虑BFD联动加速或者把通告间隔调小。华为设备可以通过vrrp vrid 10 timer advertise 200把通告间隔设为200毫秒但要求同组所有设备配置一致并且组播报文的处理会增加CPU开销网络规模很大的时候要谨慎使用。还有一个容易被忽略的点主设备重启恢复后因为preempt-mode timer delay设置了20秒延时它不会立刻抢回Master。这期间流量继续由备设备转发两台设备的状态保持不变。20秒到期后主设备发一个高优先级通告备设备收到后知道有更优设备自动降级为Backup主设备接管。这就是抢占延时的实际作用避免设备刚上电还没完全就绪时抢活干。4.2 上行链路失效基础VRRP兜不住的真实场景基础VRRP只能解决设备整机故障的问题解决不了链路故障的问题。这个坑我踩过也看别人踩过。典型场景SW1是Master它的上行口连核心路由器某天光纤被施工队挖断了但SW1本身运行正常VRRP通告照发它依然是VLAN10的Master。此时终端流量依然通过SW1转发可SW1没有上行路径了出网流量直接黑洞。用户感知是网关通Internet不通。这就必须靠第3节提到的Track机制来补位。当Track检测到上行接口Down时SW1在VRRP组里的优先级下降SW2自动接管。这里有个设计要点Track的检测对象最好是上行物理接口但如果上行是聚合口应该Track Eth-Trunk而不是单个成员口否则一个成员口Down就触发降级会造成不必要的切换。在更高要求的场景下Track接口可能还不足够因为接口Up但路由不可达也是可能发生的。这时可以用BFD双向转发检测联动VRRP让VRRP跟踪BFD会话状态。BFD能快速检测到链路故障或邻居不可达比单纯接口状态检测更灵敏。4.3 Track接口联动与快速收敛配置华为设备上Track接口联动的完整链路是这样的interface Vlanif10 vrrp vrid 10 track interface GigabitEthernet0/0/1 reduced 30这条命令的意思是当GigabitEthernet0/0/1协议状态Down时VRRP组10的本机优先级降低30。原优先级120降到90对端Backup的100自然胜出无需修改对端任何配置就可以完成切换。反之对端要担任VLAN20的Master同样通过Track自己的上行接口降低优先级来倒换。注意一个细节两台设备不要Track同一个上行接口否则上行一断两台设备优先级都降到底谁是Master取决于降低之后的数值大小极容易出现A降完比B高、B降完比A高的跷跷板抖动。每台设备Track自己的上行链路是最稳妥的工程实践。还有一个实用技巧切换是否真的发生可以从设备日志里看。华为设备在VRRP角色变化时会打出VRRP的状态转换日志比如VRID 10, Interface Vlanif10: Backup - Master我在实际运维里经常用这些日志做切换次数的统计评估网络稳定性。如果一台设备的VRRP角色一天切换十几次八成是链路质量差、接口频繁Up/Down导致优先级反复变动这时候要先修基础链路而不是调VRRP参数。5. 与OSPF、MSTP的组网协作园区冗余的完整拼图5.1 三层路由冗余OSPF等开销负载均衡与VRRP如何分工成熟园区的网络架构不会只有VRRP一层冗余通常是接入-汇聚-核心三层结构汇聚设备上跑VRRP提供网关冗余汇聚与核心之间跑OSPF提供路由冗余。这里要分清两者负责的层次。VRRP负责的是终端到网关这一段解决的是终端默认网关的高可用OSPF负责的是网关到核心这一段解决的是三层路由路径的高可用和等开销负载均衡。OSPF默认支持ECMPEqual-Cost Multi-Path当汇聚设备到核心有两条等价开销的链路时OSPF会自动把流量负载分担到两条链路上这就是热词里等开销负载均衡的含义。实际组网中汇聚设备通常双上联到两台核心形成两条等价路径。OSPF在这两条路径上建立邻居路由表里出现两条等价路由O 192.168.0.0/16 [110/2] via 10.0.0.1, GigabitEthernet0/0/1 [110/2] via 10.0.0.2, GigabitEthernet0/0/2这种情况下从汇聚出去的流量自动被OSPF在两条上行链路上做逐流负载均衡这是分载在路由层面的实现。VRRP负责的分载则在网关层面——不同VLAN的流量先由不同的VRRP Master设备接收再各走各的上行路径两台汇聚设备都处于工作状态。5.2 二层防环MSTP与VRRP主备角色的一致性设计二层网络中MSTP和VRRP是一对必须协同工作的协议。MSTP负责解决二层环路VRRP负责网关冗余但如果两者的主角色不一致网络会出现疑似环路或者报文绕路的问题。举一个实际的坑SW1是VRRP的Master但MSTP的根桥在SW2SW1到接入交换机的某个端口被MSTP阻塞了。这样VRRP通告报文虽然能从Trunk链路传到SW2但终端访问网关的流量可能会绕路甚至出现部分终端ARP获取不到网关MAC的问题。标准做法是让VRRP的Master设备与MSTP的根桥保持在同一台设备上。华为交换机上可以通过配置生成树根优先级实现把SW1的优先级设为0或4096让它成为根桥同时VRRP的Master也是SW1这样二层转发路径和三层网关路径一致数据不会绕路。在双核心双汇聚下更推荐的做法是使用MSTP的多实例映射把VLAN10映射到实例1VLAN20映射到实例2让SW1是实例1的根、SW2是实例2的根同时VRRP的VRID 10在SW1上Master、VRID 20在SW2上Master。这样每个VLAN的二层转发路径和三层网关主设备一致既破了环又让两台设备都发挥作用还可以为不同业务提供独立的生成树边界。5.3 双核心双汇聚典型架构的行为时序把VRRP、OSPF、MSTP组合到一起最典型的完整架构是这样的接入层交换机双上联到汇聚SW1和SW2汇聚SW1和SW2之间跑MSTP防止接入侧环路同时在Vlanif上跑VRRP提供各VLAN网关汇聚再双上联到核心交换机汇聚与核心之间跑OSPF。正常时刻VLAN10的网关由SW1承担SW1通过OSPF双上行到核心路径A为SW1到核心1路径B为SW1到核心2OSPF做等开销负载均衡。VLAN10终端的第一个报文到SW1后下一跳由OSPF路由表决定两条上行路径轮流走。VLAN20的网关由SW2承担同理负载分担到两个上行路径。如果SW1上行链路全断Track机制让VRID 10的优先级降低SW2接管VLAN10网关。终端流量改为先进SW2再由SW2的OSPF路径上送到核心。此时二层MSTP的实例根桥如果还在SW1就可能出现二次绕路。所以每次变更或割接我建议把VRRP主设备-生成树根桥一致性检查作为一个固定的操作步骤写进方案里。6. 排错清单与选型建议几年实操攒下的经验6.1 五个最容易踩的坑先说排错这些坑我基本都踩过一遍。第一两台设备VRID不一致却配了相同虚拟IP。VRID不一致等于两个独立虚拟路由器各自响应ARP终端网关漂移不定表现为间歇性丢包或不通。检查方法很简单display vrrp看每台设备的VRID和虚拟IP是否一致。第二虚拟IP和接口真实IP网段冲突。比如Vlanif10配置了192.168.10.2虚拟IP却配成192.168.20.1协议能起来但数据转发是乱的。VRRP的虚拟IP必须属于该VLAN接口所在网段并且和接口真实IP不重复。第三交换机之间VRRP通告被ACL过滤或组播被二层隔离。有些安全设备默认会丢弃协议号112的报文需要放行。VLANIF所在的VLAN必须放行两台交换机之间的Trunk链路否则Backup收不到通告三秒后自己变Master直接造成双Master全网网关互搏。第四Track对象选错导致频繁切换。Track了聚合组中某一个成员口结果光纤模块一抖动就降优先级切一次。Track对象应该选择Eth-Trunk逻辑口或上游设备IP可达性用BFD或NQA而不是单个物理口。第五抢占延时没设导致割接失败。我之前做一次核心设备更换新设备上线后立刻抢占Master但当时路由协议还没收敛完全终端上网忽然卡顿。后来在所有VRRP组都配置抢占延时再也没出过这种问题。6.2 什么场景才需要VRRP负载分担不是所有网络都需要VRRP负载分担这个设计是有适用条件的。如果你的两台设备性能差距很大比如一台是新的高端框式一台是旧机利旧强行做负载分担反而造成木桶效应——高性能设备被低性能设备拖累整个网络的转发上限取决于最弱的那台。这时候老老实实做主备让高性能设备承担全部转发旧设备做热备份反而是最优解。如果你的VLAN数量很少比如就两个VLAN用户流量也不大负载分担省下来的那点转发能力对设备来说九牛一毛。这时候追求的不是两台都用上而是配置简单、故障域清晰。主备模式排错直观备机虽然闲着但它的角色定位就是救火队员。真正适合VRRP负载分担的场景有三个特征多VLAN且各VLAN用户量和流量相当、两台设备性能对等、业务对可用性要求高但预算有限不可能再买第三台。比如一个中型园区10个用户VLAN均匀分布两台同型号汇聚交换机VRRP多组负载分担就非常合适——两台都干活互为备份坏任何一台另一台接管全部VLAN网关。6.3 一点收尾建议最后说点实在的。VRRP配置本身不难难的是你怎么设计谁在什么情况下接管谁的网关。每次部署前先把下面的决策表填一遍再动手决策点建议每台设备承担哪些VLAN的主网关按流量预估均分避免一台过载故障检测手段物理口Track优先要求高则加BFD优先级降低幅度确保降级后小于对端优先级留出冗余量抢占延时生产环境至少20秒割接环境建议60秒主设备与根桥一致性必须检查写入割接脚本我在实际运维中体会最深的一点是VRRP负载分担不是配置完就完事的东西。每个季度最好做一次主动切换演练——手动把SW1的VRRP优先级临时调低观察VLAN10流量是否平滑切到SW2业务侧是否有丢包告警然后再切回来。演练过几次之后你才能真正相信这套冗余机制是可靠的而不是机房里躺着两台看起来很安全的设备。如果后续还想继续深挖可以在这个架构上叠加出口多链路负载均衡、应用层健康检查联动VRRP这些更进阶的玩法。但万变不离其宗先把VRRP分组设计、故障倒换链路、与路由协议的一致性这几件事做扎实园区网络的网关冗余和流量分载就稳了。 VRRP负载均衡与网关冗余实战：从原理到华为配置
1. 从单网关痛点说起VRRP的虚拟IP与主备决策机制1.1 单网关断网的现实痛点搞网络的人十有八九都经历过这种场景核心交换机或者出口路由器就一台二层交换机、三层网关全部压在它身上。某天凌晨硬件老化或者配置误操作这台设备一趴窝整个网段的PC全部无网络访问权限终端用户第一反应是报障第二反应是问你为什么连个备用网关都没有。说白了局域网里的终端要上网第一步就是找默认网关。网关一旦不可用不管OSPF、BGP这些路由协议跑得多欢终端侧就是断的。这就是网关冗余存在的根本原因——不是给网络工程师自己看的花架子而是终端用户真正能感知到的可用性指标。VRRPVirtual Router Redundancy Protocol虚拟路由冗余协议就是为了解决这个问题出现的。它把两台或者多台三层设备伪装成一台虚拟路由器对外只暴露一个虚拟IP这个IP就是终端配置的网关地址。底层哪台设备真正干活对终端完全透明。这样任何一台物理设备挂了虚拟网关都由另一台设备顶上终端无感知。1.2 虚拟IP、虚拟MAC与三种角色状态VRRP的核心元素有三个虚拟IPVirtual IP对外提供网关服务的IP地址比如192.168.10.1由VRRP组成员共享。虚拟MACVirtual MACVRRPv2版本固定为00-00-5E-00-01-{VRID}VRRPv3固定为00-00-5E-00-02-{VRID}。这个MAC地址跟着虚拟IP走终端ARP表里看到的网关MAC始终是它不会因为主备切换而变化。VRIDVirtual Router ID虚拟路由器编号范围1到255同一广播域里维护同一个虚拟路由器的设备必须配置相同的VRID。每台参与VRRP的设备有三种角色状态。Initialize是初始状态设备刚启动或者VRRP配置尚未生效时处于这个状态它不会参与任何转发和选举。从Initialize出来之后设备会根据自身优先级和收到的通告报文进入Master或Backup状态。Master是当前真正承担转发任务的设备只有Master会响应虚拟IP的ARP请求、转发发往虚拟MAC的数据帧。Backup是候补它持续监听Master发出的VRRP通告一旦发现Master失联或者收到比自己优先级更高且开启抢占的Master通告就会升级为Master。1.3 VRRP报文与主备协商的底层规则VRRP报文是IP协议号112的组播报文组播目的地址是224.0.0.18组播MAC是01-00-5e-00-00-12。Master默认每隔1秒向组播地址发送一次Advertisement通告Backup靠接收通告来确认Master还活着。这里有个很多新手忽略的细节Backup不是说等Master挂了之后立即变成Master而是等一个超时定时器到期。这个定时器叫Master_Down_Timer默认值是3秒计算方式是Master_Down_Timer 3 × Advertisement_Interval Skew_Time其中Skew_Time (256 - Priority) / 256单位是秒。优先级越高Skew_Time越小Backup越早发起切换。也就是说如果你想让某台设备在主设备故障后尽快接管网关就把它优先级调高它在超时竞选中天然占优势。选举规则很简单优先级数值越大越优先范围0到255默认100。255比较特殊它保留给虚拟IP的真实所有者即接口上实际配置了虚拟IP地址的设备它不需要参与选举直接成为Master。优先级0是保留值表示设备放弃选举资格。如果优先级相同则比较接口主IP地址大小大的优先这是RFC规定的tie-breaker。2. 主备模式的反面VRRP负载均衡的真实原理与误区澄清2.1 一台转发一台吃灰主备模式的成本账传统的VRRP部署方式就是主备模式SW1是MasterSW2是Backup。正常运行时所有流量都走SW1SW2只收通告报文数据面完全不干活。很多企业客户采购两台相同规格的核心交换机结果一台在机房里满负荷运转另一台一年到头风扇都不怎么转。这个成本账怎么算都不划算。硬件采购是双份的维护成本是双份的但产出只有一份。更不用说备机长期处于低负载状态电子元器件在温吞水环境下反而更容易出问题——我见过好多次所谓冷备设备在真正需要它接管的时候反而起不来因为它长期不处理数据面流量线卡上积累了未知的软硬件问题关键时刻直接宕机。所以负载均衡这个需求就来了两台设备都花钱了能不能让它们都干活比如VLAN10的流量走SW1转发VLAN20的流量走SW2转发两台设备互为对方的备份。这就是VRRP负载均衡或者说流量分载的本质。2.2 关键澄清VRRP协议本身不做负载均衡这是必须澄清的一个概念误区VRRP协议本身按照RFC 3768和RFC 5798的定义就是一个一主多备的冗余协议协议层面对多台设备同时转发数据并不支持。它不像思科的GLBPGateway Load Balancing Protocol那样在协议层面就通过多个虚拟MAC地址实现多台网关设备同时转发。那么厂商宣传的VRRP负载均衡是怎么来的答案是通过多个VRRP备份组。每台设备在不同的VRRP组里担任Master不同VLAN的用户把网关指向不同VRRP组的虚拟IP这样不同VLAN的流量天然就分流到了不同物理设备上。比如SW1在VRRP组10里是Master、组20里是BackupSW2在组20里是Master、组10里是Backup。VLAN10的PC网关指向组10的虚拟IP流量全部由SW1转发VLAN20的PC网关指向组20的虚拟IP流量全部由SW2转发。如果SW1挂了组10的Master角色由SW2接管VLAN10的流量也跟着切到SW2这就是冗余和负载均衡的结合。2.3 多备份组分担让两台设备同时干活的思路用多VRRP组做负载分担核心是做好网段划分。原则很简单把用户VLAN尽量平均地分配到两台设备上让每台设备的转发量大致均衡。比如一个园区有8个用户VLAN就让SW1做VLAN10到VLAN50的主MasterSW2做VLAN60到VLAN80的主Master。不过要注意VRRP负载分担的关键在于分组设计而不是堆配置。我见过一些人把同一个VLAN里的两个网段分别指向两个不同的虚拟IP结果网关不在同一台设备上跨网段访问对端VLAN时绕了一圈才到达排错的时候把自己都绕晕了。正确的思路是一个VLAN的终端只面向一个虚拟网关负载分担的单位是VLAN组而不是网段。配合上要打好两台设备之间必须保证二层互通VRRP通告报文要能互相收到其次所有VRRP组使用的虚拟IP必须避免和组内设备接口真实IP冲突最后如果设备有多个VRRP组每个组的VRID要全局唯一不能两台设备在同一个VLAN里用相同VRID配置不同虚拟IP这会造成虚拟IP冲突。3. 双VLAN双核心实例华为VRRP负载分担配置与验证3.1 拓扑与地址规划我用一个非常典型的双核心场景来演示。SW1和SW2是两台三层交换机作为整个园区的网关层。下面是VLAN10办公网段192.168.10.0/24和VLAN20服务器网段192.168.20.0/24。两台交换机之间有一条Trunk链路专门用于传递VRRP通告和VLAN间互访流量。规划如下项目VLAN 10VLAN 20用户网段192.168.10.0/24192.168.20.0/24虚拟网关IP192.168.10.1192.168.20.1SW1接口IP192.168.10.2192.168.20.2SW2接口IP192.168.10.3192.168.20.3VRRP组编号VRID 10VRID 20SW1角色Master优先级120Backup优先级100SW2角色Backup优先级100Master优先级120这个规划的精髓在于每个VLAN只在其中一台设备上主导转发另一台设备作为该VLAN的备份。VLAN10的流量正常情况下全走SW1VLAN20全走SW2物理上实现了流量分载。3.2 交换机关键配置先看SW1的核心配置。我以华为V200R系列VRP的命令行举例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 vrrp vrid 10 track interface GigabitEthernet0/0/1 reduced 30 interface Vlanif20 ip address 192.168.20.2 255.255.255.0 vrrp vrid 20 virtual-ip 192.168.20.1SW2的配置正好对称interface Vlanif10 ip address 192.168.10.3 255.255.255.0 vrrp vrid 10 virtual-ip 192.168.10.1 interface Vlanif20 ip address 192.168.20.3 255.255.255.0 vrrp vrid 20 virtual-ip 192.168.20.1 vrrp vrid 20 priority 120 vrrp vrid 20 preempt-mode timer delay 20 vrrp vrid 20 track interface GigabitEthernet0/0/2 reduced 30解释几个关键配置的选择。VRID是虚拟路由器编号必须与所在VLAN对应关系固定SW1和SW2在Vlanif10上都用VRID 10虚拟IP都是192.168.10.1这是同一台虚拟路由器的必要条件。优先级设成120高于默认的100确保SW1在正常情况下是VLAN 10的Master。preempt-mode timer delay 20我认为是生产环境必配的。默认情况下华为设备抢占延时为0秒也就是说高优先级设备一旦恢复就立刻抢回Master角色。如果设备刚恢复、VLANIF接口刚起、路由表还没完全收敛这时候抢回Master会造成一次不必要的流量闪断。配置20秒抢占延时给新恢复的设备留出稳定时间。track interface的配置是为了处理接口物理Down但设备本身还活着的场景。比如SW1的上行接口GigabitEthernet0/0/1挂了VRRP通告照常发但它已经失去了到出口的路径终端流量进来也是黑洞。Track检测到接口Down后把优先级降30SW1在VLAN10里从120降到90SW2的100就赢了触发切换流量改由SW2转发。这个机制实际比单纯检测设备故障要重要得多。3.3 配置后验证与流量路径分析配置完成后先看VRRP状态display vrrp brief在SW1上应该看到VRID 10处于MasterVRID 20处于BackupSW2恰好相反。再看主机侧PC ping网关192.168.10.1能通arp看网关MAC是00-00-5e-00-01-0a末尾的0a就是VRID 10的十六进制表示。验证流量的分载效果可以分别在SW1和SW2上看接口流量计数。VLAN10的PC持续下载SW1对应的接口流量明显增长VLAN20的PC持续下载增长的是SW2接口。这就是不同用户的流量走向各自对应的Master设备的直观证据。如果VLAN20的PC ping不通网关先不要查主机先上交换机display vrrp brief确认VRID 20在SW2上是Master。如果发现两台设备在同一个VRID上都是Master几乎可以断定是组播报文或二层路径有问题优先排查Trunk链路VLAN放行和PVID配置。4. 故障切换实战优先级、抢占延时与上行链路监测4.1 从Master Down到新Master的切换过程主设备真正故障时切换是这样发生的Backup设备持续监听Master的通告假设通告间隔是1秒Backup的Master_Down_Timer就是3秒加Skew_Time。3秒内一个VRRP通告都没收到Backup就认为Master失联状态迁到Master然后发送免费ARP通告全网让所有终端的ARP表里网关MAC更新到新Master的虚拟MAC。需要注意的是这个3秒对于用户来说是可以感知的。终端ping网关时切网瞬间会丢两三个包这是VRRP机制本身正常的切换代价。如果业务对丢包零容忍就要考虑BFD联动加速或者把通告间隔调小。华为设备可以通过vrrp vrid 10 timer advertise 200把通告间隔设为200毫秒但要求同组所有设备配置一致并且组播报文的处理会增加CPU开销网络规模很大的时候要谨慎使用。还有一个容易被忽略的点主设备重启恢复后因为preempt-mode timer delay设置了20秒延时它不会立刻抢回Master。这期间流量继续由备设备转发两台设备的状态保持不变。20秒到期后主设备发一个高优先级通告备设备收到后知道有更优设备自动降级为Backup主设备接管。这就是抢占延时的实际作用避免设备刚上电还没完全就绪时抢活干。4.2 上行链路失效基础VRRP兜不住的真实场景基础VRRP只能解决设备整机故障的问题解决不了链路故障的问题。这个坑我踩过也看别人踩过。典型场景SW1是Master它的上行口连核心路由器某天光纤被施工队挖断了但SW1本身运行正常VRRP通告照发它依然是VLAN10的Master。此时终端流量依然通过SW1转发可SW1没有上行路径了出网流量直接黑洞。用户感知是网关通Internet不通。这就必须靠第3节提到的Track机制来补位。当Track检测到上行接口Down时SW1在VRRP组里的优先级下降SW2自动接管。这里有个设计要点Track的检测对象最好是上行物理接口但如果上行是聚合口应该Track Eth-Trunk而不是单个成员口否则一个成员口Down就触发降级会造成不必要的切换。在更高要求的场景下Track接口可能还不足够因为接口Up但路由不可达也是可能发生的。这时可以用BFD双向转发检测联动VRRP让VRRP跟踪BFD会话状态。BFD能快速检测到链路故障或邻居不可达比单纯接口状态检测更灵敏。4.3 Track接口联动与快速收敛配置华为设备上Track接口联动的完整链路是这样的interface Vlanif10 vrrp vrid 10 track interface GigabitEthernet0/0/1 reduced 30这条命令的意思是当GigabitEthernet0/0/1协议状态Down时VRRP组10的本机优先级降低30。原优先级120降到90对端Backup的100自然胜出无需修改对端任何配置就可以完成切换。反之对端要担任VLAN20的Master同样通过Track自己的上行接口降低优先级来倒换。注意一个细节两台设备不要Track同一个上行接口否则上行一断两台设备优先级都降到底谁是Master取决于降低之后的数值大小极容易出现A降完比B高、B降完比A高的跷跷板抖动。每台设备Track自己的上行链路是最稳妥的工程实践。还有一个实用技巧切换是否真的发生可以从设备日志里看。华为设备在VRRP角色变化时会打出VRRP的状态转换日志比如VRID 10, Interface Vlanif10: Backup - Master我在实际运维里经常用这些日志做切换次数的统计评估网络稳定性。如果一台设备的VRRP角色一天切换十几次八成是链路质量差、接口频繁Up/Down导致优先级反复变动这时候要先修基础链路而不是调VRRP参数。5. 与OSPF、MSTP的组网协作园区冗余的完整拼图5.1 三层路由冗余OSPF等开销负载均衡与VRRP如何分工成熟园区的网络架构不会只有VRRP一层冗余通常是接入-汇聚-核心三层结构汇聚设备上跑VRRP提供网关冗余汇聚与核心之间跑OSPF提供路由冗余。这里要分清两者负责的层次。VRRP负责的是终端到网关这一段解决的是终端默认网关的高可用OSPF负责的是网关到核心这一段解决的是三层路由路径的高可用和等开销负载均衡。OSPF默认支持ECMPEqual-Cost Multi-Path当汇聚设备到核心有两条等价开销的链路时OSPF会自动把流量负载分担到两条链路上这就是热词里等开销负载均衡的含义。实际组网中汇聚设备通常双上联到两台核心形成两条等价路径。OSPF在这两条路径上建立邻居路由表里出现两条等价路由O 192.168.0.0/16 [110/2] via 10.0.0.1, GigabitEthernet0/0/1 [110/2] via 10.0.0.2, GigabitEthernet0/0/2这种情况下从汇聚出去的流量自动被OSPF在两条上行链路上做逐流负载均衡这是分载在路由层面的实现。VRRP负责的分载则在网关层面——不同VLAN的流量先由不同的VRRP Master设备接收再各走各的上行路径两台汇聚设备都处于工作状态。5.2 二层防环MSTP与VRRP主备角色的一致性设计二层网络中MSTP和VRRP是一对必须协同工作的协议。MSTP负责解决二层环路VRRP负责网关冗余但如果两者的主角色不一致网络会出现疑似环路或者报文绕路的问题。举一个实际的坑SW1是VRRP的Master但MSTP的根桥在SW2SW1到接入交换机的某个端口被MSTP阻塞了。这样VRRP通告报文虽然能从Trunk链路传到SW2但终端访问网关的流量可能会绕路甚至出现部分终端ARP获取不到网关MAC的问题。标准做法是让VRRP的Master设备与MSTP的根桥保持在同一台设备上。华为交换机上可以通过配置生成树根优先级实现把SW1的优先级设为0或4096让它成为根桥同时VRRP的Master也是SW1这样二层转发路径和三层网关路径一致数据不会绕路。在双核心双汇聚下更推荐的做法是使用MSTP的多实例映射把VLAN10映射到实例1VLAN20映射到实例2让SW1是实例1的根、SW2是实例2的根同时VRRP的VRID 10在SW1上Master、VRID 20在SW2上Master。这样每个VLAN的二层转发路径和三层网关主设备一致既破了环又让两台设备都发挥作用还可以为不同业务提供独立的生成树边界。5.3 双核心双汇聚典型架构的行为时序把VRRP、OSPF、MSTP组合到一起最典型的完整架构是这样的接入层交换机双上联到汇聚SW1和SW2汇聚SW1和SW2之间跑MSTP防止接入侧环路同时在Vlanif上跑VRRP提供各VLAN网关汇聚再双上联到核心交换机汇聚与核心之间跑OSPF。正常时刻VLAN10的网关由SW1承担SW1通过OSPF双上行到核心路径A为SW1到核心1路径B为SW1到核心2OSPF做等开销负载均衡。VLAN10终端的第一个报文到SW1后下一跳由OSPF路由表决定两条上行路径轮流走。VLAN20的网关由SW2承担同理负载分担到两个上行路径。如果SW1上行链路全断Track机制让VRID 10的优先级降低SW2接管VLAN10网关。终端流量改为先进SW2再由SW2的OSPF路径上送到核心。此时二层MSTP的实例根桥如果还在SW1就可能出现二次绕路。所以每次变更或割接我建议把VRRP主设备-生成树根桥一致性检查作为一个固定的操作步骤写进方案里。6. 排错清单与选型建议几年实操攒下的经验6.1 五个最容易踩的坑先说排错这些坑我基本都踩过一遍。第一两台设备VRID不一致却配了相同虚拟IP。VRID不一致等于两个独立虚拟路由器各自响应ARP终端网关漂移不定表现为间歇性丢包或不通。检查方法很简单display vrrp看每台设备的VRID和虚拟IP是否一致。第二虚拟IP和接口真实IP网段冲突。比如Vlanif10配置了192.168.10.2虚拟IP却配成192.168.20.1协议能起来但数据转发是乱的。VRRP的虚拟IP必须属于该VLAN接口所在网段并且和接口真实IP不重复。第三交换机之间VRRP通告被ACL过滤或组播被二层隔离。有些安全设备默认会丢弃协议号112的报文需要放行。VLANIF所在的VLAN必须放行两台交换机之间的Trunk链路否则Backup收不到通告三秒后自己变Master直接造成双Master全网网关互搏。第四Track对象选错导致频繁切换。Track了聚合组中某一个成员口结果光纤模块一抖动就降优先级切一次。Track对象应该选择Eth-Trunk逻辑口或上游设备IP可达性用BFD或NQA而不是单个物理口。第五抢占延时没设导致割接失败。我之前做一次核心设备更换新设备上线后立刻抢占Master但当时路由协议还没收敛完全终端上网忽然卡顿。后来在所有VRRP组都配置抢占延时再也没出过这种问题。6.2 什么场景才需要VRRP负载分担不是所有网络都需要VRRP负载分担这个设计是有适用条件的。如果你的两台设备性能差距很大比如一台是新的高端框式一台是旧机利旧强行做负载分担反而造成木桶效应——高性能设备被低性能设备拖累整个网络的转发上限取决于最弱的那台。这时候老老实实做主备让高性能设备承担全部转发旧设备做热备份反而是最优解。如果你的VLAN数量很少比如就两个VLAN用户流量也不大负载分担省下来的那点转发能力对设备来说九牛一毛。这时候追求的不是两台都用上而是配置简单、故障域清晰。主备模式排错直观备机虽然闲着但它的角色定位就是救火队员。真正适合VRRP负载分担的场景有三个特征多VLAN且各VLAN用户量和流量相当、两台设备性能对等、业务对可用性要求高但预算有限不可能再买第三台。比如一个中型园区10个用户VLAN均匀分布两台同型号汇聚交换机VRRP多组负载分担就非常合适——两台都干活互为备份坏任何一台另一台接管全部VLAN网关。6.3 一点收尾建议最后说点实在的。VRRP配置本身不难难的是你怎么设计谁在什么情况下接管谁的网关。每次部署前先把下面的决策表填一遍再动手决策点建议每台设备承担哪些VLAN的主网关按流量预估均分避免一台过载故障检测手段物理口Track优先要求高则加BFD优先级降低幅度确保降级后小于对端优先级留出冗余量抢占延时生产环境至少20秒割接环境建议60秒主设备与根桥一致性必须检查写入割接脚本我在实际运维中体会最深的一点是VRRP负载分担不是配置完就完事的东西。每个季度最好做一次主动切换演练——手动把SW1的VRRP优先级临时调低观察VLAN10流量是否平滑切到SW2业务侧是否有丢包告警然后再切回来。演练过几次之后你才能真正相信这套冗余机制是可靠的而不是机房里躺着两台看起来很安全的设备。如果后续还想继续深挖可以在这个架构上叠加出口多链路负载均衡、应用层健康检查联动VRRP这些更进阶的玩法。但万变不离其宗先把VRRP分组设计、故障倒换链路、与路由协议的一致性这几件事做扎实园区网络的网关冗余和流量分载就稳了。