企业官网建设流程全解析

1. 实验场景与核心价值拆解

RIP协议，全称Routing Information Protocol，是很多网络工程师摸到的第一个动态路由协议。当年我刚接触这个协议的时候，觉得它简单得不像话，无非就是“告诉你我有什么路由，再告诉你我从你那里学到了什么”，一条默认管理距离120、以跳数做度量值、最大15跳封顶的协议，怎么看都透着一种古老的味道。但真到了做RIP协议实验的时候，我才发现事情没那么简单——版本兼容、主类网络宣告、计时器配合、防环机制，每一个坑都值得掰开揉碎地过一遍。

这个实验解决的核心问题其实很具体：在没有OSPF、没有BGP的纯小型网络环境里，如何用最简单的动态路由协议让多台路由器自动学习全网路由，并保证链路故障时的收敛行为可控。它适合三类人：一是高校计算机网络课程的学生，需要把“距离矢量”从教材概念变成设备上的真实状态；二是备考网络工程师认证的考生，RIP实验是理解路由协议原理的必经之路；三是刚入行的运维或网工新人，想在动手敲命令的过程中建立起“路由表是怎么来的，又是怎么消失的”这种底层直觉。

我选择用GNS3做这个实验，三台路由器串联组网，跑的镜像用Cisco IOS。之所以不用Cisco Packet Tracer，是因为RIP的很多细节行为需要在真实的协议交互里去观察，而GNS3的抓包和调试输出更接近生产环境。实验做到了什么程度才算合格？不只是路由表里出现R标记就完了，而是要把RIPv2更新报文的交互过程、计时器对路由生命周期的影响、环路防止机制的实际作用点，全部在设备输出和抓包里得到验证。

1.1 RIP协议的核心机制与控制点

做RIP实验之前，必须把协议本身的行为机制想清楚，否则敲命令只是照猫画虎。

RIP属于距离矢量路由协议，它和链路状态协议最本质的区别在于：RIP不维护全网拓扑图，每个路由器只知道“我距离某个网络多少跳，下一跳是谁”。这个设计思路决定了它的三个关键行为特征：

第一，RIP的路由度量值就是跳数，每经过一台路由器，跳数加1。跳数16被定义为“无穷大”，表示不可达。这两个数字是整个协议行为的根基，后面你会经常看到16这个数字出现在各种防环机制里。

第二，RIP依靠周期性广播或组播来交换完整路由表。RIPv1用广播地址255.255.255.255更新,每30秒发一次;RIPv2改用组播地址224.0.0.9，支持子网掩码传递和认证。这意味着RIP的收敛不会像OSPF那样快，它的收敛是靠“定时器驱动 + 触发更新辅助”来完成的。

第三，RIP的防环机制是叠加式的。最大跳数限制、水平分割、毒性反转、抑制计时器、触发更新，这五样东西组合在一起，构成了距离矢量协议防止路由环路和计数到无穷的完整防线。理解这五样东西在实验中各自扮演了什么角色，才是这个实验真正的进阶价值。

1.2 实验环境的选型：为什么GNS3比模拟器更能说明问题

RIP协议实验听起来简单，但选对实验环境直接决定了你能观察到什么层次的现象。

如果你只是为了快速出效果，Cisco Packet Tracer确实够用，点几下鼠标，配几条命令，路由表里能看到R路由。但Packet Tracer对协议行为的模拟精度有限，它不会完整呈现RIPv2报文里的Route Tag、Next Hop字段，也不会真实模拟计时器超时后的holddown行为细节。换句话说，你能看到结果，但看不到过程。

我实际用的是GNS3 + Cisco IOS镜像，原因有这么几条：

• 抓包能力。GNS3可以在任意链路上开启Wireshark抓包，直接看到RIPv2的UDP 520端口报文，里面每一跳的条目、跳数字段、网络掩码都清清楚楚。这是理解RIP路由交换最好的“解剖镜”。
• 调试输出完整。RIP协议在真实IOS上支持debug ip rip命令，会逐条打印路由更新的收发记录，包括“从哪个接口收到哪条路由、跳数是多少、是否加入路由表”。这个输出是Packet Tracer完全没有的。
• 计时器行为真实。RIP的update/invalid/holddown/flush四个计时器在真实IOS上是严格按秒走的，你可以亲眼看着一条路由从“有效”变成“可能无效”，再到“被删除”，这个生命周期过程是RIP实验最有价值的部分。

