华为设备上的链路聚合（LACP模式），是我这些年做网络项目几乎绕不开的一个操作。不管是给服务器做双网卡接入、两台交换机之间需要跑更大的流量，还是机房改造时想提升链路冗余，Eth-Trunk配合LACP都是最常用也最稳妥的方案。这篇文章我打算把原理、配置、负载均衡和排错一次性讲透，刚入门的朋友可以跟着命令直接敲，老手也可以重点看后面的故障排查部分，有不少是文档里不会写的细节。
1. 链路聚合到底解决什么问题
1.1 从单条链路到逻辑聚合：带宽与冗余
先说说最基础的需求。一台服务器接在交换机的某个口上，单条千兆链路带宽就是1Gbps，一旦业务量上来，网卡跑满、流量拥塞、延迟飙升，最直接的办法就是加一条网线，把两个端口绑成一个逻辑口。这里的关键在于：不是简单地把两条物理链路插上去就能用，交换机的生成树协议会检测到物理环路，直接阻塞其中一个端口，结果带宽没叠加，反而多了一条“备用”线路。
链路聚合做的事情，就是把多个物理端口抽象成一个逻辑接口。在华为设备上这个逻辑接口叫Eth-Trunk，对外表现为一个端口，参与MAC学习、VLAN转发、STP计算时都把它当成一条链路。两条千兆口聚合成一个Eth-Trunk，理论上能提供2Gbps的转发能力，同时任何一条物理链路断了，流量自动切换到剩下那条，对业务几乎无感知。用生活里的例子理解：就像收费站从单车道改成双车道，车流量翻倍，某条车道临时关闭时车辆自动走另一条，到对向出口再汇合，整个过程不需要司机下车改道。
1.2 LACP模式为什么是“自动挡”模式
华为Eth-Trunk支持两种成员加入方式：手动模式和LACP模式。手动模式简单粗暴，两端网络管理员手工把端口一个个加进Eth-Trunk，哪条链路断了、恢复后是否重新加入，完全靠配置决定，没有任何协商机制。
LACP模式则引入了Link Aggregation Control Protocol，两端设备通过互相发送LACPDU报文，自动确认哪些端口可以聚合、哪些端口作为活动成员、哪些作为备份等待。一旦活动链路出现故障，备用端口会自动提升为活动状态，不需要人工干预。这个机制有点像电梯的并联调度：两台电梯平时同时运行，其中一台故障时另一台自动承接全部楼层需求，而不是等维修师傅到现场手动切换。
我个人的建议是：只要能支持LACP，优先用LACP模式。少数老设备、特殊情况需要强制“一把梭”时才考虑手动模式，否则LACP的自动协商和快速收敛能力确实能省很多运维精力。
1.3 什么样的场景更适合LACP
链路聚合不是所有场景都必须上，但以下几类场景里LACP几乎是标配：
- 服务器双网卡接入交换机，需要带宽叠加和网卡冗余，交换机侧配LACP，服务器侧网卡做bonding或teaming，两边协商同一组活动链路。
- 两台交换机之间用多条线缆互联，既想提升上联带宽，又不想被STP阻塞成单链路。
- 出口或核心区域流量较大，单端口带宽不够，需要把多个万兆口聚合成一个高带宽逻辑口。
- 虚拟化平台里多台物理机需要高可用网络接入，用LACP保证物理链路故障时不中断业务。
场景确定后，配置思路就清晰了：先规划聚合口编号、成员端口、VLAN放通、负载均衡策略，再动手敲命令。
2. 动手前必须搞懂的几个关键点
2.1 Eth-Trunk的逻辑本质与限制
Eth-Trunk是一个虚拟的逻辑接口，在系统里有一个独立编号，比如Eth-Trunk 1、Eth-Trunk 2。它本身不直接对应任何物理硬件，而是把若干物理端口纳入麾下统一调度。这里需要特别注意：物理端口一旦加入Eth-Trunk，它的二层属性、VLAN配置、端口状态都由Eth-Trunk统一接管，你在物理接口下配置的很多东西会失去意义，甚至直接报错。
华为设备上Eth-Trunk的数量和单个Eth-Trunk的成员数有规格限制。不同型号、不同版本差异很大，入门级交换机可能只支持几个Eth-Trunk，中高端框式设备支持的数量更多，单个Eth-Trunk的成员口数量通常在8个到16个之间。动手之前查一下对应型号的产品规格文档，避免配到一半发现规格不够。
还有一个容易忽略的限制：Eth-Trunk的成员端口必须是同一个类型，不能把千兆口和万兆口混在一个聚合组里，也不能把光口和电口混用。速率和双工模式不一致的端口即使能协商成功，转发效果也会很差。
2.2 LACP的几个关键参数
LACP协商不是简单的“握个手”，背后有一套优先级体系。两端设备通过LACPDU报文交换自己的系统优先级、系统MAC、端口优先级、端口号等信息，然后根据这些参数决定谁是主控方、哪些端口作为活动成员。
系统优先级是全局参数，默认32768，数值越小优先级越高。两台设备协商时，系统优先级高的一方（数值小）作为主控，负责决定活动链路的数量。端口优先级也是默认32768，数值越小越优先被选为活动端口。当两端都是同样的优先级时，再比较端口编号，编号小的优先。
另外还有一个容易踩的坑：LACP超时时间。华为接口下可以配置LACP超时时间为慢速（默认30秒）或快速（1秒），如果对端设备配置的是快速超时而本端是慢速，协商虽然能成功，但链路故障检测速度会不一致。对接服务器网卡bonding时，建议两端都配成快速超时，这样故障感知更灵敏。
2.3 哪些配置会影响协商结果
很多人配置LACP后链路不聚合，问题往往出在协商参数不匹配上。模式不一致是最常见的：本端配了LACP，对端配了手动模式，两端无法协商，Eth-Trunk里所有端口都变成Unselected状态。其次是双工和速率不一致，比如对端网卡被强制成百兆而交换机侧是千兆自适应，协商直接失败。还有就是物理接口上有残留配置，比如原来做过端口镜像、配置过静态MAC，加入Eth-Trunk时报错。
这些细节看似小，实际排查起来很花时间。所以配置前养成一个好习惯：先清干净物理接口配置，确认对端设备支持LACP，再统一两端的参数，最后加端口。
3. 华为设备LACP模式配置完整实操
3.1 创建Eth-Trunk并启用LACP
华为设备上的配置入口是系统视图，先创建一个Eth-Trunk逻辑接口，再把模式切换为LACP静态模式。命令行如下：
system-view interface Eth-Trunk 1 mode lacp-static这里说明一下，华为交换机上LACP模式常用的就是mode lacp-static，它对应LACP协议中的主动协商方式，相当于主动向对端发送LACPDU，要求建立聚合关系。如果对端是某些只支持被动模式的老设备，也可以考虑mode lacp-dynamic，但绝大多数场景下两端都配置成lacp-static即可。
创建完Eth-Trunk后，可以用display eth-trunk 1查看当前状态。此时还没有加入成员端口，状态是空的是正常的，不用慌。
3.2 把成员端口加入Eth-Trunk
加入成员端口有两种写法。一种是在Eth-Trunk视图下指定端口：
interface Eth-Trunk 1 trunkport GigabitEthernet 0/0/1 trunkport GigabitEthernet 0/0/2另一种是进入物理接口视图，执行eth-trunk 1命令：
interface GigabitEthernet 0/0/1 eth-trunk 1两种方式等价，我习惯用第一种，批量添加时效率更高。注意一点：物理接口在加入Eth-Trunk之前，不能存在其他聚合配置或特殊业务配置，否则会提示接口已被使用或配置冲突。
如果是多个连续端口，华为也支持批量的写法吗？标准命令行里trunkport不支持直接写范围，需要逐条敲，或者配合脚本批量执行。生产环境里我通常把命令整理成一段脚本批量执行，效率高很多。
3.3 二层配置：Trunk放通VLAN
Eth-Trunk最终是要承载业务的，默认所有Eth-Trunk接口属于二层接口，需要配置链路类型和放通的VLAN。最常见的场景是服务器双网卡走Trunk口，下面放通业务VLAN：
interface Eth-Trunk 1 port link-type trunk port trunk allow-pass vlan 10 20如果VLAN数量多，可以用连续范围写法：
port trunk allow-pass vlan 10 to 30很多人配置完Eth-Trunk后发现业务不通，查了半天发现是VLAN没有放通。Eth-Trunk作为一个逻辑接口，它的VLAN放通配置是独立的，和物理成员接口没关系。所以一旦把物理口加入Eth-Trunk，就别再惦记在物理口下配VLAN了，所有二层配置都写到Eth-Trunk下。
3.4 对接服务器时的双端配置建议
如果Eth-Trunk对端是服务器，交换机侧的配置命令和对接交换机完全一样，但服务器侧的网卡bonding也要相应配置。Linux系统里常见的bonding模式是mode 4，对应802.3ad动态链路聚合，需要加载bonding模块并指定miimon=100做链路监控。
服务器侧命令大致如下：
modprobe bonding mode=4 miimon=100 ip link add bond0 type bond mode 802.3ad miimon 100 ip link set eth0 master bond0 ip link set eth1 master bond0Windows服务器则在网卡teaming功能里选择“LACP”或“802.3ad”模式，把两块物理网卡加入同一个团队。需要注意的是，交换机侧和服务器侧的LACP必须协商成功，否则就会出现交换机侧显示多个Selected端口、服务器侧却认为链路不通的情况。
4. 负载均衡策略怎么选
4.1 hash算法的基础维度
链路聚合的带宽叠加，依赖流量调度算法。Eth-Trunk收到数据帧后，会根据一定的hash算法计算出一个值，再根据这个值把流量分配到不同的成员链路上。华为设备上常见的hash维度包括：源MAC、目的MAC、源IP、目的IP、源目MAC、源目IP、VLAN等。
hash算法的选择直接决定流量分配是否均匀。如果业务主要是同一台服务器和外部大量客户端通信，源目IP的变化很丰富，选源目IP做hash效果就好。如果是二层交换场景，MAC地址变化更频繁，选源目MAC更合理。配置文件里可以看到当前使用的负载均衡方式。
4.2 华为负载均衡配置与验证
在Eth-Trunk视图下可以通过load-balance命令修改负载均衡方式：
interface Eth-Trunk 1 load-balance src-dst-ip我常用的方式有几种：src-dst-ip适用于IP业务，src-dst-mac适用于纯二层转发，src-ip适用于流量集中在一个目的地址但源IP分散的场景。具体选哪种，要看实际业务模型。配置完成后，用下面的命令确认生效情况：
display load-balance eth-trunk 1返回结果里会明确显示当前Eth-Trunk使用的负载均衡方式。如果发现某条成员链路流量特别大，其他链路几乎空闲，先去检查hash方式是否匹配业务特征，而不是急着判断链路聚合没生效。
4.3 实际流量不均怎么调整
即使hash方式选对了，流量也不可能做到绝对均衡。因为hash是按流分配的，一条流只能走一条链路，流太少、每条流带宽很大时，分配不均匀是正常的。举个实际的例子：如果Eth-Trunk后面只挂了一台存储设备，服务器访问存储的流量源目IP都很固定，无论怎么调hash，流量都大概率集中在一条链路上，聚合带宽形同虚设。
调整思路有三个方向：一是把hash维度调得更细，比如从src-ip改成src-dst-ip，让更多流参与分担；二是确认成员链路数是否合理，两根链路带宽接近满载时可以考虑增加到四根；三是有些高端设备支持增强型负载均衡，可以基于报文字段做更细粒度的分流，需要查看设备规格是否支持。这个环节最容易让新手困惑的点在于：不要用ping测速来验证聚合后的总带宽，因为ping属于单条流，永远只会走其中一条链路。
5. 状态查看与故障排查实录
5.1 如何看懂display eth-trunk输出
Eth-Trunk配置完成后，第一时间用display eth-trunk 1查看端口状态。会看到类似下面的信息：Eth-Trunk接口的模式是LACP，成员端口分成Selected和Unselected两类。Selected代表该端口已经被协商为活动链路，参与数据转发；Unselected代表该端口存在但没有成为活动链路，通常是因为优先级较低处于备份状态，或者协商失败。
重点关注几个字段：Local和Peer的系统优先级、端口的操作Key、端口状态。操作Key是设备根据端口速率、双工模式、基本配置自动生成的标识，两端只有操作Key匹配的端口才能聚合。如果看到端口一直处于Unselected，而两端的模式、优先级、操作Key都对得上，那就要考虑是不是物理链路本身有问题，或者对端设备根本没启用LACP。
5.2 常见五大坑与处理办法
我整理了一份高频问题对照表，基本覆盖了实际运维中90%的LACP疑难杂症：
| 现象 | 可能原因 | 处理方式 |
|---|---|---|
| 所有成员口都是Unselected | 对端未配置LACP或两端模式不一致 | 核对两端模式，统一为LACP静态模式 |
| 部分端口Selected、部分Unselected | 活动链路数受限或端口优先级差异 | 检查设备规格上限，必要时调整端口优先级 |
| 两端都是Selected但业务不通 | VLAN放通不一致或对端业务配置缺失 | 检查Eth-Trunk下VLAN配置，确认对端放通相同VLAN |
| 加入成员端口时报错 | 端口已被其他Eth-Trunk使用或有残留配置 | 先移除原有聚合配置，再重新加入 |
| 故障链路切换慢或感知不到 | LACP超时时间不一致 | 统一两端的LACP超时时间为快速模式 |
这里重点展开一下第一个问题。我遇到过一次两端都显示LACP模式，但所有端口始终协商不上的情况，查了很久发现对端设备的老版本固件里LACP实现有bug，需要升级固件才能支持动态聚合。所以排查时不要只盯配置，版本兼容性也是重点。
5.3 用日志和报文统计辅助定位
配置层面的问题用display命令就能查清楚，但物理链路质量问题和协商过程异常，需要看LACP报文的收发统计。华为设备上执行：
display lacp statistics可以查看Eth-Trunk收到的LACPDU报文数、发送的报文数。如果发送正常但接收计数为零，说明对端设备没有在发送LACP报文，问题大概率在对端。如果收发报文都在增长，但端口依然协商失败，再看看告警信息，用display trapbuffer或display logbuffer查看是否有端口协商超时的记录。
一个容易忽略的细节：如果Eth-Trunk两端直连的是光电转换器或经过中间传输设备，LACP报文可能会被中间设备过滤掉，导致协商失败。这种情况下要在传输设备上放通组播报文，或者直接改用手动模式聚合。这个坑比较隐蔽，很多人排查了一下午，最后发现是中间传输设备把LACPDU报文拦截了。
6. 进阶：跨设备聚合与堆叠
6.1 单设备聚合的局限
前面讲的Eth-Trunk配置，本质上是同一台交换机上的多个端口聚合成一个逻辑口。如果这台交换机本身出现故障，整个Eth-Trunk就全挂了，服务器双网卡虽然接在同一个Eth-Trunk上，但物理上还是连到了同一台设备，设备级冗余等于零。
真正需要设备级冗余的场景，常见于服务器双网卡分别接到两台交换机上。此时如果两台交换机没有做堆叠或集群，就不能用普通的Eth-Trunk，因为对两台独立设备来说，这属于跨设备链路聚合。
6.2 堆叠后的Eth-Trunk
华为交换机最常见的做法是先把两台交换机做堆叠，堆叠之后两台设备在逻辑上变成一台设备，原来的两台物理设备的端口统一归属到一个系统里。此时再创建Eth-Trunk，成员端口可以从两台物理设备上分别选取，配置命令和单设备完全一样。
堆叠的好处是配置简单、管理统一，Eth-Trunk里的成员端口可以跨物理设备，服务器双网卡分别接到两台交换机后，任何一台交换机故障，另一台设备上的成员端口依然正常工作。代价是堆叠本身有额外的要求，比如两台设备需要堆叠线缆互联、软件版本要一致、堆叠分裂会有一定的风险。
6.3 M-LAG的适用场景
如果两台交换机不做堆叠，又想实现跨设备链路聚合，就需要M-LAG技术。M-LAG把这个逻辑聚合口拆分到两台独立设备上，两台设备之间通过peer-link链路同步状态，对外呈现为一个聚合口。华为的中高端园区交换机和数据中心交换机都支持M-LAG，它比堆叠更灵活，因为两台设备可以是独立的故障域，一台挂了另一台完全不受影响。
M-LAG的配置复杂度比堆叠高不少，除了Eth-Trunk本身，还要配置peer-link、双活网关等。对于大多数中小企业场景，堆叠的性价比更高；如果对独立故障域有严格要求，再考虑M-LAG。这块内容单独展开可以写一整篇，这里先提个思路，等真正用到的时候再做深挖也不迟。
我个人在实际操作中的体会是，LACP配置本身不难，难点全在细节：两端模式是否一致、VLAN有没有放通、hash方式合不合理、物理链路有没有经过中间设备。很多问题用display命令逐层排查，其实很快就能定位。还是那句话，网络设备之间讲的是协商一致，单方面配置得再漂亮，对端不配合也是白搭。动手配置之前，先把两端的参数统一规划好，能少踩很多坑。
