链路聚合这个词搞网络的人几乎都绕不开。但真正在生产环境里踩过坑的人都知道它远不是敲两条命令绑个口那么简单。我见过太多人配完之后觉得通了就行结果一出问题就抓瞎——流量跑不满、单条链路被打爆、拔一根线整个业务抖动甚至聚合口直接起不来。这些问题背后其实都是对链路聚合的工作机制理解不到位。这篇文章不讲教科书式的定义而是从实际运维的角度把链路聚合这件事拆开揉碎讲清楚。从为什么要做聚合、底层怎么转发、不同模式怎么选、配置怎么做、出问题怎么查到生产环境里那些文档不会写的经验我都会一一展开。不管你是刚接触交换机配置的新手还是已经配过几次但没深究过原理的老手应该都能从中找到对自己有用的东西。1. 为什么要把多条线捆成一条1.1 带宽瓶颈的真实场景先说一个很常见的场景。某公司机房里有台核心交换机下联一台接入交换机中间拉了一根千兆线。一开始用着挺好后来接入层挂了几十台服务器每天备份的时候这条千兆线的利用率直接飙到95%以上备份窗口从原来的两小时拖到了五六个小时。运维的人第一反应是换万兆板卡但一查预算核心和接入两边的万兆模块加上光纤跳线费用不低而且施工还得停机。这时候链路聚合就是一个性价比很高的选择。接入交换机和核心交换机之间本来就有多余的千兆口再拉一根网线或者光纤把两个口绑成一个逻辑口带宽就从1G变成了2G。虽然单条流量还是走某一条物理链路但多条流可以分散到不同链路上整体吞吐量上去了备份窗口自然就缩短了。这里有个关键点要理解链路聚合提升的是总吞吐量不是单条流的带宽。也就是说两台设备之间如果只有一条TCP连接在传数据那它还是只能跑一条物理链路的速度。只有多条流同时传输时才能体现出聚合的优势。这个区别在后面讲负载分担的时候还会展开。1.2 冗余备份比带宽更值钱带宽不够还能忍链路断了业务直接挂那就忍不了了。单条链路最大的问题就是没有冗余——网线被老鼠咬断、光模块老化失效、交换机端口故障任何一个环节出问题整条链路就断了。链路聚合天然自带冗余能力。两条线绑在一起断了一条另一条还能继续跑。虽然带宽减半但业务不会中断。对于核心链路来说这种冗余能力有时候比带宽本身更重要。我见过一个案例某单位的办公网核心到汇聚的链路因为施工队不小心挖断了光纤导致整个办公区断网半天。后来他们做了链路聚合两条光纤走不同的管道再遇到类似情况业务只是短暂抖动一下就恢复了。注意链路聚合的冗余切换速度取决于聚合模式和协议配置。静态聚合的切换速度通常比动态聚合快但动态聚合在链路状态检测上更可靠。具体选哪种后面会详细对比。1.3 链路聚合和堆叠、M-LAG的区别很多人容易把链路聚合和堆叠搞混。简单说链路聚合是把多条链路绑成一个逻辑链路堆叠是把多台设备绑成一台逻辑设备。两者解决的问题不一样但经常配合使用。举个例子两台接入交换机分别上联到两台核心交换机如果只做链路聚合接入交换机A的两条线都连到核心交换机1那核心交换机1挂了接入交换机A就断了。这时候就需要跨设备的链路聚合也就是常说的M-LAG或者堆叠场景下的聚合。这种配置更复杂但冗余级别更高。我个人的建议是如果预算和机房条件允许核心层尽量做跨设备聚合如果只是接入层到汇聚层单设备聚合基本够用。不要为了追求高可用把架构搞得过于复杂维护成本也是成本。2. 聚合口背后的转发逻辑2.1 负载分担不是轮流发包很多人以为链路聚合就是把流量平均分配到每条成员链路上一条发一个包轮流来。实际上完全不是这么回事。链路聚合的负载分担是基于流的不是基于包的。交换机内部有一个哈希算法会根据报文的某些字段计算出一个哈希值然后根据这个哈希值选择一条成员链路。同一个流的报文哈希值是一样的所以会走同一条链路。这个设计是为了避免报文乱序。如果同一个TCP流的报文走了不同的链路到达对端的时间可能不一样接收方就会收到乱序的报文触发重传反而降低性能。所以链路聚合必须保证同一个流走同一条链路。那哈希算法根据什么字段计算呢常见的有这几种哈希因子说明适用场景源MAC根据源MAC地址哈希同源多目的场景目的MAC根据目的MAC地址哈希同目的多源场景源IP根据源IP地址哈希多客户端访问同一服务器目的IP根据目的IP地址哈希单客户端访问多服务器源IP目的IP根据IP五元组中的两个通用场景源IP目的IP源端口目的端口根据IP五元组中的四个精细化负载分担不同厂商的交换机支持的哈希因子不一样配置命令也不同。选哪种哈希因子取决于你的流量特征。比如你的场景是很多客户端访问同一台服务器那用源IP哈希就比较合适因为源IP不同哈希值就不同流量能分散开。反过来如果只有一个客户端访问一台服务器那不管用什么哈希因子都只有一条流只能走一条链路。2.2 哈希算法的极化问题哈希算法有个天生的缺陷就是极化。什么意思呢就是流量可能分配得不均匀某条链路特别忙另一条特别闲。举个例子假设你有两条成员链路哈希算法是源IP模2。如果大部分客户端的源IP模2的结果都是0那这些流量就全跑到第一条链路上了第二条链路基本闲着。这就是极化。极化问题在实际环境中很常见尤其是成员链路数量不是2的幂次的时候。比如3条链路哈希算法是模3分布可能就不太均匀。5条、7条也一样。怎么缓解极化几个思路选择哈希因子时尽量选变化多的字段。源IP目的IP源端口目的端口这种四元组哈希变化维度多极化概率低。成员链路数量尽量用2、4、8这种2的幂次哈希分布更均匀。如果流量确实集中在少数几条流上那链路聚合本身就不适合这个场景考虑其他方案。提示有些高端交换机支持动态调整哈希算法可以根据流量特征自动优化。但大部分中低端设备只支持静态配置需要手动选择。2.3 成员链路的状态同步链路聚合组里的成员链路状态是同步的。什么意思呢就是聚合组有一个整体的状态每条成员链路也有自己的状态。只有成员链路的状态和聚合组的状态都满足条件这条链路才会被加入转发。具体来说成员链路需要满足几个条件物理层UP网线插好、光模块正常、对端端口也UP。链路层协商成功如果用了LACP需要LACP协商通过。配置一致成员链路的速率、双工、VLAN等配置必须一致否则可能加入失败。如果某条成员链路不满足条件它就不会被加入聚合组流量也不会走它。如果它之前已经在聚合组里后来条件不满足了它会被踢出聚合组流量重新分配到其他成员链路上。这个切换过程的速度取决于聚合模式。静态聚合没有协议报文全靠物理层状态判断切换速度快但可能误判。动态聚合有LACP协议报文能更准确地判断链路状态但切换速度稍慢。3. 静态聚合和动态聚合怎么选3.1 静态聚合简单但有盲区静态聚合也叫手工聚合就是管理员手动把几个端口加入聚合组不跑任何协商协议。只要物理层UP端口就参与转发。配置简单是它最大的优点。两条命令下去聚合口就起来了。而且因为没有协议报文切换速度快物理层一断立刻切换。但静态聚合有个很大的盲区它只能检测物理层状态检测不了链路层的连通性。什么意思呢假设中间加了一台传输设备交换机和传输设备之间的物理层是UP的但传输设备到对端交换机的链路断了。这时候静态聚合的成员端口还是UP的交换机会继续往这条链路发包但包到了传输设备就被丢弃了业务就断了。这个问题在直连场景下不明显因为物理层断了就是断了。但如果中间有传输设备、光电转换器、波分设备静态聚合就可能出问题。3.2 动态聚合LACP协议的工作机制动态聚合跑的是LACP协议全称是链路聚合控制协议。它在成员链路之间互相发送LACPDU报文用来协商和检测链路状态。LACP的工作过程大致是这样的两端设备都开启LACP端口开始发送LACPDU。双方根据LACPDU里的信息系统优先级、MAC地址、端口优先级、端口号等选举出主动端和被动端。主动端根据端口优先级和端口号决定哪些端口加入聚合组。双方协商一致后端口加入聚合组开始转发流量。之后持续发送LACPDU检测链路状态。如果一段时间收不到对端的LACPDU就认为链路故障把端口踢出聚合组。LACP的好处是能检测链路层的连通性。即使物理层UP但LACPDU收不到也会认为链路故障。这就解决了静态聚合的盲区问题。但LACP也有缺点协商需要时间切换速度比静态聚合慢。而且LACP报文本身会占用一点带宽虽然很少。3.3 两种模式的对比和选型建议对比项静态聚合动态聚合LACP配置复杂度简单稍复杂链路层检测不支持支持切换速度快稍慢协议开销无少量LACPDU适用场景直连链路、对切换速度要求高中间有传输设备、对可靠性要求高跨厂商兼容性好好标准协议选型建议如果两台设备直连中间没有其他设备静态聚合就够了简单可靠。如果中间有传输设备、光电转换器或者对链路层检测有要求用动态聚合。如果是跨厂商设备动态聚合的兼容性更好因为LACP是标准协议。如果对切换速度要求极高比如金融交易场景静态聚合可能更合适但要接受它的盲区。我个人的习惯是核心链路用动态聚合接入链路用静态聚合。核心链路可靠性要求高动态聚合能检测更多故障类型接入链路简单直连静态聚合够用配置也简单。4. 配置实操从零搭一个聚合链路4.1 配置前的准备工作在敲命令之前有几件事必须先确认第一确认两端设备都支持链路聚合。这个听起来像废话但确实有人拿着不支持聚合的交换机折腾半天。查一下设备型号和软件版本确认支持。第二确认成员端口的配置一致。速率、双工、VLAN、MTU这些参数成员端口必须一致。如果不一致端口可能加入不了聚合组。建议先把成员端口的基础配置做好再加入聚合组。第三确认对端也做了聚合。链路聚合是两端协商的一端做了聚合另一端没做可能出问题。静态聚合的话两端都配静态聚合动态聚合的话两端都开LACP。第四规划好聚合口的配置。聚合口是一个逻辑口它的配置会影响到所有成员端口。VLAN、STP、QoS这些配置是在聚合口上做还是在成员口上做不同厂商的实现不一样需要查文档确认。4.2 静态聚合的配置步骤以常见的CLI风格为例静态聚合的配置大致是这样的# 创建聚合口 interface Bridge-Aggregation 1 description Uplink-to-Core port link-type trunk port trunk permit vlan 10 20 30 # 把成员端口加入聚合组 interface GigabitEthernet 1/0/1 port link-aggregation group 1 interface GigabitEthernet 1/0/2 port link-aggregation group 1不同厂商的命令不一样但逻辑是一样的先创建聚合口配置聚合口的属性然后把物理端口加入聚合组。这里有个细节要注意成员端口加入聚合组之后它的很多配置会继承聚合口的配置。比如聚合口是trunk允许VLAN 10、20、30那成员端口也会变成trunk允许这些VLAN。所以成员端口上不需要重复配置这些。注意有些厂商的交换机要求成员端口在加入聚合组之前不能有和聚合口冲突的配置。比如聚合口是trunk成员端口是access那加入可能会失败。建议先把成员端口恢复默认配置再加入聚合组。4.3 动态聚合的配置步骤动态聚合的配置和静态聚合差不多区别在于要开启LACP模式# 创建聚合口设置模式为动态 interface Bridge-Aggregation 1 description Uplink-to-Core port link-type trunk port trunk permit vlan 10 20 30 link-aggregation mode dynamic # 把成员端口加入聚合组 interface GigabitEthernet 1/0/1 port link-aggregation group 1 interface GigabitEthernet 1/0/2 port link-aggregation group 1关键就是link-aggregation mode dynamic这一行。加上之后聚合口就会跑LACP协议。有些厂商还支持配置LACP的系统优先级和端口优先级用来控制主动端选举和端口加入顺序。这些是进阶配置一般场景用默认值就行。4.4 验证聚合是否成功配置完之后怎么确认聚合成功了几个常用的检查命令# 查看聚合口状态 display link-aggregation verbose # 查看聚合口的成员端口 display link-aggregation summary # 查看聚合口的流量统计 display interface Bridge-Aggregation 1重点看几个信息聚合口的状态是不是UP。成员端口是不是都加入了聚合组状态是不是Selected。成员端口的LACP状态是不是Success动态聚合。聚合口的带宽是不是所有成员链路带宽之和。如果成员端口状态是Unselected说明它没有加入转发。可能的原因包括配置不一致、对端没有聚合、LACP协商失败等。需要进一步排查。5. 那些文档不会告诉你的坑5.1 聚合口起来了但流量跑不满这是最常见的问题。聚合口显示UP成员端口也都是Selected但实际流量就是跑不满总带宽。原因通常是哈希极化。前面讲过链路聚合是基于流做负载分担的如果流量集中在一两条流上那只能走一两条链路其他链路闲着。怎么判断是不是极化看每条成员链路的流量统计。如果一条链路利用率很高其他链路很低那就是极化了。解决办法换哈希因子。如果当前用的是源MAC哈希试试源IP目的IP哈希。增加流的数量。如果是备份场景可以开多个并发备份任务让流量分散开。如果流量确实集中在少数几条流上那链路聚合解决不了这个问题考虑其他方案。我遇到过一个案例某公司的备份流量怎么都跑不满聚合带宽后来发现备份软件只开了一个TCP连接。改成多线程备份之后流量立刻上去了。所以有时候问题不在网络在应用。5.2 拔一根线业务抖动甚至中断按理说链路聚合断一条线业务应该不受影响只是带宽减半。但实际环境中拔线导致业务抖动甚至短暂中断的情况并不少见。原因可能有几个第一聚合模式是静态聚合而且中间有传输设备。拔掉一条线物理层可能没有立刻DOWN比如中间有光电转换器交换机还以为链路是通的继续往这条链路发包但包实际上已经丢了。这时候业务就会中断直到交换机检测到物理层DOWN才切换流量。第二STP收敛导致短暂环路或阻塞。链路聚合口在STP里被当作一个逻辑口拔掉一条成员链路STP可能重新计算导致短暂收敛。虽然聚合口的STP状态通常不变但某些厂商的实现可能会有短暂抖动。第三ARP表项或MAC表项没有及时更新。拔掉一条链路后流量切换到另一条链路但ARP表或MAC表可能还指向原来的链路导致短暂丢包。怎么缓解用动态聚合LACP能更快检测到链路故障。开启BFD或者链路快速检测机制加快故障检测速度。调整STP参数减少收敛时间。如果对抖动极度敏感考虑用M-LAG或者堆叠冗余级别更高。5.3 跨厂商聚合的兼容性问题不同厂商的交换机做链路聚合有时候会遇到兼容性问题。虽然LACP是标准协议但各家实现可能有细微差别。常见的兼容性问题包括LACPDU的发送间隔不一样。标准是30秒但有些厂商默认是1秒或者快速模式。主动端选举规则不一样。标准是根据系统优先级和MAC地址但有些厂商的实现可能有偏差。端口优先级的取值范围不一样。标准是1-65535但有些厂商只支持部分值。遇到兼容性问题通常的解决办法是两端都配置成被动模式让其中一端主动发起协商。调整LACPDU的发送间隔两端保持一致。查两端的文档确认LACP的实现细节尽量用标准配置。如果实在搞不定退而求其次用静态聚合。静态聚合不跑协议兼容性问题少很多。5.4 聚合口上的STP配置陷阱链路聚合口在STP里被当作一个逻辑口它的STP状态会影响所有成员链路。如果聚合口的STP状态是Blocking那所有成员链路都不转发流量。有个常见的坑聚合口配置了STP边缘端口edgenport但成员链路没有配置。结果聚合口是边缘端口成员链路不是STP状态不一致导致流量异常。正确的做法是在聚合口上配置STP参数成员链路继承聚合口的配置。不要单独在成员链路上配置STP。另外如果聚合口连接的是服务器服务器端做了bonding那交换机侧的聚合口应该配置STP边缘端口避免STP收敛导致服务器网络抖动。6. 出问题了怎么查一套排查思路6.1 先看物理层和聚合口状态排查链路聚合问题第一步永远是看物理层和聚合口状态。# 查看物理端口状态 display interface GigabitEthernet 1/0/1 display interface GigabitEthernet 1/0/2 # 查看聚合口状态 display link-aggregation verbose重点看物理端口是不是UP。聚合口是不是UP。成员端口是不是Selected。成员端口的LACP状态是不是Success。如果物理端口DOWN检查网线、光模块、对端端口。如果聚合口DOWN检查聚合口配置。如果成员端口Unselected检查配置一致性和对端聚合状态。6.2 再看流量分布和哈希因子如果聚合口状态正常但流量跑不满看流量分布# 查看每条成员链路的流量统计 display interface GigabitEthernet 1/0/1 display interface GigabitEthernet 1/0/2对比每条链路的输入输出速率。如果一条高一条低就是哈希极化。尝试换哈希因子或者增加流的数量。6.3 最后看日志和告警如果以上都正常但业务还是有问题看日志# 查看日志 display logbuffer # 查看LACP统计 display lacp statistics日志里可能有LACP协商失败、端口加入失败、STP拓扑变化等信息。根据日志进一步排查。6.4 一个真实的排查案例之前遇到过一个案例两台交换机做了动态聚合聚合口UP成员端口都是Selected但业务时通时断。排查过程看物理层端口都是UP光模块正常。看聚合口状态UP成员端口Selected。看LACP统计发现LACPDU收发正常但偶尔有超时。看日志发现有STP拓扑变化的记录。查STP配置发现聚合口没有配置边缘端口STP偶尔收敛导致短暂阻塞。解决办法在聚合口上配置STP边缘端口问题解决。这个案例说明链路聚合的问题不一定在聚合本身可能在关联的STP、VLAN等配置上。排查时要全面看不要只盯着聚合口。7. 生产环境中的经验之谈7.1 聚合口描述一定要写清楚这个看起来是小事但实际很重要。聚合口如果不写描述过几个月你自己都不记得这个口是连哪里的。尤其是核心设备上聚合口多的时候没有描述根本分不清。我的习惯是聚合口描述写清楚对端设备名称和用途比如To-Access-SW-01-Uplink。成员端口也写描述标明属于哪个聚合组。7.2 变更前一定要做备份和回滚方案链路聚合的配置变更尤其是核心链路的变更风险很高。变更前一定要备份当前配置。准备好回滚命令。在业务低峰期操作。如果可能先在测试环境验证。我见过有人直接在核心交换机上改聚合配置结果聚合口起不来业务断了半小时。如果有回滚方案几分钟就能恢复。7.3 监控聚合口和成员链路聚合口和成员链路都要监控。监控聚合口的总流量也监控每条成员链路的流量。如果发现某条成员链路流量异常低可能是哈希极化或者链路故障。监控指标包括聚合口UP/DOWN、成员链路UP/DOWN、每条链路的流量、LACP状态、STP状态等。7.4 定期检查配置一致性链路聚合的成员端口配置必须一致。但实际环境中可能有人改了某个成员端口的配置导致不一致。定期检查配置一致性能提前发现问题。可以写个脚本定期对比成员端口的配置发现不一致就告警。7.5 文档和拓扑图要更新链路聚合的配置变更后文档和拓扑图要及时更新。不然下次排查问题的时候看着过时的拓扑图根本对不上。我个人的习惯是每次变更后立刻更新拓扑图和配置文档标注变更日期和变更人。这样即使过了很久也能快速了解当前状态。链路聚合这个技术配置本身不难难的是理解它的工作机制和在实际环境中的表现。希望这篇文章能帮你少踩几个坑在遇到问题的时候能快速定位和解决。如果有什么疑问或者自己的经验欢迎交流。