当然，这里补充一点，如果你没有GNS3条件，用EVE-NG也一样，后端一样是真实IOS，只是管理界面不同。如果手里有真实路由器，那就更好了，不过真实设备上RIP实验的体验反而不如模拟器方便，因为抓包和重置状态都更麻烦。

2. 拓扑设计与关键参数详解

RIP实验的拓扑设计不需要复杂，但也不能图省事只放两台路由器。两台设备只能演示路由学习，很多关键行为根本暴露不出来。

我用的拓扑是三台路由器串成一条链：R1连接R2，R2连接R3，每台路由器带一个独立loopback网段模拟终端网络。拓扑图就不画了，实际设备的互联关系如下。

为什么选这个拓扑？三台路由器串行连接可以构造出“路径长度”的概念：R1到R3的loopback需要经过两跳，R1到网络中任意一点都有清晰的跳数梯度。水平分割机制可以用R2作为观察点直接验证：R2从R1学到的路由，不会原样发回给R1。毒性反转机制也能在这里演示：当R3的loopback接口被shutdown时，R2会把这个网络以16跳标记为不可达，再回传给R3。

还有一个细节要注意：RIP宣告网络用的是主类网络号，不是子网号。在上面的规划里，192.168.12.0/24和192.168.23.0/24虽然是两个子网，但它们同属B类主类网络192.168.0.0的范围内，RIPv1下会被自动汇总成192.168.0.0/16。RIPv2配合no auto-summary命令才可以精确传递子网路由。这个特性是RIP实验里面最容易让人困惑的配置点，我后面会专门展开说。

2.1 RIP版本选择：v1、v2还是兼容模式？

RIP实验的版本选择，直接决定了你能体验到什么层级的协议行为。

RIPv1是真正的“古董级”实现，它有四个显著缺陷：没有VLSM支持、没有CIDR支持、没有认证、更新用广播发送。在今天的网络环境里，你几乎不可能在真实生产设备上遇到还开着RIPv1的场景。但RIPv1作为实验对象并非毫无价值，它可以帮助你理解为什么经典距离矢量协议无法适应无类网络的原因，以及RIPv2到底解决了什么问题。

RIPv2在报文结构上做了扩展，引入了子网掩码字段、下一跳字段、路由标记字段，并且支持明文或MD5认证。它用组播地址224.0.0.9发送更新，相比广播方式降低了无关主机的处理开销。在实验配置上，我建议直接使用RIPv2，命令就一句：version 2。

这里有个实际操作中的经典坑：很多人在配置RIPv2之后，发现邻居对端还是RIPv1，两边会直接无法正常交换路由。RIP协议没有类似OSPF那样的“邻居协商过程”，它就是老老实实地发自己的更新报文，接收方收到后如果版本不匹配就无法正确解析。所以实验前一定要确认所有参与设备上的RIP版本一致。如果你遇到“路由表里什么都没有，debug也没有任何输出”的情况，先检查版本，大概率是版本不匹配。

在实际网络中还有一种“兼容模式”的说法，即接口下配置ip rip send version 1 / ip rip receive version 2之类的组合。这个模式更多用于RIPv1到RIPv2的迁移过渡期。实验阶段不建议一上来就玩兼容模式，先把纯v2环境跑通，再去研究兼容模式下的报文差异会更有收获。

2.2 主类网络宣告规则与auto-summary的坑

RIP协议里最容易被忽视、但实验中几乎必踩的坑，就是network命令的宣告规则。和OSPF的network命令可以精确匹配到子网不同，RIP的network命令后面跟的是一个主类网络号。这句话是什么意思？我配置R1的GigabitEthernet0/0接口地址为192.168.12.1/24时，我宣告network 192.168.12.0会得到什么效果？

