企业官网建设流程全解析

“重发布”在路由协议学习里的地位，有点像“递归”在编程里的地位——命令看一眼就会，背后的坑却能让你踩到怀疑人生。无数人在实验台上敲下import-route之类的一行命令之后，都会问出同一个问题：为什么路由就是不过来？为什么通了一半？为什么一会儿通一会儿断？

这篇就以一个典型的三台设备双向重发布实验为线索，把原理、配置、验证、排错一次讲透。主要面向正在备考网络工程师认证的人、日常要维护多协议网络的同学，以及所有想在模拟器里把“重发布”彻底玩明白的朋友。我会尽量少讲空泛的理论，多给直接能抄的配置和思路，因为这种东西纸上谈兵是真的学不会。

1. 实验拓扑与整体设计思路

1.1 为什么你的网络需要“重发布”

现实中一个网络不太可能从头到尾只跑一种动态路由协议。举几个常见例子：公司原本用OSPF，后来并购了另一家长期使用RIP的小团队，两边网络要打通；又或者出口路由器上有一条指向专线的静态默认路由，需要让内网所有设备都能学到。把一种协议学到的路由“搬运”到另一种协议域里，这个动作就是路由重发布。

但不同动态路由协议之间并不只是“名字不一样”那么简单。OSPF根据接口带宽计算开销（Cost），RIP看的是跳数（Hop Count），而且RIP最大只能传15跳，第16跳就是不可达。两种协议对于“这条路好不好”的判断标准完全不同，所以在搬运路由的同时，还必须解决“引进来的路由，度量值按什么算”的问题。这也解释了为什么重发布配置虽然只有几行命令，却经常出各种莫名其妙的问题。

1.2 实验拓扑与地址规划

我这次采用的拓扑非常简单：三台路由器串成一条线。

• R1 运行OSPF，环回口 Lo0 模拟一个业务网段
• R3 运行RIP，环回口 Lo0 模拟RIP侧的业务网段
• R2 是中间桥梁，同时运行OSPF和RIP，在两种协议之间做双向重发布

地址规划如下：

• R1 与 R2 互联：192.168.12.0/24
• R2 与 R3 互联：192.168.23.0/24
• R1 环回口 Lo0：10.0.1.1/32
• R3 环回口 Lo0：10.0.3.1/32

OSPF全部放在Area 0，RIP使用RIPv2。之所以把环回口地址设成不同的10.x.x.x段，是为了让路由表里看起来更清楚，验证的时候一眼就能辨别是哪一侧的业务网段。

1.3 预配置：先建邻居，再谈重发布

三台设备的接口地址和底层协议配置并不复杂，但这一步的顺序很重要。先把OSPF和RIP各自的邻居关系建立起来，确认两边都能正常通信，再去做重发布。很多人一上来就直接敲重发布命令，结果OSPF邻居根本没起来、RIP邻居也没建立成功，最后出了故障完全分不清是重发布的问题还是邻居的问题。

R1侧只需要宣告互联网段和环回网段：

interface GigabitEthernet0/0/0 ip address 192.168.12.1 255.255.255.0 # interface LoopBack0 ip address 10.0.1.1 255.255.255.255 # ospf 1 area 0.0.0.0 network 192.168.12.0 0.0.0.255 network 10.0.1.1 0.0.0.0

R3侧同理，把互联网段和环回网段宣告进RIP：

interface GigabitEthernet0/0/0 ip address 192.168.23.3 255.255.255.255 # interface LoopBack0 ip address 10.0.3.1 255.255.255.255 # rip 1 version 2 network 192.168.23.0 network 10.0.3.0

R2先把两边的接口地址配好，OSPF和RIP的邻居配置都写上，但先不要写任何import-route语句。这个时候R2的OSPF路由表里只有192.168.12.0，RIP路由表里只有192.168.23.0和10.0.3.0，两侧各玩各的。确认 R1 能 ping 通 192.168.12.2，R3 能 ping 通 192.168.23.2，再进入下一步。

2. 重发布配置思路与逐条命令拆解

2.1 单向重发布：把RIP引入OSPF

先做单向。在R2的OSPF视图里，把RIP学到的路由引入OSPF：

