☰
HCIP多向重分布实验:方向控制与路由回灌避坑要点
2026/10/22 19:01:06 网站建设 项目流程

多向重分布这个实验,HCIP的题库里出现频率不算低,但很多人第一次上手都会在“多向”这两个字上翻车。我最初做这个题目时,以为只要在两台路由器的协议进程里各写一条 import-route 就能互通,结果R2配完重分布,R4的环回口直接消失在全网的路由表里,下一跳指向的方向刚好和预期相反。后来反复看路由表、对比AD值和种子度量,才发现问题根本不是命令语法,而是“路由从哪里进来、又从哪里出去”这个方向性问题没控制住。

这篇内容就把多向重分布实验从头到尾拆开讲一遍,包含我踩过的坑、看路由表时的判断方法,以及一套可以直接照抄的重分布配置思路。适合正在准备HCIP实验考试的兄弟,也适合日常维护多协议混合网络的同行。看完之后你会明白,重分布最难的地方不是敲命令,而是搞清楚每一条外部路由进入协议域之后,会不会被另一台边界设备再扔回去。

1. 先把“多向重分布”这块硬骨头啃明白

1.1 单点双向重分布与多向的差别在哪

很多教材喜欢用“双向重分布”作为入门案例,也就是一台边界路由器同时连接OSPF域和RIP域,两边互相引入。这个场景理解起来很直观:R1学习RIP域的路由,R4学习OSPF域的路由,中间只有一台设备负责翻译,任何路由最多经过一次翻译,路径是唯一的,选路问题几乎不存在。

但“多向重分布”完全不是这个量级。多向意味着网络里至少有两台以上的边界设备,且这些边界设备之间本身还运行着某种协议。举个例子,R2和R3都同时连接OSPF和RIP,那么OSPF域内的一条路由可以经由R2翻译成RIP路由,这条RIP路由又可以被R3翻译回OSPF路由。第三次翻译发生时,边界设备已经分不清这条路由最初到底属于哪个协议域了。

最典型的多向重分布拓扑是这样的:R1、R2、R3运行OSPF,R2、R4、R5运行RIP,同时R3和R5之间再做一条静态或直连路由引入。这样一来,R2和R3都既是OSPF边界又是RIP边界,两条重分布路径形成交叉。任何一个方向的控制没做好,全网路由表就会乱套。

这种场景在真实企业网络里其实很常见。比如总部用OSPF做核心,分支沿用RIP,中间两台汇聚设备同时接入两套协议,就是为了防止单点故障。如果只在一台设备上做重分布,边界设备挂了,整个分支的路由就全断了。但多台设备同时做重分布,代价就是必须面对路由回灌和次优路径。

1.2 多向环境里最容易翻车的三个坑

第一个坑是种子度量值不一致。每套路由协议在引入外部路由时,都会给外部路由一个初始度量值,这个值各协议默认完全不同。OSPF引入RIP外部路由时,默认cost是1,类型是Type-2;RIP引入OSPF外部路由时,默认跳数是1。问题在于,当R2把RIP路由引入OSPF后,cost只有1,这个路由在OSPF域内可能比很多OSPF内部路由还“优”,导致核心设备往分支方向的所有流量都压到这条链路上,明明另一条路径带宽更大、时延更低,但路由表就是不往那边走。

第二个坑是路由回灌,也叫路由反馈。R2把RIP域路由引入OSPF后,R3从OSPF学到这条外部路由,如果R3同时也配置了OSPF到RIP的重分布,这条路由会被R3再次翻译成RIP路由扔回RIP域。RIP域内原本的源路由器收到这条“已翻译回来”的路由,下一跳变成了R3,如果R3的路径再指回R2,一个环路就出现了。更恶心的是,这种环路不会立刻导致网络完全中断,而是表现为路由表振荡、某些目标时通时不通。