答案是：IOS会自动把它归类到主类网络192.168.0.0下面，等于宣告的是整个B类网络。如果你只有192.168.12.0/24这一个子网，那宣告192.168.12.0和宣告192.168.0.0效果一样。但如果你同时还有192.168.23.0/24这个子网，并且宣告了network 192.168.0.0，那么RIP会把两个子网都纳入协议进程。这就是RIP“按主类网络宣告”的含义。

在RIPv2下，如果不关闭自动汇总，路由条目从有类边界跨越出去时会被自动汇总成主类网络。举个例子：R2从R1学到了192.168.12.0/24，又从R3学到了192.168.23.0/24，在向R1发送更新时，因为192.168.23.0/24和192.168.12.0/24都属于192.168.0.0这个主类网络边界内部，条目不会汇聚。但如果R2再往上游连接一个10.0.0.0/8网段里的子网，并且这个子网和R2本地主类网络不同，那它就会以10.0.0.0/8的汇总形式通告出去。

为了精确传递子网信息，实验里必须配置no auto-summary。否则你会看到一种很魔幻的现象：路由表里明明有10.1.1.1/32这条loopback路由，但对端路由器收到的却是10.0.0.0/8的汇总条目。很多初学者在RIP实验里配到这一步百思不得其解，原因就在这里。

3. 路由配置与核心命令逐条解析

RIP的配置命令在整个动态路由协议家族里算是最简单的，命令少、参数少、不需要复杂的区域划分或邻居关系定义。但简单不等于无脑，每一条命令后面的含义都值得展开讲。

以R1为例，完整的RIP配置如下。

R1#conf t R1(config)#router rip R1(config-router)#version 2 R1(config-router)#network 192.168.0.0 R1(config-router)#network 10.0.0.0 R1(config-router)#no auto-summary R1(config-router)#end

第一条router rip进入路由进程，第二条version 2设定版本，第三条和第四条分别宣告两类主类网络，第五条关闭自动汇总。配置本身确实就这么多。

但很多人在这里会问一个问题：为什么我只宣告了10.0.0.0和192.168.0.0，没有精确宣告10.1.1.1/32？这正是RIP和OSPF在配置范式上最大的区别。RIP不关心你的子网掩码具体是多少，它只关心“这条链路属于哪个主类网络”，然后就按这个粒度去通告。所以loopback接口10.1.1.1/32属于10.0.0.0这个A类网络，宣告network 10.0.0.0之后，RIP进程会自动把这个接口的直连路由纳入通告。

还有一点，network命令宣告的是“哪些接口参与RIP”，不是“哪些路由要通告”。接口一旦匹配上被宣告的某个主类网络，这个接口上的直连路由就会进RIP更新，同时这个接口也会收发RIP报文。理解这个逻辑，你就能解释很多看似奇怪的现象——比如某个接口没有配置IP，但RIP进程里宣告了该接口所在的主类网络，结果是这个接口上没有路由可通告，只参与收发更新报文。

R2和R3的配置逻辑完全一样，只是宣告的网络略有差异。R2需要宣告192.168.0.0和10.0.0.0，R3同样是这两个主类网络，因为R3也没有接入其他主类网络。如果你在实验里额外设计了一个172.16.x.x的网段接在某台路由器上，别忘记把172.16.0.0也宣告进RIP进程。

配置完成后，用show ip protocols查看协议状态，重点观察Routing Information Sources栏位里是否有邻居地址，以及版本信息是否一致。然后看一下show ip route，R1上应该能看到两条带R标记的路由：192.168.23.0/24 via 192.168.12.2，以及10.3.3.3/32 via 192.168.12.2。如果这两条都出现了，说明RIP基本工作正常。

3.1 debug ip rip与抓包解读：路由更新到底长什么样

RIP的路由更新报文是协议行为的直接体现，单纯看路由表只能看到结果，要看懂过程就必须抓包加debug。

在R1上执行debug ip rip，你会在控制台看到类似下面的输出：

