我接触“重发布”这个命令最早是在给一家制造业客户改造网络的时候。他们生产区和办公区用了两套完全不同的路由协议结果业务系统上线后每天都有网络不通的投诉追查到最后问题全出在两个协议的边界上。从那天起我才意识到重发布不是写在书本里的一个简单命令而是真实网络里绕不开的关键操作。这篇文章把我做重发布实验的完整思路、配置过程和踩坑记录整理出来希望能帮到正在学路由协议、或者正在为异构网络对接发愁的朋友。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区域0R2和R3之间跑RIPR3下面挂了一台二层交换机再连两台模拟终端的PC。这样设计的关键点在于R2是重发布的核心设备它同时运行OSPF和RIP两种协议负责把OSPF学到的路由重发布进RIP也把RIP学到的路由重发布进OSPF。我特意在拓扑里加了两个环回口R1上的Loopback0模拟一个内部业务网段R3上的Loopback0模拟分公司或分支机构的网段。用环回口来模拟网段的好处是稳定性好不会因为链路抖动影响路由状态方便后面验证重发布是否成功。2.2 方案选型和关键决策点实验前我做了几个关键决策这些决策直接影响实验的难易程度和最终结论。第一个决策是协议选择。我选了OSPF和RIP这对组合而不是OSPF和EIGRP。原因是OSPF和RIP的度量值机制差异足够大能更明显地展示重发布时“种子度量值”这个问题。OSPF用开销值CostRIP用跳数两者之间没有天然的可比性重发布时必须手动指定一个起始度量值这个过程特别容易出错也最能体现实验价值。第二个决策是重发布的单向还是双向。我最初只做单向重发布也就是把OSPF的重发布进RIP验证通了之后再改成双向重发布。循序渐进的好处是问题定位容易如果直接做双向重发布出现问题后很难判断是哪一端配置错误。第三个决策是是否加入路由过滤。重发布最怕的就是路由回馈和环路风险所以我在实验里专门设计了一个环节在R2上使用路由策略控制哪些路由可以被重发布、哪些不能被重发布。这个设计很关键实际项目中重发布几乎都要配合过滤策略一起用。3. 核心配置实操详解3.1 基础配置与单向重发布所有实验的第一步都是把基础网络打通。我先把三台路由器的主接口地址配好然后分别配置OSPF和RIP确保每台路由器在自己所属的协议域内已经能学到路由。R1和R2之间使用的网段是10.0.12.0/24R2和R3之间使用的是10.0.23.0/24。R1的环回口是1.1.1.1/32R3的环回口是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之间是千兆链路开销值是1R2和R3之间是百兆链路开销值是1。如果把外部路由的初始值设得太小比如1那么可能会出现外部路由比内部路由优先的情况影响选路结果。双向重发布配置完之后我在R1上查看路由表发现RIP域内的10.0.23.0/24和3.3.3.3/32都能学到了而且协议来源显示为OSPF的外部路由OE2。这说明OSPF到RIP、RIP到OSPF两个方向的重发布都生效了。3.3 重发布类型的选路逻辑OSPF里重发布进来的路由分为两种类型外部类型1E1和外部类型2E2。默认情况下重发布进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把这个网段重发布进RIPR3从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 in4.2 次优路径问题次优路径是重发布实验里另一个经典问题。产生原因是重发布破坏了路由协议原有的选路规则使路由器选了一条“能通但不是最优”的路径。我在实验里验证了一种典型情况R2和R3之间原本只有一条直连RIP链路但我在拓扑里加了一条备用链路让R3的环回口网段既通过RIP通告也通过备用路径连到R1。当R2把OSPF路由重发布进RIP时R1收到这条外部路由的开销值是固定的而R1同时也有到达目标网段的直连或内部路由。如果我在配置重发布时把metric值设得比内部路由开销小R1就会优先走重发布过来的路由哪怕实际跨了多台设备这就是次优路径。解决次优路径通常要调整路由的管理距离Administrative Distance。不同路由协议的管理距离不同OSPF内部路由的管理距离是110RIP是120。默认情况下路由器会优先选择管理距离小的路由。如果我让重发布进RIP的OSPF路由的管理距离大于直连路由或OSPF内部路由路由器就会优先使用更优的路径。在华为设备上可以通过命令调整路由协议优先级思科设备则用distance命令。但更推荐的做法是配合路由策略精确控制不要盲目加大管理距离否则可能影响其他正常路由的选择。4.3 环路风险与防环机制环路问题虽然在实际网络中不常见但一旦出现就是大事故。我在实验里专门模拟过环路场景R2把OSPF路由重发布进RIPR3把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 常见问题速查我在多次实验里积累了一些高频问题整理成了一张速查表每次复现重发布问题都会先对一遍。现象可能原因解决办法RIP域内学不到OSPF路由OSPF路由没有配置metric值配置redistribute时指定metric值OSPF域内学不到RIP路由缺少subnets参数在redistribute命令中加subnets路由表里出现重复路由双向重发布导致路由回馈配置前缀列表和路由策略过滤路由能通但走的是绕远路径重发布路由的metric值过小调整metric值或管理距离某些网段不可达路由策略中deny规则误伤检查前缀列表匹配范围重发布后出现环路双向重发布无过滤防护配置双向路由过滤只发布本域路由任何问题在用命令排查之前都要先仔细审一遍配置。我见过太多人一上来就debug结果折腾半天才发现是network命令漏配置了。重发布实验对逻辑思维能力要求比较高一个新问题出现时先想清楚这个路由在哪个协议域里“出生”它应该以什么路径“到达”目标设备再动手改配置效率会高很多。6. 实验之外真实项目的三点经验做完这套实验对重发布的理解停留在“会配命令”的层次还不够很多细节是在真实项目里才体会到的。最后分享三点我认为最有价值的经验。第一点是重发布配置前一定要整理路由清单。在动手之前先梳理清楚哪些网段需要被重发布、哪些网段必须被过滤掉。很多工程师在实验环境里不做这个步骤到了生产环境才两眼一抹黑。我现在的习惯是先用静态路由加前缀列表的方式把所有要发布的网段列出来再写重发布配置。第二点是重发布metric值的设定不能随便拍脑袋。RIP里建议设置3到5OSPF里要结合网络带宽计算一个合适的值。如果metric值设置得过小可能导致外部路由抢占内部路由造成流量走迂回路径设置得过大又会导致部分路由器认为目标不可达。我之前在项目里就遇到过RIP跳数超过15导致路由不可达的问题根源就是重发布的种子度量值设得太大。第三点是重发布虽然能把不同协议的域打通但它本质上是一种“破坏性”操作把协议自身的拓扑信息和精确选路依据都抹掉了被重发布的路由只剩下一张“模糊的地图”。所以在网络设计阶段能通过统一协议或者双栈并行的方式解决问题就不应该依赖重发布。重发布作为过渡方案和边界方案是非常有效的但作为长期运行的架构方案要慎重得多。
