华为交换机二层链路聚合Eth-Trunk配置与排障实战

1. 链路聚合是什么，为什么非学不可

干了这么多年网络运维，我见过太多因为链路带宽不够或者单点故障导致的线上事故。你可能会想：那直接把两根网线都插上，不就能跑双倍带宽了吗？这个想法思路大方向是对的，但实现起来绝没有这么简单。如果直接把两根线同时接到交换机上，交换机会把这两个端口都认为是普通接入端口，MAC地址表会来回抖动，甚至生成树协议会发现物理环路从而阻塞其中一个端口，结果带宽不但没提升，反而把自己搞出故障来。

所以我们需要一种机制，让多根物理链路在逻辑上变成一根链路来使用，这就是链路聚合（Link Aggregation）。在华为设备上，技术术语叫 Eth-Trunk，在思科上叫 Port-Channel，在 H3C 上叫 Bridge-Aggregation。不同厂商叫法不同，但底层的原理和目的殊途同归：把多条物理链路捆绑成一条逻辑链路，既增加带宽，又实现链路冗余和负载分担。

很多人会觉得链路聚合是三层网络或者数据中心才用的东西，二层交换机上用链路聚合机会不多，这个观念其实很片面。二层链路聚合恰恰是园区网络、企业接入层最常遇到的场景之一：服务器双网卡绑定、无线AC和核心交换机之间互联、楼栋汇聚交换机上联到核心，这些场景全部都需要二层链路聚合。即便你日常接触不到数据中心级的复杂网络，学会华为交换机的二层链路聚合配置与排障，也是网络工程师一项非常核心的基本功。

这篇文章不搞纸上谈兵，我会结合我实际配置过的工程案例，把链路聚合的原理、华为设备上的两种聚合模式、手动和静态LACP的配置过程、负载均衡算法的选取、以及平时最容易踩的坑全部梳理一遍。看完之后，你不仅能在 eNSP 里敲得出命令，到了真机上遇到链路聚合相关的故障，也知道从哪些角度去排查。

2. 动手之前，先搞懂二层链路聚合的核心原理

2.1 从物理链路到逻辑链路，Eth-Trunk 做了什么

所谓二层链路聚合，本质上就是把多根物理网线对应的接口，在交换机上捆绑成一个逻辑接口。对外呈现的始终是这一个逻辑口，内部的几个物理口各司其职地分担流量。

举一个最好理解的例子：一条高速公路原来只有两个车道（对应一根物理链路，带宽比如 1G），车流量一大就堵。链路聚合相当于在旁边再修了第三条、第四条车道，然后把它们合并成一个全新的、有四个车道的高速入口。在收费站看来，目标出口没有变化，但从车道总数上看容量翻倍了，而且就算其中某一条车道临时封闭，剩下的车道依然可以保证车辆通行，只是整体运力下降而已。

从协议栈上看，二层链路聚合工作在主机的 MAC 层与物理层之间。交换机把多个物理端口放入一个 Eth-Trunk 逻辑口后，MAC 地址学习和转发查表都是在 Eth-Trunk 接口这个维度上完成的。物理端口不再是单独参与 MAC 学习的实体，真正参与二层转发的实体是 Eth-Trunk 逻辑口。因此，对外部设备来说，它看不到背后的多个物理端口，只能看到一个逻辑端口。这个逻辑端口也拥有了自己的端口属性，比如 VLAN、Trunk、Access、端口优先级等配置，都直接做在 Eth-Trunk 接口上。

注意：配置二层链路聚合时，不是把 VLAN、Trunk 等属性配置在各个物理成员接口上，而是统一配置在 Eth-Trunk 逻辑接口上。很多初学者恰恰在这里翻车，一个个物理口加 VLAN，结果业务全乱。

2.2 为什么不能直接“插两根线”？再说说环路问题

前面提到了，直接插两根线会导致环路。很多人第一次接触生成树协议的时候，都听过“二层网络必须是一棵树，不能有环”。如果没有链路聚合，交换机上的两个端口同时连接同一个下游设备，在二层的视角里，这就是一个典型的物理环路。交换机从一个端口收到广播帧，会从另一个端口泛洪出去，然后对方又从那个端口收到再泛洪回来，广播风暴就这么起来了。

链路聚合解决这个问题的思路，是在交换机内部把多个端口”合并”成一个逻辑端口。从生成树协议的视角看，逻辑口上虽然连了多根线，但它只算一个端口，不会形成环路。说白了，链路聚合是把“多根线形成环”的问题，转化成了“一根逻辑链路内部多成员负载分担”的问题。只要协议状态协商正常，环路天然不存在。

2.3 两种聚合模式：手动负载分担与静态 LACP

华为设备的二层链路聚合，分为两种模式：

第一种是手工负载分担模式（Manual Load-Balance）。这种模式下，Eth-Trunk 的成员端口完全靠手动添加，链路两端不运行 LACP 协议。只要本端把端口加进 Eth-Trunk，链路就会被链路聚合控制模块接管参与转发，不管对端是不是也做了同样配置。优点是简单粗暴，适用于对端设备不支持 LACP 协议的兼容场景；缺点也明显：如果对端配置有误或者只做了半套，本端依然会把流量往成员口上送，结果就是丢包。