RIP: sending v2 update to 224.0.0.9 via GigabitEthernet0/0 (192.168.12.1) RIP: build update entries 10.1.1.1/32 via 0.0.0.0, metric 1, tag 0 RIP: received v2 update from 192.168.12.2 via GigabitEthernet0/0 192.168.23.0/24 via 0.0.0.0, metric 1, tag 0 10.2.2.2/32 via 0.0.0.0, metric 1, tag 0 10.3.3.3/32 via 192.168.12.2, metric 2, tag 0

每次更新报文的交互过程都一目了然。一个值得特别注意的字段是metric。在R1收到来自R2的更新里，10.2.2.2/32的metric为1，因为R2直连网段到10.2.2.2就是跳数1；而10.3.3.3/32的metric为2，说明这条路由在R2看来已经是一跳之后，再传给R1又要加一跳，所以变成了2。这个“每经过一台路由器就加1”的递进关系，就是距离矢量路由协议的精髓所在。

在GNS3里对R1-R2之间的链路开启Wireshark抓包，过滤udp.port==520可以看到具体的报文内容。RIPv2的报文结构其实很直观：头部包含Command字段（1表示请求，2表示响应）、版本字段、AFI、IP地址、子网掩码、下一跳和Metric。我看到过很多初学者抓包之后对着这些字段发愣，其实只需要关注三个地方：版本号是不是2，Metric值是不是和debug输出一致，以及路由条目里的下一跳字段是0.0.0.0还是有具体地址。

这里说一个抓包实验的有趣现象：RIPv2默认每30秒发送一次完整路由表的更新，但在链路状态稳定的时候，你可能会发现更新的间隔并不是严格30秒。这是因为RIP的更新定时器带有一个随机抖动偏移，范围是0到5秒之间。这个设计是为了避免网络里多台路由器同时发送更新导致同步拥塞。这个细节在一个纯粹的配置型实验里很难注意到，但在Wireshark的时间戳上能看得清清楚楚。

实验结束前记得用no debug ip rip关掉调试输出，debug在真实设备上会占CPU资源，实验机上无所谓，但养成好习惯很重要。

3.2 路由收敛中的计时器行为与故障注入

RIP协议有四个核心计时器，不少教科书只提“30秒更新周期”这一个，实际上做实验下来你会发现，真正决定路由生命周期的是后三个。

• Update计时器（默认30秒）：周期性发送路由更新。
• Invalid计时器（默认180秒）：如果一条路由超过180秒没有收到刷新，被标记为“可能无效”。
• Holddown计时器（默认180秒）：一条路由变成无效状态后进入抑制期，期间即使收到更优路径也不会立即替换。
• Flush计时器（默认240秒）：如果240秒内一直没有收到刷新，该路由从路由表中彻底删除。

这组计时器的配合关系是RIP特有的行为。在GNS3里，我们可以做一个经典的故障注入实验来观察整个生命周期：把R3的Loopback0接口shutdown掉，然后在R2上持续观察这条路由的状态变化。

刚shutdown时，R3会立刻通过触发更新把10.3.3.3/32标记为16跳（不可达）并发送给R2。R2收到后，正常情况下不会立即删除路由，而是进入holddown状态。这180秒以内，R2的路由表里10.3.3.3/32这个条目还在，但标记可能是“possibly down”。如果你在R2上ping 10.3.3.3，会发现一直超时，明明路由表里有条目，却转发不过去。这个状态就很直观地展示了“路由存在但并不代表可用”的概念。

等invalid计时器超时，即距离最后一次有效更新过了180秒之后，路由变成“possibly down”状态；继续等到flush超时，即240秒后，条目才会从路由表中彻底消失。整个过程你可以一边watch show ip route一边记录时间点，我实测下来的节奏是：shutdown后约30秒内能看到触发更新，180秒后条目进入抑制，240秒后删除。如果实验时间充裕，建议把计时器调到更快的节奏来观察，例如：

R2(config-router)#timers basic 5 30 30 40

