我还记得第一次正儿八经给两套协议域做互通的场景：一边是稳定跑了多年的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地址 | 归属协议 |
|---|---|---|---|
| R1 | Loopback0 | 1.1.1.1/32 | OSPF |
| R1 | GigabitEthernet0/0 | 192.168.12.1/24 | OSPF 区域0 |
| R2 | Loopback0 | 2.2.2.2/32 | OSPF |
| R2 | GigabitEthernet0/0 | 192.168.12.2/24 | OSPF 区域0 |
| R2 | GigabitEthernet0/1 | 192.168.23.2/24 | OSPF 区域0 + RIP |
| R3 | Loopback0 | 3.3.3.3/32 | RIP |
| R3 | GigabitEthernet0/0 | 192.168.23.3/24 | RIP + OSPF 区域0 |
| R3 | GigabitEthernet0/1 | 192.168.34.3/24 | RIP |
| R4 | Loopback0 | 4.4.4.4/32 | RIP |
| R4 | GigabitEthernet0/0 | 192.168.34.4/24 | RIP |
为什么故意让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域的路由器R1：
interface 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.4，R4应该能看到1.1.1.1。先看R1：
show ip route | include 4.4.4.4正常情况下会看到一条O E1或O E2的外部路由，下一跳指向R2。R4上应该看到一条R开头的路由指向R3。到这里实验的最基本目标已经达成，但这才只是开始。
4. 种子度量值：最隐蔽的一个坑
4.1 各种协议重发布的默认种子度量
重发布时，被引入协议需要把源协议路由的度量翻译成自己的度量，这个翻译初始值就叫种子度量。不同协议的默认情况差异非常大，我整理了一张表：
| 重发布目标协议 | 默认种子度量 | 是否可用 |
|---|---|---|
| OSPF | 无指定时默认20，metric-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 E2，cost固定20。
- 写redistribute rip subnets metric-type 1时，路由显示为O E1，cost会累加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的管理距离是110，RIP是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路由时打tag：
router 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.4，OSPF路径的管理距离变成了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侧忘了写subnets，R1上只看得到RIP区域的主类路由，细网段全部消失。第三次翻车是在route-map里只写了deny规则没写permit，导致RIP路由进不了OSPF，整个区域路由表半空。
三次翻车总结成一句话：重发布实验的每一个关键字都有存在理由，少写一个，报错不一定出现，但路由一定会丢得很隐蔽。
最后再分享一点实用经验
这个实验做完之后，我对重发布最大的体会是：命令本身几分钟就能配完，真正的工作量在控制路由流向。我现在做重发布方案时，都会给每个边界重发布点做一张表，标明源协议、目标协议、种子度量、metric-type、tag编号和过滤策略，割接前照着表逐项核对。
额外分享一个小技巧：如果测试时发现某条路由时通时不通，先别急着加静态路由兜底。加静态路由只能把现象压下去，回灌和环路隐患还在，割接后一旦爆发，排查难度会成倍增加。正确做法是在边界路由器上检查这条路由的来源和传播路径，把真正的问题堵在源头。
这个实验后续还可以往两个方向扩展，一个是换成OSPF和BGP之间的重发布，另一个是做成多点双向重发布。后者复杂度会明显上升，但只要把今天这套基础跑通，往哪个方向走都不会太吃力。
