第一次做这个课设的时候，我在一根串口线前面耗了四十分钟。两边接口都是 up，IP 地址核对了三遍，ping过去就是不通，最后发现是两侧的 PPP 认证方式一边写了 PAP、一边写了 CHAP。那之后我才明白，这类实验真正考的不是背命令，而是能不能看懂"链路层协商"和"网络层寻址"这两件事各自负责什么、在哪一层断掉该去哪里查。

这篇内容把我把IP 地址配置、PPP 协议配置、静态路由配置、RIP 动态路由配置这四个任务串起来做的完整过程整理出来，包含拓扑规划、命令配置、验证方法和踩坑记录。适合正在做网络方向课设、刚开始接触设备命令行的同学，也适合已经能敲命令但对"为什么这么敲"没底的朋友。全程用常见的网络设备命令行语法演示，你在模拟器或者真机上都能对应上。

1. 拓扑与地址规划：动手敲命令之前的半小时

1.1 为什么地址规划比配置本身更值得花时间

我见过太多人打开模拟器就开始拖设备、连网线、敲 IP，半小时后陷入"到处能 ping 通一半"的混乱局面。根源在于没有一张纸上的规划。地址规划的意义不在于"美观"，而在于它提前排除了两类最常见的错误：同一网段内地址重复，以及路由聚合后互相覆盖。

具体来说，动手前至少要在纸上（或者笔记软件里）写清楚三件事：每个网段用哪个地址块、每个设备的每个接口落在哪个网段、每个网段的地址用途是什么（互联链路、用户接入、环回测试）。第三点最容易被跳过，但它直接决定了后面写静态路由和 RIP 的network语句时会不会漏。我个人的习惯是画一个小表格，左列是网段，中间是掩码和可用地址范围，右列是这条链路两端的接口名。表格填完，拓扑的正确性基本就锁死了七成。

课设场景一般三到五台路由器就够了。我用下面这个结构演示，后面所有命令都基于它：

1.2 互联链路为什么清一色用 /30

新手最常问的一个问题是：两台路由器之间就一根线，为什么要浪费一个 /24 甚至一个 /16？答案很直接——互联链路只需要两个可用地址，/30 的 255.255.255.252 正好提供两个主机位地址，一个给这端、一个给那端，不多不少。用 /24 不会立刻出错，但会给后面挖坑：第一，RIP 和静态路由的路由表里会多出一堆无意义的明细条目，display ip routing-table一屏翻不完；第二，某天你要往这条链路上挂第三台设备做旁路测试，地址冲突的排查成本会陡增。

这里的计算其实很简单。一个 /30 的子网掩码是 255.255.255.252，主机位只有 2 位，2²-2=2 个可用地址，网络号是 4 的倍数。所以 10.1.1.0/30 可用地址就是 10.1.1.1 和 10.1.1.2，广播地址 10.1.1.3。下一条链路就从 10.1.1.4 开始，写成 10.1.2.0/30 更不容易看错。我建议串行链路直接用第二段做区分，比全挤在 10.1.1.0/24 里切 /30 要直观得多。

提示：如果你用的模拟器版本较老，Serial 接口的编号规则可能是Serial 0/0/0这种三位格式，而新版本是Serial 1/0/0。敲命令前先display interface brief看一眼实际存在的接口名，别凭记忆写。

1.3 设备命名和接口描述：一个几乎零成本的好习惯

这件事我一开始也嫌麻烦，后来在做四台以上设备的拓扑时彻底改观了。sysname R1这种命名会让命令行提示符从<HUAWEI>变成[R1]，一眼就知道自己在哪台设备上操作。模拟器里所有设备默认名是一样的，多开几个窗口之后，你真的会分不清哪个是哪个，然后就在 R2 上配了 R3 的地址。

接口描述是另一个被低估的细节。description to-R2-Serial1/0/0这样一行字，写的时候只花两秒，排错的时候能省你十分钟。它的价值在于把"接口名"这个纯技术标识，翻译成"这条线通向哪里"的业务语义。等你display interface brief看到一屏 up 的接口时，描述列是唯一能告诉你哪条线接哪里的信息。

配置方式很朴素：