第二种是静态 LACP 模式（Static LACP，也叫 802.3ad 静态聚合）。这种模式下，链路两端都启用 LACP 协议，成员端口需要通过 LACP 协议报文协商成功之后，才真正成为 Eth-Trunk 的可用成员。每一端都可以设置系统优先级和端口优先级，LACP 会根据这些优先级决定哪些端口作为活动端口参与转发，哪些作为备份端口待命。简单理解：手动模式是“我觉得成员口可以用，那就用”，LACP 模式是“双方协商好了，才用”。

在真实企业网络中，只要对端设备支持 LACP，我强烈建议优先使用静态 LACP 模式。因为这种模式有成体系的协商机制和故障感知能力，某些端口出现故障时，LACP 能更及时地感知并从活动链路集合里剔除故障端口，降低对业务的影响。

延伸阅读：华为设备在较新的版本里还有一种动态 LACP 模式（链路聚合控制协议），主要用于堆叠场景和部分特殊链路场景，在普通的二层交换机互联中不常用。大多数场景下，静态 LACP 模式已经足够。

2.4 二层链路聚合与三层链路聚合怎么选

链路聚合不止有二层，三层接口上同样可以做链路聚合。二层链路聚合和三层链路聚合的核心区别在于：Eth-Trunk 接口是二层口还是三层口。

二层链路聚合里，Eth-Trunk 接口可以配置成 Access 口或者 Trunk 口，参与 VLAN 转发，典型应用是接入交换机上联、服务器双网卡配置。三层链路聚合里，Eth-Trunk 接口则作为三层路由接口使用，通常配 IP 地址，运行路由协议，典型应用是核心交换机之间互联或者路由器与交换机互联。

选哪个，不取决于带宽需求，而取决于这条链路上要跑的是什么业务。如果下游是 VLAN 网络，需要多个 VLAN 跨设备互通，那就用二层聚合；如果两端是可路由的接口，需要走三层路由转发，那就用三层聚合。做方案的时候把这个想清楚，后续配置就不会走弯路。

2.5 负载分担算法：链路聚合的“灵魂”

链路聚合的最终效果，取决于交换机的负载分担算法。同样是四根物理链路，如果负载分担算法选得不好，可能出现一条链路跑满、另外三条空闲的尴尬局面。

华为设备常用的负载分担方式有：基于源 MAC 地址、基于目的 MAC 地址、基于源+目的 MAC 地址、基于源 IP 地址、基于目的 IP 地址、基于源+目的 IP 地址，以及基于 VLAN、基于源目端口号等。

二层链路聚合场景，通常是纯二层转发，没有 IP 层的参与，所以最常用的负载分担策略就是基于源+目的 MAC 地址。这样设计的好处是：同一对通信主机之间的业务流量，MAC 对固定，HASH 结果一致，数据帧会始终走同一条成员链路，避免了帧乱序；而不同主机之间的流量则会相对均匀地散列到不同成员链路上，实现负载均衡。

如果链路里跑的是三层业务（比如 VLAN 间路由，流量需要上送到三层网关转发），那 HASH 参考源+目的 IP 地址会更合理。IP 地址的随机性通常比 MAC 地址好，散列更均匀，负载均衡效果更佳。

这里必须提醒一点：不要迷信“负载分担算法能保证绝对均匀”。HASH 是概率性的，只要业务流的 HASH 分布符合大概率均匀，效果就已经很好了。遇到负载非常不均的情况，可以从调整 HASH 因子这个角度去优化，而不是指望换一种算法就全能解决。

3. 华为设备二层链路聚合配置实战（附命令与思路）

3.1 配置前需要明确哪些信息

动手敲命令之前，先把这些问题想清楚，免得做到一半返工：

第一，哪两个设备之间做链路聚合？是交换机到交换机，还是交换机到服务器？如果是交换机到服务器，服务器网卡那边也需要做团队（Teaming）或者 bond 配置，两端的聚合模式、速率双工、VLAN 属性必须一致。任何一端没配对，链路都起不来。

第二，链路两端用什么聚合模式？推荐静态 LACP，双方都启用 LACP 协议协商。只有在设备不支持 LACP 的情况下，才考虑手工负载分担模式。

第三，这些成员链路跑哪些 VLAN？如果是 Trunk 口，放行 VLAN 列表要想清楚。千万不要把不该放行的 VLAN 全部放行，这不仅是安全问题，也是广播域扩散问题。

第四，希望负载分担的 HASH 因子选什么。二层业务优先选源+目的 MAC，三层业务优先选源+目的 IP。

3.2 eNSP 拓扑规划与接口规划

我们以一个标准的网络实训拓扑来配置。假设有一台核心交换机（华为 S5700 系列）和一台接入交换机（华为 S3700 系列），两台交换机之间使用两条物理链路互联，需要在核心交换机和接入交换机上分别配置二层链路聚合。聚合后的链路作为 Trunk 口使用，放行 VLAN 10 和 VLAN 20。

接口规划如下：

