企业官网建设流程全解析

RIP（Routing Information Protocol，路由信息协议）大概是每个学网络的人最早接触的动态路由协议了。别看它在生产环境里已经被OSPF、ISIS按在地上摩擦，但RIP作为距离矢量路由协议的典型代表，恰恰是理解“路由协议到底在干什么”的最顺手切入点。我这次在GNS3里用三台路由器搭了一个三角形拓扑，把RIPv1/v2配置、非连续子网问题、防环机制、故障切换，以及那些只存在于教科书上的计时器全部过了一遍。整个实验做下来收获比想象中多，这篇文章把实验设计、每一步的配置命令和踩过的坑都整理出来了。正在做课程设计，或者准备网络认证实操，再或者只是想搞明白RIP细节的同学，可以照着这套方案搭一遍，也可以直接拿去当实验报告素材。

1. 实验目标与整体设计思路

1.1 为什么一定要动手做一次RIP实验

很多人觉得RIP又老又简单，学一遍就扔。但真到了实验课上，不少人连“network 10.0.0.0”为什么能把两个接口都宣告进去都说不清，更别提理解水平分割和毒性逆转的实际表现。RIP能教会你的不是配置本身，而是三个基础但极其重要的思维：

第一，距离矢量协议是“逐跳传递”的。每台路由器只告诉邻居“我这条路能到哪、花多少跳”，至于完整的网络地图，大家都没有。这个特性直接决定了RIP必然需要靠一堆防环机制来兜底，也正是理解路由环路成因的最好教材。第二，RIP的配置命令极其简单，门槛低，适合把精力集中在观察协议行为上，而不是耗在排错和调试复杂状态机上面。第三，RIP暴露出来的一些设计缺陷，比如收敛慢、跳数限制、有类路由问题，正好可以作为反面典型，让你明白OSPF和ISIS为什么要设计成链路状态协议。

1.2 拓扑方案选型：从链式改到三角形的理由

一开始我打算用最简单的三台路由器串成一条线，R1—R2—R3，这样配置最简单，跳数也一目了然。但很快发现这个拓扑能演示的实验太局限：没有冗余链路就看不到故障切换，没有等价路径就讲不清楚选路规则，水平分割的验证也不够直观。所以最后我把拓扑改成了三角形，三台路由器两两相连，把R1和R3之间也打通了。

改完之后的收益非常明显：R1到R3的loopback网段有两条路径，一条直连metric为1，一条经过R2 metric为2，RIP会稳定选metric最小的那条；当我手动断开直连链路时，又能现场观察路由表在几十秒内切换到备用路径的全过程。对实验教学来说，这个拓扑的性价比很高，只比链式拓扑多一台设备的一段链路，可玩性和可讲性却强了一个档次。

链式、三角形、全互联这三种拓扑我都简单对比过，可以给后来人一个参考：

1.3 地址规划与设备说明

地址规划采用“环回口模拟用户网段，物理接口模拟骨干链路”的经典做法。R1的Loopback0模拟左侧用户网络，R3的Loopback0模拟右侧服务器网络，中间用/30掩码的互联链路串起来，避免地址浪费。为了实验RIPv1的非连续子网问题，我特意把R1和R3的Loopback地址规划到了同一个主类网络172.16.0.0/16里面的不同子网，这一步在后面成了整个实验里最有戏剧性的部分。

具体规划如下：

这里把R1和R3的Loopback放在同一个主类网络的意图是：一旦跑RIPv1，R2收到的将是两条汇聚后的172.16.0.0/16，根本分不清172.16.1.0和172.16.2.0该怎么走；而RIPv2配合关闭自动汇总后，两条精确子网路由才能同时出现在路由表里。后面看到的“Ping不通”现象，全由这个规划引发。

2. 实验环境搭建与基础配置

2.1 模拟器选型：GNS3、Packet Tracer还是EVE-NG

实验环境我优先推荐GNS3。Packet Tracer虽然操作门槛最低、对新手最友好，但它对RIP的很多细节做了简化，比如部分版本不支持在debug输出里完整展示RIPv1和RIPv2的区别，也不容易观察到触发更新的实时行为，对课程实验来说勉强够用，但要深入玩就有点受限。EVE-NG的Web界面很现代，适合部署在服务器上长期跑，但对单机实验来说安装和网络配置反而成了多余的前置负担。