把更新周期改成5秒，invalid改成30秒，holddown改成30秒，flush改成40秒，这样整个路由失效生命周期可以在不到一分钟内完整走完，非常适合教学演示和快速理解。注意这个命令是对整个RIP进程生效的，且必须在配置路由进程阶段就设置好，不能在运行状态下修改。真实生产环境里随意改动RIP计时器是高风险操作，实验环境里倒是可以大胆尝试。

4. 防环机制实验：水平分割与毒性反转的实际表现

RIP实验做到路由学习阶段只能算入门，真正的核心价值在防环机制的部分。这部分内容在书本上往往只有几段抽象描述，但在设备上实测之后，你对距离矢量协议的理解会完全不一样。

水平分割的规则很简单：从某个接口学到的路由，不能再从同一个接口发回去。这样做是为了防止两台路由器之间出现路由反馈环路。在R1和R2的链路上抓包，你会发现从R2发往R1的RIP更新报文里，永远不会包含192.168.12.0/24这个网络条目，因为它是R2从192.168.12.0这个接口上（也就是从R1方向）学到的。这个行为不需要任何额外配置，默认就是开启的。

要验证水平分割的真实效果，在R2上执行show ip interface gigabitethernet0/0，可以看到Split horizon is enabled的字样。如果想观察关闭后的行为，在接口视图下配置no ip split-horizon，再抓包就会发现R2开始把R1学到的路由原封不动地回传给R1，这个时候如果没有其他防环机制兜底，就会出现路由反馈。

毒性反转是水平分割的增强版。它不是在接口上简单地“不发回”路由，而是把从某接口学到的路由以16跳（不可达）的形式显式地发回去。这么做的作用是主动告知上游路由器“这条路已经不可用了”，加速路由的收敛和错误信息清除。

在R2上有个细节操作可以触发明显的毒性反转效果：把R3的Loopback0 shutdown后，在R2-R1的链路上抓包，你会发现R2很快给R1发送了10.3.3.3/32 metric 16的条目。这就是R2在收到R3的触发更新后，再通过毒性反转机制把这个坏消息广播给其他邻居。如果没有毒性反转，R1可能还要等最长30秒的更新周期才能感知到网络变化。

防环机制里还有一个很容易被忽略的全局机制：最大跳数限制。RIP把16定义为无穷大，当路由信息在环路里反复传递时，每转一圈跳数加1，直到达到16跳就会被丢弃，彻底终止环路的无休止传播。所以你在前面看到的毒性反转把metric标记为16，正是利用了最大跳数这一规则：一个16跳的路由条目，在距离矢量算法面前等价于“不可达”。

4.1 环路模拟实验：如果关掉所有防环机制会怎样

RIP的防环机制不是摆设，如果你真的把水平分割关掉，让两台路由器之间相互学习并回传路由，路由环路就会在十几秒内形成。

我做过这个实验。在R1和R2的互联链路上关闭split-horizon，再手动构造一个“虚假”的远端网络，比如在R1上配置一条静态路由指向一个不存在网段，然后通过redistribute static让RIP通告出去。R2会学到这条路由，因为水平分割已经关闭，它又会在下个更新周期里把这条路由原样传回给R1。R1收到后一看，“这个网段我没直连啊，但它是从R2学来的”，于是把这条路由加入路由表，metric加1。接下来每个30秒，这条路由就在R1和R2之间互相传递，跳数不断累加。

抓包结果会非常直观：第一次更新时跳数是1，第二个周期变成2，然后是3、4、5...当metric累加到16时，该路由条目被标记为不可达并被丢弃，环路才自然终止。这个“计数到无穷”的完整过程大约需要8分钟，因为每30秒只加一跳。如果你配合前面提到的timers basic命令把更新周期缩短到5秒，整个环路演化过程可以在1分多钟内看到全貌。

做完这个实验再回头看RIP为什么会设计水平分割、毒性反转、最大跳数限制这一整套组合拳，就明白了：单靠任何一个机制都不能完美杜绝环路，RIP采用的是“多层防护、组合出击”的策略。这也是后来OSPF等链路状态协议出现并取代RIP的根本原因——链路状态协议持有全网拓扑图，天然不存在环路问题，不需要依赖这些防御性机制。