第三个坑是管理距离优先级冲突。在厂商设备默认值里,RIP的管理距离是100,OSPF内部路由是10,OSPF外部路由是150,静态路由是60。多向重分布之后,同一条目标路由可能同时通过OSPF外部和RIP两条路径学习到,设备会比较AD值决定谁进路由表。RIP的AD值100比OSPF外部路由的150更小,于是设备可能选择一条经过多跳翻译的RIP路径,而不是连接边界设备的OSPF直达路径。AD值本身没有对错,但它不会考虑网络拓扑的合理性,只会机械地选数值小的。

1.3 为什么方案设计比命令配置更重要

多向重分布实验里,命令总共就那么几条:import-route、route-policy、filter-policy、cost、tag。光看命令量,十分钟就能敲完。但真正决定这个实验能不能拿分的,是敲命令之前你有没有想清楚下面三个问题。

第一个问题:哪些路由需要被引入到对端协议域,哪些路由必须留在原地。第二个问题:如果一条路由被多台边界设备同时引入,如何保证所有设备选择同一条最优路径。第三个问题:如何防止已经被翻译过的路由被另一台边界设备再次翻译回去。

这三个问题比重分布本身更难,因为它们要求你站在整个网络拓扑的高度去考虑流量走向,而不是盯着某一台设备的配置看。我见过不少兄弟在实验考试里把route-policy写得很复杂,又是匹配ACL又是匹配前缀列表,结果忽略了最基本的“我应该信任哪条路径”这个判断,最后整张路由表越调越乱。

多向重分布有一个非常实用的设计原则:先确定主用路径和备用路径,再确定回流方向。主用路径上可以将路由正常引入,备用路径上要么用更大的cost压低优先级,要么直接过滤掉回灌路由。这个思路在下面的实操里会一直用到。

2. 实验准备:拓扑规划与关键参数说明

2.1 实验拓扑与地址规划

为了把这个实验做得有代表性,我搭建了一个四台路由器组成的混合协议环境,完全可以用厂商模拟器复现。拓扑结构如下:R1和R3之间建立OSPF邻居,R2和R3之间建立OSPF邻居,R1和R2之间是RIP域,R4同时连接R1和R2,并且R4同时跑OSPF和RIP,形成一个交叉的多边界网络。

地址规划按管理网段和业务网段分开。OSPF域使用10.1.0.0/16,RIP域使用10.2.0.0/16。R1的环回口模拟OSPF域内业务网段,地址为10.1.1.1/32;R2的环回口模拟RIP域内业务网段,地址为10.2.2.2/32;R4的环回口作为两个协议域之间的桥梁网段,地址为10.4.4.4/32,同时通告进OSPF和RIP。

接口互联地址建议全部使用30位掩码,避免路由汇总带来的干扰。R1和R3之间是10.1.12.0/30,R2和R3之间是10.1.23.0/30,R1和R2之间是10.2.12.0/30,R4分别与R1、R2互联,地址段为10.1.14.0/30和10.2.24.0/30。四台设备全部启用环回口,便于后续验证路由学习情况和做路径追踪。

这个拓扑的巧妙之处在于,R1和R2同时都是OSPF与RIP的边界设备,但两者承担的职责不同。设计上让R1作为主边界,R2作为备用边界,这样在验证路由回灌时,能够非常清晰地看到同一条路由在两个边界设备之间反复横跳的过程。

2.2 关键参数与默认值速查

重分布实验里,有几个参数必须刻在脑子里,因为它们直接决定了外部路由进入新协议域后的“身份”。先把某厂商设备上的常见默认值整理在下面,方便配置时对照。

参数项OSPF引入外部路由RIP引入外部路由
默认种子度量11
路由类型Type-2Metric(跳数)
默认管理距离150(OSPF外部)100
是否自动打Tag否否
是否继承原协议度量否否

