1. LACP 到底是什么为什么网络工程师绕不开它做网络这行时间久了你会发现一个尴尬的现实单条链路永远不够用。不管你是接服务器、接核心交换机还是做出口设备的HA总会碰到带宽打满、链路单点故障这种让人头疼的问题。加带宽吧换万兆光模块、换光缆钱花了一大把不加吧业务高峰期卡顿、丢包老板和业务部门的投诉电话一个接一个。我最早被LACP“教育”是在一次机房迁移的深夜——两台接入交换机做堆叠上联核心的两条万兆光缆因为误插到了同一个静态聚合组里结果不仅没有实现带宽叠加反而因为Hash算法和硬件表项冲突导致部分流量直接不通。当时被我师傅骂了一顿然后他把我拉到一边丢给我一句话“你以后做链路捆绑能走LACP就别手搓静态聚合协议帮你做的事比你想象的多得多。”LACP全称是Link Aggregation Control Protocol也就是链路聚合控制协议。它属于IEEE 802.3ad标准的一部分后来并入了IEEE 802.1AX核心作用就两个字协商。它通过设备之间互相发送LACPDU报文来自动决定哪几条物理链路可以捆绑成一个逻辑链路从而增加带宽、提高可靠性。相比手工静态聚合LACP最大的价值在于链路状态发生变化时协议能自动感知、自动收敛不需要人为干预。这篇文章就是把我这些年碰到的LACP相关问题、踩过的坑和排查思路整理出来。不管你是刚入行的新人还是在机房摸爬滚打多年的老油条只要你的环境里涉及交换机互联、服务器双网卡绑定、防火墙双机热备这篇文章都会对你有用。我会尽量把原理讲得接地气把配置步骤拆到可以直接抄作业的程度。2. 链路聚合的核心机制弄懂这几个点才算真入门2.1 LACPDU和协商过程协议在底层做了什么LACP之所以叫“控制协议”核心在于它有专门的协商报文叫LACPDULink Aggregation Control Protocol Data Unit。这个报文默认是组播发送的目的MAC地址是固定的01:80:C2:00:00:02发送周期有两种模式慢速模式每30秒发一次快速模式每1秒发一次。协商的大致过程是这样的交换机端口启用LACP后端口会进入“主动协商”状态向对端发送LACPDU。对端收到报文后会把自己的系统优先级、系统MAC、端口优先级、端口号、操作Key等信息回传给发送方。双方都收到对方的参数后会各自计算哪些端口可以聚合成一个LAGLink Aggregation Group。这里有个非常关键的细节LACP协商不是一次性的而是一个持续过程。只要聚合组里有端口状态变化比如某条链路down了、某个端口被拔掉了LACP会立刻通过LACPDU把这个变化同步给对端然后双方重新计算聚合成员。这也是LACP比静态聚合安全的核心原因——协议在持续看护成员链路的状态。2.2 Actor和PartnerLACP状态机里的两个角色很多人看LACP的调试信息看不懂就是因为没理解Actor和Partner这套概念。简单说任何一个LACP端口在逻辑上都有两个角色Actor本方本设备自己在该端口上的LACP参数包含本端系统优先级、系统MAC、端口优先级、端口号、操作Key等。Partner对端对端设备通过LACPDU报过来的参数实际上是本端“看到的”对端信息。当你在命令行敲show lacp internal和show lacp neighbor的时候internal看的是Actor状态neighbor看的就是Partner状态。两个角色的参数会进行一个比对系统ID优先级MAC小的优先端口优先级小的优先如果都一样再比端口号。这套比较规则决定了谁是聚合组的“权威”——哪台设备的参数被采纳以及端口在聚合组里的顺序。打个通俗的比方Actor是你自己填的报名表Partner是对面递过来的名片。两边先把名片换一换然后按一套统一的规则排座次谁坐前面谁坐后面一目了然。如果没有这套可比较的数值两台设备各自说了算聚合组就乱套了。2.3 Key值、系统优先级、端口优先级选主备到底靠什么LACP协商里几个关键参数我逐个拆开讲这些都是考试爱考、工作必用的点。系统优先级默认是32768取值范围0到65535数值越小优先级越高。这个参数在主备设备协商中起着决定性作用。两台设备互联的时候系统ID优先级和MAC的组合更小的一方会作为聚合的主动方负责决定哪些端口加入聚合。如果两个系统的优先级相等就继续比较系统MACMAC小的优先。这就是为什么两台设备配置完全一样也能顺利协商的原因——MAC是唯一的。操作Key这个参数是设备本地概念用于标识一组端口具有相同的聚合能力。比如同样是千兆口、同样的双工模式、同样的速率它们的Key就可能一样。只有Key值相同的端口才能被聚合在一起。不同速率、不同介质类型的端口Key不一样所以LACP天然不会把千兆口和万兆口捆绑成一个聚合组除非你做了特殊配置。端口优先级默认也是32768数值越小越优先。当一个聚合组里现有成员物理能力足够但出现了端口数量超过硬件限制或者物理链路不稳定的情况端口优先级就派上用场了。LACP聚合组最大成员数通常是8个或16个不同厂商有差异当超过上限时优先级高的端口被保留优先级低的会被踢出聚合组。另外在配置LACP端口为standby备份成员时这个参数也决定谁当备份。2.4 慢速分发与快速分发该用哪个模式LACP有两种工作模式实际部署时候需要想清楚再选慢速分发SlowLACPDU发送间隔30秒超时时间90秒。好处是协议报文少占用的带宽和控制面资源极小适合物理链路质量好、不需要频繁感知故障的场景。缺点是链路故障感知速度慢一台设备上聚合组某条链路挂了最坏情况下要等90秒才被对端发现业务受影响的时间比较长。快速分发FastLACPDU发送间隔1秒超时时间3秒。链路状态感知速度快了一个数量级适合对切换时间有要求的场景比如服务器双网卡绑定、核心交换机之间的互联。代价是控制报文的频率高了30倍但说实话LACPDU报文很小即便1秒一次对设备CPU和带宽的占用也完全可以忽略。我的习惯是核心设备间互联用Fast模式接入设备到终端设备比如服务器双方支持的话也用Fast。只有链路质量极好且不要求收敛速度的内网环境才会用Slow模式。很多初级工程师在配置交换机的时候只写了mode active就完事没注意还应该配合lacp rate fast导致故障出现后切换时间长达一分钟业务早就超时了。3. 从交换机到服务器一套完整的LACP配置实操3.1 配置前的准备工作和硬性要求在做LACP配置之前有几个前提条件必须满足否则后面全是坑第一参与聚合的端口速率和双工模式必须一致。哪怕有一端是千兆自适应、另一端强制千兆全双工虽然协商能成功但会造成带宽分配不均甚至引起端口频繁up/down这是LACP配置里最常见的“隐形炸弹”。第二所有成员端口必须属于同一VLAN或同为Trunk口。如果其中一个口是Access口另一个是Trunk口它们即便在配置层面被加到了同一个聚合组数据转发也会出问题。我遇到过某同事把两个上联口一个配成Access VLAN 10一个配成Trunk导致对端交换机学不到MAC全网广播风暴差点打挂核心。第三聚合组的成员端口上不能配置任何独占性功能比如IP地址、DHCP Snooping信任口、端口安全、风暴控制里的单独限速等。这些功能要配置的话应该配置到逻辑口如Eth-Trunk、Port-Channel上而不是物理口上。否则LACP虽然可以协商成功但数据面会按物理口各自的策略转发与聚合组的逻辑冲突。3.2 华为交换机配置实例千万别漏了模式华为的设备上LACP聚合口的逻辑接口叫Eth-Trunk。我以两台交换机堆叠后上联核心的典型场景为例# 逻辑口创建这里要注意华为V200R003之后版本的Eth-Trunk接口支持直接配置为LACP模式 interface Eth-Trunk1 port link-type trunk port trunk allow-pass vlan 10 20 30 mode lacp-static # LACP静态模式即主动协商模式 lacp preempt enable # 使能LACP抢占恢复的链路可以重新加入聚合组 lacp preempt delay 10 # 抢占延迟10秒防止链路震荡导致频繁切换 # 物理口加入聚合组 interface GigabitEthernet0/0/1 eth-trunk 1 interface GigabitEthernet0/0/2 eth-trunk 1注意华为的LACP模式分两种lacp-static和lacp-dynamic。lacp-static是静态LACP需要双方都配置才能协商成功lacp-dynamic是动态LACP只要一方配置为active另一方配置为passive也能协商。生产环境里我强烈建议两边都配置成lacp-static因为这样角色明确、状态可控。lacp-dynamic常用于和一些老设备、非标设备对接兼容性更好但也更容易出现协商失败。还有一点容易漏华为交换机默认的LACP报文发送模式是Slow如果想修改为Fast需要在系统视图下配置lacp rate fast这个命令是全局生效的设备上所有LACP聚合口都会变成1秒发送LACPDU。如果要单独针对某个接口配置需要进入接口视图执行lacp rate fast。3.3 思科交换机配置实例Nexus和IOS略有差异思科设备上LACP聚合口的逻辑接口叫Port-Channel。以传统的IOS交换机为例interface Port-channel1 switchport trunk encapsulation dot1q switchport mode trunk switchport trunk allowed vlan 10,20,30 interface GigabitEthernet0/1 channel-group 1 mode active interface GigabitEthernet0/2 channel-group 1 mode active关键的命令是channel-group 1 mode active。Cisco的LACP模式有三个active主动、passive被动、on强制/不协商。on模式其实就是静态聚合不走LACP协商如果两端都是on也可以工作但失去了协议感知能力。生产环境请务必用active模式。Nexus系列的命令稍有不同比如interface Ethernet1/1 channel-group 1 mode active interface Ethernet1/2 channel-group 1 mode active interface port-channel1 switchport mode trunkNexus还支持一种称为“vPC”的跨设备链路聚合方案比传统的STP阻塞一端要优雅得多。但vPC本身不属于LACP的范畴它是在LACP之上做了一个双活网关扩展这里不展开。只说一点如果交换机之间做vPC Peer-Link互联建议用lacp mode active、lacp rate fast组合同时把成员端口分散在两台设备上后端服务器用双网卡分别接到两个不同设备上这样任何一个单点故障都不影响业务。3.4 Linux服务器双网卡bonding配置mode4就是LACP大部分互联网公司的服务器是Linux双网卡绑定是最常见的LACP使用场景。Linux bonding驱动一共支持7种模式mode 0到6其中mode4802.3ad就是动态链路聚合需要交换机侧启用LACP才能协商成功。我用CentOS/RHEL系的NetworkManager配置方式举个例子。首选在交换机上把接服务器的两个端口绑成LACP聚合组然后在服务器上nmcli connection add type bond con-name bond0 ifname bond0 mode 802.3ad nmcli connection add type ethernet con-name bond0-port1 ifname eno1 master bond0 nmcli connection add type ethernet con-name bond0-port2 ifname eno2 master bond0 nmcli connection modify bond0 ipv4.addresses 192.168.1.10/24 nmcli connection modify bond0 ipv4.gateway 192.168.1.1 nmcli connection modify bond0 ipv4.method manual nmcli connection up bond0关键点在于mode 802.3ad以及bond的xmit_hash_policy参数。这个参数决定了数据包在两条物理链路上怎么分配。常见的策略有三个layer2按MAC地址做Hash同一对源目MAC的流量固定走同一条链路配置最简单但遇到一个大流量会话比如视频传输时只能跑一条链路。layer23按MAC和IP地址做Hash比layer2均匀一些适合一般业务。layer34按IP和端口做Hash可以做到比较精细的负载分担缺点是对某些特殊协议如果包含分片报文可能因为Hash不均导致重排对性能反而有影响。实际生产里如果业务流量大多是TCP/UDP长连接我建议设为layer34可以让两条链路都跑起来。如果业务全是广播或组播为主比如视频监控流那么Hash策略影响不大重点看组播是否走单条链路。配置好bond后在交换机上敲show lacp neighbor正常情况下能看到对端服务器的两个端口都在聚合组里状态是BNDLBundled。如果在交换机上看到状态是DETACHED或WAIT那就是协商失败需要优先排查服务器bond配置和交换机LACP模式是否匹配。3.5 一整套场景实战交换机堆叠服务器双网卡LACP我把一个典型的小型数据中心接入场景串起来演示一下。需求是两台服务器做业务双机热备每台服务器配双千兆网卡通过两台接入交换机做堆叠上联核心。核心要求带宽叠加和链路冗余。交换机侧堆叠环境下interface Eth-Trunk1 port link-type trunk port trunk allow-pass vlan 100 200 mode lacp-static lacp preempt enable lacp preempt delay 15 # 把堆叠里不同成员交换机的端口加进同一聚合组 interface GigabitEthernet1/0/1 eth-trunk 1 interface GigabitEthernet2/0/1 eth-trunk 1服务器侧CentOS系统bond配置# 编辑 /etc/sysconfig/network-scripts/ifcfg-bond0 BONDING_OPTSmode802.3ad miimon100 xmit_hash_policylayer34这里有一个容易被忽略的点如果交换机做了堆叠服务器网卡ab两条线最好分别接到堆叠里的不同物理交换机上这样才能真正避免单点故障。如果两台物理交换机不做堆叠而是独立运行那么服务器双网卡接两台交换机就不叫LACP了需要走M-LAG或者vPC这类跨设备链路聚合协议否则交换机会因为环路而阻塞端口这个问题我在后面的故障排查里会再讲。4. 常见故障排查与避坑实录4.1 链路聚合协商失败的排查步骤LACP协商失败的场景特别多我总结了一套我自己一直在用的排查顺序循着这个顺序走基本能定位90%的问题。第一步物理层排查。先看光纤模块收发光功率是否在正常范围用display interface华为或show interface思科看物理口状态是否up。很多协商失败本质上是光路问题LACP只是背了锅。物理口如果频繁up/downLACPDU自然发不出去也收不回来协商永远不会成功。第二步确认对端设备状态。用display lacp neighbor或show lacp neighbor看能否看到对端的Actor参数。如果能看到说明LACPDU已经通了问题大概率出在参数不匹配上如果完全看不到说明LACPDU在中间就断了要查VLAN放行、光路、中间设备是否透传、端口模式。第三步对比两端参数。重点看系统优先级、系统MAC、端口优先级、操作Key是否匹配。华为的display eth-trunk 1 verbose会把actor和partner的详细参数列出来思科用show etherchannel 1 detail。我在旁边见过太多人把两端配置成一样的IP、一样的VLAN却忽略了操作Key不一致导致LACP始终聚合不起来。第四步检查模式匹配。一端是active、另一端是passive没问题两端都是active没问题一端active、另一端on静态聚合无法协商两端都是passive无法协商。很多入门者总以为“LACP是自动协商的插上就能用”忘记了主动侧和被动侧的模式搭配原则。4.2 模式不匹配最常见也是最难排查的坑先给一个典型场景交换机侧配置了mode active主动和一台老服务器网卡自带的LACP驱动对接。服务器网卡驱动默认的是被动模式理论上能协商成功。但实际却协商不了抓包发现LACPDU有发有收状态机却一直停在WAIT状态。后来查到这个服务器网卡驱动对LACP的实现有问题它在收到对方LACPDU后不会主动发送本端的Actor信息除非驱动显式配置成active模式。这就是实现不标准造成的协商失败。这种问题光靠配置层面很难解决最终方案是给服务器网卡驱动装上最新版补丁或者在交换机上把这两个端口改成静态聚合华为的mode lacp-static无法解决需要改成手工聚合即mode manual绕开协商过程。另外一个经常被忽视的模式坑是同一台设备上多个物理端口组合成一个聚合组时不能允许其中一部分端口是Trunk、另一部分是Access。很多配置工程师图省事往Eth-Trunk里加新成员时直接把接口默认VLAN的模式带进去了导致同一个聚合组内既有Trunk口又有Access口。这种状态LACP协商大概率能成功但业务流量却会全部走不通因为逻辑口的VLAN处理跟物理口的实际模式对不上。4.3 误接线和环路风险LACP聚合组的安全边界LACP虽然能自动协商但它只对已加入聚合组的端口进行控制没法防止你把人家的线插错位置。最典型的事故是两台核心交换机之间既要跑三层路由又要跑二层LACP互联结果运维同学把其中一条互联光纤插到了错误的槽位上导致对端的LACP聚合组里混入了一个不属于本聚合组的端口于是一瞬间出现了环路。这种故障的排查难点在于LACP本身没有报错聚合组状态也是正常的但网络广播风暴起来了。后来我用华三设备的display link-aggregation verbose看聚合组成员时发现其中一个端口的Partner MAC竟然和另外几个端口都不一样——它连的根本不是同一台对端设备。这就是LACP聚合组内端口与对端设备逐一对应的基本要求被打破了。所以我要强烈建议LACP聚合组里的每一个物理端口必须是对端同一台设备的物理端口。如果两台设备之间的互联有多条链路要聚合请确认每一根线都是插在两台设备正确的互联口上。再强调一遍LACP无法防止逻辑上错误的物理连接只能防止物理链路down掉后逻辑口无法感知。4.4 和虚拟化平台相关的LACP连接问题现在服务器虚拟化太普及了虚拟机交换机和物理交换机的LACP对接问题也很多。VMware ESXi的标准交换机vSwitch和分布式交换机vDS都支持LACP但有一个大坑vDS的LACP只支持主动模式并且需要ESXi 6.0及以上版本同时需要在vCenter里配置LACP聚合组。如果你只配了物理交换机的LACP没有在vDS侧配置就会一直看到对端物理交换机上报partner不匹配。另外虚拟化平台的LACP和物理网卡驱动有很强的依赖关系。我遇到过一台戴尔服务器iDRAC里把两个网口同时启用了PXE和iSCSI结果Linux bond在引导阶段和交换机的LACP协商中断导致服务器启动后IP地址无法配置。迁移在线业务的时候这种问题折腾最久。排查手段是先用ethtool确认两个网口的物理速率和双工模式一致再检查BIOS里网卡是否启用了类似“MAC地址随机化”或“NIC Teaming”的选项禁用掉虚拟化层自带的网卡绑定功能只保留LACP一层。4.5 问题排查速查表下面这张表是我日常干活时经常参照的遇到问题先对号入座能省下很多排查时间。故障现象可能原因首选排查动作LACPDU收不到协商不成功光路断、VLAN未放行、中间防火墙拦截组播display lacp neighbor确认对端参数检查光模块光功率收到LACPDU但状态卡在WAIT模式不匹配、Key值不一致、对端实现不标准对比actor和partner参数检查两端模式聚合组up但业务流量不通端口模式Access/Trunk不一致、逻辑口VLAN配置错误检查Eth-Trunk下的VLAN配置和成员口模式聚合后流量总走一条链路Hash策略不合适、单会话大流量调整xmit_hash_policy为layer34确认对端Hash一致性链路down后恢复慢LACPDU超时时间过长Slow模式全局启用lacp rate fast将超时缩短到3秒与虚拟机平台对接失败vDS LACP未配置或版本过老升级ESXi到6.0在vDS设置启用LACP聚合组成员偶发被踢出端口优先级冲突、物理链路不稳定检查端口up/down记录调整端口优先级或更换光模块4.6 经验总结几个我从坑里爬出来的细节最后聊几个不是文档里会写、但实战中一定会碰到的细节。第一个是LACP和STP的配合问题。聚合组在初始协商的瞬间STP是感知不到端口已经聚合的。如果交换机配置了RSTP或MSTP在LACP尚未完成协商前物理口可能会被STP置于Blocking状态导致LACPDU发不出去。遇到聚合组一段时间后自动恢复、但刚插线时协商失败的情况可以先检查STP状态。第二个是交换机上LACP成员端口和硬件表项的关系。聚合组成员数量超过硬件支持上限时底层芯片可能只在部分成员口上建立哈希表项剩下的成员口虽然LACP状态是BNDL但实际不走流量。所以别只看协议状态要测一下流量是不是真的在两三条链路上都平均分布。用display load-sharing华为或show etherchannel load-balance思科可以确认实际负载分担的情况。第三个是协商成功后改变成员端口优先级。比如想人为指定某条链路作为主链路、其他链路作为备份可以通过调低主链路的端口优先级来实现。但是注意修改了优先级后如果不对聚合组执行一次shutdown/undo shutdown新规则不一定立即生效。这种时候别傻等手动重启一下成员端口最直接。第四个是关于LACP的抢占功能。华为设备默认lacp preempt disable意思是当主链路恢复后不会主动抢回原主链路的位置。如果你希望恢复的链路立刻回到主用状态需要显式配置lacp preempt enable。但这里牵涉到一个工程判断如果主链路物理状态不稳定经常up/down配置抢占反而会引发频繁切换影响业务。所以抢占功能不是越多越好要根据你的物理链路质量来定。5. 最后再分享一个小技巧说实话LACP不是新协议也不是什么高深技术但它就是能让你在网络出问题的时候少挨几次骂。我把踩过这么多坑之后最重要的三个经验放在这里当是个人心得也好当是给后来者的提醒也好第一配置LACP之前永远先看物理层。光路不行、模块老化、网卡驱动版本太旧这些问题不是LACP能解决的但LACP会第一个背锅。第二无论设备多高端、协议多自动化上线前一定要做一次成员端口拔插测试。把聚合组里的物理链路一根根拔掉再插回确认交换机状态和服务器网卡都能快速收敛。这个操作花不了十分钟但能把潜在的单点故障暴露在业务割接之前。第三团队协作时把两端的LACP参数整理成一张表格再配置系统优先级、端口优先级、模式、超时时间、Hash策略全部列清楚。我在每一次割接前都会这样做这张表不只是配置依据更是后续故障排查时的第一手参考。如果你在配置LACP的过程中也遇到过什么匪夷所思的问题欢迎一起交流。网络这个行当越往深处走越会发现“协议搞定一切”是个错觉能够把协议用对、用好、用出经验来才是真正的本事。