1. 什么是LACP：先别急着敲命令，搞懂它在解决什么问题
做网络运维和系统集成这些年，我见过太多人一上来就敲channel-group 1 mode active，配置是配上了，但问一句“LACP到底干了啥”，瞬间卡壳。这其实很危险——链路聚合（Link Aggregation）本身不是新概念，但LACP（Link Aggregation Control Protocol）作为其中的自动化控制协议，它的价值绝不只是“把两根网线绑在一起”这么简单。
简单说，LACP是IEEE 802.3ad标准里定义的一种控制协议，后来演进到802.1AX。它让两台网络设备之间能动态协商、自动建立多条物理链路组成的逻辑聚合链路。听起来很绕？打个比方：假设你家到公司有两条平行的公路，LACP干的事，就是派两个交通员在两头协调，让这两条公路能按规则分流车辆，其中一条断了，车辆自动走另一条，整个过程不需要你半夜爬起来手动改路由。
LACP解决的痛点非常明确：冗余和高带宽。服务器双网卡连交换机，一条链路断了业务直接中断？LACP让另一条自动顶上。视频存储需要10G带宽，又没有万兆光模块？LACP可以把4条千兆聚合起来，逻辑上接近4G的吞吐。而它区别于手工静态捆绑的核心优势，是动态协商——双方设备通过交换LACPDU（Link Aggregation Control Protocol Data Unit，链路聚合控制协议数据单元）报文，自动完成成员端口的加入、退出和状态同步，还能检测对端配置是否一致。
这篇文章适合谁看？刚接触网络聚合的运维新手、准备做服务器网卡bonding的虚拟化管理员、以及需要跟网络团队扯皮“为什么聚合带宽不达标”的背锅侠。看完你会明白LACP的工作原理、配置背后的逻辑、排查问题的套路，以及那些厂商文档里不会写清楚的坑。
2. 核心机制拆解：LACP是怎么“商量”出一条聚合链路的
2.1 从手工捆绑到动态协商：LACP解决了什么痛点
在LACP出现之前，链路聚合主要靠手工配置。两边设备各设置一个聚合组号，把端口往里一塞，就算完事。这种方式有三个致命问题：
第一个问题是配置一致性无法验证。你这边把端口1、2、3加进聚合组，对端可能只加了端口1、2。物理上确实通了，但流量会在聚合链路上出现哈希不均，甚至造成广播风暴。第二个问题是故障感知迟钝。某条成员链路物理断开，有的设备能通过链路状态立刻感知，但有的设备需要等超时，期间流量仍然往断链上扔，表现为丢包但线路看起来“是好的”。第三个问题是无法快速扩展和撤离。想临时加一条带宽，必须两边同时改配置，两端甚至得重启端口才生效，运维窗口极长。
LACP的引入就是来解决这些麻烦的。它定义了一套标准的协商机制：设备在聚合组的成员端口上定期发送LACPDU报文，报文中携带本端的系统优先级、MAC地址、端口优先级、端口号、聚合组标识等参数。对端收到后进行比较，谁能成为主控端（Actor）由系统优先级和MAC地址共同决定，然后双方在这个框架下确认哪些端口能聚合、哪些端口参数不一致需要排除。
这套机制的价值在于“自动对账”。两端配置有差异时，LACP不会傻乎乎地把所有端口都拉起来，而是把参数不匹配的端口置为Down或Standby状态，并且通过日志告诉你原因。换句话说，LACP把原来靠人肉核对配置的工作变成了协议自动完成，减少了人为失误，提高了故障自愈能力。
2.2 LACP的模式认知：Active、Passive和On（静态）怎么选
LACP有两种标准模式：Active（主动）和Passive（被动）。Active模式表示设备主动发送LACPDU，Passive模式表示设备被动响应——只有收到对端的LACPDU后才回应，自己不主动发起。
组网时，两端至少要有一端为Active，协商才能建立。如果两端都是Passive，两边都在等人开口，链路聚合永远起不来。如果两端都是Active，没问题，协商会正常完成。所以生产环境里我一般建议：交换机侧固定配Active，服务器侧按需选Active或Passive。比如某品牌的服务器网卡驱动对LACP支持不完善，被动模式反而更稳，这时候交换机Active、服务器Passive是最优组合。
还有个特殊模式：On（静态聚合）。这种模式不发送也不处理LACPDU，纯粹靠手工捆绑。有些老设备不支持LACP，或者你明确知道对端设备一定不会变，可以用On模式。但它失去了LACP的动态感知能力，链路故障只能靠物理层检测，不推荐在核心链路使用。我个人在实际项目中，除非是设备能力受限，否则一律用LACP，宁可在两端配置上多花点功夫，也不愿意在冗余能力上赌运气。
2.3 聚合组参数背后的小九九：系统优先级、端口优先级、超时时间
LACP协商过程中，有几个关键参数决定了哪些端口能成为聚合成员，哪些会被排除：
系统优先级（System Priority）：默认32768，数值越小优先级越高。它决定了在两端都想主导协商时，谁能成为决策方。一般保持默认即可，但当你希望某台设备明确拥有控制权时，可以把它调小。
端口优先级（Port Priority）：默认也是32768，用于竞争聚合组内的活动端口名额。如果聚合组允许的最大活动端口数是8，而你绑了10个物理口，LACP会比较端口优先级，择优录取，剩下的进入Standby状态待命。
超时时间（Timeout）：分为Short（3秒）和Long（90秒）。Short模式探测故障更快，但同时会增加LACPDU的发送频率和CPU开销。生产环境我倾向于Short，前提是设备CPU有富余；如果你的核心交换机本身负载就高，Long模式更稳妥。
还有一个被很多人忽略的点：LACP的系统ID是“系统优先级+MAC地址”的组合，不是单看MAC。两台不同厂商的设备对接时，如果它们对系统ID的排序逻辑有差异，可能出现“我这边觉得该我主导，你那边觉得该你主导”的僵局。这种现象不常见，但遇到时把两台设备的系统优先级都手动设置成不一样的数值，能快速打破僵局。
3. 实操部署：从拓扑设计到配置落地的完整过程
3.1 拓扑与需求先行：不要上来就敲配置
我第一次做LACP组网时犯过一个错：需求都没理清就直接在交换机上配了Port-channel，结果后端服务器根本没做bonding，物理链路是聚合了，服务器侧还是两条独立网卡——这种半吊子配置比不配还坑，因为IP地址冲突和流量绕路会让你排查到怀疑人生。
所以在动任何配置之前，先画拓扑、写清楚需求。我常用的模板是这样的：
- 业务形态：是虚拟化集群存储网络，还是生产业务前端？这决定了用几层聚合、是否跨设备堆叠。
- 对端设备：交换机的品牌型号、是否支持LACP、是否开启堆叠（Stack）或集群（Cluster）。跨设备聚合有两种方案：一种是两独立交换机各自出聚合口再到服务器，相当于服务器一条聚合、两个交换机各自LACP；另一种是把两台交换机做堆叠后虚拟成一台，再用Multi-chassis LACP（MC-LAG）支持跨设备聚合。两者的区别直接决定配置模式。
- 物理链路数量：预留几条？规划多少条？聚合组的活动上限是多少？这影响你设置端口优先级是否有意义。
- 带宽需求：真的需要聚合那么多链路吗？很多场景一根万兆就够，LACP只是冗余需要，这时候不要盲目加链路，浪费端口也增加排障难度。
理清这些后，才轮到选交换机端口、规划VLAN和IP，最后才是配置命令。
3.2 交换机侧的LACP配置：一步一步来
以常见的某知名品牌交换机为例，配置LACP的步骤大致如下：
第一步，创建聚合组并指定类型。命令类似interface port-channel 1，然后switchport mode trunk或switchport access vlan x，根据业务需要选择。注意，聚合组本身是三层口还是二层口，决定了后续IP和VLAN的配置方式。
第二步，把物理端口加入聚合组。在物理接口下输入channel-group 1 mode active。这里有几个隐藏细节：
- 两端模式至少一端是active，建议交换机统一用active。
- 端口必须处于同一种操作模式，比如都是access口或都是trunk口，VLAN配置要一致。
- 不要手动在这些物理口上配置IP，IP只配在逻辑口（Port-channel）上。
第三步，确认协商状态。用show etherchannel summary或show lacp int查看端口状态。正常情况下应该是SU（State Up），如果出现SD（State Down）或ST（Standby），就需要排查。
第四步，如果有多组聚合，注意聚合组的编号一致性。两端虽然不需要完全相同的聚合组号，但同一台设备内部不能有编号冲突。我之前见过一个案例，某人把端口1、2加进聚合组1，又把端口3加进聚合组2，结果端口3怎么都协商不起来——因为物理拓扑上两组端口连接的是同一台对端设备，对端无法区分这两组聚合到底是谁。
3.3 服务器侧的链路聚合（Bonding）姿势
服务器侧以Linux为例，配置LACP的通用做法是用Bonding模块，模式选择mode=4（802.3ad）。
在/etc/modprobe.d/bonding.conf里加：
alias bond0 bonding options bond0 mode=4 miimon=100 lacp_rate=1然后配置网络接口，把两块物理网卡加入bond0。配置文件大致长这样：
# /etc/sysconfig/network-scripts/ifcfg-bond0 DEVICE=bond0 BOOTPROTO=none ONBOOT=yes IPADDR=192.0.2.10 NETMASK=255.255.255.0 BONDING_OPTS="mode=4 miimon=100 lacp_rate=1 xmit_hash_policy=layer3+4"关键参数解释一下：
mode=4：即IEEE 802.3ad动态链路聚合，必须配合交换机LACP使用。miimon=100：链路状态监测间隔100毫秒。这个值不宜过大，否则故障感知慢；也不宜过小，否则CPU占用高。100是比较通用的折中。lacp_rate=1：LACPDU发送频率为Short（3秒），对应交换机的short timeout。xmit_hash_policy：决定流量负载均衡的哈希策略。默认是layer2，只按MAC地址哈希；如果你有多种业务IP流量混跑，建议用layer3+4，把源目IP和端口都纳入哈希，分布更均匀。但要注意，使用layer3+4时，如果流量是单条TCP长连接，再均匀的哈希也拆不开，链路的带宽还是会被单流限制，这是LACP的固有限制，别指望它能突破单流性能。
配置完网卡后，用ifenslave bond0 eth0 eth1或者重启网络服务使配置生效，再用/proc/net/bonding/bond0查看状态。看到LACP active和Aggregator ID后，基本就成功了一半。
3.4 验证与调优：怎么判断聚合是真的“高可用”而不是“假聚合”
配置完成后不要急着收工，做一轮完整验证：
第一步，查两端的协商状态。交换机侧用show lacp neighbor，服务器侧看/proc/net/bonding/bond0，确认双方看到的对端信息一致。
第二步，测流量分布。用打流工具（比如iperf）打多路并发流，观察各成员链路的流量是否均匀。如果不均匀，优先检查哈希策略，其次检查物理链路是否过载导致重传。
第三步，做故障演练。拔掉一根网线，观察流量是否自动切换到剩余链路。好的LACP聚合在几十毫秒到几百毫秒内就能完成切换，不会出现业务中断。如果切换后有丢包，说明你的链路监测时间设置太长，或者服务端应用的TCP超时设置太短。
第四步，检查广播域。确认聚合组内各端口的VLAN配置没有差异，特别是trunk口，allowed VLAN列表必须一致，否则聚合链路会出现广播域错乱。
4. 常见问题与排查技巧：我踩过的坑，你大概率也会踩
4.1 协商不起来：从状态字看动机
最常见的现象是服务器侧显示ad_port_state: 4（对应ETHTOOL_LINK_MODE），交换机侧显示端口在聚合组里但状态是D（Down）。排查顺序我一般按这样来：
首先，确认物理链路本身是通的。看端口光的指示灯、插拔网线看两端接口的状态，如果光纤断了，后面就都不用查了。
其次，检查模式匹配。一端是Active，另一端必须至少是Passive；两端都Passive是永远协商不起来的。
再次，检查接口类型和VLAN配置。两端接口一个在access一个在trunk，或者trunk的allowed vlan不同，LACP会认为参数不匹配，直接拒绝加入。
最后，查看本端的系统ID和聚合ID。有时两台设备系统优先级一样、MAC地址排序产生平局，会导致协商稳定不下来，现象是聚合组内端口状态像“蹦迪”一样来回切换。解决办法是手动修改其中一台的系统优先级，人为打破平局。
4.2 流量不均：哈希算法与长连接陷阱
流量不均的原因分两类：一类是物理层面，比如网卡和交换机的哈希算法不一致；另一类是逻辑层面，比如流量模型本身只集中在某一条连接上。
我遇到过一个典型案例：某存储服务器用4条千兆聚合，访问客户的IP是固定的，存储流量大多数是同一台客户端到服务器的长连接，结果4条链路里只有1条疯狂跑满，其余3条几乎闲置。这不是LACP坏了，而是哈希策略对这个流量模型压根不敏感。后来把xmit_hash_policy从layer2改成layer3+4，情况稍有好转，但也没能做到4条链路全打满。
所以做LACP前先想明白一个原则：LACP做的负载均衡是基于数据流的，不是数据包级别的。同一对源目IP和端口的单条流，永远只会走一条物理链路。想突破单流带宽？老老实实上更高速率的端口，或者改造应用层逻辑，别指望LACP帮你“开挂”。
4.3 故障切换不干净：超时设置与业务侧的超时博弈
还有一个坑在于LACP的故障检测与业务侧超时的配合。比如我配了LACP的Long超时（90秒），而数据库客户端连接超时只有30秒，那链路一断，数据库连接先断了，LACP还没感知到链路故障，等LACP切换完成，客户端早已报错，业务中断已经发生。
这种情况的解法有三个方向：一是把LACP的故障检测调快，比如用Short超时，或开启设备的BFD（Bidirectional Forwarding Detection，双向转发检测）联动；二是在服务器侧调大应用的超时时间，但这会影响业务层的高可用指标，不是所有场景都允许；三是在物理层面做链路监测，比如交换机启用光模块的Digital Optical Monitoring（DOM）告警，一旦光功率衰减超过阈值，立即Down掉端口，让LACP更快完成切换。
4.4 跨厂商设备互通：那些“标准”里没写的“方言”
LACP是IEEE标准，理论上所有厂商都该一致，但现实中你总会遇到一些“方言”问题：
- 有的厂商交换机对LACPDU的发送间隔有自己的默认值，需要手动改成标准的Short或Long；
- 有的厂商把LACP聚合组的“最大活动端口数”默认设得极少，比如只有2，哪怕你绑了4个口，另外2个也只能当Standby；
- 有的厂商在用户侧接口默认开启
edge-port之类的快速收敛特性，这本来是为了配合非聚合场景的STP优化，一旦跟LACP同时用，反而造成端口反复震荡。
遇到这类问题时，我习惯先用标准命令把两端的参数表打出来比对，逐步缩小差异范围。不要想当然地认为是“必须用某厂商的特色命令配合”，先从标准参数查起，九成的互通问题都能解决。如果实在无法解决，就采用保守方案：一端LACP，另一端手工静态聚合的On模式，牺牲动态协商能力，换取稳定可用。
5. 进阶扩展：VPC、MC-LAG与LACP的结合玩法
如果你管理的网络拓扑稍微大一点，会遇到一个新问题：两台接入交换机，服务器只能物理连接到这两台不同的设备，但又希望做LACP，怎么整？这时候就需要跨设备链路聚合了。
主流厂商的解法是各有名称的MC-LAG方案，比如那两家头部厂商的VPC和M-LAG。共同原理是：先把两台交换机做虚拟化/堆叠，让它们共享一个系统MAC和系统优先级，再对外表现为一台逻辑设备，服务器发LACPDU时看到的对端系统ID是唯一的，聚合就能正常建立。
这种架构的好处是：服务器的一条LACP聚合可以跨两台物理交换机，任何一台交换机宕机，只要还有一条成员链路在另一台机器上活着，LACP聚合就不中断，配合服务器侧bonding的xmit_hash_policy，能做到业务层面的无缝切换。
但MC-LAG也有它的复杂性。比如两台交换机之间的peer link带宽要充分，不能成为瓶颈；比如两台设备的软件版本必须一致，否则LACP协议栈行为可能产生分歧；比如故障切换时的水平分割机制必须正确，否则会出现广播环路。这些内容展开写又是一篇文章的篇幅，这里先提醒一句：如果你想在MC-LAG场景下用LACP，务必要对厂商的限速和防环机制做充分验证，不要只看聚合起来了就以为万事大吉。
6. 我的实操体会与选型建议
做了这么多年的LACP接网落地，我的体会可以浓缩成几条不是文档里的经验：
- LACP是冗余工具，不是带宽扩展的银弹。它的核心价值是自动协商和故障自愈。带宽提升是“附带红利”，且受流数量限制。想纯粹翻倍带宽，优先考虑更高速率端口。
- 配置前先统一两端参数，尤其是模式、超时、VLAN配置。宁可多花半小时对表，不要省下这时间留给半夜排障。
- 故障演练必须做。别信“配好了就没事”这句话，拔线测试是检验LACP是否真正可用的唯一标准。
- 跨厂商互通时，从标准参数查起，不要一上来就怀疑对方设备有bug。事实上更多时候是两端默认参数不一致造成的“看起来像bug”。
如果你刚开始接触LACP，建议先搭一个最小化实验环境：两台交换机加一台双网卡服务器，图省事可以直接用网络模拟器（比如GNS3或EVE-NG）做纯虚拟实验，把Active/Passive、Short/Long、不同VLAN、不同端口优先级这些情况都试一遍。这套东西玩熟了，再上真机，你会发现真机反而比模拟器简单——因为真实设备之间的“方言”问题只有在实战中才能体会。
LACP本身不复杂，复杂的是它跟周边协议的协同方式。把它放在整体网络设计里去理解，才能在真正需要它的时候拿得稳、跟得紧、切得快。
