1. 重发布实验：先搞清楚它解决什么问题
做网络运维这几年，多协议互通的活儿没少碰。公司某个区域跑OSPF，另一个区域因为历史原因一直用RIP，两边业务要打通，靠的就是路由重发布，也就是业内常说的 route redistribution。前阵子我在实验室搭了一套多协议互通环境，把重发布从单向注入做到双向发布，从种子度量值调整做到环路抑制，完整过了一遍。今天把这套实验整理出来，顺便把踩过的坑和排查思路一起说清楚。
这套实验主要适合三类人：刚接触动态路由的工程师、准备网络认证考试的人，以及日常要维护混合协议网络的运维朋友。实验本身不复杂，三台路由器就能搭起来，但里面涉及的知识点非常密集。重发布表面上就是几条命令的事，真正难的是理解它背后的度量值换算、外部路由标记、以及双向重发布带来的环路风险。这些都是生产环境里最容易出问题的地方。
我自己的习惯是，遇到这类知识点，先在实验环境里把各种异常情况造出来，再一个一个排除，比直接背命令有效得多。下面就从重发布为什么存在讲起，把整个实验过程和关键细节都过一遍。
1.1 为什么网络里会同时存在多种路由协议
很多人一开始会有疑问：既然OSPF这么好用，为什么不全网统一用OSPF？理论上当然可以，但现实世界从来没那么理想。最常见的情况是公司合并，A公司整个网络跑的是OSPF，B公司那边一直用RIP，并购之后网络要打通，总不能把B公司整个重新规划一遍，周期太长，成本也高。这时候就需要在边界设备上做重发布，先让两边互通，后续再慢慢迁移。
还有一种情况是历史遗留。老网络设备上线年代早，当时技术选型有限，跑的协议可能是RIP或者静态路由。新区域的设备性能强、规模大，普遍用OSPF。两个时代的网络要对接，自然形成了多协议并存的局面。另外，不同团队运维习惯也不一样，有的团队对OSPF熟悉，有的团队对RIP更熟练，各自维护自己的片区，边界上就需要一个"翻译"的角色。
只要出现这种多协议共存的场景，重发布就是绕不开的环节。它不一定是最优解，但它是当下成本最低、最快的解决方案。
1.2 重发布的本质：协议间的翻译官
重发布说白了就是让一种路由协议学习到的路由信息，经过边界路由器转换之后，注入到另一种协议里面去，让全网都能互相学到对方的网段。这个过程很像翻译官：两个语言不通的人要对话，中间必须有人把A的话翻译成B能听懂的语言，再把B的回复翻译回A的语言。
具体到路由协议上，OSPF是链路状态协议，它维护的是整个网络的拓扑数据库，通过SPF算法计算最短路径，度量值是cost。RIP是距离矢量协议，只看跳数，超过15跳就认为不可达。两者的路由计算方式和度量标准完全不一样，所以OSPF学到的路由不能直接塞进RIP的数据库里，必须经过一次格式和度量值的转换。
我用OSPF和RIP这两套来搭实验，主要就是看中它们差异性大，能把重发布的各种细节暴露出来。这两个协议在很多真实网络里的共存概率也确实高。等把这两个玩清楚了，再看静态路由注入、EIGRP重发布这些，思路都是一样的，只是参数不同而已。
2. 实验拓扑与基础配置
2.1 拓扑设计与IP规划
实验环境不需要太复杂，三台路由器就能满足全部需求。核心设计思路是让R1和R2之间跑RIP，R2和R3之间跑OSPF，R2作为两个协议的边界，负责做双向重发布。为了模拟真实的业务网段，每台设备上再开一个Loopback接口，Loopback地址在路由协议里通告出去，用来后面验证远端可达性。
我用的IP规划如下：
| 设备 | 接口 | IP地址 | 用途 |
|---|---|---|---|
| R1 | Gig0/0 | 10.10.12.1/24 | 连接R2 |
| R1 | Loopback0 | 10.10.1.1/24 | 模拟左侧业务网段 |
| R2 | Gig0/0 | 10.10.12.2/24 | 连接R1 |
| R2 | Gig0/1 | 10.10.23.2/24 | 连接R3 |
| R2 | Loopback0 | 2.2.2.2/32 | 模拟管理网段 |
| R3 | Gig0/0 | 10.10.23.3/24 | 连接R2 |
| R3 | Loopback0 | 10.10.3.1/24 | 模拟右侧业务网段 |
这个规划的核心点在于：RIP侧有两段需要被RIP学习到的网段，分别是10.10.12.0/24和10.10.1.0/24；OSPF侧有两段，分别是10.10.23.0/24和10.10.3.0/24。重发布完成之后，R1应该能学到10.10.3.0/24，R3应该能学到10.10.1.0/24，这就相当于跨协议打通了。
2.2 接口与链路的基础配置
先做最基础的接口配置，确保三层链路是通的。以R1为例：
interface GigabitEthernet0/0 ip address 10.10.12.1 255.255.255.0 no shutdown ! interface Loopback0 ip address 10.10.1.1 255.255.255.0R2和R3的接口配置类似，只是IP地址按表格里的规划填写。配置完之后，建议先做一轮连通性测试，R1能ping通R2的Gig0/0地址10.10.12.2，R3能ping通R2的Gig0/1地址10.10.23.2，这是后续所有工作的前提。
很多初学者习惯一上来就直接写路由协议，结果排障的时候发现链路本身就不通，白折腾半天。先把物理层和三层连通性验证好，后面每一步都心里有数。
2.3 先把RIP和OSPF各自跑起来
接口配好之后，开始配置动态路由协议。RIP侧只涉及R1和R2，R2上连接R3的接口不要运行RIP，否则RIP会试图从R2到R3的链路上发广播，造成不必要的协议流量，也可能把直连路由泄露到协议里，干扰重发布的结果。
R1的RIP配置如下：
router rip version 2 network 10.0.0.0 no auto-summaryR2上也配置同样的RIP，但要在连接R3的接口上设置静默接口：
router rip version 2 network 10.0.0.0 no auto-summary passive-interface GigabitEthernet0/1R2和R3的OSPF配置如下：
router ospf 1 router-id 2.2.2.2 network 10.10.23.0 0.0.0.255 area 0R3上把router-id换成3.3.3.3，network宣告自己连接R2的接口和Loopback0。R2连接R1的接口不应该出现在OSPF配置里，同样的道理，避免OSPF在RIP侧产生无关的邻接和路由。
配置完成后，在R1上执行show ip route，应该能看到RIP学习到的路由，包括10.10.1.0/24和10.10.12.0/24。在R3上执行show ip route，应该能看到OSPF学习到的路由，包括10.10.23.0/24和10.10.3.0/24。这个阶段两边各自为政，R1看不到R3的网段，R3也看不到R1的网段，重发布还没开始生效。
3. 核心实操：从单向注入到双向重发布
3.1 把RIP重发布进OSPF
基础路由都跑起来之后，开始做重发布第一步：把RIP侧的路由注入到OSPF里面去。这样OSPF域的R3就能学到R1的Loopback网段了。操作在R2上进行：
router ospf 1 redistribute rip subnets metric 100命令里有两个关键点必须讲清楚。第一个是subnets参数。OSPF在重发布外部路由的时候，默认只发布主类网络，如果不加subnets，像10.10.1.0/24这种子网掩码不是默认主类掩码的路由，根本不会被注入到OSPF里。很多人在这一步踩坑，以为配置没生效，其实只是缺了这个参数。
第二个是metric 100。OSPF重发布外部路由的默认种子度量值是20，如果不手动指定，外部路由会以cost 20的姿态进入OSPF域。我在实验里设置100，是为了方便后面观察外部路由的标记和选路逻辑。metric的值不是越大越好，要结合OSPF域内的链路cost来设计，保证外部的真实路径优势能在路由表里体现出来。
配置完成后，在R3上查看路由表：
show ip route ospf正常情况下会看到类似这样的输出：
O E2 10.10.1.0/24 [110/100] via 10.10.23.2, 00:01:23, GigabitEthernet0/0O E2就是OSPF外部路由的标记。E2表示外部路由类型为Type 2，它只计算重发布时配置的外部cost，不计算到达ASBR的内部路径cost。默认情况下，OSPF重发布进来的外部路由都是E2类型。后面我会在进阶部分讲E1和E2的区别以及怎么切换。
3.2 把OSPF重发布进RIP
RIP侧的方向也做一遍。把OSPF域的路由注入到RIP域，让R1能学到R3的Loopback网段。操作同样在R2上进行：
router rip version 2 redistribute ospf 1 metric 3这里有一个很容易被忽略的陷阱：RIP的默认种子度量值是16，而RIP协议里16就代表不可达。如果你只写redistribute ospf 1，不指定metric，重发布出来的路由就是不可达的，R1收到之后路由表里不会出现这条路由，效果看起来就像"没发布成功"。
所以必须显式指定metric。这里填3的意思是，从RIP的角度看，这些从OSPF学习到的网段距离是3跳。RIP的seed metric取值范围是1到15，15已经是临界值，再往上就是不可达，生产环境里建议取2到5之间比较稳妥。
配置完成后，在R1上查看路由表，应该能看到：
R 10.10.23.0/24 [120/3] via 10.10.12.2, 00:00:07, GigabitEthernet0/0 R 10.10.3.0/24 [120/3] via 10.10.12.2, 00:00:07, GigabitEthernet0/0R代表RIP路由，[120/3]里的120是RIP的管理距离，3就是刚才设置的种子度量值。到这里，单向的重发布已经完成了，RIPv3网段和OSPF网段之间通过R2这座桥实现了双向互通。
3.3 双向重发布后的路由变化
既然单向都通了，把两条命令合在一起，做成标准的双向重发布：
router ospf 1 redistribute rip subnets metric 50 ! router rip version 2 redistribute ospf 1 metric 3配置完成后，全网的路由就互通了。R1的路由表里除了本地直连和RIP学习到的路由，多出了来自OSPF域的外部路由；R3的路由表里除了本地直连和OSPF学习到的路由，多出了来自RIP域的外部路由。用ping验证一下，R1能ping通R3的Loopback地址10.10.3.1，R3能ping通R1的Loopback地址10.10.1.1，整个实验的预期效果就达成了。
不过在继续往下之前，我要多说一句：上面的双向重发布配置，在实验环境里能通，但在生产环境里是绝对不能这么直接上的。原因先放在这，后面章节专门讲环路和次优路由的时候会详细展开。
3.4 种子度量值这个坑，必须单独说
种子度量值，英文叫seed metric，是重发布里最容易出问题的地方。它的含义是：一条路由从原协议被注入到目标协议时，目标协议给它赋的初始度量值。这个值直接决定了路由在目标协议里的"身价"。
不同的协议对种子度量值的要求不一样，我把常见的几个整理了一下：
| 目标协议 | 默认种子度量值 | 需要注意的地方 |
|---|---|---|
| OSPF | 20 | 需要配合subnets使用，否则只发布主类路由 |
| RIP | 16（不可达） | 必须显式设置1-15之间的值，否则路由无效 |
| 静态路由注入IS-IS | 0 | 需要显式设置metric，否则部分实现下路由异常 |
| EIGRP | 无穷大 | 必须设置带宽、延迟等复合度量参数 |
我在实验里遇到的最典型情况就是：RIP重发布OSPF的时候忘了加metric，路由倒是出现在OSPF数据库里了，但cost都是默认的20，根本反应不出真实路径质量。还有一次是RIP侧忘了写metric，R1那边死活学不到路由，后来才发现默认值16被RIP认为是不可达，直接丢弃了。
种子度量值的设计一定要结合目标协议的特性。比如RIP只能识别跳数，你把一个跨了很多跳的路径重发布进RIP，metric设置太小，选路结果可能就和真实网络拓扑背离了，次优路径就是这么来的。设置合理的seed metric，是重发布的第一步，也是选路质量的根基。
4. 重发布常见的坑与排查实录
4.1 路由学不到？先查种子度量值和subnets
我在实验过程中反复遇到的最大的坑，就是配完重发布之后，对方路由器死活学不到路由。总结下来，大部分情况都出在下面几个点上。
第一，RIP重发布OSPF时没写subnets。OSPF默认不发布无类路由，比如10.10.1.0/24这种子网，如果redistribute命令后面不带subnets，这条路由就被吞掉了。检查方法很简单，在R2上用show ip ospf database external看有没有对应的LSDB条目，如果没有，基本就是这个原因。解决办法就是在命令末尾加上subnets。
第二，RIP重发布OSPF时忘了metric。OSPF默认种子度量值是20，这个值不是错，但会导致外部路由全部以20进入OSPF域，如果域内已经有cost更小的路径，外部路由可能被选为备份路径，路由表里显示的形式会让人误以为方向不对。真实网络里，建议显式给metric，让它匹配链路的实际质量。
第三，OSPF重发布RIP时没设metric。这个问题我在上面提过，RIP的默认种子度量值是16，16等于不可达。不设metric，R1和R2的RIP路由表里根本不会出现重发布进来的路由。这类问题用show ip route rip一眼就能看出来，路由数量是0，然后去边界路由器上看配置，十有八九是少了metric。
解决这类问题，我一般习惯按下面的顺序排查：先看目标路由器有没有收到路由，再看源路由器有没有发出路由，最后看中间转换的度量值是否合理。收到没收到是结果，中间配置是原因，度量值是变量。
4.2 次优路由与环路是怎么冒出来的
实验做完基础版本之后，我又在拓扑里加了一条冗余路径，用来模拟双向重发布最常见的两个问题：次优路由和路由环路。这两个问题如果不亲眼见过，很难理解为什么说双向重发布危险。
先讲次优路由。假设RIP域里还有另一台路由器R4，R4有一条到10.10.1.0/24的直连路由，并且这条路由通过RIP传到了R2。R4到目标网段的真实跳数是1。现在R2把OSPF学到的一条外部路由也重发布回了RIP，这条外部路由的metric是3。结果RIP域里的其他路由器可能选择走R2再绕一圈，而不直接走R4，因为RIP看不到完整拓扑，它只比较跳数。这就是次优路由。
再讲环路。双向重发布的本质是两边的路由互相倒来倒去。RIP域里有一条路由10.10.1.0/24，R2重发布进OSPF，R3学到了。如果OSPF域里还有另一台设备可以把这条路由再引回RIP域，比如通过静态路由或另一个重发布点，那么路由就可能在RIP和OSPF之间来回传递，永远收敛不了。多个边界路由器同时做双向重发布，是环路风险最高的场景。
生产和实验里验证有没有环路，最直接的办法是traceroute。如果一条目标为远端Loopback的路径，经过的跳数明显多于实际物理路径，或者出现了来回经过同一台设备的情况，基本可以断定有了环路或次优路径。这时再去边界路由器上看路由表，会看到那条路由的下一跳地址可能已经变成了一个"不该出现的邻居"。
4.3 用标记和过滤把环路掐死
解决双向重发布环路问题的思路有两个方向：一个是控制"哪些路由可以被重发布"，另一个是控制"重发布进来的路由不能再回去"。
第一个方向用prefix-list或access-list配合route-map就能实现。比如我只想让RIP域的10.10.1.0/24注入到OSPF，可以这样写：
ip prefix-list RIP-TO-OSPF seq 5 permit 10.10.1.0/24 ! route-map REDIS-TO-OSPF permit 10 match ip address prefix-list RIP-TO-OSPF set metric 100 ! router ospf 1 redistribute rip subnets route-map REDIS-TO-OSPF这样写之后，不是所有RIP路由都会进入OSPF，只有在prefix-list里允许的网段才会被注入，其他网段一概不放行。这种细粒度的控制在生产环境里非常实用，重发布之前先用route-map白名单卡一道，比直接无脑全网发布安全得多。
第二个方向用路由标记。在路由被重发布出源协议的时候，给它打一个tag，然后在边界另一边过滤掉这个tag，防止路由"回流"。比如R2把OSPF重发布进RIP的时候设置tag 200：
route-map REDIS-TO-RIP permit 10 set tag 200 ! router rip redistribute ospf 1 metric 3 route-map REDIS-TO-RIP之后在R2做RIP到OSPF方向的重发布时，就拒绝所有tag为200的路由：
route-map BLOCK-LOOP deny 10 match tag 200 ! route-map BLOCK-LOOP permit 20 ! router ospf 1 redistribute rip subnets route-map BLOCK-LOOP metric 50这样OSPF域里学习到的、被打上200标记的路由，不会再被注入回RIP域，环路的主要来源就被掐断了。我一般在生产配置里同时使用白名单和tag两种机制，白名单管方向，tag防回流，双保险。
4.4 一套顺手的排查流程与命令
重发布排障最忌讳上来就debug，容易把问题搅得更乱。我自己的经验是，先在路由器上做分层检查，从最外层的"有没有学到"一步步往内层查。
第一步，看路由表。对端设备上执行show ip route，确认目标网段是否出现在路由表里，以及标记的协议来源是什么。这能快速判定问题出在"没发布"还是"发布了但没收到"。
第二步，看协议状态。在边界路由器上执行show ip protocols，检查redistribution配置是否真的生效，route-map是否被引用，metric值是多少。这个命令会把所有路由协议的关键参数都打出来，一眼就能发现配置遗漏。
第三步，看具体协议的内部信息。OSPF侧用show ip ospf database external看外部LSA是否生成，RIP侧用show ip rip database看RIP数据库里是否有重发布过来的路由。这一步能判断问题出在发布端还是接收端。
第四步，做连通性验证。用traceroute看实际路径是否合理，用ping确认业务通断。如果路由表里有路由但ping不通，问题多半不在重发布本身，要往更底层查。
再提供一个实用技巧：实验室环境里改完配置，可以执行clear ip route *清空路由表，让协议重新收敛，比干等更新快很多。生产环境就不建议这么干了，容易造成短暂的路由震荡。
5. 实验收尾：踩过几次坑之后的体会
5.1 生产环境里我一般怎么做重发布
把整套实验做完之后，我对重发布的理解比之前单纯看文档要深得多。最大的体会是：重发布并不是什么炫技操作，它本质上是一种妥协，是在多协议并存这个"历史包袱"下的无奈之举。所以生产环境里，我的原则是能不做就不做，必须要做就严格控制范围。
具体来说，我一般会遵循几个思路。第一，能用单向重发布解决问题，就不要双向。很多业务场景其实只需要把某一侧的路由引入另一侧，让单向域名互通即可，反向可以通过静态路由或默认路由解决。双向重发布会成倍增加环路风险，必须有充分理由才做。
第二，重发布一定要配合过滤机制。不管是redistribute还是default-information originate，都必须在前面挂route-map控制好允许发布的前缀范围。我见过太多现网故障都是因为有人上了条不带过滤的重发布命令，结果把大量不该泛滥的外部路由引入核心区域，瞬间挤爆路由表。
第三，严格控制seed metric和管理距离。生产网络里每个metric值都必须有设计依据，不能随手填。管理距离的调整要尤其谨慎，重发布配合AD调整可以解决一些选路难题，但也容易引发更隐蔽的次优路径问题，改之前一定要有充分的拓扑分析。
5.2 几句真心建议
如果让我给初学网络的人一个建议，我会说：别急着跑一堆厂商的模拟器去敲命令，先把OSPF和RIP各自的路由计算逻辑吃透，再来看重发布就豁然开朗了。重发布的难点从来不在命令本身，而在于各种协议之间的度量逻辑冲突，以及这些冲突如何在真实路径中暴露出来。
我还想分享一个实测有效的学习路径：先把这个三路由器拓扑做通，然后往里面加冗余链路，手动制造次优路由和环路，再用route-map和tag把它们解决。这个过程比任何刷题都管用，因为你会亲眼看到协议之间是怎么"打架"的，也会真正理解为什么网工界都在强调控制重发布范围。这个实验做完之后，再去看现网架构里那些重发布的设计，会觉得每个配置都有它的道理。
