一个 Received LACP Packets: 0，对面改完协议我才下班

大家好，我是老张。

前几天碰到一个 LACP 链路聚合的案例，故障本身不复杂，但排查过程中学到两个挺有意思的点，分享一下。

事情很简单：两台汇聚交换机和一台防火墙做双口 LACP 链路聚合，配置完成后一查，只有一口正常，另一口是 Unselected。

第一阶段：交换机侧排查

先看聚合口状态：

display link-aggregation verbose Route-Aggregation 13

结果一出来就发现问题了：

WGE1/0/13(R)  S  {ACDEFG}    ← 正常
WGE2/0/13     U  {ACG}       ← 未选中，缺 DEF

注意右边的 Flag，WGE2/0/13 只有 ACG，缺了 D（Synchronization）、E（Collecting）、F（Distributing）——这三个 Flag 意味着端口虽然加入了聚合组，但没有和对面完成协商。

再看看 Remote 对端信息：

Remote:
  WGE1/0/13  0000-0000-0000  {DEF}
  WGE2/0/13  0000-0000-0000  {DEF}

全显示 0000-0000-0000，对端的 MAC 地址都没拿到。这不像正常 LACP 协商的状态。

交换机这边还能查什么？物理口状态、光模块、错误统计、LACP 报文收发：

display interface Twenty-FiveGigE2/0/13
# Current state: UP，物理层正常

display interface Twenty-FiveGigE2/0/13 | include error|drop|crc
# 全 0，链路质量没问题

display link-aggregation member-port WGE2/0/13

第二条命令的输出是关键：

Received LACP Packets: 0 packet(s)
Sent LACP Packets: 65 packet(s)

WGE2/0/13 发出去了 65 个 LACPDU，但一个都没收到回复。

我们交换机能查的都查了：物理层 UP、链路 0 error、LACPDU 已发出。如果是交换机的问题，要么 LACPDU 发不出去，要么收到但校验不过——现在是反过来，对面根本不理。

到这里基本能下结论了：交换机侧没问题，找防火墙厂商查。

第二阶段：对面改完就好

反馈过去之后，对面把防火墙的聚合协议从静态改成了动态 LACP，一切恢复正常：

WGE1/0/13  S  {ACDEF}
WGE2/0/13  S  {ACDEF}    ← 已选中！

Remote:
  WGE1/0/13  xxxx-xxxx-xxxx  {ACDEF}   ← 对端 MAC 已识别
  WGE2/0/13  xxxx-xxxx-xxxx  {ACDEF}

WGE1 Received LACP: 15,  WGE2 Received LACP: 15    ← 双向收包正常
display interface Route-Aggregation 13
# Bandwidth: 20000000 kbps（20G）

根因一句话：防火墙侧配的是静态链路聚合，交换机是 dynamic LACP，两边协议不匹配。

💡 记笔记：Received LACP Packets: 0 = 对端问题

这个案例可以提炼成一个简单判断逻辑：

display link-aggregation member-port <端口> | grep Received

Received LACP Packets: 0       → 对端问题，查对面
Received LACP Packets: > 0     → 两边都在发包，查 Flag 协商状态

以后再配 LACP 聚合，配完先跑这条命令看一眼，如果某个口的 Received 是 0，基本不需要在自己这边折腾了，直接联系对面厂商。

🔧 顺手踩坑：25GE 端口组速率联动

配置过程中还有个有意思的细节。25GE 口设 speed 的时候：

[交换机]speed 10000
This command will take effect on Twenty-FiveGigE1/0/13 to Twenty-FiveGigE1/0/16,
which belong to a port group. Continue? [Y/N]:

改一个口的速度，提示会影响 4 个口。为什么？

H3C 的 25GE 口在 ASIC 芯片层面 4 口共享一组 SerDes + PLL 时钟源，所以硬件层面做不到组内每个口独立设不同速率：

┌────────────────────────────────┐
│        ASIC 芯片               │
│  ┌──────────────────────────┐  │
│  │  SerDes 组 (13~16)       │  │
│  │  共享 PLL 时钟           │  │
│  │  速率：全 10G 或 全 25G  │  │
│  └──────────────────────────┘  │
│  ┌──────────────────────────┐  │
│  │  SerDes 组 (17~20)       │  │
│  └──────────────────────────┘  │
└────────────────────────────────┘

这个设计意味着：如果将来 14~16 口需要 25G，13 口也会被联动拉上去。如果 13 口对端设备不支持 25G（比如这次防火墙协商的是 10G），那就冲突了。

实际的生产影响是：这组 4 个口最好统一规划速率，不要混用不同速率的设备。

总结

知识点	一句话
LACP 排查	`Received LACP Packets: 0` = 对端问题
跨厂商对接	先确认两边聚合模式一致（dynamic/static）
端口组	25GE 口 4 个一组共享 SerDes，速率统一
实用命令	`display link-aggregation member-port` 看 LACPDU 收发

两个排查经验都不复杂，但知道之后能省不少时间——以后遇到类似情况，5 分钟就能定位，不用像这次来回折腾。

💬 互动话题

你遇到过最坑的跨厂商对接是哪两个设备？最后怎么解决的？
端口组速率联动这个设计，你觉得是合理还是反人类？
除了 LACP 聚合，还有哪些协议对接时容易栽在模式不匹配上？

欢迎留言聊聊。我是老张，下期见。