双点双向重分布路由环路成因与解决方案：OSPF与RIP场景实战-平芜编程栈

1. 问题场景：双点双向重分布，环路是怎么溜进来的

做网络的人，基本都躲不开路由重分布这件事。尤其在企业网或者数据中心出口，经常遇到不同路由协议并存的局面——内网跑OSPF，上游或者某段历史遗留链路跑RIP，或者和外部单位对接用的IS-IS，两边得互通，就得做重分布。听起来简单，就是把路由倒来倒去，但一旦涉及到两个点、双向倒，路由环路的风险就悄悄爬上来了。

所谓“双点”，指的是在网络里有两个路由器同时在做重分布。比如说，R1和R2都连着OSPF区域和RIP区域，R1把OSPF路由重分布进RIP，R2也把OSPF路由重分布进RIP；反过来R1和R2也把RIP的路由重分布进OSPF。这种设计在冗余组网里非常常见，因为单点重分布一旦设备挂了，两个协议域就断了，所以生产环境几乎都是双点冗余。

“双向”则是指两边协议互相导入，OSPF学到RIP的路由，RIP也学到OSPF的路由。这种交叉引入本身没问题，问题是协议之间互相不知道对方的“底细”，比如RIP不知道OSPF内部的路由到底是从哪儿来的，OSPF也不知道RIP的路由是不是自己扔出去的，于是环路就出现了。

有一次我在一个模拟项目X里复现这个场景，配置完双点双向重分布之后，拓扑里出现了一个非常隐蔽的环路：RIP域内一台终端访问OSPF域内某个网段时，数据包在R1和R2之间来回弹跳，直到TTL耗尽。排查了大半天，最后发现问题出在RIP的管理距离比OSPF外部路由更优，重分布回去的路由又被人家学回来，形成了一条“自产自销”的环。

这个问题的核心就一句话：重分布是单向的、无意识的，它不管这条路由是不是自己人扔出去的，只要协议觉得“这条路由我更喜欢”，它就会收下来。所以解决思路也围绕一个关键词：让路由回不到原点，或者即使回来了也不被采纳。

这篇内容我会把自己的排查过程和最终方案完整讲一遍，包括协议特性、配置思路、策略细节和实测结果，希望给同样被这个坑折磨过的朋友一些参考。适合刚接触重分布的网络工程师，也适合那些配置做完了但心里没底、想确认自己方案是否稳妥的人。

2. 环路成因拆解：为什么偏偏是“双点双向”容易出事

2.1 管理距离不一致引发的“次优路由回灌”

不同路由协议之间相互不信任，这从它们各自的管理距离上就能看出来。比如OSPF内部路由管理距离是10，外部路由是110，RIP是120。从数字上看，OSPF比RIP“权威”得多。但问题恰恰出在这个差异上。

双点双向重分布之后，RIP域内会通过重分布学到OSPF的路由，管理距离是120；同时RIP自身也可能有一条通过R1学到的相同前缀路由。由于R1是从OSPF重分布过来的，它把这条OSPF路由在RIP里通告出去时，会把metric按照配置规则换算。问题来了：如果另一个重分布点R2也从OSPF听到了同一条路由，两边重分布进RIP之后，RIP内部会比较metric和hop count。如果R2重分布后的metric更小，那么RIP域内所有流量都会倾向走R2。可这个R2也许并不是去往OSPF目标网段的最优出口，因为原生的OSPF路由还在R1那边。

这还只是“次优路径”问题，更狠的是环路。R1把OSPF重分布进RIP时，如果R2也从RIP学到了这条路由，并且在它的OSPF进程里通过重分布把这条路由再扔回OSPF域，那么OSPF域内就会收到一条“从RIP学来的、但原本就是自己域内的路由”。由于重分布进OSPF的路由管理距离是110（OSPF External），它和原本OSPF内部路由的管理距离10没法比，所以正常情况下OSPF内部路由会胜出。

但如果这条回灌路由的前缀恰好是OSPF域内的某个汇聚网段，而内部路由因为某些原因（比如被动接口、路由过滤）没有被通告，那么OSPF域内就会用这条回灌的“外部路由”来转发，发给它之后，这条路由又会经由R1或R2在RIP和OSPF之间反复倒腾，环路就成了。

