RIP动态路由协议实验指南：配置、抓包与故障排查实战

RIP，也就是Routing Information Protocol，路由信息协议，很多人的第一个动态路由协议实验都是从它开始的。我最早搭RIP实验那会儿，还是找三台老路由器一根console线慢慢敲命令，现在GNS3、eNSP里点几下鼠标就能复现同样的事，但这个协议值得亲手完整做一遍。如果你已经能看懂静态路由，想搞明白动态路由到底是怎么“动”起来的，或者课程作业正好卡在RIP配置和排错上，这篇实验记录就是照着敲一遍就能跑通的那种。

我这次用模拟器搭了一个三台路由器的经典拓扑，配置RIPv2，把报文抓出来逐字段看了一遍，又专门制造了几类典型故障来观察收敛过程。整个过程里最有价值的不是“三条路由器都通了”这个结果，而是把RIP的更新机制、计时器、防环策略和排错思路全部用实际输出串起来了。下面按实验推进的顺序完整记录。

1. 轮不到生产环境却躲不开的RIP：先想清楚为什么要做这个实验

先说点实在的。现在生产环境里RIP确实少见，企业网络用OSPF或IS-IS，跨域互联用BGP，数据中心里还有各种overlay协议。但这不代表RIP不值得学，它恰恰是理解所有动态路由协议的最佳起点，尤其是如果你还没搞明白“路由协议到底在交换什么信息、凭什么信邻居的话”这两个基本问题。

RIP属于距离向量协议，核心逻辑可以概括成一句大白话：我周期性地把自己整张路由表告诉直连邻居，邻居拿到的信息是“从我这个路由器出发，经过多少跳能到哪里”。每个路由器只跟邻居交换信息，不关心全网拓扑，网络地图是每一台设备各自拼出来的。这个思路和OSPF的链路状态算法有本质差别——OSPF是路由器之间互相通报自己有哪些邻居、有哪些直连网段，然后每台设备用SPF算法自己算全图；RIP则朴素得多，只传“方向加距离”。

正因为RIP简单，它把路由协议最核心的概念都暴露在了浅层：路由条目的度量值是怎么累加的、更新报文里到底装着什么、路由过期后路由器要等多久才肯放弃。这些机制放到OSPF和BGP里虽然形式不同，底层逻辑是一脉相承的。所以我在带新人或者自己复习的时候，一定从RIP开始，而不是直接扔一份OSPF配置让他抄。

另外还要说一个现实原因：RIP并没有完全退场。小型分支机构、工业交换设备、一些老旧的运营商接入设备，以及部分嵌入式网络环境，偶尔还能碰到RIP的身影。它最大跳数限制为15跳，16跳表示不可达，意味着它只适合小型网络，但反过来想，在规模足够小的场景里它足够简单可靠，不需要维护复杂的邻居状态和数据库同步机制。这也是为什么很多网工面试还喜欢拿RIP的机制来考基础。

那这个实验要验证什么？具体来说四件事：第一，RIP更新报文怎么产生和传播；第二，四种计时器如何协同控制路由条目的生命周期；第三，水平分割和毒性反转这些防环机制在实际输出里长什么样；第四，当路由真的消失时，全网要多久才能收敛一致。这四个点才是RIP实验真正的价值所在，配置命令反而是最花不了多少时间的事。

2. 实验环境准备：模拟器、拓扑和地址规划

模拟器这块我在GNS3、华为eNSP和Cisco Packet Tracer之间做了取舍。Packet Tracer虽然安装简单、对机器配置要求低，但它的不少RIP行为和真实设备有微妙差异，debug输出也不全，抓包更是别扭，不适合做报文分析。eNSP适合手上只有华为设备的人，命令体系和思科有差异，但RIP机制完全一致，后面我会单独给出VRP版本的配置对照。我最终选了GNS3配思科IOS镜像，理由很实际：它支持完整的debug ip rip输出，能把路由更新过程看得清清楚楚，Wireshark也能直接抓到设备间真实交互的报文。

拓扑就用三台路由器串联，这个规模已经足以覆盖RIP实验绝大多数的观察目标。