ospf 1 import-route rip

命令就一行，但它背后藏着一个默认值问题。OSPF引入外部路由时，默认的度量值是1，而且默认是Type-2外部路由。也就是说，如果不加任何修饰，R3环回10.0.3.1被引入OSPF后，在R1看来路径开销几乎等于“白送”，这会给后续排错和选路判断带来很多误导。

所以我在实际配置里习惯显式指定cost：

ospf 1 import-route rip cost 10

这里把默认值变成明确的10，意思就是“RIP域的路由进入OSPF域后，外部开销统一按10计算”。为什么是10？不一定非要10，但显式写一个数会让配置一目了然，也方便后面做选路实验时调整数值。

配置完成后，在R1上执行display ospf routing，能看到10.0.3.1以外部路由的形式出现。同时，这条路由也会出现在R1的全局路由表里，下一跳是192.168.12.2，说明RIP侧的业务网段已经被成功引入OSPF域。

2.2 单向重发布：把OSPF引入RIP

反过来，在R2的RIP视图里，把OSPF学到的路由引入RIP：

rip 1 import-route ospf

这个实验最大的坑之一就在这里。RIP引入外部路由时，如果不显式指定cost，默认的种子度量值直接是16，也就是无穷大。无穷大在RIP里意味着“不可达”，所以这样的路由根本不会被RIP通告出去。很多初学者配置完以后，R3上看不到任何来自OSPF域的路由，排查半天发现就是少了这个cost。

正确的写法是：

rip 1 import-route ospf cost 5

这里cost 5表示“OSPF域路由进入RIP域后，跳数按5计算”。RIP的cost就是跳数，取值范围1到15，所以你可以根据拓扑规模自己定。我选5，纯粹是为了在验证时能明显看到这条路由是从OSPF引入进来的外部路由，而不至于和RIP内部直连路由混在一起分辨不清。

2.3 双向重发布与路由回馈风险

单向都通了以后，把两边都打开，就是双向重发布。双向重发布在原理上很好理解，但真正要面对的敌人是路由回馈。

回馈的过程可以这样描述：R3的环回网段先从RIP进入R2，被R2引入OSPF，R1学到了这条路由；如果R2又无条件地把OSPF里学到的全部路由再次引入RIP，那么这条路由就会重新被“送回”RIP域。这样一来，路由在OSPF和RIP之间来回倒腾，轻则出现次优路径，重则导致路由振荡甚至环路。

OSPF协议自身有一定防环能力：当外部路由被引入OSPF时，OSPF会给它打一个tag（默认tag是1，也可以自定义）。执行第二次重发布时，OSPF会识别这些外部路由，不会再让它们重新回到OSPF域。但RIP没有这套tag机制来区分“这条路由是不是我送出去的”。所以双向重发布时，RIP引入OSPF的这个方向必须手动做过滤，这也是整个实验里最核心、最值得动手练的部分。

2.4 用tag + route-policy切断回馈路径

我的做法是：在R2的OSPF引入RIP时，给来自RIP域的路由打一个自定义tag，比如100。等RIP准备引入OSPF时，再用route-policy把带tag 100的路由全部拒掉。

具体配置如下。

第一步，在OSPF引入RIP时打tag：

ospf 1 import-route rip tag 100

第二步，创建route-policy，拒绝tag为100的路由，放行其他所有路由：

route-policy deny-tag100 deny node 10 if-match tag 100 # route-policy deny-tag100 permit node 20 #

第三步，在RIP引入OSPF时应用这个route-policy：

rip 1 import-route ospf cost 5 route-policy deny-tag100

拆开解释一下这条链路做了什么。R3的环回网段在R2的路由表里从RIP学到，被OSPF引入时打上了“tag 100”的标签。走到IR2做反向引入时，RIP要引入OSPF路由，发现这条带tag 100的路由正是自己刚才送出去的，于是直接丢掉。而R1的环回网段来自OSPF内部路由，没有tag 100，node 20的permit会把它正常放行进RIP域。