我实际复现时用的办法是：在拓扑里刻意让OSPF某条内部路由不连续，比如R1的loopback接口开了OSPF但R2没有宣告完整，然后把RIP和OSPF做双向重分布，几秒钟后traceroute就能看到数据包在R1-R2之间反复横跳。

2.2 双点重分布的“路由震荡”放大器效应

单点重分布也会产生问题，但环路出现的概率不高，因为只有一个“翻译官”，没有人与它竞争。双点重分布就完全不一样了：两个重分布点会互相学习对方重分布过去的同一条路由，然后以各自的方式再次通告回来。

举个具体例子。R1把OSPF内网路由10.1.0.0/16重分布进RIP，metric按默认规则换算为1跳；R2在RIP里听到这条路由后，也把它重分布进OSPF，由于R2本身就在OSPF域内，它重新注入的这条路由又会带着一个tag或者metric被R1看到。R1此时面临一个选择：它是相信OSPF里本地已有的10.1.0.0/16内部路由，还是相信这个经由R2绕了一圈回到OSPF的外部路由？

正常情况下OSPF内部路由优先级更高，但如果你配置了外部路由优先（比如修改了distance或用了路由策略把外部路由优先级调高），这条回灌路由就会被采纳。一旦采纳，数据从OSPF域内到达10.1.0.0/16时就会发给R2，R2查询路由表发现去往10.1.0.0/16的下一跳是R1（因为它是在RIP里从R1学到的），于是数据包又发回R1，R1再发回R2。

这个“放大器”效应在链路时延低、设备性能好的环境下尤其恶心：数据包不会立刻被丢弃，而是在环里高速转发，直到TTL归零才消失。排查时show interfaces counters会发现两台设备之间Link的流量异常飙升，但并没有实际用户流量。

2.3 区分“双向重分布”与“路由回灌”

很多人分不清这两个概念，导致排查时思路打转。

双向重分布是指两个协议域之间互相把对方的路由引入自己域内。这是主动配置的行为，本身是中性的，如果只做单点，基本不会产生环路。而路由回灌是“我在A域内通告了一条路由，它通过B域绕了一圈，又被当作外部路由重新回到了A域”。回灌是双向重分布在多点部署时的必然副作用。

用一句大白话概括：双向重分布是“互通”，路由回灌是“串味”。你炖了一锅肉，肉香飘到隔壁，邻居炖了一锅菜又把肉香飘回来，结果你的肉锅里多了菜的味，这锅菜又不知道这味本来就来源于你这锅肉，于是两边互相加料，越熬越浑。

理解了回灌的本质，后面的所有解决方案都基于一个核心策略：让回灌的路由“不被认领”。可以通过过滤、修改管理距离、打tag识别来源后拒绝等手段实现。

3. 四种主流解法：哪种策略最适合你的网络

3.1 方案一：“源头标记法”——用Route-Tag识别回灌路由

Tag是解决重分布环路最经典的手段。原理非常简单：在重分布出去的时候，给路由打上一个特殊的标记值，对方协议域收到这个标记后，再做重分布回来时，我们检查路由是否带着这个特征，如果有，就直接过滤掉。

配置层面以华为设备为例。假设OSPF重分布进RIP时，给路由打上tag 100：

rip 1 import-route ospf route-policy FROM_OSPF route-policy FROM_OSPF permit node 10 if-match ip route-source 0.0.0.0 0.0.0.0 apply tag 100

然后在RIP重分布回OSPF时，过滤掉tag为100的路由：

ospf 1 import-route rip route-policy BLOCK_LOOP route-policy BLOCK_LOOP deny node 10 if-match tag 100 route-policy BLOCK_LOOP permit node 20

这样即使R2把OSPF路由重分布进了RIP，RIP又把这条路由传回了R2的OSPF进程，R2在重分布时也会因为检查到tag 100而拒绝这条路由回灌。

这套方案的核心优势是可扩展性强，你可以给不同方向打不同tag，还可以区分边缘重分布和内部重分布。缺点是要求所有参与重分布的设备必须支持tag传递，如果跨厂商设备，tag字段的处理可能存在差异，需要先在实验室里验证一遍。