地址规划里藏着一个值得注意的设计。互联网段分别用了192.168.12.0/24和192.168.23.0/24，这两个网段同属于B类主类网络192.168.0.0。在思科IOS里，RIP的network命令匹配的是主类网络号，所以R2只需要敲一条network 192.168.0.0，就能把G0/0和G0/1两个接口同时宣告进RIP。如果我把互联地址改成一个属于A类主类、一个属于B类主类，那就要写两条network命令，多一步操作也多了出错的可能。这样规划不是为了偷懒，而是为了让实验主线聚焦在RIP本身，尽量减少因为宣告方式产生的干扰。

如果手边没有思科镜像，也可以用GNS3配合Linux虚拟机的FRR路由套件把R2替换掉，FRR的RIP配置语法很接近思科，互通没有任何问题。类似这样：

router rip version 2 network 192.168.12.0/24 network 192.168.23.0/24

还能顺便看看开源实现和商业实现的兼容性，这也是RIP协议标准化程度高的好处之一。

3. RIP的核心机制拆解：更新、计时器与防环三板斧

3.1 距离向量算法到底怎么“干活”

RIP的度量值就是跳数，一条路由每经过一台路由器转发，跳数加1。直连接口算0跳，从R1到R3上的3.3.3.3，要经过R1到R2、R2到R3两次转发，所以是2跳。路由器启动RIP后，会周期性把路由表里所有通过RIP学到的条目，加上自己直连的条目，打包成Response报文发给所有启用了RIP的接口。

这句话背后有个容易被忽略的重点：RIP根本不验证目的网络是否真的可达，它只是信任邻居给过来的信息。你说3.3.3.3是2跳，我就记成2跳；你下一秒说3.3.3.3变成16跳了，我也跟着改成16跳。这套信任模型极其简单，也因此正是环路问题的根源。后来RIP设计了水平分割、毒性反转和触发更新这些机制去打补丁，但始终没有从根本上解决“我无法验证你告诉我的是真是假”的问题。

3.2 四种计时器的联动关系

RIP的路由条目不是永久有效的，每条路由都受一组计时器管理。思科IOS的默认值如下：

这几个数值的联动关系是：一条路由如果在invalid计时器超时前没有收到新的更新，它先被标记为不可达；从标记不可达那一刻起，holddown计时器开始计数，这段抑制期内即使邻居通告了更好或等价的路由，路由器也暂时不听；等到flush计时器超时，路由条目被彻底删除。

我在实验里故意停掉R3的Loopback0，R1上那条3.3.3.3/32的路由从显示变为消失，走了将近三分钟。这个“等待”就是计时器机制在起作用。直观感受是慢到让人怀疑配置错了，但理解了机制之后就明白，这正是为了抑制网络中短暂的路由抖动而付出的代价。

3.3 水平分割、毒性反转与抑制计时器

防环机制是RIP实验里必须亲眼看一遍的内容，只看文字描述很容易看过就忘。

水平分割规则一句话说清：从哪个接口学来的路由，绝不再从这个接口通告回去。R2从G0/0学到1.1.1.1，那么在G0/1上通告路由时1.1.1.1会正常出现，但在G0/0上就不会再把这个路由原样发给R1了。这条规则阻断了A和B之间来回传送路由信息形成环路的经典场景。

毒性反转是水平分割的加强版。不是“不回传”，而是“回传时把度量值改成16”，也就是明确告诉对端这个网络不可达，比单纯沉默更积极。RIPv2里这个行为通常表述为“把该路由置为毒性路由”后再通告。抓包时看到某个条目的Metric字段突然变成16，就是这个机制在工作。

抑制计时器和这两个机制配合，形成一个多维防环体系。在故障瞬间，R2发现3.3.3.3不可达后，会通过毒性路由快速通知R1；但R1不会因为收到这条坏消息就立刻相信“全网都崩了”，它会先进入抑制状态，这个状态持续期间不接受来自任何邻居的等价或更差路由。这样的组合能够把绝大多数简单拓扑中的路由振荡压制住。

3.4 RIPv1和RIPv2的核心差异

实验里我用的是RIPv2，因为RIPv1在实际使用中的问题太明显了。两者关键差异可以看这张表：

