问题背景

公司数据中心采用 Spine-Leaf 架构，核心层由两台华为 CE12800 组成集群，汇聚层为 CE6800，核心与汇聚之间通过 2 条 10G 光纤链路做 LACP 链路聚合，逻辑带宽 20Gbps。汇聚下联 40 台物理服务器，承载微服务集群。

故障现象

上午 10:00，运维监控突然发出多条告警：多个微服务实例的连接池耗尽，Nginx 日志中 upstream timed out 错误激增。服务器之间 ping 延迟从 <1ms 飙升到 15ms-30ms，但未出现完全断网。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# 核心交换机上查看聚合组状态
[CE12800] display eth-trunk 10
Eth-Trunk10's state information is:
WorkingMode: NORMAL
LAG ID: 10
Operating Status: down      # 一条成员口 down！
...
Member Port Status:
GigabitEthernet1/0/1: Up    (Selected)
GigabitEthernet1/0/2: Down  (Unselected)

链路聚合组（Eth-Trunk）中 G1/0/2 状态为 Down/Unselected——20G 聚合组只剩一条链路在工作，带宽减半。业务高峰期的流量（峰值约 14Gbps）超过单链路 10Gbps 容量，导致拥塞丢包。

排查过程

第一步：物理层排查

1
2
3
4
5
6

[CE12800] display interface gigabitethernet 1/0/2
GigabitEthernet1/0/2 current state: UP
Line protocol current state: UP
...
Last physical up time: 2023-02-05 09:58:21   # 今天刚up过
Last physical down time: 2023-02-05 09:47:15  # 9:47掉线

端口物理层 UP，光功率正常：

1
2
3

[CE12800] display transceiver interface gigabitethernet 1/0/2
RX Power(dBM): -5.21   # 正常范围 -1 ~ -10
TX Power(dBM): -2.35   # 正常

物理层没有问题。

第二步：检查 LACP 协商日志

1
2
3
4
5
6

[CE12800] display lacp statistics eth-trunk 10
Port: GigabitEthernet1/0/2
  LACPDUs Sent: 0          # 未发送任何LACPDU！
  LACPDUs Received: 4852
  Marker Sent: 0
  Marker Received: 0

本端收到了对端发来的 LACPDU 包（4852 个），但本端一条 LACPDU 都没发送——说明本端压根没有启动 LACP 协商。

1
2
3
4
5

[CE12800] display eth-trunk 10 verbose | include "Actor|Partner|System"
Actor System ID: 0x8000, 00e0-fc12-3456
Partner System ID: 0x8000, 00e0-fc65-4321
Actor System Priority: 32768
Partner System Priority: 32768

对端的 System ID 是本端完全不认识的 MAC——汇聚交换机不是被换过主控板，就是这条光纤插到了另一台设备上。

第三步：追踪物理链路

登录汇聚交换机 CE6800 检查：

1
2

[CE6800] display interface gigabitethernet 1/0/24
Description: TO-CORE-01-G1/0/2

光模块信息显示型号是 SFP-10G-SR（多模，850nm），但核心交换机这一端的型号是 SFP-10G-LR（单模，1310nm）。两个模块的波长和光纤类型完全不匹配！

进一步追溯变更记录：前天晚上有人更换了 CE6800 侧的故障光模块，但使用了库存中型号不匹配的备件——应该装 SFP-10G-LR，却装了一支 SFP-10G-SR。

两端的物理层其实都是 UP：核心端看到了 1310nm 波长的光（来自汇聚端原装 LR 模块的漏光），汇聚端看到了 850nm 波长的光（来自核心端 LR 模块的漏光），所以接口显示物理 UP，但实际上两端根本不是同步通信——只能在极低速率下看到对方的 LACPDU 包却无法正常协商。

解决方案

1. 更换正确光模块：将 CE6800 侧的 SFP-10G-SR 更换为 SFP-10G-LR，接口短暂 down/up 后 LACP 自动协商成功。
2. 验证聚合带宽：

1
2
3
4

[CE12800] display eth-trunk 10
Member Port Status:
GigabitEthernet1/0/1: Up (Selected)
GigabitEthernet1/0/2: Up (Selected)   # 恢复

3. 业务流量恢复，延迟回落到正常水平。

根因分析

直接原因：备件管理中光模块型号混用——SFP-10G-SR（多模短距）替换了 SFP-10G-LR（单模长距），波长和光纤类型不匹配，导致 LACP 协商数据包只能勉强到达但无法完成协议握手。

深层原因：

• 备件仓库光模块未按型号分库存放和标识
• 更换流程中没有"更换前验证型号、更换后验证链路聚合状态"的标准化步骤
• 缺少光模块插入后的自动型号校验告警

预防措施

1. 光模块备件管理：所有备件按型号独立存放，标签标注类型、波长、适用场景
2. 更换 SOP：光模块更换必须包含"更换前拍照记录型号 → 更换后验证 eth-trunk 状态"两步
3. 交换机告警规则：新增"Eth-Trunk 成员口状态变更"告警，成员口 Down/Unselect 立即通知
4. 光模块数字诊断：定期通过 display transceiver 收集全量光模块的型号、序列号，生成资产清单
5. 备件定期盘点：每季度盘点光模块备件，清点型号和数量

总结

链路聚合故障的排查往往最先关注的是协议配置、系统版本、电缆质量，很少人会第一时间想到——光模块型号。但这次就是典型的物理层欺骗：两个波长不对的光模块硬生生点亮了对方的端口状态灯（因为确实检测到了光），让运维在第一轮排查时排除了物理层故障的可能性。在数据中心环境中，光模块型号的严格管理不是矫情，是底线。