链路聚合实战指南：原理、配置与故障排查

1. 链路聚合到底解决了什么问题很多刚接触网络运维的朋友第一次听到“链路聚合”这个词脑子里冒出来的画面可能是把几根网线捆在一起觉得这不过是个物理层面的小把戏。但真到了机房里面对两台交换机之间那根被业务流量压得喘不过气的千兆线或者核心层与接入层之间需要更高带宽却又不愿意花大价钱换万兆模块的时候你就会发现链路聚合几乎是性价比最高的那个选择。链路聚合行业内也常叫端口聚合、链路捆绑或者以太通道它的核心逻辑就是把交换机上多个物理端口绑成一个逻辑端口来用。这个逻辑端口对外表现出来的是一根链路但实际承载流量的是背后那好几根物理线。这样做带来的好处是双重的一方面是带宽叠加比如四根千兆线聚合成一条逻辑链路理论吞吐就能到四千兆另一方面是冗余备份其中一根线断了只要还有活着的成员端口业务就不会断聚合组会自动把流量重新分配到剩余的线路上。我见过不少中小企业的网络架构核心交换机和接入交换机之间就靠一根线撑着一旦这根线被施工挖断或者接口故障整个楼层就瘫了。后来他们上了链路聚合用两根线做捆绑成本增加有限但网络的健壮性上了一个台阶。所以这篇文章我想从实际动手的角度把链路聚合的技术细节、配置思路、排错经验完整地聊一遍。不管你是刚入行的网络小白还是已经配过几次聚合但总遇到奇怪问题的老手应该都能从下面的内容里找到一些能直接拿去用的东西。2. 链路聚合的核心原理与关键概念拆解2.1 聚合组、成员端口与逻辑接口的关系要理解链路聚合先得把几个基础概念理清楚。聚合组是一个逻辑上的容器你把多个物理端口加进这个组它们就成了一家人。每个加进去的物理端口叫成员端口而聚合之后对外呈现的那个接口叫逻辑接口不同厂商的叫法不太一样有的叫聚合口有的叫端口通道还有的叫绑定接口。这里有个关键点逻辑接口的配置会下发到所有成员端口上。比如你在逻辑接口上配了允许通过的VLAN列表那所有成员端口都会继承这个配置。但成员端口自己也可以有一些独立的物理参数比如速率、双工模式这些通常需要保持一致否则聚合可能起不来。我个人的习惯是在把端口加入聚合组之前先把它们的物理参数手动固定下来比如强制千兆全双工避免因为自协商结果不一致导致聚合组不稳定。还有一个容易混淆的地方逻辑接口的MAC地址。有些厂商会从成员端口里选一个作为主端口用它的MAC作为逻辑接口的MAC有些则是自动生成一个。这个细节在排查一些二层协议问题的时候会用到比如生成树计算时看到的桥MAC到底是哪个心里要有数。2.2 流量负载分担的几种常见算法链路聚合把多条物理链路绑在一起但流量并不是均匀地每根线分一点。它需要一个哈希算法来决定哪条流走哪根线。常见的算法有基于源MAC、目的MAC、源IP、目的IP或者这些元素的组合。你可以把它想象成高速公路的多个收费口每辆车根据车牌号或者目的地被分配到某个收费口通过而不是所有车都挤在一个口。这里有个非常重要的经验哈希算法的选择直接决定了负载分担的效果。如果你选的是基于源MAC的算法而网络里大部分流量都来自同一个网关设备的同一个MAC那所有流量都会走同一条物理线其他线闲着聚合等于白做。我遇到过好几次这种情况客户抱怨说做了聚合但带宽没上去一查发现算法选错了流量全压在一条线上。一般来说如果流量是南北向的也就是内网到外网源MAC和目的MAC都比较分散用MAC-based的算法问题不大。但如果是服务器和存储之间的流量可能源IP和目的IP更丰富用IP-based的算法效果更好。最稳妥的办法是实际抓包看看流量特征或者直接选基于源和目的IP加端口的五元组算法这样哈希散列的范围最广。不过要注意有些低端交换机不支持太复杂的哈希算法选型的时候要确认清楚。2.3 静态聚合与动态聚合的取舍链路聚合分静态和动态两种模式。静态聚合就是两边交换机都手动配置好不跑协商协议只要物理链路通了、配置匹配了聚合组就起来。动态聚合则会跑一个协商协议比较常见的是LACP也就是链路聚合控制协议。两边交换机会通过LACPDU报文互相交换信息确认哪些端口可以加入聚合组哪些端口因为参数不一致被踢出去。静态聚合的优点是配置简单不依赖协议交互兼容性好老设备也支持。但缺点是如果一边配置改了另一边没改或者中间传输设备把某些报文丢了可能导致聚合组状态异常但又不自知。动态聚合则更智能它能自动检测链路故障、端口参数不匹配等问题并且会把有问题的端口从聚合组里暂时移除等恢复正常了再加回来。缺点是配置稍微复杂一点而且两边必须都支持LACP。我的建议是如果两边设备都支持LACP优先用动态聚合。尤其是在跨设备、跨厂商的环境里LACP能帮你省掉很多排查的麻烦。静态聚合更适合那些老旧设备或者对协议交互有严格限制的场景。但不管用哪种两边的模式必须匹配一边静态一边动态是绝对起不来的。3. 动手前的准备工作与选型考量3.1 硬件与线缆的匹配检查在敲命令之前有些物理层面的东西必须先确认。首先是成员端口的速率和双工模式必须一致。你不能把一根千兆线和一根百兆线聚合成一个组交换机不会允许这样操作即使强行配置了聚合组也起不来。同样全双工和半双工也不能混用。我一般会建议把所有成员端口的速率和双工手动固定不要用自协商因为自协商在某些劣质线缆或者光模块上可能会出问题导致端口反复up/down聚合组跟着震荡。线缆本身也有讲究。如果是电口超五类线跑千兆没问题但如果是长距离或者电磁环境复杂的机房建议用六类线。如果是光口要确认光模块的波长、传输距离和光纤类型匹配。我见过有人把多模模块插到单模光纤上端口根本起不来还以为是交换机坏了。另外聚合组里的成员端口最好分布在不同板卡上如果是模块化交换机的话。这样万一某块板卡故障不会导致整个聚合组全挂。如果是固定端口交换机那至少确保端口来自不同的端口组避免内部总线成为瓶颈。3.2 聚合组编号与端口规划规划聚合组编号看起来是小事但如果不提前规划好后期维护会很乱。我的习惯是按业务或者按对端设备来编号。比如核心交换机到接入交换机A的聚合组用1号到接入交换机B的用2号服务器接入用10号开始。这样一看编号就知道这条聚合链路是干什么的。成员端口的选择也要有规划。不要随便找两个空闲端口就绑上要考虑端口的位置、标签、走线是否方便。最好在配线架上做好标记写明这个端口属于哪个聚合组。我吃过亏有一次排查故障发现某个聚合组的成员端口在配线架上标签掉了花了半天才理清楚哪根线对应哪个口。从那以后我要求所有聚合组的端口标签必须用机打标签手写的不要。另外如果交换机支持堆叠或者横向虚拟化跨设备的链路聚合是更高级的玩法。比如两台核心交换机堆叠成一台逻辑设备然后接入交换机用两根线分别上联到两台核心做成一个跨设备聚合组。这样既有了链路冗余又有了设备冗余可靠性更高。但这需要交换机支持相应的堆叠技术配置也更复杂后面我会单独展开讲。3.3 业务流量的特征分析在决定用哪种负载分担算法之前最好先摸清楚业务流量的特征。如果条件允许可以在交换机上开个端口镜像把聚合组其中一个成员端口的流量镜像出来用抓包工具分析一下。看看源IP、目的IP、源MAC、目的MAC的分布情况。如果发现大量流量都是同一个源和同一个目的那不管用什么哈希算法都只能走同一条线这时候聚合的意义就不大了得考虑其他方案比如换更高速率的单链路。还有一种情况是流量本身就不大但要求高可靠。比如办公网络平时流量可能就几十兆但断网一分钟业务就停摆。这种场景下聚合的主要目的是冗余而不是带宽那负载分担算法就没那么关键了随便选一个都行重点是保证成员端口分布合理避免单点故障。我一般会建议在业务低峰期做这个流量分析避免影响正常使用。如果交换机支持sFlow或者NetFlow也可以直接看流量统计不用镜像抓包那么麻烦。但要注意有些低端交换机的流量统计精度不够只能看个大概不能作为精确依据。4. 主流厂商配置实操与命令解析4.1 华为交换机链路聚合配置示例华为交换机的链路聚合配置逻辑比较清晰。先创建聚合口然后把物理口加进去。我以两台交换机互联为例假设用G0/0/1和G0/0/2两个口做聚合聚合组编号为1。# 在系统视图下创建聚合接口 interface Eth-Trunk 1 mode lacp-static port link-type trunk port trunk allow-pass vlan 10 20 30 # 把物理口加入聚合组 interface GigabitEthernet 0/0/1 eth-trunk 1 interface GigabitEthernet 0/0/2 eth-trunk 1这里有几个细节要注意。mode lacp-static表示用静态LACP模式也就是两边都配了LACP但不会动态协商主动/被动角色。如果要用动态LACP命令是mode lacp。华为还有手工负载分担模式命令是mode manual load-balance那就是纯静态聚合不跑LACP。配置完之后可以用display eth-trunk 1查看聚合组状态。重点看成员端口的状态是不是Selected如果是Unselected说明端口有问题可能是物理链路没通或者两边配置不一致。我遇到过一种情况一边配了LACP一边配了手工模式结果端口一直是Unselected查了半天才发现模式不匹配。华为的负载分担算法可以通过load-balance命令调整比如load-balance src-dst-ip就是基于源和目的IP做哈希。默认算法可能是基于MAC的如果流量特征不匹配记得改一下。4.2 思科交换机链路聚合配置示例思科这边链路聚合叫EtherChannel。配置方式也分静态和动态动态用的是PAgP或者LACP。PAgP是思科私有的LACP是标准的。如果对端不是思科设备必须用LACP。interface range GigabitEthernet0/1 - 2 channel-group 1 mode active channel-protocol lacp interface Port-channel1 switchport mode trunk switchport trunk allowed vlan 10,20,30mode active表示主动发起LACP协商对端可以配成passive被动模式。如果两边都配成passive那就协商不起来了这点要注意。静态模式的话命令是channel-group 1 mode on但我不太推荐用静态模式除非对端设备实在太老不支持LACP。思科的负载分担算法是通过全局命令port-channel load-balance来设置的后面跟算法类型比如src-dst-ip、src-dst-mac等。这个命令是全局生效的改完之后所有EtherChannel都会用新算法。我一般会在业务割接前就规划好算法避免上线后再改因为改算法可能会导致短暂的流量中断。查看状态的命令是show etherchannel summary输出里会显示每个聚合组的成员端口和状态。如果看到端口后面标着(P)表示在聚合组里且正常工作如果是(I)表示独立状态没加进去如果是(D)表示down。这些状态码要记熟排错的时候一眼就能看出问题。4.3 跨设备链路聚合的进阶玩法跨设备链路聚合华为叫M-LAG思科叫vPC其他厂商也有类似的技术。它的核心思想是两台物理交换机对外表现为一台逻辑交换机然后接入设备用两根线分别上联到这两台交换机做成一个聚合组。这样接入设备看到的是一个聚合组但实际上联到了两台不同的物理设备上。配置跨设备聚合比单设备聚合复杂得多。首先两台核心交换机之间要建立对等链路同步状态信息。然后要配置一个虚拟MAC地址作为逻辑接口的MAC。接入设备那边就正常配聚合组不需要知道对端是两台设备。这种方案的好处是显而易见的既有了链路冗余又有了设备冗余。一台核心交换机挂了接入设备通过另一台照样能通信。但缺点也很明显配置复杂排错困难而且对设备型号有要求不是所有交换机都支持。我建议只有在核心层或者对可靠性要求极高的场景才上这个方案接入层用普通的单设备聚合就够了。配置的时候要特别注意版本兼容性。两台核心交换机的软件版本最好一致否则可能出现状态同步异常。我遇到过因为版本不一致导致M-LAG起不来升级到同一版本后问题就解决了。另外对等链路的带宽要足够因为所有跨设备转发的流量都要走这条链路如果带宽不够会成为新的瓶颈。5. 负载分担效果验证与调优5.1 如何判断聚合组是否在正常工作配完聚合组怎么知道它到底有没有在干活最直接的方法是看成员端口的流量计数器。在华为交换机上可以用display interface eth-trunk 1查看聚合口的总体流量然后用display interface gigabitethernet 0/0/1和display interface gigabitethernet 0/0/2分别查看每个成员端口的流量。如果两个成员端口都有流量而且流量比例大致符合预期说明负载分担在起作用。但要注意流量计数器是累计值要看的是速率而不是总量。可以用display interface brief看实时速率或者隔几秒连续执行几次display interface命令手动算一下差值。如果发现所有流量都走同一个端口另一个端口只有零星的管理报文那大概率是哈希算法选得不对或者流量特征太单一。思科这边可以用show interfaces port-channel 1看聚合口状态用show interfaces gigabitethernet0/1看成员口流量。还有一个好用的命令是show etherchannel load-balance可以查看当前的负载分担算法和哈希结果。有些平台还支持test etherchannel load-balance interface port-channel 1 ip 1.1.1.1 2.2.2.2这样的命令模拟一个流量看它会走哪个成员口非常直观。5.2 调整哈希算法提升带宽利用率如果发现负载分担不均第一步就是调整哈希算法。前面说过算法选择取决于流量特征。我一般会按这个顺序尝试先试基于源和目的IP的算法如果不行再试基于源和目的MAC的再不行就试基于源IP和目的IP加四层端口的五元组算法。每次改完算法都要重新观察成员端口的流量分布。但这里有个现实问题即使算法选得再好如果流量本身哈希熵不够比如只有一条TCP流那不管怎么哈希都只能走一条线。这种情况下聚合组只能提供冗余不能提供带宽叠加。要解决带宽问题要么把一条大流拆成多条小流比如用多线程下载工具要么换更高速率的单链路。我见过有人为了跑满聚合带宽专门写了个脚本开多个并发连接虽然有点取巧但确实能验证聚合组的带宽叠加能力。还有一个容易被忽略的点聚合组的带宽是双向的。比如四根千兆线聚合总带宽是四千兆但这是上下行加起来的概念。如果业务是单向的大流量比如备份服务器往存储写数据那上行带宽可能跑满四千兆但下行只有很少的确认报文。这种情况下负载分担算法要针对上行流量的特征来优化。5.3 聚合组带宽的实际测试方法理论带宽和实际带宽往往有差距。要准确测试聚合组的实际吞吐最好用专业的打流工具比如IxChariot或者iperf。用iperf的话可以在两端各起一个服务端和客户端开多个并发连接来打流。比如iperf -c 对端IP -P 8就是开8个并发连接这样能更好地利用聚合组的带宽。测试的时候要注意两端的服务器或者测试机的网卡本身不能成为瓶颈。如果测试机只有一块千兆网卡那不管聚合组是四千兆还是八千兆测试结果都不会超过千兆。所以测试机最好也做链路聚合或者用多块网卡分别接入不同的成员端口。我见过有人用一台单网卡的笔记本去测四千兆的聚合组然后抱怨说带宽只有千兆这就是测试方法本身有问题。另外测试时间要足够长至少跑个几十秒避免因为TCP慢启动导致结果偏低。测试方向也要双向都测因为有些交换机的负载分担算法对上下行的处理可能不一样。如果条件允许最好在业务低峰期做测试避免影响正常业务。6. 常见故障排查与避坑经验6.1 聚合组起不来的几种典型原因聚合组起不来是最常见的问题原因五花八门。我整理了一个速查表按出现频率从高到低排列故障现象可能原因排查方法成员端口状态为Unselected两边模式不匹配检查两边是静态还是动态LACP还是手工成员端口状态为Unselected物理参数不一致检查速率、双工、VLAN配置是否相同聚合组完全down物理链路故障检查线缆、光模块、端口指示灯聚合组时up时down线缆或光模块不稳定查看日志检查端口错包计数部分成员端口不在组里端口被其他配置占用检查端口是否已加入其他聚合组或配了其他业务模式不匹配是最常见的。一边配了LACP另一边配了手工负载分担那肯定起不来。我建议在配置前先确认两边的模式最好写在割接方案里避免临场忘记。物理参数不一致也很常见尤其是速率和双工。有些交换机默认是自协商如果一边协商成千兆全双工另一边协商成百兆半双工聚合组就起不来。所以我在前面强调过手动固定物理参数。还有一个坑是VLAN配置不一致。如果聚合口上允许通过的VLAN列表两边不一样虽然聚合组可能能起来但某些VLAN的流量会不通。这种问题比较隐蔽因为聚合组状态看起来是正常的但业务就是不通。排查的时候要仔细核对两边的VLAN配置包括允许列表和PVID。6.2 流量不均的排查思路流量不均的问题比聚合组起不来更隐蔽因为聚合组状态是正常的但性能不达标。排查思路是这样的先确认成员端口是否都在Selected状态如果有Unselected的先解决那个问题。然后看成员端口的流量计数器确认是不是所有流量都走一个口。如果是再检查负载分担算法。算法检查完之后如果还是不均就要分析流量特征了。可以在交换机上做端口镜像把聚合口的流量镜像到一个空闲端口然后用抓包工具分析。重点看源IP、目的IP、源MAC、目的MAC的分布。如果发现大量流量的这几个字段都相同那说明哈希熵不够换什么算法都没用。这时候要么接受现实要么从业务层面想办法比如把大流拆成小流。还有一种情况是聚合组里混入了不同速率的端口。比如三个千兆口加一个百兆口做聚合那百兆口会成为瓶颈而且负载分担算法可能会把更多流量分到千兆口上导致百兆口利用率很低。所以聚合组的成员端口速率必须一致这是硬性要求。6.3 聚合组与生成树的交互问题链路聚合和生成树协议一起用的时候有一些需要注意的地方。聚合组在生成树看来是一个逻辑端口只参与一次生成树计算。这本来是好事减少了拓扑复杂度。但如果配置不当可能会出现生成树阻塞了聚合组的情况导致所有成员端口的流量都被阻断。我遇到过一种情况两台交换机之间做了聚合组但同时还有一条备用链路。生成树计算后把聚合组阻塞了备用链路反而在转发。这是因为生成树的路径开销计算方式导致的聚合组的开销可能比备用链路还大。解决办法是调整生成树的端口开销让聚合组优先转发。或者干脆把备用链路也做成聚合组的一部分这样生成树就只有一个逻辑端口不存在选路问题了。另外如果聚合组里某个成员端口被生成树阻塞了那这个端口就不会转发流量但它在聚合组里还是Selected状态。这种情况比较少见但一旦出现会导致聚合组实际可用带宽下降。排查的时候要同时看聚合组状态和生成树状态确认没有成员端口被生成树阻塞。7. 链路聚合在不同场景下的应用策略7.1 核心层与接入层之间的聚合部署核心层和接入层之间的链路是网络的主干道也是最需要链路聚合的地方。通常的做法是在接入交换机上用两个或者四个上行口分别连接到核心交换机的不同板卡或者不同设备上。如果核心交换机是堆叠的那就跨设备聚合如果是单台那就普通聚合。这个场景下我建议用动态LACP并且开启LACP的抢占功能。抢占功能的意思是当之前故障的端口恢复正常后它会自动重新加入聚合组并参与流量转发。如果不开启抢占故障端口恢复后可能一直处于待机状态直到聚合组重新协商。华为的LACP抢占默认是关闭的需要手动开启命令是lacp preempt enable还可以设置抢占延时避免端口刚恢复就加入导致震荡。带宽规划方面接入层的上行带宽要根据接入用户的数量和业务类型来定。如果接入的是办公电脑每台电脑平均按一百兆到两百兆的并发流量估算一台二十四口的接入交换机上行至少需要两个千兆口做聚合。如果接入的是服务器或者摄像头那带宽需求更高可能需要四个千兆口或者直接上万兆。7.2 服务器接入场景的聚合配置要点服务器接入和交换机互联不太一样。服务器端的网卡要做绑定操作系统层面也要配置。常见的服务器操作系统都支持网卡绑定比如Linux的bonding模块Windows的NIC Teaming。配置的时候要注意服务器端的绑定模式和交换机端的聚合模式要匹配。如果交换机端用的是静态聚合服务器端一般用mode 0或者mode 2。mode 0是轮询模式所有网卡轮流发送负载分担效果一般但兼容性好。mode 2是异或模式基于源和目的MAC做哈希需要交换机端配静态聚合。如果交换机端用的是LACP动态聚合服务器端要用mode 4也就是802.3ad模式。这个模式支持LACP协商能和交换机端配合得更好。服务器场景下还有一个特殊问题如果服务器上跑的是虚拟机虚拟交换机的上行链路也要做聚合。比如VMware的vSphere Distributed Switch支持LACP但配置起来比物理交换机复杂。我建议在虚拟化环境下先在小范围测试通过后再上生产因为虚拟交换机的LACP实现和物理交换机可能有差异容易出现兼容性问题。7.3 存储网络与高带宽需求的聚合方案存储网络对带宽和延迟的要求比普通业务网络高得多。iSCSI或者NFS存储流量通常是突发的大块数据传输对负载分担算法很敏感。如果算法选得不好存储流量全压在一条线上性能会急剧下降。我的经验是存储网络的聚合组最好用基于源和目的IP加四层端口的五元组算法这样哈希散列最均匀。如果交换机支持基于流的动态负载分担就更好了它能根据实时流量情况调整分配策略。另外存储网络的聚合组成员端口最好全部来自同一块板卡或者同一组芯片避免内部转发路径不一致导致延迟抖动。带宽规划方面存储网络一般建议至少四千兆起步如果预算允许直接上万兆。因为存储流量的突发性很强四千兆聚合在业务高峰期可能还是不够用。我见过一个视频编辑团队用四千兆聚合跑共享存储平时没问题但多个人同时渲染的时候就会卡顿后来换成万兆聚合才解决。8. 个人实操心得与进阶建议链路聚合这个技术说简单也简单敲几条命令就能配好说复杂也复杂各种模式、算法、兼容性问题能让人折腾好几天。我这些年配过的聚合组没有一千也有几百个了踩过的坑总结下来其实大部分问题都出在细节上。第一个心得是配置前一定要做物理检查。线缆、光模块、端口速率、双工模式这些看起来是小事但往往是问题的根源。我现在养成了一个习惯配聚合之前先用display interface把每个成员端口的物理状态看一遍确认没有错包、没有CRC错误、速率双工一致然后再动手配。这个习惯帮我省了很多事后排查的时间。第二个心得是两边配置要对称。不光是聚合模式要匹配VLAN配置、生成树配置、QoS配置都要尽量一致。我遇到过一边配了VLAN修剪另一边没配导致某些VLAN流量不通的情况。后来我干脆写了一个配置检查清单每次配聚合组之前对着清单过一遍确保两边没有遗漏。第三个心得是不要迷信理论带宽。四根千兆线聚合理论带宽是四千兆但实际能跑到三千兆就算不错了。因为哈希算法不可能完美均匀而且交换机内部转发也有开销。所以做带宽规划的时候要留足够的余量不要按理论值去算。我一般按理论值的百分之六十到七十来估算实际可用带宽这样比较稳妥。第四个心得是文档和标签比配置本身更重要。聚合组的配置可能几个月都不会动但一旦出问题如果没有文档和标签排查起来会非常痛苦。我现在要求所有聚合组必须有文档记录包括聚合组编号、成员端口、对端设备、配置模式、负载分担算法最好再附上拓扑图。配线架上的标签也要清晰用机打的不要手写。最后一个建议是如果条件允许在实验环境里先把各种模式和算法都试一遍。静态聚合、动态LACP、不同哈希算法、跨设备聚合都动手配一次看看效果和报错信息。这样到了生产环境遇到问题心里就有底了。我刚开始学的时候就是在实验室里拿两台旧交换机反复折腾把各种错误都触发了一遍后来去客户现场配聚合基本都是一次过。链路聚合这个技术本身不算新但它在实际网络里的价值一直很稳定。只要物理链路还是主要传输介质只要带宽需求还在增长链路聚合就会一直有用武之地。把基础打牢把细节抠清楚它就能成为你网络架构里最可靠的那块基石。