RIPv1不携带子网掩码，这意味着它在有类网络边界上只能按主类汇总，无法支持可变长子网掩码。如果实验环境里存在跨越主类边界的子网划分，RIPv1就会出现一堆诡异的路由缺失问题。所以除非你刻意在验证RIPv1的有类特性，否则一律建议直接从RIPv2起步。

4. 配置实操：从零到全网互通

环境准备和机制都理清楚之后，配置反而是最简单的一步。三台设备配置基本一样，先给接口配IP，然后进RIP进程宣告网络。R1的完整配置如下：

interface GigabitEthernet0/0 ip address 192.168.12.1 255.255.255.0 no shutdown interface Loopback0 ip address 1.1.1.1 255.255.255.255 router rip version 2 network 1.0.0.0 network 192.168.0.0 no auto-summary

R2的配置多了G0/1：

interface GigabitEthernet0/0 ip address 192.168.12.2 255.255.255.0 no shutdown interface GigabitEthernet0/1 ip address 192.168.23.2 255.255.255.0 no shutdown interface Loopback0 ip address 2.2.2.2 255.255.255.255 router rip version 2 network 2.0.0.0 network 192.168.0.0 no auto-summary

R3和R1结构一致，把Loopback0换成3.3.3.3即可。

这里要说一个思科IOS特有的细节：router rip下的network命令写的是主类网络号，不是精确的IP地址或子网号。我写network 1.0.0.0，意味着凡是属于1.0.0.0主类的接口都会参与RIP，并不只是精确宣告1.1.1.1这一个地址。这正是RIP的network和OSPF的network在思科体系里最大的区别——OSPF的network需要写反掩码做精确匹配，RIP只需要撞上主类就行。很多第一次接触RIP的人在这里栽跟头，反复检查发现命令没错，但路由就是学不到，其实是对network匹配逻辑理解偏了。

配置完成后，在R1上查看路由表：

R1#show ip route rip 2.0.0.0/32 is subnetted, 1 subnets R 2.2.2.2 [120/1] via 192.168.12.2, 00:00:17, GigabitEthernet0/0 3.0.0.0/32 is subnetted, 1 subnets R 3.3.3.3 [120/2] via 192.168.12.2, 00:00:13, GigabitEthernet0/0

括号里的120是RIP的管理距离，后面的1和2分别是跳数。2.2.2.2在R2上，所以R1到达它要1跳；3.3.3.3在R3上，要经过R2转发，所以是2跳。输出中的时间字段代表这条路由从收到开始已经存在了多少秒，超过30秒没有刷新的话，新的一轮更新又会把它续上，所以这个时间会循环归零。

再执行show ip protocols，可以看到协议运行的完整参数：

R1#show ip protocols Routing Protocol is "rip" Sending updates every 30 seconds with +/-50%, next due in 18 seconds Invalid after 180 seconds, hold down 180, flushed after 240 Redistributing: rip Default version control: send version 2, receive version 2

这个输出把计时器的当前配置和版本控制都列出来了。注意“next due in”这个值，由于更新周期带有随机偏移，你看到它剩余18秒完全正常，反过来也能明显观察到不同路由器发更新的时间点不是严格对齐的。

如果你用的是华为eNSP或者真机，命令风格会不一样，但机制一样，核心配置如下：

[R1] rip 1 [R1-rip-1] version 2 [R1-rip-1] network 1.0.0.0 [R1-rip-1] network 192.168.0.0

华为VRP里的network命令后面可以带通配掩码做更精细的宣告，比如network 192.168.12.0 0.0.0.255，这是思科IOS默认只能写主类网络所不具备的灵活度。验证命令相应变成display rip 1 route和display ip routing-table protocol rip。

5. 抓包验证：亲手看到RIP报文长什么样

配置通了之后，我强烈建议停下来抓一次包，这正是模拟器比真机更舒服的地方。在GNS3里对R1连接R2的那条链路开启Wireshark，抓包过滤器直接写：

rip or udp.port == 520

RIPv2使用组播地址224.0.0.9作为目的地址，UDP端口是520。抓几十秒就能看到R1和R2互相发送的Response报文，每条路由一个条目，周期大约是30秒。

点开一个Response报文，几个关键字段值得仔细看。