这套逻辑在实验环境中稳定可靠，也是生产环境里比较标准的防回馈姿势。还有一种更简单的替代思路：用前缀列表直接deny掉RIP侧那几条已知网段，例如明确拒绝10.0.3.0/32被再次引入RIP。在小规模实验里这样写更快，但它需要你静态维护一份网段清单，一旦后续加网段就很容易漏。tag方案虽然配置稍微多几行，但胜在“自动识别、无需手工维护”，所以我在实验里优先推荐它。

2.5 路由优先级导致的选路陷阱

做重发布时，另一个容易忽略的是不同协议的路由优先级。在设备默认配置下，常见优先级是：直连0、静态60、OSPF内部10、OSPF外部150、RIP 100。数值越小越优先。

这个优先级设定会带来一个经典问题：如果R1同时通过OSPF外部路由和RIP都能学到R3的环回，R1会优先选择RIP学到的路径，即使那条路径可能绕远。反过来，如果设备上同时存在OSPF内部路由和RIP外部路由，OSPF内部路由又会被优先选择，哪怕OSPF的cost总量远远大于RIP的跳数。

在实际设计网络时，这个优先级差异必须纳入考量。如果只想让某一条路径成为主路径，可以通过修改cost、修改路由优先级，或者配合filter-policy控制路由的引入范围来实现。实验里先理解这种优先级机制，后面遇到“路由明明存在却不走我想要的路径”时，就能快速定位是优先级问题，而不是链路故障。

3. 关键验证与抓包分析

3.1 查看OSPF和RIP路由表

配置完成后的验证，我习惯从两端往中间查。

在R1上执行：

display ospf routing

输出里会出现10.0.3.1/32，类型是External，cost是10，下一跳指向192.168.12.2。同时执行：

display ip routing-table

可以看到这条OSPF外部路由已经在全局路由表里，这就说明RIP域的业务网段已经成功传递给OSPF域。

然后在R3上执行：

display rip routing

应该能看见10.0.1.1/32，cost为5，下一跳指向192.168.23.2。同样地，再查一下全局路由表确认状态为Active。这样两端互通的验证就通过了，R1能ping通10.0.3.1，R3能ping通10.0.1.1。

验证双向防回馈是否生效，关键看R2和R3。在R3上执行display rip routing，正常情况下不会看到10.0.3.1/32这条路由又出现在RIP路由表里。如果出现了，而且下一跳指向R2，说明回馈过滤没有生效，需要回头检查route-policy的方向和tag值是否匹配。

3.2 抓包观察LSA和RIPv2报文

模拟器里的抓包功能虽然不如真实抓包工具丰富，但用来理解重发布过程足够了。

抓R1和R2之间的OSPF报文，在R2完成重发布之后，R1会收到Type-5类型的外部LSA。在这个LSA的字段里，External Route Tag就是我们在配置里打上的tag值100。Metric字段显示10，就是我们在import-route rip cost 10里指定的cost。这一步能直观看到“OSPF外部路由的tag确实跟着LSA在传播”，也就能理解为什么R2在反向引入时可以基于tag做过滤。

抓R2和R3之间的RIPv2报文，在R2配置了向RIP引入OSPF路由之后，RIPv2的Response报文里会出现10.0.1.1/32这条路由，cost字段为5。这也印证了RIP的“seed metric”设定是跟着报文走的。

3.3 用最终配置文件核对实验状态

验证到最后，我习惯把R2的完整配置导出来看一眼。一个规范的双向重发布配置，重点检查三件事：

• OSPF视图里是否有import-route rip，并且是否带了tag
• RIP视图里是否有import-route ospf，并且是否带了cost和route-policy
• route-policy的deny节点是否精确匹配，permit节点是否放行了其他路由

# route-policy deny-tag100 deny node 10 if-match tag 100 # route-policy deny-tag100 permit node 20 # ospf 1 import-route rip tag 100 # rip 1 import-route ospf cost 5 route-policy deny-tag100 #

对比这个模板，几乎能排查掉九成以上的配置遗漏问题。重发布的故障，绝大多数都不是协议本身的问题，而是默认值、方向、过滤条件这三类人为配置问题。

4. 常见问题与排错实录

