Cisco静态路由实验：ip route配置、路由表解读与故障排查

配置完静态路由，ping还是不通，show ip route里明明躺着那条目标网段——几乎每个人第一次做 Cisco 静态路由实验，都会撞上这个瞬间。盯着屏幕反复确认命令没敲错，接口都是 up，掩码也没写反，但数据包就是不回来。静态路由实验之所以经典，不是因为命令多难，而是它把“路由表里有一行字”和“数据包真的能过去”这两件事之间的一整条链路，全部摊开在你面前。本文围绕 Cisco 静态路由实验展开，从拓扑设计和地址规划，到ip route的三种写法、show ip route输出怎么读，再到单向路由、递归查找失败、管理距离冲突这几类高频故障的完整排查链路，最后补上默认路由、浮动静态路由和负载分担的落地配置。适合刚接触 IOS 命令行、正在准备网络方向实验考核，或者带新人做实验的读者参考。全篇给的是可以直接照抄的参数和命令，也会说清楚每一步为什么要这么写。

1. 动手配命令之前，先把静态路由这件事想透

1.1 路由表的三要素决定了你该敲哪条命令

很多新手做实验的习惯是“照着拓扑图把ip route抄一遍”，抄完通了就交差，不通就删了重来。这种打法能过实验，但过了就忘。想把静态路由真正吃下去，得先认清路由表里一条表项到底在说什么。IOS 的路由表条目，本质上是三个要素的组合：目的网段（含掩码）、下一跳地址或者出接口、管理距离与度量值。你敲的每一条ip route，都是在手工往这三个位置填内容，路由器不替你做任何推断。

这三个要素里，目的网段决定“这条路由管谁”，下一跳决定“包交给谁”，管理距离决定“和别的路由打架时谁优先”。静态路由的管理距离默认是 1，这个数字非常小，意味着只要有一条静态路由匹配上了，直连路由之外的动态路由基本都要让路。理解这一点，后面排错时看到“明明动态协议学到了一条更好的路径，为什么还是走静态”就不会慌——那不是设备坏了，是管理距离在按规则办事。

还有一个常被忽略的点：静态路由是单向的。你在 R1 上写一条指向右边网段的路由，只解决了 R1 出去的方向。回程包要回来，对端路由器也必须有一条指向 R1 侧网段的路由。这是静态路由实验里“通一半”问题最根本的来源，后面第 4 章会专门拆开讲。

1.2 静态路由和动态路由的边界在哪

做实验时经常会有一个疑问：既然 OSPF、RIP 这些协议能自动学路由，为什么还要手工写静态路由？答案不在“能不能”，而在“值不值”。动态路由协议要跑起来，需要邻居建立、报文交互、收敛计算，这套机制在几十台设备、链路频繁变化的网络里是刚需，但在只有三台路由器、一台出口设备的小规模网络里，纯属给自己加负担。

我自己的取舍标准通常是这几条：

• 网络规模小、拓扑稳定：静态路由优先。配置量可控，出了问题一眼能看出来，不用去翻邻居状态和 LSA。
• 末梢网络或单一出口：默认路由几乎是无脑选择，一条ip route 0.0.0.0 0.0.0.0收口，比跑个协议省事得多。
• 需要精确控制转发路径：比如要做策略路由之外的主备选路，静态路由配合管理距离比调协议的度量值直观。
• 链路抖动频繁、存在多路径冗余：这时候动态协议的价值才真正体现，静态路由要靠浮动配置硬撑，维护成本会迅速上升。

静态路由的代价也很明确：它不会自己消失。链路断了，静态路由依然在路由表里待着，只要出接口物理状态还是 up，流量就会被黑洞一样吸进去。这个特性在实验里是考点，在生产里就是事故来源。

1.3 三台路由器、两个网段，实验拓扑的最小可用配置

做静态路由实验，拓扑不需要复杂，但必须满足一个条件：至少有一台路由器的两侧都不直连你想要访问的网段。否则直连路由就把事情办完了，静态路由根本没有发挥空间。

我推荐的经典拓扑是这样的：R1 和 R3 各自挂一个用户网段，R2 夹在中间做中转，R1 与 R2 之间用串行链路连接，R2 与 R3 之间同样用串行链路。这套结构的好处是，R1 要访问 R3 侧的用户网段，必须穿过 R2，而 R2 对 R1 来说是“非直连”的，静态路由的必要性立刻显现出来。

