企业官网建设流程全解析

我接触“重发布”这个命令，最早是在给一家制造业客户改造网络的时候。他们生产区和办公区用了两套完全不同的路由协议，结果业务系统上线后每天都有网络不通的投诉，追查到最后，问题全出在两个协议的边界上。从那天起我才意识到，重发布不是写在书本里的一个简单命令，而是真实网络里绕不开的关键操作。这篇文章把我做重发布实验的完整思路、配置过程和踩坑记录整理出来，希望能帮到正在学路由协议、或者正在为异构网络对接发愁的朋友。

1. 重发布到底解决什么问题

1.1 为什么需要重发布

先说一个最直白的问题：不同路由协议之间为什么不能直接互相通信？这就像两个团队的人各说各的语言，OSPF内部用链路状态数据库计算路由，RIP靠跳数传递路由，BGP则用路径属性选路。它们对“一条好路由”的定义完全不同，各自维护的路由表格式也不一样，自然没法直接对话。

但现实中，一个企业网络很难从头到尾只用一种协议。最常见的情况是：公司收购了一家小厂，对方网络里跑着RIP，自己这边跑着OSPF，两套网络必须打通；或者核心层用了OSPF，出口接运营商用了BGP，边界上必须做协议转换。这时候就需要一个中间机制，把一种协议学到的路由“翻译”成另一种协议能理解的语言，这个机制就是重发布（Route Redistribution）。

打个比方，重发布就像两个部门之间的翻译官。翻译官的工作不只是把话传递过去，还得确保信息在传递过程中不丢、不变形。路由重发布也是如此，它不只是把路由条目从一个协议“倒”到另一个协议，更重要的是要让接收方能够正确评估这条路由的优先级和开销，否则就会出现路由黑洞或者环路。

1.2 我接触到的真实应用场景

我做过的实验和实际项目中，重发布最常见的应用场景有三个。

第一个场景是部门合并或企业并购。两家公司网络合并，各自用的路由协议不同，最简单的做法不是在边界路由器上重新规划所有网段，而是通过重发布让两个协议域互相学习对方的路由。这种做法实施快、改动小，特别适合业务紧张不能长时间中断的场合。

第二个场景是路由协议迁移过渡期。比如公司准备把全网从RIP升级到OSPF，不可能一天之内把几十台路由器全部改完，常见的做法是分区域逐步迁移，迁移期间老区域跑RIP、新区域跑OSPF，中间通过重发布保持全网路由可达。等迁移彻底完成后，再把重发布配置移除。

第三个场景是双协议边界设计。有些大型网络的骨干用OSPF，分支或专线部分用静态路由或BGP，边界路由器上同时运行多种协议。这种情况下，重发布往往是唯一能把这些异构部分连通的办法，而不是可选项。

2. 实验拓扑设计与思路拆解

2.1 实验环境规划

我在做重发布实验时，没有直接上真实设备，而是先在GNS3里搭了一套环境。用模拟器的好处很明显：改配置不用顾虑业务影响，可以随意折腾，还能用抓包工具直接看协议报文。

实验拓扑我设计了三台路由器加两台交换机的结构。R1和R2之间跑OSPF，属于OSPF区域0；R2和R3之间跑RIP；R3下面挂了一台二层交换机，再连两台模拟终端的PC。这样设计的关键点在于，R2是重发布的核心设备，它同时运行OSPF和RIP两种协议，负责把OSPF学到的路由重发布进RIP，也把RIP学到的路由重发布进OSPF。

我特意在拓扑里加了两个环回口：R1上的Loopback0模拟一个内部业务网段，R3上的Loopback0模拟分公司或分支机构的网段。用环回口来模拟网段的好处是稳定性好，不会因为链路抖动影响路由状态，方便后面验证重发布是否成功。

2.2 方案选型和关键决策点

实验前我做了几个关键决策，这些决策直接影响实验的难易程度和最终结论。