• 核心交换机：GE0/0/1、GE0/0/2 加入 Eth-Trunk 1，Eth-Trunk 1 配置为 Trunk，放行 VLAN 10、20。
• 接入交换机：GE0/0/1、GE0/0/2 加入 Eth-Trunk 1，Eth-Trunk 1 配置为 Trunk，放行 VLAN 10、20。
• 接入交换机下联 PC1（VLAN 10）、PC2（VLAN 20），用于验证不同 VLAN 的二层互通。

先看核心交换机上的配置：

text复制system-view
[HUAWEI] sysname Core-SW
[Core-SW] interface eth-trunk 1
[Core-SW-Eth-Trunk1] mode lacp-static
[Core-SW-Eth-Trunk1] trunkport gigabitethernet 0/0/1
[Core-SW-Eth-Trunk1] trunkport gigabitethernet 0/0/2
[Core-SW-Eth-Trunk1] port link-type trunk
[Core-SW-Eth-Trunk1] port trunk allow-pass vlan 10 20
[Core-SW-Eth-Trunk1] quit

再看接入交换机上的配置：

text复制system-view
[HUAWEI] sysname Access-SW
[Access-SW] interface eth-trunk 1
[Access-SW-Eth-Trunk1] mode lacp-static
[Access-SW-Eth-Trunk1] trunkport gigabitethernet 0/0/1
[Access-SW-Eth-Trunk1] trunkport gigabitethernet 0/0/2
[Access-SW-Eth-Trunk1] port link-type trunk
[Access-SW-Eth-Trunk1] port trunk allow-pass vlan 10 20
[Access-SW-Eth-Trunk1] quit

这里有一个细节值得特别注意：华为交换机上，创建 Eth-Trunk 之后，必须先在 Eth-Trunk 接口视图下配置聚合模式（mode lacp-static），再添加成员口。如果你先把物理口加进去了，再改聚合模式，可能会触发接口重新初始化，造成流量闪断。更保险的做法是提前规划好，按“创建 Eth-Trunk – 配置模式 – 添加成员口 – 配置端口属性”的顺序来。

3.3 手工负载分担模式的配置差异

如果对端设备不支持 LACP，比如一些老旧的服务器网卡或者某类非标准交换机，那就只能使用手工负载分担模式。配置上和静态 LACP 的区别只有一处：不需要配置 mode lacp-static，默认就是手工负载分担模式，直接把物理口加入 Eth-Trunk 即可。

text复制[Core-SW] interface eth-trunk 1
[Core-SW-Eth-Trunk1] trunkport gigabitethernet 0/0/1
[Core-SW-Eth-Trunk1] trunkport gigabitethernet 0/0/2
[Core-SW-Eth-Trunk1] port link-type trunk
[Core-SW-Eth-Trunk1] port trunk allow-pass vlan 10 20
[Core-SW-Eth-Trunk1] quit

这种模式下，只要本端把物理口加进 Eth-Trunk，端口就会立刻被聚合逻辑接管，无论对端是否配置了同样的聚合。所以一定要保证两端配置一致性。否则，对端设备还是普通物理端口，而本端把流量分担到多个物理口上，对端会当成不同端口的独立流量来接收，二层转发就会乱套。

我自己的经验是：如果是交换机到交换机互联，优先用 LACP；如果是交换机到服务器，先看服务器网卡驱动支持什么模式，如果服务器只支持静态绑定，那就只能和手工负载分担模式对应起来。两边模式一定要互相匹配，否则业务链路异常。

3.4 负载分担算法的配置调整

华为交换机上，负载分担算法的配置命令是：

text复制[Core-SW] eth-trunk 1
[Core-SW-Eth-Trunk1] load-balance src-dst-mac

这条命令的意思是：Eth-Trunk 1 的负载分担 HASH 因子选择源+目的 MAC 地址。不同型号支持的 HASH 因子集合会有些差异，常见的有 dst-ip、src-ip、src-dst-ip、dst-mac、src-mac、src-dst-mac、vlan 等。

如果链路里跑的业务绝大多数是跨 VLAN 或三层路由流量，可以考虑把 HASH 因子调整为 src-dst-ip，这样 IP 五元组信息参与 HASH 计算，分布更均匀：

text复制[Core-SW-Eth-Trunk1] load-balance src-dst-ip

这里必须说一个很多人忽略的点：Eth-Trunk 的负载分担算法，需要在 Eth-Trunk 接口视图下配置，不需要在成员物理口上配置。有些初学者误以为要进入物理口去调负载分担，结果命令都敲不出来。另外，修改负载分担算法会短暂影响该 Eth-Trunk 链路正在转发的业务流量，虽然极其短暂，但在核心链路上操作时依然建议在业务低峰期进行，避免对正在传输大流量业务造成可感知的影响。

3.5 配置后的确认命令与典型输出

配置完成后，必做的动作是检查 Eth-Trunk 状态。最常见的确认命令是：

text复制display eth-trunk 1

正常情况下，你会看到类似下面的关键信息：

text复制Eth-Trunk1 current state: UP
WorkingMode: STATIC
Hash arithmetic: According to SA-XOR-DA
Least Active-linknumber: 1
Operational status: up
NumberOf Active Ports: 2
PortName                      Status      Weight
GigabitEthernet0/0/1          Up          1
GigabitEthernet0/0/2          Up          1

重点看几个字段：