现象 可能原因 处理思路 R3学不到OSPF域的路由 RIP引入时未指定cost，种子度量16 配 import-route ospf cost 5 R1学不到RIP域的路由 OSPF邻居未建立或区域不匹配 检查 display ospf peer，状态应为Full R3的RIP路由表里出现自己的环回路由 tag过滤未配置 用route-policy拒绝带tag的回馈路由 R1到R3的流量走了非预期路径 路由优先级或cost设置不合理 调整cost或显式调整路由优先级 路由表中出现cost=16的RIP条目 引入方向配置错误 检查RIP引入指令和cost参数 整网路由频繁振荡 双向重发布未做防环过滤 配置tag机制，只保留必要方向引入

4.1 RIP侧学不到OSPF路由：种子度量值问题

这是新手最容易踩的坑。RIP引入外部路由时，默认的种子度量值是16，也就是不可达。你在R2上写了import-route ospf，以为就完事了，结果R3死活学不到。解决方式就是在命令里显式加cost，比如import-route ospf cost 5。

4.2 OSPF侧学不到RIP路由：先查邻居

如果R1学不到R3的环回，优先怀疑OSPF邻居关系。执行：

display ospf peer

看R2和R1之间的邻居状态是不是Full。如果不是，先解决底层邻居问题，再看重发布。曾经有朋友拿着“OSPF引入RIP不生效”的问题找我，结果一查是R1和R2的OSPF进程区域ID写错了，根本不是引入的问题。

4.3 双向重发布后偶发中断：多半是路由振荡

双向重发布且没有过滤时，RIP域的路由会反复进入OSPF再被引回RIP，路由表的变化会导致部分流量在间歇性中断。在实验里表现为“ping通几次，然后丢几个包”，非常迷惑。解决思路就是用tag + route-policy切断回馈路径。如果过滤配置本身没错，检查一下route-policy应用的位置是不是在RIP引入方向，很多次是配好了route-policy但忘记在import-route ospf后面引用。

4.4 路由存在，但走的路径和你预期的不一样

这个问题的根源多半是优先级。比如R1既从OSPF外部路由学到了10.0.3.1，又从RIP学到了同一条路由，由于RIP优先级100小于OSPF外部优先级150，设备会优先走RIP。如果RIP那条路径实际上是绕远路，就会出现“明明有直连OSPF路径不走，偏要走RIP”的诡异现象。

排错时先在相关设备上执行：

display ip routing-table 10.0.3.1

能看到当前生效的路径来源和优先级，再对照两边的cost值。如果确实需要调整选路，可以修改重发布时的cost，或者用协议优先级调节命令改变默认优先级。

5. 扩展思考：重发布不是越多越好

实验做通了以后，可以再往前想一步：是不是能用重发布解决所有多协议互通问题？

我的观点是，在能通过静态路由、默认路由或者单方向重发布解决问题时，尽量不做双向重发布。双向重发布意味着引入的每一条路由都可能成为潜在的回馈源、次优路径源，尤其在多台设备同时做重发布的网络中，风险会成倍放大。生产网络里更常见的做法是只选择一台设备作为“翻译官”，在OSPF域和RIP域之间做双向引入，同时用精确的route-policy严格控制哪些路由可以跨界，哪些路由必须留在自己的域内。

如果边界设备不止一台，还要考虑两台设备同时引入相同路由导致的负载分担不均衡、环路、次优路径等多重问题，这时候的排错难度会远超今天的实验场景。实际上，单台设备上的双向重发布防环，是整个多协议网络设计里最基础、也是最核心的一环。

我个人在实际操作中的体会是：重发布实验值得多敲几遍，而且每次都要用抓包和路由表验证来确认自己真的理解了“路由从哪里来、到哪里去”。如果你在实验里把tag、cost、优先级这几个变量逐个改一改、观察一下路由表和报文的实时变化，比死记十遍理论都管用。

最后再分享一个小技巧：做这类实验千万别直接把所有配置一次性配完。先配单向，验证通过，再配反向，验证隔离。每步都确认路由表符合预期，最后出了问题也能快速缩小范围到某一条配置上。这套“小步快跑”的排错习惯，在真实网络里能帮你省下大量时间。