[R1] interface Serial 1/0/0 [R1-Serial1/0/0] description to-R2-via-PPP [R1-Serial1/0/0] quit

做完上面这三件事，基础就稳了。有人会问，地址规划能不能靠 DHCP 或者自动配置省掉？在这类课设里不行，因为静态路由和 RIP 都要依赖你确切知道每个网段是什么，自动分配反而会引入不确定性。规划是"人"的工作，配置才是"设备"的工作。

2. IP 地址配置：从接口地址到真正能通

2.1 两个状态位决定一切

接口配上地址之后，display ip interface brief会显示两列状态：Physical 和 Protocol。这一条命令是整个网络排错的起点，我认为它比ping更重要，因为它告诉你的是"链路本身活了没有"，而 ping 只能告诉你"端到端通不通"，后者不通的时候你根本不知道断在哪一层。

Physical 状态反映物理层，指的是接口有没有检测到载波信号，串行线缆没插好、对端接口被shutdown了，这一列就是 Down。Protocol 状态反映数据链路层，指的是链路层协议有没有协商成功。PPP 场景下，这条线最容易出现"Physical up、Protocol down"，说明物理连接是好的，但 LCP 协商失败了——认证方式不匹配、认证失败、或者一端是 PPP 另一端是 HDLC，都会造成这个现象。

这两种状态的组合其实已经给出了排查方向：

记住这张表，后面所有排错都能省掉一半时间。

2.2 路由器、交换机、主机三者的配置路径不一样

路由器配置接口地址是最直接的：

<R1> system-view [R1] sysname R1 [R1] interface GigabitEthernet 0/0/0 [R1-GigabitEthernet0/0/0] ip address 192.168.10.1 255.255.255.0 [R1-GigabitEthernet0/0/0] undo shutdown [R1-GigabitEthernet0/0/0] quit

注意后面两句的顺序：先配地址再undo shutdown，或者反过来都行，但一定不能只配地址就不管shutdown状态。有些设备接口默认是开启的，有些不是，模拟器里尤其容易出现配置完了发现 Physical 一直 down，其实只是接口没打开。

交换机不能直接在物理接口上配 IP（三层交换机除外），这个坑我第一次做的时候就踩了。二层交换机要管理地址，得建一个 VLAN 接口：

<SW1> system-view [SW1] vlan 10 [SW1-vlan10] quit [SW1] interface Vlanif 10 [SW1-Vlanif10] ip address 192.168.10.254 255.255.255.0 [SW1-Vlanif10] quit

而且这个 VLANIF 要 up，必须至少有一个属于 VLAN 10 的物理端口处于 up 状态，否则 VLANIF 的 Protocol 会一直是 down。这是二层交换机管理地址配不通的头号原因，很多人配完发现 ping 不通交换机的管理地址，查了半天地址，其实问题在没有活动端口。

主机的地址配置反而最容易被想复杂。在模拟器里给 PC 配 IP、掩码、网关三步走，网关填的是同网段的路由器接口地址，不是远端网段地址。这个"网关必须是同网段"的常识，在紧张赶工的时候反而经常写错。

2.3 掩码写错之后，症状千奇百怪

掩码错误是这个实验里最高频的低级错误，但它的症状非常有欺骗性，因为有时候它居然能"通"。举个真实例子：R1 的 GE0/0/0 配成 192.168.10.1/24，PC 的网关配成 192.168.10.1，PC 自己的地址配成 192.168.10.100/25。这时候 PC 设 192.168.10.1 网关能用，因为 192.168.10.1 在它的 /25 范围内，但如果你把 PC 地址改成 192.168.10.200/25，它就会认为网关 192.168.10.1 不在自己网段（它的网段是 192.168.10.128/25），于是往网关发 ARP 的时候就出问题了。

所以判断掩码配置是否正确，最可靠的方法是对比两端。在 R1 上display ip interface brief确认接口掩码，在 PC 上看配置，再在 PC 上ping 192.168.10.1验证。如果 ping 网关不通而接口状态正常，那十有八九是掩码或网段的问题。还有一个小技巧：在 PC 上查看 ARP 表，如果网关条目一直是"未解析"的状态，说明 ARP 请求根本没到网关，问题就在二层可达性或者地址规划。

