1. 从一个真实故障说起：为什么单根网线永远不够用很多刚入行的网络运维同行都有过这样的经历：机房搬迁，核心交换机到接入交换机的链路只有一根千兆网线，业务高峰期一到，监控大屏上那条链路的使用率直接顶到95%以上，丢包、延迟、视频卡顿全来了。临时加一根网线？生成树协议（STP）会立刻把其中一条链路阻塞掉，带宽一点没涨，白忙活一场。这就是链路聚合要解决的核心问题。它的思路很朴素：既然一根线不够用，那就把多根物理线缆捆成一根逻辑链路，让流量同时跑在多根线上，总带宽叠加，同时任何一根线断了，剩下的线还能继续扛，业务不中断。而LACP（Link Aggregation Control Protocol，链路聚合控制协议）就是让两端设备自动协商、自动维护这条捆绑链路的“对话规则”。这篇文章面向的是需要配置华为交换机链路聚合的运维人员、备考网络认证的学员，以及遇到“聚合配了但不通”“流量只跑一根线”这类问题的工程师。我会从LACP的协商机制讲起，把华为交换机上手工模式与LACP模式的差异、负载分担的哈希逻辑、配置命令、验证方法和最常见的踩坑点全部拆开讲清楚。读完你至少能做到三件事：知道什么场景该用LACP而不是手工聚合、能独立完成一套可用的聚合配置、遇到聚合异常时知道从哪几个方向排查。需要先说明一点：链路聚合不是“配了就一定快”。它能不能提升带宽，取决于你的流量模型和负载分担算法是否匹配。这一点后面会用专门章节展开，很多人的聚合“配了个寂寞”，根子就在这里。2. LACP到底在协商什么：报文、状态机与超时机制2.1 LACPDU报文里装的是什么LACP的本质是两端设备通过交换LACPDU（Link Aggregation Control Protocol Data Unit）报文来确认“哪些端口可以绑在一起”。这个报文是二层报文，目的MAC地址是一个固定的组播地址，类型字段标识为慢协议。所谓“慢协议”，是指它的发送周期比较长，默认是每秒发一次，而不是像某些快速协议那样毫秒级交互。LACPDU里携带的关键信息包括：系统优先级、系统MAC地址、端口优先级、端口号、操作密钥（Operational Key）等。两端设备拿到对方的信息后，会做两件事：一是判断对方是不是“同一个聚合组”的成员，二是判断端口能不能加入这个组。操作密钥是一个很关键的字段，它由聚合组的配置（比如聚合模式、速率、双工等）计算得出，只有两端对应端口的操作密钥一致，端口才可能进入转发状态。这里有个容易被忽略的点：LACP协商的是“端口能不能聚合”，而不是“聚合后流量怎么走”。流量怎么分担是本地设备根据哈希算法决定的，跟对端没关系。所以你会看到一种现象——一端配置改了负载分担模式，另一端完全无感，但流量分布确实变了。2.2 端口状态机：从Selected到UnselectedLACP协议为每个端口维护一个状态机，核心状态包括：Selected（选中）：端口被选为聚合组的活动成员，可以参与流量转发。Standby（备用）：端口符合聚合条件，但因为活动端口数量达到上限（比如聚合组最大活动端口数限制），暂时作为备份。Unselected（未选中）：端口不符合聚合条件，比如速率不一致、双工不匹配、对端没有回应LACP等。端口能不能变成Selected，取决于两端的“Mux状态机”协商结果。简单说，就是双方都认为“这个端口可以一起干活”，它才会被置为转发状态。如果一端认为可以、另一端认为不行，端口就会卡在Unselected，表现为聚合组起来了但某个成员口不转发流量。2.3 超时机制：短超时与长超时LACP有两种超时模式：超时模式报文发送周期超时判定时间适用场景短超时（Fast）1秒3秒对故障切换速度要求高的场景长超时（Slow）30秒90秒常规场景，减少协议报文开销华为交换机默认使用长超时。如果你希望链路故障时能更快感知并切换，可以在接口下配置短超时。但要注意，短超时意味着LACPDU发送频率提高30倍，在端口数量多的环境下会增加一定的CPU负担，需要权衡。提示：超时模式是两端独立配置的，不要求一致。但实际经验是，如果一端短超时、一端长超时，短超时那端会因为收不到足够频繁的报文而频繁超时，导致端口震荡。所以建议两端保持一致。3. 手工聚合与LACP聚合：选错了模式，排查方向全错3.1 两种模式的本质差异华为交换机上配置链路聚合有两种模式：手工负载分担模式和LACP模式。很多人觉得“都是聚合，随便选一个”，结果出了问题连排查方向都找不到。手工模式（manual load-balance）的逻辑是：只要我把几个端口加进同一个Eth-Trunk，它们就无条件成为聚合成员，不跟对端协商。对端如果也是手工模式，那就能通；对端如果是LACP模式，那就可能出问题——因为LACP那端在等LACPDU，而手工这端根本不发。LACP模式的逻辑是：端口加入Eth-Trunk后，先进入协商状态，通过LACPDU确认对端也在这个组里，双方达成一致后才把端口置为转发。如果对端不回应，端口就一直是Unselected，不转发流量。3.2 什么场景该用哪种模式对比维度手工负载分担模式LACP模式协商机制无协商，强制聚合通过LACPDU协商对端要求对端也必须是手工模式或支持静态聚合对端必须支持并启用LACP故障检测依赖物理层状态物理层+协议层双重检测成员口数量全部成员都转发可配置活动端口上限，多余做备份配置复杂度低略高适用场景对端设备不支持LACP、服务器双网卡绑定交换机之间互联、需要协议级故障检测我的经验是：只要两端都是华为交换机且软件版本支持，优先用LACP模式。原因很简单——LACP能检测到“物理层通但协议层不通”的中间链路问题（比如中间经过了不支持聚合的传输设备），而手工模式在这种情况下会误以为链路正常，实际上流量已经断了。3.3 一个典型的误配场景曾经遇到过一个案例：一端配置了LACP模式，另一端配置了手工模式。结果LACP这端的端口全部是Unselected，业务完全不通。排查时看物理层是UP的，看Eth-Trunk也是UP的，但就是不通。最后用display lacp命令一看，对端根本没有LACPDU回应，才定位到模式不匹配。这个坑的教训是：配置聚合之前，先确认两端的聚合模式。如果对端是服务器，还要确认服务器的网卡绑定模式是否与交换机匹配。服务器侧的bond模式（如mode 4对应LACP）必须和交换机侧的LACP模式对应，否则一样不通。4. 负载分担：为什么你的聚合带宽没有叠加4.1 哈希算法决定了流量走哪根线这是链路聚合最容易被误解的地方。很多人以为“我捆了4根千兆线，总带宽就是4G，随便什么流量都能跑满4G”。实际上，链路聚合的负载分担是基于“流”的，不是基于“包”的。设备会根据报文的某些字段计算一个哈希值，然后根据哈希值选择一条成员链路。同一条流的所有报文，哈希值相同，走同一条链路。华为交换机支持的负载分担模式包括：源MAC地址：根据报文源MAC做哈希目的MAC地址：根据报文目的MAC做哈希源IP地址：根据报文源IP做哈希目的IP地址：根据报文目的IP做哈希源端口号：根据报文源端口做哈希目的端口号：根据报文目的端口做哈希组合模式：如源IP+目的IP、源IP+源端口等4.2 选错模式的后果假设你有一条从A到B的备份流量，源IP和目的IP都是固定的，只有源端口在变。如果你配置的负载分担模式是“源IP+目的IP”，那么这条流量的哈希值永远相同，永远走同一条成员链路。结果就是：4根千兆线捆在一起，实际只有1根在跑流量，另外3根闲着。带宽一点没叠加，故障切换倒是有了。反过来，如果是“源IP+源端口”模式，源端口变化会导致哈希值变化，流量就能分散到不同链路上。所以负载分担模式的选择，必须基于你的实际流量特征。4.3 怎么选：看流量模型流量特征推荐负载分担模式理由大量不同用户访问同一服务器源IP不同用户源IP不同，哈希分散同一用户访问多个服务器目的IP不同服务器目的IP不同服务器之间大量并发连接源IP+目的IP+源端口+目的端口四元组哈希，分散度最高只有少数几条大流量任意模式效果都有限流的数量太少，哈希分散空间不足注意：华为部分交换机型号支持通过load-balance命令在Eth-Trunk接口下修改负载分担模式。修改后对新建流量生效，已建立的会话可能仍然走原链路，需要等会话老化或手动清除。4.4 一个反直觉的结论如果你的流量只有一条TCP连接，那么无论怎么配置负载分担模式，它都只能走一条物理链路。因为一条TCP连接的四元组是固定的，哈希值固定，只能选一条路。这种情况下，链路聚合只能提供冗余，不能提供带宽叠加。想要单条连接跑满多根链路的总带宽，需要的是另一种技术（比如多路径传输），而不是链路聚合。所以，在规划链路聚合之前，先问自己：我的流量是“多条小流”还是“一条大流”？如果是后者，聚合的带宽叠加效果会非常有限。5. 华为交换机LACP配置实操：从零到验证通过5.1 配置前的准备工作在敲命令之前，有几件事必须先确认：两端设备的聚合模式：都用手工，或都用LACP，不能混。成员口的物理参数：速率、双工必须一致。千兆口和百兆口不能混在一个聚合组里。成员口的配置：加入Eth-Trunk之前，成员口上不能有独立的业务配置（如IP地址、VLAN等），否则加入时会报错或配置丢失。VLAN配置：Eth-Trunk接口的VLAN配置会同步到成员口，不需要在成员口上单独配。STP状态：聚合成功后，Eth-Trunk作为一个逻辑口参与STP计算，成员口的STP状态由Eth-Trunk决定。5.2 完整配置步骤以下以两台华为交换机互联为例，假设使用GigabitEthernet0/0/1到0/0/3三个端口做LACP聚合。第一台交换机配置：# 创建Eth-Trunk接口，模式设为LACP interface Eth-Trunk 1 mode lacp-static # 配置负载分担模式为源IP+目的IP load-balance src-dst-ip # 配置最大活动端口数为2，第三个口做备份 max active-linknumber 2 # 配置为Trunk口，允许VLAN 10和20通过 port link-type trunk port trunk allow-pass vlan 10 20 quit # 将物理口加入Eth-Trunk interface GigabitEthernet 0/0/1 eth-trunk 1 quit interface GigabitEthernet 0/0/2 eth-trunk 1 quit interface GigabitEthernet 0/0/3 eth-trunk 1 quit第二台交换机配置：interface Eth-Trunk 1 mode lacp-static load-balance src-dst-ip max active-linknumber 2 port link-type trunk port trunk allow-pass vlan 10 20 quit interface GigabitEthernet 0/0/1 eth-trunk 1 quit interface GigabitEthernet 0/0/2 eth-trunk 1 quit interface GigabitEthernet 0/0/3 eth-trunk 1 quit5.3 验证配置是否生效配置完成后，用以下命令验证：# 查看Eth-Trunk状态 display eth-trunk 1 # 查看LACP协商状态 display lacp peer # 查看成员口状态 display interface eth-trunk 1display eth-trunk 1的输出中，重点关注：WorkingMode：应为LACPStatus：应为UpNumber of Up Ports in Trunk：应为实际UP的成员口数量成员口列表：每个成员口的Status应为Selected如果某个成员口显示Unselected，说明它没有通过LACP协商。常见原因包括：对端没有回应LACPDU、速率双工不匹配、操作密钥不一致等。5.4 验证负载分担效果配置完负载分担模式后，怎么确认流量真的分散了？可以在Eth-Trunk接口上查看各成员口的流量统计：display interface GigabitEthernet 0/0/1 | include rate display interface GigabitEthernet 0/0/2 | include rate如果两个口的入方向/出方向速率都有明显流量，说明负载分担生效了。如果一个口跑满、另一个口几乎为零，说明哈希分散度不够，可能需要调整负载分担模式。提示：测试时最好用多条不同源IP的流量同时打，单条流量的测试结果不能代表负载分担效果。6. 聚合不通？按这个顺序排查就对了6.1 第一步：确认物理层和聚合模式先看成员口的物理状态：display interface GigabitEthernet 0/0/1确认current state是UP，Line protocol state也是UP。如果物理层DOWN，先解决物理层问题（网线、光模块、端口）。然后确认两端的聚合模式：display eth-trunk 1看WorkingMode字段。如果一端是Manual、一端是LACP，那就是模式不匹配，改成一致即可。6.2 第二步：看LACP协商状态display lacp peer这个命令会显示对端的系统优先级、系统MAC、端口信息。如果输出为空，说明没有收到对端的LACPDU。可能的原因：对端没有配置LACP中间链路阻断了LACPDU（某些传输设备会过滤慢协议报文）对端端口没有加入聚合组6.3 第三步：检查成员口是否Selecteddisplay eth-trunk 1 verbose查看每个成员口的Status字段。如果是Unselected，继续看Reason字段，常见原因有：Unselected原因含义解决方向Port not in sync端口状态未同步检查两端配置是否一致LAG ID mismatch聚合组ID不匹配确认两端Eth-Trunk编号对应Speed/Duplex mismatch速率或双工不匹配统一成员口参数Max active limit reached活动端口数达到上限调整max active-linknumber6.4 第四步：检查VLAN和STP如果聚合组状态是UP、成员口都是Selected，但业务还是不通，问题可能出在VLAN或STP上：确认Eth-Trunk接口的VLAN配置是否正确确认STP没有把Eth-Trunk接口阻塞确认成员口的VLAN配置没有被独立修改display stp brief display port vlan eth-trunk 16.5 一个隐蔽的坑：成员口配置残留有时候成员口在加入Eth-Trunk之前，上面配置了独立的VLAN或IP地址。加入Eth-Trunk后，这些配置可能不会自动清除，导致成员口的实际转发行为与Eth-Trunk不一致。排查时可以对比成员口和Eth-Trunk的配置：display current-configuration interface GigabitEthernet 0/0/1 display current-configuration interface Eth-Trunk 1如果发现成员口上有Eth-Trunk没有的配置，手动清除掉。7. 几个只有踩过才知道的实操细节7.1 跨设备聚合不是LACP能解决的LACP是单设备内的链路聚合协议，它只能把同一台设备上的多个端口捆在一起。如果你想把两台不同交换机上的端口捆成一个逻辑链路（比如服务器双网卡分别接两台交换机），那需要的是跨设备链路聚合技术（如华为的M-LAG或堆叠），LACP本身做不到。很多人一开始会混淆这两个概念，配了半天发现LACP根本不支持跨设备。7.2 聚合组的成员口数量不是越多越好理论上一个Eth-Trunk可以支持很多成员口，但实际中成员口越多，哈希分散的粒度越细，单条流的带宽反而可能下降。而且成员口多了之后，故障切换时的收敛时间也会变长。我的经验是：接入层到汇聚层用2到4个口就够了，核心层可以根据实际带宽需求适当增加，但一般不超过8个。7.3 修改负载分担模式后要清会话前面提到过，修改负载分担模式后，已建立的会话可能仍然走原链路。如果是在生产环境调整，建议在业务低峰期操作，或者手动清除相关会话表项，让流量重新哈希。7.4 LACP和STP的配合Eth-Trunk接口在STP中被视为一个逻辑端口，成员口的STP状态由Eth-Trunk统一管理。这意味着你不需要在成员口上单独配置STP参数。但要注意：如果Eth-Trunk接口被STP阻塞，所有成员口都会停止转发，这时候聚合的冗余能力就失效了。所以在设计拓扑时，要确保Eth-Trunk接口在STP中的角色是根端口或指定端口，而不是替代端口。7.5 服务器侧的bond模式要对应如果对端是服务器，服务器网卡绑定模式必须和交换机侧匹配。Linux下常见的bond模式中，mode 4对应LACP，mode 0是轮询（对应交换机的手工模式），mode 1是主备（不需要交换机聚合）。如果服务器配了mode 4但交换机配了手工模式，或者反过来，都会导致聚合不通。这个坑在服务器和交换机联调时非常常见。8. 写在最后：一点个人体会链路聚合这个技术，配置命令本身并不复杂，难的是理解它“能做什么”和“不能做什么”。我见过太多人把链路聚合当成“带宽倍增器”，结果配完之后发现流量还是跑在一根线上，然后开始怀疑设备有问题。实际上，问题往往出在流量模型和负载分担模式不匹配上。另一个体会是：LACP模式比手工模式多出来的那点配置复杂度，换来的是协议级的故障检测能力，这个交换在绝大多数场景下都是划算的。除非对端设备确实不支持LACP，否则我建议默认就用LACP模式。最后分享一个小技巧：在割接或变更之前，先用display lacp peer确认两端协商正常，再用display eth-trunk verbose确认所有成员口都是Selected，最后用流量测试验证负载分担效果。这三步走完，基本可以避免90%的聚合配置问题。
1. 从一个真实故障说起：为什么单根网线永远不够用很多刚入行的网络运维同行都有过这样的经历：机房搬迁，核心交换机到接入交换机的链路只有一根千兆网线，业务高峰期一到，监控大屏上那条链路的使用率直接顶到95%以上，丢包、延迟、视频卡顿全来了。临时加一根网线？生成树协议（STP）会立刻把其中一条链路阻塞掉，带宽一点没涨，白忙活一场。这就是链路聚合要解决的核心问题。它的思路很朴素：既然一根线不够用，那就把多根物理线缆捆成一根逻辑链路，让流量同时跑在多根线上，总带宽叠加，同时任何一根线断了，剩下的线还能继续扛，业务不中断。而LACP（Link Aggregation Control Protocol，链路聚合控制协议）就是让两端设备自动协商、自动维护这条捆绑链路的“对话规则”。这篇文章面向的是需要配置华为交换机链路聚合的运维人员、备考网络认证的学员，以及遇到“聚合配了但不通”“流量只跑一根线”这类问题的工程师。我会从LACP的协商机制讲起，把华为交换机上手工模式与LACP模式的差异、负载分担的哈希逻辑、配置命令、验证方法和最常见的踩坑点全部拆开讲清楚。读完你至少能做到三件事：知道什么场景该用LACP而不是手工聚合、能独立完成一套可用的聚合配置、遇到聚合异常时知道从哪几个方向排查。需要先说明一点：链路聚合不是“配了就一定快”。它能不能提升带宽，取决于你的流量模型和负载分担算法是否匹配。这一点后面会用专门章节展开，很多人的聚合“配了个寂寞”，根子就在这里。2. LACP到底在协商什么：报文、状态机与超时机制2.1 LACPDU报文里装的是什么LACP的本质是两端设备通过交换LACPDU（Link Aggregation Control Protocol Data Unit）报文来确认“哪些端口可以绑在一起”。这个报文是二层报文，目的MAC地址是一个固定的组播地址，类型字段标识为慢协议。所谓“慢协议”，是指它的发送周期比较长，默认是每秒发一次，而不是像某些快速协议那样毫秒级交互。LACPDU里携带的关键信息包括：系统优先级、系统MAC地址、端口优先级、端口号、操作密钥（Operational Key）等。两端设备拿到对方的信息后，会做两件事：一是判断对方是不是“同一个聚合组”的成员，二是判断端口能不能加入这个组。操作密钥是一个很关键的字段，它由聚合组的配置（比如聚合模式、速率、双工等）计算得出，只有两端对应端口的操作密钥一致，端口才可能进入转发状态。这里有个容易被忽略的点：LACP协商的是“端口能不能聚合”，而不是“聚合后流量怎么走”。流量怎么分担是本地设备根据哈希算法决定的，跟对端没关系。所以你会看到一种现象——一端配置改了负载分担模式，另一端完全无感，但流量分布确实变了。2.2 端口状态机：从Selected到UnselectedLACP协议为每个端口维护一个状态机，核心状态包括：Selected（选中）：端口被选为聚合组的活动成员，可以参与流量转发。Standby（备用）：端口符合聚合条件，但因为活动端口数量达到上限（比如聚合组最大活动端口数限制），暂时作为备份。Unselected（未选中）：端口不符合聚合条件，比如速率不一致、双工不匹配、对端没有回应LACP等。端口能不能变成Selected，取决于两端的“Mux状态机”协商结果。简单说，就是双方都认为“这个端口可以一起干活”，它才会被置为转发状态。如果一端认为可以、另一端认为不行，端口就会卡在Unselected，表现为聚合组起来了但某个成员口不转发流量。2.3 超时机制：短超时与长超时LACP有两种超时模式：超时模式报文发送周期超时判定时间适用场景短超时（Fast）1秒3秒对故障切换速度要求高的场景长超时（Slow）30秒90秒常规场景，减少协议报文开销华为交换机默认使用长超时。如果你希望链路故障时能更快感知并切换，可以在接口下配置短超时。但要注意，短超时意味着LACPDU发送频率提高30倍，在端口数量多的环境下会增加一定的CPU负担，需要权衡。提示：超时模式是两端独立配置的，不要求一致。但实际经验是，如果一端短超时、一端长超时，短超时那端会因为收不到足够频繁的报文而频繁超时，导致端口震荡。所以建议两端保持一致。3. 手工聚合与LACP聚合：选错了模式，排查方向全错3.1 两种模式的本质差异华为交换机上配置链路聚合有两种模式：手工负载分担模式和LACP模式。很多人觉得“都是聚合，随便选一个”，结果出了问题连排查方向都找不到。手工模式（manual load-balance）的逻辑是：只要我把几个端口加进同一个Eth-Trunk，它们就无条件成为聚合成员，不跟对端协商。对端如果也是手工模式，那就能通；对端如果是LACP模式，那就可能出问题——因为LACP那端在等LACPDU，而手工这端根本不发。LACP模式的逻辑是：端口加入Eth-Trunk后，先进入协商状态，通过LACPDU确认对端也在这个组里，双方达成一致后才把端口置为转发。如果对端不回应，端口就一直是Unselected，不转发流量。3.2 什么场景该用哪种模式对比维度手工负载分担模式LACP模式协商机制无协商，强制聚合通过LACPDU协商对端要求对端也必须是手工模式或支持静态聚合对端必须支持并启用LACP故障检测依赖物理层状态物理层+协议层双重检测成员口数量全部成员都转发可配置活动端口上限，多余做备份配置复杂度低略高适用场景对端设备不支持LACP、服务器双网卡绑定交换机之间互联、需要协议级故障检测我的经验是：只要两端都是华为交换机且软件版本支持，优先用LACP模式。原因很简单——LACP能检测到“物理层通但协议层不通”的中间链路问题（比如中间经过了不支持聚合的传输设备），而手工模式在这种情况下会误以为链路正常，实际上流量已经断了。3.3 一个典型的误配场景曾经遇到过一个案例：一端配置了LACP模式，另一端配置了手工模式。结果LACP这端的端口全部是Unselected，业务完全不通。排查时看物理层是UP的，看Eth-Trunk也是UP的，但就是不通。最后用display lacp命令一看，对端根本没有LACPDU回应，才定位到模式不匹配。这个坑的教训是：配置聚合之前，先确认两端的聚合模式。如果对端是服务器，还要确认服务器的网卡绑定模式是否与交换机匹配。服务器侧的bond模式（如mode 4对应LACP）必须和交换机侧的LACP模式对应，否则一样不通。4. 负载分担：为什么你的聚合带宽没有叠加4.1 哈希算法决定了流量走哪根线这是链路聚合最容易被误解的地方。很多人以为“我捆了4根千兆线，总带宽就是4G，随便什么流量都能跑满4G”。实际上，链路聚合的负载分担是基于“流”的，不是基于“包”的。设备会根据报文的某些字段计算一个哈希值，然后根据哈希值选择一条成员链路。同一条流的所有报文，哈希值相同，走同一条链路。华为交换机支持的负载分担模式包括：源MAC地址：根据报文源MAC做哈希目的MAC地址：根据报文目的MAC做哈希源IP地址：根据报文源IP做哈希目的IP地址：根据报文目的IP做哈希源端口号：根据报文源端口做哈希目的端口号：根据报文目的端口做哈希组合模式：如源IP+目的IP、源IP+源端口等4.2 选错模式的后果假设你有一条从A到B的备份流量，源IP和目的IP都是固定的，只有源端口在变。如果你配置的负载分担模式是“源IP+目的IP”，那么这条流量的哈希值永远相同，永远走同一条成员链路。结果就是：4根千兆线捆在一起，实际只有1根在跑流量，另外3根闲着。带宽一点没叠加，故障切换倒是有了。反过来，如果是“源IP+源端口”模式，源端口变化会导致哈希值变化，流量就能分散到不同链路上。所以负载分担模式的选择，必须基于你的实际流量特征。4.3 怎么选：看流量模型流量特征推荐负载分担模式理由大量不同用户访问同一服务器源IP不同用户源IP不同，哈希分散同一用户访问多个服务器目的IP不同服务器目的IP不同服务器之间大量并发连接源IP+目的IP+源端口+目的端口四元组哈希，分散度最高只有少数几条大流量任意模式效果都有限流的数量太少，哈希分散空间不足注意：华为部分交换机型号支持通过load-balance命令在Eth-Trunk接口下修改负载分担模式。修改后对新建流量生效，已建立的会话可能仍然走原链路，需要等会话老化或手动清除。4.4 一个反直觉的结论如果你的流量只有一条TCP连接，那么无论怎么配置负载分担模式，它都只能走一条物理链路。因为一条TCP连接的四元组是固定的，哈希值固定，只能选一条路。这种情况下，链路聚合只能提供冗余，不能提供带宽叠加。想要单条连接跑满多根链路的总带宽，需要的是另一种技术（比如多路径传输），而不是链路聚合。所以，在规划链路聚合之前，先问自己：我的流量是“多条小流”还是“一条大流”？如果是后者，聚合的带宽叠加效果会非常有限。5. 华为交换机LACP配置实操：从零到验证通过5.1 配置前的准备工作在敲命令之前，有几件事必须先确认：两端设备的聚合模式：都用手工，或都用LACP，不能混。成员口的物理参数：速率、双工必须一致。千兆口和百兆口不能混在一个聚合组里。成员口的配置：加入Eth-Trunk之前，成员口上不能有独立的业务配置（如IP地址、VLAN等），否则加入时会报错或配置丢失。VLAN配置：Eth-Trunk接口的VLAN配置会同步到成员口，不需要在成员口上单独配。STP状态：聚合成功后，Eth-Trunk作为一个逻辑口参与STP计算，成员口的STP状态由Eth-Trunk决定。5.2 完整配置步骤以下以两台华为交换机互联为例，假设使用GigabitEthernet0/0/1到0/0/3三个端口做LACP聚合。第一台交换机配置：# 创建Eth-Trunk接口，模式设为LACP interface Eth-Trunk 1 mode lacp-static # 配置负载分担模式为源IP+目的IP load-balance src-dst-ip # 配置最大活动端口数为2，第三个口做备份 max active-linknumber 2 # 配置为Trunk口，允许VLAN 10和20通过 port link-type trunk port trunk allow-pass vlan 10 20 quit # 将物理口加入Eth-Trunk interface GigabitEthernet 0/0/1 eth-trunk 1 quit interface GigabitEthernet 0/0/2 eth-trunk 1 quit interface GigabitEthernet 0/0/3 eth-trunk 1 quit第二台交换机配置：interface Eth-Trunk 1 mode lacp-static load-balance src-dst-ip max active-linknumber 2 port link-type trunk port trunk allow-pass vlan 10 20 quit interface GigabitEthernet 0/0/1 eth-trunk 1 quit interface GigabitEthernet 0/0/2 eth-trunk 1 quit interface GigabitEthernet 0/0/3 eth-trunk 1 quit5.3 验证配置是否生效配置完成后，用以下命令验证：# 查看Eth-Trunk状态 display eth-trunk 1 # 查看LACP协商状态 display lacp peer # 查看成员口状态 display interface eth-trunk 1display eth-trunk 1的输出中，重点关注：WorkingMode：应为LACPStatus：应为UpNumber of Up Ports in Trunk：应为实际UP的成员口数量成员口列表：每个成员口的Status应为Selected如果某个成员口显示Unselected，说明它没有通过LACP协商。常见原因包括：对端没有回应LACPDU、速率双工不匹配、操作密钥不一致等。5.4 验证负载分担效果配置完负载分担模式后，怎么确认流量真的分散了？可以在Eth-Trunk接口上查看各成员口的流量统计：display interface GigabitEthernet 0/0/1 | include rate display interface GigabitEthernet 0/0/2 | include rate如果两个口的入方向/出方向速率都有明显流量，说明负载分担生效了。如果一个口跑满、另一个口几乎为零，说明哈希分散度不够，可能需要调整负载分担模式。提示：测试时最好用多条不同源IP的流量同时打，单条流量的测试结果不能代表负载分担效果。6. 聚合不通？按这个顺序排查就对了6.1 第一步：确认物理层和聚合模式先看成员口的物理状态：display interface GigabitEthernet 0/0/1确认current state是UP，Line protocol state也是UP。如果物理层DOWN，先解决物理层问题（网线、光模块、端口）。然后确认两端的聚合模式：display eth-trunk 1看WorkingMode字段。如果一端是Manual、一端是LACP，那就是模式不匹配，改成一致即可。6.2 第二步：看LACP协商状态display lacp peer这个命令会显示对端的系统优先级、系统MAC、端口信息。如果输出为空，说明没有收到对端的LACPDU。可能的原因：对端没有配置LACP中间链路阻断了LACPDU（某些传输设备会过滤慢协议报文）对端端口没有加入聚合组6.3 第三步：检查成员口是否Selecteddisplay eth-trunk 1 verbose查看每个成员口的Status字段。如果是Unselected，继续看Reason字段，常见原因有：Unselected原因含义解决方向Port not in sync端口状态未同步检查两端配置是否一致LAG ID mismatch聚合组ID不匹配确认两端Eth-Trunk编号对应Speed/Duplex mismatch速率或双工不匹配统一成员口参数Max active limit reached活动端口数达到上限调整max active-linknumber6.4 第四步：检查VLAN和STP如果聚合组状态是UP、成员口都是Selected，但业务还是不通，问题可能出在VLAN或STP上：确认Eth-Trunk接口的VLAN配置是否正确确认STP没有把Eth-Trunk接口阻塞确认成员口的VLAN配置没有被独立修改display stp brief display port vlan eth-trunk 16.5 一个隐蔽的坑：成员口配置残留有时候成员口在加入Eth-Trunk之前，上面配置了独立的VLAN或IP地址。加入Eth-Trunk后，这些配置可能不会自动清除，导致成员口的实际转发行为与Eth-Trunk不一致。排查时可以对比成员口和Eth-Trunk的配置：display current-configuration interface GigabitEthernet 0/0/1 display current-configuration interface Eth-Trunk 1如果发现成员口上有Eth-Trunk没有的配置，手动清除掉。7. 几个只有踩过才知道的实操细节7.1 跨设备聚合不是LACP能解决的LACP是单设备内的链路聚合协议，它只能把同一台设备上的多个端口捆在一起。如果你想把两台不同交换机上的端口捆成一个逻辑链路（比如服务器双网卡分别接两台交换机），那需要的是跨设备链路聚合技术（如华为的M-LAG或堆叠），LACP本身做不到。很多人一开始会混淆这两个概念，配了半天发现LACP根本不支持跨设备。7.2 聚合组的成员口数量不是越多越好理论上一个Eth-Trunk可以支持很多成员口，但实际中成员口越多，哈希分散的粒度越细，单条流的带宽反而可能下降。而且成员口多了之后，故障切换时的收敛时间也会变长。我的经验是：接入层到汇聚层用2到4个口就够了，核心层可以根据实际带宽需求适当增加，但一般不超过8个。7.3 修改负载分担模式后要清会话前面提到过，修改负载分担模式后，已建立的会话可能仍然走原链路。如果是在生产环境调整，建议在业务低峰期操作，或者手动清除相关会话表项，让流量重新哈希。7.4 LACP和STP的配合Eth-Trunk接口在STP中被视为一个逻辑端口，成员口的STP状态由Eth-Trunk统一管理。这意味着你不需要在成员口上单独配置STP参数。但要注意：如果Eth-Trunk接口被STP阻塞，所有成员口都会停止转发，这时候聚合的冗余能力就失效了。所以在设计拓扑时，要确保Eth-Trunk接口在STP中的角色是根端口或指定端口，而不是替代端口。7.5 服务器侧的bond模式要对应如果对端是服务器，服务器网卡绑定模式必须和交换机侧匹配。Linux下常见的bond模式中，mode 4对应LACP，mode 0是轮询（对应交换机的手工模式），mode 1是主备（不需要交换机聚合）。如果服务器配了mode 4但交换机配了手工模式，或者反过来，都会导致聚合不通。这个坑在服务器和交换机联调时非常常见。8. 写在最后：一点个人体会链路聚合这个技术，配置命令本身并不复杂，难的是理解它“能做什么”和“不能做什么”。我见过太多人把链路聚合当成“带宽倍增器”，结果配完之后发现流量还是跑在一根线上，然后开始怀疑设备有问题。实际上，问题往往出在流量模型和负载分担模式不匹配上。另一个体会是：LACP模式比手工模式多出来的那点配置复杂度，换来的是协议级的故障检测能力，这个交换在绝大多数场景下都是划算的。除非对端设备确实不支持LACP，否则我建议默认就用LACP模式。最后分享一个小技巧：在割接或变更之前，先用display lacp peer确认两端协商正常，再用display eth-trunk verbose确认所有成员口都是Selected，最后用流量测试验证负载分担效果。这三步走完，基本可以避免90%的聚合配置问题。