• WorkingMode 为 STATIC，说明是静态 LACP 模式。
• NumberOf Active Ports 为 2，说明两个成员口都处于活动状态。
• Operational status 为 up，说明 Eth-Trunk 逻辑口是通的。
• Least Active-linknumber 表示最小活动链路数，默认是 1，也就是说只要还有一条活动链路，Eth-Trunk 就保持 up。某些业务对可靠性要求高，可以调整这个值，比如最少需要 2 条活动链路才让 Eth-Trunk up，如果只有 1 条链路存活，Eth-Trunk 直接 down。

修改最小活动链路数的命令是：

text复制[Core-SW-Eth-Trunk1] least active-linknumber 2

这个命令的作用是：当活动成员口数量降到 2 以下时，Eth-Trunk 逻辑口进入 down 状态，业务主动中断。为什么要有这种看似“反直觉”的设计？因为有些业务对带宽有硬性要求，比如视频会议系统，如果带宽减半可能导致服务不可用，此时还不如让 Eth-Trunk 直接 down，触发上层路由协议切换或业务切换到备用链路，而不是强行降级运行。这个参数要根据业务特性来定，不能用默认值糊弄过去。

3.6 配置 LACP 系统优先级和端口优先级

静态 LACP 模式下，链路两端会协商活动端口。默认情况下，两端交换机的系统优先级相同（32768），此时会比较 MAC 地址，MAC 地址小的一端成为 LACP 主动端，主动端决定哪些端口作为活动端口，哪些作为备份端口。

如果想人为控制哪一侧是主动端，可以修改系统优先级，数值越小优先级越高：

text复制[Core-SW] lacp priority 1000

如果希望在某些场景下优先选择特定端口作为活动端口，可以调整端口优先级：

text复制[Core-SW] interface gigabitethernet 0/0/1
[Core-SW-GigabitEthernet0/0/1] lacp priority 100
[Core-SW-GigabitEthernet0/0/1] quit

端口优先级也是数值越小越优先。在实际工程里，我不太建议轻易去调这些优先级参数。多数场景下，让两端设备按默认规则协商即可。除非你明确知道某条链路质量更好，或者某个端口所在的单板处理能力更强，希望优先使用这条链路，才去调整优先级。优先级配置不当，可能导致两端的协商结果不符合预期，反而把问题搞复杂。

3.7 二层链路聚合的兼容场景：服务器双网卡的 bond

链路聚合不只存在于交换机之间。最常见的另一个场景，是服务器双网卡做 bond，然后上联到交换机。

Linux 服务器上双网卡绑定有很多种模式，比如 mode 0（balance-rr）、mode 1（active-backup）、mode 4（802.3ad）。二层链路聚合对应的是 mode 4，也就是 802.3ad 动态链路聚合。配置 mode 4 时，交换机端必须启用 LACP，否则协商不上。很多运维新手第一次配服务器 bond 时，交换机侧用了手工负载分担模式，结果服务器侧 LACP 协商失败，链路完全不通。

Linux 下配置 bond mode 4 的步骤大致是：

• 安装 bonding 模块；
• 修改网卡配置文件，把两块物理网卡绑定为 bond0；
• bond0 的 BONDING_OPTS 里设置 mode=802.3ad、miimon=100、xmit_hash_policy=layer3+4；
• 交换机侧配置静态 LACP 模式的 Eth-Trunk，并把成员口加入。

xmit_hash_policy 这个参数要特别说一下，它决定了服务器端发送流量的 HASH 依据。layer3+4 表示基于三层 IP 地址和四层端口进行 HASH，对绝大多数业务来说均衡效果比较稳定。如果交换机侧设置的 HASH 因子和服务器端不一致，并不会导致链路不通，但负载均衡效果可能会变差。所以做服务器 bond 时，记得两端 HASH 策略尽量对齐思路，才能达到最优效果。

4. 链路聚合的数据传输机制与关键参数决策

4.1 成员端口的状态机：从 down 到 active 的过程

不要以为链路聚合配置完成，成员口状态自然就是 up。尤其在使用静态 LACP 模式时，一个成员口从物理插线到最终成为活动成员，会经历一个完整的协商过程。

在 LACP 协议中，每个端口的状态由 MUX 状态机和 MII 状态机共同决定。简单概括就是：端口先通过物理层检测确认链路是通的（物理 up），然后发送 LACPDU 报文与对端交换系统优先级、端口优先级、端口号等信息。当两端协商一致，确认这个端口可以成为活动端口后，MUX 状态才置为 Collecting/Distributing，此时该端口才真正参与数据转发。

如果我对端连接的是一台没配链路聚合的设备，LACP 报文发过去没人回应，端口就会一直处于 waiting 或者 disabled 状态，Eth-Trunk 里这个成员口始终不会 up。这也是判断链路聚合是否稳定的一个重要观察点：如果 Eth-Trunk 中有成员口处于 not selected 状态，大概率是对端协商失败，或者对端接口没加入聚合。

4.2 为什么同一对主机的流量不能拆到两条链路

有人可能会问：既然有四条链路，为什么不能把一个大文件的流量同时拆分到四条链路上跑，这样速度不就提升四倍了吗？

