专线那点“疑似故障”，九成以上用 ping、tracert（或 mtr）、telnet 这三类基础命令，再配合接口计数器，就能判断问题卡在自家 CE 设备、运营商 PE 网络，还是对端业务系统，不用一上来就抓包或者急着报障。
机房监控半夜告警，业务方说“专线断了”，电话打过来时你手上只有一台笔记本和一条能登录设备的跳板，这时候最该做的不是打开抓包工具，而是按顺序敲几条命令，把“不通”拆成“哪一段不通”。
专线链路不通怎么排查？先分清“断”和“慢”
同样是报故障，现象完全不是一回事，业内习惯先归成三类,每类对应不同的命令组合。
三类现象，三套起手式
- 完全不通：ping 目标地址 100% 丢包，业务全停，先 ping 本地网关，再 ping 对端 CE,判断责任边界。
- 间歇丢包：能通，但延迟忽高忽低、丢包率飘，用 mtr 持续探测,看丢包从第几跳开始。
- 能通但业务慢：ping 正常，应用卡顿，重点查 MTU、TCP 端口可达性、带宽是否被打满。
| 现象 | 首选命令 | 关键判读点 |
|---|---|---|
| 完全不通 | ping 网关、ping 对端CE |
网关是否可达，决定责任在谁 |
| 间歇丢包 | mtr -r -c 100 目标IP |
从哪一跳开始丢，后续跳是否延续 |
| 能通但慢 | ping -l 1472 -f、telnet IP 端口 |
MTU 黑洞或应用层阻塞 |
动手前的三个准备
- 确认测试源在链路哪一侧,别拿公网出口去测专线。
- 记下电路编号、两端设备型号、互联 IP,报障时能省一半沟通时间。
- 有些设备默认禁 ICMP，先确认对端没做限制，别把“禁 ping”误判成“断链”。
从 ping 开始：三分钟判断链路通不通
ping 谁都会敲，但参数用不对,结论就会跑偏。
三个参数决定测试有效性
-t（Windows）/ 持续模式：观察长周期抖动,而不是看一次结果。-n 100/-c 100：样本太少没意义,几十个包才能看出丢包规律。-l 1472 -f：测路径 MTU，专线最常见的“能 ping 通但网页打不开”多半卡在这。
Linux 下对应 ping -c 100 -s 1472 -M do 目标IP；Windows 用 -l 1472 -f，返回“需要拆分数据包但已设置 DF”就说明路径 MTU 小于 1500。
延迟和丢包怎么读
同城专线往返延迟通常在个位数毫秒，跨省视距离而定，真正有价值的不是绝对值，而是稳定性：
- 丢包 0、延迟曲线平直,链路层基本可以排除。
- 丢包 0 但延迟周期性抬升,查带宽利用率和队列拥塞。
- 丢包集中在固定时段,对照业务高峰看是不是链路被打满。
先 ping 网关，这一步定责任
这是最省事的分诊动作，ping 不通自己的网关，问题在本地设备、跳线、光模块或本地环路；网关通、对端不通，才轮到运营商网络和对端设备，很多扯皮半天的工单,用这一条命令就能定性。
tracert 和 mtr 有什么区别？定位断点在第几跳
tracert 的用法和局限
tracert -d 目标IP（-d 不解析域名，速度快很多），看的是数据包从哪一跳之后开始全部超时，但中间跳不响应 ICMP 非常普遍，骨干设备普遍对 ICMP 限速，所以中间某一跳超时，不等于故障点在那一跳。
mtr 的持续观测价值
mtr -r -c 100 -n 目标IP 把 tracert 和 ping 合在一起，输出每一跳的丢包率,判断规则很明确：
- 某一跳开始丢包，并且后面所有跳都在丢,这一跳才是真凶。
- 只有单跳丢包，后续跳恢复正常，那是该设备的 ICMP 限速,忽略即可。
这个区别是排查专线时最容易被误读的地方,也是很多工单描述失真的原因。
双向测试才算数
专线去程和回程路由经常不对称，像上海、苏州这类制造业分支密集的区域，一条跨省专线可能经过多家运营商落地设备，回程绕路很常见，只在本地做 tracert，看到的可能只是一半的路径，正确做法是两端同时向对方打 mtr,对比两份结果。
跨省专线丢包怎么诊断？分段打点做证据链
跨省场景下，链路上设备多、责任方多，光靠一次 ping 说不清，得把链路切成段,逐段留证据。
分段测试的基本路径
沿着 CE → 本地 PE → 骨干 → 对端 PE → 对端 CE 的顺序，用每一段的下一跳地址逐段 ping 和 mtr，哪一段开始出现稳定丢包，就把问题锁定在那一段，这个动作不需要任何高级工具,一台能登录设备的终端就够。
接口计数器比 ping 更早发现问题
登录设备敲 show interface（华为设备用 display interface）,重点看几个字段：
- input errors / CRC：持续增长基本指向物理层，光衰偏大、跳线端面脏、单纤收发不平衡都可能。
- giants / runts：帧长异常，常见于 MTU 不一致或双工不匹配。
- drops：队列溢出，说明带宽真的不够,不是链路坏了。
光功率也要看，show interfaces transceiver 或 display transceiver diagnosis，收光功率贴着模块灵敏度下限走,链路就会时好时坏。
带宽打满和链路故障是两回事
业务高峰丢包、低谷正常，八成是带宽跑满了，加带宽或者做 QoS 限流就能解决，这类问题报给运营商会被告知“链路正常”,因为链路确实正常。
链路通但业务不通，命令往下走一层
ping 全通、业务报错,问题在四层以上。
端口和 TCP 层测试
- Windows：
telnet 目标IP 端口，或Test-NetConnection -ComputerName IP -Port 端口。 - Linux：
nc -zv 目标IP 端口，curl -v看握手卡在哪一步。
SYN 发出去没有任何回应，一般是中间 ACL 或防火墙拦了；返回 RST，说明对端端口没监听,责任在对端系统。
路由和 ARP 别跳过
show ip route 目标网段 确认出接口和下一跳是否正确；display ip routing-table 同理，同网段不通时看 ARP 表，学不到 MAC 地址就是二层问题,跟专线本身没关系。
什么时候找运营商，什么时候自己先动手
企业专线故障排查要花钱请人吗
多数情况下不需要，ping、tracert、mtr、接口计数器这套组合已经能定位到“哪一段”，外部服务的价值主要体现在需要现场仪表的场景OTDR 测光纤断点、光功率计测收光、协议分析仪做深度抓包，这类工作按次收费，价格从几百到上千不等，具体看城市和服务商，但只要你能把范围缩到“某一段光纤”，这笔钱往往也可以省下来,直接交给运营商处理。
报障时怎么说才有效
给三样东西：源 IP、目标 IP、带时间戳的 mtr 完整输出，业内专家指出，附带探测数据的工单，在运营商侧的分派和处理路径会明显不同,因为一线工程师可以直接据此判断是接入段还是骨干段。
几个容易踩的误区
行业共识认为，专线排障的多数返工来自操作习惯而非技术难度,常见的坑有这么几个：
- 用大包持续压测代替诊断,把好好的链路测出告警。
- 只看 ping 通不通,忽略延迟抖动和丢包率。
- 单端测试就下结论,忽略回程路径。
- 拿公网 tracert 结果去判断专线质量,测试源根本不在同一条链路上。
关于基础命令做专线链路诊断的常见问答
ping 通但有丢包，能直接判定是运营商的问题吗
不能，要先看丢包位置：本地到网关就丢，问题在本地设备或接入线路；网关正常、越过某一跳后开始丢，才指向运营商网络，另外确认测试时段是否与业务高峰重合,带宽拥塞造成的丢包不属于链路故障。
mtr 显示某一跳丢包比例较高，是不是这一跳坏了
大概率不是，判断标准是丢包是否延续到后续跳，只有后续跳同样丢包，该节点才可疑；若仅该跳丢包、后续正常，通常是设备对 ICMP 做了限速，属正常现象,不影响业务转发。
专线链路诊断一定要抓包吗
不需要，ping 判断连通性、tracert 和 mtr 定位断点、接口计数器判断物理层健康度、telnet 验证端口可达性，这四步能覆盖绝大多数专线故障场景，抓包一般只在应用层协议异常、且已确认链路和端口都正常时才用得上。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/788420.html
