ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

VRRP+OSPF双出口负载均衡配置实战与故障排查

2026/10/5 5:08:21 拓冰建站 浏览量
VRRP+OSPF双出口负载均衡配置实战与故障排查 简介针对Jan16公司采用ISP-A、ISP-B双线路接入互联网的出口瓶颈问题这份PDF以项目化方式给出基于VRRP与OSPF从主备切换改造为负载均衡的完整配置方案。文档先说明项目背景与规划再按配置路由器接口、部署OSPF网络、配置VRRP协议、配置上行接口监视、配置部门计算机IP五步展开包含拓扑图说明、IP地址规划表、端口规划表以及华为设备命令行示例。通过创建多个VRRP备份组并为不同部门指定不同虚拟网关可让流量经R1、R2分流配合接口链路状态跟踪在链路故障时自动降低主路由器优先级实现秒级切换兼顾带宽利用与冗余可靠。资源为单个PDF文件压缩包约606KB适合网络管理员、IT运维人员及网络技术学习者用于实战配置参考和排错思路梳理。目前已有150人学习下载对需要解决双出口负载均衡与链路冗余问题的读者具有直接借鉴价值。1. 出口链路负载均衡为什么要同时搬出VRRP和OSPF很多企业出口有两家运营商链路上联是双线的但流量长期只走其中一条另一条闲着。问运维为什么不用起来回答通常是“怕切不动”“不敢动策略”。这个场景里VRRP解决的是网关不丢OSPF解决的是路由跟着链路走两者配合才能让双出口真正变成负载均衡而不是“假装双活”。下面这套配置解析以华为VRP设备为例讲的是一套可在园区网或中小数据中心落地的双出口方案VRRP管用户网关冗余OSPF管出口链路分担与故障切换。适合正在做双出口改造、或已被“主备出口”带宽浪费困扰的运维人员。2. 分工与选型VRRP管网关冗余OSPF管链路均衡2.1 VRRP多实例如何做到网关负载分担先看VRRP的角色。单看一台设备时VRRP的作用是给用户提供一个不随设备故障漂移的虚拟网关。两台设备组成一个VRRP组谁优先级高谁当MasterMaster持有虚拟IP并回应用户的ARP请求Backup在Master故障时接管。但只有一个VRRP组时两台设备永远是一主一备流量全走MasterBackup设备的上联链路完全闲置——这不叫负载均衡。要让两条出口链路都被用起来常见做法是配置多个VRRP实例把不同VLAN的网关角色错开。比如VLAN10的Master是SW-C1VLAN20的Master是SW-C2。这样VLAN10的用户流量进入后走SW-C1的上联出口VLAN20的用户流量由SW-C2转发设备层面的CPU、内存、转发表项和上联带宽都被分摊。这也是标题里“负载均衡”在网关侧的直接体现。VRRP多实例配置不复杂但有两个细节要盯紧。第一是抢占模式默认开启建议一定加抢占延时否则主备之间反复震荡会导致用户网关频繁切换掉线一两秒是常事。第二是虚拟IP必须和用户配置的网关地址一致掩码由接口IP决定不需要也不能在virtual-ip后面再跟掩码。2.2 OSPF ECMP如何让两条出口链路都被用起来VRRP把不同网段的入口流量分开了但出口方向的选路还需要路由协议来管。假设两台出口路由器R-A和R-B分别上联ISP1和ISP2它们都把一条默认路由通告给核心交换机且通告的cost相同核心交换机路由表里就会出现两条等价默认路由下一跳分别是R-A和R-B。OSPF的原生ECMP机制会把流量按哈希分摊到两条链路上任何一条链路或设备故障OSPF会自动撤销或隐藏对应路由另一条立刻接管。这就是标题里“OSPF负责负载均衡”的含义。很多设备默认就开了多路径负载均衡华为交换机路由器的maximum load-balancing默认数值通常是8两条链路等价时不需要额外配置。判断“等开销”的条件有三个前缀相同、cost相同、下一跳不同。缺一个路由表里就只会留一条另一条变成冷备。这也是后面配置章节里我要反复强调cost值的原因。2.3 为什么不推荐只用策略路由替代OSPF做出口选路有同行会问既然要分流直接用策略路由PBR按源地址把VLAN10指到R-A、VLAN20指到R-B不就行了确实能分流但PBR的问题是它不感知链路状态。R-A的上联光缆被挖断策略路由规则还在流量照样往R-A发业务直接黑洞。除非再配一套NQA联动Track去改PBR否则故障自愈能力几乎为零。OSPF的价值恰恰在此路由是协议动态算出来的链路断掉就撤回等价路径自动收敛。PBR适合在OSPF之上做细粒度补充比如某个视频会议网段必须走指定运营商而不是用来替代动态路由。生产环境里我的建议是OSPF做主干选路PBR只做少数例外流量的策略分流。3. 拓扑与配置落地双出口路由器的VRRPOSPF完整命令3.1 地址规划与拓扑配置先看拓扑。本文采用一台出口路由器对应一台核心交换机的串行结构R-A上联ISP1下联SW-C1R-B上联ISP2下联SW-C2SW-C1和SW-C2之间建立三层互联用于VRRP报文传输、OSPF邻居同步以及故障时逃生转发。设备角色关键接口与地址R-A出口路由器A上联ISP1: 100.1.1.2/29下联SW-C1: 10.254.1.2/30R-B出口路由器B上联ISP2: 100.2.2.2/29下联SW-C2: 10.254.2.2/30SW-C1核心交换机1用户VLAN10网关: 10.0.10.252/24上联R-A: 10.254.1.1/30互联SW-C2: 10.254.200.1/30SW-C2核心交换机2用户VLAN20网关: 10.0.20.252/24上联R-B: 10.254.2.1/30互联SW-C1: 10.254.200.2/30R-A和R-B之间加不加互联口取决于你是否需要“跨设备逃生”。如果核心交换机到出口路由器的链路断了但核心交换机本身没故障VRRP不感知此时必须有一条R-A到R-B的互联链路做路由兜底。我在配置里保留这个互联口并把它的OSPF cost调高保证平时不走、故障时才顶上。3.2 出口路由器R-A与R-B的OSPF配置下面先贴R-A的完整配置再说明每个参数的作用。# R-A出口路由器A sysname R-A # interface GigabitEthernet0/0/0 description To-ISP1 ip address 100.1.1.2 255.255.255.248 undo shutdown # interface GigabitEthernet0/0/1 description To-SW-C1 ip address 10.254.1.2 255.255.255.252 # interface GigabitEthernet0/0/2 description To-R-B-Escape-Link ip address 10.254.0.1 255.255.255.252 ospf cost 200 # ip route-static 0.0.0.0 0.0.0.0 100.1.1.1 # ospf 1 router-id 1.1.1.1 default-route-advertise always cost 10 area 0.0.0.0 network 10.254.1.0 0.0.0.3 network 10.254.0.0 0.0.0.3 # bfd interface GigabitEthernet0/0/0 ospf bfd enable # return这段命令的核心思路是R-A通过一条静态默认路由指向ISP1网关100.1.1.1再通过OSPF的default-route-advertise always把这条默认路由通告给核心交换机通告cost固定为10。注意router-id我写成1.1.1.1实际生产环境不要用这种可被猜到的地址建议直接用设备Loopback地址。R-A和R-B之间的互联口我单独设置了ospf cost 200目的是让这条逃生链路平时不参与默认路由优选。因为R-A从R-B学到的默认路由总cost会是200加10远大于本地直连通告的10OSPF自然只选本地路径。只有R-A上联ISP1故障时本地发布的默认路由被撤销这条cost 210的备份路由才会生效。R-B的配置结构和R-A完全对称只是地址换成100.2.2.2、10.254.2.2、10.254.0.2router-id换成3.3.3.3。上联ISP2网关是100.2.2.1默认路由改为指向它。两台出口路由器之间通过10.254.0.0/30网段建立OSPF邻居同时把BFD打开后面第4章会细说BFD为什么重要。3.3 核心交换机VRRP多实例配置核心交换机的配置分两层用户网关的VRRP和上联出口路由器的OSPF。先看SW-C1。# SW-C1核心交换机1 sysname SW-C1 # vlan batch 10 20 # interface Vlanif10 description user-vlan10-gateway ip address 10.0.10.252 255.255.255.0 vrrp vrid 10 virtual-ip 10.0.10.254 vrrp vrid 10 priority 120 vrrp vrid 10 preempt-mode timer delay 10 # interface Vlanif20 description user-vlan20-gateway ip address 10.0.20.252 255.255.255.0 vrrp vrid 20 virtual-ip 10.0.20.254 vrrp vrid 20 priority 100 # interface GigabitEthernet0/0/24 description To-R-A ip address 10.254.1.1 255.255.255.252 ospf cost 10 # interface GigabitEthernet0/0/25 description To-SW-C2-Link ip address 10.254.200.1 255.255.255.252 # ospf 1 router-id 2.2.2.2 area 0.0.0.0 network 10.0.10.0 0.0.0.255 network 10.0.20.0 0.0.0.255 network 10.254.1.0 0.0.0.3 network 10.254.200.0 0.0.0.3 # returnSW-C1在VLAN10的VRRP组里优先级是120是Master在VLAN20的VRRP组里优先级是100是Backup。SW-C2的配置把这两组优先级对调VLAN10优先级100VLAN20优先级120。这样两个网段的用户网关由不同设备承载这就是多实例VRRP的负载分担效果。注意我把抢占延时设成了10秒。为什么要延时假如SW-C1因瞬时故障优先级下降VRRP切到SW-C2结果SW-C1 10秒内恢复了如果没有抢占延时它会立刻抢回Master用户网关在短时间内连续切换两次丢包更严重。设置10秒延时的意思是SW-C1恢复后先观察一段时间确认稳定再抢回。这个值在双出口场景里比较常用你可以根据业务容忍度在5到30秒之间调。3.4 用cost统一出口优先级等价与必选项配置里有两个cost值要重点理解。第一个是出口路由器上联接口的OSPF cost。本文拓扑里R-A到SW-C1的接口、R-B到SW-C2的接口我都建议在接口下显式配置ospf cost 10。为什么不依赖默认值因为华为设备OSPF默认参考带宽是100Mbps千兆接口算出来的cost是1万兆接口算出来也是1默认值无法反映接口实际带宽差异。如果不手动配两条一宽一窄的链路在OSPF眼里是等价的流量按哈希分布但带宽能力不同窄链路容易先被大流量打满。手动把两条上联链路都设成cost 10至少保证“两边都是10”语义清晰后续想调主备也方便。第二个是逃生互联链路的cost。R-A和R-B之间的互联口设为200核心交换机SW-C1与SW-C2之间的互联口也建议设成100以上。这个cost的作用是让正常流量不要走内部互联绕路但故障时路由依然可达。SW-C1和SW-C2之间的互联口为什么也需要OSPF因为VRRP主备切换后回程流量可能仍然被出口路由器送到原Master的物理IP上。此时原Master已经降为Backup按VRRP规则它不应该再转发该虚拟IP的流量如果没有SW-C1到SW-C2的互联链路和OSPF路由回程包就丢了。有了互联链路原Master能通过路由表把包跳到新Master业务只有极短抖动。这条链路从代价上看是“逃生通道”但从可靠性上看是刚需。4. 参数调优让ECMP和VRRP真正协同工作4.1 OSPF的cost、带宽参考值与哈希算法OSPF的选路归根结底是cost的比较。华为设备默认参考带宽是100Mbps接口cost 参考带宽 / 接口带宽结果小于1时取1。所以千兆口cost是1百兆口也是1万兆口还是1。这就带来了一个经典问题链路带宽翻倍OSPF选路结果却完全不变。处理办法有两个。第一个是全设备修改参考带宽把bandwidth-reference改成1000让千兆口cost算成1、万兆口cost算成0.1取整为1但百兆口就成了10。这个办法一改全改两台上联设备必须一致不然邻居之间算出来的链路开销对不上。第二个更推荐忽略默认cost直接在关键接口下手动指定cost。出口链路就两条手动指定不费事而且可读性好排障时一眼能看出设计意图。ECMP的负载分担算法也值得关注。华为设备默认是逐流哈希即对数据包的五元组做哈希同一条TCP连接的所有报文走同一个出口避免乱序。逐流模式在连接数多时均衡效果很好但如果某条链路上有几个大流量应用单条流不能拆分就可能出现一条链路被几个视频流打满、另一条链路闲着的情况。这时可以在接口下调整负载分担方式华为部分框式设备支持配置基于源IP、目的IP、或者增强的hash算法逐包模式不推荐因为TCP会因乱序大量重传。4.2 用BFD把链路切换时间压到毫秒级OSPF本身有Hello报文检测机制默认Hello间隔10秒、Dead间隔40秒。这意味着一条上联链路断了最坏要等40秒才能把路由撤掉业务中断40秒放到生产环境谁都接受不了。把Hello间隔改小是一种办法比如改成1秒、Dead 3秒但Hello报文多了有额外开销而且两台设备之间的链路若本来就卡顿容易误判。更适合的做法是开BFD。BFD是独立于OSPF的快速检测协议能在毫秒级发现链路故障再联动OSPF快速收敛。配置上只需要在两端开启BFD并在接口下执行ospf bfd enable。R-A上联ISP1的接口、R-A到R-B的互联接口、SW-C1到SW-C2的互联接口这些关键链路我都建议开启。对端设备如果是运营商BFD往往协商不起来因为运营商不会配合你的BFD参数。所以BFD主要用在自己可控的内部链路。上联运营商这条链路断了其实你本地的物理接口状态会立刻变down静态默认路由随之消失OSPF撤销通告也很快不一定非要BFD。真正需要BFD的是两台设备之间的互联链路物理接口up但链路质量劣化这种“半死不活”的状态只有BFD能快速识别。4.3 VRRP抢占延时与OSPF收敛的配合VRRP切换和OSPF收敛是两个独立的机制但它们会影响同一个业务。假设SW-C1是VLAN10的Master某天SW-C1设备重启VRRP在几秒内切到SW-C2VLAN10网关由SW-C2接管。业务出方向没问题但R-A从OSPF学到的10.0.10.0/24路由下一跳仍然是SW-C1因为OSPF邻居还没感知到SW-C1重启。回程流量送到SW-C1而SW-C1正在重启包就丢了。等到OSPF邻居dead timer超时路由才撤掉。这中间的窗口就是“VRRP快于OSPF”造成的黑洞。要缩小这个窗口除了上一条说的BFD把OSPF收敛加快还可以考虑把OSPF接口的dead timer调小。但这里有个度两边都设成Hello 1秒、Dead 3秒配合BFD毫秒检测切换时间能做到秒级以内。如果链路质量一般Hello调太快容易误翻车。我的习惯是内部互联链路上调成Hello 1秒、Dead 3秒并开BFD上联运营商链路保持默认。VRRP侧的抢占延时也要和OSPF收敛配合。SW-C1恢复后如果抢占延时太短它会立刻抢回Master但此时它的OSPF邻居还没完全建立业务流量进去了却出不去又断一次。所以抢占延时不能比OSPF收敛时间短。一般我建议VRRP抢占延时设10秒OSPF做了BFD毫秒收敛后这个值可以适当缩小到5秒但不要低于OSPF收敛时间。5. 常见坑与排查出口链路负载均衡的5个真实翻车现场5.1 虚拟IP进了OSPF负载均衡直接失效现象配置完以后查看路由表默认路由确实有两条但流量全走一台设备另一台上联带宽始终是零。show一下业务流量分布发现发往R-B的流量几乎不存在。原因有人在核心交换机的OSPF里把VRRP虚拟IP所在的网段也宣告了或者把VLANIF接口直接network进了OSPF。这样OSPF算出来的下一跳会指向虚拟IP而虚拟IP永远只在Master上响应。核心交换机把默认路由下一跳固定成了虚拟IP流量只会交给MasterECMP的第二条路径成了摆设。解决VRRP虚拟IP只用于用户网关不参与OSPF路由通告。OSPF宣告的是两台核心交换机的物理接口网段和用户业务网段不要把virtual-ip写进network命令。验证方法很直接查看核心交换机上OSPF的邻居状态和路由下一跳如果两条默认路由的下一跳都是同一个虚拟IP就说明配置错了。5.2 VRRP不感知上联故障主设备还在“裸转”现象R-A的上联ISP1链路断了但R-A设备本身没宕机。VLAN10的Master依然是SW-C1用户流量照常发给SW-C1SW-C1转给R-AR-A的默认路由静态指向100.1.1.1但下一跳不可达业务直接断网。更难受的是SW-C2明明有健康的出口链路却收不到任何切换信号。原因VRRP只检测接口和设备的可用性不检测“上联链路是否还能到达运营商网关”。R-A的接口状态是up的VRRP认为一切正常。这是双出口场景里最常见的翻车点也是“VRRP只能保证网关在线不能保证出口可用”的血泪教训。解决配置NQA联动Track用ICMP探测运营商网关地址。R-A探测100.1.1.1连续几次失败就认为上联故障降低它在VRRP组里的优先级让SW-C2接管VLAN10。NQA和Track的配置各家设备语法不一样建议参照设备版本手册做。核心思路是把出口链路的可用性转化为VRRP优先级的变化让网关切换跟着链路质量走。5.3 cost默认都是1两条链路带宽差一倍却不均衡现象两条出口链路分别是500M和1G配好后流量几乎对半分但500M那条链路持续打满1G那条只用了四成。用户反馈视频卡顿运维查了半天发现OSPF把两条链路当成等价路径了。原因华为设备OSPF默认参考带宽100Mbps千兆和万兆口算出来cost都是1。带宽不同但cost相同OSPF自然认为两条路径质量一样哈希分流时不管带宽差异。这不是OSPF负载均衡失效而是你没告诉OSPF链路真实带宽。解决手动给接口配置cost。500M链路设置cost 201G链路设置cost 10OSPF就不再认为它们等价。如果你确实想继续让两条链路分担流量也可以保留相同cost但要做好“窄链路先被打满”的心理准备。带宽差异超过两倍时我建议直接拉开cost做主备而不是强行均衡。5.4 ECMP哈希不均匀热门应用把单条链路打满现象路由表里两条默认路由都在接口流量统计却一条90%一条10%。排除了配置问题发现是某个大流量应用把整条链路占住了。原因默认哈希基于五元组逐流分布。如果业务里有几条超大流比如视频会议、海量文件同步这些流不能被拆开哈希的随机性在少量大流面前失效负载不均衡就出现了。解决先看清楚大流是什么。如果是少量大流可以尝试把设备负载分担模式调整为基于源IP或目的IP的增强哈希看能否把流打散到不同链路。有些框式设备支持配置哈希种子或者更均匀的哈希算法。如果业务对运营商线路有要求比如视频会议必须走电信那就需要用PBR指定这部分流量固定走某条链路剩下的流量继续走OSPF ECMP。这块属于“哈希调到极限还是不均衡”后的必经之路别硬扛。5.5 两台核心的OSPF区域不一致默认路由学不到现象核心交换机上display ospf peer能看到和出口路由器的邻居是Full但路由表里就是没有默认路由。或者出口路由器偶尔能从对端核心学到用户网段一重启就丢。原因最常见的是区域划分不一致。SW-C1和R-A在区域0SW-C2和R-B在区域1SW-C1和SW-C2之间的互联又在区域0。Area 1的默认路由要进Area 0必须经过ABR通告如果ABR上没有配default-route-advertise或者区域间路由汇总把默认路由过滤掉了下游就学不到。有些老旧的方案为了省地址用虚链路vlink把区域0串起来虚链路本身不稳定OSPF邻居反复抖动路由表跟着抽风。解决尽量全互联都用area 0不要拆区域。出口设备就这么几台区域0足够承载。确实需要分区域的场景明确哪台设备是ABR并在ABR上确认type 3 LSA的传递方向和默认路由通告策略。遇到学不到路由又看邻居都正常的情况先看LSDB再逐步查ABR的路由汇总和过滤规则不要盲目重启进程。6. 上线前的验证与一次完整的故障演练6.1 三分钟确认VRRP与OSPF状态正常配置完成后先做静态验证。核心交换机上执行display vrrp brief确认VLAN10的Master是SW-C1、VLAN20的Master是SW-C2。再执行display ospf peer brief确认SW-C1和R-A、SW-C1和SW-C2之间的邻居都是Full。出口路由器上执行display ip routing-table 0.0.0.0正常情况下看到的输出类似下面这样Destination/Mask Proto Pre Cost Flags NextHop Interface 0.0.0.0/0 O_ASE 150 10 D 100.1.1.1 GigabitEthernet0/0/0R-A上只有自己那条默认路由是优选路径从R-B学到的cost 210路由不会出现在优选路由表里。核心交换机上的路由表则应该能看到两条默认路由下一跳分别是10.254.1.2和10.254.2.2这就是ECMP在起作用。6.2 拔线演练从丢包数看切换收敛时间验证状态正常不代表故障时表现合格。我的习惯是在业务低峰做一次拔线演练。准备一台测试终端持续ping运营商网关地址命令用ping -c 1000 -i 0.2。然后让同事拔掉R-A上联ISP1的光纤观察ping丢包次数和恢复时间。拔线后你会看到R-A的静态默认路由因为下一跳不可达被撤销OSPF不再向外通告默认路由。SW-C1上原本从R-A学到的cost 10默认路由消失替换成从SW-C2方向学到的cost更高的备份默认路由或者直接通过VRRP把VLAN10的流量切到SW-C2。整个过程如果配置了BFD丢包数应该在个位数以内如果没配BFD还在用默认Dead 40秒你会看到40秒左右的连续丢包这个数字足够让你下定决心把BFD补上。恢复链路后别急着收工观察VRRP是否发生了主备回切。如果SW-C1的抢占延时设了10秒拔线期间它降级成Backup恢复后要等10秒再抢回Master这期间VLAN10的流量继续由SW-C2转发属于正常现象。如果回切时间比预期长很多检查有没有其他track项绑定了优先级。6.3 用流量统计验证两条链路是否真正五五开故障演练通过后最后一步是验证负载均衡效果。在出口路由器上分别执行display interface GigabitEthernet0/0/0查看两台上联接口的Input/Output速率。持续观察一个小时两条链路的流量应该大致按哈希分布分摊不可能精确五五开但差距不应超过一倍。如果出现一条链路长时间利用率超过80%而另一条低于20%回到第5.4节排查哈希问题。这套方案上线后我还会在出口路由器上开启简单的NetStream或sFlow采样把每条链路的流量按应用类型留存一周。这样即使将来出现“某条链路莫名被打满”也能直接翻历史数据定位是哪种业务流在失衡而不是对着设备发呆。这些年做出口改造我最大的感受是VRRP和OSPF的配置命令并不难难的是想清楚谁负责网关、谁负责路由、故障时它们如何配合。把本章的验证步骤完整做一遍你踩过的那些坑基本都能在演练阶段暴露出来希望帮到你。本文还有配套的精品资源点击获取