如果想再贴近一点真实场景，给每台路由器加一个 Loopback 接口当模拟业务网段。Loopback 是逻辑接口，不会因为物理链路插拔而 down，实验过程中状态永远稳定，拿来当“远端业务网段”比真实接口可靠得多。很多同学习惯用 PC 模拟，结果 PC 的防火墙、网卡休眠、IP 配置错误全混进来，排错时根本分不清是路由问题还是终端问题。

设备选择上，用两台路由器加一台三层交换机也能搭，但对于第一次做静态路由实验的人，三台路由器是最干净的方案。串行接口要注意 DCE 端需要配置时钟频率，这个细节在模拟器里有时被自动处理，在真实设备上漏配就是接口起不来，属于典型的“实验能做通、真机就翻车”的坑。

2. 地址规划没钉死，后面每一步都是返工

2.1 一张表把网段、接口和地址全部锁定

我做实验有个习惯：开命令行之前先把地址表写出来，写在纸上或者文档里都行。这张表一旦定了，后面所有配置和排错都以它为准，绝不在配置过程中临时改地址。临时改地址是实验失败的头号原因，你会记不清哪个网段配在哪台设备的哪个口上，ping不通时连该查哪里都不知道。

下面是我常用的规划表，直接照这个填就能开工：

互联链路用 /30 而不是 /24，这是一个值得养成的习惯。点到点链路只需要两个可用地址，用 /30 正好两个，既省地址空间，也让路由表看起来干净。实验环境地址富裕，很多人随手写 /24，结果后面做路由汇总或者配 ACL 的时候，一堆“看起来能用其实不该用”的地址混在网段里，排查起来非常痛苦。

2.2 直连网段不需要配路由，但你要知道为什么

新手最容易困惑的一点是：为什么 R1 的 G0/0 配了 192.168.1.1/24，R1 就自动知道 192.168.1.0/24 这个网段怎么走，而我什么都没配？这是因为接口配置了 IP 并处于 up 状态后，IOS 会自动把该接口所在网段以直连路由的形式注入路由表，管理距离为 0，代码标记为 C（connected）。如果你再给接口配一个secondary地址，对应的网段同样会自动出现。

理解这一点，就能明白静态路由实验里真正需要你操心的只有非直连网段。在刚才的拓扑里，R1 需要关心的非直连网段是 192.168.3.0/24、10.0.23.0/30 和 3.3.3.3/32；R2 需要关心 192.168.1.0/24 和 192.168.3.0/24；R3 需要关心 192.168.1.0/24、10.0.12.0/30 和 1.1.1.1/32。把这些列出来，你的配置清单就已经完成一半了。

还有一个细节：直连路由在路由表里显示时会带上出接口信息，而静态路由如果是“下一跳”写法，出接口那栏显示的是递归查出来的接口。看路由表时要能区分这两种显示方式，否则你会误以为下一跳写法没有生效。

2.3 Loopback 接口是这个实验里的“稳定锚点”

Loopback 的价值在排错阶段会成倍放大。物理链路在实验过程中一旦被误碰、模拟器重载，接口状态就会变，而 Loopback 始终 up。用 Loopback 当测试目标，可以把“链路故障”和“路由配置故障”这两类问题彻底分开。

配置也很简单，进入全局配置模式后指定接口编号和地址，IOS 会自动把它置为 up 状态，不需要no shutdown：

R1(config)# interface loopback 0 R1(config-if)# ip address 1.1.1.1 255.255.255.255

掩码写成四个 255，也就是 /32，代表这是一个主机地址而不是网段。这一点很关键：如果写成 /24，那么 1.1.1.0/24 整个网段都会被当成直连路由，你在别的地方写 1.1.1.0/24 的静态路由就会被直连路由压住，怎么配都不生效。

3. 命令行落地：从空白配置到路由表出现目标网段

3.1 基础配置的固定套路，别在细节上丢分

我习惯按固定的顺序推配置：主机名、接口地址、接口开启、串行链路时钟、Loopback。顺序固定下来，就不会漏项。特别是串行接口的no shutdown，很多人配完地址就退出，忘了这一步，接口一直是 administratively down，show ip interface brief里显示 down/down，然后开始怀疑路由配置有问题。

完整的 R1 基础配置如下：

