第31篇：路由环路是怎么产生的：TTL 与跳数限制

关键词：路由环路、TTL、跳数限制、ICMP Time Exceeded、水平分割（Split Horizon）

一、引言

在第30篇中，我们学习了浮动静态路由如何实现链路主备切换。但如果主备路由配置不当，或者网络拓扑出现变化时路由信息未能及时更新，数据包就会在路由器之间反复传递，形成路由环路（Routing Loop）。路由环路不仅浪费带宽和设备资源，还会导致业务完全中断。本篇深入分析环路产生的根本原因，以及 IP 协议中 TTL 机制如何作为"最后一道防线"阻止环路无限持续。

二、环路产生的根本原因

2.1 什么是路由环路

路由环路是指数据包在两台或多台路由器之间循环转发，永远无法到达目的地址的现象。本质上，环路是路由表中存在相互矛盾的下一跳指向。

以三台路由器为例：

• R1 认为到达 10.0.0.0/8 的下一跳是 R2
• R2 认为到达 10.0.0.0/8 的下一跳是 R3
• R3 认为到达 10.0.0.0/8 的下一跳是 R1

此时发往 10.0.0.0/8 的数据包将在 R1→R2→R3→R1 之间无限循环。

2.2 环路产生的四大场景

2.3 场景还原：链路故障后的环路

三、TTL：IP 协议的防环机制

3.1 TTL 的工作原理

TTL（Time To Live）是 IP 报文头部的一个 8 比特字段。虽然名字是"生存时间"，但它实际上记录的是最大跳数。每经过一台三层设备（路由器或三层交换机），TTL 减 1；当 TTL 减到 0 时，设备丢弃该报文并向源地址发送 ICMP Time Exceeded 消息。

3.2 TTL 递减过程

3.3 不同系统的默认 TTL

通过观察收到的报文 TTL 值，可以推断源主机的操作系统类型，这也是网络侦察中常用的方法。例如：PC ping测网络设备ip查看到的TTL可能是253；PC ping测Windows主机ip查看到的TTL可能是124；PC ping测Linux主机ip查看到的TTL可能是59。

3.4 TTL 在环路中的作用

TTL 不是用来"防止"环路产生的，而是在环路已经发生时，限制环路造成的损害范围：

1. 阻止无限循环：没有 TTL，数据包将永远在环路中传递
2. 释放资源：TTL 过期后报文被丢弃，释放链路上占用的带宽
3. 故障诊断：ICMP Time Exceeded 消息可帮助定位环路位置

四、实战配置与故障案例

4.1 案例一：接口故障后残留静态路由导致环路

故障描述：某企业分支到核心之间的链路正常，但办公网段用户访问外网出现间歇性丢包和时延增大，且与办公侧接口频繁 Down/Up 的时段吻合。

网络结构：分支路由器 BR 通过 GE0/0/1 接入核心路由器 CR。BR 上联接口 GE0/0/1 的 IP 为 10.1.1.1/30，CR 对端 IP 为 10.1.1.2/30。BR 身后办公网段为 192.168.10.0/24（Vlanif10）。CR 通过 GE0/0/2 上联互联网网关。

# BR 上正确的默认路由（办公用户去外网 → CR）
[BR] ip route-static 0.0.0.0 0 10.1.1.2

# 错误配置：BR 上为办公网段 192.168.10.0/24 配了一条"反指"回 CR 的静态路由
[BR] ip route-static 192.168.10.0 24 10.1.1.2       ← 错误！办公网段被反指回 CR

# 正常情况下：办公侧直连路由（Pre 0）优先，错误静态路由不生效，不会环路
# 一旦办公侧接口（Vlanif10）故障 Down，直连路由消失，错误静态路由"浮出水面"：
# - 外网回程 → CR → BR（按 CR 上的 192.168.10.0/24 回程路由）
# - BR 查表命中 "192.168.10.0/24 → 10.1.1.2 (CR)"，再次丢回 CR
# - CR 又回给 BR → 循环往复，直到 TTL 减为 0 被丢弃

