最近处理了好几个网络故障根源都落在同一个点上——LACP 协议协商异常。有一个现场特别典型核心交换机到服务器做了四条万兆口捆绑业务高峰期延迟直接飙到几十毫秒丢包率看着不高但应用就是卡得没法用。排查到最后问题出在两端 LACP 的 system priority 配置和超时机制上。这类问题在现网里太常见了而且非常隐蔽不是简单地看一眼接口 up 没 up 就能定位的。我把这段时间踩过的坑、做过的试验和最终沉淀下来的排查思路整理成这篇博文希望对正在跟链路聚合较劲的人有帮助。1. LACP 的核心机制与配置前必须想清楚的事1.1 LACP 到底解决了什么问题我先用大白话把 LACP 的作用说清楚。链路聚合英文 Link Aggregation它的核心目标是把多个物理端口捆绑成一个逻辑端口。为什么要这么干两个直接原因带宽叠加和链路冗余。比如你有一台存储服务器后端挂了两块万兆网卡分别连接到交换机的两个万兆口。如果不做链路聚合这两条链路就是两条独立的路径服务器和交换机之间跑业务只能选其中一条另一条要么做备胎要么干脆闲置。LACP 出现之后两端通过互相发送 LACP 数据单元LACPDU来协商把两条甚至更多物理链路组合成一个逻辑链路转发面看到的就是一个端口带宽翻倍同时任何一条物理链路断掉流量自动切换到剩下的链路上业务不中断。这里有一个很重要的认知点LACP 不是唯一的链路聚合方式。业界还有一种叫静态链路聚合或者叫手工聚合它不需要协议协商两端配置好捆绑关系后直接把物理口加入聚合组就行。而 LACP 是加入了协议协商的动态聚合它比静态聚合多了几个关键能力——自动检测对端配置是否一致、自动感知链路状态变化、当某一侧配置出错时能阻止链路进入转发状态。换句话说LACP 在一定程度上是一种自愈型的聚合方式这也是为什么现在数据中心和园区网里绝大多数都推荐使用 LACP 而不是静态聚合。1.2 LACP 的运行机制系统优先级、Actor 与 Partner 的概念很多初学者看到 LACP 的报文格式就头大其实不用去背那些字节偏移量抓住几个核心概念就够了。LACP 报文里最关键的信息可以拆成两大部分一个是系统层面的标识一个是端口层面的标识。系统层面用的是系统优先级System Priority加系统 MAC 地址组合起来形成一个全局唯一的 System ID端口层面用的是端口优先级Port Priority加端口号形成 Port ID。在协商过程中每一端都要把自己的系统信息和端口信息告诉对端同时也要学习对端的系统信息和端口信息所以 LACP 协议里有 Actor主动方和 Partner对端两套信息字段。你在设备上敲命令查看 LACP 状态时经常会看到 Actor System ID、Partner System ID 这样的输出说的就是这两套信息。聚合组能不能建立成功关键在于两端协商出来的结果是否一致。具体来说LACP 会按照以下逻辑确定哪些端口能够聚合两端必须都能识别彼此发出的 LACPDU也就是说两端至少有一端处于 Active主动模式。系统优先级用来决定哪一端拥有决策权。优先级数值越小越优如果系统优先级相同就比较系统 MAC 地址MAC 地址越小越优。拥有优势的那一方会成为 LACP 的决策方它来决定哪些端口可以加入聚合组。端口优先级用来决定在资源受限时优先选择哪些端口加入聚合组。比如一台设备的聚合组成员上限只有 8 个但你配置了 12 个端口那端口优先级更高数值更小的端口会被优先选中。这两套优先级体系互相配合最终决定链路聚合的结果。很多人配置 LACP 时只关注端口是否 join 进去了忽略了系统优先级的作用这在两端都是默认优先级的情况下问题不大但如果两侧都是默认值且出现了 MAC 地址大小比较的场景最终形成的聚合组可能会和你预想的不一样。下面我会在配置规划和故障排查部分展开讲。1.3 Active 和 Passive模式选错一步都起不来LACP 有两种工作模式Active主动模式和 Passive被动模式。Active 模式的特点是设备主动向对端发送 LACPDU 报文主动发起协商。Passive 模式则相反设备不会主动发送 LACPDU只有当收到对端发来的 LACPDU 之后它才会回应并参与协商。这就引出了 LACP 配置里的第一条铁律链路两端至少有一端必须是 Active 模式。如果两端都是 Passive那么链路永远协商不起来聚合组始终处于 down 状态。我在实际项目中见过很多次这样的情况工程师配置了两台交换机之间的跨设备链路聚合两端都图省事直接配了 Passive结果插上线缆之后发现聚合组始终起不来。查了端口状态、物理层、光模块都正常最后才发现是两端模式都是被动谁都不肯先开口说话。那么实际部署中应该怎么选模式我个人的建议是核心侧设备配置 Active接入侧或终端侧设备配置 Passive。原因很好理解——核心侧通常承担着汇聚和调度的职责主动发起协商有利于快速建立聚合终端侧配置 Passive 则可以让它等待核心侧发起协商减少不必要的报文交互。当然如果终端侧需要主动感知链路状态变化也可以配置成 Active这没有绝对的对错只要保证两端至少有一端 Active 即可。2. 配置 LACP 之前的设计规划这些参数不先定好后面全是坑2.1 聚合模式选择静态聚合还是 LACP 动态聚合在选择链路聚合方式时首先要考虑的是业务场景。静态聚合也叫手工负载均衡聚合特点是配置简单不需要协商报文只要物理链路连通、两端配置一致聚合组就能工作。它适合一些对配置简洁性要求高、链路数量少并且不会频繁变动的场景。但静态聚合有一个致命弱点它无法感知对端的配置状态。假设你在一台交换机上配置了静态聚合组包含 4 个端口但另一端只把其中 2 个端口做了捆绑另外 2 个端口还是普通接入模式那么静态聚合侧是没有任何告警的它只会傻傻地把流量按照负载均衡算法从 4 个端口发出去其中有 2 个端口发出去的流量对端根本不认这就会造成丢包。这种故障非常隐蔽排查起来极其消耗时间。而 LACP 动态聚合通过报文协商可以在链路建立之前就校验对端配置是否一致如果某一侧配错了端口不会进入转发状态通过设备日志和 show 命令能明显看到异常。所以我个人强烈建议除了那种设备特别老旧、不支持 LACP 的老古董之外一律使用 LACP 动态聚合。它带来的配置复杂度增加不多但排障效率和安全系数高出一大截。2.2 参数规划系统优先级、端口优先级、超时时间LACP 聚合能否按预期工作很大程度上取决于这几个参数的规划第一个是系统优先级。取值范围通常是 0 到 65535数值越小优先级越高默认值一般是 32768。在多台设备互联做跨设备链路聚合的时候系统优先级决定了哪一端拥有最终决策权。我建议在规划阶段就明确指定决策端比如把汇聚交换机或者核心交换机的系统优先级改小比如设为 4096把接入交换机和服务器网卡侧保持默认值或调大这样能够确保聚合组的建立过程是稳定可控的。第二个是端口优先级。同样取值范围 0 到 65535默认为 32768。当需要控制具体哪些端口优先加入聚合组时就需要调整端口优先级。比如设备限制聚合组最大成员数为 8而你有 10 个候选端口这时端口优先级高的会被保留其他端口会处于 Standby 状态。合理设置端口优先级可以做到让关键的、速率更高的端口优先成为活跃成员。第三个是超时时间。LACP 支持短超时Short Timeout和长超时Long Timeout两种模式。短超时一般对应 1 秒的接收超时也就是说每隔 1 秒发送一次 LACPDU对端如果在 3 秒内没有收到报文就认为链路中断长超时对应 30 秒超时通常每 30 秒发送一次报文。短超时可以更快地感知链路故障但消耗的系统资源和带宽也更多长超时则相反。对于关键链路我会倾向于使用短超时模式来做快速故障收敛但要注意对端也必须支持并配置一致。这些参数在两端设备上必须保持匹配否则会引发协商异常。比如一端配置了短超时另一端使用默认长超时那么短超时一端可能会因为收不到预期频率的 LACPDU 而频繁重置链路状态导致聚合组震荡。2.3 成员端口的一致性要求速率、双工、VLAN 都不能有差异这是一个特别基础但特别容易被忽略的检查点。LACP 要求加入同一个聚合组的所有成员端口必须满足一致性条件具体包括端口速率必须一致。10G 端口不能和 25G 端口混绑在一个聚合组里。双工模式必须一致。全双工端口不能半双工端口混用。端口类型必须一致。二层口和三层口不能混绑。VLAN 配置必须一致。如果端口是 trunk 口允许通过的 VLAN 列表要一致如果是 access 口默认 VLAN 要一致。端口的 STP 相关配置建议一致避免出现环路计算不一致的问题。如果这些条件不满足即使物理链路都是通的LACP 协商也可能会失败或者协商成功后数据转发异常。我曾经遇到过一个案例服务器侧两个千兆口连接交换机一个口是 access VLAN 10另一个口是 trunk 允许 VLAN 10、20然后做了 LACP 聚合结果聚合组虽然建起来了但 VLAN 20 的流量时通时不通特别难查。最后一看就是因为两个端口的 VLAN 配置不一致协商过程中虽然系统优先级、端口优先级都对但成员口接收到的帧类型不对导致部分流量被丢弃。所以在配置 LACP 之前把成员端口的基础配置拉平是必须做的前置动作。这里没有什么捷径就是细心把每一条配置都验证一遍。3. 实操过程LACP 配置的完整步骤与参数调优3.1 环境说明与规划示例我以一台核心交换机Switch A和一台接入交换机Switch B为例中间用两条万兆光纤互联。两端端口分别为 TenGigabitEthernet1/0/1 和 TenGigabitEthernet1/0/2。目标是实现在这两条物理链路上建立 LACP 动态聚合逻辑端口名为 Bridge-Aggregation 1不同厂商叫法不一样华为叫 Eth-Trunk思科叫 Port-Channel锐捷叫 AP 口这里我用通用叫法来说明思路。规划参数如下系统优先级Switch A 设为 4096Switch B 保持默认 32768让 Switch A 作为决策端。成员端口每个设备上的两个万兆口端口优先级保持默认。超时时间使用短超时模式加快故障感知速度。负载均衡算法使用基于源目 IP 和源目端口的哈希确保大流量场景下负载均匀。3.2 分步配置流程从命令行到底层原理这里我用类标准命令行语法来描述配置过程具体语法不同厂商略有差异但思路完全一致。第一步创建聚合接口并指定为 LACP 动态模式。在设备上执行命令创建一个聚合接口例如interface bridge-aggregation 1然后将该接口的工作模式设置为 LACP 动态聚合。这一步相当于创建了一个容器后续成员端口都挂到这个容器下面。第二步配置系统优先级。在系统视图下修改 LACP 的系统优先级例如lacp system-priority 4096。这一步的作用是让本设备在协商过程中占据决策权。如果两端都是默认优先级 32768那么系统 MAC 地址更小的一端会自动成为决策方这在网络规模较小的时候可能没问题但一旦系统 MAC 地址变化或者多台设备堆叠后 MAC 地址重算就可能导致决策方漂移带来不确定性。第三步进入成员端口将端口加入聚合组。例如在interface TenGigabitEthernet1/0/1视图下执行port link-aggregation group 1同样的命令在第二个成员端口上再执行一次。这个动作的本质是把物理端口绑定到聚合逻辑接口上物理端口后续的转发行为由聚合接口统一调度。第四步配置聚合接口的二层属性。在聚合接口视图下配置端口类型为 trunk设置允许通过的 VLAN例如允许 VLAN 10 和 VLAN 20 通过。注意这里一定不要忘了聚合接口上的属性必须和成员端口原本的配置保持一致否则会出现配置冲突。有些设备在把物理端口加入聚合组后物理端口上的配置会被自动清除这是正常现象以聚合接口上的配置为准。第五步配置超时时间。在聚合接口视图下配置 LACP 超时时间为短超时例如lacp timeout fast。配置完成后设备会以 1 秒为周期发送 LACPDU。如果对端也配置了 fast 模式协商完成后两端能以秒级速度感知链路中断极大缩短故障切换时间。第六步配置负载均衡算法。这一步不是必需的但强烈建议做。默认的负载均衡算法通常基于源目 MAC 地址对于典型的南北向流量用户到服务器基于源目 IP 和端口的哈希效果更好尤其是在大流量、多连接场景下可以有效避免哈希不均导致的单链路拥塞。执行命令配置 hash 模式为源 IP、目的 IP、源端口、目的端口。第七步验证。配置完成后使用查看命令检查聚合组状态。如果显示聚合组状态为 up成员端口状态为 selected说明协商成功。如果某个端口显示为 individual 或 standby说明它没有成功加入聚合组需要进一步排查。不同厂商的输出字段略有不同但核心信息都包含成员端口、聚合组状态、Actor/Partner 的系统信息等。3.3 参数选择背后的逻辑与负载均衡算法优化为什么上面把系统优先级调到 4096原因在于我需要明确指定决策端。决策端确定之后LACP 协商的过程会更可预测。当你对某一条链路做维护或者调整端口优先级时不会因为决策方不确定而出现聚合组内端口状态的意外变化。超时时间选 fast 的原因也很直接关键业务链路要的就是故障快速感知和快速切换。短超时 1 秒的探测周期配合 3 秒的超时阈值比长超时 30 秒的感知速度提升了近 10 倍。当然代价是 LACPDU 发送频率高了但这几乎不占带宽对现代设备来说完全不是负担。负载均衡算法值得单独说一下。LACP 本身只负责把多条链路绑成一个逻辑链路但流量具体从哪个物理端口转发由转发面的负载均衡算法决定。算法不对会出现一个端口忙死、另一个端口闲死的现象。我见过不少案例明明做了 4 条万兆链路聚合实际吞吐只有 1 条万兆的水平一看 hash 算法用的是基于源 MAC而业务流量源 MAC 就那几台服务器hash 结果高度集中负载完全没散开。所以配置 LACP 时一定不要忽略负载均衡算法的调优。对于数据中心 east-west 流量优先选基于五元组或至少基于源目 IP 的哈希对于纯二层转发场景源目 MAC 哈希可能更合适但也要看实际流量模型。核心思路是让哈希因子尽可能分散让流量尽可能均匀地分布在所有成员链路上。4. 常见故障与排查技巧实录那些年 LACP 踩过的坑4.1 物理层一切正常聚合组却起不来这是 LACP 故障里最高频的一类。物理链路明明都是通的端口都能 up但聚合组就是无法协商成功。第一排查点两端模式是不是全 Passive。检查命令一下就能看到本端的 LACP 模式也要登到对端去看。如果两端都是 PassiveLACPDU 永远不会开始传输协商自然无法进行。解决办法就是至少把一端改成 Active。第二排查点聚合接口的编号两端是否一致。有些设备要求两端聚合组 ID 要一致比如一端是 Aggregation 1另一端也是 Aggregation 1。如果两端 ID 不一致也会造成协商失败。这点比较坑因为不同厂商的默认行为可能不同有些厂商即使 ID 不一致也能协商成功但为了保险起见规划时就约定好两端使用相同的聚合组 ID。第三排查点系统优先级和 MAC 地址的决策结果是否符合预期。如果两端都是默认优先级 32768系统 MAC 小的一方成为决策方而它可能不是你希望的那台设备。排查时可以通过查看命令确认当前决策方的身份如果发现决策方不对就需要调整系统优先级。第四排查点成员端口的状态卡在了 individual。在 LACP 中如果成员端口无法与对端协商成功它会退化为一个独立的普通端口发送报文方式跟普通口一样。这通常意味着对端对应的端口没有正确配置聚合组或者两端端口配置不一致。这时候需要逐端口核对两端配置。4.2 聚合组起来了但流量单向丢包或吞吐异常聚合组状态是 up物理端口都在转发状态但业务表现不对劲要么吞吐上不去要么丢包时有时无。这类问题的核心往往不在 LACP 协商本身而在于转发面。第一种可能负载均衡算法不合适。前面说过哈希因子不够分散流量会集中到某一条链路上甚至出现单链路打满、其他链路闲置的情况。解决方法是调整 hash 算法观察调整后的每个成员端口的流量分布。第二种可能成员链路的带宽或双工模式不一致。如果一条链路是 10G另一条是 1GLACP 协商也许能成功但负载均衡后 1G 链路会成为瓶颈而且由于 LACP 不感知带宽差异部分厂商支持配置权重但默认情况下不明确区分流量可能被均匀分配到两条链路1G 那条就拥塞了。这相当于木桶效应整个聚合组的实际吞吐被最慢的链路拖死。第三种可能对端设备只支持静态聚合。前面提过LACP 动态聚合要求对端也开启 LACP如果对端配置的是静态聚合协商就建立不起来。这类问题的典型表现就是聚合口 persistently 处于 down 状态但物理链路 up、端口也能收发报文。排查时先确认对端聚合模式。第四种可能中间链路出现了单通或丢包。比如光模块老化、光纤弯曲半径过小、接头污染。这类问题最迷惑人因为端口状态是 up 的计数中可能只有少量 CRC 错误。建议排查时不仅看 LACP 状态还要看每个成员物理端口的错误计数如果某一个端口 CRC 错误持续增长优先把它换掉再观察。4.3 快速排查命令速查与日志解读下面是我在现网排查 LACP 问题时几乎必敲的几条命令以通用形式列出具体设备上命令名略有差别。第一查看聚合组概要状态。确认聚合组是 up 还是 down成员端口处于哪种状态。重点看状态列如果 member port 是 selected说明它被选中进入聚合组如果是 standby说明它处于备份状态可能是端口优先级较低或者达到了成员数上限如果是 individual重点排查说明协商失败退化为独立端口。第二查看 LACP 协商详细信息。主要看 Actor System Priority、Partner System Priority、Actor Port、Partner Port、Actor State、Partner State 几个字段。重点核对两端设备显示的 Partner 信息是不是对方的真实信息如果对不上说明中间可能还有别的设备在转发报文或者配置链路有误。第三查看物理端口错误计数。检查 CRC error、runts、giants、late collision 等计数如果这些计数持续增长基本可以判定物理层质量有问题优先处理光模块、光纤和端口自协商设置。第四查看日志。LACP 相关的日志关键字包括 LACP、lag、bonding、aggregation 等重点看有没有端口被 block、standby、individual 之类的状态变化记录。日志能帮你还原故障时间线判断是协商阶段的问题还是运行过程中的链路抖动。4.4 实战案例复盘一次堆叠场景下的 LACP 故障最后分享一个让我印象深刻的真实案例。某现场有两台核心交换机做了堆叠服务器通过双网卡分别连接两台核心的不同物理端口服务器侧启用 LACP 动态聚合核心侧也配置了对应的聚合组。上线初期一切正常但运行了两个月后业务出现周期性丢包每次持续时间约几秒然后又自动恢复。刚开始我怀疑是物理链路问题但查看了两个成员端口的光功率都正常CRC 错误也几乎没有。后来开始查 LACPDU 的交互记录发现事件发生的时间点和堆叠系统的主备切换时间点高度吻合。原来核心交换机在堆叠主备切换时聚合组的成员端口经历了重新选举的过程服务器侧用的是短超时核心侧配置的是默认长超时两者超时机制不匹配导致服务器在堆叠切换期间判定链路中断中断了转发直到超时重新协商完成后才恢复。排查到根因后解决方案分两步走第一把核心侧的 LACP 超时时间也改为短超时确保两端超时机制匹配第二对服务器侧网卡驱动的 LACP 相关参数做调优缩短其对 LACPDU 丢失的容忍时间降低对堆叠切换的感知时延。这个案例给我的启发是跨设备场景下两端设备的 LACP 参数一致性比什么都重要尤其是超时时间和模式选择一个不起眼的默认值差异可能在关键时刻给你挖一个巨大的坑。5. 经验总结与日常维护建议做网络这一行越久越发现真正影响业务稳定性的往往不是那些高深莫测的协议细节而是最基本参数的合理规划与一致性校验。LACP 这个协议本身并不复杂它的设计初衷就是让大家快速把多条链路捆起来用但它对两端配置的一致性要求非常高。从前面的案例也能看出大多数 LACP 问题归根结底都是配置不对齐、参数默认值不一致导致的。在维护建议上我总结了几条自己的习惯做法。第一建立端口配置基线把每台设备的 LACP 相关配置模板化、版本化任何变更走评审流程。第二定期巡检聚合组的成员端口状态和错误计数重点关注 individual 状态和 CRC 错误字段发现问题提前处理不要等业务受损才介入。第三对负载均衡算法的调整要结合现网流量模型做评估不要盲目改改完后观察一段时间的端口利用率和 Hash 分布。第四在做设备割接或堆叠升级前提前核对两端设备的 LACP 参数一致性切断可能引发协商震荡的隐患。LACP 是一个基础但极其重要的协议它撑起了现代数据中心和园区网里大量的带宽冗余和负载均衡需求。理解了它的协商机制和常见故障模式很多网络问题其实都能在几分钟内定位到根因。希望这篇文章能帮你少走一些弯路少熬几个分析抓包的深夜。