GNS3的优势在于它加载的是真正的Cisco IOS镜像，所有命令输出都是真实行为。实验中我用的是c3725镜像（支持RIP和基本的GigabitEthernet接口，对学习完全够用），内存给512MB就非常流畅了。如果你电脑性能一般，用c2600或c7200也一样能跑，区别只是接口名称和启动速度。另外要注意，GNS3里默认添加的交换机是普通Ethernet Switch，实验中我们没有用到VLAN，所以纯路由器互联不需要交换机，这点和Packet Tracer里必须加交换机的思路不太一样。

2.2 镜像加载与设备启动的注意事项

GNS3中添加路由器的步骤其实很简单：编辑首选项里的IOS路由器模板，选好镜像文件，设置好内存和插槽类型，然后拖到画布连线就行。但有一个细节容易被忽略：c3725默认没有GigabitEthernet口，需要在路由器模板里添加GT16ESW或其他支持千兆的板卡，否则你只能看到FastEthernet接口。这个差异不影响RIP实验本身，但会让配置命令里的接口名写对。

启动设备后第一件事不要急着配IP，先把控制台连上，用show ip interface brief确认每个接口的编号和状态。由于GNS3里路由器默认所有接口都是shutdown状态，物理链路正常不代表接口可用，必须显式执行no shutdown。我在第一次搭建时漏掉了R1的G0/1，导致R1和R3之间的直连路由迟迟不出现，排查了半天才发现是接口没起来。这是一个非常典型的新手错误，后来我把每个接口的no shutdown都写进配置脚本，再也没出过这类问题。

2.3 三台路由器的接口地址配置

先做基础地址配置。三台路由器的配置大同小异，R1的配置如下：

enable configure terminal hostname R1 ! interface Loopback0 ip address 172.16.1.1 255.255.255.0 ! interface GigabitEthernet0/0 ip address 10.0.12.1 255.255.255.252 no shutdown ! interface GigabitEthernet0/1 ip address 10.0.13.1 255.255.255.252 no shutdown

R2的配置只需要配置两个物理接口，不放Loopback，因为它在实验里纯粹扮演中间转发角色。R3的配置和R1对称，Loopback0用172.16.2.1，物理接口分别是G0/0（10.0.23.3）和G0/1（10.0.13.3）。全部配置完成后，依次测试一下直连链路的连通性。

R1# ping 10.0.12.2 R1# ping 10.0.13.3 R2# ping 10.0.23.3

这三个ping全部返回成功之后，网络底层就算打通了。此时在R1上ping 172.16.2.1必然是不通的，因为R1的路由表里根本没有172.16.2.0/24，这正是接下来要交给动态路由协议解决的问题。搞清楚“在配置RIP前，路由表里只有直连路由”这个基线状态非常关键，因为后面所有RIP生效后的变化都是相对这个基线来观察的。

3. RIP路由协议配置：从RIPv2开始

3.1 RIPv2核心配置：network命令到底在干什么

我建议先做RIPv2，因为RIPv2携带子网掩码、支持VLSM和无类路由，行为更符合直觉，等整体流程跑通了再回头对比RIPv1才有冲击力。三台路由器上的RIP配置如下。

R1上的配置：

configure terminal router rip version 2 no auto-summary network 172.16.0.0 network 10.0.0.0

R2上的配置：

configure terminal router rip version 2 no auto-summary network 10.0.0.0

R3上的配置：

configure terminal router rip version 2 no auto-summary network 172.16.0.0 network 10.0.0.0

很多初学者不理解network命令后面为什么要写主类网络地址，而不是直接写接口IP。这里要讲清楚一个关键机制：network后面跟的是一个“范围声明”，它告诉RIP进程“哪些接口所在的网络要参与RIP通告”，而不是“要通告哪条具体路由”。比如network 10.0.0.0会把所有IP地址以10开头的接口都选中，R1的G0/0和G0/1正好都属于10.0.0.0主类，所以都被RIP接管。network 172.16.0.0则选中Loopback0。

