链路聚合明明配好了却不通？99% 是这个细节没搞对

整理：老杨丨11年资深网络工程师，更多网工提升干货，请关注公众号：网络工程师俱乐部

你是不是也有过这样怀疑人生的瞬间……

• Eth-Trunk 配好了，两边状态都是 UP
• display eth-trunk 一切正常
• 但设备之间根本通信不了
• 甚至都能看到 ARP 学习了，但业务走不通
• 改回单链路立马就好

说实话，这种链路聚合的问题不比 ACL 简单，踩一次能查一天。

其实80% 问题都集中在 3 个关键细节。

1. LACP 协议没协商成功，链路只是“假通”

你看着接口是 UP 的，其实 LACP 协议根本没协商成功，设备只是把接口状态提起来了而已，聚合根本没生效。

常见表现：

• display eth-trunk 状态是 up，但成员接口状态是 Unselected
• display lacp peer 根本查不到邻居
• 抓包没看到 LACP 报文（UDP 端口 8809）

原因有哪些？

• 对端接口没开启 LACP，结果你一边是动态聚合，另一边当你不存在
• 接口协商模式不一致（active vs passive）
• 某一边用了静态模式，另一边用了动态 LACP

正确姿势：

两边都要一致：

interface Eth-Trunk1
 mode lacp

成员接口这样配置：

interface GigabitEthernet0/0/1
 eth-trunk 1
 mode lacp

建议模式用主动协商：

lacp mode active

别一边是 LACP，另一边是静态聚合，根本协不起来！

ps.LACP属于公有协议，只要LACPDU报文一致，设备厂商就能够对接支持LACP设备。不同厂商LACP模式链路聚合对接情况如下表：

2. 接口参数不一致，导致成员口被踢出聚合组

链路聚合讲究“完全一致”：速率、双工、VLAN、MTU、STP 状态，甚至一些奇怪的接口默认值，只要有一点点不同，成员接口就会被系统踢出。

重点看这几项：

用命令排查：

display eth-trunk 1 verbose

看到某接口是“Unselected”，说明它已经被聚合逻辑踢出去了，继续用那口通信必挂。

3. Hash 策略不一致，导致负载均衡异常或单向不通

链路聚合不是“多条链路全混着跑”，它靠 hash 算法 把流量分到不同链路上。

但如果两边算法不一致（比如一边按源 IP，另一边按目的 MAC），就可能出现“单向不通”、“部分业务断”、“某些 IP 一直走一条链路”等问题。

建议做法：

确认两端设备的 hash 策略统一，比如：

# 华为
load-balance src-dst-mac

或者：

load-balance src-dst-ip

适用业务建议：

4. 某一根链有环或死链，业务正好被 hash 到这条上

这个太隐蔽了！

你配置了 4 条物理链路聚合，但其中有一条中间其实断了、或者接了错误设备，导致形成黑洞。

而 hash 算法刚好把某些 IP/端口 hash 到这条链路上，于是：

• ping 有时通有时不通
• curl 能连首页但登录失败
• 某业务节点死活打不通

怎么定位？

• 用 display eth-trunk statistics 看每条链路流量，有一条没流量的就是可疑的
• 用 traceroute 带固定源端口测试不同 hash 条件
• 把怀疑链路 disable 掉再试，看业务是否恢复

5. STP、防环、MAC抖动，聚合上联之后“反而不稳定”

很多人做链路聚合是为了“高可用 + 提速”，但聚合做完之后发现：

• 接入设备老掉线
• 交换机日志提示 MAC 动态切换频繁
• ARP 表跳来跳去
• STP 状态来回变化

其实这不是聚合的问题，而是：你没把原先防环逻辑升级成聚合逻辑，结果系统反复误判。

推荐做法：

• 聚合之后，成员口关闭 STP，统一在 trunk 上层管理
• 注意接入设备是否支持 LACP，否则建议用静态聚合
• 华为设备建议开启 mac-address flapping detect 定位问题

总结一波：链路聚合不通，重点查这 5 个点

原创：老杨丨11年资深网络工程师，更多网工提升干货，请关注公众号：网络工程师俱乐部