另外提醒一句，/24 和 /32 是两个极端。/24 用于普通网段，/32 通常只用在环回口上——环回口配 /32 是个好习惯，它保证了这个地址不会被误认为属于某个更大的网段，同时作为设备标识使用最稳定。interface LoopBack 0加ip address 1.1.1.1 32，两行搞定，后面做 RIP 和静态路由的时候，用它当测试目标是标准做法。

3. PPP 协议：真正需要盯的是协商过程

3.1 LCP 和 NCP 分别在谈什么

PPP 的全称是点对点协议，但真正理解它要抓住一件事：PPP 不是"一层"，而是由若干个协议组成的栈。上面跑的 IP 包需要被封装，封装前要先建链路，建链路前要协商参数，这些工作被拆给了 LCP 和 NCP 两大部分。

LCP（链路控制协议）负责的是"我们这个链路怎么建立"——最大接收单元多大、要不要认证、用什么认证方式、什么时候拆链。NCP（网络控制协议）是一组协议的总称，对 IP 而言就是 IPCP，它负责的是"链路建好之后，IP 地址这些网络层参数怎么协商"。

这个分层结构解释了很多现象。比如你在串口上把链路层封装换成 PPP，display interface Serial 1/0/0会看到 LCP 的 open 状态；如果认证配错了，LCP 就会在 negotiation 阶段卡住或者关闭，Protocol 状态跟着变 down。所以看到"Physical up / Protocol down"，第一反应就是去看 LCP 协商到哪一步了，而不是去查 IP 地址。

3.2 两侧参数必须一致的那几项

PPP 配置最核心的原则是：结果要一致，配法可以不同。具体说，至少有四项是必须两端对齐的：

第一项是封装协议。两端都得是link-protocol ppp，一端 PPP 一端 HDLC，LCP 根本无法开始协商。第二项是认证方式，一端 CHAP 一端 PAP 也不行，因为认证方式是在 LCP 协商阶段就定下来的。第三项是认证的凭据内容，用户名和密码必须匹配。第四项是 MTU 和 MRU，这一项一般来说默认值就一致，但只要有人改过其中一端，就会出现"小包通大包不通"的诡异现象，这个坑很值得警惕。

我来演示一套标准的 CHAP 单向认证配置。假设 R1 是认证方，R2 是被认证方。R2 上要先建本地用户：

<R2> system-view [R2] aaa [R2-aaa] local-user r1-account password cipher Lab@12345 [R2-aaa] local-user r1-account service-type ppp [R2-aaa] quit [R2] interface Serial 1/0/0 [R2-Serial1/0/0] link-protocol ppp [R2-Serial1/0/0] ip address 10.1.1.2 255.255.255.252 [R2-Serial1/0/0] ppp authentication-mode chap [R2-Serial1/0/0] quit

然后在 R1 上把用户名密码告诉它，让它在被要求认证时能应答：

<R1> system-view [R1] interface Serial 1/0/0 [R1-Serial1/0/0] link-protocol ppp [R1-Serial1/0/0] ip address 10.1.1.1 255.255.255.252 [R1-Serial1/0/0] ppp chap user r1-account [R1-Serial1/0/0] ppp chap password cipher Lab@12345 [R1-Serial1/0/0] quit

这里有一个特别容易搞错的地方：ppp chap user后面跟的用户名，是对端设备上创建的本地用户名，不是本设备的名字。因为 CHAP 是三报文握手，认证方发一个随机数和自己的名字，被认证方用收到的随机数加上密码算一个哈希值回过去，同时带上自己的用户名，认证方拿这个用户名去本地 AAA 里查密码再算一遍做比对。所以 R1 发出去的用户名必须能在 R2 的本地用户表里找到。我第一次配的时候想当然填了自己的设备名，结果认证一直失败。

3.3 认证失败的完整排查链路

认证失败的报错信息很少，基本就是display interface Serial 1/0/0看到 LCP 状态异常，或者日志里一行 "PPP authentication failed"。信息少不代表难查，关键是按顺序走。

第一步，确认两端认证方式是否一致。R1 写ppp authentication-mode chap，R2 也必须是 chap，如果 R1 是 chap 而 R2 根本没配ppp authentication-mode，那 R1 就会认为对端不支持认证，协商直接谈崩。