RIPv2默认开启自动汇总，会把172.16.1.0/24和172.16.2.0/24都汇聚成172.16.0.0/16来通告。我们在实验中要演示VLSM和非连续子网，必须用no auto-summary关闭它，让每条子网路由以精确掩码的形式出现在更新里。这个命令在真实网络中也是常态，因为现代网络几乎都用无类路由。

配置完成后，R1上看到的RIP路由应该如下：

R1# show ip route rip 172.16.0.0/24 is subnetted, 1 subnets R 172.16.2.0/24 [120/1] via 10.0.13.3, 00:00:02, GigabitEthernet0/1

注意R1学到的172.16.2.0/24只走了直连R3这一条路径，metric为1，因为RIP选路是纯粹的跳数优先，直连路径最矮。与此同时R1其实也能从R2那边听到metric为2的相同路由，但最优路由已经占了位置，备份就不会出现在路由表中。等后面链路断开时，这条备份才会浮上来。

3.2 那些决定命运的计时器

RIP的计时器是理解它“收敛慢”的钥匙。Cisco IOS里的RIP沿用了RFC 1058定义的基本参数但还是做了一些默认调整，标准四个计时器分别是更新计时器（Update）、失效计时器（Invalid）、抑制计时器（Holddown）和刷新计时器（Flush）。

用show ip protocols可以直接看到这些参数：

R1# show ip protocols Routing Protocol is "rip" Sending updates every 30 seconds, next due in 18 seconds Invalid after 180 seconds, hold down 180, flushed after 240 ...

实验里观察30秒更新特别有意思。在R1上执行debug ip rip，等30秒左右，就能看到R1组播发送更新到224.0.0.9，同时从邻居收到更新。RIPv2使用组播而不是广播（RIPv1用255.255.255.255广播），这是一个容易考到的知识点，在debug输出里也能明确看到224.0.0.9这个地址。观察完记得用undebug all关掉debug，否则控制台会一直被刷屏。

3.3 show ip route与debug ip rip的正确打开方式

验证RIP实验，最常用的是三条命令：show ip route、show ip route rip、show ip protocols。第一条看全局路由表，第二条只看RIP学到的动态路由，第三条看协议参数。这里分享一个习惯：怀疑RIP问题时不建议直接看整张路由表，先用show ip route rip过滤，能少看一大片无关信息。

路由表里那条[120/1]的解读方式非常固定：120是RIP的管理距离，1是metric跳数。管理距离用来决定“如果多个协议学到了同一条路由，谁说了算”，RIP的120比直连路由的0大，所以直连永远优先；它又比OSPF的110大，意味着同一网络里如果OSPF和RIP同时存在，OSPF路由会胜出。搞懂这个数字的意义，后面做路由重分布时才不会懵。

debug ip rip是所有RIP实验中信息量最大的命令，它的输出能直接看到更新内容：

R1# debug ip rip RIP: sending v2 update to 224.0.0.9 via GigabitEthernet0/1 (10.0.13.1) RIP: build update entries 172.16.1.0/24 via 0.0.0.0, metric 1, tag 0 RIP: received v2 update from 10.0.13.3 on GigabitEthernet0/1 172.16.2.0/24 via 0.0.0.0 in 1 hops

注意“in 1 hops”指的是从R3到目标网段是1跳，R1本地学到的路由metric就是1+1=2吗？并不是，这里要细心：debug输出显示的是“接收到更新里标注的跳数”，R1根据这条更新生成路由时，会把接收接口的cost叠加进去。但Cisco RIP默认接口cost为0，所以实际metric保持1。如果加入metric offset相关配置，这里就会体现差异。输出里tag 0是路由标签，RIPv2支持给路由打tag，后续做策略路由时有用。

4. RIPv1与RIPv2对比：非连续子网的经典翻车现场

4.1 复现非连续子网问题

基础RIPv2跑通之后，终于可以进入我觉得最有教学价值的环节：非连续子网问题。所谓非连续子网，指同一个主类网络的两个子网被另一个主类网络分隔开。在我们的拓扑里，172.16.1.0/24挂在R1上，172.16.2.0/24挂在R3上，中间的骨干链路全是10.0.0.0/30网段，这正好构成了典型的非连续子网结构。

把三台路由器的RIP版本改成1：

router rip version 1

然后观察R2的路由表：

R2# show ip route rip R 172.16.0.0/16 [120/1] via 10.0.12.1, 00:00:14, GigabitEthernet0/0