R1(config)# hostname R1 R1(config)# interface gigabitEthernet 0/0 R1(config-if)# ip address 192.168.1.1 255.255.255.0 R1(config-if)# no shutdown R1(config-if)# exit R1(config)# interface serial 0/0/0 R1(config-if)# ip address 10.0.12.1 255.255.255.252 R1(config-if)# clock rate 64000 R1(config-if)# no shutdown R1(config-if)# exit R1(config)# interface loopback 0 R1(config-if)# ip address 1.1.1.1 255.255.255.255

clock rate只在 DCE 端配，也就是提供时钟的那一端。真实实验中，如果两台设备用背靠背串口线连接，一端是 DCE 一端是 DTE，DCE 端必须配时钟，否则链路协议状态起不来，表现为接口物理 up、协议 down。在模拟器里，有时两端都配也不会报错，但那只是宽容，不代表做法正确。判断哪端是 DCE，用show controllers serial 0/0/0看输出里有没有 “DCE V.35” 字样。

配完所有设备的基础部分，先别急着写静态路由，先做一轮直连验证：R1ping 10.0.12.2，R2ping 10.0.12.1和ping 10.0.23.3，R3ping 10.0.23.2。这些必须全通。直连都不通就去配静态路由，等于在坏地基上盖楼。

3.2 ip route 的三种写法，选错就是给未来埋雷

静态路由命令的语法是ip route 目的网段 掩码 {下一跳地址 | 出接口 | 出接口 下一跳地址}，三种写法各有适用场景，差别不只是风格问题。

**第一种：只写出接口。**比如ip route 192.168.3.0 255.255.255.0 serial 0/0/0。这种写法在点到点链路上能正常工作，路由器认为从该接口出去的包都能到达目的网段。问题在于，如果是以太网这类多路访问链路，路由器不知道下一跳的 MAC 地址，会对每一个目的地址发起 ARP 请求，路由表里会出现大量 ARP 条目，转发效率极低。点到点接口可以用，以太网接口不要用。

**第二种：只写下一跳地址。**比如ip route 192.168.3.0 255.255.255.0 10.0.12.2。这是最推荐、也是实验里最常用的写法。路由器拿到包之后，用下一跳地址去路由表里做一次递归查找，找到对应的出接口，然后再转发。这种写法对链路类型不敏感，以太网、串行都能用，而且下一跳写错了会直接表现为路由不生效，问题暴露得早。

**第三种：出接口加下一跳一起写。**写成ip route 192.168.3.0 255.255.255.0 serial 0/0/0 10.0.12.2。这种方式跳过了递归查找，转发效率略高，在以太网链路上也能避免 ARP 泛洪，属于工程上的优化写法。缺点是配置量大，链路一改就要动两处。实验阶段我建议先用第二种把逻辑跑通，理解清楚之后再改成第三种体会差异。

按拓扑，三台路由器的完整静态路由配置是这样：

R1(config)# ip route 192.168.3.0 255.255.255.0 10.0.12.2 R1(config)# ip route 10.0.23.0 255.255.255.252 10.0.12.2 R1(config)# ip route 3.3.3.3 255.255.255.255 10.0.12.2 R2(config)# ip route 192.168.1.0 255.255.255.0 10.0.12.1 R2(config)# ip route 192.168.3.0 255.255.255.0 10.0.23.3 R3(config)# ip route 192.168.1.0 255.255.255.0 10.0.23.2 R3(config)# ip route 10.0.12.0 255.255.255.252 10.0.23.2 R3(config)# ip route 1.1.1.1 255.255.255.255 10.0.23.2

注意 R2 的角色：它是中转设备，两侧的网段都需要它来转，所以两条静态路由一条指左一条指右，缺一条就断一半。另外，R1 到 3.3.3.3 的路由其实可以省略，因为 3.3.3.3 属于 192.168.3.0/24 之外，但如果只写一条 192.168.3.0/24 的静态路由，去往 3.3.3.3 的包匹配不上，会被丢弃。要不要写汇总路由，取决于你想让实验覆盖到什么程度。

3.3 show ip route 的输出，每一列都有信息

配完路由，第一件事是看路由表，但很多人只会看“有没有那一行”，不看细节。show ip route的输出信息密度很高，我挑几个关键位置说。

