芙蓉塘外有轻雷前几天在机房处理一个故障，一台服务器双网卡接两台上联交换机，业务高峰时丢包严重。我过去一看，兄弟把两条网线都插上了，但没做任何绑定，交换侧也没做聚合处理，结果两条链路同时工作还互刷广播，交换机直接告警环路。这其实是个很典型的场景：明明可以靠交换机的二层链路聚合解决问题，不少同行还是会绕远路。
二层链路聚合，在华为设备上通常就叫 Eth-Trunk。它的核心逻辑很简单：把两台交换机之间、或者交换机与服务器之间的多条物理链路，捆绑成一条逻辑链路。对外是一个逻辑接口，对内是多条成员链路同时转发，既能提升带宽，又能实现链路冗余，还能避开生成树协议对冗余链路的阻塞。这篇文章就围绕华为设备，把二层链路聚合的原理、配置、验证和排错讲透。适合刚接触园区网配置的工程师，也适合在运维过程中被链路聚合坑过一次但又没完全搞懂的同行。
1. 什么时候真的需要一层二层链路聚合：业务场景与取舍
1.1 先从一次“假双链”故障说起
我前面提到的那个故障，服务器上明明插了两根网线，为什么反而出问题？因为交换机的物理接口在没有聚合时，默认都会被生成树协议(STP)纳管。两条物理路径一旦构成环路，STP会阻塞其中一条，另一条正常转发。但服务器侧的网卡驱动如果做了主动负载均衡，或者干脆把两个口都配置成“活的”，交换机的STP判断和服务器网卡的转发逻辑就会打架。结果就是广播风暴、MAC地址漂移，业务呈现“时通时断”的状态。
如果当时用二层链路聚合，把服务器两个网卡和交换机两个接口绑定成一个Eth-Trunk，情况就完全不同。流量会按照负载分担算法分散到两条链路上，而且任何一条链路断开，另一条还能继续承载全部流量。这个道理放在交换机到交换机之间更常见：两栋楼之间、两级核心之间，往往要跑好几条光纤，如果不做聚合，带宽叠加不了，冗余也做不了。
1.2 “带宽不够”不一定就要换设备
很多朋友第一反应是“带宽不够就上更贵的交换机”，这不一定划算。一台接入交换机到核心交换机之间，如果只是普通千兆口，两条千兆链路聚合后，理论转发能力可以接近2Gbps。虽然实际效果受哈希算法和流量模型影响，达不到完美叠加，但比单条链路强得多，而且成本几乎为零。
聚合的另一个价值是链路冗余。物理链路断了，流量能自动切换到其他成员链路，用户基本无感知。这在接入层尤其关键，毕竟终端用户不会容忍你跑进机房换线。对于设备本身而言，做二层链路聚合不需要额外license，也不需要换板卡，是性价比非常高的扩容和冗余手段。
1.3 二层聚合和三层聚合的边界
这里要区分一下：二层链路聚合处理的是二层接口，成员接口类型可以是access、trunk，也就是我们常说的“中继模式”或“接入模式”，Eth-Trunk本身也是一个二层逻辑接口。三层链路聚合则是在Eth-Trunk上配置IP地址，常用于路由场景和跨设备互联。
我这篇文章聚焦的是二层场景。实际组网中，交换机之间跑多个VLAN时，二层聚合适配度最高，因为不需要重新规划IP网段，也不用考虑路由协议。只要把成员接口加入聚合组，VLAN透传范围保持一致，两边的配置对称，链路就能正常工作。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 华为二层链路聚合的两条技术路线：手工负载分担与LACP动态协商
2.1 链路聚合从哪来：从“物理堆线”到“逻辑一根线”
在交换机的早期阶段，两条链路同时用是有条件的。STP会阻塞冗余端口，防止形成环路。后来出现了端口捆绑技术，让多条物理链路被当成一条逻辑链路，stp也只对这个逻辑接口进行判断，不会阻塞成员链路。传统的端口捆绑需要人工在两端配置，只要两边成员接口都加入同一个聚合组，协议栈就把它们看成一个端口。
华为设备上，这个逻辑接口称为 Eth-Trunk。你可以把Eth-Trunk理解成一个“虚拟容器”，里面装了好几个物理口。实际转发时，设备会根据报文的MAC地址或IP地址进行哈希计算，选中某一条成员链路发送。这个哈希算法是可调的，我们要根据自己的业务流量模型去选择合适的哈希因子。
2.2 手工负载分担模式的关键逻辑
手工负载分担模式，是链路聚合里最朴素的一种实现。两端的交换机都不参与协商，只要把接口手工加入同一个Eth-Trunk编号，配置一致，链路就进入工作状态。成员链路之间全部负载分担，同时承担流量转发，任何一条链路故障时自动从哈希表中排除，流量由剩余成员链路承接。
这种模式的好处是配置简单、依赖少，适用于两侧设备不支持LACP协商，或者链路对端是服务器的场景。但它有一个比较大的问题，就是链路对端必须也配置成相同的聚合模式、相同的Eth-Trunk编号