只能看到一条172.16.0.0/16，而且下一跳指向R1。问题来了：R2明明同时从R1和R3两个方向收到了关于172.16.0.0/16的通告，为什么路由表里只保留了一个下一跳？

原因是RIPv1是有类路由协议，它在通告路由时，如果目标网段和发送接口不属于同一个主类网络，会自动把路由汇总到主类边界。R2从R1方向收到的172.16.1.0/24变成了172.16.0.0/16，从R3方向收到的172.16.2.0/24也变成了172.16.0.0/16。两条更新的目标网络完全一样，前缀完全一样，metric也一样，RIP认为它们是等价的，就选了先收到的或负载均衡，而路由表只显示一条。无论选哪个下一跳，都必然导致部分流量走向错误的方向。

此时从R1去ping R3的Loopback：

R1# ping 172.16.2.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.2.1, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)

丢包100%。R1的路由表里只有一条172.16.0.0/16，指向R2；R2的172.16.0.0/16也指向R1，数据包在R1和R2之间打转，形成典型的路由环路和黑洞。这就是教科书上说的“计数到无穷”的现实雏形——虽然这里还没到无限跳数，但已经因为路由信息丢失而彻底丧失了方向判断能力。

4.2 从RIPv1切换到RIPv2

修复方法很简单，把三台路由器的RIP版本全部改回2并取消自动汇总：

router rip version 2 no auto-summary

此时R2的路由表会同时出现两条精确子网：

R2# show ip route rip 172.16.0.0/24 is subnetted, 2 subnets R 172.16.1.0/24 [120/1] via 10.0.12.1, 00:00:01, GigabitEthernet0/0 R 172.16.2.0/24 [120/1] via 10.0.23.3, 00:00:01, GigabitEthernet0/1

R1上的ping立刻恢复：

R1# ping 172.16.2.1 Success rate is 100 percent (5/5)

从“全丢”到“全通”只隔了一个version 2加no auto-summary。这个对比画面感极强，建议在实验报告里把切换前后的show ip route rip输出贴在一起，比任何文字都直观。

4.3 实验结论：有类路由和无类路由的本质区别

这个实验让我彻底理解了“有类”和“无类”到底差在哪：RIPv1根本不携带子网掩码信息，接收方只能按照地址类别猜掩码；RIPv2在更新条目里携带了完整的子网掩码，接收方无需猜测就能精确还原目标网络。再加上RIPv1在主类边界上的强制汇总行为，非连续子网在RIPv1下必然出错，因为它丢失了“中间隔着另一个主类网络”这个关键上下文。

顺带说一句，RIPv1还有一个隐蔽的问题是对VLSM的不支持。同样是非连续子网的实验，如果把R1的Loopback改成172.16.1.1/25，RIPv2能精确传递172.16.1.0/25，而RIPv1只能把它当成172.16.1.0/24来处理，掩码信息直接丢失。日常做题时也经常会出这个考点：RIPv1为什么不能支持变长子网掩码？答案就在它更新报文的结构里，根本没有掩码字段。

5. 防环机制与稳定性实验

5.1 水平分割：同一个接口学到的路由不回同一接口

距离矢量协议天生容易产生路由环路，RIP靠四个机制来兜底。第一个是水平分割，也是最容易在实验里观察到的。它的原则简单说就是：从哪个接口学到的路由，绝对不从这个接口再通告回去。

验证方法非常直接。在R1上开启debug：

R1# debug ip rip

观察R1通过G0/0（连接R2的接口）发送的更新内容。正常情况下，更新里只包含R1自己的直连路由或从其他接口学到的路由，绝不会有从G0/1学到的172.16.2.0/24。如果我把G0/1接口上的水平分割关掉：

R1# configure terminal R1(config)# interface GigabitEthernet0/1 R1(config-if)# no ip split-horizon

再观察debug输出，就能看到R1开始通过G0/1把172.16.2.0/24通告回R3，等于把R3告诉自己的路由原封不动地还回去。这种“回音”是环路形成的前奏。实验结束后记得把水平分割恢复默认，用ip split-horizon重新开启。注意Cisco IOS里物理接口默认是开启水平分割的，但帧中继等NBMA接口有时需要手动确认，这是老网络工程师都懂的坑。