路由表条目开头的字母是路由来源代码：C 表示直连，S 表示静态，S* 表示静态默认路由，O 表示 OSPF，R 表示 RIP。方括号里的两个数字，格式是[管理距离/度量值]，静态路由默认是[1/0]。最后的via后面跟的是下一跳地址，再后面是出接口和从该接口出去需要经过的跳数。

一条典型的静态路由长这样：

S 192.168.3.0/24 [1/0] via 10.0.12.2

如果写的是出接口方式，会显示成is directly connected, Serial0/0/0，这时候容易被误认为是直连路由，但开头的 S 已经说明了它的来源。还有一个容易误判的情况：show ip route里看不到你配的静态路由，第一反应是配置没生效，实际上可能是被更优的路由覆盖了——如果存在一条管理距离更小的同网段路由，静态路由不会出现在主路由表里，需要加show ip route 192.168.3.0查看详情，或者看show ip route static确认它是否在配置里。

验证阶段建议按这个顺序走：先在 R1 上show ip route确认静态路由存在且下一跳正确；再从 R1 用扩展 ping 指定源地址ping 192.168.3.1 source 192.168.1.1，排除源地址选择带来的干扰；最后从终端侧做端到端验证。指定源地址这一步很多人跳过，结果 ping 通了但业务不通，因为路由器默认用出接口地址做源，而真实业务流量的源地址是终端地址。

4. 四类高频故障，顺着现象往回找根因

4.1 接口全 up、路由也有，就是 ping 不通

这是出现频率最高的现象。排查时别急着删配置，按链路层次顺着往下走，效率比乱试高得多。我的固定动作是四步：

1. show ip interface brief确认所有相关接口的 status 和 protocol 都是 up。物理层和协议层任何一个 down，后面的都不用看。
2. show ip route确认去程和回程两个方向都有匹配的路由，注意是两个方向。
3. show cdp neighbors或者show lldp neighbors确认链路对端确实是预期的设备，防止接线接错口。
4. 在对端路由器上用扩展 ping 指定源地址回 ping，看回程是否成立。

这四步里，第三步最容易被跳过，但实际实验环境里接错口的概率不低。串行线插到另一个 serial 口上，地址配得没错，路由也写得没错，就是不通，因为物理通路的对端不是你以为的那台设备。

如果四步都过了还是不通，考虑掩码问题。静态路由的掩码写错一位，路由表里那条路由就跟目标网段匹配不上，包会走默认路由或者直接被丢弃。我曾经把 /24 写成 /25，路由表里显示的是192.168.3.0/25，去 192.168.3.200 的包完全匹配不上，show ip route 192.168.3.200直接提示没有匹配条目。这个命令非常好用，直接告诉你某条具体路由会怎么走。

4.2 递归查找失败：下一跳地址本身不可达

用“只写下一跳”的写法时，路由器需要拿下一跳地址再去路由表里查一次，这叫递归查找。如果下一跳地址本身不可达，静态路由会被标记为无效，路由表里根本不显示，或者显示但不参与转发。判断方法很简单：先ping一下下一跳地址，通不了就说明问题在这一层。

造成下一跳不可达的原因，常见的有三种。第一，下一跳地址写在了错误的网段里，比如接口是 10.0.12.1/30，下一跳写成 10.0.13.2，这个地址在另一个网段，路由表里没有直连路由指向它。第二，下一跳接口没起来，直连路由消失，递归查找失败。第三，下一跳写成了对端的 Loopback 地址，而你没有到达那个 Loopback 的路由，形成死循环。

还有一种更隐蔽的情况：出接口写成了以太网口，下一跳却没写。路由器会对每个目的地址发起 ARP，但 ARP 请求发出去没人应答（因为目的地址不在这个广播域里），包全部被丢弃。现象是 ping 不通、接口 up、路由表看起来正常，但show arp或者show ip arp里会看到一堆 Incomplete 条目。看到 Incomplete，基本可以锁定是这个原因。

4.3 路由存在但不转发：管理距离与最长匹配在起作用

路由表里有两类冲突会让人怀疑人生。一类是同网段多条路由，靠管理距离决胜负。静态路由默认管理距离 1，直连是 0，OSPF 是 110，RIP 是 120。如果你在同一个网段上写了静态路由，同时这个网段又是某个接口的直连网段，直连路由永远赢。这时候静态路由配了等于没配，show ip route static能看到它，但主路由表里没有。