3.2 方案二：“优先级整容法”——让外部路由“矮一头”

如果不想动tag，也可以从优先级上做文章。原理是让所有重分布进来的路由，管理距离劣于协议内部路由，从而在路由表选路时天然不占优势。

在某些设备上，可以通过命令调整协议的外部距离，比如把RIP的管理距离调成比OSPF外部路由更大的值，或者反过来调高OSPF外部路由的距离，让回灌路由永远也不可能被优选。

华为设备上调整OSPF外部路由距离的配置示例：

ospf 1 distance 200

这意味着OSPF域内所有外部路由距禈是200，而RIP仍然是120，内部路由仍然是10，回灌的路由即便进了OSPF，也会因为距离太大输给一切内部路由甚至其他外部路由。

这套方案的优点是不需要额外维护tag规划，实施简单。缺点也很明显：它是“一刀切”，所有外部路由都被降级了，如果网络里确实存在需要优选的正当外部前缀（比如去往分支机构的静态路由做重分布），也会被一并打趴下。所以要慎用，最好配合前缀过滤一起做。

根据我个人实测，对于大部分中小型网络，单纯通过调整距离就能解决90%以上的回灌问题。但如果是大型网络，外部路由类型多、来源杂，只调距离会引发选路不符合预期，还是建议结合tag和前缀过滤，立体防护。

3.3 方案三：“进出分别过滤”——针对前缀的精准拦截

这是最直观、也最容易被理解的方案：在重分布的两个方向上分别配置过滤策略，明确允许哪些前缀通过、拒绝哪些前缀。

比如，OSPF域内的核心内网网段是10.1.0.0/16，RIP域内的业务网段是172.16.0.0/16。那么配置就应该是：

OSPF重分布进RIP时，只允许10.1.0.0/16出去；RIP重分布进OSPF时，只允许172.16.0.0/16进来。

ip ip-prefix FROM_OSPF permit 10.1.0.0 16 greater-equal 16 less-equal 32 ip ip-prefix FROM_OSPF deny 0.0.0.0 0 less-equal 32 rip 1 import-route ospf route-policy FILTER_FROM_OSPF route-policy FILTER_FROM_OSPF permit node 10 if-match ip-prefix FROM_OSPF

反向类似：

ip ip-prefix FROM_RIP permit 172.16.0.0 16 greater-equal 16 less-equal 32 ip ip-prefix FROM_RIP deny 0.0.0.0 0 less-equal 32 ospf 1 import-route rip route-policy FILTER_FROM_RIP route-policy FILTER_FROM_RIP permit node 10 if-match ip-prefix FROM_RIP

这套方案在双点双向重分布场景下最为稳妥，因为你等于给两个方向分别画了一条“国境线”，只有明确需要跨域的路由才能通行，其他一切回灌都被挡在门外。

缺点是后续运维要时刻记得维护这两个前缀列表，新增网段时如果忘记更新，业务就会断，而且故障表现非常隐蔽——路由表里看不到缺失，但数据包就是不通。生产环境中我吃过这个亏，后来给自己立了一条规矩：所有前缀过滤的配置必须带注释，并且每次变更前先对着路由表把新增前缀在策略里过一遍。

3.4 方案四：“双点打通式”——OSPF区域间直接互通，绕过重分布

这是从架构上规避问题的思路。如果条件允许，两边协议域之间能不能打通一个“直连通道”，把需要互访的网段用物理链路连起来，两端分别宣告进各自协议，而不是依靠重分布让两个协议互相翻译？

举个例子：R1-R2之间拉一条三层互联链路，R1侧宣告进OSPF，R2侧宣告进RIP，然后让R1和R2互指静态路由或者通过其他IGP把直连网段散布出去。这样OSPF域访问RIP域时，流量走到R1或R2的直连接口就直接转给RIP域了，不存在“RIP把OSPF路由再倒回OSPF”的可能性。

这种做法常见于两个公司合并、两套网络互通的场景。重分布依然保留，但只处理边缘的某些前缀，核心互访流量走直连通道。环路风险被压缩到最低。

当然，如果两边协议域规模都很大、网段数量多，物理打通成本高、改造成本也高，那就不太现实。这种情况下优先考虑方案一或方案三的组合。