5.2 触发更新与毒性逆转：链路故障时的急救动作

第二个和第三个机制分别是触发更新和毒性逆转。它们的应用场景是链路突然断开。

我在R2的G0/1接口上执行shutdown，模拟R2到R3的链路中断。正常情况下，R2要等30秒周期更新才能把坏消息传出去，但RIP会在检测到接口状态变化后立刻发送触发更新。此时在R2上执行debug，可以看到：

R2# debug ip rip RIP: sending v2 update to 224.0.0.9 via GigabitEthernet0/0 (10.0.12.1) RIP: build update entries 172.16.2.0/24 via 0.0.0.0, metric 16, tag 0

注意metric变成了16。这就是毒性逆转的口语化表达：不可达路由以metric 16通告出去，邻居收到后立刻知道这条路径断了，而不是继续傻乎乎地等180秒失效计时器。16在RIP里是个特殊数字，代表“无穷大”，也就是不可达。

这里有个细节值得说明：链路故障的检测依赖的是接口down事件，所以触发更新几乎是立即发生的。如果是链路物理正常但对端设备宕机，就要靠180秒的Invalid计时器来兜底，那体验就完全不一样了，后文故障切换实验会看到这个差异。RIP最遭人诟病的“慢收敛”，根源就在这些计时器上。

5.3 最大跳数与计数到无穷的理论极限

RIP把metric限制在0到15的范围内，16就是不可达。这意味着一个网络直径超过15跳的拓扑就无法使用RIP，这也是它在大型网络中彻底出局的原因。为什么非要设个15的上限？因为距离矢量协议一旦出现环路，R1告诉R2“我能在1跳内到达X”，R2告诉R1“我能从你那里1跳到达X”，两个路由器互相递增跳数，理论上会一直加到无穷大。如果不设上限，这条路就永远不会“死”，数据包会在环里跑到TTL耗尽。

设了16这个上限后，路由更新里的metric一旦到达16，所有收到该更新的路由器都会立刻把这条路由标记为不可达并触发更新，环路被强制打断。这个机制在实验里其实很难用实物完整复刻，因为拓扑规模不允许，但它解释了为什么RIP的“跳数天花板上限”和“防环机制”是一体两面的设计。

实际操作中如果你想制造一个metric 16的路由，不用真的去搭16台路由器，直接在配置里用offset-list或者重分布一个不可达路由就能做到，但更推荐的做法是像上面那样直接shutdown一个接口，让协议自己产生不可达更新，这样看到的现象最真实。

6. 故障切换与收敛时间观测

6.1 人为故障：断开R1-R3链路

基础实验跑通后，我把R1和R3之间的直连链路做成故障点，模拟网络拓扑发生变化。此时R1到172.16.2.0/24的最优路径是直连R3，metric为1。在R1上执行：

R1# configure terminal R1(config)# interface GigabitEthernet0/1 R1(config-if)# shutdown

链路down掉后，R1立刻失去了直连方向上的172.16.2.0/24路由，因为这条路由的更新源接口失效了。但R1还有一条从R2学来的metric 2备份路由，此时是否立刻生效，取决于RIP的抑制计时器（Holddown）。

这里出现了本实验最值得观察的现象：R1什么时候才把下一跳从10.0.13.3切换到10.0.12.2？答案不是立刻。因为R1刚进入抑制期，对172.16.2.0/24暂时不接受任何新路由，必须等Holddown计时器走完，或者等到那条路由被彻底Flush后重新学习。所以在断链后的前180秒里，R1的路由表里可能完全看不到172.16.2.0/24。这正是RIP收敛慢的最直观体现。

为了加速观察，我把三台路由器的计时器临时调小：

router rip timers basic 5 30 30 40

这行命令把更新计时器改为5秒，失效30秒，抑制30秒，刷新40秒。实验环境下这样调非常方便，能在一个合理的时间窗口内完整走完“断链→触发更新→进入抑制→恢复路由”的全过程。真实生产网络当然不建议乱改计时器，但做实验时它是个好工具。

6.2 备用路径切换的全过程

调小计时器后重新做故障切换，整个流程大约这样：

