
1. 链路聚合到底解决了什么问题第一次接触链路聚合是在一个模拟器实验里两台交换机之间只连了一根线跑流量的时候直接卡成幻灯片。当时第一反应是换根更粗的线但现实里线缆的带宽是有物理上限的千兆口就是千兆口万兆口就是万兆口你不可能靠换一根超级网线把带宽翻十倍。链路聚合的思路就完全不一样了——既然一根线不够用那就把多根线捆在一起让它们逻辑上变成一根粗线。这个捆的动作在行业里叫链路聚合英文是Link Aggregation各家厂商叫法不太一样。在思科体系里它叫EtherChannel在华为体系里叫Eth-Trunk在通用标准里叫LACP链路聚合控制协议或者802.3ad。名字五花八门但核心逻辑是一致的把多条物理链路绑定成一条逻辑链路对外只呈现一个逻辑接口从而实现带宽叠加、链路冗余和负载分担。我之所以拿思科模拟器来做这个实验是因为它能把整个协商过程、状态变化、故障切换都直观地展示出来比在真机上盲调要清楚得多。这篇文章适合两类人看一类是刚学网络、搞不清楚EtherChannel和LACP区别的新手另一类是配过聚合但总遇到起不来一边通一边不通这类问题的朋友。我会从设计思路讲到具体配置再到排查技巧尽量把踩过的坑都摊开说。需要先明确一个概念链路聚合不是带宽乘以链路数这么简单。两条千兆线捆一起理论带宽是2Gbps但单条数据流的带宽上限仍然是1Gbps。因为聚合的负载分担是基于流的哈希算法同一条流比如同一个源IP到同一个目的IP只会走其中一条物理链路。这一点很多人一开始会误解以为捆两根线单个大文件传输就能跑到2Gbps实际跑下来还是1Gbps左右然后就开始怀疑配置错了。不是配置错是原理如此。2. 核心概念与方案选型拆解2.1 手工聚合与LACP协商聚合的区别链路聚合在配置层面分两大流派这个必须先搞清楚否则后面配置的时候会一头雾水。手工模式Static/On模式两端的聚合口都强制设为On不跑任何协商协议。只要两端配置的成员接口一致聚合就能起来。优点是简单直接不依赖协议报文缺点是没有任何握手确认机制如果一端配了聚合、另一端没配或者成员口对不上可能出现环路或者流量黑洞而且自己不会报错排查起来很痛苦。LACP模式动态协商两端通过LACPDU报文互相协商确认哪些链路可以加入聚合组。它有一个主动端和被动端的概念主动端负责决策哪些链路活跃。优点是可靠性高一端配置有问题另一端能感知到不会闷头转发缺点是配置稍复杂需要理解系统优先级、端口优先级这些参数。我个人的建议是只要设备支持优先用LACP。手工模式看起来省事但省的那点事在出故障的时候会加倍还回来。模拟器里两种都能做但LACP能观察到的状态变化更丰富学习价值更高。2.2 二层聚合与三层聚合的适用场景聚合口本身可以工作在二层也可以工作在三层这个选择取决于你的网络设计。二层聚合Layer 2 EtherChannel是把聚合口当作一个交换口用通常配置成Trunk连接两台交换机。这是最常见的场景比如接入层交换机上行到汇聚层用两条线做聚合既增加带宽又提供冗余。三层聚合Layer 3 EtherChannel是把聚合口当作一个路由口用上面直接配IP地址通常用于两台三层设备之间的互联。这种场景下聚合口不参与VLAN标签的转发纯粹做路由转发。选哪个取决于你的拓扑需求。如果是交换机之间的互联且中间要透传多个VLAN那必须用二层聚合配Trunk。如果是两台核心设备之间做三层互联那用三层聚合更干净。模拟器实验里我建议两种都做一遍感受一下配置差异。2.3 负载分担算法的选择逻辑聚合组起来之后流量怎么分配到各条物理链路上是由负载分担算法决定的。思科设备上常见的算法有基于源MAC、目的MAC、源目的MAC、源IP、目的IP、源目的IP等。这里有个实操经验算法要选得散。什么意思如果你的流量源IP很集中比如都来自同一个服务器那基于源IP的算法就会把所有流量压到同一条链路上其他链路闲着聚合等于白做。这时候应该选基于目的IP或者源目的IP的算法让流量能分散开。模拟器里默认算法通常是基于源目的IP的这个在大多数场景下够用。但如果你的实验里发现某条链路流量特别大、其他链路很闲就要考虑换算法了。这个细节很多教程不讲但实际排障时经常遇到。3. 模拟器环境搭建与基础配置实操3.1 实验拓扑设计与设备准备我用的拓扑很简单两台三层交换机中间用两条线互联分别接在双方的GigabitEthernet0/1和0/2口上。两端各下挂一台PC用于测试连通性。这个拓扑足够演示聚合的建立、验证和故障切换。设备选型上模拟器里选支持EtherChannel的交换机型号即可二层或三层都行我这次用三层交换机是为了顺便演示三层聚合。接口速率统一用千兆避免速率不一致导致聚合起不来——成员口的速率、双工模式必须一致这是硬性要求速率不匹配的接口无法加入同一个聚合组。配置前先确认一件事两端的成员口数量要对应。一端用了0/1和0/2另一端也得用两个口不能一边两个一边三个。LACP虽然能协商但成员口数量不对等会导致部分链路处于备用状态这个后面会讲到。3.2 二层EtherChannel配置全过程先做二层聚合。在两台交换机上分别进入接口配置模式把成员口加入聚合组。交换机A的配置SwitchA(config)# interface range gigabitEthernet 0/1 - 2 SwitchA(config-if-range)# channel-group 1 mode active SwitchA(config-if-range)# exit SwitchA(config)# interface port-channel 1 SwitchA(config-if)# switchport trunk encapsulation dot1q SwitchA(config-if)# switchport mode trunk SwitchA(config-if)# switchport trunk allowed vlan 10,20交换机B做对称配置channel-group编号可以不同但模式要匹配。这里我用了mode active表示主动发起LACP协商。如果一端active一端passive也能起来但两端都passive就起不来因为没人主动发起。这个细节新手很容易踩。配置完先别急着测用show etherchannel summary看一眼状态。正常的话应该看到聚合组的状态是SU其中S表示二层U表示in use在用。如果看到的是Ddown或者Pbundled但standby那就有问题需要进一步查。3.3 三层EtherChannel配置要点三层聚合的配置略有不同成员口加入聚合组后IP地址配在port-channel接口上而不是物理口上。SwitchA(config)# interface range gigabitEthernet 0/3 - 4 SwitchA(config-if-range)# no switchport SwitchA(config-if-range)# channel-group 2 mode active SwitchA(config-if-range)# exit SwitchA(config)# interface port-channel 2 SwitchA(config-if)# no switchport SwitchA(config-if)# ip address 10.0.0.1 255.255.255.252注意no switchport这个命令它把二层口转成三层口。成员口和port-channel口都要执行顺序上先成员口后聚合口。如果忘了在成员口上执行聚合口配了IP也不通因为物理口还是二层状态。三层聚合起来之后用show ip interface brief能看到port-channel口的状态是upIP地址生效。这时候从对端ping这个地址应该能通。4. LACP协商机制与状态验证4.1 LACP报文交互与主动端选举LACP的协商过程值得单独讲一下因为理解了它排查问题就有方向了。两端启用LACP后会互相发送LACPDU报文。报文里携带了系统优先级、系统MAC、端口优先级、端口号等信息。双方根据这些信息选举出一个主动端主动端负责决定哪些链路进入活跃状态。选举规则是先比系统优先级数值小的优先优先级相同再比系统MAC小的优先。主动端选出来之后它会根据端口优先级决定哪些端口活跃、哪些端口备用。端口优先级数值小的优先活跃。如果成员口数量超过了设备支持的最大活跃链路数比如有些平台一个聚合组最多支持8条活跃链路多出来的链路就进入备用状态主链路故障时才顶上。这个机制在模拟器里可以观察到。你可以故意把一端的系统优先级调低看它是不是变成了主动端。命令是lacp system-priority在全局配置模式下执行。4.2 聚合状态查看与关键字段解读验证聚合状态主要靠几条命令我把常用的列出来命令作用关键看什么show etherchannel summary查看聚合组整体状态标志位SU表示正常D表示downshow etherchannel port-channel查看聚合口详细信息成员口列表、负载分担算法show lacp neighbor查看LACP邻居信息对端系统优先级、端口状态show lacp internal查看本端LACP信息本端端口状态、优先级show interfaces port-channel 1查看聚合口流量统计各成员口收发包是否均衡show etherchannel summary是最常用的输出里每个聚合组前面有一串标志位。S表示二层R表示三层U表示在用P表示捆绑中D表示downI表示独立没加入聚合。看到SU或者RU就是正常的。如果看到成员口后面标的是P而不是U说明链路捆绑了但处于备用状态没在转发流量。这种情况通常是活跃链路数超限或者对端配置有问题。4.3 负载分担效果验证方法聚合配好了怎么确认负载分担真的生效了光看状态是SU不够得看流量。模拟器里可以制造一些流量比如从PC1持续ping PC2然后看各成员口的收发包计数。命令是show interfaces gigabitEthernet 0/1和show interfaces gigabitEthernet 0/2对比两者的input/output packets。如果两条链路的计数都在增长说明负载分担生效了。如果只有一条在涨另一条不动那可能是算法问题或者流量本身就是单条流单条流只走一条链路是正常的。想验证得更明显可以开多个ping会话源IP不同这样基于源IP的算法就能把流量分散到不同链路。模拟器里可以用不同网段的PC来制造多源流量。5. 常见故障与排查技巧实录5.1 聚合起不来的典型原因聚合起不来是最常见的问题我整理了一个速查表现象可能原因排查方法成员口状态D物理链路没通检查连线、接口shutdown状态聚合组状态D两端模式不匹配一端active一端passive可以两端passive不行成员口状态P活跃链路数超限查看最大活跃链路数配置聚合口up但ping不通Trunk允许VLAN没配检查switchport trunk allowed vlan一端SU一端D成员口数量不对等检查两端channel-group成员速率不一致成员口速率/双工不同统一速率和双工模式我踩过最坑的一次是两端都配了passive模式结果聚合死活起不来查了半天才发现是模式问题。LACP要求至少一端是active这个规则一定要记住。还有一个隐蔽的坑成员口的配置必须完全一致。如果一端0/1口配了Trunk允许VLAN 100/2口忘了配那0/2口加入聚合组后可能被踢出来或者导致整个聚合组行为异常。配置成员口的时候最好用interface range一次性配避免遗漏。5.2 流量不均衡的排查思路聚合起来了但流量全压一条链路这个问题也很常见。排查顺序是这样的先确认负载分担算法。用show etherchannel load-balance查看当前算法。如果是基于源MAC而你的流量源MAC都相同比如都经过同一个网关那流量自然集中。换成基于源目的IP的算法试试。再确认流量特征。如果实验里只有一条流单个ping或者单个文件传输那不管什么算法都只会走一条链路这是正常的。要验证负载分担必须有多条流。最后看成员口状态。如果部分成员口是P备用状态那流量当然只走活跃的那几条。检查活跃链路数限制和端口优先级配置。5.3 故障切换测试与验证链路聚合的核心价值之一是冗余所以故障切换必须测。测试方法很简单聚合正常运行的时候把其中一条成员口的线拔掉模拟器里可以shutdown接口观察流量是否中断。正常情况下流量应该无缝切换到剩余链路最多丢一两个包。如果流量中断了好几秒甚至完全不通那说明聚合配置有问题可能是LACP超时时间设置太长或者备用链路没准备好。LACP有两种超时时间短超时3秒和长超时90秒。短超时反应快但报文多长超时反应慢但开销小。默认是长超时故障切换需要等90秒这个在实验里会感觉很明显。想加快切换可以配lacp rate fast改成短超时。我实测下来短超时模式下拔线切换基本无感长超时模式下会断几秒。生产环境里如果对切换时间敏感建议用短超时。6. 进阶技巧与生产环境注意事项6.1 跨设备聚合的思路普通聚合的成员口都在同一台设备上如果这台设备整个挂了聚合再冗余也没用。跨设备聚合比如思科的vPC、华为的M-LAG就是解决这个问题的成员口分布到两台设备上任何一台挂了另一台还能顶。模拟器里做跨设备聚合比较复杂需要特定的平台支持。但思路要清楚跨设备聚合需要两台设备之间有专门的同步链路保证它们对聚合组的状态认知一致否则会出现双活冲突。这个在实验环境里可以先了解概念实际配置等有真机或者支持的环境再深入。6.2 聚合与STP的配合二层聚合口在STP里被视为一个逻辑端口STP只在聚合口层面计算不会对成员口单独计算。这意味着聚合组内的成员口不会因为STP被阻塞这是聚合的一个隐性好处——既增加了带宽又避免了STP阻塞链路。但要注意如果聚合配置有问题导致成员口被踢出聚合组那个被踢出的口会重新参与STP计算可能引起拓扑震荡。所以聚合的稳定性直接影响STP的稳定性配置要仔细。6.3 生产环境配置清单如果要把这套配置用到实际环境我建议按这个清单逐项确认成员口速率、双工、MTU一致两端LACP模式至少一端active成员口配置Trunk、允许VLAN完全一致负载分担算法匹配流量特征LACP超时时间根据切换要求设置聚合组编号两端可以不同但成员口对应关系要清楚配置保存避免重启后丢失还有一点生产环境改聚合配置尽量在业务低谷期做因为调整过程中可能短暂断网。模拟器里随便折腾真机上要谨慎。6.4 模拟器实验的局限与补充最后说句实在话模拟器再方便也有它的局限。模拟器的流量是软件模拟的负载分担效果和真机有差异模拟器对某些硬件特性支持不全比如某些平台的硬件哈希算法模拟器的故障切换时间和真机也不完全一致。所以模拟器里跑通了只能说明配置逻辑没问题真机部署前最好还是在测试环境验证一遍。特别是负载分担和故障切换这两个点真机上的表现才是最终依据。我个人在做这类实验的时候习惯把每一步的验证命令和输出都记下来形成自己的排查手册。下次遇到类似问题直接对照手册查比从头分析快得多。链路聚合这个技术本身不复杂但细节多坑也多多练几遍把状态变化摸熟了后面遇到问题基本看一眼状态就知道卡在哪。