这个问题要回到二层转发的本质：数据帧是有序的，接收端必须要能按顺序重组数据。如果同一个业务流（比如同一对 MAC 地址之间的流量）被 HASH 到两条不同的物理链路上，这两条链路的传播时延和队列状态不可能完全一致，帧到达对端的时间顺序就可能错乱。二层交换机不负责重排序，帧乱序对上层 TCP 协议非常不友好，会触发大量重传，性能反而严重下降。

所以链路聚合对负载分担的最小粒度是“流”，不是“包”。同一条流永远走同一条物理链路，不同流之间才可能被分散到不同链路。这也是为什么 HASH 因子选择这么重要：HASH 因子直接决定了流的划分粒度。如果你选择源 MAC 作为 HASH 因子，那么一个源 MAC 对应的一条流永远固定走一条物理链路，哪怕这个源 MAC 有大量并发连接，也只会在一条链路上跑。

4.3 最多能聚合多少条链路

华为交换机 Eth-Trunk 的成员口数量上限，不同型号不一样。以常见的 S5700/S6700 系列为例，Eth-Trunk 最多支持 8 个活动成员口。部分框式交换机支持的成员口数量更多。但在二层接入场景，我建议不要把鸡蛋放在一个篮子里，除非带宽需求真的很大，否则 2 到 4 条物理链路聚合是成本和收益最平衡的选择。

判断最优链路数量，可以按这个思路粗略估算：先看业务峰值流量是多少，再看单条物理链路的带宽，最后留出至少 30% 的冗余余量。比如业务峰值 1.5 Gbps，单链路 1 Gbps，那么 2 条链路聚合理论带宽 2 Gbps，扣除负载分担不均的损耗，实际可用大约 1.6～1.8 Gbps，足够覆盖峰值且有余量。

4.4 动态聚合与静态聚合的故障切换差异

链路聚合最大的价值之一就是故障切换。当某一条物理链路断开时，交换机是否能快速感知并把流量切换到其他活动链路上，直接决定了业务中断的时长。

手工负载分担模式对链路故障的感知，主要依赖物理层 DOWN 信号的传递。链路断开、光模块丢失等物理故障可以被快速感知，切换时间通常在毫秒到秒级别。但如果是那种物理层没有 DOWN、实际链路质量已经下降的“哑故障”（比如光口收发光异常导致的错包），手工负载分担模式几乎无法感知。

静态 LACP 模式除了物理层信号，还会周期性发送 LACPDU 报文，对端会持续监控这些报文的接收情况。如果一段时间内收不到对端的 LACPDU，就认为链路协商超时，自动把该端口从活动链路中剔除，并把流量切换到其他正常链路上。LACP 的超时时间分为短超时（3 秒）和长超时（90 秒），默认是长超时。如果业务对故障切换时间非常敏感，可以调整 LACP 超时时间为短超时：

text复制[Core-SW-Eth-Trunk1] lacp timeout fast

这样配置后，LACP 报文的发送间隔会缩短，对端感知故障的时间也会缩短，切换更快，但同时也会增加少量协议报文开销。对于两根物理链路互联的普通场景，这个开销可以忽略不计。

4.5 二层流量转发在 Eth-Trunk 上的查表过程

为了更直观地理解链路聚合在二层转发中的位置，我描述一下一个数据帧从接入交换机到核心交换机的完整旅程。

假设 PC1 发送一个目的 MAC 为服务器 MAC 的数据帧，从接入交换机的 Access 口进入。接入交换机做二层查表，发现目的 MAC 对应的出接口是 Eth-Trunk 1。于是，交换机对数据帧做 HASH 运算，计算依据正是 Eth-Trunk 上配置的负载分担因子。HASH 结果落入某个成员物理端口，帧最终从这个成员口出去。

这里有一个细节：如果 HASH 结果命中的成员口恰好处于 down 状态，交换机会自动把该帧重新 HASH 到另一个可用的活动成员口，而不是直接丢弃。这个机制保证了即使单链路故障瞬间有少量帧需要重新选择路径，也能尽可能避免丢包。

5. 常见故障排查：链路聚合起不来，问题到底出在哪

5.1 成员口没起来？先看物理层再查协商

Eth-Trunk 起不来，最容易犯的错误是忽略物理层检查。我曾经遇到过一个项目，链路聚合状态显示只有一条成员口 up，另一条永远 down。现场工程师排查了半天配置，最后发现问题出在光模块上，有一根光纤跳线接错了端口，交换机的光口根本没收到光。

所以排查链路聚合问题时，第一步永远是看物理层状态：

text复制display interface gigabitethernet 0/0/1

确认端口物理状态为 up。如果物理 down，先处理物理层问题，别急着查协议。物理层没问题了，再看 LACP 协商状态：

text复制display lacp statistics

如果发现 LACP 报文收发计数一直在增长，说明协议报文是通的，协商没走通一般是优先级、模式、VLAN 属性等问题。如果 LACP 报文计数不增长，大概率是对端没启用 LACP，或者两端连接的端口号不对应。

5.2 两边配置都对了，为什么 Eth-Trunk 还是 down

这是新手常问的一个问题。配置看着完全一样，交换机之间两根线也插好了，Eth-Trunk 就是 down。