4.2 次优路径与管理距离：RIP实验里容易忽略的细节

RIP的默认管理距离是120，这是一个很容易在实验里被忽略、但在实际网络里影响重大的参数。管理距离是路由器选择路由来源的优先级，数值越小越优先。静态路由的默认管理距离是1，直连路由是0，而RIP是120。

这意味着什么？我在实验里构造过这样一个场景：R2上同时配置了一条静态默认路由指向R1，并且RIP进程从R1也学习到了一条指向同一网段的路由，即使静态路由对应的物理链路实际上已经断开，路由器依然会把静态路由留在路由表中优先使用。因为静态路由的管理距离更小，RIP路由根本没有机会进入路由表。这个现象让很多初学者困惑不解——明明RIP学到了更优路径，为什么show ip route里看不到？原因就是管理距离。查看show ip route输出，你会发现路由条目代码那里写着R，但前面没有星号标记，表示这条路由虽然被RIP学到了，但因为来源优先级不够，没有放入路由表。

在实验里验证这个细节，可以在R2上配置ip route 10.3.3.3 255.255.255.255 192.168.12.1，观察路由表变化。你会看到10.3.3.3/32的下一跳立即切换成了192.168.12.1（静态路由路径），而RIP路由虽然仍然在后台学习，却因为管理距离更大只能“坐冷板凳”。这个行为在真实网络中常常导致路由黑洞，排查起来也很费劲。

理解了管理距离，再看RIP的度量值跳数，你就会发现RIP选路有个很大的软肋：它完全不考虑带宽、延迟和负载。两条路径一条是千兆光纤、一条是56K拨号，只要跳数一样，RIP就会负载均衡到两条都走。这在今天的网络环境里简直不可接受。这也是为什么RIP只能在很小规模的网络里存活，而且逐渐被OSPF、EIGRP等更智能的协议取代的原因。

5. 常见问题与排查技巧实录

RIP实验做完一轮，我整理了几个实际中最高频的故障现场，每一个都在真实设备或GNS3里遇到过。如果你把这些排查思路记住，能省下大量排错时间。

第一个经典故障是路由表里一条R路由都看不到。排查顺序是这样的：先用show ip protocols确认RIP进程已经启动、版本正确、宣告的网络正确；然后ping对端接口地址确认链路层通了；再用debug ip rip看有没有更新报文收发。如果debug显示发送正常但没收到，检查两端版本是否一致；如果发送和接收都正常但路由表不更新，检查是否被入方向过滤或ACL阻断了。我在GNS3里遇到过一个特别隐蔽的情况：RIP更新报文虽然到达了接口，但被接口下的ip access-group入方向策略丢弃了，这时候debug ip rip完全看不到任何接收记录，排错一度陷入僵局。

第二个高频问题是RIP路由存在但下一跳不可达。这类问题在NBMA环境或部分mesh拓扑里出现概率较高。RIPv2的更新报文里带有明确的下一跳字段，如果下一跳地址在接收方看来不可达，路由会被接收但无法使用。实验里简单排查方式就是show ip route看路由条目的下一跳字段，再ping这个地址确认连通性。

第三个问题是收到汇总路由而不是精确子网路由。前面已经详细说过，这是auto-summary在作怪。如果你故意没有配置no auto-summary，R2往R3通告192.168.12.0/24时，由于跨主类网络边界，会汇总成192.168.0.0/16。R3收到的路由条目就是错误的，检查这个现象时重点看路由条目的掩码位数。

第四个问题是GNS3特有的环境坑。GNS3里路由器接口默认是shutdown状态，必须手动no shutdown，这个漏配会让链路协议明明起来了但网络不通。另外GNS3的分布式交换矩阵有时会导致RIP组播报文丢失，如果debug显示发送正常但接收端完全无响应，可以考虑关闭组播改用单播邻居，RIP支持neighbor命令指定单播更新地址，这是兼容老设备和特定组网需求时的常用手段。

5.1 路由卡在“possibly down”状态的处理

