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组，谁优先级高谁当Master，Master持有虚拟IP并回应用户的ARP请求，Backup在Master故障时接管。但只有一个VRRP组时，两台设备永远是一主一备，流量全走Master，Backup设备的上联链路完全闲置——这不叫负载均衡。

要让两条出口链路都被用起来，常见做法是配置多个VRRP实例，把不同VLAN的网关角色错开。比如VLAN10的Master是SW-C1，VLAN20的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. 拓扑与配置落地：双出口路由器的VRRP+OSPF完整命令

3.1 地址规划与拓扑

配置先看拓扑。本文采用一台出口路由器对应一台核心交换机的串行结构：R-A上联ISP1，下联SW-C1；R-B上联ISP2，下联SW-C2；SW-C1和SW-C2之间建立三层互联，用于VRRP报文传输、OSPF邻居同步以及故障时逃生转发。

R-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，远大于本地直连通告的10，OSPF自然只选本地路径。只有R-A上联ISP1故障时，本地发布的默认路由被撤销，这条cost 210的备份路由才会生效。

R-B的配置结构和R-A完全对称，只是地址换成100.2.2.2、10.254.2.2、10.254.0.2，router-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 # return

SW-C1在VLAN10的VRRP组里优先级是120，是Master；在VLAN20的VRRP组里优先级是100，是Backup。SW-C2的配置把这两组优先级对调：VLAN10优先级100，VLAN20优先级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-C2，VLAN10网关由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，流量只会交给Master，ECMP的第二条路径成了摆设。

解决：VRRP虚拟IP只用于用户网关，不参与OSPF路由通告。OSPF宣告的是两台核心交换机的物理接口网段和用户业务网段，不要把virtual-ip写进network命令。验证方法很直接：查看核心交换机上OSPF的邻居状态和路由下一跳，如果两条默认路由的下一跳都是同一个虚拟IP，就说明配置错了。

5.2 VRRP不感知上联故障，主设备还在“裸转”

现象：R-A的上联ISP1链路断了，但R-A设备本身没宕机。VLAN10的Master依然是SW-C1，用户流量照常发给SW-C1，SW-C1转给R-A，R-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 20，1G链路设置cost 10，OSPF就不再认为它们等价。如果你确实想继续让两条链路分担流量，也可以保留相同cost，但要做好“窄链路先被打满”的心理准备。带宽差异超过两倍时，我建议直接拉开cost做主备，而不是强行均衡。

5.4 ECMP哈希不均匀，热门应用把单条链路打满

现象：路由表里两条默认路由都在，接口流量统计却一条90%一条10%。排除了配置问题，发现是某个大流量应用把整条链路占住了。

原因：默认哈希基于五元组，逐流分布。如果业务里有几条超大流，比如视频会议、海量文件同步，这些流不能被拆开，哈希的随机性在少量大流面前失效，负载不均衡就出现了。

解决：先看清楚大流是什么。如果是少量大流，可以尝试把设备负载分担模式调整为基于源IP或目的IP的增强哈希，看能否把流打散到不同链路。有些框式设备支持配置哈希种子或者更均匀的哈希算法。如果业务对运营商线路有要求，比如视频会议必须走电信，那就需要用PBR指定这部分流量固定走某条链路，剩下的流量继续走OSPF ECMP。这块属于“哈希调到极限还是不均衡”后的必经之路，别硬扛。

5.5 两台核心的OSPF区域不一致，默认路由学不到

现象：核心交换机上display ospf peer能看到和出口路由器的邻居是Full，但路由表里就是没有默认路由。或者出口路由器偶尔能从对端核心学到用户网段，一重启就丢。

原因：最常见的是区域划分不一致。SW-C1和R-A在区域0，SW-C2和R-B在区域1，SW-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/0

R-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的配置命令并不难，难的是想清楚谁负责网关、谁负责路由、故障时它们如何配合。把本章的验证步骤完整做一遍，你踩过的那些坑基本都能在演练阶段暴露出来，希望帮到你。

本文还有配套的精品资源，点击获取