在t=0时断链，R2立刻通过触发更新把“172.16.2.0/24不可达”的消息传给R1，同时也把从R3方向学到的路由信息做重新计算。但因为R2到R3的链路还通着，R2其实依然能从R3正常学习到172.16.2.0/24，所以R2的更新里那条metric 16只是针对自己原来连接R3的接口，不影响它从R3学到的同网络路由的正确性。这里我建议用show ip route配合show logging来跟踪路由表变化的时间线。

最终的稳定状态是：

R1# show ip route 172.16.2.0 Routing entry for 172.16.2.0/24 Known via "rip", distance 120, metric 2 Last update from 10.0.12.2 on GigabitEthernet0/0, 00:00:01 ago Routing Descriptor Blocks: * 10.0.12.2, from 10.0.12.2, on GigabitEthernet0/0 Route metric is 2, traffic share count is 1

R1到172.16.2.0/24的下一跳变成了10.0.12.2，metric从1涨到2。这个切换在调整计时器的情况下，大约几十秒内完成；如果保持默认30秒更新，整个过程会超过3分钟。RIP的这个特性放到今天的生产网络里是不可接受的，但理解它的形成过程，反而能让你对OSPF秒级收敛的实现有多牛产生更具体的认知。

6.3 RIP收敛慢的根源与调优实验

把RIP收敛慢的根源拆开看，主要有三个：第一，周期性更新最快要30秒一轮，消息传递天然滞后；第二，Holddown计时器强制路由器在180秒内不接受可能不稳定的新路由，这是为了防止环路，但也拖慢了有效路径的启用；第三，距离矢量本身缺乏全局拓扑视图，每条路由的可靠性完全依赖邻居的转述，无法主动判断哪条备选路径更可靠。

调优实验里我试过timers basic 5 30 30 40，收敛时间确实可以压到30秒以内，但随之而来的是更新报文数量暴增，每5秒钟三台路由器就要互相发一轮完整路由表。在三角形拓扑里还好，如果换成几十台路由器的大型网络，这点开销会被迅速放大。所以这里的结论不是“RIP可以调快”，而是“RIP的设计决定了它只适合小型网络”。做实验记录时，建议把默认计时器和调优计时器的两组收敛时间同时记录下来，然后用OSPF的秒级收敛做对比。

7. 常见问题排查与避坑指南

7.1 高频故障速查表

整个实验做下来会遇到不少坑，我把它们按“现象→原因→解决”的方式整理成了一张速查表，希望对你有用：

加一个容易忽略的点：RIP管理距离是120，如果网络里同时存在静态路由指向同一个目标网段，静态路由的管理距离为1，会覆盖RIP路由。这种“明明配置了RIP却不走RIP”的情况，第一反应要查静态路由和直连路由是否冲突。

7.2 几条实操心得

• 做实验前一定先把接口地址配好、ping通，再动路由协议。很多RIP排错最后都变成底层连通性排错，先解决底层问题能省大量时间。

• 所有改动之前先截一张show ip route和show ip protocols的截图或保存文本，回滚时心里有数。GNS3里还可以直接保存设备配置，reset之前先备份是硬习惯。

• 观察协议行为优先用debug ip rip，但别让多台路由器同时开debug，控制台日志会互相淹没。建议一次只在一台路由器上开，看完立刻undebug all。

• 调计时器只做实验用。timers basic调完之后记得在最终配置里恢复默认值，否则你记录下来的收敛时间不具备参考意义。

• 最后清理配置时要注意，GNS3的配置保存不算完整的wr，记得copy running-config startup-config，而且关闭GNS3项目时选择保存，否则下次打开拓扑还是空配置。

写在最后

做完这一整套RIP实验，最大的感受是：纸上谈兵再多，都不如亲眼看到路由表里那条metric在几秒钟内从1变成2、debug输出里出现一行metric 16来得深刻。RIP虽然已经是老古董，但它把“距离矢量协议是怎么想的”“环路的本质是什么”“为什么现代协议要用链路状态思想”这些问题都摆在桌面上，让你练手的同时搞懂了计算机网络里最微妙的那部分逻辑。

如果你接下来要学OSPF，建议保留这套拓扑，把router rip换成router ospf，用同样方式再看一遍路由表的形成和故障切换，你会发现两类协议的思维差异一下子就能对比出来。需要实验脚本或者想讨论某个输出细节的，欢迎留言。