第一个决策是协议选择。我选了OSPF和RIP这对组合，而不是OSPF和EIGRP。原因是OSPF和RIP的度量值机制差异足够大，能更明显地展示重发布时“种子度量值”这个问题。OSPF用开销值（Cost），RIP用跳数，两者之间没有天然的可比性，重发布时必须手动指定一个起始度量值，这个过程特别容易出错，也最能体现实验价值。

第二个决策是重发布的单向还是双向。我最初只做单向重发布，也就是把OSPF的重发布进RIP，验证通了之后再改成双向重发布。循序渐进的好处是问题定位容易，如果直接做双向重发布，出现问题后很难判断是哪一端配置错误。

第三个决策是是否加入路由过滤。重发布最怕的就是路由回馈和环路风险，所以我在实验里专门设计了一个环节，在R2上使用路由策略控制哪些路由可以被重发布、哪些不能被重发布。这个设计很关键，实际项目中重发布几乎都要配合过滤策略一起用。

3. 核心配置实操详解

3.1 基础配置与单向重发布

所有实验的第一步都是把基础网络打通。我先把三台路由器的主接口地址配好，然后分别配置OSPF和RIP，确保每台路由器在自己所属的协议域内已经能学到路由。

R1和R2之间使用的网段是10.0.12.0/24，R2和R3之间使用的是10.0.23.0/24。R1的环回口是1.1.1.1/32，R3的环回口是3.3.3.3/32。实际上，我自己做配置有个习惯，就是环回口地址直接用1.1.1.1这种规律性强的地址，方便在路由表里一眼认出是哪台设备的。

基础配置完成后，关键在R2上。此时R2的路由表里既有OSPF域内的路由（包括10.0.12.0/24和1.1.1.1/32），也有RIP域内的路由（包括10.0.23.0/24和3.3.3.3/32）。但R1不知道RIP域的路由，R3也不知道OSPF域的路由，因为两台设备之间没有直接链路，也没有重发布来传递。

单向重发布的配置是在R2上把OSPF路由引入RIP，命令如下：

R2(config)# router rip R2(config-router)# version 2 R2(config-router)# network 10.0.0.0 R2(config-router)# redistribute ospf 1 metric 3

这里最关键的是metric 3这个参数。RIP的默认最大跳数是15，超过15跳就被认为不可达。OSPF路由本身没有跳数概念，如果不手动指定metric值，RIP就会默认使用一个比较高的数值，很可能导致路由被标记为不可达。我在实验里特意把metric设成3，意味着收到这条路由的路由器会认为它距R2有3跳，这样R3就能正常使用这些路由了。

配置完成后，我在R3上执行show ip route，确认能否看到OSPF域内的1.1.1.1/32路由。如果能看到且协议来源显示为RIP，就说明单向重发布配置成功。

3.2 双向重发布与种子度量值问题

单向重发布通了之后，我开始尝试双向重发布。双向重发布的思路是：R2既把OSPF路由引入RIP，也把RIP路由引入OSPF。OSPF部分的配置是这样的：

R2(config)# router ospf 1 R2(config-router)# redistribute rip subnets metric 30

这里有两个容易踩坑的点。第一，必须加subnets参数，否则OSPF只会重发布主类网络路由，也就是只发布10.0.0.0/8，而不发布具体的子网路由。我见过不少人在这里栽跟头，明明配置了重发布，但网络上就是学不到具体网段路由，查了半天才发现是没加这个参数。

第二，metric 30指定了重发布路由的初始开销值。OSPF计算开销值的默认公式是参考带宽（默认100Mbps）除以接口带宽，但重发布进来的外部路由没有对应接口，所以必须手动指定一个起始开销。我选30是综合考虑了拓扑里的链路带宽：R1和R2之间是千兆链路，开销值是1；R2和R3之间是百兆链路，开销值是1。如果把外部路由的初始值设得太小，比如1，那么可能会出现外部路由比内部路由优先的情况，影响选路结果。