4. 实操复盘：从发现环路到彻底消除的全过程

4.1 构建复现环境与初始配置

为了把问题讲透，我搭了一个最小化复现环境：两台路由器R1和R2，R1的G0/0/0连接OSPF区域，R2的G0/0/1连接RIP区域，R1和R2之间用G0/0/2直连，同时跑OSFP和RIP（双点双向重分布）。

具体配置是这样的：

R1:

interface GigabitEthernet0/0/0 ip address 10.1.1.1 255.255.255.0 # interface GigabitEthernet0/0/2 ip address 192.168.12.1 255.255.255.0 # ospf 1 router-id 1.1.1.1 area 0.0.0.0 network 10.1.1.0 0.0.0.255 network 192.168.12.0 0.0.0.255 # rip 1 version 2 network 192.168.12.0 import-route ospf 1

R2:

interface GigabitEthernet0/0/1 ip address 172.16.1.1 255.255.255.0 # interface GigabitEthernet0/0/2 ip address 192.168.12.2 255.255.255.0 # ospf 1 router-id 2.2.2.2 area 0.0.0.0 network 192.168.12.0 0.0.0.255 import-route rip 1 # rip 1 version 2 network 172.16.1.0 network 192.168.12.0 import-route ospf 1

这组配置本身就是“教科书级”的双点双向重分布环路布置，R1和R2都同时运行OSPF和RIP，两边都在做互相引入。

R1把OSPF内的10.1.1.0/24重分布进RIP，R2在RIP里学到这条路由，同时R2也把172.16.1.0/24重分布进OSPF，R1在OSPF里学到这条路由。从表面看，两边路由表里都有对方域内的路由了，双向互通是通的。但仔细看路由表，会发现10.1.1.0/24在R2的路由表里出现两次：一次是OSPF学到（内部路由），一次是RIP学到（重分布进来的外部路由）。由于RIP管理距离120大于OSPF外部110，R2优先选OSPF。

这配置的隐藏问题在于：如果R1和R2之间的直连链路或者某个接口中断，OSPF内部路由消失，RIP里学到的“二手路由”就顶上来了。此时R2的OSPF域内如果有一个路由器需要到达10.1.1.0/24，它从R2学到的是RIP重分布进OSPF的外部路由，下一跳指向R2，R2查找路由表发现去10.1.1.0/24的下一跳是R1（因为R1在RIP里通告了这条路由），而R1在RIP里学到去10.1.1.0/24的下一跳又是R2——因为R2也在RIP里通告了同一条路由，且路径代价一样时，RIP会选先学到的那个。两头互指，环路直接成立。

4.2 环路触发与现象观察

我模拟了OSPF域内10.1.1.0/24的直连网段从R1的OSPF进程中消失的场景（把10.1.1.0网段从OSPF里移除，但接口仍然保留地址）。此时R1不再通过OSPF通告10.1.1.0/24，但R1的RIP进程里仍然会通告这条路由（如果RIP能够从其他来源学到的话）。

为了让场景更真实，我还在R1上配置了一条指向10.1.1.0/24的黑洞静态路由，保证数据包进入R1后不会因为无路由而被丢弃。这样一来，从RIP域内发往10.1.1.0/24的流量到达R2后，R2发现去这个网段最优路径是通过RIP从R1学到的那条路由（此时OSPF内部路由已经消失，RIP路由成了唯一选择），于是把包发给R1。R1收到后，发现去10.1.1.0/24的下一跳是R2（因为R2也在RIP里通告了该网段），于是又把包发回R2。两个路由器互相撕扯这个包，直到TTL变0。

用traceroute从RIP域内某台设备出发，现象非常典型：

1 192.168.12.2 2 ms 1 ms 1 ms 2 192.168.12.1 2 ms 1 ms 1 ms 3 192.168.12.2 2 ms 1 ms 1 ms 4 192.168.12.1 2 ms 1 ms 1 ms ...

数据包在R1和R2之间来回横跳，TTL逐跳递减，最终在某个数字上请求超时。

