说实话,现在很多教程讲到RIP都是教你怎么敲几条network命令把邻居跑起来,真正把RIP的版本兼容、定时器、优先级这三个进阶配置点讲透的并不多。这次实验我刻意把这三个点放在同一个场景里过了一遍:一端跑RIPv1一端跑RIPv2混用,把三个默认定时器改成另一组参数,再通过调整协议优先级让路由表按预期选路。做完这段实验,你会明显感觉到RIP并没有想象中那么“无脑”,通告机制、老化机制、选路逻辑其实和其他动态路由协议一脉相承。这篇内容适合刚学完基础RIP配置、想深入理解协议细节的网工,也适合备考数通认证时想亲手验证协议机理的兄弟参考。
1. 实验设计:三个配置点为什么值得放在一起做
1.1 RIP版本兼容背后的协议差异
只要接触过RIP,都知道有v1和v2两个版本,但很多人不清楚它们之间的兼容并不是“自动完成”的。RIPv1是有类路由协议,更新报文里不携带子网掩码,所以它对子网划分不敏感,只能按照A/B/C类主网段来理解路由。RIPv2则是无类路由协议,更新报文里带掩码,还支持组播更新、明文/MD5认证和路由标记,这些都是v1没有的能力。
关键问题在于:RIP协议本身没有版本协商机制,不像OSPF那样通过Hello报文里的参数去协商邻居关系。RIPv1设备默认监听广播地址255.255.255.255,RIPv2设备默认监听组播地址224.0.0.9。一个网段上如果只有RIPv1监听广播,RIPv2发出来的组播更新它根本收不到,反之亦然。这个版本兼容问题在全是新设备的网络里不常见,但只要新旧设备混跑、或者前期规划夹着历史遗留设备,版本差异就是第一个要排的雷。
1.2 定时器:路由老化和收敛速度的核心
RIP的三个定时器分别是Update(更新定时器)、Timeout(失效定时器)、Garbage-collection(垃圾回收定时器),默认值分别是30秒、180秒、120秒。简单理解就是:每30秒周期性地把整张RIP路由表发给邻居;如果一条路由180秒没有收到新的更新,就把它标记为不可达;被标记不可达后,再等120秒仍然没有恢复,就彻底从路由表里删除。
这三个值的设计逻辑,本质上是在“快速收敛”和“避免误判”之间找平衡。更新周期太短,广播/组播报文会消耗链路带宽和CPU,尤其在大规模网络中影响明显;失效时间太短,一条路由因为网络拥塞丢了几次更新就被误判为失效,路由表就会震荡。真正的生产环境里,改RIP定时器不是为了让收敛变快,而是让收敛衰减曲线和网络特性对齐,比如卫星链路这种高时延场景,默认参数很可能不合适。
1.3 优先级:路由表选路的“裁判规则”
优先级在华为设备上叫preference,是不同路由协议之间选路的裁判依据。华为设备里直连路由优先级是0,OSPF是10,静态默认是60,RIP默认是100。数值越小越优先。当路由器同时从多个协议学到去往同一个目的网段的路由时,这些路由会先进入各自协议的路由表,再通过比较preference决定谁进入全局路由表。
这个参数看起来不起眼,但实际组网中它的作用非常大。比如一台路由器同时运行RIP和OSPF,或者同时配置了静态路由和RIP,如果没有理清优先级关系,路由走向就会跟预期完全相反。修改RIP的preference,本质上就是在改变它跟其他路由来源PK时的胜算,这也是多出口备份、路由分流场景里的常用控制手段。
实验拓扑我用的是三台路由器串成一条链路:R1和R2之间跑RIPv2,R2和R3之间跑RIPv1,R2作为两台设备之间的“翻译官”。这样一个拓扑里,版本兼容、跨版本路由通告的问题就全部暴露出来了。定时器和优先级的调整也在同一拓扑上完成,不需要额外搭建复杂环境,知识点分布非常清晰。
2. 版本兼容配置:单进程内混跑v1和v2
2.1 拓扑与基础配置
先看拓扑规划。R1连接内部网段10.1.1.0/24,R3连接内部网段10.3.3.0/24,路由器之间的互联地址分别是10.0.12.0/24和10.0.23.0/24。R1和R2之间的链路使用RIPv2,R2和R3之间的链路使用RIPv1,所有路由器都启用RIP进程,使用network命令宣告直连网段。
这里有个关键点必须讲清楚:华为设备的RIP进程可以启一个RIP进程,在接口视图下单独覆盖版本。也就是说,R2可以在全局RIP进程下指定version 2,然后在连接R3的接口下单独指定version 1,这样单进程里就能同时支持两个版本,不需要多跑一个RIP进程。配置如下:
R1的配置(v2侧):
[Huawei] rip 1 [Huawei-rip-1] version 2 [Huawei-rip-1] network 10.0.0.0 [Huawei-rip-1] network 10.1.0.0R2的配置(全局v2、接口v1混合):
[Huawei] rip 1 [Huawei-rip-1] version 2 [Huawei-rip-1] network 10.0.0.0 [Huawei-rip-1] quit [Huawei] interface GigabitEthernet 0/0/1 [Huawei-GigabitEthernet0/0/1] ip address 10.0.23.2 24 [Huawei-GigabitEthernet0/0/1] rip version 1R3的配置(v1侧):
[Huawei] rip 1 [Huawei-rip-1] version 1 [Huawei-rip-1] network 10.0.0.0 [Huawei-rip-1] network 10.3.0.0注意,R2接口下配置rip version 1后,这个接口发送和接收的RIP报文都会按v1处理,但全局RIP进程还是v2。R1和R2之间走v2组播,R2和R3之间走v1广播。配置完成后,用display rip 1 neighbor分别观察R1、R2、R3上的邻居关系,就能看到一个有意思的现象:R2的邻居表里既有R1的v2邻居,也有R3的v1邻居,这就是单进程混跑版本的效果。
2.2 版本兼容的判定与验证
配置完成后,在R3上执行display ip routing-table,正常情况下能看到10.1.1.0/24这条路由,在R1上也能看到10.3.3.0/24。但细看路由信息你会发现一些版本差异导致的细节:R1看到的10.3.3.0/24可能是子网掩码完整的精确路由,R3看到的10.1.1.0/24却可能变成了10.1.0.0/16之类的主网段路由。原因非常简单,R2和R3之间走的是v1,v1报文里不携带掩码,R2在向R3通告时只能按有类路由的规则处理,把10.1.1.0/24汇总成B类主网段10.1.0.0/16再通告。
为了验证这一点,可以用display rip 1 route对比两台设备的路由明细。建议把R1和R3上的RIP路由表输出都截下来,放在一起对比,一看就明白v1的自动汇总行为。
再有一个细节,RIPv2默认使用组播发送更新报文,但如果你在R2连接R1的接口下看到R1的RIPv2邻居正常建立,那说明两边都能正确处理组播报文。如果在某些环境里R1和R2起不来邻居,可以尝试在R2的接口下配置rip version 2 broadcast,用广播方式发送v2报文。这种配置下v2报文里仍然携带子网掩码,但用的是广播地址,兼容性更好。实际工作中遇到的三方设备互联,很多都是通过这种方式解决版本兼容问题的。
2.3 兼容配置的注意事项
做版本兼容的时候有几个坑,基本上每个都会踩一遍。
第一,版本配置的位置要分清楚。全局RIP进程下的version命令是缺省版本,接口下单独配置的rip version会覆盖全局设置。如果你在全局配置了version 2,却在接口下忘了处理,这个接口默认还是会按v2收发,跟对端v1设备完全没有交集。排查的时候先检查接口下的实际生效配置,用display this看起来最直接。
第二,自动汇总状态要提前确认。RIPv2默认自动汇总在某些版本里是开启的,如果实验中需要传递子网路由,记得在RIP进程下使用undo summary关闭自动汇总。否则明明配置了10.1.1.0/24,通告出去却变成10.1.0.0/16,掩码不一致导致路由看起来像“丢失”了一样。
第三,认证只在v2里才有。如果链路上混跑v1和v2,不要在RIP进程下配置认证,否则v1报文根本没有认证字段,对端处理不了直接丢弃,表现为邻居一直起不来。以前有同事在生产环境里踩过这个坑,RIP认证一开,整条链路的邻居全断了,排查半天才发现是版本混跑导致认证能力不对称。
3. 定时器配置:参数原理与收敛效果验证
3.1 三个定时器的真实工作流程
RIP定时器虽然是老生常谈,但很多人没仔细推演过时间线。我在这里把全过程捋一遍。假设路由器A启用了RIP,路由表里有一条去往10.1.1.0/24的RIP路由,来源是路由器B。第0秒学习到这条路由,同时启动180秒的Timeout定时器。每隔30秒,路由器B会发一次更新,A收到后重置Timeout定时器,重新计时180秒。
如果从某个时刻开始,路由器B因为链路故障或自身问题不再发送关于这条路由的更新,A在180秒内都没收到刷新,就会把这条路由标记为“不可达”。注意,这里不是立即删除,而是从可用路由变成不可用路由。再往后120秒,也就是从标记不可达起继续等待一个Garbage-collection周期,如果始终没有恢复,才彻底把这条路由从路由表里删除。
这个“失效后再等120秒”的设计很有讲究:给路由一个恢复缓冲期。如果这条路由只是经历了短暂的丢包或网络波动,在Garbage-collection期间又收到了B的更新,那它可以直接恢复到可用状态,不需要重新学习,避免路由表闪断。真正彻底断线的情况下,这条路由会在第300秒从路由表中消失。从头到尾算下来,默认情况下RIP的最坏收敛时间其实是300秒,不是180秒。
3.2 修改定时器的命令与参数选择
华为设备RIP定时器的配置命令在RIP进程视图下执行,命令格式是timer rip后跟三个参数,依次是Update、Timeout、Garbage-collection,单位都是秒。比如我现在把它改成15秒更新、90秒失效、75秒垃圾回收:
[Huawei] rip 1 [Huawei-rip-1] timer rip 15 90 75修改完成后用display rip 1 timer确认生效情况,输出里会显示更新定时器、失效定时器、垃圾回收定时器三行参数。这个命令是立即生效的,不需要重启RIP进程,这点比改某些协议参数要方便很多。
参数要怎么选?我的建议是遵守一个原则:Timeout要明显大于Update,一般取Update的3到6倍;Garbage-collection不要小于一个Update周期,否则还没来得及接收恢复更新,路由就被删了。实验里为了体现收敛速度差异,建议把Update调成10秒,Timeout调成60秒,Garbage-collection调成40秒,这样一条路由从断线到彻底删除的时间大约是100秒,跟默认的300秒对比非常直观。
生产环境里的调整思路不一样。核心原则是把握住“别因为参数太小导致路由震荡,别因为参数太大导致收敛过慢”。更新定时器如果调到5秒以下,在路由条目多的网络里会明显增加带宽和CPU消耗;Timeout如果只设成Update的两倍,网络一抖动就容易误判。真实项目中一般只在WAN链路或卫星链路这类特殊场景下才动RIP定时器,常规园区网里保持默认值反而是最稳妥的。
3.3 定时器调整后的收敛验证
修改完定时器后,为了验证效果,我在R1上做了个破坏性测试。R1有一个接口直连10.1.1.0/24网段,我先记住R3上查看这条路由时显示的Age时间,然后到R1上执行shutdown把这个接口直接关掉。
关闭接口后,在R3上反复执行display rip 1 route,盯着10.1.1.0/24这一条。第一次刷新还能看到,过了一个Update周期再看,路由还在但Age在继续增长。当达到Timeout时间(比如60秒)时,这条路由会变成“不可达”状态,但还能在表里看到,状态字段会有明显变化。再等Garbage-collection时间之后,这条路由就从RIP路由表里消失了,全局路由表也随之更新。
测试过程中我用这个对比记录表来记录观察结果:
| 观察时间点 | 路由状态 | 全局路由表现象 |
|---|---|---|
| 接口关闭后立即查看 | 仍显示可用 | 路由正常转发 |
| 达到Update时间间隔 | 仍显示可用,Age继续增长 | 路由正常转发 |
| 达到Timeout时间 | 标记为不可达 | 路由不再参与选路 |
| 达到Timeout+Garbage后 | 从RIP表彻底删除 | 全局路由表消失 |
这个测试做完,你对RIP“多少秒才收敛”就有非常直观的体感了。我还做过一组对照实验,一组用默认定时器,一组用调小的参数,同时断线,结果默认那组在快300秒时才彻底丢路由,改动后的100秒就已经刷新完成。差距确实明显。
4. 路由优先级配置:让RIP按你的意愿“上位”
4.1 preference在路由选择中的位置
路由选路是一个多层级的过程,preference是第一层筛选,metric是第二层筛选。preference决定的是“当多个路由协议都学到同一条目的路由时,谁进全局路由表”;metric决定的是“同一个RIP协议内学到多条路径时,哪条更优”。很多新手把这两个概念混在一起,但实际上它们是完全不同的两个维度。
华为设备上修改RIP协议的preference非常简单,命令直接在RIP进程视图下执行:
[Huawei] rip 1 [Huawei-rip-1] preference 80这样修改后,RIP路由的优先级就变成了80,但仍然大于直连的0和OSPF的10,小于静态路由默认的60。如果想把RIP的优先级压到静态路由前面,就把数值调到60以下,比如50或40。这里有个容易混淆的地方:华为设备里“数值越大优先级越低”,RIP默认100,改小数值代表RIP更容易被选中进入全局路由表。
4.2 实验验证:RIP和静态路由同台竞争
为了验证优先级的实际效果,我在R1上做了一个设计。R1通过RIP从R2学到了去往10.3.3.0/24的路由,同时我又在R1上配置了一条静态路由,下一跳指向一个模拟的外网方向接口,目的也是10.3.3.0/24。
默认参数下,静态路由的preference是60,RIP是100。60比100更小,所以全局路由表里选中静态路由,访问10.3.3.0/24走的是静态路由的下一跳。这个结果用display ip routing-table protocol static和display ip routing-table protocol rip可以看得很清楚,同一目的网段只有静态路由出现在全局表里。
然后我在RIP进程下把preference改成50:
[Huawei] rip 1 [Huawei-rip-1] preference 50再看display ip routing-table 10.3.3.0 24,下一跳立刻变成了RIP邻居的地址,出口切换完成。这个操作在双出口备份、路由策略调度里非常实用。RIP这种协议虽然本身没有路径标签、没有策略路由那样丰富的控制手段,但通过调整preference,完全可以用它实现“主备切换”的效果。
除了一刀切的preference 50,华为还支持结合route-policy按需修改优先级。比如只让RIP通告的某几条路由优先,其他保持100,就可以写一个route-policy,在RIP进程里执行preference route-policy xxxx。
4.3 优先级和接口度量值的区别
有些教程会把preference和metricin/metricout放在一起讲,但这两个东西的操作对象不同。metricin和metricout影响的是RIP协议内部的路径优劣。比如R2从R3学到一条RIP路由,再通告给R1时,可以通过在R2连接R1的接口上配置rip metricout 5,把这条路由的跳数加5,这样R1学到这条路由时跳数变大,在同协议内多条路径的比较中处于劣势。
preference则是跨协议的PK标准,它不关心某一条路由的跳数,只看协议身份。所以实际使用中,可以用metricin/metricout控制RIP内部路径选择,用preference控制RIP和其他协议之间的选路结果,两者是配合关系,不是替代关系。这个层次关系理清了,配置的时候就不会犯晕。
5. 实验踩坑与问题排查实录
5.1 RIPv1/v2邻居学不到对方路由
这是最常遇到的现象,症状是路由表里空空的,或者只看到本端路由看不到对端。排查顺序我习惯这样走:先看接口状态和IP地址对不对,用display ip interface brief确认物理层和链路层都up。然后看接口下的RIP版本配置,用display this确认到底是v1还是v2。再查看display rip 1 neighbor,确认邻居是否建立。如果邻居表里没有对方,说明版本或认证存在问题。
排除完这些还没有结果,就要考虑报文交互了。RIPv2默认走组播224.0.0.9,RIPv1走广播255.255.255.255,如果中间有二层隔离或交换机端口配置了组播过滤,RIPv2的组播报文可能被丢弃。这时候把v2接口改成rip version 2 broadcast,用广播模式发更新,往往就能解决。
5.2 定时器改了好像没生效
之前有人问我,为什么在RIP进程下配了timer rip 10 60 40,但路由失效还是要等很久。我让他执行display rip 1 timer,结果发现输出里还是默认值。原因很可能是他在进入RIP进程时,进了rip 2而不是rip 1。华为设备支持多RIP进程,进程号不对,配置自然落在别的进程上,观察的却还是老进程。
还有一种情况是模拟器环境里,路由器配置保存后重启,某些老版本模拟器对RIP定时器命令的恢复逻辑有缺陷,重启后参数被重置成默认值。遇到这种情况不用纠结,重新敲一遍配置,再用display rip 1 timer确认即可。真机上这个现象基本不存在。
5.3 优先级配置后路由表不变化
修改preference后路由表没变化,先确认是不是有更低preference的协议压着。比如RIP和OSPF同时学到路由,你只把RIP从100改成80,但OSPF默认是10,依然比80更优先,所以全局路由表不变。这时候要么把RIP改到10以下,要么同时调整OSPF的preference,否则只是数值变化但没有改变最终结果。
另外,注意掩码是否完全一致。去往同一个目的地址,如果一条是10.1.0.0/16,一条是10.1.1.0/24,那它们不算同一条路由,不存在preference竞争关系,各自独立存在于路由表里。很多人在排障时忽略了掩码长度,盯着地址看半天觉得“这明明一样啊”,实际完全不是一回事。
5.4 模拟器和真机的差异
这个实验如果在模拟器里做,版本兼容和优先级的表现基本一致,但定时器的收敛效果会跟真机有偏差。模拟器对RIP报文的处理是简化过的,更新报文周期和计时器的实际触发时机不一定严格同步,有时候你看到路由表已经变了,但抓包软件里根本没有对应报文。这属于模拟器的正常局限。
有条件的话,建议在真机或者能把控制平面完整跑起来的虚拟化平台上做定时器实验,配合抓包观察RIP报文的发送间隔,那才是协议运行的真实面目。调试命令方面,debugging rip 1 packet可以看到报文收发细节,但生产设备上慎用,这个命令会大幅增加CPU占用,一旦在业务高峰期开启,可能直接把设备拖垮。
最后再分享一个小技巧
这个实验做完,我的建议是把每台设备的display rip、display rip 1 route、display ip routing-table输出保存成文本,在改动每个参数前后各存一份。改版本就对比邻居表和路由掩码,改定时器就对比Age和删除时间,改优先级就对比下一跳变化。这比你背一百遍命令都管用,因为你在亲手验证每一个参数到底改变了什么。RIP虽然老,但版本兼容的思路、定时器之间的耦合关系、preference的选路逻辑,放到OSPF、BGP里也照样用得上,底子就是这层东西,值得花时间磨一磨。