双向重发布配置完之后，我在R1上查看路由表，发现RIP域内的10.0.23.0/24和3.3.3.3/32都能学到了，而且协议来源显示为OSPF的外部路由（OE2）。这说明OSPF到RIP、RIP到OSPF两个方向的重发布都生效了。

3.3 重发布类型的选路逻辑

OSPF里重发布进来的路由分为两种类型：外部类型1（E1）和外部类型2（E2）。默认情况下，重发布进OSPF的路由是E2类型。E2类型路由计算开销值时，只计算外部路由自己带的度量值，不累加内部路径的开销；E1类型路由则会累加从ASBR到目标网段的全部开销。

我实验里配置的metric 30，因为没有特别指定类型，所以默认是E2。这意味着所有路由器看到的这条外部路由开销值都是30，无论它们距离R2有多远。如果我希望路由开销随距离增加而增加，就应该把外部路由改成E1类型：

R2(config-router)# redistribute rip subnets metric 30 metric-type 1

理解E1和E2的区别，在真实项目中非常重要。如果一个区域里有多台ASBR同时做重发布，E2类型可能会导致所有路由器都选择同一台ASBR（通常是metric值最小的那台），造成流量拥塞；E1类型则会让不同位置的设备根据自身到ASBR的距离选择不同的出口，流量分担更均匀。

4. 重发布最容易引发的三类问题

4.1 路由回馈问题

路由回馈是双向重发布最容易出现的问题，也是我在实验中第一次遇到就印象深刻的问题。简单来说，就是OSPF域内的路由被重发布到RIP之后，这条路由又通过RIP传播回边界路由器，边界路由器认为这是一条新的RIP路由，然后又把它重发布回OSPF，导致路由信息在两种协议之间来回循环。

这个问题在拓扑里是这样发生的：R1有一个业务网段1.1.1.1/32，这个网段在OSPF域内正常通告。R2把这个网段重发布进RIP，R3从R2那里学到了这条路由。如果R3上配置了RIP到OSPF的双向重发布，R3也会把从RIP学到的1.1.1.1/32路由重发布回OSPF。这样一来，R2和R1都会收到来自R3的这条外部路由。虽然在OSPF内部，域内路由的优先级高于外部路由，不会影响实际转发，但路由表的条目会变得混乱，而且可能引发次优路径问题。

解决路由回馈的标准做法是使用路由过滤。我在R2上配置了前缀列表和路由策略，只允许内部真实存在的业务网段被重发布，不允许从对端协议学到的路由再被重发布回去：

R2(config)# ip prefix-list OSPF_TO_RIP seq 5 permit 10.0.0.0/8 le 32 R2(config)# ip prefix-list OSPF_TO_RIP seq 10 deny 192.168.0.0/16 le 32 R2(config)# route-map OSPF_TO_RIP permit 10 R2(config-route-map)# match ip address prefix-list OSPF_TO_RIP R2(config)# router rip R2(config-router)# distribute-list route-map OSPF_TO_RIP in

4.2 次优路径问题

次优路径是重发布实验里另一个经典问题。产生原因是重发布破坏了路由协议原有的选路规则，使路由器选了一条“能通但不是最优”的路径。

我在实验里验证了一种典型情况：R2和R3之间原本只有一条直连RIP链路，但我在拓扑里加了一条备用链路，让R3的环回口网段既通过RIP通告，也通过备用路径连到R1。当R2把OSPF路由重发布进RIP时，R1收到这条外部路由的开销值是固定的；而R1同时也有到达目标网段的直连或内部路由。如果我在配置重发布时把metric值设得比内部路由开销小，R1就会优先走重发布过来的路由，哪怕实际跨了多台设备，这就是次优路径。

解决次优路径，通常要调整路由的管理距离（Administrative Distance）。不同路由协议的管理距离不同，OSPF内部路由的管理距离是110，RIP是120。默认情况下，路由器会优先选择管理距离小的路由。如果我让重发布进RIP的OSPF路由的管理距离大于直连路由或OSPF内部路由，路由器就会优先使用更优的路径。