另一类是不同掩码的多条路由重叠，靠最长匹配原则。比如路由表里同时有 192.168.0.0/16 指向一个方向，192.168.3.0/24 指向另一个方向，那么去 192.168.3.5 的包会走 /24 那条，因为掩码更长、更精确，跟管理距离无关。这个规则经常被误解成“管理距离小的优先”，实际上最长匹配在前，管理距离只用于同一前缀长度的比较。

实验里可以主动制造一次这种场景来加深印象：在 R1 上加一条ip route 192.168.0.0 255.255.0.0 10.0.12.2，然后看show ip route，你会发现 192.168.0.0/16 这条进了表，但去 192.168.3.0/24 的流量依然走原来那条 /24。再show ip route 192.168.3.1，输出会明确告诉你匹配的是哪一条。这个命令是排错时最值得信任的伙伴，它不给模糊答案。

4.4 去得回不来：单向路由的完整定位过程

单向路由是静态路由实验的经典坑。R1 配了去 R3 网段的路由，R3 忘了配回 R1 网段的路由，现象是 R1pingR3 的接口地址能通（因为那是直连或者同链路），但pingR3 侧的用户网段不通。

定位方法是分段测。先在 R1 上ping 10.0.23.3，通了说明 R1 到 R3 的路径本身没问题；再ping 192.168.3.1 source 192.168.1.1，不通；这时到 R3 上show ip route 192.168.1.1，如果提示无匹配条目，结论就明确了——回程路由缺失。整个过程不需要抓包，靠路由表就能定位。

抓包确认也不难，在 R2 和 R3 之间的链路上抓 ICMP，会看到 Echo Request 正常过去，但没有 Echo Reply 回来。这个现象和“目标主机不存在”不同，后者会收到 Destination Unreachable，而单向路由是彻底的沉默。用traceroute也能看出来，它在某一跳之后就没有响应了。

5. 默认路由、浮动路由与负载分担的落地写法

5.1 末梢网络用默认路由收口

如果一台路由器只有一个出口，那么它所有非直连网段都得从这个出口走，这时候逐条写静态路由就是浪费。一条默认路由解决全部问题：

R1(config)# ip route 0.0.0.0 0.0.0.0 10.0.12.2

这条命令的意思是：所有匹配不上更精确路由的包，全部交给 10.0.12.2。路由表里显示为S* 0.0.0.0/0 [1/0] via 10.0.12.2，星号标记它是候选默认路由。

默认路由的优先级要特别注意：它是最不精确的匹配，任何一条掩码更长、能匹配上的路由都会抢在它前面。所以配了默认路由之后，原来那些精确的静态路由不需要删，它们依然会生效。反过来说，如果你发现流量莫名其妙走了默认路由，那说明本应该匹配上的精确路由没配对，回头查掩码。

一个常见误区是认为默认路由会“覆盖”其他路由，其实刚好相反，它是最后的选择。理解这一点，才能在有多出口的网络里正确安排默认路由的位置。

5.2 浮动静态路由做备份链路

拓扑里加了第二条链路之后，就可以做浮动静态路由了。思路是：主路由用默认管理距离 1，备份路由写一个更大的管理距离，比如 200。正常情况下主路由生效，备份路由不出现在路由表里，只有主路由失效，备份才会浮上来。

R1(config)# ip route 192.168.3.0 255.255.255.0 10.0.12.2 R1(config)# ip route 192.168.3.0 255.255.255.0 10.0.13.2 200

这里的关键在于“主路由失效”的判定条件。如果主路由的下一跳是通过串行接口直连的，接口 physical down 会让直连路由消失，静态路由跟着失效，备份就会浮上来。但如果下一跳不是直连，而是需要经过中间设备才能到达，接口 down 了下一跳依然“看起来可达”，静态路由就不会失效，备份不会切换，流量被黑洞吞掉。

这个坑在实验里不太容易碰见，但在真实网络中引发过大量事故。解决办法是配合对象跟踪或者改用动态路由协议，实验阶段至少要知道这个边界在哪。

备份路由浮上来之后，用show ip route 192.168.3.0能看到管理距离变成了 200，路由表里原来的条目被替换。等主链路恢复，管理距离更小的那条会重新夺回位置，整个过程自动收敛，不需要人工干预。这也是静态路由实验里少数能直观看到“自动切换”的场景。

5.3 等价静态路由做负载分担

