2.7.2 连通性与路径诊断（ping/tracepath/mtr）

连通性与路径诊断（ping/tracepath/mtr）#

连通性与路径诊断用于快速判断“是否可达、走哪条路、在哪一跳异常、是否存在 MTU 问题”。推荐的排查顺序是：ping 初判可达与时延 → tracepath 定位路径与 MTU → mtr 持续观测丢包与抖动趋势。

原理草图：探测包在路径中的变化

1) 工具安装与版本确认#

Linux 常见工具来自 iputils 与 mtr 包。

Debian/Ubuntu

sudo apt update
sudo apt install -y iputils-ping iputils-tracepath mtr-tiny
ping -V
tracepath -V
mtr -V

RHEL/CentOS/Rocky

sudo yum install -y iputils mtr
ping -V
tracepath -V
mtr -V

2) ping：可达性与基础时延评估（含 MTU 验证）#

关键指标： RTT、丢包率、时延抖动
常用参数解释：
- -c N：发送 N 次后退出
- -i 秒：探测间隔
- -s 字节：载荷大小（不含 IP/ICMP 头）
- -M do：禁止分片，用于 PMTU 验证

基础可达性测试

ping -c 4 -i 0.5 8.8.8.8

输出示例（截断）与解读

4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 12.4/13.2/15.1/1.1 ms

0% 丢包：可达
avg 13.2ms：平均时延
mdev 1.1ms：抖动低

PMTU 诊断（以 1472 载荷为例）

# 1500 MTU - 20(IP) - 8(ICMP) = 1472
ping -c 3 -M do -s 1472 目标IP

可能输出

ping: local error: Message too long, mtu=1460

说明路径 MTU < 1500，建议将载荷下调至 1432 或继续探测直到成功。

3) tracepath：路径与 MTU 诊断（无需 root）#

关键点：
- 展示每一跳时延
- 自动发现路径 MTU（pmtu）
- no reply 可能是中间设备禁止回显，不一定故障

示例

tracepath 目标IP

输出示例（截断）

 1:  10.0.0.1                                          0.350ms
 2:  100.64.0.1                                         1.231ms
 3:  203.0.113.5                                        5.882ms
 4:  198.51.100.9                                       8.214ms
 5:  203.0.113.10                                       9.720ms pmtu 1460
 6:  目标IP                                              9.901ms reached

解读：
- 第 5 跳出现 pmtu 1460，路径 MTU 被降低
- 若业务出现分片问题，可考虑调整接口 MTU 或应用层包大小

4) mtr：持续动态观测与报告输出#

适用场景： 需要持续监测丢包和抖动趋势
参数说明：
- -r：报告模式（一次性输出）
- -c N：探测次数
- -w：宽屏输出，便于阅读

示例（报告模式）

mtr -r -c 50 -w 目标IP

输出示例（截断）

HOST: node1                         Loss%   Snt   Last   Avg  Best  Wrst StDev
 1.|-- 10.0.0.1                     0.0%    50    0.4    0.5   0.3   1.2   0.2
 2.|-- 100.64.0.1                   2.0%    50    1.3    1.5   1.0   3.9   0.6
 3.|-- 203.0.113.5                  2.0%    50    6.2    6.5   5.1  12.4   1.8
 4.|-- 198.51.100.9                 2.0%    50    9.0    9.3   7.9  15.7   1.9
 5.|-- 目标IP                        2.0%    50    9.8   10.1   9.1  16.2   2.0

解读要点：
- 丢包在第 2 跳出现并在后续延续 → 该段或其后链路异常
- 若仅某一跳丢包而后续不丢 → 可能是该跳 ICMP 限速

5) 排错流程与命令解释模板#

排错流程
1) ping -c 4 目标IP → 判断可达性
2) tracepath 目标IP → 判断路径与 PMTU
3) mtr -r -c 50 目标IP → 持续观测丢包与抖动

结论输出模板
- 现象：目标可达/不可达；RTT 平均 xx ms；丢包 xx%
- 路径：第 N 跳出现明显时延/丢包（是否延续到后续）
- MTU：路径 MTU 变更为 xx（是否影响业务大包）
- 建议：联系运营商排查该段链路或调整 MTU/绕路

6) 典型问题与对策（含排错命令）#

问题一：ping 不通但服务可访问
- 可能原因：ICMP 被防火墙丢弃
- 排查命令：

# 检查本机防火墙策略
sudo iptables -L -n | grep -i icmp
sudo nft list ruleset | grep -i icmp

处理建议：确认安全策略是否允许 ICMP Echo

问题二：tracepath 出现 pmtu 降低且业务大包失败
- 排查命令：

# 用禁止分片的 ping 验证 PMTU
ping -c 3 -M do -s 1472 目标IP

处理建议：调整接口 MTU 或应用层包大小

问题三：mtr 某一跳丢包高但后续不丢
- 原因：该跳 ICMP 限速或优先级低
- 处理建议：关注后续跳与目标跳的 Loss%

7) 练习与实战任务#

1) 使用 ping 对公网 DNS 进行 20 次探测，记录 RTT 与丢包率。
2) 使用 tracepath 对目标主机检测路径，写出路径中 MTU 是否变化。
3) 使用 mtr -r -c 100 生成报告，判断异常跳是否延续到后续。
4) 修改本机 MTU（虚拟机/测试环境），验证 ping -M do 的变化。

参考命令（测试环境）

# 修改接口 MTU（仅测试环境）
sudo ip link set dev eth0 mtu 1400
ip link show dev eth0 | grep mtu