我还记得第一次正儿八经给两套协议域做互通的场景一边是稳定跑了多年的OSPF核心另一边是设备选型被迫保留的RIP区域业务又要求两边路由全局可达。当时在模拟环境里把“重发布实验”跑了好几轮才把redistribute这条命令背后的种子度量、路由回灌和次优路径彻底摸清楚。这篇文章就按我实际动手的顺序把这次实验的完整过程记录下来给准备做网络割接、或者正在啃路由交换认证的朋友做个参考。1. 为什么要练重发布多协议共存的现实场景1.1 三个必须用重发布的真实场景我在做网络方案时总结过凡是涉及到重发布的基本都是下面这三种情况之一。第一种是网络演进改造。老网络用老协议跑了好几年核心设备不能停机新区域或者新设备又只能支持新的协议两边没法强行统一只能在边界路由器上做路由互相引入。第二种是企业合并或者部门划转。两个单位各有各的路由协议规划合并之后网络要通但不可能立刻推倒重来重发布是最务实的过渡手段。第三种是厂商替换。原来用的一套私有协议换成新厂商设备后对方只认标准协议这个过渡阶段也得靠重发布把边界撑住。这三种情况的共同点是网络不是一张白纸协议在短期内无法统一但业务要求所有网段能够互通。这时候重发布就是唯一能把两张协议网络“缝”在一起的手段。1.2 为什么实验选OSPF和RIP组合有人可能会问RIP在生产环境都快绝迹了练它还有什么价值。我的看法恰恰相反RIP在重发布实验里是最好的对照组。RIP的度量是跳数OSPF的度量是接口开销两者反差极大能非常直观地暴露出种子度量不一致带来的选路问题。再加上RIP从其他协议引入路由时存在默认度量不可达这个经典坑几乎每个第一次做实验的人都会在这里被绊一下这个坑的价值比学一堆高级协议命令大得多。把OSPF和RIP这套练明白之后再去做OSPF和BGP、OSPF和EIGRP之间的重发布就只是换参数和换关键字的问题了。底层逻辑完全相同。2. 实验拓扑、编址与模拟器准备2.1 拓扑结构与地址规划本次实验我用四台路由器组成一条串形拓扑R1是纯OSPF域设备R4是纯RIP域设备R2和R3各自同时运行OSPF和RIP充当两个协议域的边界。链路和环回规划如下设备接口IP地址归属协议R1Loopback01.1.1.1/32OSPFR1GigabitEthernet0/0192.168.12.1/24OSPF 区域0R2Loopback02.2.2.2/32OSPFR2GigabitEthernet0/0192.168.12.2/24OSPF 区域0R2GigabitEthernet0/1192.168.23.2/24OSPF 区域0 RIPR3Loopback03.3.3.3/32RIPR3GigabitEthernet0/0192.168.23.3/24RIP OSPF 区域0R3GigabitEthernet0/1192.168.34.3/24RIPR4Loopback04.4.4.4/32RIPR4GigabitEthernet0/0192.168.34.4/24RIP为什么故意让R2和R3两台边界都做双向重发布因为单向重发布只能验证命令写得对不对体现不出路由回灌和次优路径这些真正会咬人的问题。只有双边界同时双向重发布才能完整复现生产环境中常见的环路隐患。2.2 协议区域划分OSPF进程1区域0成员是R1、R2、R3三台设备RIP v2成员是R2、R3、R4三台设备。注意R2和R3同时属于两个协议域这正是现实中边界设备的典型状态。这里有一个设计上的取舍需要说明我把R2和R3之间的边界链路同时宣告进了OSPF和RIP让同一接口同时属于两个协议这样能更清晰地看出路由在不同协议里的传播路径。实际工程中边界设备通常把两种协议的接口物理隔离开但实验保留这种做法可以更直观地观察路由来源不影响对重发布核心原理的理解。2.3 模拟器选择与准备工作设备用GNS3或者EVE-NG都行。我这次用的是EVE-NG优点是可以同时开多台设备配置完丢在那里跑一天也不掉线。GNS3更轻量单机学习完全够用。无论用哪个建议每台路由器至少分配512MB内存把控制台日志输出关掉不然反复debug的时候终端刷新会让人崩溃。镜像我统一用的企业级路由器镜像保持命令一致。如果是第一次做开局后先检查所有直连链路能不能互相ping通这个基础没确认就直接配置路由协议后面排错会分不清是链路问题还是协议问题。3. 基础配置与双向重发布落地3.1 OSPF侧基础配置先配置纯OSPF域的路由器R1interface Loopback0 ip address 1.1.1.1 255.255.255.255 ! interface GigabitEthernet0/0 ip address 192.168.12.1 255.255.255.0 ! router ospf 1 router-id 1.1.1.1 network 1.1.1.1 0.0.0.0 area 0 network 192.168.12.0 0.0.0.255 area 0边界路由器R2的OSPF部分interface Loopback0 ip address 2.2.2.2 255.255.255.255 ! interface GigabitEthernet0/0 ip address 192.168.12.2 255.255.255.0 ! interface GigabitEthernet0/1 ip address 192.168.23.2 255.255.255.0 ! router ospf 1 router-id 2.2.2.2 network 192.168.12.0 0.0.0.255 area 0 network 192.168.23.0 0.0.0.255 area 0network命令宣告的是接口所在网段必须精确匹配接口掩码和反掩码。很多人习惯直接写network 0.0.0.0 0.0.0.0虽然能跑通但实验里不建议这么干原因后面排错时会讲到。3.2 RIP侧基础配置边界路由器R3的RIP部分interface GigabitEthernet0/0 ip address 192.168.23.3 255.255.255.0 ! interface GigabitEthernet0/1 ip address 192.168.34.3 255.255.255.0 ! router rip version 2 network 192.168.23.0 network 192.168.34.0 no auto-summaryR4的RIP配置interface Loopback0 ip address 4.4.4.4 255.255.255.255 ! interface GigabitEthernet0/0 ip address 192.168.34.4 255.255.255.0 ! router rip version 2 network 192.168.34.0 no auto-summaryRIP配置里no auto-summary这条建议写上尤其在做重发布实验时自动汇总会把细路由折叠成主类网络干扰观察。3.3 边界设备执行双向重发布这一步才是实验的核心。R2上写router ospf 1 redistribute rip subnets metric-type 1 ! router rip redistribute ospf 1 metric 1R3上写router ospf 1 redistribute rip subnets metric-type 1 ! router rip redistribute ospf 1 metric 1这里有几个关键字必须解释清楚。OSPF进程里redistribute rip后面的subnets意思是把RIP的子网路由也带进来如果不写OSPF只接受无类别边界上的主类路由很多细网段会在重发布时消失。metric-type 1让外部路由带上OSPF区域内部开销一起计算一般建议重发布都写它。RIP进程里redistribute ospf 1 metric 1表示从OSPF引入的路由在RIP里的跳数初始值如果不写路由会直接不可达这个坑我下一节专门讲。配置完之后理论上R1应该能看到4.4.4.4R4应该能看到1.1.1.1。先看R1show ip route | include 4.4.4.4正常情况下会看到一条O E1或O E2的外部路由下一跳指向R2。R4上应该看到一条R开头的路由指向R3。到这里实验的最基本目标已经达成但这才只是开始。4. 种子度量值最隐蔽的一个坑4.1 各种协议重发布的默认种子度量重发布时被引入协议需要把源协议路由的度量翻译成自己的度量这个翻译初始值就叫种子度量。不同协议的默认情况差异非常大我整理了一张表重发布目标协议默认种子度量是否可用OSPF无指定时默认20metric-type默认E2可用RIP默认不可达必须显式指定metric不可用EIGRP带宽、延迟、可靠性、负载、MTU全部为0不可用BGP沿用源IGP度量可用所以重发布进OSPF相对宽松不指定metric也能通只是默认值是20重发布进RIP和EIGRP就严格多了不指定种子度量对方协议根本不会认为这是一条可用路由。4.2 RIP侧丢路由的真实原因我第一次做实验时只写了redistribute ospf 1没有跟metric结果R4上死活看不到R1的环回路由。查了半天才发现RIP收到一条种子度量为0或者不可达的外部路由后直接把它当成无效路由处理不会通告给邻居。这类问题在模拟器上表现为静默丢路由没有任何报错非常容易把人带偏。解决办法就是加上metric参数比如metric 1或者metric 2。实际项目中我习惯给RIP引入的路由统一设metric 2预留一点调整空间。4.3 OSPF侧默认20与E1/E2差异OSPF这边如果不特意写metric-type重发布进去的路由默认是E2类型对外开销固定显示20不会累加OSPF区域内部的路径开销。在小型实验环境里这条影响不大但在多区域网络中E2会让远端路由器误以为边界离自己很近导致选路失真。我在实验里对比过两种写法同样在R1上查看4.4.4.4写redistribute rip subnets时路由显示为O E2cost固定20。写redistribute rip subnets metric-type 1时路由显示为O E1cost会累加R1到R2这条链路自身的开销。这个差别在排线上看得很清楚。所以我在实际项目里除非有特殊需求重发布到OSPF一律写metric-type 1让外部路由的路径开销更贴近真实拓扑。5. 次优路径与路由回灌把环路看透彻5.1 双边界双向重发布后发生了什么当两台边界设备都在做双向重发布时路由表的表象很可能一切正常但RIP数据库和OSPF外部LSA里已经出现了一堆“不该存在”的路由条目。我在R2上执行show ip route | include 1.1.1.1R2既能通过OSPF从R1学到1.1.1.1也能通过RIP从R3收到一条被重新重发布回来的1.1.1.1。由于OSPF的管理距离是110RIP是120最终选路会走OSPF看起来没问题。但再往深处看R3会把从RIP收到的1.1.1.1又重发布回OSPF区域等于把R1的原始路由包装成了一条OSPF外部路由再次送回给它本来的归属区域。这就是路由回灌。单台边界设备上管理距离能帮忙掩盖问题但回灌导致的外部LSA会在OSPF区域里扩散。如果拓扑再多几台双边界设备反复回灌会让同一前缀出现多条来源路由表膨胀排障时根本分不清哪个下一跳是真实的。5.2 一个典型次优路径的产生过程次优路径的问题在R3上看最明显。R3到R4的环回4.4.4.4明明是通过RIP从直连的R4学到度量只有1跳但在双边界同时重发布之后R2已经通过OSPF重发布了一条4.4.4.4的外部路由到R3。OSPF的管理距离110低于RIP的120于是R3认为去往4.4.4.4应该走R2那边而不是走直连的R4。在R3上执行show ip route 4.4.4.4看到的结果就是去往4.4.4.4的下一跳被指向了R2一个明显的绕路路径。这就是典型的次优路径现实中如果R4后面拖着一大片业务网段整段流量都会因此绕路严重时还会产生环路振荡。5.3 为什么管理距离救不了你很多人以为管理距离能兜底实验做完就不会去处理回灌。但管理距离只解决同一台设备上多个协议来源的选路优先级解决不了路由在整个协议域里传播的路径问题。回灌后的外部路由依然会在OSPF里扩散依然会抢占某些设备的选路表依然会增加故障时的排查难度。依赖管理距离的结果就是单点拓扑看着正常一旦设备数量增加问题就开始显现。所以生产环境做重发布一定要在边界上主动控制路由的流向而不是指望选路规则自动把一切理顺。6. 用route-map、prefix-list和tag把边界收紧6.1 用prefix-list阻断本区域回灌路由最基本的控制办法是在重发布出方向做过滤。比如R3上要从RIP往OSPF重发布就先把1.1.1.1这条从OSPF流过去又流回来的路由拒绝掉。配置如下ip prefix-list DENY_LOOP seq 5 permit 1.1.1.1/32 ! route-map NO_BACKFLOW deny 10 match ip address prefix-list DENY_LOOP ! route-map NO_BACKFLOW permit 20 ! router ospf 1 redistribute rip subnets metric-type 1 route-map NO_BACKFLOWroute-map里的规则很有讲究先deny匹配到的回灌路由再用permit放行其余所有路由。如果只写deny部分忘了permit会导致所有RIP路由都无法进入OSPF整个区域直接断连。6.2 用tag标记穿越路由从根源掐断循环比直接过滤地址更工程化的做法是打tag。原理是在第一次重发布进入协议域时给路由打上一个特殊标记之后其他边界再遇到这个标记就知道这条路由已经穿过一次了直接丢弃。R2往OSPF重发布RIP路由时打tagrouter ospf 1 redistribute rip subnets metric-type 1 tag 200R3从RIP往OSPF重发布时检查并丢弃带tag 200的条目route-map DROP_TAG deny 10 match tag 200 ! route-map DROP_TAG permit 20 ! router ospf 1 redistribute rip subnets metric-type 1 route-map DROP_TAG打tag的方式比单纯匹配网段更健壮因为不管网段怎么变只要路由被边界标记过就能被统一识别和拦下来。这在大型多点重发布场景中是标准做法。6.3 用distance调整外部路由优先级次优路径问题也可以从选路优先级上做补救。比如我希望R3在OSPF外部路由和RIP直连路由之间优先选择RIP可以针对4.4.4.0这个网段调整OSPF的管理距离access-list 10 permit 4.4.4.0 0.0.0.255 ! router ospf 1 distance 130 0.0.0.0 255.255.255.255 10这样R3看到的4.4.4.4OSPF路径的管理距离变成了130大于RIP的120选路就会回到RIP直连路径上。不过distance方案属于补救措施只适用于边界设备少、规则简单的情况。生产环境里还是优先考虑用过滤和tag从传播链路上切断问题。7. 实验验证与排错命令清单7.1 验证重发布效果的关键命令重发布做完后不能光看路由表里有路由就收工要把下面几条命令都跑一遍命令作用show ip route看最终选路结果区分内部路由和外部路由show ip protocols看协议进程里重发布相关的配置摘要show ip ospf database看OSPF区域里的外部LSA能发现回灌条目show ip rip database看RIP进程里的路由数据库确认外部路由是否被接收debug ip rip观察RIP更新报文查看路由在RIP中的真实通告过程尤其建议在配置重发布后执行show ip protocols它会直接列出当前进程里的redistributing配置、种子度量和route-map关联情况万一配置漏了关键字一眼就能看出来。7.2 我的排错顺序做这个实验过程中我踩了几次坑慢慢总结出了一套固定的排查顺序先看边界自身路由表。边界上如果没有目标路由重发布无从谈起。确认源协议的路由状态。是直连、静态还是通过协议学到的内部路由状态不同会影响重发布结果比如有些协议默认不重发布直连以外的路由需要额外写redistribute connected。检查种子度量。RIP和EIGRP引入路由时最容易在这里出问题。查route-map和过滤策略。配置了过滤后路由消失十有八九是ACL或者prefix-list顺序写错。最后看回灌和次优路径。回到边界数据库检查是否有本区域前缀被重新引入进来。这套顺序照这个顺序走绝大多数重发布异常都逃不掉。7.3 几次翻车记录第一次翻车是RIP侧漏写metric花了半小时查为什么R4学不到1.1.1.1最后show ip rip database才发现路由在边界上就没有被通告出去。第二次翻车是OSPF侧忘了写subnetsR1上只看得到RIP区域的主类路由细网段全部消失。第三次翻车是在route-map里只写了deny规则没写permit导致RIP路由进不了OSPF整个区域路由表半空。三次翻车总结成一句话重发布实验的每一个关键字都有存在理由少写一个报错不一定出现但路由一定会丢得很隐蔽。最后再分享一点实用经验这个实验做完之后我对重发布最大的体会是命令本身几分钟就能配完真正的工作量在控制路由流向。我现在做重发布方案时都会给每个边界重发布点做一张表标明源协议、目标协议、种子度量、metric-type、tag编号和过滤策略割接前照着表逐项核对。额外分享一个小技巧如果测试时发现某条路由时通时不通先别急着加静态路由兜底。加静态路由只能把现象压下去回灌和环路隐患还在割接后一旦爆发排查难度会成倍增加。正确做法是在边界路由器上检查这条路由的来源和传播路径把真正的问题堵在源头。这个实验后续还可以往两个方向扩展一个是换成OSPF和BGP之间的重发布另一个是做成多点双向重发布。后者复杂度会明显上升但只要把今天这套基础跑通往哪个方向走都不会太吃力。 
长河君 · 2026/10/20 14:15:30 · 阅读 1.2k OSPF与RIP双向重发布实战：种子度量与次优路径详解
我还记得第一次正儿八经给两套协议域做互通的场景一边是稳定跑了多年的OSPF核心另一边是设备选型被迫保留的RIP区域业务又要求两边路由全局可达。当时在模拟环境里把“重发布实验”跑了好几轮才把redistribute这条命令背后的种子度量、路由回灌和次优路径彻底摸清楚。这篇文章就按我实际动手的顺序把这次实验的完整过程记录下来给准备做网络割接、或者正在啃路由交换认证的朋友做个参考。1. 为什么要练重发布多协议共存的现实场景1.1 三个必须用重发布的真实场景我在做网络方案时总结过凡是涉及到重发布的基本都是下面这三种情况之一。第一种是网络演进改造。老网络用老协议跑了好几年核心设备不能停机新区域或者新设备又只能支持新的协议两边没法强行统一只能在边界路由器上做路由互相引入。第二种是企业合并或者部门划转。两个单位各有各的路由协议规划合并之后网络要通但不可能立刻推倒重来重发布是最务实的过渡手段。第三种是厂商替换。原来用的一套私有协议换成新厂商设备后对方只认标准协议这个过渡阶段也得靠重发布把边界撑住。这三种情况的共同点是网络不是一张白纸协议在短期内无法统一但业务要求所有网段能够互通。这时候重发布就是唯一能把两张协议网络“缝”在一起的手段。1.2 为什么实验选OSPF和RIP组合有人可能会问RIP在生产环境都快绝迹了练它还有什么价值。我的看法恰恰相反RIP在重发布实验里是最好的对照组。RIP的度量是跳数OSPF的度量是接口开销两者反差极大能非常直观地暴露出种子度量不一致带来的选路问题。再加上RIP从其他协议引入路由时存在默认度量不可达这个经典坑几乎每个第一次做实验的人都会在这里被绊一下这个坑的价值比学一堆高级协议命令大得多。把OSPF和RIP这套练明白之后再去做OSPF和BGP、OSPF和EIGRP之间的重发布就只是换参数和换关键字的问题了。底层逻辑完全相同。2. 实验拓扑、编址与模拟器准备2.1 拓扑结构与地址规划本次实验我用四台路由器组成一条串形拓扑R1是纯OSPF域设备R4是纯RIP域设备R2和R3各自同时运行OSPF和RIP充当两个协议域的边界。链路和环回规划如下设备接口IP地址归属协议R1Loopback01.1.1.1/32OSPFR1GigabitEthernet0/0192.168.12.1/24OSPF 区域0R2Loopback02.2.2.2/32OSPFR2GigabitEthernet0/0192.168.12.2/24OSPF 区域0R2GigabitEthernet0/1192.168.23.2/24OSPF 区域0 RIPR3Loopback03.3.3.3/32RIPR3GigabitEthernet0/0192.168.23.3/24RIP OSPF 区域0R3GigabitEthernet0/1192.168.34.3/24RIPR4Loopback04.4.4.4/32RIPR4GigabitEthernet0/0192.168.34.4/24RIP为什么故意让R2和R3两台边界都做双向重发布因为单向重发布只能验证命令写得对不对体现不出路由回灌和次优路径这些真正会咬人的问题。只有双边界同时双向重发布才能完整复现生产环境中常见的环路隐患。2.2 协议区域划分OSPF进程1区域0成员是R1、R2、R3三台设备RIP v2成员是R2、R3、R4三台设备。注意R2和R3同时属于两个协议域这正是现实中边界设备的典型状态。这里有一个设计上的取舍需要说明我把R2和R3之间的边界链路同时宣告进了OSPF和RIP让同一接口同时属于两个协议这样能更清晰地看出路由在不同协议里的传播路径。实际工程中边界设备通常把两种协议的接口物理隔离开但实验保留这种做法可以更直观地观察路由来源不影响对重发布核心原理的理解。2.3 模拟器选择与准备工作设备用GNS3或者EVE-NG都行。我这次用的是EVE-NG优点是可以同时开多台设备配置完丢在那里跑一天也不掉线。GNS3更轻量单机学习完全够用。无论用哪个建议每台路由器至少分配512MB内存把控制台日志输出关掉不然反复debug的时候终端刷新会让人崩溃。镜像我统一用的企业级路由器镜像保持命令一致。如果是第一次做开局后先检查所有直连链路能不能互相ping通这个基础没确认就直接配置路由协议后面排错会分不清是链路问题还是协议问题。3. 基础配置与双向重发布落地3.1 OSPF侧基础配置先配置纯OSPF域的路由器R1interface Loopback0 ip address 1.1.1.1 255.255.255.255 ! interface GigabitEthernet0/0 ip address 192.168.12.1 255.255.255.0 ! router ospf 1 router-id 1.1.1.1 network 1.1.1.1 0.0.0.0 area 0 network 192.168.12.0 0.0.0.255 area 0边界路由器R2的OSPF部分interface Loopback0 ip address 2.2.2.2 255.255.255.255 ! interface GigabitEthernet0/0 ip address 192.168.12.2 255.255.255.0 ! interface GigabitEthernet0/1 ip address 192.168.23.2 255.255.255.0 ! router ospf 1 router-id 2.2.2.2 network 192.168.12.0 0.0.0.255 area 0 network 192.168.23.0 0.0.0.255 area 0network命令宣告的是接口所在网段必须精确匹配接口掩码和反掩码。很多人习惯直接写network 0.0.0.0 0.0.0.0虽然能跑通但实验里不建议这么干原因后面排错时会讲到。3.2 RIP侧基础配置边界路由器R3的RIP部分interface GigabitEthernet0/0 ip address 192.168.23.3 255.255.255.0 ! interface GigabitEthernet0/1 ip address 192.168.34.3 255.255.255.0 ! router rip version 2 network 192.168.23.0 network 192.168.34.0 no auto-summaryR4的RIP配置interface Loopback0 ip address 4.4.4.4 255.255.255.255 ! interface GigabitEthernet0/0 ip address 192.168.34.4 255.255.255.0 ! router rip version 2 network 192.168.34.0 no auto-summaryRIP配置里no auto-summary这条建议写上尤其在做重发布实验时自动汇总会把细路由折叠成主类网络干扰观察。3.3 边界设备执行双向重发布这一步才是实验的核心。R2上写router ospf 1 redistribute rip subnets metric-type 1 ! router rip redistribute ospf 1 metric 1R3上写router ospf 1 redistribute rip subnets metric-type 1 ! router rip redistribute ospf 1 metric 1这里有几个关键字必须解释清楚。OSPF进程里redistribute rip后面的subnets意思是把RIP的子网路由也带进来如果不写OSPF只接受无类别边界上的主类路由很多细网段会在重发布时消失。metric-type 1让外部路由带上OSPF区域内部开销一起计算一般建议重发布都写它。RIP进程里redistribute ospf 1 metric 1表示从OSPF引入的路由在RIP里的跳数初始值如果不写路由会直接不可达这个坑我下一节专门讲。配置完之后理论上R1应该能看到4.4.4.4R4应该能看到1.1.1.1。先看R1show ip route | include 4.4.4.4正常情况下会看到一条O E1或O E2的外部路由下一跳指向R2。R4上应该看到一条R开头的路由指向R3。到这里实验的最基本目标已经达成但这才只是开始。4. 种子度量值最隐蔽的一个坑4.1 各种协议重发布的默认种子度量重发布时被引入协议需要把源协议路由的度量翻译成自己的度量这个翻译初始值就叫种子度量。不同协议的默认情况差异非常大我整理了一张表重发布目标协议默认种子度量是否可用OSPF无指定时默认20metric-type默认E2可用RIP默认不可达必须显式指定metric不可用EIGRP带宽、延迟、可靠性、负载、MTU全部为0不可用BGP沿用源IGP度量可用所以重发布进OSPF相对宽松不指定metric也能通只是默认值是20重发布进RIP和EIGRP就严格多了不指定种子度量对方协议根本不会认为这是一条可用路由。4.2 RIP侧丢路由的真实原因我第一次做实验时只写了redistribute ospf 1没有跟metric结果R4上死活看不到R1的环回路由。查了半天才发现RIP收到一条种子度量为0或者不可达的外部路由后直接把它当成无效路由处理不会通告给邻居。这类问题在模拟器上表现为静默丢路由没有任何报错非常容易把人带偏。解决办法就是加上metric参数比如metric 1或者metric 2。实际项目中我习惯给RIP引入的路由统一设metric 2预留一点调整空间。4.3 OSPF侧默认20与E1/E2差异OSPF这边如果不特意写metric-type重发布进去的路由默认是E2类型对外开销固定显示20不会累加OSPF区域内部的路径开销。在小型实验环境里这条影响不大但在多区域网络中E2会让远端路由器误以为边界离自己很近导致选路失真。我在实验里对比过两种写法同样在R1上查看4.4.4.4写redistribute rip subnets时路由显示为O E2cost固定20。写redistribute rip subnets metric-type 1时路由显示为O E1cost会累加R1到R2这条链路自身的开销。这个差别在排线上看得很清楚。所以我在实际项目里除非有特殊需求重发布到OSPF一律写metric-type 1让外部路由的路径开销更贴近真实拓扑。5. 次优路径与路由回灌把环路看透彻5.1 双边界双向重发布后发生了什么当两台边界设备都在做双向重发布时路由表的表象很可能一切正常但RIP数据库和OSPF外部LSA里已经出现了一堆“不该存在”的路由条目。我在R2上执行show ip route | include 1.1.1.1R2既能通过OSPF从R1学到1.1.1.1也能通过RIP从R3收到一条被重新重发布回来的1.1.1.1。由于OSPF的管理距离是110RIP是120最终选路会走OSPF看起来没问题。但再往深处看R3会把从RIP收到的1.1.1.1又重发布回OSPF区域等于把R1的原始路由包装成了一条OSPF外部路由再次送回给它本来的归属区域。这就是路由回灌。单台边界设备上管理距离能帮忙掩盖问题但回灌导致的外部LSA会在OSPF区域里扩散。如果拓扑再多几台双边界设备反复回灌会让同一前缀出现多条来源路由表膨胀排障时根本分不清哪个下一跳是真实的。5.2 一个典型次优路径的产生过程次优路径的问题在R3上看最明显。R3到R4的环回4.4.4.4明明是通过RIP从直连的R4学到度量只有1跳但在双边界同时重发布之后R2已经通过OSPF重发布了一条4.4.4.4的外部路由到R3。OSPF的管理距离110低于RIP的120于是R3认为去往4.4.4.4应该走R2那边而不是走直连的R4。在R3上执行show ip route 4.4.4.4看到的结果就是去往4.4.4.4的下一跳被指向了R2一个明显的绕路路径。这就是典型的次优路径现实中如果R4后面拖着一大片业务网段整段流量都会因此绕路严重时还会产生环路振荡。5.3 为什么管理距离救不了你很多人以为管理距离能兜底实验做完就不会去处理回灌。但管理距离只解决同一台设备上多个协议来源的选路优先级解决不了路由在整个协议域里传播的路径问题。回灌后的外部路由依然会在OSPF里扩散依然会抢占某些设备的选路表依然会增加故障时的排查难度。依赖管理距离的结果就是单点拓扑看着正常一旦设备数量增加问题就开始显现。所以生产环境做重发布一定要在边界上主动控制路由的流向而不是指望选路规则自动把一切理顺。6. 用route-map、prefix-list和tag把边界收紧6.1 用prefix-list阻断本区域回灌路由最基本的控制办法是在重发布出方向做过滤。比如R3上要从RIP往OSPF重发布就先把1.1.1.1这条从OSPF流过去又流回来的路由拒绝掉。配置如下ip prefix-list DENY_LOOP seq 5 permit 1.1.1.1/32 ! route-map NO_BACKFLOW deny 10 match ip address prefix-list DENY_LOOP ! route-map NO_BACKFLOW permit 20 ! router ospf 1 redistribute rip subnets metric-type 1 route-map NO_BACKFLOWroute-map里的规则很有讲究先deny匹配到的回灌路由再用permit放行其余所有路由。如果只写deny部分忘了permit会导致所有RIP路由都无法进入OSPF整个区域直接断连。6.2 用tag标记穿越路由从根源掐断循环比直接过滤地址更工程化的做法是打tag。原理是在第一次重发布进入协议域时给路由打上一个特殊标记之后其他边界再遇到这个标记就知道这条路由已经穿过一次了直接丢弃。R2往OSPF重发布RIP路由时打tagrouter ospf 1 redistribute rip subnets metric-type 1 tag 200R3从RIP往OSPF重发布时检查并丢弃带tag 200的条目route-map DROP_TAG deny 10 match tag 200 ! route-map DROP_TAG permit 20 ! router ospf 1 redistribute rip subnets metric-type 1 route-map DROP_TAG打tag的方式比单纯匹配网段更健壮因为不管网段怎么变只要路由被边界标记过就能被统一识别和拦下来。这在大型多点重发布场景中是标准做法。6.3 用distance调整外部路由优先级次优路径问题也可以从选路优先级上做补救。比如我希望R3在OSPF外部路由和RIP直连路由之间优先选择RIP可以针对4.4.4.0这个网段调整OSPF的管理距离access-list 10 permit 4.4.4.0 0.0.0.255 ! router ospf 1 distance 130 0.0.0.0 255.255.255.255 10这样R3看到的4.4.4.4OSPF路径的管理距离变成了130大于RIP的120选路就会回到RIP直连路径上。不过distance方案属于补救措施只适用于边界设备少、规则简单的情况。生产环境里还是优先考虑用过滤和tag从传播链路上切断问题。7. 实验验证与排错命令清单7.1 验证重发布效果的关键命令重发布做完后不能光看路由表里有路由就收工要把下面几条命令都跑一遍命令作用show ip route看最终选路结果区分内部路由和外部路由show ip protocols看协议进程里重发布相关的配置摘要show ip ospf database看OSPF区域里的外部LSA能发现回灌条目show ip rip database看RIP进程里的路由数据库确认外部路由是否被接收debug ip rip观察RIP更新报文查看路由在RIP中的真实通告过程尤其建议在配置重发布后执行show ip protocols它会直接列出当前进程里的redistributing配置、种子度量和route-map关联情况万一配置漏了关键字一眼就能看出来。7.2 我的排错顺序做这个实验过程中我踩了几次坑慢慢总结出了一套固定的排查顺序先看边界自身路由表。边界上如果没有目标路由重发布无从谈起。确认源协议的路由状态。是直连、静态还是通过协议学到的内部路由状态不同会影响重发布结果比如有些协议默认不重发布直连以外的路由需要额外写redistribute connected。检查种子度量。RIP和EIGRP引入路由时最容易在这里出问题。查route-map和过滤策略。配置了过滤后路由消失十有八九是ACL或者prefix-list顺序写错。最后看回灌和次优路径。回到边界数据库检查是否有本区域前缀被重新引入进来。这套顺序照这个顺序走绝大多数重发布异常都逃不掉。7.3 几次翻车记录第一次翻车是RIP侧漏写metric花了半小时查为什么R4学不到1.1.1.1最后show ip rip database才发现路由在边界上就没有被通告出去。第二次翻车是OSPF侧忘了写subnetsR1上只看得到RIP区域的主类路由细网段全部消失。第三次翻车是在route-map里只写了deny规则没写permit导致RIP路由进不了OSPF整个区域路由表半空。三次翻车总结成一句话重发布实验的每一个关键字都有存在理由少写一个报错不一定出现但路由一定会丢得很隐蔽。最后再分享一点实用经验这个实验做完之后我对重发布最大的体会是命令本身几分钟就能配完真正的工作量在控制路由流向。我现在做重发布方案时都会给每个边界重发布点做一张表标明源协议、目标协议、种子度量、metric-type、tag编号和过滤策略割接前照着表逐项核对。额外分享一个小技巧如果测试时发现某条路由时通时不通先别急着加静态路由兜底。加静态路由只能把现象压下去回灌和环路隐患还在割接后一旦爆发排查难度会成倍增加。正确做法是在边界路由器上检查这条路由的来源和传播路径把真正的问题堵在源头。这个实验后续还可以往两个方向扩展一个是换成OSPF和BGP之间的重发布另一个是做成多点双向重发布。后者复杂度会明显上升但只要把今天这套基础跑通往哪个方向走都不会太吃力。