链路训练失败的现象识别：你该盯紧哪些信号？

链路训练失败，说白了就是网口两边的设备在「握手」的时候谈崩了。握手没握好，数据传起来自然就磕磕绊绊。这一节我们专门来聊聊，当链路训练出问题时，你会看到哪些异常现象。

我带了这么多年数据中心的网络，可以很负责地告诉你：链路训练失败的早期信号，往往并不显眼。可能就是某个接口偶尔丢一个包，或者某个业务突然卡了那么几秒。很多人会忽略，觉得「哎呀偶然现象」。嗯，但等它发展成大规模丢包甚至业务中断，那就晚了。

现象一：丢包率升高

这是最直接的表现。链路训练失败后，两端的物理层握手没对齐，数据帧在传输过程中就会出现错位、CRC 校验失败，最终被丢弃。

我个人习惯用 ping 先做一轮快速验证。但注意了，普通的 ping 不一定能暴露问题。我建议你用连续的大包去压：

# 用大包、连续发、看丢包率
ping -l 1472 -n 1000 192.168.1.1

# 如果有丢包，再看连续丢包的个数
ping -l 1472 -n 10000 192.168.1.1 | find "Lost"

通常来说，链路训练失败导致的丢包，并不像线缆损坏那样持续稳定。它的特点是「一阵一阵的」。你可能连续跑 1000 个包一个不丢，但下一秒突然连续丢 5~10 个。为什么会这样？因为两端的链路训练在反复尝试、失败、回退、再尝试。

现象二：接口 flapping

接口 flapping 就是端口的状态在 UP 和 DOWN 之间反复跳动。你可以在交换机上看到类似这样的日志：

%LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to down
%LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/1, changed state to down

你想想看，接口一会儿通一会儿断，业务能稳住才怪。我记得有一次在数据中心做割接，一个核心交换机接口每隔 2~3 分钟就 flap 一次，业务那边直接炸了。我查了整整一个下午，最后发现就是一块老旧的千兆光模块在训练时死活稳不住。

这里要区分两种情况：

• 物理层 UP 但协议层 DOWN： 这就是典型的链路训练失败。物理信号能通，但握手对不上。
• 物理层和协议层一起 DOWN： 这可能是线缆断了或者光模块坏了，属于硬件故障。

现象三：协商降速

链路训练失败后，两个设备可能会自动协商到一个更低的速度。比如你的网卡是千兆（1000M），路由器也是千兆，但最终实际协商成百兆（100M）甚至十兆（10M）。在交换机上用 show interface 一看，速度不对了。

Router# show interfaces GigabitEthernet0/1
GigabitEthernet0/1 is up, line protocol is up
  Hardware is CN Gigabit Ethernet, address is xxxx.xxxx.xxxx
  Description: To Core Switch
  MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  **Auto-duplex, 100Mb/s, 100BaseTX/FX**

看到 100Mb/s 了吗？两个千兆口，最后只有百兆。这就是链路训练失败最常见的妥协方案——两边放弃高规格，退回到低速度保证能用。

我遇到过一个典型的场景：机房巡检时发现一台服务器的文件拷贝速度从正常的 110MB/s 掉到了 11MB/s。一查接口，果然协商成了百兆。问了一圈，原来是昨天晚上机柜挪动，光纤被弯折了一下，链路训练失败后直接降速了。

所以我的建议是：别只看接口状态是 UP 就觉得万事大吉。一定要确认协商速度。我每次巡检必做的一件事，就是写脚本批量检查所有千兆接口的实际协商速度，只要发现有降速的，直接定位到具体链路排查。

现象四：连接超时

如果说丢包是「偶尔断一下」，那连接超时就是在链路训练彻底失败的情况下，握手完全拖垮了数据传输。表现在业务层面就是：TCP 会话频繁超时、HTTP 请求卡死、数据库连接报「Connection timed out」。

这种场景通常发生在链路训练双方都没有成功回退到低速模式的时候。比如两端都强制写死了千兆全双工，但物理层又无法完成训练。设备会一遍又一遍地尝试训练，直到超时然后报错。

我记得有一次在数据中心排障，应用方一直报「连接到数据库超时」。我一看网络，ping 核心网关倒是通的，但延迟高得离谱，平均 500ms 以上。用 Wireshark 抓包发现，TCP 的 SYN 包发出去后，对端要等 10 多秒才回 SYN-ACK。原因就是链路训练失败导致每个包都要在物理层反复重传。

下面这张图可以帮你快速理解链路训练失败的四种现象以及它们之间的内在联系：

在实际排障中，这四种现象往往不是孤立出现的。丢包率升高可能先来，然后接口开始 flap，最后直接超时。但也可能直接跳过了某个阶段。所以我建议你每次遇到网络异常，先看接口状态和协商速度，再看日志里有没有 flapping 记录，最后抓包确认丢包和超时的具体模式。