Command字段有两个取值，1表示Request请求，2表示Response应答。路由器刚启动RIP或者收到邻居的Request时，会先发一个Request过去，邻居收到后立刻回一个Response。此前抓包大多数时候看到的都是周期性的Response。

Version字段显示2，对应RIPv2。

核心部分是路由条目，每一条的结构是一次IP地址、子网掩码、下一跳、度量值的组合。抓包工具会把它们列成多行，每一行就是一条路由。例如一个条目里IP Address是3.3.3.3、Subnet Mask是255.255.255.255、Metric是2，代表这条路由通告的是3.3.3.3/32，到达它需要2跳。

还有个容易被忽视的设计细节：一个UDP报文里最多装25条路由。为什么是25？因为RIP强制规定整个报文最大512字节，UDP头8字节、RIP公共头4字节、每条路由条目20字节，512减去12再除以20，结果就是25。这个数字不是我编的，是协议规范里明确算死的。如果路由表超过25条，路由器就得拆成多个Response报文分批发，你会在抓包里看到同一时刻发出多个目的地址为224.0.0.9的UDP报文。

抓包还有助于理解毒性路由的样子。我在R3上执行shutdown把Loopback0关掉，然后盯住R3发往R2的下一个更新报文，会发现里面多了一个3.3.3.3的条目，Metric变成了16。这就是毒性反转的实际表现，R3明确告诉R2“3.3.3.3已经不可达”。R2收到后再向R1发更新时，会把这个毒化信息继续传递。整个过程中不需要等待30秒的更新周期，触发更新机制会把这条坏消息以最快的速度推出去。

做一个对比实验效果更直观：把Loopback0重新no shutdown，然后马上抓包，R3发出的更新里3.3.3.3的Metric又变回了0跳（因为它是R3自己的直连）。恢复的速度同样很快，几乎是一瞬间的事，这就是触发更新对收敛的贡献。

如果抓不到任何RIP报文，优先检查两件事。第一，PC网卡桥接是否正确，模拟器里的cloud设备有没有挂到正确的链路端口上；第二，在设备上执行debug ip rip，确认更新到底有没有发出。Wireshark抓包是“从旁路看”，debug是“从内部看”，两个手段配合能快速定位问题到底出在发送端、链路还是接收端。

6. 三类典型故障的复现与排查

6.1 学不到路由，先查network宣告范围

实验里最容易遇到的故障就是某条路由全网学不到，最常见原因是network宣告范围漏了。比如R3上只敲了network 192.168.0.0，忘记把Loopback0的3.0.0.0宣告进去，那么R1上永远看不到3.3.3.3这条RIP路由。

排查路径很有代表性。先在R1上看show ip route rip，确认3.3.3.3确实缺失；然后到R3上执行show run | section router rip，检查宣告范围；再执行debug ip rip观察R3每次发出的更新条目里有没有3.3.3.3。这三步就能稳定定位是“没宣告”还是“宣告了但没学到”。

这里还想提醒一个坑：no auto-summary这条命令。如果IOS版本比较老或者默认行为不一致，RIPv2开启后自动汇总仍然生效，会导致192.168.12.0/24和192.168.23.0/24被汇总成192.168.0.0/16发布，看似“正常”但子网信息丢失。所以在配置里主动写no auto-summary是值得养成习惯的动作，避免在不同IOS版本之间踩坑。

6.2 多余的接口被宣告成RIP邻居

如果把R1上连着PC的接口也写进了RIP的network范围，就会发生一个很有意思的现象：PC网卡会持续收到组播到224.0.0.9的RIP更新报文。绝大多数情况下PC上的Windows防火墙会直接丢弃这些组播流量，对整个实验没有破坏性，但这个行为说明RIP正在向一个本不该参与路由的接口广播路由信息，既浪费带宽又暴露网段拓扑。

这个问题的正解是配置被动接口，思科IOS里有两种做法：

router rip passive-interface GigabitEthernet0/1

或者干脆把所有接口设为被动，再单独挑出需要启用路由协议的接口：

router rip passive-interface default no passive-interface GigabitEthernet0/0

华为VRP里对应的是silent-interface命令。被动接口的作用是这个接口不再主动发送RIP更新，但仍然能够接收和处理收到的更新。这种“只收不发”的模式非常适合网络出口连接接入层设备时的场景。