注意几个容易被忽略的点。OSPF外部路由默认是Type-2,意思是外部路由在进入OSPF域后,只累加ASBR到外部目的网段的cost,不累加OSPF域内沿途的cost。这意味着R1学到R2引入的RIP路由时,cost就是R2上配置的那个值,不管R1和R2之间的OSPF链路质量如何。如果想让外部路由的cost随着OSPF内部路径累加,需要显式指定Type-1。实验里我们尽量用Type-1,这样选路更精确。

RIP引入外部路由时默认metric为1,这个值在RIP域内每经过一台路由器加1。多向环境下,如果不对metric做区分,从R1引入的路由和从R2引入的路由在R4看来可能是完全等价的,R4做负载分担,环路风险反而更高。所以配置时要主动给不同边界设备引入的路由设置不同metric值。

2.3 配置前的统一命名与Tag规划

多向重分布里,Tag是一个被大多数人忽略但极其好用的工具。Tag可以理解成贴在路由上的一个标签,不参与实际度量计算,但可以在路由策略里被匹配。利用Tag可以精确识别“这条路由是从哪里引入的”,然后再决定要不要再次引入。

我在实验里给每个方向的重分布定义了不同的Tag值。主边界R1从RIP引入到OSPF的路由打Tag 100,从OSPF引入到RIP的路由打Tag 200;备用边界R2从RIP引入到OSPF的路由打Tag 300,从OSPF引入到RIP的路由打Tag 400。这样在任何一台设备上看路由表,都能通过Tag判断路由的出生地。

Tag规划建议写在实验记录本上,而不是记在脑子里。因为多向重分布调试过程中,你会在多台设备之间反复切换,一旦Tag记混,配出来的route-policy就可能把本来需要放行的路由全部过滤掉。我在做这个实验时就因为把Tag 200和Tag 300搞混,导致R2上的外部路由全部被拒收,排查了十分钟才发现是Tag匹配错位。

3. 完整实操过程:从底层配置到重分布落地

3.1 底层接口与路由协议配置

先做物理层和数据链路层准备。四台设备的互联接口分别配置IP地址。R1的GigabitEthernet0/0/0接口连接R3,地址设为10.1.12.1/30;GigabitEthernet0/0/1接口连接R2,地址设为10.2.12.1/30;GigabitEthernet0/0/2接口连接R4,地址设为10.1.14.1/30。R2的GigabitEthernet0/0/0接口连接R3,地址设为10.1.23.2/30;GigabitEthernet0/0/1接口连接R1,地址设为10.2.12.2/30;GigabitEthernet0/0/2接口连接R4,地址设为10.2.24.2/30。

OSPF部分,R1、R2、R3全部加入区域0,同时R4也需要加入区域0,这样R4才能从OSPF学到核心网段的路由。RIP部分,R1、R2、R4启用RIP进程1,在相应接口上使能RIP。注意R3不启用RIP,R4同时启用两种协议但属于不同的接口。

配置OSPF时,我习惯把router-id手动指定为环回口地址,避免接口down掉后router-id漂移导致邻居关系重建。配置RIP时,建议关闭自动汇总,因为自动汇总在多向重分布环境下会掩盖明细路由,让排障变得更加困难。此外,所有环回口网段都要通过network命令或import直连路由的方式通告进相应协议。

完成底层配置后,四台设备之间应该能通过各自协议互相学习到直连网段,但此时还没有做任何重分布,所以OSPF域学不到RIP域的路由,RIP域也学不到OSPF域的路由。这个阶段是验证底层配置是否正确的黄金窗口期。

3.2 核心命令:OSPF与RIP的双向重分布配置

第一轮重分布放在主边界R1上。进入OSPF进程,将RIP路由引入OSPF。命令如下:

R1# configure terminal R1(config)# router ospf 1 R1(config-router)# import-route rip 1 cost 20 type 1 tag 100 R1(config-router)# exit