关键点：只要办公侧直连路由存在，正确路由始终优先（Pre 0 最小），错误静态路由不会真正生效。环路往往在接口 Down、直连路由消失后才被触发——接口状态已变化，残留的旧路由却还在表中转发流量，这正是"路由信息延迟更新"类环路的典型形态。

排查过程：

# 查看路由表：此时办公接口已 Down，直连路由消失，只剩残留的静态路由
<BR> display ip routing-table 192.168.10.0
Destination/Mask    Proto  Pre  Cost  NextHop       Interface
192.168.10.0/24     Static 60   0     10.1.1.2      GE0/0/1    ← 残留的错误静态路由

# 确认办公侧接口状态（直连路由消失的原因）
<BR> display interface Vlanif10
# Vlanif10 当前处于 Down 状态

# 使用 tracert 观察路径：反复出现 10.1.1.2，说明数据包在 BR↔CR 之间循环
<CR> tracert 192.168.10.10

# 修复 1：删除错误静态路由
[BR] undo ip route-static 192.168.10.0 24 10.1.1.2

# 修复 2：排查并恢复办公侧物理链路，使直连路由重新生成

4.2 案例二：环路导致的 ICMP Time Exceeded 爆发

故障描述：核心交换机 CPU 利用率异常升高，经 GE1/0/1 接入的业务出现明显时延增大、间歇性丢包。

# 查看 CPU 占用
<HUAWEI> display cpu-usage
# CPU utilization for five seconds: 85%; one minute: 80%; five minutes: 75%
# 如果设备支持按任务查看，可用 display cpu-usage task，按需查看（以实际设备版本为准）

# 查看接口统计
<HUAWEI> display interface GigabitEthernet 1/0/1
# 发现端口速率异常

# 通过抓包或镜像定位
# 在 GE1/0/1 上做端口镜像，使用 Wireshark 抓包
# 发现大量 ICMP Time Exceeded 报文，TTL 均为 1 或 2

# 根因：接入交换机与核心之间形成 L3 路由环路，数据包被反复转发、TTL 耗尽后产生大量 ICMP Time Exceeded；这些 ICMP 报文的目的地址路由又指回环路，形成二次环路（雪崩效应），进一步挤占带宽和转发资源，导致 CPU 升高和业务时延增大。

4.3 案例三：使用 TTL 追踪定位环路

# 使用 tracert 定位环路节点
<HUAWEI> tracert -a 192.168.1.1 10.10.10.10
 1  10.1.1.2    1ms    1ms    1ms
 2  10.2.2.1    2ms    2ms    2ms
 3  10.3.3.1    3ms    3ms    3ms
 4  10.1.1.2    4ms    4ms    4ms   ← 回到节点1！
 5  10.2.2.1    5ms    5ms    5ms   ← 环路确认
 6  * * *
 7  * * *
# tracert 发现 1→2→3→1 形成环路

原理：tracert 通过发送 TTL 依次为 1、2、3 ... 的探测报文，每一跳设备在 TTL 减到 0 时返回 ICMP Time Exceeded，从而把路径画出来。当路径里出现重复 IP，就能确认环路。

4.4 华为设备上的环路防护配置

# 方法1：静态路由使用出接口方式（接口 Down 时路由自动失效）
[HUAWEI] ip route-static 0.0.0.0 0 GigabitEthernet 0/0/1
# 接口 Down → 路由自动撤销；接口恢复 → 路由自动放回

# 方法2：在易形成环路的接口上做报文过滤或路由汇总
# 例如对办公网段做黑洞路由兜底
[HUAWEI] ip route-static 192.168.10.0 24 NULL0

五、总结

思考

1. 为什么 TTL 字段设计为"跳数"而非"时间"？用时间计时的方案有什么缺陷？
2. 如果一台路由器的 TTL 没有正常递减（设备 Bug），会对网络产生什么影响？
3. tracert 利用 TTL 探测路径的原理是什么？为什么需要连续发送 TTL=1、2、3... 的报文？

下篇预告：第32篇：策略路由（PBR）：不按路由表走