「网络时好时坏」是专线类报修里难处理的一类——测试时正常、投诉时又出问题。有效做法不是多测几次，而是把取证做完整：确定丢包发生在哪一段、抖动与什么时间相关、内网侧是否已排除。拿着这套数据去提工单，运营商侧的定位效率会明显不同。
\n
\n
一、先分清四段：定位的本质是分段
\n
一次访问从终端到目标系统，大致经过四段：
\n
- \n
- 终端到内网网关（内网无线/交换）；
- 内网网关到运营商接入设备（出口路由器与光猫/光端机之间的链路）；
- 运营商网络内部（城域、骨干、跨网互通）；
- 目标系统侧（对端服务器、云端业务、CDN 节点）。
\n
\n
\n
\n
\n
排查原则：从近到远逐段测，先证明内网没问题，再谈运营商。
\n
\n
二、第二步：基础测试（Windows）
\n
- \n
- 内网网关测试（确认内网无丢包）：
\n
\n
ping -n 100 192.168.1.1\n
关注：丢包率、平均时延、峰值时延（抖动看峰值与平均值的差）；
\n
- \n
- 带包长测试（发现 MTU 与分片问题）：
\n
\n
ping -n 50 -l 1400 223.5.5.5\n ping -n 50 -l 1472 -f 223.5.5.5\n
-l 指定数据长度，-f 设置不分片；若小包通、大包不通或带 -f 不通，多与 MTU/PPPoE 封装有关；
\n
- \n
- 路径测试：
\n
\n
tracert -d 目标地址\n
-d 不解析域名，输出更快；看时延在哪一跳开始明显抬升；
\n
- \n
- 综合统计：
\n
\n
pathping 目标地址\n
会给出逐跳的丢包统计，适合给不太熟悉命令行的人看结果。
\n
\n
三、第三步：MTR（定位效率较高的一步）
\n
MTR 把 ping 与 tracert 结合，能直接给出每一跳的丢包与时延，是定位运营商侧丢包的主要工具。
\n
Linux：
\n
mtr -rwzc 100 目标地址\n
参数含义：-r 报告模式、-w 宽输出、-z 显示 ASN、-c 包数。
\n
Windows 可用 WinMTR 等图形化工具，输出列含义一致：
\n
| 列 | 含义 |
|---|---|
| Loss% | 该跳的丢包比例 |
| Avg / Best / Wrst | 平均 / 低值 / 高值时延（Wrst-Avg 反映抖动） |
| StDev | 时延标准差，越大说明抖动越明显 |
\n
判读要点：
\n
- \n
- 某一跳开始持续丢包且后续各跳同样丢包 → 故障点大概率在该跳或其上游；
- 中间某跳丢包但后续正常 → 多为该设备对探测报文限速（ICMP 限速），不能作为故障证据；
- 只有最后一跳丢包 → 多为对端限制 ICMP，应改用业务层测试（HTTP 请求、实际业务操作）确认。
\n
\n
\n
\n
\n
四、第四步：内网侧自检（提工单前必须做）
\n
- \n
- 出口设备负载：CPU、内存、会话数是否接近规格（会话数问题见 T05）；
- 内网是否有泛洪：二层广播风暴（见 T02）、组播泛洪（见 T03）都会表现为出口侧丢包；
- 光模块与收发光功率（专线经光纤落地时）：
\n
\n
\n
\n
display transceiver interface GigabitEthernet 0/0/x\n
关注接收光功率是否在模块允许范围内；光衰过大、尾纤弯折、法兰头污染都会导致误码；
\n
- \n
- 端口错误计数：
\n
\n
display interface GigabitEthernet 0/0/x\n
关注 CRC 错误、错包、up/down 次数，持续增长说明物理层有问题；
\n
- \n
- 双线与主备切换：主备链路切换瞬间的丢包，应与切换日志时间对齐后再判断是否误报。
\n
\n
\n
五、第五步：时间相关性分析
\n
抖动类问题要和时间对上，建议记录：
\n
| 记录项 | 用途 |
|---|---|
| 故障发生的具体时段 | 判断是否为高峰拥塞 |
| 影响范围（单业务/全网/单终端） | 判断是否链路问题 |
| 当时的出口带宽利用率 | 判断是否容量问题 |
| 当时的会话数与 CPU | 判断是否设备规格问题 |
\n
若丢包只出现在固定时段且与出口利用率曲线吻合，方向是容量而不是链路质量；若全天随机出现且与利用率无关，方向是链路物理层或运营商侧。
\n
\n
六、处理动作与回退
\n
| 原因 | 处理 | 验证 |
|---|---|---|
| 内网泛洪 | 按 T02/T03 处理 | 内网侧丢包消失 |
| 光衰/误码 | 清洁法兰头、更换尾纤或光模块 | 端口错误计数停止增长 |
| MTU 不匹配 | 调整出口 MSS/MTU（PPPoE 场景常见） | 大包带 -f 测试通过 |
| 容量不足 | 按峰值复核带宽规格并扩容 | 高峰利用率留有余量 |
| 双线切换 | 核对切换策略与告警阈值 | 切换时间与日志对齐 |
| 运营商侧 | 提交工单并附完整取证 | 运营商回单后复测 |
\n
提工单材料清单：故障时段、源目 IP、MTR 报告（含 -c 100 以上包数）、ping 统计截图、内网侧自检结论（已排除内网的说明）、光模块收发光功率。
\n
\n
七、避坑小结
\n
- \n
- 中间跳丢包不等于故障，要区分 ICMP 限速与真实丢包；
- 一次 ping 不能当结论，抖动的判据是多次采样的分布；
- 只测公网 DNS 不够，要测实际业务地址；
- 先排除内网再报障，否则工单会在来回确认中消耗时间；
- 取证要留原始数据，包括命令与时间戳，便于复现与对比。
\n
\n
\n
\n
\n
\n
速查表：丢包与时延
\n
| 现象 | 优先动作 |
|---|---|
| ping 网关就丢包 | 内网无线/交换侧排查 |
| 大包不通小包通 | MTU/分片与 MSS |
| 高峰时段抖动 | 带宽利用率与容量 |
| 全天随机丢包 | 光模块/链路物理层 |
| 仅最后一跳丢包 | 改业务层测试确认 |
| 切换瞬间丢包 | 核对主备切换日志 |
\n
\n\n
常见问题（FAQ）
\n
Q：ping 有丢包是不是一定线路有问题？
\n
A：不一定。要分位置看：ping 内网网关就丢包，属于内网问题；中间跳丢包但后续跳正常，多为该设备对 ICMP 限速；只有最后一跳丢包，多为对端限制 ICMP，需要用实际业务（打开业务系统、发起请求）来验证。真正需要报障的判据是：从某一跳开始持续丢包，且之后各跳都受影响。
\n
Q：MTR 报告要跑多少包才有说服力？
\n
A：一般不少于 100 包，抖动类问题建议 200 包以上并分多个时段采样。包数太少时偶然丢包会被放大，无法区分随机丢包与持续丢包。提交运营商工单时，附上不同时段的两到三份报告更有说服力。
\n
Q：视频会议卡顿但下载正常，是带宽不够吗？
\n
A：不一定。视频会议对时延与抖动的敏感度高，对带宽的敏感度相对低。若下载能跑满带宽而会议卡顿，方向应是抖动与丢包，而不是总带宽。建议按本文做分段 MTR，并结合会议软件自带的网络质量统计（时延、抖动、丢包）一起判断。
\n
本文由 58120 智能网络 原创发布。转载请注明出处并保留原文链接。
评论 0
还没有评论，来抢沙发吧。