这里有几个关键点。cost设置成20,是为了让这条外部路由在OSPF域内有一个明确度量,不至于因为默认的cost 1太高优先级而与OSPF内部路由竞争。Type选择1,让OSPF域内沿途累加cost,这样从R3和R4两条路径学到的外部路由cost不一样,R4可以比较后选择更优路径。Tag设置成100,标记这是从RIP引入过来的路由。

然后进入RIP进程,将OSPF路由引入RIP:

R1(config)# router rip 1 R1(config-router)# import-route ospf 1 cost 5 tag 200 R1(config-router)# exit

RIP侧引入OSPF时,cost设置成5。这个值在RIP域内每经过一台路由器增加1。R4如果从R1方向学到这条路由,metric是6;如果从R2方向也能学到同一条路由,两侧的metric比较就能决定选路。Tag 200标记这是从OSPF引入进来的路由。

同样的配置,在备用边界R2上也需要做一遍,但cost和Tag要刻意区分。R2上从RIP引入OSPF时,cost设置成50,Tag设置成300;从OSPF引入RIP时,cost设置成10,Tag设置成400。这样R4在OSPF域内同时看到R1和R2引入的同一条RIP路由时,R1的cost 20加路径开销明显小于R2的cost 50加路径开销,R4会自动选择R1作为主路径。而RIP域内同时看到R1和R2引入的同一条OSPF路由时,R1的metric 6也比R2的metric 11更优。

配置完成后,在R4上查看路由表,应该能看到来自两个方向的冗余路由,其中主用路径已经被协议自动选出来了。如果能走到这一步,双向重分布就通了。

3.3 控制方向:用route-policy精明显路

双向重分布通了,但多向网络的风险才刚刚开始。现在R4上既有从R1学到的OSPF外部路由,又有从R2学到的RIP路由。R4自己同时也运行OSPF和RIP,如果我们在R4上也配置了双向重分布,R4就会把从R1学到的OSPF外部路由翻译成RIP路由,再通过RIP域送回R1和R2。而R1收到这条“被R4翻译过”的RIP路由之后,如果R1上也配置了RIP向OSPF的重分布,这条路由又会再次被翻译回OSPF域。一旦这个循环建立,路由表的下一跳会在R1、R2、R4之间来回变化。

解决这个问题的标准做法是使用route-policy配合Tag做方向过滤。以R4为例,我们规定R4只允许把Tag为200的路由从OSPF引入到RIP。Tag为200的路由本来就是R1从OSPF引入到RIP的,它们通过RIP域传递到R4,R4再将它们引入OSPF,这等于让R4作为RIP域的转发节点,把R1已经翻译过的路由再共享给OSPF域的其他设备。而R2通过OSPF外部路由学习到的RIP路由,在R2上被打的是Tag 300,这条路由如果被R4学到的路径是OSPF外部,R4在向RIP重分布时需要把Tag 300的OSPF外部路由过滤掉,防止它再次回到RIP域形成环。

route-policy配置步骤如下,在R4上:

R4(config)# ip access-list standard LOOPBACK R4(config-std-nacl)# permit 10.1.1.1 0.0.0.0 R4(config-std-nacl)# exit R4(config)# route-policy OSPF_TO_RIP permit node 10 R4(config-route-policy)# if-match ip address acl LOOPBACK R4(config-route-policy)# apply cost 8 R4(config-route-policy)# apply tag 500 R4(config-route-policy)# exit R4(config)# router rip 1 R4(config-router)# import-route ospf 1 route-policy OSPF_TO_RIP

这段配置的意思是:R4向RIP引入OSPF路由时,只放行目标指向10.1.1.1的那条OSPF外部路由,也就是R1从RIP引入后再在OSPF域内传递的那条路由,并将其cost调整为8,Tag修改为500。其他OSPF外部路由一概不放行。这就切断了R2侧OSPF外部路由继续向RIP域回灌的路径。

同样地,R4向OSPF引入RIP路由也应该做过滤,只允许从R2方向学到的RIP回灌路由进入OSPF域,并打上新的Tag。这样每一台设备都能清楚知道某条路由在翻译过程中经历了哪些边界,回灌的可能性被大幅压缩。