我总结过几个高发原因：

第一个原因，两端聚合模式不一致。本端配了 static lacp，对端是默认的手工负载分担模式，LACP 报文协商不成功，Eth-Trunk 就会 down。解决办法是统一两端的聚合模式。

第二个原因，Eth-Trunk 接口被 shutdown 了。有些人配置完 Eth-Trunk，顺手执行了 shutdown，后来忘了恢复。检查一下 Eth-Trunk 接口和成员物理口上是否有 shutdown 配置。

第三个原因，成员口被其他业务占用。比如某个物理口已经被划到某个 VLAN 接口或者被其他 Eth-Trunk 引用，加入新的 Eth-Trunk 时就会失败。华为设备上，一个物理口只能属于一个 Eth-Trunk，不能重复添加。

第四个原因，对端设备接口类型不匹配。比如对端口是 Access 口，本端是 Trunk 口，即使聚合协商通过，VLAN 转发也会异常。这个要在配置前就规划好，不能等出问题了再对。

5.3 链路聚合通了，但只有一条链路有流量

这个现象特别典型：Eth-Trunk 显示 up，所有成员口也 up，但流量统计一看，只有一条成员口有流量，其他成员口几乎为零。

原因通常是负载分担 HASH 因子选择不合理。如果业务流的 MAC 地址集中度很高，比如下面挂着的是一个客户端的网关，所有流量都收敛到同一组 MAC，那么选择基于源 MAC 或目的 MAC 作 HASH 因子，就可能导致流量全部命中同一条链路。

遇到这种情况，我的处理思路是先看看流量特征。打开 Eth-Trunk 的流量统计，确认哪些成员口在转发流量，然后修改负载分担因子。如果链路里跑的流量主要是 IP 业务，可以试试 src-dst-ip 或者增强型 HASH 策略：

text复制[Core-SW-Eth-Trunk1] load-balance src-dst-ip

改完之后再看流量分布。如果还是不均匀，可以观察是不是业务流本身就很少，只有一两条大流，那任何 HASH 算法都做不到均衡，因为链路聚合的最小粒度是流不是包。这种情况下，只能从业务侧分流或者接受现状，不能硬调 HASH。

5.4 聚合链路频繁闪断，问题出在 LACP 超时与错误包

还有一种相对隐蔽的故障：Eth-Trunk 时好时坏，接口状态在 up 和 down 之间反复跳变。

我在现场遇到过一起，现象是 Eth-Trunk 每隔十几分钟就闪断一次，业务短时间抖动后又恢复。排查了很久，最后发现问题出在物理链路的 CRC 错误包上。光模块或者网线质量不好，产生了大量 CRC 错误帧，LACP 协议报文也受到了影响，导致对端认为 LACP 协商超时，把端口踢出活动集合，流量切换后又恢复，再踢再恢复，形成反复抖动。

排查思路是查看物理接口的错误计数：

text复制display interface gigabitethernet 0/0/1

重点关注 CRC、FCS 错误计数是否在快速增长。如果有大量错包，先换线、换光模块、清洁光纤接头，再观察链路稳定性。不要指望交换机配置能解决物理层质量问题，物理层的问题只能从物理层解决。

5.5 修改配置后流量中断，可能忽略了这些细节

有时候，配置本身没有错，但调整配置的顺序不对，也会引发业务闪断。举几个我踩过的坑：

• 先删除了 Eth-Trunk，再重新创建，期间业务完全中断。如果 Eth-Trunk 下联的是核心业务设备，这个中断就非常致命。
• 先在物理口上清除了原有配置，再打算加入新的 Eth-Trunk。比如原本物理口是 Access 口，上面配了 VLAN，直接输入 undo port link-type 或 clear configuration this 把端口配置清了，但没意识到这一步就把链路切断了。
• 在 Eth-Trunk 接口上调整端口属性时，比如修改允许通过的 VLAN 列表，也会对链路产生瞬时影响。影响时间通常极短，但大型网络里也可能造成个别业务闪断。

我的建议是：在做链路聚合相关的变更之前，先写变更方案，明确配置顺序，评估影响面，尽量在业务低峰期操作。尤其对核心链路，能不做变更就不做，必须做就提前准备好回退方案。

5.6 常见问题速查表

我把日常维护中遇到最多的链路聚合问题整理成一张表，方便你现场排查时快速定位。

6. 华为设备二层链路聚合的进阶玩法与典型应用

6.1 核心层到底用二层聚合还是堆叠

在园区网汇聚层或接入层设计中，核心交换机之间除了链路聚合，还有一个常见方向：堆叠（iStack/Cluster）。堆叠和链路聚合是解决链路带宽和可靠性的两种不同思路。

链路聚合交换的是流量路径的冗余；堆叠是把多台设备虚拟成一台设备，管理面和控制面合一，然后配合跨设备链路聚合，实现设备级冗余。堆叠的可靠性更高，但配置复杂度也更高，升级风险更大。链路聚合简单直接，但设备本身依然是独立的两台，一台挂了，业务仍会中断。