如果此时抓包，还能看到R1和R2之间在疯狂转发同一个目的IP的数据包，链路利用率被打满，而实际上根本没那么多真实流量。特别迷惑的是，如果你只看路由表，会发现R1和R2上都有关于10.1.1.0/24的路由，质量还挺“正常”，无非下一跳互指而已。这时候如果经验不足，很容易往二层环路、STP、交换机问题上排查，白白浪费时间。

4.3 制定并落地修复策略

我的修复方案采用了“方案一+方案三”的组合：源头打tag，同时做前缀过滤，双保险。

首先，在R1和R2上都配置路由策略。R1需要做两件事：一是重分布进RIP时给所有从OSPF引入的路由打上tag 100；二是从RIP重分布进OSPF时，拒绝所有携带tag 100的路由。

R1配置：

route-policy FROM_OSPF permit node 10 if-match ip-prefix INTERNAL apply tag 100 ip ip-prefix INTERNAL permit 10.1.1.0 24 route-policy BLOCK_RIP permit node 10 if-match tag 100 deny route-policy BLOCK_RIP permit node 20 ospf 1 import-route rip route-policy BLOCK_RIP rip 1 import-route ospf route-policy FROM_OSPF

R2配置类似，只是方向反一下，OSPF重分布进RIP时打tag 200，RIP重分布进OSPF时拒绝tag 200。

R2配置：

route-policy FROM_RIP permit node 10 if-match ip-prefix EXTERNAL apply tag 200 ip ip-prefix EXTERNAL permit 172.16.1.0 24 route-policy BLOCK_OSPF permit node 10 if-match tag 200 deny route-policy BLOCK_OSPF permit node 20 ospf 1 import-route rip route-policy BLOCK_OSPF rip 1 import-route ospf route-policy FROM_RIP

这套配置的效果是：R1重分布进RIP的OSPF路由带有tag 100；R2在RIP里学到后，如果试图以这条路由为来源重分布进OSPF，R2的BLOCK_OSPF策略会检查tag并直接拒绝。同理，R2重分布进RIP的RIP域路由带tag 200，R1在重分布回OSPF时也会拒绝。

这样一来，回灌路径被彻底掐断，两个方向上即使出现“绕圈路由”，也没有机会再进入对方协议域形成闭环。

配置完成后，从RIP域内再次traceroute到10.1.1.0/24，路径就稳定了：

1 192.168.12.1 1 ms 1 ms 1 ms 2 10.1.1.1 2 ms 1 ms 2 ms

数据包不再在R1-R2之间弹跳，而是直接进入目标网段。从OSPF域内traceroute到172.16.1.0/24也恢复正常。

4.4 验证策略有效性的几个关键命令

修复之后，不能只看traceroute通了就说“完事大吉”。我习惯用以下几条命令做完整验证。

第一，查看路由表里是否出现tag。华为设备上，在OSPF进程中开启tag可见性后：

display ospf routing display ip routing-table verbose

在verbose输出中，能看到路由条目里携带的tag值。如果发现OSPF路由表里还有tag 100或tag 200的路由，说明还有某个方向没有过滤干净。

第二，检查重分布统计。华为设备可以用display rip 1 statistics或者在OSPF进程里看LSA类型5的数目。如果重分布的策略生效，外部LSA数量应该稳定，不会因为RIP域内的路由抖动而变化。

第三，人为触发一次路由震荡。把R1上OSPF的10.1.1.0/24网段重新宣告再移除，或者shutdown再no shutdown一个接口，观察R2和R1的路由表变化。健康的配置下，无论怎么震荡，两边的外部路由数量都不会异常攀升。

第四，从两个方向的末梢设备互相ping大包，同时开启扩展ping选项，源地址分别指定不同网段，确认数据路径稳定可控。

这套验证方法虽然简单，但在生产变更时非常有用，能让你在业务投诉之前发现问题。

5. 常见问题与排查技巧实录

5.1 问题一：过滤策略写对了，但路由还在回灌，怎么办

有一次我自认为配置完全正确，但R1的OSPF路由表里仍然能看到来自RIP的重分布路由。后来查了很久，发现是R2上有一个额外的静态路由，它指向了R1，而这条静态路由也被重分布进了OSPF，来源和动态协议无关。我的过滤策略只匹配了RIP进程重分布的路由，没有匹配静态路由，导致漏网。