第二步，确认用户名在不在对端本地用户表里。在认证方执行display local-user，看有没有对端发来的那个用户名。注意这里查的是认证方的表，不是被认证方的表。

第三步，确认密码是否一致。这个最难查，因为密码在配置里是密文显示的，display current-configuration看到的是cipher %^%#...一串乱码，肉眼比对不了。最可靠的办法是在两端都重新local-user xxx password cipher 新密码覆盖一遍，用同一串明文。我吃过一次亏，一个字符大小写不一致，折腾了很久。

第四步，检查ppp chap user有没有配。很多人在被认证方只配了密码没配用户名，或者反了。用户名和密码这一对是必须同时存在的。

第五步，如果以上都对了还不通，去看 MAC 或者接口速率/双工。串行链路一般没有这个问题，但如果你做的是以太网口上的 PPPoE 或者用了转换器，速率不匹配会造成间歇性认证失败。

注意：PAP 是明文传输密码的两次握手，CHAP 是三次握手并且密码不直接上线。课设里两种都要求会配，但实际工程里能用 CHAP 就不要用 PAP。PAP 的配置差别在于被认证方用ppp pap local-user 用户名 password cipher 密码，而认证方仍然在 AAA 里建本地用户。

3.4 IP 地址协商这个容易被跳过的点

PPP 的 IPCP 支持地址协商，一端可以配置ppp ipcp remote-address或者干脆让对端用ip address ppp-negotiate从对端获取地址。课设通常不要求，所以我建议两边都配静态 IP 地址，简单可控。

但是这里有个细节值得知道：如果你在接口上写了ip address ppp-negotiate，那么无论你再写什么固定地址，最终生效的都是协商来的那个。有人在接口上同时配了两条，然后display ip interface brief看到的地址和自己预期的不一样，查了半天以为自己敲错了。所以配之前先想清楚用哪种方式，别混着来。

验证 PPP 链路是否真正可用，我通常做三件事：display interface Serial 1/0/0看 LCP 和 IPCP 状态，ping对端的接口地址，最后ping对端的环回口地址。第二项验证直连链路，第三项验证路由是否已经就位。三步都过，这条链路可以认为彻底通了。

4. 静态路由：手工指路背后的判断逻辑

4.1 路由表里那几种条目的优先级

在写第一条ip route-static之前，必须先理解路由表是怎么选路的。设备会维护一张路由表，每条表项包含目的网段、掩码、下一跳/出接口、优先级（preference）和开销（cost）。选路时先比掩码长度，最长匹配优先；掩码相同再比优先级，数值小的优先；优先级相同再比开销。

这个规则解释了为什么直连路由永远最优先。直连网段的路由是接口配置 IP 之后自动生成的，优先级是 0，而静态路由默认优先级是 60，RIP 默认是 100。所以只要接口上有地址且状态是 up，同一个网段你就别想用静态路由去覆盖它。

理解了这个顺序，配静态路由的时候就不会犯"为什么我配了默认路由但不生效"这类错误。常见原因是：第一，下一跳不可达；第二，目的网段其实有更精确的明细路由；第三，设备上压根没开路由功能（三层交换机要ip routing，某些型号还要注意）。第三种在三层交换机场合特别常见，配了一堆路由发现display ip routing-table里根本没有，最后发现是没开全局路由。

4.2 下一跳写 IP 还是写出接口

静态路由有两种写法，指定下一跳 IP，或者指定出接口。这两种写法的适用场景完全不同，值得说清楚。

指定下一跳 IP 的写法是标准做法：

[R1] ip route-static 192.168.30.0 255.255.255.0 10.1.1.2

好处是明确，设备知道把包交给谁，会为了这个下一跳去查一次路由，适合多点接入的以太网环境。缺点是在点对点链路上多做了一次递归查找，而且如果下一跳地址本身不可达，这条路由就不会生效。

指定出接口的写法是：

[R1] ip route-static 192.168.30.0 255.255.255.0 Serial 1/0/0

