深夜网络中断：光纤衰耗大 + 端口误差导致的丢包案例复盘

一、 故障背景：那个不平静的凌晨

凌晨 2:15，运维组的值班电话准时响起（好像故障总是喜欢挑这个时候）。监控平台告警显示：核心机房至汇聚节点 B 的上行链路中断，链路状态为 Down。

该链路承载着几个重要的业务系统。虽然链路有冗余备份，但由于备份链路带宽较小，此时业务流量已经出现拥塞，部分用户反馈系统卡顿。

作为当班工程师，我迅速远程登录到核心交换机进行排查，一场与时间的赛跑开始了。

二、 排查过程：抽丝剥茧

1. 第一层排查：物理链路“看起来”是通的

登录核心交换机（Switch-Core），查看端口状态：

 display interface GigabitEthernet 0/0/1 GigabitEthernet0/0/1 current state : UP Line protocol current state : UP ... Input:  12345678 packets, 987654321 bytes         5000 errors, 3000 CRC Output: 87654321 packets, 123456789 bytes         0 errors, 0 collisions

奇怪的现象出现了：
端口物理状态是 UP，协议也是 UP。也就是说，路由层面认为链路是通的。但是，我注意到 Input errors 和 CRC 错误计数在持续快速增长。

此时 Ping 对端设备 IP，结果如下：

 ping 192.168.10.2   PING 192.168.10.2: 56  data bytes, press CTRL_C to break     Reply from 192.168.10.2: bytes=56 Sequence=1 ttl=255 time=25ms     Request time out     Reply from 192.168.10.2: bytes=56 Sequence=3 ttl=255 time=35ms     Request time out

丢包率高达 40%，且延时不稳定。这显然不是简单的路由问题，而是典型的二层物理层损伤。

2. 第二层排查：光纤衰耗的“隐形杀手”

既然有 CRC 错误，首先怀疑光路问题。我们这是一条 10km 的单模光纤，中间经过多个跳线架。

查看光模块收发光功率：

 display transceiver interface GigabitEthernet 0/0/1 verbose ...   Rx Power(dBm)  : -23.5   Tx Power(dBm)  : -3.2

查看光模块规格书，该模块（10km SFP）的接收灵敏度通常在 -20dBm 左右，过载点约 -3dBm。
当前接收光功率为 -23.5dBm，低于灵敏度阈值！

初步结论：光路衰耗过大，导致光信号太弱，接收端无法正确解码，从而产生 CRC 错误。

于是，我连夜联系了驻守机房的同事，让他带着红光笔和光功率计去现场。

3. 第三层排查：光纤修好了，故障却没消失

同事到达汇聚节点 B 后，按照我的指示：

1. 清洁光纤接头： 用无水酒精擦拭端面，光功率没有明显回升。

2. 排查跳线： 发现机房内有一段跳线被机柜门压住了，且弯曲半径过小。更换备用跳线并理顺光路后。

3. 复测光功率： 此时核心交换机侧的 Rx Power 上升到了 -12dBm，这已经是一个非常好的数值，完全在正常范围内。

我以为故障结束了。然而，重新查看端口状态时，令人崩溃的一幕发生了：

 display interface GigabitEthernet 0/0/1 ... Input:  ... 500 errors (计数仍在增加)

光路已经正常了，为什么误码还在增加？

4. 第四层排查：被忽视的“端口误差”

此时已经是凌晨 3:30。既然光路没问题，那问题只能出在“电”或者“逻辑”层面——也就是交换机端口或光模块本身。

我尝试在核心交换机上执行 shutdown / undo shutdown（重启端口），甚至更换了一个备用的光模块，但错误计数依然在 Ping 测试时疯涨。

冷静下来分析：

• CRC 错误通常源于物理层干扰。

• 光路正常。

• 模块正常。

• 那剩下的可能性只有：端口速率/双工模式协商问题，或者 物理接口老化导致的信号失真。

我检查了两端的配置：

• 核心端：speed 1000，duplex full（强制千兆全双工）。

• 汇聚端：speed auto，duplex auto（自适应）。

这就是问题所在！

虽然现代设备大多能很好地处理速率强制与自适应的混用，但在某些老旧设备或特定硬件版本上，这种“强制 vs 自适应”的配置差异，会导致对端协商失败或处于半双工状态，或者导致时钟同步出现微小偏差，进而引发帧校验错误（FCS/CRC）。

为了验证，我立刻修改汇聚端配置，强制指定速率和双工模式：

[Switch-B] interface GigabitEthernet 0/0/1 [Switch-B-GigabitEthernet0/0/1] speed 1000 [Switch-B-GigabitEthernet0/0/1] duplex full

配置生效后，我清除了接口统计计数，并开始长 Ping 测试。

 reset counters interface GigabitEthernet 0/0/1  ping -c 1000 192.168.10.2   --- 192.168.10.2 ping statistics ---   1000 packets transmitted, 1000 received, 0% packet loss

0% 丢包！ 再次查看接口统计，Input errors 计数不再增长。

此时时间指向凌晨 4:10，故障彻底解决。

三、 根因复盘与经验总结

这次故障并非单一原因造成，而是典型的“复合型故障”。

1. 故障链条还原

1. 光纤衰耗大（主因）： 光纤跳线受损导致光功率逼近临界值，这是导致最初大量丢包和链路震荡的直接原因。

2. 端口协商配置错误（次因）： 长期存在的配置不规范（一端强制、一端自适应）。平时可能勉强工作，但在光路恢复、信号重组的过程中，这种隐性的配置冲突被放大，导致持续性的误码。

2. 经验教训

• 光功率不仅要看“通不通”，更要看“稳不稳”：
  不要只满足于 UP 状态。日常巡检中，Rx Power 应该至少保留 3-5dBm 的余量。本例中 -23.5dBm 虽然偶尔能通，但极其脆弱。

• 双工模式不匹配是 CRC 错误的元凶之一：
  当发现大量 CRC 错误且排除了光路问题后，第一时间检查双工模式配置。最佳实践是：两端要么都自适应，要么都强制。永远不要一边强制一边自适应。

• 排查思路要闭环：
  很多工程师修好光纤后就走了，忽略了后续的验证。验证的标准不是“光功率达标”，而是“误码率归零”和“业务恢复”。

四、 后续改进措施

1. 配置规范化： 下周将对全网核心互联端口进行配置核查，统一改为“双方强制 1000M/Full”或“双方 Auto”。

2. 监控细化： 调整 Zabbix 监控策略，增加 Input Errors 和 CRC Errors 的阈值告警（>10个/分钟即告警），而不是等到链路 Down 才报警。

3. 文档记录： 将此次光纤衰耗测试数据记录进资产表，对老化光纤线路列入整改计划。

*这次深夜排障虽然过程曲折，但也再次印证了那句老话：网络工程，最后拼的都是物理层。*

*(本文涉及设备型号及IP已做脱敏处理)*