凌晨两点值班手机把我从被窝里拽了出来。客户的办公网上联做了四条链路聚合白天割接完成时测速一切正常晚上业务高峰期就开始间歇性丢包。远程登进去一看聚合口状态是 UP四个成员口也都 Link UP但二层转发计数器显示只有两个口在走流量另外两个始终是 standby。这种看着是好的实际半残的状态是我做网络运维这些年处理 LACP 协议相关问题时的最常见开局。LACPLink Aggregation Control Protocol链路聚合控制协议属于 IEEE 802.3ad现在归入 802.1AX标准作用是把多条物理以太网链路捆绑成一个逻辑链路。很多刚接触的人以为它就是多插几根网线让速度翻倍真到排障的时候才发现协议协商、成员管理、流量分发、跨厂商行为每一层都有能让你半夜爬起来查的东西。这篇文章我不打算从零抄协议文档而是按我实际排障的顺序把 LACP 从配置到故障处理到负载均衡的经验完整梳理一遍。适合刚接手园区网或数据中心接入层的运维也适合那些聚合口老是无缘无故降速的倒霉蛋。1. 先说清楚 LACP 是什么为什么两条物理链路不能直接当一条用1.1 为什么需要链路聚合要理解 LACP得从交换机之间的老问题说起。两台交换机之间如果有两条物理链路且都处于转发状态二层就会形成环路广播帧在环路里无限复制最后把整台设备打瘫痪。传统解决方案是生成树协议STP它会阻塞冗余链路只留一条转发。好处是没环路坏处也很明显你花双倍钱买了两条万兆链路实际只有一条在工作带宽冗余全浪费了。链路聚合就是冲着这个矛盾来的。把两条或更多物理链路捆绑成一个逻辑接口通常叫 Port-Channel、Eth-Trunk、Bond 等叫法不同本质一样对外表现为一个端口。生成树只看这个逻辑口不会再去逐条物理链路上做阻塞所有成员链路可以同时转发。这样既消除了环路又能叠加带宽还能提供 11 链路冗余。一条成员断了流量由剩下的成员承担整条聚合链路不中断。1.2 LACP 协议干了哪四件事LACP 本身不负责分流量它只管哪些成员口能进这个组——这个误解必须先纠正。很多人以为聚合口建起来之后协议会自动做负载均衡实际上 LACP 的职责边界非常窄窄到可能超乎你想象。具体拆开看它只做四件事发现与协商通过互发 LACPDULink Aggregation Control Protocol Data Unit让对端知道自己这边的系统 ID、端口 ID、端口优先级和操作 key双方确认这些端口可以聚到一起去。成员资格维护持续监控成员链路链路断了、配置变了及时把端口从聚合组里剔除或重新加入。状态同步通过 Actor/Partner 两个方向的状态信息保证两端对哪些口是 Selected、哪些口是 Standby达成一致。收敛加速链路状态变化时协商动作越快业务中断时间越短。LACPDU 有一个很重要的细节它是慢协议Slow Protocol目的 MAC 是 01:80:C2:00:00:02会被交换机 CPU 上送处理而且有速率限制。这意味着 LACPDU 丢失一般不是物理问题而是 CPU 拥塞或交换芯片处理慢的问题后面排查时这一点会用到。标准的 LACP 有两种超时模式短超时Short Timeout发送间隔 1 秒约 3 秒判定对端消失和长超时Long Timeout发送间隔 30 秒约 90 秒判定对端消失。用短超时收敛快但对链路抖动更敏感长超时稳定但一条链路断了要等很久才从聚合组踢出去。这两者的选择直接影响故障切换速度也是后面很多案例的根源。1.3 几个必须搞懂的状态机概念真正排障时你会看到一大堆ACT、AGG、SYNC、COL、DIST之类的状态位它们不是随便显示的本质是 LACP 状态机在对外汇报自己的情况。建议把下面几个概念吃透Actor / PartnerActor 是发出这个报文的本地设备Partner 是它眼里的对端设备。两边看到的对方状态才是协商结果。系统 ID 与优先级每个设备有一个系统优先级默认一般是 32768加上自己的 MAC 地址组成系统 ID。两边的系统 ID 和端口信息参与端口归属的计算。Key操作键一组端口的属性集合比如速率、双工方式、VLAN 配置等只有这些属性一致的端口才有资格进同一个聚合组。很多端口聚合不起来的故障本质就是 key 不一致。Selected / Standby协商完成后端口被分成两类Selected 的端口进入转发状态Standby 的端口作为备用。如果你的设备支持最大活跃端口数max-active-ports超出部分的端口会转成 Standby。这些概念听起来抽象但实际排障时就是照着它们一个个核对。下一节我们进入配置阶段的坑。2. 配置阶段最容易踩的坑模式、超时与优先级2.1 模式不匹配是头号杀手LACP 的工作模式有三个Active主动、Passive被动、On强制静态不跑 LACP。很多初学者栽的第一个跟头就是模式配法本端模式对端模式能否协商成功ActiveActive能ActivePassive能PassivePassive不能两边都在等对方先开口Active / PassiveOn静态不能LACP 报文没人回应Active 对 Active、Active 对 Passive 都能协商唯独 Passive 对 Passive 会一直沉默因为 LACP 是先发制人的必须有至少一端主动发起 LACPDU另一端才跟着回应。而 On 模式根本不跑 LACP属于静态捆绑和任何 LACP 模式都搭不到一起。这里我想多说一句Passive 不是不能用但要清楚它依赖对端先开口。有些设备比如部分防火墙、服务器网卡的 teaming 驱动默认就是 Passive如果你交换机这头也写了 Passive两条链路明明都是好的LACP 就是协商不出来。处理办法很直接一边改成 Active。我自己的习惯是两端都配 Active避免任何一端装死。2.2 超时时间快还是慢LACP 超时时间主要影响故障切换速度。短超时 3 秒就能发现对端消失长超时要 90 秒。看起来短超时全面优于长超时但实际要分场景机房内交换机到服务器、交换机到交换机链路质量稳定可以上短超时切换快。跨楼宇、跨弱电井、经过配线架的链路或者已知光模块偶发误码的环境短超时可能把一个瞬间抖动放大成一次聚合成员变更引起不必要的流量重哈希反而更痛。两端超时不一致通常也能协商因为超时字段是告诉对方你应该多久发一次。但如果一边是短超时、一边是长超时中间再夹一个三层设备或者负载均衡器做透明转发某些设备对慢协议的转发策略不一样会出现一边疯狂重传、一边迟迟不判死的情况。我的建议是两端显式配成一致不要赌默认值。还有一个细节容易被忽略LACP 报文是慢协议交换机 CPU 有限速如果设备上同时配了很多聚合口、或者 CPU 被其他协议如频繁的路由协议抖动打满LACPDU 可能被随机丢弃表现为成员口一会儿 UP 一会儿 DOWN计数器里全是超时。这种时候先去查 CPU 利用率不要一上来就怀疑光纤。2.3 端口优先级和最大活跃端口数LACP 协商完成后如果可用成员口数量超过最大活跃端口数max-active-ports / lacp max-bundle就得选出谁干活、谁 standby。选人靠两个东西端口优先级和端口号谁优先级高数值小谁先入选。这个机制本意是好的比如四根万兆里留一根做热备或者让两条不同板卡上的链路形成主备。但如果配置时不注意会出现两个经典的诡异现象一是明明四根链路都好的某一根因为端口优先级配高数值大而长期 standby带宽吃不满。二是设备重启或者拔插后优先级排序结果变了原来在转发的链路变成 standby流量路径悄悄切换有时候还会伴随一段丢包。这类问题你查物理链路全是 UP查协议协商也正常最后翻到优先级配置才明白。另外注意标准 LACP 要求聚合组内成员速率和双工一致。有些厂商允许混合速率聚合但那样做对负载均衡很不友好而且一旦协商出错低速链路会成为拥塞点。我在生产环境里基本只用同速率同型号端口做聚合。2.4 一个典型配置模板配置语法各家略有差异思路完全一致。以常见的以太网接口聚合为例# 交换机 A interface port-channel 1 description Uplink-to-SW-B switchport mode trunk switchport trunk allowed vlan 10,20,30 mtu 9216 lacp rate fast interface GigabitEthernet0/0/1 channel-group 1 mode active interface GigabitEthernet0/0/2 channel-group 1 mode active interface GigabitEthernet0/0/3 channel-group 1 mode active# 交换机 B interface port-channel 1 description Uplink-to-SW-A switchport mode trunk switchport trunk allowed vlan 10,20,30 mtu 9216 lacp rate fast interface GigabitEthernet0/0/1 channel-group 1 mode active interface GigabitEthernet0/0/2 channel-group 1 mode active interface GigabitEthernet0/0/3 channel-group 1 mode active配置注意点列几条两端聚合口上的 VLAN 配置必须一样至少交集要覆盖所有业务 VLAN。成员口的物理参数速率、双工、MTU要一致且和聚合口上的配置一致。不要把 channel-group 和其他口级配置比如单独 VLAN、ACL混在一起容易产生部分生效的坑。先配聚合口属性再把成员口加入 channel-group避免中间态误伤流量。配置阶段的问题大多是一眼能看出来的真正麻烦的是聚合口建起来之后的行为问题。下一节说排查链路。3. 聚合口起来之后仍然出问题的排查链路3.1 第一层物理链路和成员口配置核对我排 LACP 故障有个固定原则先看物理再看协议最后看流量。很多人一上来就贴邻居信息忽略了最基础的物理层。聚合口 DOWN 或者某些成员口不转发第一步永远是逐口确认每个成员口的 Link 状态是否 UP光功率是否正常有没有大量 CRC 错误、错帧。两端的速率、双工是否一致。现在全双工自适应问题少了但跨厂商旧设备混用时仍有半双工的可能。成员口上有没有被误配了 shutdown、access vlan 之类的东西。这一步要确认到每个成员口而不是聚合口整体因为 LACP 允许部分成员 UP。四个口里三个是好的、一个是坏的聚合口照样显示 UP但带宽和冗余已经缩水了。如果只看聚合口状态这种半残问题根本发现不了。3.2 第二层LACP 状态机与邻居信息核对物理层没问题再上协议层。需要抓的信息包括聚合口摘要、邻居信息、LACP 统计计数器。不同厂商命令名字不一样但信息结构类似我习惯按这几项核对每个成员口对端是不是同一个设备系统 ID 是否一致。如果两个口协商出来的 Partner System ID 不一样说明对端根本不是同一台设备聚合组貌合神离。两端互相看到的 Actor/Partner 状态。重点关注 SYNC 和 COLL/DIST 位。SYNC 表示对端认可这个端口COLL/DIST 表示进入收发聚合状态。只 SYNC 不 COLL/DIST说明端口还没真正参与转发。操作 Key 是否一致。两边 key 不一样的端口不可能进同一聚合组这时优先去查速率、双工、VLAN、MTU 这些参与 key 计算的属性。测一下 LACPDU 收发统计也有用。如果接收方向计数持续增长说明协商报文正常到达如果发送方向在涨、接收方向不动很可能对端不是 LACP比如配成了静态 On或者中间设备把慢协议给掐了。这时候用抓包软件在交换机镜像口抓 ethertype 0x8809LACP 的以太网类型的帧能直接看到是谁在发、发给谁、里面带的系统优先级是多少。3.3 第三层流量与转发行为验证协议状态全绿不代表业务就正常。聚合口建立后真正影响体验的是流量分发。我在现场常用三个验证手段看每个成员口的方向计数理想情况是多条成员口都有流量如果某条成员口方向计数长期为零说明哈希算法没有把任何流分过去或者对端有端口没有真正转发。打多层流量测试不要只 ping 网关就完事。用多源多目的 IP 加多端口的流量去测比如 iperf 起多个连接观察流量是否能分布在多条成员口上。关注丢包的位置聚合口上查成员口的 drop、error 计数如果某个口有不可解释的丢包再配合查看生成树状态、ACL、QoS 策略是否对成员口有影响。3.4 分步排查思路总结把这三层串起来就是个可以直接复用的排障流程表层级检查内容关键判断物理层成员口 Link、光功率、CRC、错帧物理全绿的端口才谈得上协商协议层LACPDU 收发包、Actor/Partner 状态、Key、System ID协商状态与成员一致性流量层成员口计数、多流测试、丢包位置聚合是否真的在同时转发一个容易忽略的点是时间顺序现场看状态要连同时间轴一起看。你看到的那一刻端口是 UP 的但十分钟前它可能 DOWN 过又恢复了。不去翻日志、翻计数器就发现不了周期闪断这种隐蔽故障。这也是下一节案例三里会讲到的内容。4. 从实际故障案例谈 LACP 的隐性雷区4.1 案例一VLAN 不一致导致的假聚合某次割接客户把服务器双网卡做 LACP 捆绑上联交换机。配置完成后聚合口协商成功四个成员口全部 Selected但业务 VLAN 里的流量时通时断一会儿能 ping 通网关一会儿完全不通。查了半天最后发现两台交换机上聚合口允许的 VLAN 列表不一样一台是 10、20、30另一台是 10、20而且其中一条成员口上被历史配置残留了一个独立的 access vlan 30。问题在于 LACP 协商本身不校验双方允许的 VLAN 交集。只要速率、双工这种 key 属性一致端口就能聚合但 VLAN 配置不一致时同一个聚合组里不同成员口能转发的 VLAN 集合不同。哈希把某个 VLAN 的流分到不支持该 VLAN 的成员口上流量就断了。这就是我说的假聚合协议上是 UP 的转发层面是残废的。处理方式是把所有成员口的 access/trunk 配置统一清掉全部以聚合口为准重新配置并要求两端完全一致。平时做批量下发时也一定要避免跳过某些口这种只改一半的配置残留是假聚合的主要来源。4.2 案例二MTU 不一致的静默黑洞另一个很隐蔽的问题出在 MTU。LACPDU 本身很小不管 MTU 是 1500 还是 9000 都能正常协商所以 MTU 不一致不会让聚合起不来。服务器或者存储网卡设了巨型帧交换机聚合口和成员口还是默认 1500小包测试一切正常一跑大流量或者备份任务就疯狂重传、卡死。原因是 IP 报文如果大于接口 MTU 且不能分片会被直接丢弃。普通 ping 的包小根本测不出来。我当时让客户做了带 DF 标志的大包测试2K 的包通、8K 的包不通双向核对之后才发现交换机聚合口 MTU 没改。处理方法是把聚合口、成员口、对端物理口整条链路两端的 MTU 统一设置。这里要特别提醒有些交换机上 MTU 是在物理口配的有些是在聚合口配的格式还分二层 MTU 和三层 IP MTU改之前先把设备的手册翻清楚。4.3 案例三端口闪断引发的哈希重排风暴第三个案例是我认为 LACP 相关故障里最难定位的一类。客户核心到接入做了四链路聚合监控上偶尔报丢包每次持续几十秒到几分钟不等然后就自己恢复。上去看的时候端口状态都是 UP聚合也很健康流量分布也正常。翻统计才发现某条成员口每隔几分钟就出现一次 Link Down/Up日志显示是光模块接收功率在临界值附近抖动。问题不在 LACP 本身但 LACP 把这个问题放大了一旦某个成员口状态变化聚合组会重新哈希原来分布在各成员口的流被重新计算瞬间大量流要切换路径转发层面出现短暂的乱序和丢包。如果闪断频率高就相当于持续在给整个聚合组挠痒痒丢包看起来毫无规律。排查思路是先通过成员口 Link 状态变化日志锁定闪断的物理口再检查对应的光模块、跳线、配线架。把闪断根源修掉之后聚合组就不再反复重哈希了。这也是我为什么强调先看物理层。如果物理问题暂时修不了可以考虑把该口设成 Standby 或者干脆踢出聚合组总比它反复祸害整条聚合链路强。4.4 案例四跨厂商互通时系统优先级打架LACP 是标准协议跨厂商一般能通但能通和按你期望的方式通是两回事。一次在防火墙与核心交换机之间做双链路聚合防火墙厂商的默认系统优先级和交换机不一样两边都希望通过优先级让特定端口成为主用结果协商完成后被选中的端口和设计文档完全相反导致一条链路负载很高、另一条闲置。LACP 的端口选择规则是先比系统优先级再比系统 MAC最后比端口优先级和端口号。两边设备默认优先级如果相同回退到 MAC 比较而不同厂商的系统 MAC 没有可比性谁大谁小完全随机。设计的时候如果对主备有要求就应该在两端显式配置 LACP 系统优先级并且全程在两个端口对的两个方向上核对协商结果而不是想当然。跨厂商还有个小坑部分厂商的 LACP 实现里聚合组内成员口数上限、是否支持短超时、最大活跃端口数的语义都不同。上线前先查一下两边版本的特性说明别拿 A 厂商的命令参数套 B 厂商的设备。5. 负载均衡与性能聚合不等于带宽翻倍5.1 哈希算法到底怎么算很多人对链路聚合有个误解四条千兆聚合成一条下载速度应该翻四倍。实际上 LACP 只负责把端口捆绑起来流量怎么分到各个成员口是交换芯片的哈希算法决定的跟 LACP 协议本身没有直接关系。哈希算法一般取报文头部的一组字段按固定算法算出一个值再映射到具体成员口。常见的字段组合有源 MAC 和目标 MAC二层哈希、源 IP 和目标 IP三层哈希、源端口和目标端口四层哈希有的设备还能加入 VLAN 编号做组合。关键特性是同一个流固定走同一个成员口这样才能保证包不乱序。但这也意味着单个 TCP 连接永远只会在一条链路上跑。5.2 流量特征决定你能否吃满带宽如果业务只有一条大流比如一个存储到一台服务器做单线程备份聚合之后的带宽上限仍然是单条链路的带宽其他成员口只能睡觉。只有并发流足够多、流与流之间字段差异足够大哈希才能把流量散开。这就是为什么聚合口明明四根线下载速度只有一根线的速度——不是协议坏了是流量模型决定的。另一个常被忽视的是哈希极化Hash Polarization。如果网络是多层聚合比如服务器双网卡聚到接入交换机接入交换机再通过四链路聚合上联到核心每一层的哈希算法和字段选择都一样那么上一层被分到一起的流在下一层很可能又被分到同一个成员口结果就是上层某条链路拥塞、下层某条链路超载其他链路闲着。解决思路是在不同层采用不同的哈希字段组合或者不同的哈希种子让两级聚合的解耦性更好。5.3 负载均衡模式选型建议负载均衡模式的选型要结合你的业务特征纯二层环境同网段大量 MAC 互访用源目的 MAC 哈希。三层路由环境用源目的 IP 哈希比 MAC 哈希更均匀。四层业务大量并发连接如 Web、数据库用源目的 IP 加端口哈希效果最好。存储场景要看存储协议特征很多存储走 iSCSI 时源 IP 固定、端口固定这时候最稳妥的是把 VLAN 或会话信息也纳入哈希尽量扩大变化字段。选型之后怎么验证我通常会在业务低峰期起多发流量比如 iperf 开 32 个连接观察各成员口的方向计数是否接近均衡。如果某条口长期高负载而其他口很闲先试换哈希模式再看单条大流是否把某条口占满。哈希模式是全局配置变更会影响现网所有聚合口最好在维护窗口操作。值得一提的高级特性是 Resilient Hashing弹性哈希部分数据中心级交换机支持在成员口变化时只重哈希受影响的流而不是全盘重排能大幅减少端口闪断带来的抖动。如果你的设备支持强烈建议打开不支持的话就只能靠物理链路质量来保证稳定了。6. 我的 LACP 维护经验清单6.1 上线前必查项目给别人做了无数次 LACP 上线支撑之后我把上线前的检查固定成了一张清单每次按顺序过一遍两端所有成员口速率、双工、MTU 一致。聚合口和成员口的 VLAN、access/trunk 配置统一两端一致。两端 LACP 模式能正常协商推荐 Active 对 Active超时模式显式统一。最大活跃端口数、最小活跃端口数符合设计预期端口优先级按主备需求配置。生成树配置聚合口上的生成树设置合理别让生成树把聚合口阻塞了。确认对端设备支持当前使用的哈希模式和 LACP 超时参数。这张清单在割接前过一遍能挡掉七成以上的上线后半夜电话。6.2 故障时的救命命令与信息真出了故障别急着猜。先把证据链拉齐下面这些信息建议在 5 分钟内抓完聚合口摘要哪些成员口是 Selected、哪些是 Standby。LACP 邻居信息每个成员口对端的 Actor/Partner 状态、系统 ID、操作 Key。成员口的物理层计数器CRC 错误、错帧、Link 状态变化次数。设备日志有没有端口 down/up、LACP 超时、CPU 过高的记录。流量计数器抓故障前后的成员口方向计数用于对照哈希分布。如果现场允许在镜像口抓一段 LACPDU过滤 ethertype 0x8809能直接看到协商报文的来源、速率、携带的优先级。很多时候比对两端的系统 ID 和优先级字段比看几十行 show 命令更快定位问题。6.3 日常监控与变更注意最后说日常运维。聚合口不是配完就能放养的我建议至少做三件事对每个成员口做 Link 状态变化监控任何成员口闪断都要有告警不要只看聚合口整体状态。定期检查是否有成员口处于 Standby 但实际带宽已经不够的情况尤其是做了 max-active-ports 设计的链路。凡是涉及聚合口相关变更调整成员口、改 VLAN、改 MTU、换光模块一律走维护窗口并且变更后立即验证成员口计数和流量分布。我个人处理 LACP 相关问题的最大体会是八成故障不是 LACP 协议本身出问题而是物理链路质量、成员口配置不一致、哈希或者生成树这些周边因素在捣乱。协议只是一个告密者把问题暴露出来的往往也是它。所以别一上来就怀疑协议按物理、协议、流量三层去剥大多数问题都能在半小时内定位。真到了协议那层还不明白记得把两端的系统 ID、优先级、Key 和超时时间拉到一起对比答案通常就写在那些字段里。 
长河君 · 2026/9/26 11:58:18 · 阅读 1.2k LACP链路聚合故障排查指南：配置、排障与负载均衡实践
凌晨两点值班手机把我从被窝里拽了出来。客户的办公网上联做了四条链路聚合白天割接完成时测速一切正常晚上业务高峰期就开始间歇性丢包。远程登进去一看聚合口状态是 UP四个成员口也都 Link UP但二层转发计数器显示只有两个口在走流量另外两个始终是 standby。这种看着是好的实际半残的状态是我做网络运维这些年处理 LACP 协议相关问题时的最常见开局。LACPLink Aggregation Control Protocol链路聚合控制协议属于 IEEE 802.3ad现在归入 802.1AX标准作用是把多条物理以太网链路捆绑成一个逻辑链路。很多刚接触的人以为它就是多插几根网线让速度翻倍真到排障的时候才发现协议协商、成员管理、流量分发、跨厂商行为每一层都有能让你半夜爬起来查的东西。这篇文章我不打算从零抄协议文档而是按我实际排障的顺序把 LACP 从配置到故障处理到负载均衡的经验完整梳理一遍。适合刚接手园区网或数据中心接入层的运维也适合那些聚合口老是无缘无故降速的倒霉蛋。1. 先说清楚 LACP 是什么为什么两条物理链路不能直接当一条用1.1 为什么需要链路聚合要理解 LACP得从交换机之间的老问题说起。两台交换机之间如果有两条物理链路且都处于转发状态二层就会形成环路广播帧在环路里无限复制最后把整台设备打瘫痪。传统解决方案是生成树协议STP它会阻塞冗余链路只留一条转发。好处是没环路坏处也很明显你花双倍钱买了两条万兆链路实际只有一条在工作带宽冗余全浪费了。链路聚合就是冲着这个矛盾来的。把两条或更多物理链路捆绑成一个逻辑接口通常叫 Port-Channel、Eth-Trunk、Bond 等叫法不同本质一样对外表现为一个端口。生成树只看这个逻辑口不会再去逐条物理链路上做阻塞所有成员链路可以同时转发。这样既消除了环路又能叠加带宽还能提供 11 链路冗余。一条成员断了流量由剩下的成员承担整条聚合链路不中断。1.2 LACP 协议干了哪四件事LACP 本身不负责分流量它只管哪些成员口能进这个组——这个误解必须先纠正。很多人以为聚合口建起来之后协议会自动做负载均衡实际上 LACP 的职责边界非常窄窄到可能超乎你想象。具体拆开看它只做四件事发现与协商通过互发 LACPDULink Aggregation Control Protocol Data Unit让对端知道自己这边的系统 ID、端口 ID、端口优先级和操作 key双方确认这些端口可以聚到一起去。成员资格维护持续监控成员链路链路断了、配置变了及时把端口从聚合组里剔除或重新加入。状态同步通过 Actor/Partner 两个方向的状态信息保证两端对哪些口是 Selected、哪些口是 Standby达成一致。收敛加速链路状态变化时协商动作越快业务中断时间越短。LACPDU 有一个很重要的细节它是慢协议Slow Protocol目的 MAC 是 01:80:C2:00:00:02会被交换机 CPU 上送处理而且有速率限制。这意味着 LACPDU 丢失一般不是物理问题而是 CPU 拥塞或交换芯片处理慢的问题后面排查时这一点会用到。标准的 LACP 有两种超时模式短超时Short Timeout发送间隔 1 秒约 3 秒判定对端消失和长超时Long Timeout发送间隔 30 秒约 90 秒判定对端消失。用短超时收敛快但对链路抖动更敏感长超时稳定但一条链路断了要等很久才从聚合组踢出去。这两者的选择直接影响故障切换速度也是后面很多案例的根源。1.3 几个必须搞懂的状态机概念真正排障时你会看到一大堆ACT、AGG、SYNC、COL、DIST之类的状态位它们不是随便显示的本质是 LACP 状态机在对外汇报自己的情况。建议把下面几个概念吃透Actor / PartnerActor 是发出这个报文的本地设备Partner 是它眼里的对端设备。两边看到的对方状态才是协商结果。系统 ID 与优先级每个设备有一个系统优先级默认一般是 32768加上自己的 MAC 地址组成系统 ID。两边的系统 ID 和端口信息参与端口归属的计算。Key操作键一组端口的属性集合比如速率、双工方式、VLAN 配置等只有这些属性一致的端口才有资格进同一个聚合组。很多端口聚合不起来的故障本质就是 key 不一致。Selected / Standby协商完成后端口被分成两类Selected 的端口进入转发状态Standby 的端口作为备用。如果你的设备支持最大活跃端口数max-active-ports超出部分的端口会转成 Standby。这些概念听起来抽象但实际排障时就是照着它们一个个核对。下一节我们进入配置阶段的坑。2. 配置阶段最容易踩的坑模式、超时与优先级2.1 模式不匹配是头号杀手LACP 的工作模式有三个Active主动、Passive被动、On强制静态不跑 LACP。很多初学者栽的第一个跟头就是模式配法本端模式对端模式能否协商成功ActiveActive能ActivePassive能PassivePassive不能两边都在等对方先开口Active / PassiveOn静态不能LACP 报文没人回应Active 对 Active、Active 对 Passive 都能协商唯独 Passive 对 Passive 会一直沉默因为 LACP 是先发制人的必须有至少一端主动发起 LACPDU另一端才跟着回应。而 On 模式根本不跑 LACP属于静态捆绑和任何 LACP 模式都搭不到一起。这里我想多说一句Passive 不是不能用但要清楚它依赖对端先开口。有些设备比如部分防火墙、服务器网卡的 teaming 驱动默认就是 Passive如果你交换机这头也写了 Passive两条链路明明都是好的LACP 就是协商不出来。处理办法很直接一边改成 Active。我自己的习惯是两端都配 Active避免任何一端装死。2.2 超时时间快还是慢LACP 超时时间主要影响故障切换速度。短超时 3 秒就能发现对端消失长超时要 90 秒。看起来短超时全面优于长超时但实际要分场景机房内交换机到服务器、交换机到交换机链路质量稳定可以上短超时切换快。跨楼宇、跨弱电井、经过配线架的链路或者已知光模块偶发误码的环境短超时可能把一个瞬间抖动放大成一次聚合成员变更引起不必要的流量重哈希反而更痛。两端超时不一致通常也能协商因为超时字段是告诉对方你应该多久发一次。但如果一边是短超时、一边是长超时中间再夹一个三层设备或者负载均衡器做透明转发某些设备对慢协议的转发策略不一样会出现一边疯狂重传、一边迟迟不判死的情况。我的建议是两端显式配成一致不要赌默认值。还有一个细节容易被忽略LACP 报文是慢协议交换机 CPU 有限速如果设备上同时配了很多聚合口、或者 CPU 被其他协议如频繁的路由协议抖动打满LACPDU 可能被随机丢弃表现为成员口一会儿 UP 一会儿 DOWN计数器里全是超时。这种时候先去查 CPU 利用率不要一上来就怀疑光纤。2.3 端口优先级和最大活跃端口数LACP 协商完成后如果可用成员口数量超过最大活跃端口数max-active-ports / lacp max-bundle就得选出谁干活、谁 standby。选人靠两个东西端口优先级和端口号谁优先级高数值小谁先入选。这个机制本意是好的比如四根万兆里留一根做热备或者让两条不同板卡上的链路形成主备。但如果配置时不注意会出现两个经典的诡异现象一是明明四根链路都好的某一根因为端口优先级配高数值大而长期 standby带宽吃不满。二是设备重启或者拔插后优先级排序结果变了原来在转发的链路变成 standby流量路径悄悄切换有时候还会伴随一段丢包。这类问题你查物理链路全是 UP查协议协商也正常最后翻到优先级配置才明白。另外注意标准 LACP 要求聚合组内成员速率和双工一致。有些厂商允许混合速率聚合但那样做对负载均衡很不友好而且一旦协商出错低速链路会成为拥塞点。我在生产环境里基本只用同速率同型号端口做聚合。2.4 一个典型配置模板配置语法各家略有差异思路完全一致。以常见的以太网接口聚合为例# 交换机 A interface port-channel 1 description Uplink-to-SW-B switchport mode trunk switchport trunk allowed vlan 10,20,30 mtu 9216 lacp rate fast interface GigabitEthernet0/0/1 channel-group 1 mode active interface GigabitEthernet0/0/2 channel-group 1 mode active interface GigabitEthernet0/0/3 channel-group 1 mode active# 交换机 B interface port-channel 1 description Uplink-to-SW-A switchport mode trunk switchport trunk allowed vlan 10,20,30 mtu 9216 lacp rate fast interface GigabitEthernet0/0/1 channel-group 1 mode active interface GigabitEthernet0/0/2 channel-group 1 mode active interface GigabitEthernet0/0/3 channel-group 1 mode active配置注意点列几条两端聚合口上的 VLAN 配置必须一样至少交集要覆盖所有业务 VLAN。成员口的物理参数速率、双工、MTU要一致且和聚合口上的配置一致。不要把 channel-group 和其他口级配置比如单独 VLAN、ACL混在一起容易产生部分生效的坑。先配聚合口属性再把成员口加入 channel-group避免中间态误伤流量。配置阶段的问题大多是一眼能看出来的真正麻烦的是聚合口建起来之后的行为问题。下一节说排查链路。3. 聚合口起来之后仍然出问题的排查链路3.1 第一层物理链路和成员口配置核对我排 LACP 故障有个固定原则先看物理再看协议最后看流量。很多人一上来就贴邻居信息忽略了最基础的物理层。聚合口 DOWN 或者某些成员口不转发第一步永远是逐口确认每个成员口的 Link 状态是否 UP光功率是否正常有没有大量 CRC 错误、错帧。两端的速率、双工是否一致。现在全双工自适应问题少了但跨厂商旧设备混用时仍有半双工的可能。成员口上有没有被误配了 shutdown、access vlan 之类的东西。这一步要确认到每个成员口而不是聚合口整体因为 LACP 允许部分成员 UP。四个口里三个是好的、一个是坏的聚合口照样显示 UP但带宽和冗余已经缩水了。如果只看聚合口状态这种半残问题根本发现不了。3.2 第二层LACP 状态机与邻居信息核对物理层没问题再上协议层。需要抓的信息包括聚合口摘要、邻居信息、LACP 统计计数器。不同厂商命令名字不一样但信息结构类似我习惯按这几项核对每个成员口对端是不是同一个设备系统 ID 是否一致。如果两个口协商出来的 Partner System ID 不一样说明对端根本不是同一台设备聚合组貌合神离。两端互相看到的 Actor/Partner 状态。重点关注 SYNC 和 COLL/DIST 位。SYNC 表示对端认可这个端口COLL/DIST 表示进入收发聚合状态。只 SYNC 不 COLL/DIST说明端口还没真正参与转发。操作 Key 是否一致。两边 key 不一样的端口不可能进同一聚合组这时优先去查速率、双工、VLAN、MTU 这些参与 key 计算的属性。测一下 LACPDU 收发统计也有用。如果接收方向计数持续增长说明协商报文正常到达如果发送方向在涨、接收方向不动很可能对端不是 LACP比如配成了静态 On或者中间设备把慢协议给掐了。这时候用抓包软件在交换机镜像口抓 ethertype 0x8809LACP 的以太网类型的帧能直接看到是谁在发、发给谁、里面带的系统优先级是多少。3.3 第三层流量与转发行为验证协议状态全绿不代表业务就正常。聚合口建立后真正影响体验的是流量分发。我在现场常用三个验证手段看每个成员口的方向计数理想情况是多条成员口都有流量如果某条成员口方向计数长期为零说明哈希算法没有把任何流分过去或者对端有端口没有真正转发。打多层流量测试不要只 ping 网关就完事。用多源多目的 IP 加多端口的流量去测比如 iperf 起多个连接观察流量是否能分布在多条成员口上。关注丢包的位置聚合口上查成员口的 drop、error 计数如果某个口有不可解释的丢包再配合查看生成树状态、ACL、QoS 策略是否对成员口有影响。3.4 分步排查思路总结把这三层串起来就是个可以直接复用的排障流程表层级检查内容关键判断物理层成员口 Link、光功率、CRC、错帧物理全绿的端口才谈得上协商协议层LACPDU 收发包、Actor/Partner 状态、Key、System ID协商状态与成员一致性流量层成员口计数、多流测试、丢包位置聚合是否真的在同时转发一个容易忽略的点是时间顺序现场看状态要连同时间轴一起看。你看到的那一刻端口是 UP 的但十分钟前它可能 DOWN 过又恢复了。不去翻日志、翻计数器就发现不了周期闪断这种隐蔽故障。这也是下一节案例三里会讲到的内容。4. 从实际故障案例谈 LACP 的隐性雷区4.1 案例一VLAN 不一致导致的假聚合某次割接客户把服务器双网卡做 LACP 捆绑上联交换机。配置完成后聚合口协商成功四个成员口全部 Selected但业务 VLAN 里的流量时通时断一会儿能 ping 通网关一会儿完全不通。查了半天最后发现两台交换机上聚合口允许的 VLAN 列表不一样一台是 10、20、30另一台是 10、20而且其中一条成员口上被历史配置残留了一个独立的 access vlan 30。问题在于 LACP 协商本身不校验双方允许的 VLAN 交集。只要速率、双工这种 key 属性一致端口就能聚合但 VLAN 配置不一致时同一个聚合组里不同成员口能转发的 VLAN 集合不同。哈希把某个 VLAN 的流分到不支持该 VLAN 的成员口上流量就断了。这就是我说的假聚合协议上是 UP 的转发层面是残废的。处理方式是把所有成员口的 access/trunk 配置统一清掉全部以聚合口为准重新配置并要求两端完全一致。平时做批量下发时也一定要避免跳过某些口这种只改一半的配置残留是假聚合的主要来源。4.2 案例二MTU 不一致的静默黑洞另一个很隐蔽的问题出在 MTU。LACPDU 本身很小不管 MTU 是 1500 还是 9000 都能正常协商所以 MTU 不一致不会让聚合起不来。服务器或者存储网卡设了巨型帧交换机聚合口和成员口还是默认 1500小包测试一切正常一跑大流量或者备份任务就疯狂重传、卡死。原因是 IP 报文如果大于接口 MTU 且不能分片会被直接丢弃。普通 ping 的包小根本测不出来。我当时让客户做了带 DF 标志的大包测试2K 的包通、8K 的包不通双向核对之后才发现交换机聚合口 MTU 没改。处理方法是把聚合口、成员口、对端物理口整条链路两端的 MTU 统一设置。这里要特别提醒有些交换机上 MTU 是在物理口配的有些是在聚合口配的格式还分二层 MTU 和三层 IP MTU改之前先把设备的手册翻清楚。4.3 案例三端口闪断引发的哈希重排风暴第三个案例是我认为 LACP 相关故障里最难定位的一类。客户核心到接入做了四链路聚合监控上偶尔报丢包每次持续几十秒到几分钟不等然后就自己恢复。上去看的时候端口状态都是 UP聚合也很健康流量分布也正常。翻统计才发现某条成员口每隔几分钟就出现一次 Link Down/Up日志显示是光模块接收功率在临界值附近抖动。问题不在 LACP 本身但 LACP 把这个问题放大了一旦某个成员口状态变化聚合组会重新哈希原来分布在各成员口的流被重新计算瞬间大量流要切换路径转发层面出现短暂的乱序和丢包。如果闪断频率高就相当于持续在给整个聚合组挠痒痒丢包看起来毫无规律。排查思路是先通过成员口 Link 状态变化日志锁定闪断的物理口再检查对应的光模块、跳线、配线架。把闪断根源修掉之后聚合组就不再反复重哈希了。这也是我为什么强调先看物理层。如果物理问题暂时修不了可以考虑把该口设成 Standby 或者干脆踢出聚合组总比它反复祸害整条聚合链路强。4.4 案例四跨厂商互通时系统优先级打架LACP 是标准协议跨厂商一般能通但能通和按你期望的方式通是两回事。一次在防火墙与核心交换机之间做双链路聚合防火墙厂商的默认系统优先级和交换机不一样两边都希望通过优先级让特定端口成为主用结果协商完成后被选中的端口和设计文档完全相反导致一条链路负载很高、另一条闲置。LACP 的端口选择规则是先比系统优先级再比系统 MAC最后比端口优先级和端口号。两边设备默认优先级如果相同回退到 MAC 比较而不同厂商的系统 MAC 没有可比性谁大谁小完全随机。设计的时候如果对主备有要求就应该在两端显式配置 LACP 系统优先级并且全程在两个端口对的两个方向上核对协商结果而不是想当然。跨厂商还有个小坑部分厂商的 LACP 实现里聚合组内成员口数上限、是否支持短超时、最大活跃端口数的语义都不同。上线前先查一下两边版本的特性说明别拿 A 厂商的命令参数套 B 厂商的设备。5. 负载均衡与性能聚合不等于带宽翻倍5.1 哈希算法到底怎么算很多人对链路聚合有个误解四条千兆聚合成一条下载速度应该翻四倍。实际上 LACP 只负责把端口捆绑起来流量怎么分到各个成员口是交换芯片的哈希算法决定的跟 LACP 协议本身没有直接关系。哈希算法一般取报文头部的一组字段按固定算法算出一个值再映射到具体成员口。常见的字段组合有源 MAC 和目标 MAC二层哈希、源 IP 和目标 IP三层哈希、源端口和目标端口四层哈希有的设备还能加入 VLAN 编号做组合。关键特性是同一个流固定走同一个成员口这样才能保证包不乱序。但这也意味着单个 TCP 连接永远只会在一条链路上跑。5.2 流量特征决定你能否吃满带宽如果业务只有一条大流比如一个存储到一台服务器做单线程备份聚合之后的带宽上限仍然是单条链路的带宽其他成员口只能睡觉。只有并发流足够多、流与流之间字段差异足够大哈希才能把流量散开。这就是为什么聚合口明明四根线下载速度只有一根线的速度——不是协议坏了是流量模型决定的。另一个常被忽视的是哈希极化Hash Polarization。如果网络是多层聚合比如服务器双网卡聚到接入交换机接入交换机再通过四链路聚合上联到核心每一层的哈希算法和字段选择都一样那么上一层被分到一起的流在下一层很可能又被分到同一个成员口结果就是上层某条链路拥塞、下层某条链路超载其他链路闲着。解决思路是在不同层采用不同的哈希字段组合或者不同的哈希种子让两级聚合的解耦性更好。5.3 负载均衡模式选型建议负载均衡模式的选型要结合你的业务特征纯二层环境同网段大量 MAC 互访用源目的 MAC 哈希。三层路由环境用源目的 IP 哈希比 MAC 哈希更均匀。四层业务大量并发连接如 Web、数据库用源目的 IP 加端口哈希效果最好。存储场景要看存储协议特征很多存储走 iSCSI 时源 IP 固定、端口固定这时候最稳妥的是把 VLAN 或会话信息也纳入哈希尽量扩大变化字段。选型之后怎么验证我通常会在业务低峰期起多发流量比如 iperf 开 32 个连接观察各成员口的方向计数是否接近均衡。如果某条口长期高负载而其他口很闲先试换哈希模式再看单条大流是否把某条口占满。哈希模式是全局配置变更会影响现网所有聚合口最好在维护窗口操作。值得一提的高级特性是 Resilient Hashing弹性哈希部分数据中心级交换机支持在成员口变化时只重哈希受影响的流而不是全盘重排能大幅减少端口闪断带来的抖动。如果你的设备支持强烈建议打开不支持的话就只能靠物理链路质量来保证稳定了。6. 我的 LACP 维护经验清单6.1 上线前必查项目给别人做了无数次 LACP 上线支撑之后我把上线前的检查固定成了一张清单每次按顺序过一遍两端所有成员口速率、双工、MTU 一致。聚合口和成员口的 VLAN、access/trunk 配置统一两端一致。两端 LACP 模式能正常协商推荐 Active 对 Active超时模式显式统一。最大活跃端口数、最小活跃端口数符合设计预期端口优先级按主备需求配置。生成树配置聚合口上的生成树设置合理别让生成树把聚合口阻塞了。确认对端设备支持当前使用的哈希模式和 LACP 超时参数。这张清单在割接前过一遍能挡掉七成以上的上线后半夜电话。6.2 故障时的救命命令与信息真出了故障别急着猜。先把证据链拉齐下面这些信息建议在 5 分钟内抓完聚合口摘要哪些成员口是 Selected、哪些是 Standby。LACP 邻居信息每个成员口对端的 Actor/Partner 状态、系统 ID、操作 Key。成员口的物理层计数器CRC 错误、错帧、Link 状态变化次数。设备日志有没有端口 down/up、LACP 超时、CPU 过高的记录。流量计数器抓故障前后的成员口方向计数用于对照哈希分布。如果现场允许在镜像口抓一段 LACPDU过滤 ethertype 0x8809能直接看到协商报文的来源、速率、携带的优先级。很多时候比对两端的系统 ID 和优先级字段比看几十行 show 命令更快定位问题。6.3 日常监控与变更注意最后说日常运维。聚合口不是配完就能放养的我建议至少做三件事对每个成员口做 Link 状态变化监控任何成员口闪断都要有告警不要只看聚合口整体状态。定期检查是否有成员口处于 Standby 但实际带宽已经不够的情况尤其是做了 max-active-ports 设计的链路。凡是涉及聚合口相关变更调整成员口、改 VLAN、改 MTU、换光模块一律走维护窗口并且变更后立即验证成员口计数和流量分布。我个人处理 LACP 相关问题的最大体会是八成故障不是 LACP 协议本身出问题而是物理链路质量、成员口配置不一致、哈希或者生成树这些周边因素在捣乱。协议只是一个告密者把问题暴露出来的往往也是它。所以别一上来就怀疑协议按物理、协议、流量三层去剥大多数问题都能在半小时内定位。真到了协议那层还不明白记得把两端的系统 ID、优先级、Key 和超时时间拉到一起对比答案通常就写在那些字段里。