在实际操作中，RIP实验最容易让人慌的是看到路由状态变成possibly down，而且长时间不恢复。我从观察中得到的经验是：这个状态多数发生在对端设备已经停止发送RIP更新的情况下，本端的invalid计时器超时后，路由会进入抑制期。

处理思路其实很简单：先判断对端设备是不是还活着。如果对端正常，检查它为什么停止发送更新——可能是协议进程崩溃、接口被shutdown、或者ACL把出方向的UDP 520封堵了。如果对端确实故障了，那possibly down就是正确的协议行为，不用干预，等flush计时器超时后自动删除。如果在holddown期间对端恢复并发送了带正确度量的更新，路由会立刻恢复到有效状态，不再等待完整的计时周期。

这里有一个小技巧：在实际操作中很多人分不清holddown和possibly down的实际区别，看到路由标记变了就开始紧张。我的建议是——不必紧张，RIP协议内部的这套延迟删除机制就是为了防止不稳定抖动导致路由频繁切换。只要最终能收敛，它就是正常工作的。

5.2 RIP实验的扩展：从Cisco IOS到FRR和Linux

实验做到这里，如果你想从Cisco环境跳出来，看看RIP在真实开源世界的实现方式，我强烈建议再做一个扩展实验：用Linux加FRRouting（FRR）跑一套RIP。FRR是当前Linux世界里最主流的动态路由软件套件，它实现了RIP、OSPF、BGP等全套协议，配置风格和Cisco高度相似但又有自己的特点。

安装FRR之后，编辑/etc/frr/daemons文件开启ripd，然后通过vtysh进入配置模式。配置逻辑和Cisco基本一致：

router rip version 2 network 192.168.12.0/24 network 192.168.23.0/24 no auto-summary

FRR的RIP配置和Cisco的区别在于network命令可以精确到子网掩码，不需要再按主类网络宣告，这是一个体验上的进步。用FRR做实验还有个额外好处：你可以直接把扩展性拉满，把FRR设备插入GNS3拓扑里，让Linux主机和Cisco路由器互通RIP。这样你就能亲手验证不同厂商实现之间的协议互通性，这在实际企业网络里非常重要。

我自己实测下来，Cisco IOS和FRR之间跑RIPv2完全兼容，没有任何版本或字段上的障碍。这个跨界实验做完，你对RIP协议的了解就不再局限于某一厂商，而是真正理解了协议本身。

6. 实验复盘与实操体会

做RIP协议实验，表面上看是学会了几条配置命令，但往深了看，它其实是在建立一套完整的数据面控制面思维。每次做这套实验，我都有一些新的体会，这里挑几个最值得说的记录一下。

第一点感受：RIP是理解所有距离矢量协议的基石。你学了RIP再看EIGRP，会发现EIGRP只是把跳数换成了复合度量，把周期更新换成了部分更新，但底层的距离矢量思想、防环意识完全一脉相承。再看BGP，BGP本质上是路径矢量协议，它通过传播AS路径来避免环路，思路和RIP的跳数限制异曲同工。把RIP吃透了，后面学其他协议都会顺很多。

第二点体会：RIP实验的每一步都可以用抓包验证，不要只停留在看路由表。第一次看到RIPv2报文里的metric字段随跳数递增时，我才真正理解了“距离矢量”这四个字的分量。同样，第一次看到毒性反转把metric置为16并回传给上游时，我才理解了RIP为什么要这样设计。

第三点经验：做实验要多留故障注入的时间。光把配置敲完看到路由表全通，这个实验对你的帮助有限。真正有价值的操作是模拟链路故障，观察RIP的收敛过程；是关闭水平分割，感受环路形成时那种一步一步逼近16跳的紧张感。这些实验做完，你才会有“我理解了RIP”的底气，而不是“我配过RIP”。

最后再分享一个小细节：做RIP实验时，建议边做边记录每个计时器节点的观察结果，把它整理成一张时间线。后来你会发现，这张时间线图就是你理解距离矢量路由协议收敛行为最直观的参考材料。比任何教科书上的文字描述都管用。