3.4 测试验证:环回口路由跨协议互通

配置完成后,先在R4上执行路由表查询,确认10.1.1.1和10.2.2.2两个环回口网段都能出现在路由表中。正常状态下,R4应该通过OSPF学到10.1.1.1,通过RIP学到10.2.2.2,同时还能通过OSPF外部路由学到RIP域其他网段,但下一跳必须指向R1而不是R2,因为R1的cost更优。

然后从R4分别ping R1的环回口和R2的环回口。如果通了,说明跨协议路由已经生效。但这只是第一步,还要验证回灌是否真的被堵住。在R1上查看路由表,关注是否有下一跳指向R4但目的地属于RIP域的路由。正常情况下,R1从RIP域学习到的10.2.2.2下一跳应该直接指向R2或R4,而不会通过OSPF外部绕一圈再回来。如果出现了回灌,路由表里会出现一条“第二跳是自己”的诡异路径,用tracert能看到路径在R1和R4之间来回跳。

再用display ip routing-table protocol rip和display ip routing-table protocol ospf分别过滤两种来源的路由,核对每一条外部路由的Tag值。如果Tag与规划一致,说明route-policy生效;如果某条路由的Tag变成了默认值,说明它在某个边界设备上被重新引入时没有经过策略控制,需要回头检查对应设备的import-route命令是否遗漏了route-policy参数。

4. 常见问题与排障实录

4.1 路由表“翻车”现场:次优路径的识别与修正

多向重分布实验里最经典的故障现象是:全网互通,但所有流量都走了备用路径,主路径上一点流量都没有。从连通性上看,这个网络是“正常”的,但实际质量很差。判断次优路径的标志是看路由表里外部路由的下一跳设备与拓扑规划是否一致。

我在第一次做实验时,配置完R1和R2双边界重分布后,在R4上查看10.2.2.2这条RIP域内路由,下一跳指向R2。表面看没问题,R2确实直连RIP域。但继续查看R4到10.2.2.2的往返时延,发现路径经过了R3,绕了一大圈。问题出在我给R2设置的RIP引入OSPF的cost太小,导致R4认为R2引入的外部路由比R1更优,而实际上R1到RIP域只有一跳,R2则需要跨OSPF域再到RIP域。

这种问题的排查思路是:先确认路由表里同一条目标路由是否存在两个来源,再对比两个来源的cost和AD值,最后调整较重那条路径的引入cost或AD值。调整时优先改cost,因为cost只影响这一条重分布路由的方向,而AD值会全局影响所有该协议的外部路由,不小心就会引发更大范围的选路变化。

4.2 环路故障:路由振荡与回灌的快速定位

路由振荡是多向重分布另一个典型故障。现象是R4上的某条路由一会儿是OSPF外部来源,一会儿是RIP来源,路由表不断刷新,CPU占用率升高,ping偶尔超时。这种故障的根源几乎都是回灌。

定位回灌时,最快的方法是看路由的下一跳。如果一条RIP域内路由的下一跳指向了R1,而R1本身并不直连目标网段,说明这条路由已经被边界设备翻译回RIP域了。用tracert跟踪路径,如果路径中出现了“去程经过翻译边界、回程又经过另一个翻译边界”的情况,基本可以确认回灌点。

解决回灌没有万能命令,只能回到route-policy的设计上。我的习惯是:在所有参与重分布的边界设备上,统一使用Tag标识路由来源,并在引入方向上只放行来源Tag正确的路由。R1上从OSPF引入RIP时只放行Tag 100的路由(即原本属于RIP域、被R1翻译到OSPF、又被其他设备翻译回来的路由),其他一律deny。这样做等于给每一台边界设备设置了“只许原路返回,不许横穿”的规则,环路自然消失。

4.3 隐藏的坑:默认AD值对重分布路由的隐性干扰