生产环境里被动接口是个高频配置，因为没有人希望路由协议在接入层到处刷存在感。实验里也建议养成习惯，只让路由器之间的互联接口真正参与RIP协议交互，其余接口全部静默。

6.3 收敛慢到怀疑人生：实测计时器的影响

这个故障实验不需要改变配置，只做操作加观察即可。在R1上先用ping 3.3.3.3把连通性确认好，然后到R2和R3之间的链路上执行shutdown，模拟链路彻底中断。随后在R1上每隔几秒执行一次show ip route 3.3.3.3，记录路由条目的状态变化。

我的实测结果是：链路断开后的前180秒内，R1上3.3.3.3/32这条路由仍然存在，显示正常；到大约180秒上下，条目被标记为不可达，show ip route的输出里它可能变成带问号或消失的状态；再往后一段时间，条目被彻底删除。整个“感知故障并删除路由”的过程大概持续了240秒左右。

为什么直连故障发生了，远端要等那么久才肯删除？因为R2和R3之间的链路断掉后，R2虽然在直连层面立刻感知到了，但它还需要把“3.3.3.3不可达”这个信息通过RIP传给R1。如果触发更新恰好在这个节点上工作，R1可能在几十秒内就收到毒性路由；但由于holddown计时器和invalid计时器的存在，R1即使收到了坏消息，也会按照协议规定等待一段时间，确认这个消息不是网络抖动造成的假象，然后才执行删除动作。这就是收敛慢的根源，也是RIP被链路状态协议取代的关键原因之一。

为了观察这个机制全貌但又不想等太久，可以在实验环境里临时把计时器调小：

router rip timers basic 5 30 30 60

update周期5秒、invalid 30秒、holddown 30秒、flush 60秒，整个收敛过程缩短到一分钟以内。这只适合实验环境验证机制，生产环境的RIP千万别改计时器，不同厂商设备对计时器的容忍范围不一致，改不好会让路由不断振荡。

7. 实验延伸：默认路由注入、等价负载和RIPng

基础实验跑通之后，有三件我认为很值得顺手做的延伸，它们分别对应生产网络中非常常见的三个场景。

第一个是默认路由注入。假设R1是企业出口路由器，它连接运营商时并没有学来具体路由，只想让内网把流量全部交给它。这时可以在R1上开启：

router rip default-information originate

R2和R3就会从RIP更新里收到一条0.0.0.0/0的默认路由。这个配置模拟了企业内部默认路由通告的经典方式，适合和静态默认路由配合使用。

第二个是等价负载均衡观察。把拓扑改成一个三角形链路，R1分别连R2和R3，同时R2和R3相连，那么R1到达3.3.3.3将存在两条等价路径。RIP默认支持4条等价路由，执行show ip route rip会看到同一目的地址下面出现两个via条目：

R 3.3.3.3/32 [120/2] via 192.168.12.2, 00:00:09, GigabitEthernet0/0 [120/2] via 192.168.13.3, 00:00:09, GigabitEthernet0/1

流量会在两条路径间分摊，这个行为能直观体现RIP对等价路径的处理方式。

第三个是RIPng，给IPv6网络用的RIP版本。它和RIPv2的机制几乎一样，但独立进程、独立命令，使用UDP端口521，组播地址改为FF02::9。思科IOS里需要先开启IPv6路由转发，然后单独进入ipv6 router rip进程配置。大部分人在实际工作中不太会遇到RIPng，但知道它存在、知道它的端口和组播地址，遇到老设备上的IPv6路由需求时就不会一头雾水。

我自己的体会是，RIP实验最值得花时间的地方不是把三台路由器配置到互通，而是配置完成后那一个小时的抓包和故障注人。亲眼看到30秒周期的更新报文、毒性路由的Metric=16、计时器倒计时带来的秒级等待，这些经验会沉淀成一种直觉，往后排OSPF或者BGP的问题时，你会下意识去想“这条路由的失效计时器是多少”“抑制期到了没有”“为什么这么大的网络接到一条坏消息却要等这么久才能一致”。把这些朴素机制吃透了，再看那些复杂的路由协议，一切都显得顺理成章。