在点对点链路上这种写法更高效，因为串行链路上只有一个对端，直接把包丢出接口就行了，不需要再查一次。问题在于，如果链路类型不是点对点（比如以太网），写出接口就会导致设备不知道目的 MAC 应该填谁的，它只能尝试广播或者丢弃。

我的习惯是：串行链路和隧道接口用出接口写法，以太网链路一律用下一跳 IP 写法。两种都写其实也支持，ip route-static 目的 掩码 出接口 下一跳，在某些场景下这样写更稳，但没必要为难自己。

4.3 默认路由与浮动静态路由

默认路由是 0.0.0.0/0，本质上是"所有其他网段都往这里走"。在 R1 上，如果没有别的路由能匹配，就走默认路由：

[R1] ip route-static 0.0.0.0 0.0.0.0 10.1.1.2

它的好处是省事，坏处是掩盖问题。默认路由配上之后，ping一个不存在的地址可能不会立刻报"网络不可达"，而是等超时，因为数据包被扔出去了但没人回。排错的时候，默认路由的存在会让"目标不可达"的判断变得模糊。

浮动静态路由是我认为这个实验里最值得学的技巧。它的原理很简单：给备份路径的静态路由配一个更大的优先级数值（数值越大优先级越低），主路径失效时，备份路径会自动顶上。具体写法：

[R1] ip route-static 192.168.30.0 255.255.255.0 10.1.1.2 preference 60 [R1] ip route-static 192.168.30.0 255.255.255.0 10.1.2.2 preference 100

前一条优先级 60（默认值），后一条 100。正常情况下只有前一条进路由表，display ip routing-table找不到后一条。当你把主链路接口shutdown掉，等待几秒再看，第二条就会顶上来。这个"看不到"到"看得到"的切换过程，是理解路由优先级最直观的方式。

验证的命令是display ip routing-table，配合display ip routing-table 192.168.30.0查看具体条目。另外display ip routing-table protocol static只看静态路由，在路由条目多的时候很好用。

4.4 路由环路长什么样

静态路由配错方向很容易造成环路。典型场景是两台路由器互相把对方当成去往某个网段的下一跳：

# R2 上 [R2] ip route-static 192.168.10.0 255.255.255.0 10.1.1.1 # R1 上（错误示范） [R1] ip route-static 192.168.10.0 255.255.255.0 10.1.1.2

R1 明明自己就直连着 192.168.10.0/24，却又配了一条指向 R2 的静态路由。因为直连路由优先级是 0，静态是 60，这条错误配置在正常情况下不会生效，属于"潜伏的隐患"。但如果 R1 的 GE0/0/0 接口 down 了，直连路由消失，这条静态路由就会被激活，数据包在 R1 和 R2 之间来回弹，直到 TTL 减到 0。tracert看到一串在两跳之间循环的结果，就是这个现象。

更隐蔽的情况是目的网段根本不存在，两台路由器互相指对方为下一跳，形成"黑洞"。这种拓扑下ping表现为超时而不是"不可达"，很容易被误判为链路问题。所以配完静态路由，务必对所有网段做一次全连通验证，而不是只测一条。

5. RIP 动态路由：协议帮你算路，但你得管住它

5.1 距离矢量的本质与 15 跳的天花板

RIP 是距离矢量路由协议，核心思想是"我听邻居说去某地要几跳，那我就用邻居的跳数加一"。它不关心网络拓扑长什么样，只关心跳数这个标量。这种设计的优点是实现简单、配置量小，缺点是收敛慢，而且有 15 跳的硬上限——超过 15 跳的网段会被认为不可达，标记为 16。

这个 15 跳的限制不是理论摆设。课设拓扑一般两三跳，肯定碰不到，但你要知道它存在，因为这意味着 RIP 只适合小型网络。另外它还有一个副作用：跳数相同的多条路径会被等价负载分担，这在某些场景下是好事，但在排错时会造成困惑——即使用tracert看到流量走了某条路，也不代表另一条路没被使用。

RIP 的另一个特征是它用 UDP 520 端口发报文，周期性广播或者组播整张路由表。所以它天然会消耗带宽，网络规模一大就更明显。理解这一点，你就知道为什么network命令的写法需要谨慎——它不是"宣告某个接口"，而是"宣告某个网段"，这个区别非常关键。