除了seed metric和回灌,还有一个容易被忽视但实际影响很大的因素:管理距离。在OSPF与RIP同时运行时,默认AD值RIP是100,OSPF外部是150,OSPF内部是10。由于RIP的AD值比OSPF外部更小,一台同时运行两种协议的设备,即使OSPF外部路由的cost更佳,也可能因为AD值更差而选择RIP路径。

这个隐藏干扰在多向重分布中表现得特别明显。R4同时运行OSPF和RIP,当它通过OSPF外部路由学到10.2.2.2时,AD值是150;同时通过RIP也学到了10.2.2.2,AD值是100。尽管RIP路径的cost更大、绕路更远,设备还是会优先把RIP路径放入路由表,因为AD值规则在协议栈层面优先于cost比较。

解决这个干扰有两种思路。第一种是针对重分布路由修改AD值,在边界设备上通过命令直接调整特定协议的全局AD值,这个操作影响面大,适合在路由策略完全无法奏效时使用。第二种更推荐的做法是,在边界设备上用filter-policy把不应该被本机选路的那些路由直接过滤掉,从根上避免“两条路径打架”。比如R4上如果RIP只是辅助路径,那么在RIP进程里配置filter-policy,只允许特定网段通过RIP进入路由表,其余RIP路由直接丢弃,OSPF外部路由就能稳定占据了主用位置。

4.4 验证命令速查表

多向重分布调试过程中,这几条命令可以说是救命稻草。我放在桌面上随时调用,也分享给各位兄弟。

命令作用使用时机
display ip routing-table查看完整路由表,关注下一跳和协议来源任何时候
display ip routing-table protocol ospf只看OSPF来源路由确认OSPF外部路由是否被正确引入
display ip routing-table protocol rip只看RIP来源路由确认RIP路由是否被正确引入
display ospf lsdb查看OSPF链路状态数据库确认外部LSA是否在域内正常泛洪
display rip 1 route查看RIP协议路由表确认RIP域内路由的metric变化
display current-configuration configuration rip查看RIP相关配置排查import-route是否配置了route-policy
tracert 目标地址跟踪路径确认流量是否绕路或环路

调试时建议每次都先看路由表,不要急着敲命令改配置。多向重分布最大的难点不在配置本身,而在于你面对一张已经混乱路由表时,能不能快速定位是哪台设备的哪条重分布路由出了问题。路由表里的下一跳是定位问题的钥匙,协议来源是判断方向的尺子,Tag是追踪来源的DNA,把这三样结合起来,绝大多数问题都能在十分钟内定位。

5. 实验做完之后,我的一些实在经验

多向重分布实验做完之后,我最大的感触是:这个实验考的不是你背了多少条命令,而是你能不能顶住压力读路由表。命令就那几条,翻来覆去不过是import-route加route-policy,但每台设备的一个参数差异,最终都会反映到全网路由表的走向上。做这个实验之前,我建议先画一张手写拓扑图,把每台设备上计划的重分布方向、Tag值和cost值写上去,再动手敲配置。

第二个经验是,Tag规划和Route-Policy优先级必须写在纸上。我在实验中最怕遇到的不是配置错误,而是配到一半自己忘了最初的设计意图,于是开始随意调整cost,结果越改越乱。手边有一张参考表,哪怕网络乱成一锅粥,也能按表逐步还原预期状态。

最后分享一个实用小技巧:配置完多向重分布后,故意把主边界R1的接口shutdown掉,观察R4的路由表能否自动切换到R2路径;恢复R1接口后,再观察路由表能否自动回切。这两次切换如果都能正确完成,并且没有出现长时间的路由振荡,说明你的重分布策略已经走上了正轨。很多兄弟做完实验只看连通性,不看切换行为,结果在真实网络的故障演练中直接露馅。重分布做得好的网络,不但要静态下能通,还要在动态变化下保持稳定,这一点比实验本身更有价值。

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询