从实际选型看，接入层到汇聚层、汇聚层到核心层，绝大多数场景用链路聚合就足够了。只有在核心层或者对设备高可用要求特别苛刻的场景，才考虑堆叠加跨设备链路聚合的方案。新手不要一上来就追求堆叠，先把链路聚合玩明白，再去碰堆叠，否则出了故障连排查思路都会混乱。

6.2 和生成树协议的协同配合

二层链路聚合经常会和生成树协议一起出现。比如接入交换机上联到两台核心交换机，想实现链路冗余，这时一般会配置跨设备的链路聚合（在堆叠场景中）或者在两端分别做 Eth-Trunk，然后让生成树协议阻塞冗余链路。

对于普通的单台交换机互联，Eth-Trunk 在生成树协议里会被当作一个逻辑口参与计算，成员端口不再单独参与 STP。所以要注意：不要在 Eth-Trunk 的成员物理口上单独修改 STP 相关参数，要在 Eth-Trunk 接口上统一配置。否则可能出现配置了但不生效、排查困难的问题。

如果接入交换机双归上联到两台核心交换机，但没有堆叠，这时候同一台接入交换机上会有两个 Eth-Trunk 分别上联到两台核心。生成树协议会在两个上联口之间选举一个根端口，阻塞另一个，避免环路。这个场景下，生成树和链路聚合是配合工作的，缺一不可。

6.3 通过 Eth-Trunk 提升服务器接入的可靠性

给服务器配置双网卡上联交换机，是链路聚合在企业网络中最高频的应用之一。但很多运维在这里栽过跟头。

服务器上一般建议配置两个物理网口，分别连接到两台不同的交换机，或者连接到同一台交换机的两个不同单板上，然后通过链路聚合实现故障冗余。如果两台物理网口都接到了同一块单板上，单板一旦故障，所有链路同时失效，冗余就失去了意义。

连接不同交换机时，两台交换机之间需要先完成跨设备的二层打通（比如通过堆叠或者三层互通），否则服务器侧的链路聚合只会带来环路和混乱。一个更稳妥的做法是把服务器双网口接入同一台交换机的不同单板，配合 Eth-Trunk 的 LACP 模式，实现端口级和单板级的冗余，这是企业接入服务器最常用的方案。

6.4 二层链路聚合能不能跨设备做

跨设备链路聚合在华为体系里叫 M-LAG（跨设备链路聚合），是后来才大规模铺开的技术。M-LAG 通过两台设备之间建立 peer-link，让两台设备对外呈现为一个逻辑设备，服务器或者下联交换机用一根 Eth-Trunk 连到这两台设备上，实现设备级冗余和负载分担。

但我要提醒一点：M-LAG 属于相对高阶的架构，依赖 peer-link 链路和双主检测机制的可靠性，配置复杂度远高于普通链路聚合，故障场景也更难排查。初学者不要一上来就挑战 M-LAG，先把单设备上的 Eth-Trunk 原理和配置吃透，再逐步探索跨设备方案。否则配置一堆，故障一来根本无法定位是哪一层出了问题。

6.5 链路聚合上的 QoS 与流量监控

链路聚合以后，对业务的一个显著影响是 QoS 策略的生效位置。很多 QoS 行为是在物理端口上配置的，比如限速、优先级重标记、队列调度。当链路聚合把多个物理口合并后，这些 QoS 策略需要配置在 Eth-Trunk 接口上，或者确保两台设备的 QoS 策略保持一致。

流量监控同理。有些网管系统喜欢在成员物理口上抓流量，但链路聚合场景下，业务流量是分布到多个成员口上的，任何单一口的流量统计都不能代表整个 Eth-Trunk 的流量。要拿到整体流量数据，应该通过 Eth-Trunk 接口级别去查看统计。如果用了网管平台，也要确认平台支持对 Eth-Trunk 逻辑口的监控，否则监控数据会严重失真，影响容量规划判断。

7. 链路聚合的下一步：从华为设备到整个网络体系

链路聚合不是孤立存在的技术，它在整个网络体系中和其他协议、其他层次的技术都有千丝万缕的联系。如果你只把链路聚合当成几条命令来背，难免只见树木不见森林。以下是我在多年运维中体会到的几个关联点。

第一，链路聚合和路由协议密不可分。在核心交换机上配置三层链路聚合之后，这个 Eth-Trunk 接口可以作为路由协议的互联接口，参与 OSPF 或静态路由的邻居建立。此时，链路的故障切换速度不仅取决于链路聚合本身，还取决于路由协议的收敛速度。哪怕链路聚合切换得再快，路由协议如果收敛慢，业务中断时间依然很长。

第二，链路聚合和网络监控体系的配合。真实生产环境里，不可能靠人肉去盯链路状态。链路聚合 Eth-Trunk 的状态、成员口的错包计数、LACP 协商状态，都应该纳入监控范围。如果监控系统只盯物理端口，聚合链路出现活性下降（比如成员口从 4 个降到 2 个），监控系统可能不会告警，因为 Eth-Trunk 还是 up 的，但实际带宽已经减少了一半。这种隐患最可怕，因为业务不会立刻中断，但性能已经下降，用户开始抱怨卡顿，你却很难定位。