5.2 RIPv1 和 v2 的差异，以及 network 到底在做什么

RIPv1 是有类路由协议，路由更新里不带掩码，所以它只认 A/B/C 类主网，且不支持 VLSM。RIPv2 加了掩码字段，支持 VLSM 和 CIDR，还支持组播更新和认证。课设里一律用 v2，因为我们的互联链路是 /30，v1 根本表达不了。

配置形态是这样，以 R1 为例：

[R1] rip 1 [R1-rip-1] version 2 [R1-rip-1] network 192.168.10.0 [R1-rip-1] network 10.0.0.0 [R1-rip-1] undo summary [R1-rip-1] quit

这里最容易出错的地方是network参数。它后面跟的是主类网络地址，不是接口地址，也不是子网地址。192.168.10.0/24 是 C 类地址，主类网络就是 192.168.10.0，写它没问题。但互联链路 10.1.1.0/30 是 A 类地址空间，主类网络是 10.0.0.0，你必须写成network 10.0.0.0，而不能写network 10.1.1.0。写错了不报错，只是这条链路不会被 RIP 宣告出去。

这个规则第一次接触会觉得反直觉，但它背后的逻辑其实很清楚：RIP 的 network 命令是在告诉设备"请找出所有属于这个主类网络的接口，把它们启用 RIP"。设备内部会做匹配，所以填的是主类网络。RIPv2 加上undo summary之后，宣告出去的是明细网段而不是自动汇总的大网段，这样 /30 的互联链路才能被正确传递。

undo summary这一条我建议无脑加上。自动汇总在 RIPv2 里默认开启，会把 192.168.10.0/24 这类子网汇总成 192.168.0.0/16 发包出去，如果你的拓扑里有多个 192.168.x.0/24 网段分布在不同的路由器上，汇总会导致路由混乱——远端路由器以为去 192.168.0.0/16 走某一条路就行，结果把包送错了地方。这个坑我在做多网段拓扑时踩过，症状是某些网段在不同位置 ping 结果不一致。

5.3 水平分割和毒性逆转解决什么

既然 RIP 靠邻居传话，那必然要处理一个问题：我从邻居那里学到的路由，要不要再告诉这个邻居？不加限制的话，邻居 A 告诉 B 说"我能到网段 X"，B 又告诉 A"我能到网段 X"，A 就会把 B 当成去 X 的路径，形成环路。RIP 用两条机制堵这个漏洞。

水平分割的规则是：从某个接口学到的路由，不再从这个接口发回去。这条规则基本上就堵住了最直接的两跳环路。毒性逆转则更主动：从某个接口学到的路由，从这个接口发回去时把跳数标成 16（不可达）。两者效果相近，毒性逆转更保险但更耗带宽。

设备上一般默认开启水平分割，display rip 1 interface verbose能看到当前状态。我的建议是保持默认，不用刻意关。有些特殊拓扑（比如帧中继的星型结构）需要关闭，但课设里用不到。

这里还有一个容易忽略的点：接口被配了silent-interface之后，这个接口就不会收发 RIP 报文了。它的用途是让连接用户网段的接口只通告路由、不接收路由更新，安全性更好。配置方式是：

[R1] rip 1 [R1-rip-1] silent-interface GigabitEthernet 0/0/0

在课设里这是加分项，不是必须项。但如果你发现某个接口明明在network范围内，却始终不发 RIP 更新，先去查有没有被误配成 silent。

5.4 用 display 和 debugging 把协议看穿

RIP 的验证分三个层次。

第一层看全局，display rip 1能看到 RIP 进程状态、版本、是否开启汇总。这一条用来确认配置生效了没有。

第二层看路由，display rip 1 route是 RIP 自己的路由数据库，display ip routing-table protocol rip是已经进入全局路由表的条目。这两个结果不一定一样，因为 RIP 数据库里可能有优先级更低的条目被静态路由压住，没进全局表。对比两者能快速发现"学是学到了但没生效"的问题。

第三层看报文，这一步最有用但也最少人做：

<R1> terminal monitor <R1> terminal debugging <R1> debugging rip 1 packet