在华为设备上可以通过命令调整路由协议优先级，思科设备则用distance命令。但更推荐的做法是配合路由策略精确控制，不要盲目加大管理距离，否则可能影响其他正常路由的选择。

4.3 环路风险与防环机制

环路问题虽然在实际网络中不常见，但一旦出现就是大事故。我在实验里专门模拟过环路场景：R2把OSPF路由重发布进RIP，R3把RIP路由重发布进OSPF，两边形成双向重发布闭环，同时中间链路出现故障，路由信息就会在两种协议之间不断传递，形成路由环路。

路由协议本身有一些防环机制，比如OSPF内部没有环路是因为SPF算法基于链路状态计算，RIP则用最大跳数限制环路。但跨协议的重发布实际上绕过了这些机制，所以必须在重发布边界上做防护。

最有效的防环手段就是在重发布路由器上做双向过滤。具体思路是：R2只重发布本地的、确认属于OSPF域内的路由到RIP，不重发布从R3学到的RIP路由回OSPF；同理，R3也只重发布本地的直连网段，不把从R2学到的路由再重发布回去。这样每个方向都只传递“源发”路由，环路自然就不存在了。

5. 实验调试与常见问题排查

5.1 有效排查命令

重发布实验一出现问题，第一步永远是看路由表。我用得最多的命令是show ip route和show ip route ospf，目的是确认路由是否被重发布、协议来源是什么、管理距离和metric值是多少。

第二组常用命令是show ip protocols，这个命令会列出路由器上所有正在运行的路由协议、重发布配置和过滤策略。排查重发布问题的时候，第一步不是去看拓扑，而是先用这个命令确认配置是否生效。经常有这种情况：配置明明写对了，但没有在正确的进程下配置，或者配置被后面的策略覆盖了，show ip protocols一眼就能看出问题。

第三组命令是调试命令，比如思科的debug ip rip和debug ip ospf events。这些命令会实时打印协议报文信息，能直接看到路由器收到路由更新、发送路由更新的全过程。不过在生产设备上开debug要很谨慎，CPU占用会很高，在实验环境里则可以放心大胆地用。

5.2 常见问题速查

我在多次实验里积累了一些高频问题，整理成了一张速查表，每次复现重发布问题都会先对一遍。

任何问题在用命令排查之前，都要先仔细审一遍配置。我见过太多人一上来就debug，结果折腾半天才发现是network命令漏配置了。重发布实验对逻辑思维能力要求比较高，一个新问题出现时，先想清楚这个路由在哪个协议域里“出生”，它应该以什么路径“到达”目标设备，再动手改配置，效率会高很多。

6. 实验之外：真实项目的三点经验

做完这套实验，对重发布的理解停留在“会配命令”的层次还不够，很多细节是在真实项目里才体会到的。最后分享三点我认为最有价值的经验。

第一点是重发布配置前一定要整理路由清单。在动手之前先梳理清楚哪些网段需要被重发布、哪些网段必须被过滤掉。很多工程师在实验环境里不做这个步骤，到了生产环境才两眼一抹黑。我现在的习惯是先用静态路由加前缀列表的方式把所有要发布的网段列出来，再写重发布配置。

第二点是重发布metric值的设定不能随便拍脑袋。RIP里建议设置3到5，OSPF里要结合网络带宽计算一个合适的值。如果metric值设置得过小，可能导致外部路由抢占内部路由，造成流量走迂回路径；设置得过大又会导致部分路由器认为目标不可达。我之前在项目里就遇到过RIP跳数超过15导致路由不可达的问题，根源就是重发布的种子度量值设得太大。

第三点是重发布虽然能把不同协议的域打通，但它本质上是一种“破坏性”操作，把协议自身的拓扑信息和精确选路依据都抹掉了，被重发布的路由只剩下一张“模糊的地图”。所以在网络设计阶段，能通过统一协议或者双栈并行的方式解决问题，就不应该依赖重发布。重发布作为过渡方案和边界方案是非常有效的，但作为长期运行的架构方案，要慎重得多。