第三，链路聚合是理解 SDN 和自动化网络的基础。软件定义网络里的很多逻辑端口抽象、链路捆绑、流量调度概念，底层都离不开链路聚合的思路。理解了 Eth-Trunk 的成员管理和负载分担逻辑，再去学 SDN 的流表下发、链路捆绑策略，会容易很多。

8. 动手实验：在 eNSP 里完整跑通一个二层链路聚合实验

只讲理论不实操，永远是纸上谈兵。下面我在 eNSP 模拟器里完整演示一遍二层链路聚合的实验流程，方便你跟着一起操作。

8.1 实验拓扑与基础配置

在 eNSP 中拖入两台交换机，分别命名为 SW1 和 SW2，在 SW1 和 SW2 之间连接两条网线，使用接口 GE0/0/1 和 GE0/0/2。另外在 SW1 下挂 PC1（VLAN 10），SW2 下挂 PC2（VLAN 10），用来测试二层互通。

先给两台交换机配置基础 VLAN 和接口：

SW1：

text复制system-view
[S1] vlan batch 10 20
[S1] interface gigabitethernet 0/0/3
[S1-GigabitEthernet0/0/3] port link-type access
[S1-GigabitEthernet0/0/3] port default vlan 10
[S1-GigabitEthernet0/0/3] quit

SW2 的接口配置类似，给 GE0/0/3 配 Access 并划入 VLAN 10，用于连接 PC2。

8.2 配置二层链路聚合

SW1 配置：

text复制[S1] interface eth-trunk 1
[S1-Eth-Trunk1] mode lacp-static
[S1-Eth-Trunk1] trunkport gigabitethernet 0/0/1
[S1-Eth-Trunk1] trunkport gigabitethernet 0/0/2
[S1-Eth-Trunk1] port link-type trunk
[S1-Eth-Trunk1] port trunk allow-pass vlan 10 20

SW2 配置完全相同：

text复制[S2] interface eth-trunk 1
[S2-Eth-Trunk1] mode lacp-static
[S2-Eth-Trunk1] trunkport gigabitethernet 0/0/1
[S2-Eth-Trunk1] trunkport gigabitethernet 0/0/2
[S2-Eth-Trunk1] port link-type trunk
[S2-Eth-Trunk1] port trunk allow-pass vlan 10 20

配置完成后，在 SW1 上执行 display eth-trunk 1，应该可以看到两个成员口都处于 active 状态。

8.3 验证二层互通与链路故障切换

给 PC1 配置 IP 192.168.10.1/24，PC2 配置 IP 192.168.10.2/24。从 PC1 ping PC2，如果能通，说明二层链路聚合已经正常工作。

接下来做故障切换实验：在 SW1 上手动关闭 GE0/0/1 接口：

text复制[S1] interface gigabitethernet 0/0/1
[S1-GigabitEthernet0/0/1] shutdown

此时再到 PC1 上 ping PC2，你会发现丢包极少或者几乎没有丢包，因为流量已经自动切换到 GE0/0/2 上继续转发了。这充分说明链路聚合实现了链路冗余。

恢复 GE0/0/1 接口后，链路会自动重新加入 Eth-Trunk，两条成员口恢复 active。整个过程对业务的影响非常小。

8.4 手动负载分担模式的验证差异

再做一个对比实验：把 SW1 和 SW2 的 Eth-Trunk 模式改为手工负载分担（删除 LACP 模式配置）：

text复制[S1] interface eth-trunk 1
[S1-Eth-Trunk1] undo mode
[S2] interface eth-trunk 1
[S2-Eth-Trunk1] undo mode

手工负载分担模式下，两端不需要 LACP 协商，只要物理口 up 且加入 Eth-Trunk，就会参与转发。从验证效果看，ping 测试也能通，故障切换也能做，但少了一层 LACP 协议协商和故障自动感知能力。真机生产环境里，如果对端性能允许，我始终推荐用静态 LACP 而不是手工模式。

9. 写在最后：链路聚合这件事，我的真实体会

做了这么多年网络运维，链路聚合是我用得最多也最基础的技术之一。不管是最简单的两台交换机用两根线互联，还是数据中心级的跨设备链路聚合，其核心逻辑始终没有变过：把多条物理链路抽象成一条逻辑链路，既扩容又冗余。

在实际操作中，我最大的体会是：链路聚合的配置命令其实很少，真正的复杂度在于两端一致性的把控和故障定位。你永远要记住，链路聚合是一个跨设备协同技术，不是单台交换机的自嗨。任何一边配置疏忽，都可能造成链路不通或者负载不均。排查问题的时候，先看物理层，再看协议协商，最后看流量分布，按这个顺序来，绝大多数问题都能快速定位。

如果你正在学习华为设备，我建议在 eNSP 里多做几遍二层链路聚合的实验，从手工模式到静态 LACP 模式都跑一遍，再去把负载分担算法改来改去，观察成员口上的流量变化。这些实验操作成本极低，但对理解链路聚合的原理帮助极大。等你到了真机环境，遇到链路聚合的故障，心里就会有底气，不会被一堆状态字段吓住。

学网络没有捷径，但链路聚合绝对是一个值得你花时间彻底吃透的基础知识点。把这一课学扎实了，后面无论是堆叠、M-LAG 还是数据中心网络，学起来都会顺畅很多。