1. 为什么同是链路聚合我却建议你选LACP模式1.1 静态聚合与LACP的本质差别有一次半夜被叫起来处理某个托管机房的网络故障现象很典型业务时断时续交换机上两根千兆物理链路都显示Up但流量严重掉包光看接口状态根本看不出问题。最后拔掉一根线故障立刻消失插回去又复现这才定位到是“两台设备之间配置了静态聚合但物理接线上有一根误跳到了别的设备”。这种场景我遇到过不止一次根子就在聚合模式的选型上。华为设备上做链路聚合常见的是两条路线一个是手工模式的静态聚合Eth-Trunk手动加入成员口不协商另一个就是标题里说的LACP模式。手工模式最大的问题是“不协商”只要本地把端口加入Eth-Trunk接口就直接参与转发不管对端是否真的在同一条聚合里、不管中间有没有串接其他设备、也不管对端端口有没有启用。好处是很简单坏处是物理接错线时它不会主动“纠错”反而会把流量双发、打环把业务搞挂。LACPLink Aggregation Control Protocol链路聚合控制协议则完全不同。它会在聚合两端周期性发送LACPDU报文双方确认彼此的身份、端口属性、优先级之后才决定哪些物理链路能成为活动成员哪些只能作为备份。换句话说它是在“握手成功”之后才让链路转发流量而不是“硬凑在一起”。所以当物理拓扑变动、某根线被误插到别的设备时LACP的协商状态会立刻异常端口要么不进入聚合要么链路抖动至少能从状态里看出问题而不会悄悄引流。1.2 手工模式与LACP怎么选选型其实不复杂核心就看对端能不能配合协商。如果两端都是支持LACP的设备华为交换机之间、华为设备与主流服务器网卡、虚拟化平台之间优先用LACP模式也就是命令里的mode lacp-static。它能保证成员口只有在双方确认后才转发同时还能配合活动链路数量限制、端口抢占、快速超时这些特性这是手工模式给不了的。只有一种情况迁就手工模式对端是非常老的设备、某些嵌入式网卡驱动不完整、或者对端只支持静态聚合而完全没法开启LACP。这时候用mode manual硬聚合是可以接受的但必须接受它“不协商”的风险物理接线、对端口状态都要人工确认到位。另外一个不少见的坑是对端网卡支持LACP但接口默认是被动模式passive两边都在等对方先发报文结果协商迟迟不成功。这种场景要么把华为侧配成主动LACP要么把对端网卡也改成主动模式不能两端都卡在被动上。1.3 为什么很多故障本质上是“没协商成”后来做了这么多年网络我越来越觉得LACP最核心的不是那些配置命令而是协商机制本身。网上教程大多是教“怎么配对、怎么敲命令”很少有文章讲清楚它为什么可以防环、为什么有的链路协商成功却不转发、为什么聚合口Up了流量还是走单根。只要把“协商”这个底子理解透后面所有排查都顺了LACP报文里带着系统优先级、系统MAC、端口优先级、端口号、操作Key等信息两端通过这些信息比对选出活动链路、确定主备关系。协商的过程中只要有一项对不上端口就不会进入正常的聚合状态。所以排查的时候与其瞎猜不如直接看协商结果哪一项没对齐就改哪一项这就是LACP排障的基本思路。2. 配置前必须吃透的三个底层机制2.1 LACPDU里到底协商了什么LACP的工作基础是LACPDULink Aggregation Control Protocol Data Unit。这个报文很小包含了几组关键信息系统优先级和系统MAC用来确认“我是谁”两端配对时比对的是这套身份信息。端口优先级和端口号用来确认“哪个成员口是哪个”并参与活动链路的选择。操作Key相当于聚合组的“身份标签”两端只有Key匹配的端口才会被拉进同一个Eth-Trunk。状态标志和超时字段包括本端是否处于Active、是否已同步、对端状态是否聚合等。处理链路聚合故障时我几乎必看display lacp negotiation verbose里面会把本端Actor和对端Partner的详细信息都列出来。很多“协商失败”其实一眼就能看出来比如系统ID对不上两端接的不是同一台设备、操作Key不一致成员口被其他配置影响、超时字段不匹配等等。这个时候再去查配置、查接线方向就非常明确。2.2 华为LACP的优先级体系华为数通设备里LACP涉及两级优先级很多人配完也没完全搞懂这里展开说。第一个是系统LACP优先级缺省32768数值越小越优先。它决定的是两端协商时谁拥有“主导权”。当链路数量超过活动链路上限时是让本端的端口优选还是让对端的端口优选是由系统优先级高的一端来决定的。一般建议在网络核心侧调低系统优先级让核心设备掌握活动链路的选择权。第二个是接口LACP优先级也缺省32768同样数值越小越优先。它决定的是“一旦链路数量受限哪些端口优先成为活动链路”。比如一个Eth-Trunk里有4个成员口但设置了lacp max active-linknumber 2那么接口优先级高的两个口成为活动链路另外两个口自动进入备份状态活动链路故障后备份口再顶上来。这个机制非常有用可以在保证带宽的同时保留冗余资源。我见过不少朋友对这两个优先级不设区分全程用缺省值结果出现链路上限时两台设备“各说各话”选出的活动口不是预期的那几根。实际操作中建议在重要的框式设备上把系统优先级调小在关键板卡或高速率端口上把接口优先级调小这样活动链路的选择就是可控的。2.3 超时机制与快速收敛LACP报文不是一直狂发它按照超时机制决定发送周期和老化速度。华为设备上常见两种慢超时Long Timeout默认的30秒周期对端3倍时间内没收到报文就判定链路超时。适合多数静态场景开销小。快超时Short Timeout1秒周期对端3倍时间内没收到就判定超时适合要求快速检测链路故障的场景。超时的作用是感知链路故障如果某根成员链路物理层还Up但中间链路异常、报文过不来LACP超时后会让该端口从聚合中退出业务会迅速切换到其他活动链路上。很多人问“物理链路都Up聚合怎么还会踢端口”其实就是这个超时机制在起作用。需要说明的是超时机制与对端必须匹配两端不一致时协商结果虽然也能起来但收敛行为会变得不可预期。华为设备上如果需要快速收敛可以在成员接口视图配置lacp timeout fast同时确认对端也配置了相同的快速超时。2.4 活动链路与备份链路的关系前面提到了活动链路上限这里再展开说清楚。LACP模式下一个Eth-Trunk的成员口可以大于实际转发所需的链路数。超出上限的端口处于备份状态不转发数据但持续参与协商、持续监控链路状态。一旦活动链路故障导致可用链路数低于上限备份端口能自动切换为活动链路。这个特性在核心侧尤其有意义四根链路做聚合平时只跑两根另外两根热备既保带宽又保冗余还不增加日常转发负担。顺带提醒一个容易误会的点备份链路虽然不转发数据但它仍然占用端口、仍在收发LACPDU所以排障时看到端口有少量报文计数并不代表业务流量在走它。要区分活动链路和备份链路直接看display eth-trunk里的状态即可。3. 华为设备LACP配置全流程可直接套用3.1 准备阶段的物理口检查配置LACP之前我习惯先把物理层条件过一遍。这里的“物理层条件”不只是说线缆插没插好而是包含几个经常被忽略的细节所有成员口的速率和双工模式必须一致。LACP不会自动纠正速率不一致的问题协商时会出现端口属性不匹配导致部分成员口无法加入聚合。所有成员口必须处于未shutdown状态。有的设备在长期维护中某个口被手动shutdown过重新做聚合时很容易漏掉。成员口不能有残留的VLAN、ACL、QoS、镜像等业务配置加入Eth-Trunk前最好先清空。如果是三层物理口需要先切换到二层模式华为设备上常见undo portswitch然后再加入Eth-Trunk或者提前确认该系列设备支持直接在三层口上创建三层聚合。这些检查和LACP本身关系不大但十次配置问题里有八次出在这种“前戏”上。3.2 创建Eth-Trunk并设置LACP模式以常见VRP命令行举例核心过程如下不同系列和版本命令细节会有出入但整体套路一致system-view interface Eth-Trunk 1 mode lacp-static load-balance src-dst-ip lacp max active-linknumber 2 lacp preempt enable quit这里逐条说明mode lacp-static把Eth-Trunk 1设为静态LACP模式。这条命令是最关键的它决定了这个聚合口走的是LACP协商而不是手工聚合。load-balance src-dst-ip设置负载分担算法。具体算法选型后面有专门章节讲这里先用最常见的源目的IP组合。lacp max active-linknumber 2限制最大活动链路数为2。如果你的场景不需要限制可以不加这条让所有成员口全部参与转发。lacp preempt enable使能端口抢占。意思是当高优先级的端口恢复后可以重新抢占成为活动链路。如果不开启抢占恢复的端口只能等现有活动链路故障后才有机会顶替。3.3 加入成员口加入成员口有两种常见方式。第一种是在Eth-Trunk视图下批量加入interface Eth-Trunk 1 trunkport GigabitEthernet0/0/1 to GigabitEthernet0/0/4 quit第二种是逐个进入物理接口视图加入interface GigabitEthernet0/0/1 eth-trunk 1 quit interface GigabitEthernet0/0/2 eth-trunk 1 quit两种方式都能用我更喜欢批量方式少敲几行命令也少犯错。不过批量方式在某些设备上仅对二层口生效如果物理口有特殊配置稳妥起见还是逐口加入。一个细节成员口一旦加入Eth-Trunk原有的接口配置就不能独立生效了相关二层/三层配置要在Eth-Trunk接口上统一配置。很多新手把VLAN配在物理口上又在Eth-Trunk上配了一遍看起来状态正常实际上转发行为错乱。记住一个原则物理口加入聚合后它只是“成员”所有对外业务配置一律在Eth-Trunk口上做。3.4 配置后的状态确认配置完不要急着测流量先确认协商状态。必看三个命令display eth-trunk 1 display lacp negotiation verbose display interface Eth-Trunk 1display eth-trunk 1查看聚合口整体状态、成员口列表、活动链路与备份链路分布。重点看Actor/Partner是否都为Selected以及每个口的成员状态。display lacp negotiation verbose查看详细的LACP协商信息适合排查协商不到一起的问题比如系统优先级、操作Key是否匹配。display interface Eth-Trunk 1查看聚合口流量计数和速率用于后续观察负载是否均匀。一个可复现的检查思路是先把display eth-trunk 1里每个成员口的状态记下来再和物理拓扑对照。如果某个物理口始终是Unselected或者不在聚合里优先怀疑物理层或配置残留而不是怀疑命令敲错了。3.5 关键参数速查下面这个表格是配置时经常涉及的参数和它们的影响收藏起来方便对照参数缺省值作用建议系统LACP优先级32768决定谁主导活动链路选择核心侧调小如4096接口LACP优先级32768决定哪些端口优先成为活动链路高速端口/主用板卡调小活动链路上限不限制超过上限的端口进入备份状态按带宽与冗余平衡设置抢占关闭高优先级端口恢复后能否重新成为活动链路核心场景建议开启超时机制慢超时影响链路故障检测速度对端支持时建议快超时负载分担算法按设备默认决定数据流如何分配到各成员链路按业务流量特征选择4. 华为设备与服务器、虚拟化平台的LACP对接细节4.1 与Linux服务器bonding对接Linux服务器做网卡绑定时LACP对应的就是bonding的mode 4802.3ad。华为侧配置静态LACP模式后Linux侧建议这样处理# 加载bonding模块 modprobe bonding # 创建bond接口 ip link add bond0 type bond mode 802.3ad # 设置LACP报文速率可选fast或slow echo fast /sys/class/net/bond0/bonding/lacp_rate # 将两块网卡加入bond ip link set ens33 master bond0 ip link set ens34 master bond0对接时最容易踩的坑是两侧协商模式不匹配华为侧虽然配置了mode lacp-static但如果Linux bond的LACP没有被正确激活比如网卡驱动没加载、bond0没有正确设置mode协商永远起不来。排查时在服务器上执行cat /proc/net/bonding/bond0确认LACP状态是否已经转为Negotiated再回到交换机上看协商信息。另一个常见问题是Linux侧的流量均衡算法和华为侧不一致。Linux bond mode 4默认使用基于哈希的发送策略可以通过xmit_hash_policy调整而华为侧也要选择对应的负载分担算法。否则即使协商成功也会出现出口流量集中在某一根物理链路上的情况。建议在两侧都采用包含IP、端口等二元组/四元组哈希的策略保证离散度。4.2 与VMware虚拟化平台对接VMware场景下LACP一般出现在两个层面标准交换机的网卡绑定或者分布式交换机上开启LACP支持。前者通常是在vSwitch属性里把负载均衡策略设为“基于IP哈希的路由Route based on IP hash”后者则要配置LACP组。对接VMware时有几个必须注意的点交换机侧必须配置为主动LACP即华为的mode lacp-static。VMware的LACP默认是被动等待还是主动发送要按实际版本确认后再决定要不要保留被动模式。虚拟化主机的多张物理网卡必须连接到同一台交换机或同一个堆叠系统的对应端口上不能一张网卡接接入交换机A、另一张网卡接交换机B除非这个场景本身用的是堆叠状态下的跨设备链路聚合。VMware的“基于IP哈希的路由”本质上也是哈希分配流量单条TCP连接仍然只会走一根物理链路。如果虚机里跑的是大型文件传输该TCP会话还是只能占满一根链路多根链路的带宽不会叠加到单会话上。在ESXi主机上核查时可以通过图形界面查看“物理适配器”的负载状态再回到华为侧对比每个成员口的流量计数确认两个方向上的分布是否合理。4.3 与Windows网卡Teaming对接Windows网卡TeamingWindows Server网卡绑定对接华为设备时模式选择要对应清楚Windows“静态成组Static Teaming”对应华为的手工静态聚合模式。Windows“动态成组Dynamic Teaming”对应华为的LACP模式。如果华为侧配了mode lacp-staticWindows侧就选动态成组不要选静态成组否则协商状态会异常。Windows Teaming里还有一个“交换机独立模式Switch Independent”的选项这种模式并不依赖交换机侧做聚合通常配合“地址哈希”分配流量跟LACP没有直接关系。如果客户明确要求华为侧做LACPWindows侧一定不能用交换机独立模式否则交换机上看到的只会是两个独立端口流量分配逻辑也是乱的。4.4 各种对接场景的通用建议对接外部设备服务器、防火墙、负载均衡器、存储设备时我建议按四个步骤走先确认对端支持什么协议再确认对端是主动还是被动模式然后统一两端超时机制最后核对负载分担策略。这四个点都对齐了聚合起来就是水到渠成的事任何一个点没对齐后面大概率要反复查。5. 链路聚合起不来的排查实战从命令到根因5.1 先看物理层别让配置背锅LACP起不来时第一步不是改配置而是先把物理层过一遍。我就见过很多次“协商状态一直显示Init”的情况最后发现是某根网线的水晶头松了重插一下就好。排查时按这个顺序来display interface GigabitEthernet0/0/1看物理口是否Up、是否有CRC错误、是否有大量input/output error。如果有错误计数持续增长优先怀疑线缆问题或光模块问题哪怕物理状态显示Up也不能排除。接着逐口检查所有成员口确认有没有被shutdown。很多项目在前期调试时临时shutdown过端口后来做聚合时忘了恢复这类问题从配置上找是找不到的。5.2 再查协商状态定位是哪一项没对齐物理层没问题就要看协商了。display lacp negotiation verbose里会有Actor和Partner两组状态我把重点字段列出来字段含义常见问题Actor System ID本端系统标识对端看到的值不是预期设备说明接线错Partner System ID对端系统标识显示为0或异常说明没收到对端LACPDUActor Key / Partner Key操作Key不一致时端口无法进入聚合Actor State / Partner State协商状态State里包含Activity、Timeout、Synchronization等标志如果Partner System ID一直是0说明本端根本没收到对端的LACPDU问题出在对端是否启用LACP、中间链路是否阻断、对端是否因为某种原因不发报文。如果两端系统ID都有但状态一直在“Expired”或“Defaulted”之间切换重点看中间链路有没有丢包、超时机制是否匹配。5.3 常见配置冲突与环路隐患协商成功了不代表万事大吉。有几个配置冲突在不熟悉LACP的人手里很容易被漏掉成员口上残留了Access VLAN或Trunk VLAN配置而Eth-Trunk口上又配了另一套VLAN两层配置打架表现为聚合口转发异常但协商状态正常。成员口分别属于不同板卡或不同模块在某些老设备上跨板卡聚合需要额外条件不是所有设备都支持随意跨板。遇到协商成功但流量不均或端口频繁Down时要检查板卡归属。有中间串接设备。LACP只能用于物理上直连的链路聚合如果中间串了一台二层交换机LACPDU和业务流量都会受到干扰极有可能出现链路反复横跳、Eth-Trunk状态时好时坏。这一点常被忽视但在托管机房、跨机柜跳线场景里非常常见。5.4 一个典型的协商成功但业务抖动的案例复盘有一次在某项目上客户报核心交换机与接入交换机之间聚合不稳定现象是Eth-Trunk显示多条链路协商成功但接口流量曲线像锯齿掉包率在高峰期飙到百分之十几。我按照上面的排查顺序走了一遍先看物理层所有成员口都Up错误计数也正常。再看协商Actor和Partner都握手成功状态是Selected看起来一切正常。然后看VLAN配置居然发现成员口上还保留着旧的PVID配置接口上既有Switchport配置又有Eth-Trunk配置立刻怀疑这里有冲突。清掉成员口上的残留配置后掉包率下降了一些但流量仍然不稳定。继续查才发现拓扑里四根线有三根是直连核心和接入的第四根线被机房施工时跳到了另一台设备上那台设备也在跑LACP两个不同系统在同一个聚合里争夺协商权。处理办法很简单把第四根线从其他设备上拆掉按直连关系重新插回接入交换机。重新查看display eth-trunk 1所有成员口状态稳定业务掉包消失。这个案例给了我一个很深的印象LACP协商成功只能说明双方“身份对上了”并不能说明物理拓扑一定正确。一旦怀疑接线问题不要怕麻烦把每一根线捋清楚尤其是聚合链路这种多条线并行的场景标签混乱是常态。5.5 配置回滚与重新加入的规范操作排查过程中如果确认是配置问题不要直接删Eth-Trunk重加不然可能引起业务闪断。我通常的做法是先把有问题的成员口从Eth-Trunk中移除undo eth-trunk。再清理该物理口上的残留配置undo switchport、undo vlan等。确认物理口恢复正常独立状态后再重新加入Eth-Trunk。每次只动一根链路观察业务影响确认无误后再动下一根。这样可以把影响面控制到最小也便于在中间态定位问题。6. 流量不均、单链路打满负载分担算法调优实测6.1 聚合后流量不均衡先看流量特征LACP聚合后的总带宽是多条物理链路相加但有个本质限制一条数据流只会经过某一根物理链路不会在中间被拆到多条链路上。以最常见的TCP会话为例同一个五元组的流量会通过同一根成员链路转发不会因为聚合就自动“分片并行”。所以如果业务里存在少量大流量会话比如大文件复制、视频监控流、数据库同步很可能出现三根链路基本空闲、一根链路长期打满的现象。这个限制不是设备问题而是链路聚合的通用原理。理解了这一点调优方向就清晰了要么从流量特征出发选择更合理的哈希算法要么在业务层面做多流拆解比如把大的数据会话拆成多个连接。6.2 华为负载分担算法的选型思路华为设备上常见的负载分担算法包括按目的MAC、源MAC、目的IP、源IP、源目的IP、源目的MAC等。算法没有绝对的对错关键看流量模型场景推荐算法理由二层交换为主大量MAC离散src-dst-macMAC地址离散度好分配更均匀三层路由为主跨网段流量多src-dst-ipIP地址哈希最适合路由场景下行流量远大于上行dst-ip目的IP离散度高下行分配均匀出口NAT场景src-dst-ip兼顾源和目的避免单一方向哈希走偏数据中心东西向流量src-dst-ip 端口设备支持时多维度哈希更均匀配置算法时要注意修改负载分担算法会导致哈希结果变化业务瞬间会重新分布到各链路但这属于正常的重新负载均衡不会丢包。不过为了稳妥还是建议在业务低峰期调整再观察各成员口流量分布。6.3 实测验证怎么看均匀不均匀调完算法不能光靠感觉要看数据。方法很简单display interface Eth-Trunk 1这条命令会把聚合口下每个成员口的瞬时速率都打出来。我一般会连续观察3-5分钟取几个时间点作对比如果某条物理链路长期占用率超过80%而其他链路只有20%-30%说明哈希算法和流量模型不匹配需要换算法再测。还有一种强行均匀的用法是配置每包轮询某些专业设备上叫增强负载分担或逐包负载分担。但逐包转发会破坏TCP报文顺序对性能要求高的场景可能造成重传这里不做推荐。常规的做法还是选择高维度的哈希算法让流量自然散开。6.4 客户最常见的误解聚合等于单流加速做网络越久越觉得“翻译”比“实现”更重要。很多业务同事看到四根千兆做了聚合第一反应是“下载速度应该到4G”。但实际上聚合是把多个大流分配到不同链路单个TCP连接依然只能走一条物理链路。两个大流可以同时各走各的一个大流永远跑不满聚合总带宽。所以项目前期如果客户明确有大带宽单流需求我会建议直接上高带宽物理链路如万兆而不是靠多根千兆聚合硬扛。这虽然不是LACP本身的问题但在选型讨论中经常被扯进来提前把预期说清楚能省掉后续很多扯皮。7. 跨设备场景与那些容易被忽略的实战细节7.1 跨设备链路聚合不是随便做的LACP本身是点对点的概念物理上要求聚合链路两端设备直连。但数据中心里经常出现“跨设备”需求核心侧有两台框式交换机接入侧交换机希望同时连接两台核心形成双归接入。这种场景必须借助堆叠、集群或跨设备链路聚合技术把两台核心在逻辑上“变成一台设备”然后接入交换机再用Eth-Trunk对接。如果两台核心没有做堆叠只是简单地把接入交换机的两张上联分别接到两台独立的交换机上然后在接入交换机上做一个Eth-Trunk这种做法在某些设备上可能协商不起来即使协商起来了对端两台设备因为没有统一协商状态极可能形成环路或转发黑洞。所以遇到跨设备聚合需求第一件事确认对端是否具备堆叠/集群基础再确认是否支持对应的跨设备Eth-Trunk特性。7.2 中间链路与串接设备问题前面案例里已经提到中间串接设备的危害这里单独再强调一次LACP的协商和流量都要求两条链路之间是干净的物理直连。中间不能有独立的交换机、分光器、光电转换器、转发器之类的设备。原因是中间设备一旦参与转发LACPDU的到达时间、内容都可能被改两端协商出来的结果就和实际拓扑不一致流量路径也未必沿着聚合成员口转发。在工程实施时我会在聚合链路两端做好明确的标签和标识避免运维后期插错。曾经有个机房项目几条聚合链路走向混乱最后是靠着标签和链路追踪一条条捋出来的那次的教训让我对“布线规范”这件事有了更高的敬畏。7.3 升级和替换设备时的顺序问题升级固件或者替换设备时聚合链路最容易出问题。常见错误是先把新设备上电再把两根聚合链路同时插到新设备上而旧设备侧还留着聚合配置中间过程可能产生环路也可能出现一台设备还没协商完成就开始转发流量造成广播风暴。我推荐的安全做法是先在旧设备上把Eth-Trunk的成员口数量降为1临时保留单活同时在新设备上把LACP配置准备好然后一根一根切换线路每根线切换后立即确认协商状态和流量是否正常最后再逐步恢复多成员。虽然过程繁琐但比业务中断要好得多。7.4 关于LACP的一些经验谈做了这么多年网络对LACP最深的体会就是它其实是个“很讲道理”的协议双方协商成功才转发协商条件不满足就乖乖待着。这份“讲道理”在平时显得啰嗦但在拓扑混乱、维护频繁的生产环境里反而能帮你挡住很多灾难。我自己养成的几个习惯分享出来供参考配置完成后一定先看一眼display eth-trunk确认每个成员口的状态每次变更前保存当前配置和状态截图出了问题能快速回退物理链路的标签上除了写“几楼几柜几设备”还要写明“聚合组编号”。这些看似琐碎的习惯在真正出故障的时候往往比任何高级特性都有用。如果你手头也有LACP场景不管是华为设备之间还是华为设备对接服务器、虚拟化、防火墙建议不要只停留在“把命令敲上去”的阶段多花点时间把协商、优先级的逻辑理一遍。配置只是最后一步理解才是真正的护城河。 
长河君 · 2026/10/23 8:24:15 · 阅读 1.2k 华为设备LACP链路聚合实战：模式选择、配置与故障排查
1. 为什么同是链路聚合我却建议你选LACP模式1.1 静态聚合与LACP的本质差别有一次半夜被叫起来处理某个托管机房的网络故障现象很典型业务时断时续交换机上两根千兆物理链路都显示Up但流量严重掉包光看接口状态根本看不出问题。最后拔掉一根线故障立刻消失插回去又复现这才定位到是“两台设备之间配置了静态聚合但物理接线上有一根误跳到了别的设备”。这种场景我遇到过不止一次根子就在聚合模式的选型上。华为设备上做链路聚合常见的是两条路线一个是手工模式的静态聚合Eth-Trunk手动加入成员口不协商另一个就是标题里说的LACP模式。手工模式最大的问题是“不协商”只要本地把端口加入Eth-Trunk接口就直接参与转发不管对端是否真的在同一条聚合里、不管中间有没有串接其他设备、也不管对端端口有没有启用。好处是很简单坏处是物理接错线时它不会主动“纠错”反而会把流量双发、打环把业务搞挂。LACPLink Aggregation Control Protocol链路聚合控制协议则完全不同。它会在聚合两端周期性发送LACPDU报文双方确认彼此的身份、端口属性、优先级之后才决定哪些物理链路能成为活动成员哪些只能作为备份。换句话说它是在“握手成功”之后才让链路转发流量而不是“硬凑在一起”。所以当物理拓扑变动、某根线被误插到别的设备时LACP的协商状态会立刻异常端口要么不进入聚合要么链路抖动至少能从状态里看出问题而不会悄悄引流。1.2 手工模式与LACP怎么选选型其实不复杂核心就看对端能不能配合协商。如果两端都是支持LACP的设备华为交换机之间、华为设备与主流服务器网卡、虚拟化平台之间优先用LACP模式也就是命令里的mode lacp-static。它能保证成员口只有在双方确认后才转发同时还能配合活动链路数量限制、端口抢占、快速超时这些特性这是手工模式给不了的。只有一种情况迁就手工模式对端是非常老的设备、某些嵌入式网卡驱动不完整、或者对端只支持静态聚合而完全没法开启LACP。这时候用mode manual硬聚合是可以接受的但必须接受它“不协商”的风险物理接线、对端口状态都要人工确认到位。另外一个不少见的坑是对端网卡支持LACP但接口默认是被动模式passive两边都在等对方先发报文结果协商迟迟不成功。这种场景要么把华为侧配成主动LACP要么把对端网卡也改成主动模式不能两端都卡在被动上。1.3 为什么很多故障本质上是“没协商成”后来做了这么多年网络我越来越觉得LACP最核心的不是那些配置命令而是协商机制本身。网上教程大多是教“怎么配对、怎么敲命令”很少有文章讲清楚它为什么可以防环、为什么有的链路协商成功却不转发、为什么聚合口Up了流量还是走单根。只要把“协商”这个底子理解透后面所有排查都顺了LACP报文里带着系统优先级、系统MAC、端口优先级、端口号、操作Key等信息两端通过这些信息比对选出活动链路、确定主备关系。协商的过程中只要有一项对不上端口就不会进入正常的聚合状态。所以排查的时候与其瞎猜不如直接看协商结果哪一项没对齐就改哪一项这就是LACP排障的基本思路。2. 配置前必须吃透的三个底层机制2.1 LACPDU里到底协商了什么LACP的工作基础是LACPDULink Aggregation Control Protocol Data Unit。这个报文很小包含了几组关键信息系统优先级和系统MAC用来确认“我是谁”两端配对时比对的是这套身份信息。端口优先级和端口号用来确认“哪个成员口是哪个”并参与活动链路的选择。操作Key相当于聚合组的“身份标签”两端只有Key匹配的端口才会被拉进同一个Eth-Trunk。状态标志和超时字段包括本端是否处于Active、是否已同步、对端状态是否聚合等。处理链路聚合故障时我几乎必看display lacp negotiation verbose里面会把本端Actor和对端Partner的详细信息都列出来。很多“协商失败”其实一眼就能看出来比如系统ID对不上两端接的不是同一台设备、操作Key不一致成员口被其他配置影响、超时字段不匹配等等。这个时候再去查配置、查接线方向就非常明确。2.2 华为LACP的优先级体系华为数通设备里LACP涉及两级优先级很多人配完也没完全搞懂这里展开说。第一个是系统LACP优先级缺省32768数值越小越优先。它决定的是两端协商时谁拥有“主导权”。当链路数量超过活动链路上限时是让本端的端口优选还是让对端的端口优选是由系统优先级高的一端来决定的。一般建议在网络核心侧调低系统优先级让核心设备掌握活动链路的选择权。第二个是接口LACP优先级也缺省32768同样数值越小越优先。它决定的是“一旦链路数量受限哪些端口优先成为活动链路”。比如一个Eth-Trunk里有4个成员口但设置了lacp max active-linknumber 2那么接口优先级高的两个口成为活动链路另外两个口自动进入备份状态活动链路故障后备份口再顶上来。这个机制非常有用可以在保证带宽的同时保留冗余资源。我见过不少朋友对这两个优先级不设区分全程用缺省值结果出现链路上限时两台设备“各说各话”选出的活动口不是预期的那几根。实际操作中建议在重要的框式设备上把系统优先级调小在关键板卡或高速率端口上把接口优先级调小这样活动链路的选择就是可控的。2.3 超时机制与快速收敛LACP报文不是一直狂发它按照超时机制决定发送周期和老化速度。华为设备上常见两种慢超时Long Timeout默认的30秒周期对端3倍时间内没收到报文就判定链路超时。适合多数静态场景开销小。快超时Short Timeout1秒周期对端3倍时间内没收到就判定超时适合要求快速检测链路故障的场景。超时的作用是感知链路故障如果某根成员链路物理层还Up但中间链路异常、报文过不来LACP超时后会让该端口从聚合中退出业务会迅速切换到其他活动链路上。很多人问“物理链路都Up聚合怎么还会踢端口”其实就是这个超时机制在起作用。需要说明的是超时机制与对端必须匹配两端不一致时协商结果虽然也能起来但收敛行为会变得不可预期。华为设备上如果需要快速收敛可以在成员接口视图配置lacp timeout fast同时确认对端也配置了相同的快速超时。2.4 活动链路与备份链路的关系前面提到了活动链路上限这里再展开说清楚。LACP模式下一个Eth-Trunk的成员口可以大于实际转发所需的链路数。超出上限的端口处于备份状态不转发数据但持续参与协商、持续监控链路状态。一旦活动链路故障导致可用链路数低于上限备份端口能自动切换为活动链路。这个特性在核心侧尤其有意义四根链路做聚合平时只跑两根另外两根热备既保带宽又保冗余还不增加日常转发负担。顺带提醒一个容易误会的点备份链路虽然不转发数据但它仍然占用端口、仍在收发LACPDU所以排障时看到端口有少量报文计数并不代表业务流量在走它。要区分活动链路和备份链路直接看display eth-trunk里的状态即可。3. 华为设备LACP配置全流程可直接套用3.1 准备阶段的物理口检查配置LACP之前我习惯先把物理层条件过一遍。这里的“物理层条件”不只是说线缆插没插好而是包含几个经常被忽略的细节所有成员口的速率和双工模式必须一致。LACP不会自动纠正速率不一致的问题协商时会出现端口属性不匹配导致部分成员口无法加入聚合。所有成员口必须处于未shutdown状态。有的设备在长期维护中某个口被手动shutdown过重新做聚合时很容易漏掉。成员口不能有残留的VLAN、ACL、QoS、镜像等业务配置加入Eth-Trunk前最好先清空。如果是三层物理口需要先切换到二层模式华为设备上常见undo portswitch然后再加入Eth-Trunk或者提前确认该系列设备支持直接在三层口上创建三层聚合。这些检查和LACP本身关系不大但十次配置问题里有八次出在这种“前戏”上。3.2 创建Eth-Trunk并设置LACP模式以常见VRP命令行举例核心过程如下不同系列和版本命令细节会有出入但整体套路一致system-view interface Eth-Trunk 1 mode lacp-static load-balance src-dst-ip lacp max active-linknumber 2 lacp preempt enable quit这里逐条说明mode lacp-static把Eth-Trunk 1设为静态LACP模式。这条命令是最关键的它决定了这个聚合口走的是LACP协商而不是手工聚合。load-balance src-dst-ip设置负载分担算法。具体算法选型后面有专门章节讲这里先用最常见的源目的IP组合。lacp max active-linknumber 2限制最大活动链路数为2。如果你的场景不需要限制可以不加这条让所有成员口全部参与转发。lacp preempt enable使能端口抢占。意思是当高优先级的端口恢复后可以重新抢占成为活动链路。如果不开启抢占恢复的端口只能等现有活动链路故障后才有机会顶替。3.3 加入成员口加入成员口有两种常见方式。第一种是在Eth-Trunk视图下批量加入interface Eth-Trunk 1 trunkport GigabitEthernet0/0/1 to GigabitEthernet0/0/4 quit第二种是逐个进入物理接口视图加入interface GigabitEthernet0/0/1 eth-trunk 1 quit interface GigabitEthernet0/0/2 eth-trunk 1 quit两种方式都能用我更喜欢批量方式少敲几行命令也少犯错。不过批量方式在某些设备上仅对二层口生效如果物理口有特殊配置稳妥起见还是逐口加入。一个细节成员口一旦加入Eth-Trunk原有的接口配置就不能独立生效了相关二层/三层配置要在Eth-Trunk接口上统一配置。很多新手把VLAN配在物理口上又在Eth-Trunk上配了一遍看起来状态正常实际上转发行为错乱。记住一个原则物理口加入聚合后它只是“成员”所有对外业务配置一律在Eth-Trunk口上做。3.4 配置后的状态确认配置完不要急着测流量先确认协商状态。必看三个命令display eth-trunk 1 display lacp negotiation verbose display interface Eth-Trunk 1display eth-trunk 1查看聚合口整体状态、成员口列表、活动链路与备份链路分布。重点看Actor/Partner是否都为Selected以及每个口的成员状态。display lacp negotiation verbose查看详细的LACP协商信息适合排查协商不到一起的问题比如系统优先级、操作Key是否匹配。display interface Eth-Trunk 1查看聚合口流量计数和速率用于后续观察负载是否均匀。一个可复现的检查思路是先把display eth-trunk 1里每个成员口的状态记下来再和物理拓扑对照。如果某个物理口始终是Unselected或者不在聚合里优先怀疑物理层或配置残留而不是怀疑命令敲错了。3.5 关键参数速查下面这个表格是配置时经常涉及的参数和它们的影响收藏起来方便对照参数缺省值作用建议系统LACP优先级32768决定谁主导活动链路选择核心侧调小如4096接口LACP优先级32768决定哪些端口优先成为活动链路高速端口/主用板卡调小活动链路上限不限制超过上限的端口进入备份状态按带宽与冗余平衡设置抢占关闭高优先级端口恢复后能否重新成为活动链路核心场景建议开启超时机制慢超时影响链路故障检测速度对端支持时建议快超时负载分担算法按设备默认决定数据流如何分配到各成员链路按业务流量特征选择4. 华为设备与服务器、虚拟化平台的LACP对接细节4.1 与Linux服务器bonding对接Linux服务器做网卡绑定时LACP对应的就是bonding的mode 4802.3ad。华为侧配置静态LACP模式后Linux侧建议这样处理# 加载bonding模块 modprobe bonding # 创建bond接口 ip link add bond0 type bond mode 802.3ad # 设置LACP报文速率可选fast或slow echo fast /sys/class/net/bond0/bonding/lacp_rate # 将两块网卡加入bond ip link set ens33 master bond0 ip link set ens34 master bond0对接时最容易踩的坑是两侧协商模式不匹配华为侧虽然配置了mode lacp-static但如果Linux bond的LACP没有被正确激活比如网卡驱动没加载、bond0没有正确设置mode协商永远起不来。排查时在服务器上执行cat /proc/net/bonding/bond0确认LACP状态是否已经转为Negotiated再回到交换机上看协商信息。另一个常见问题是Linux侧的流量均衡算法和华为侧不一致。Linux bond mode 4默认使用基于哈希的发送策略可以通过xmit_hash_policy调整而华为侧也要选择对应的负载分担算法。否则即使协商成功也会出现出口流量集中在某一根物理链路上的情况。建议在两侧都采用包含IP、端口等二元组/四元组哈希的策略保证离散度。4.2 与VMware虚拟化平台对接VMware场景下LACP一般出现在两个层面标准交换机的网卡绑定或者分布式交换机上开启LACP支持。前者通常是在vSwitch属性里把负载均衡策略设为“基于IP哈希的路由Route based on IP hash”后者则要配置LACP组。对接VMware时有几个必须注意的点交换机侧必须配置为主动LACP即华为的mode lacp-static。VMware的LACP默认是被动等待还是主动发送要按实际版本确认后再决定要不要保留被动模式。虚拟化主机的多张物理网卡必须连接到同一台交换机或同一个堆叠系统的对应端口上不能一张网卡接接入交换机A、另一张网卡接交换机B除非这个场景本身用的是堆叠状态下的跨设备链路聚合。VMware的“基于IP哈希的路由”本质上也是哈希分配流量单条TCP连接仍然只会走一根物理链路。如果虚机里跑的是大型文件传输该TCP会话还是只能占满一根链路多根链路的带宽不会叠加到单会话上。在ESXi主机上核查时可以通过图形界面查看“物理适配器”的负载状态再回到华为侧对比每个成员口的流量计数确认两个方向上的分布是否合理。4.3 与Windows网卡Teaming对接Windows网卡TeamingWindows Server网卡绑定对接华为设备时模式选择要对应清楚Windows“静态成组Static Teaming”对应华为的手工静态聚合模式。Windows“动态成组Dynamic Teaming”对应华为的LACP模式。如果华为侧配了mode lacp-staticWindows侧就选动态成组不要选静态成组否则协商状态会异常。Windows Teaming里还有一个“交换机独立模式Switch Independent”的选项这种模式并不依赖交换机侧做聚合通常配合“地址哈希”分配流量跟LACP没有直接关系。如果客户明确要求华为侧做LACPWindows侧一定不能用交换机独立模式否则交换机上看到的只会是两个独立端口流量分配逻辑也是乱的。4.4 各种对接场景的通用建议对接外部设备服务器、防火墙、负载均衡器、存储设备时我建议按四个步骤走先确认对端支持什么协议再确认对端是主动还是被动模式然后统一两端超时机制最后核对负载分担策略。这四个点都对齐了聚合起来就是水到渠成的事任何一个点没对齐后面大概率要反复查。5. 链路聚合起不来的排查实战从命令到根因5.1 先看物理层别让配置背锅LACP起不来时第一步不是改配置而是先把物理层过一遍。我就见过很多次“协商状态一直显示Init”的情况最后发现是某根网线的水晶头松了重插一下就好。排查时按这个顺序来display interface GigabitEthernet0/0/1看物理口是否Up、是否有CRC错误、是否有大量input/output error。如果有错误计数持续增长优先怀疑线缆问题或光模块问题哪怕物理状态显示Up也不能排除。接着逐口检查所有成员口确认有没有被shutdown。很多项目在前期调试时临时shutdown过端口后来做聚合时忘了恢复这类问题从配置上找是找不到的。5.2 再查协商状态定位是哪一项没对齐物理层没问题就要看协商了。display lacp negotiation verbose里会有Actor和Partner两组状态我把重点字段列出来字段含义常见问题Actor System ID本端系统标识对端看到的值不是预期设备说明接线错Partner System ID对端系统标识显示为0或异常说明没收到对端LACPDUActor Key / Partner Key操作Key不一致时端口无法进入聚合Actor State / Partner State协商状态State里包含Activity、Timeout、Synchronization等标志如果Partner System ID一直是0说明本端根本没收到对端的LACPDU问题出在对端是否启用LACP、中间链路是否阻断、对端是否因为某种原因不发报文。如果两端系统ID都有但状态一直在“Expired”或“Defaulted”之间切换重点看中间链路有没有丢包、超时机制是否匹配。5.3 常见配置冲突与环路隐患协商成功了不代表万事大吉。有几个配置冲突在不熟悉LACP的人手里很容易被漏掉成员口上残留了Access VLAN或Trunk VLAN配置而Eth-Trunk口上又配了另一套VLAN两层配置打架表现为聚合口转发异常但协商状态正常。成员口分别属于不同板卡或不同模块在某些老设备上跨板卡聚合需要额外条件不是所有设备都支持随意跨板。遇到协商成功但流量不均或端口频繁Down时要检查板卡归属。有中间串接设备。LACP只能用于物理上直连的链路聚合如果中间串了一台二层交换机LACPDU和业务流量都会受到干扰极有可能出现链路反复横跳、Eth-Trunk状态时好时坏。这一点常被忽视但在托管机房、跨机柜跳线场景里非常常见。5.4 一个典型的协商成功但业务抖动的案例复盘有一次在某项目上客户报核心交换机与接入交换机之间聚合不稳定现象是Eth-Trunk显示多条链路协商成功但接口流量曲线像锯齿掉包率在高峰期飙到百分之十几。我按照上面的排查顺序走了一遍先看物理层所有成员口都Up错误计数也正常。再看协商Actor和Partner都握手成功状态是Selected看起来一切正常。然后看VLAN配置居然发现成员口上还保留着旧的PVID配置接口上既有Switchport配置又有Eth-Trunk配置立刻怀疑这里有冲突。清掉成员口上的残留配置后掉包率下降了一些但流量仍然不稳定。继续查才发现拓扑里四根线有三根是直连核心和接入的第四根线被机房施工时跳到了另一台设备上那台设备也在跑LACP两个不同系统在同一个聚合里争夺协商权。处理办法很简单把第四根线从其他设备上拆掉按直连关系重新插回接入交换机。重新查看display eth-trunk 1所有成员口状态稳定业务掉包消失。这个案例给了我一个很深的印象LACP协商成功只能说明双方“身份对上了”并不能说明物理拓扑一定正确。一旦怀疑接线问题不要怕麻烦把每一根线捋清楚尤其是聚合链路这种多条线并行的场景标签混乱是常态。5.5 配置回滚与重新加入的规范操作排查过程中如果确认是配置问题不要直接删Eth-Trunk重加不然可能引起业务闪断。我通常的做法是先把有问题的成员口从Eth-Trunk中移除undo eth-trunk。再清理该物理口上的残留配置undo switchport、undo vlan等。确认物理口恢复正常独立状态后再重新加入Eth-Trunk。每次只动一根链路观察业务影响确认无误后再动下一根。这样可以把影响面控制到最小也便于在中间态定位问题。6. 流量不均、单链路打满负载分担算法调优实测6.1 聚合后流量不均衡先看流量特征LACP聚合后的总带宽是多条物理链路相加但有个本质限制一条数据流只会经过某一根物理链路不会在中间被拆到多条链路上。以最常见的TCP会话为例同一个五元组的流量会通过同一根成员链路转发不会因为聚合就自动“分片并行”。所以如果业务里存在少量大流量会话比如大文件复制、视频监控流、数据库同步很可能出现三根链路基本空闲、一根链路长期打满的现象。这个限制不是设备问题而是链路聚合的通用原理。理解了这一点调优方向就清晰了要么从流量特征出发选择更合理的哈希算法要么在业务层面做多流拆解比如把大的数据会话拆成多个连接。6.2 华为负载分担算法的选型思路华为设备上常见的负载分担算法包括按目的MAC、源MAC、目的IP、源IP、源目的IP、源目的MAC等。算法没有绝对的对错关键看流量模型场景推荐算法理由二层交换为主大量MAC离散src-dst-macMAC地址离散度好分配更均匀三层路由为主跨网段流量多src-dst-ipIP地址哈希最适合路由场景下行流量远大于上行dst-ip目的IP离散度高下行分配均匀出口NAT场景src-dst-ip兼顾源和目的避免单一方向哈希走偏数据中心东西向流量src-dst-ip 端口设备支持时多维度哈希更均匀配置算法时要注意修改负载分担算法会导致哈希结果变化业务瞬间会重新分布到各链路但这属于正常的重新负载均衡不会丢包。不过为了稳妥还是建议在业务低峰期调整再观察各成员口流量分布。6.3 实测验证怎么看均匀不均匀调完算法不能光靠感觉要看数据。方法很简单display interface Eth-Trunk 1这条命令会把聚合口下每个成员口的瞬时速率都打出来。我一般会连续观察3-5分钟取几个时间点作对比如果某条物理链路长期占用率超过80%而其他链路只有20%-30%说明哈希算法和流量模型不匹配需要换算法再测。还有一种强行均匀的用法是配置每包轮询某些专业设备上叫增强负载分担或逐包负载分担。但逐包转发会破坏TCP报文顺序对性能要求高的场景可能造成重传这里不做推荐。常规的做法还是选择高维度的哈希算法让流量自然散开。6.4 客户最常见的误解聚合等于单流加速做网络越久越觉得“翻译”比“实现”更重要。很多业务同事看到四根千兆做了聚合第一反应是“下载速度应该到4G”。但实际上聚合是把多个大流分配到不同链路单个TCP连接依然只能走一条物理链路。两个大流可以同时各走各的一个大流永远跑不满聚合总带宽。所以项目前期如果客户明确有大带宽单流需求我会建议直接上高带宽物理链路如万兆而不是靠多根千兆聚合硬扛。这虽然不是LACP本身的问题但在选型讨论中经常被扯进来提前把预期说清楚能省掉后续很多扯皮。7. 跨设备场景与那些容易被忽略的实战细节7.1 跨设备链路聚合不是随便做的LACP本身是点对点的概念物理上要求聚合链路两端设备直连。但数据中心里经常出现“跨设备”需求核心侧有两台框式交换机接入侧交换机希望同时连接两台核心形成双归接入。这种场景必须借助堆叠、集群或跨设备链路聚合技术把两台核心在逻辑上“变成一台设备”然后接入交换机再用Eth-Trunk对接。如果两台核心没有做堆叠只是简单地把接入交换机的两张上联分别接到两台独立的交换机上然后在接入交换机上做一个Eth-Trunk这种做法在某些设备上可能协商不起来即使协商起来了对端两台设备因为没有统一协商状态极可能形成环路或转发黑洞。所以遇到跨设备聚合需求第一件事确认对端是否具备堆叠/集群基础再确认是否支持对应的跨设备Eth-Trunk特性。7.2 中间链路与串接设备问题前面案例里已经提到中间串接设备的危害这里单独再强调一次LACP的协商和流量都要求两条链路之间是干净的物理直连。中间不能有独立的交换机、分光器、光电转换器、转发器之类的设备。原因是中间设备一旦参与转发LACPDU的到达时间、内容都可能被改两端协商出来的结果就和实际拓扑不一致流量路径也未必沿着聚合成员口转发。在工程实施时我会在聚合链路两端做好明确的标签和标识避免运维后期插错。曾经有个机房项目几条聚合链路走向混乱最后是靠着标签和链路追踪一条条捋出来的那次的教训让我对“布线规范”这件事有了更高的敬畏。7.3 升级和替换设备时的顺序问题升级固件或者替换设备时聚合链路最容易出问题。常见错误是先把新设备上电再把两根聚合链路同时插到新设备上而旧设备侧还留着聚合配置中间过程可能产生环路也可能出现一台设备还没协商完成就开始转发流量造成广播风暴。我推荐的安全做法是先在旧设备上把Eth-Trunk的成员口数量降为1临时保留单活同时在新设备上把LACP配置准备好然后一根一根切换线路每根线切换后立即确认协商状态和流量是否正常最后再逐步恢复多成员。虽然过程繁琐但比业务中断要好得多。7.4 关于LACP的一些经验谈做了这么多年网络对LACP最深的体会就是它其实是个“很讲道理”的协议双方协商成功才转发协商条件不满足就乖乖待着。这份“讲道理”在平时显得啰嗦但在拓扑混乱、维护频繁的生产环境里反而能帮你挡住很多灾难。我自己养成的几个习惯分享出来供参考配置完成后一定先看一眼display eth-trunk确认每个成员口的状态每次变更前保存当前配置和状态截图出了问题能快速回退物理链路的标签上除了写“几楼几柜几设备”还要写明“聚合组编号”。这些看似琐碎的习惯在真正出故障的时候往往比任何高级特性都有用。如果你手头也有LACP场景不管是华为设备之间还是华为设备对接服务器、虚拟化、防火墙建议不要只停留在“把命令敲上去”的阶段多花点时间把协商、优先级的逻辑理一遍。配置只是最后一步理解才是真正的护城河。