解决方式是扩大过滤范围，在R2上把所有进入OSPF的重分布源全部套用同一个过滤策略，包括static、direct、rip。同时在R1的入方向也做二次过滤，即使R2漏了一条，R1也不会收。

这个坑提示我们：重分布环路不只是“协议对协议”的问题，静态路由、直连路由都可能成为回灌载体，排查时不能只盯着动态协议。

5.2 问题二：RIP和OSPF的metric换算导致次优路径

RIP的跳数上限是15，OSPF的cost理论值可以很大。重分布时，OSPF路由进入RIP，默认把cost转成hop count，如果OSPF路由到重分布点的cost很大，换算后的hop可能达到甚至超过15，这条路由在RIP域内直接就不可达了。

我在配置双点双向重分布时，遇到过RIP域内某条OSPF重分布路由网络可达但总是走备用链路的情况，根因就是R1和R2重分布进RIP时换算的hop count不同，R2换算出的跳数比R1小，RIP域内就都往R2跑了。而实际上R1才是真正靠近目标网段的设备。

解决方式是手动配置重分布metric，在RIP进程的import-route里固定metric值，让两个重分布点保持一致。比如R1和R2都配置成：

rip 1 import-route ospf 1 cost 3

这样RIP域内无论从哪个点学到这条路由，metric都是统一的，次优路径的隐患就被消除了。

5.3 问题三：设备厂商间tag字段行为不一致

如果网络是跨厂商设备，比如一边华为一边思科，tag字段的传递可能会出问题。思科的OSPF外部路由tag默认是0，可以设置；华为也是按标准实现。但RIP协议本身并没有标准的tag字段，大多数厂商在RIP里用route tag扩展来实现，这条扩展信息在跨厂商重分布时可能被丢弃。

这意味着“在华为设备上给RIP路由打tag，在思科设备上识别”不一定可靠。我在一个混搭环境里就碰到过这个问题，后来统一改成前缀过滤方案，虽然维护成本高一些，但至少行为可预期。

建议在做跨厂商方案设计时，先做一轮最小化验证，确定tag在协议之间传递的兼容性，再决定是否依赖tag方案。不经过验证的tag策略，跟没配差不多。

5.4 排查技巧：用Log和Debug精准定位环路口

当环路已经发生时，单纯看路由表容易懵，因为路由表里看起来“每条路由都有下一跳，好像都通”。我推荐三个高性价比排查手段。

第一个是看接口计数器。在R1和R2互连的接口上执行display interface，重点看output方向的总字节数和pps。如果环路正在发生，接口的Output速率会异常地高，而且报文基本上是同样的源目地址。数据包在环里每绕一圈，都会增加接口的出方向计数。

第二个是配置ACL抓特定流量。在R1上写一条permit ip any host 10.1.1.1的ACL，然后在接口下traffic统计，看这个ACL的匹配次数涨得有多快。如果每秒成千上万地涨，说明这个目的IP的流量正在被疯狂转发，八成就是环路。

第三个是使用debug ip packet，但要注意生产环境慎用，因为debug的输出量极其巨大，可能导致设备CPU跑满。我一般只在模拟环境或维护窗口期使用，而且会把debug输出重定向到buffer里，用完立刻关掉。

正确的排查顺序应该是：先接口计数判断环路是否成立，再ACL统计定位具体目的地址，最后抓包确认环路路径，整个过程控制在几分钟内完成，不惊动业务。

5.5 独家避坑：重分布前先画“路由流向图”

配置双点双向重分布之前，我强烈建议先在纸上画出整个网络的“路由流向图”。不需要画得很精细，但要把每个重分布点、重分布方向、涉及的前缀、期望的选路路径画清楚。然后对着图走一遍：OSPF里这个前缀如果在A点消失，B点的路由表会变成什么样？如果R1挂了，流量走R2会不会有问题？R1恢复后，路由收敛会不会产生瞬时环路？

这套脑力演练成本几乎为零，但能避免掉大部分“配置一时爽，事后火葬场”的局面。路由协议本身不复杂，复杂的是多协议、多点、多方向的交叉影响。动手前先把图捋一遍，后面出问题的概率会小非常多。