如果在 R2 上到同一个目的网段有两条开销相同的路径，可以写两条管理距离和度量值都一样的静态路由，IOS 默认支持最多 4 条等价路径做负载分担。

R2(config)# ip route 192.168.1.0 255.255.255.0 10.0.12.1 R2(config)# ip route 192.168.1.0 255.255.255.0 10.0.24.1

路由表里会显示两条 via，后面标注等价。需要注意的是，等价负载分担是逐包还是逐流，取决于设备的转发机制。较新的平台默认基于流的哈希，同一条 TCP 连接的所有包走同一条路径，避免乱序；早期平台可能是逐包轮转，抓包时能看到两条路径交替出现。实验里想验证负载分担是否生效，用多个不同源端口发起连接更容易观察到。

配置等价路由时，两条路径的下一跳都必须可达，任何一条失效，对应的路由从表中移除，流量自动走剩下的那条，这属于静态路由天然具备的冗余能力，不需要额外配置浮动。

6. 实验跑通之后，还有几个值得补的动作

6.1 用 traceroute 和 debug 交叉验证路径

ping通只证明端到端可达，不证明路径符合你的设计。R1 到 R3 的用户网段，很可能绕了远路还照样通。用traceroute看每一跳，确认包确实按你写的静态路由走，这个过程能暴露不少配置失误。

traceroute的原理是逐跳增加 TTL，每经过一台设备 TTL 减一，减到零时设备回一个 ICMP 超时报文，从而把路径上的每一跳都逼出来。输出里每一行是一个 TTL 值，后面跟的是响应地址和三次探测的往返时间。如果看到某一跳之后全是星号，说明那里的设备没有回 ICMP 超时，可能是被过滤了，也可能是路由断了。

debug ip packet或者debug ip routing这类命令在模拟器里可以开，真实设备上要谨慎，尤其是流量大的时候，debug 输出会打满控制台甚至拖垮设备。实验环境里配合undebug all用，能直观看到路由表变化和包的转发决策，比看静态的路由表有意思得多。用完之后记得立刻关掉，这个习惯从实验阶段就要养成。

6.2 抓一次包，看清 ARP 和 ICMP 的完整过程

在第一次做静态路由实验时抓一次包，收获会比配十条路由都大。选 R1 和 R2 之间的链路，从 R1 ping R3 的 Loopback，抓到的报文序列大致是：R1 先发 ARP 请求问 10.0.12.2 的 MAC，R2 回复 ARP，然后 R1 发出 ICMP Echo Request，R2 收到后查路由表转发给 R3，R3 回 Echo Reply，原路返回。

这个过程中能看到几个关键点：ARP 的广播范围只在本链路，跨网段时源 MAC 会逐跳改写，但源 IP 始终不变；TTL 逐跳递减，这也是 traceroute 能工作的基础；每一跳都要重新查路由表，没有任何一台设备知道完整路径。静态路由配的每一条，都只是告诉某台设备“下一站交给谁”，端到端的路径是所有设备各自决策串起来的。

这些在课本上是文字，在抓包窗口里是实实在在的报文。做完这一步，再回头看静态路由的原理，理解的深度完全不一样。

6.3 故意破坏一次配置，再把它修回来

实验跑通不代表学会了。我的建议是，配置全部验证通过之后，主动制造几个故障，然后在不看答案的情况下修回来。可以试的破坏方式有：删掉 R3 上的一条静态路由，观察单向路由的表现；把某条路由的掩码从 /24 改成 /25，观察最长匹配的行为；把下一跳地址改成一个不可达地址，观察递归查找失败；把管理距离改大，观察路由是否还进主表。

每制造一个故障，先在脑子里预测现象，再动手验证。预测对了，说明理解到位；预测错了，那个反差就是最深刻的记忆。这个练法比反复抄配置有价值得多，也是我认为准备实验考核最有效的路径。真正上场时，考官给的排错题往往就是这些故障的组合，平时练过，临场就不会慌。

最后分享一个我个人踩过的坑：早期做实验时喜欢在每台设备上把路由配满，包括那些其实不需要的网段，觉得配得越全越保险。结果一次实验里路由表乱七八糟，出了问题根本不知道是哪条路由在起作用。后来改成只配必要的路由，配置清单短了，排错速度快了不止一倍。静态路由这东西，少写一条往往比多写十条更需要判断力，而这份判断力才是实验真正想让你练出来的东西。