然后你会看到 RIP 报文在接口上进出的情况，包括从哪个接口收到、源地址是什么、里面有几个路由条目。如果发现某个网段在发的报文里根本不存在，问题就在宣告端；如果在发的报文里有但收端没学到，问题就在接收端的network配置或者过滤策略。

注意：debugging 会大量占用设备 CPU，做完立刻用undo debugging all关掉。在模拟器里无所谓，但在真机或者考试环境里忘了关，可能直接导致设备响应变慢。

6. 四个任务串起来做时的顺序和联动问题

6.1 我的实际操作顺序

这四个任务不是平级的，它们有依赖关系，顺序错了会重复返工。我的做法是：先 IP 地址，再 PPP，再静态路由，最后 RIP。

理由是：地址是一切的基础，链路层协商成功才能谈网络层可达，静态路由能让你在不依赖协议的情况下先验证拓扑是否全通，RIP 则是在静态路由验证过的拓扑上做动态替换。如果先配 RIP 再配静态路由，你会发现静态路由进不了路由表（被优先级更高的直连和 RIP 抢占），排错时会怀疑自己写错了命令。

具体到验证节点，我在四个阶段分别做一次检查：

最后一行是关键。很多人配完 RIP 之后不撤静态路由，看到能 ping 通就交卷了，其实那时候通的是静态路由，RIP 根本没工作。撤掉静态路由再测一遍，才是真正验证 RIP 生效的方法。

6.2 一个典型的多故障叠加场景

我在一次课上遇到过这样一个情况：R1 到 R3 的两个用户网段互相 ping 不通，但从 R2 上 ping 两边都通。表面上看是 R1 或 R3 的单向问题，实际上是三个错误叠在一起。

第一个错误是 R3 的 RIP 里network 10.0.0.0忘了配（只配了network 192.168.30.0），导致 R3 不会把互联链路宣告出去，R1 和 R2 都学不到 R3 的串行口地址。第二个错误是 R1 有一条指向 192.168.30.0/24 的静态路由，下一跳写的是 10.1.2.2（应该是 10.1.1.2），下一跳不可达。第三个错误是 R2 上一条路由的掩码写成了 /24 而实际应该是 /30。

这三个错误单看都不致命，合在一起就造成了非常诡异的现象。定位方法是从 R2 往外 ping，逐步确认每一跳的可达性，然后逐台设备display ip routing-table对比。当发现 R1 的路由表里 192.168.30.0 的下一跳是 10.1.2.2 时，问题就破了一半。剩下的用display rip 1 route一看，R2 上确实没有 R3 那边的串行链路路由，问题定位完成。

这个经历让我形成一个习惯：排错先看路由表，再看接口状态，最后看协议状态。因为路由表是"结果"，接口和协议是"原因"，从结果反推原因，比从原因猜结果要快得多。

6.3 几条写给自己看的经验

第一，配置完一台设备立刻save或者至少display current-configuration扫一眼。模拟器崩溃或者误操作重启，前面的功夫全白费。我在连续做了三个小时之后因为模拟器崩溃重配过一次，那之后养成了每完成一段就保存的习惯。

第二，ping的时候不要只 ping 一个地址。从 R1 依次 ping 每一个网段的每一个接口地址，形成一张连通性矩阵。这张矩阵能立刻暴露出单向可达的问题，而单向可达恰恰是路由配置错误最典型的表现。

第三，看到"请求超时"和"目标主机不可达"要分开对待。前者说明包出去了但没回来，问题在回程路由或者目标设备；后者说明本机路由表里根本没有匹配条目，问题在源端配置。这两种报错指向完全不同的排查方向，混在一起想只会浪费时间。

第四，接口的description、设备的sysname、统一的密码规则，这些看起来是"面子工程"的东西，在多设备联调时的价值远超预期。我现在的习惯是每个接口都写描述，格式统一成to-设备名-接口名，查路由表的时候一眼就能看出这条路由通向哪台设备。

最后分享一个我觉得最实用的小技巧：做这个课设的时候，把每一次成功的配置段落复制到一个文本文件里，按设备名分段存好。等你需要重做或者换拓扑的时候，改改地址就能直接复用。这套东西我第一次做了四个小时，第二次做只用了四十分钟，差距全在这个文件上。