1. 链路聚合到底解决了什么现实问题很多刚接触网络设备的朋友会有个疑问明明已经买了千兆交换机为什么还要折腾什么链路聚合一根网线不够用吗这个问题问得好因为链路聚合Eth-Trunk诞生的初衷就是为了解决单根物理链路带来的带宽瓶颈和单点故障问题。先说说带宽瓶颈。假设你有一台接入层交换机和一台核心交换机中间只连了一根千兆网线。平时办公流量跑跑没问题但一到下午集中备份数据、或者某个部门集中上传大文件的时候这根千兆线瞬间就被跑满了。用户端感受到的就是卡顿、丢包、访问慢。这时候你可能会想我再加一根网线不就行了问题来了如果直接加一根网线生成树协议STP会立刻把其中一条链路阻塞掉因为STP认为两条链路形成了环路。结果就是你物理上插了两根线逻辑上只有一根在工作另一根纯属摆设。链路聚合就是来解决这个尴尬的。它把多条物理链路捆绑成一条逻辑链路对上层业务来说看到的就是一条带宽翻倍的“大管子”。比如把4条千兆链路聚合在一起逻辑上就变成了一条4Gbps的链路。而且STP也不会再阻塞其中任何一条成员链路因为聚合后的逻辑接口在STP看来就是一个整体。再说单点故障。单根网线一旦被老鼠咬断、或者水晶头老化接触不良整个网络就断了。有了链路聚合只要还有一条成员链路活着逻辑链路就不会断业务几乎无感知。这就是链路聚合的第二个核心价值链路冗余。所以链路聚合的本质就是两件事带宽叠加和链路冗余。它不解决路由问题不解决VLAN划分问题它专注的就是把多条物理线缆“拧成一股绳”让它们协同工作。这个技术在实际项目中应用极其广泛服务器与交换机之间的连接、核心与汇聚之间的互联、甚至数据中心里叶脊架构的下行链路到处都有它的身影。注意链路聚合不是“插上线就自动生效”的。它需要两端设备都做配置而且配置必须匹配否则聚合可能起不来甚至引发广播风暴。这是新手最容易踩的坑。2. Eth-Trunk的手工模式与LACP模式到底怎么选华为设备上把链路聚合叫做Eth-Trunk它支持两种工作模式手工负载分担模式和LACP模式。很多人配的时候随手选一个结果发现效果不对又回头来查原因。其实这两种模式的适用场景差别很大选错了轻则聚合不生效重则网络出环。2.1 手工负载分担模式简单粗暴但可控性差手工模式顾名思义就是完全靠管理员手动指定哪些接口加入Eth-Trunk。设备之间没有任何协商报文你配了它就认为对端也配了。这种模式的好处是配置简单不依赖对端设备是否支持LACP。坏处也很明显如果一端配了、另一端没配或者两端成员接口数量不一致就可能出现流量黑洞或者环路。手工模式适合什么场景我个人的经验是当对端设备是不支持LACP的旧设备、或者某些服务器网卡做bonding时只支持静态聚合这时候手工模式就是唯一选择。另外在一些临时测试环境里手工模式配起来快不用等协商。但手工模式有一个致命问题它无法检测链路层的故障。比如中间加了一台传输设备物理层是up的但实际数据转发已经断了手工模式是感知不到的。这时候流量还是会往这条“假活”的链路上发导致丢包。2.2 LACP模式带协商的智能聚合LACP全称是链路聚合控制协议它通过LACPDU报文和对端设备协商。协商的内容包括哪些接口可以加入聚合组、哪些接口是活跃的、哪些是备用的。LACP模式最大的好处是自动故障检测和成员接口状态协商。举个例子你配了4条链路做LACP聚合但实际只有3条需要转发流量第4条可以作为备份。当其中一条活跃链路故障时LACP会自动把备用链路切换成活跃状态整个过程对业务透明。这种灵活性是手工模式不具备的。LACP还有两种活动模式主动模式和被动模式。主动模式会主动发送LACPDU被动模式只有收到对端的LACPDU才回应。一般建议至少一端配成主动模式否则两端都被动谁也不发报文协商就起不来。对比项手工负载分担模式LACP模式协商机制无有LACPDU协商故障检测依赖物理层可检测链路层故障成员接口管理全部活跃支持活跃/备份配置复杂度低中等适用场景旧设备、服务器bonding交换机之间互联2.3 选型建议别为了省事选手工我的建议很明确只要两端设备都支持LACP就优先用LACP模式。多花两分钟配置换来的是更可靠的故障切换和更清晰的链路状态。手工模式只在确实不支持LACP的情况下才用。而且即便是手工模式也一定要确保两端配置完全对称包括成员接口数量、接口类型、速率等。还有一个细节Eth-Trunk的成员接口必须具有相同的属性包括接口类型、速率、双工模式、流控配置等。如果混插了千兆和百兆接口或者全双工和半双工混用聚合可能起不来。这个在ENSP模拟器里可能不明显但在真机上一定会报错。3. 在华为ENSP里从零搭一个Eth-Trunk实验理论说再多不如动手配一遍。华为ENSP模拟器是学习网络技术非常好的工具下面我带你从零搭一个链路聚合的实验环境。这个实验的目标是两台交换机通过三条链路互联配置LACP模式的Eth-Trunk验证带宽叠加和故障切换效果。3.1 实验拓扑搭建与接口规划打开ENSP拖出两台S5700交换机分别命名为SW1和SW2。再拖出两台PCPC1连接SW1PC2连接SW2。SW1和SW2之间用三条线连接分别接在G0/0/1、G0/0/2、G0/0/3接口上。接口规划如下SW1G0/0/1、G0/0/2、G0/0/3 加入Eth-Trunk 1SW2G0/0/1、G0/0/2、G0/0/3 加入Eth-Trunk 1PC1IP 192.168.1.1/24网关 192.168.1.254PC2IP 192.168.1.2/24网关 192.168.1.254SW1的VLANIF 1接口IP192.168.1.254/24这里为了简化我们用VLAN 1作为管理VLAN实际项目中建议单独划分一个管理VLAN。PC的网关配在SW1上SW2作为二层透传。提示ENSP里S5700默认的接口是百兆还是千兆取决于你选的型号。如果发现接口速率不对可以在接口视图下用negotiation auto命令调整。不过ENSP里一般不用太纠结这个真机上才需要严格匹配。3.2 手工模式配置步骤与验证先看手工模式怎么配。在SW1上执行以下命令SW1 system-view [SW1] interface Eth-Trunk 1 [SW1-Eth-Trunk1] mode manual load-balance [SW1-Eth-Trunk1] trunkport GigabitEthernet 0/0/1 to 0/0/3 [SW1-Eth-Trunk1] port link-type trunk [SW1-Eth-Trunk1] port trunk allow-pass vlan 1 [SW1-Eth-Trunk1] quitSW2上做对称配置SW2 system-view [SW2] interface Eth-Trunk 1 [SW2-Eth-Trunk1] mode manual load-balance [SW2-Eth-Trunk1] trunkport GigabitEthernet 0/0/1 to 0/0/3 [SW2-Eth-Trunk1] port link-type trunk [SW2-Eth-Trunk1] port trunk allow-pass vlan 1 [SW2-Eth-Trunk1] quit配完之后用display eth-trunk 1查看状态。如果看到成员接口状态都是Up而且WorkingMode显示为Manual说明聚合成功了。这时候你可以把其中一条线拔掉在ENSP里右键接口选择断开再ping一下应该不会断流。但手工模式有个问题如果你只在一端配了Eth-Trunk另一端没配ENSP里可能不会立刻报错但实际流量会出问题。所以配完之后一定要两端都检查。3.3 LACP模式配置与活动接口选举LACP模式的配置稍微复杂一点但更值得掌握。在SW1上SW1 system-view [SW1] interface Eth-Trunk 1 [SW1-Eth-Trunk1] mode lacp-static [SW1-Eth-Trunk1] trunkport GigabitEthernet 0/0/1 to 0/0/3 [SW1-Eth-Trunk1] port link-type trunk [SW1-Eth-Trunk1] port trunk allow-pass vlan 1 [SW1-Eth-Trunk1] max active-linknumber 2 [SW1-Eth-Trunk1] quit这里我特意加了一条max active-linknumber 2意思是最多只有2条链路处于活跃状态第3条作为备份。这样做的目的是为了演示LACP的备份切换功能。如果不配这条默认所有成员接口都是活跃的。SW2上做对称配置但LACP的活动模式可以只在一端配主动SW2 system-view [SW2] interface Eth-Trunk 1 [SW2-Eth-Trunk1] mode lacp-static [SW2-Eth-Trunk1] trunkport GigabitEthernet 0/0/1 to 0/0/3 [SW2-Eth-Trunk1] port link-type trunk [SW2-Eth-Trunk1] port trunk allow-pass vlan 1 [SW2-Eth-Trunk1] max active-linknumber 2 [SW2-Eth-Trunk1] quit配完之后用display eth-trunk 1查看。你会看到类似这样的输出Eth-Trunk1s state information is: WorkingMode: LACP Preempt: NO Hash arithmetic: According to SIP-XOR-DIP Least Active-linknumber: 1 Max Active-linknumber: 2 ActorPortName Status PortType PortPri PortNo GigabitEthernet0/0/1 Selected 1GE 32768 1 GigabitEthernet0/0/2 Selected 1GE 32768 2 GigabitEthernet0/0/3 Unselect 1GE 32768 3注意看Status那一列前两个是Selected第三个是Unselect。这就是LACP的活动接口选举结果。选举依据是接口优先级和接口编号优先级越小越优先优先级相同则接口编号越小越优先。你可以通过lacp priority命令修改接口优先级来影响选举结果。3.4 验证流量分担与故障切换配置完成后怎么验证流量确实分担了呢在ENSP里可以用display interface eth-trunk 1查看流量统计。但更直观的方法是在PC1上持续ping PC2然后在SW1上断开一条活跃链路观察ping是否中断。如果配的是LACP模式且max active-linknumber为2断开一条活跃链路后备份链路会自动变成活跃状态ping应该只丢一两个包甚至不丢包。如果配的是手工模式断开一条链路后流量会自动切换到剩余链路但切换速度取决于物理层检测速度可能会丢几个包。这里有个小技巧在ENSP里模拟链路故障可以右键接口选择“断开”而不是直接删除线缆。删除线缆有时候ENSP的模拟不够真实断开接口更接近真机上的shutdown操作。注意LACP的故障切换速度受LACPDU超时时间影响。默认情况下LACPDU的超时时间是90秒慢速报文。如果希望更快切换可以配置lacp timeout fast把超时时间缩短到3秒。但快速报文会增加CPU负担一般只在核心链路使用。4. 负载分担算法流量到底走哪条线链路聚合配好了带宽也叠加了但流量到底是怎么分配到各条成员链路上的这个问题很多人没搞明白导致实际使用中发现“带宽没叠加”或者“一条线跑满、其他线闲着”。这就要说到负载分担算法了。4.1 华为Eth-Trunk支持的负载分担模式华为设备支持多种负载分担模式可以通过load-balance命令配置。常见的模式包括src-ip根据源IP地址做哈希dst-ip根据目的IP地址做哈希src-dst-ip根据源IP和目的IP组合做哈希src-mac根据源MAC地址做哈希dst-mac根据目的MAC地址做哈希src-dst-mac根据源MAC和目的MAC组合做哈希src-dst-ip-sport-dport根据源IP、目的IP、源端口、目的端口做哈希默认情况下华为S5700的Eth-Trunk负载分担模式是src-dst-ip。这个模式在大多数场景下够用但在某些特定场景下可能不够均匀。4.2 哈希算法的本质为什么有时不均匀负载分担的核心是哈希算法。设备把报文的某些字段提取出来经过哈希计算得到一个数值然后根据这个数值选择一条成员链路。哈希算法的特点是相同的输入一定得到相同的输出但不同的输入可能得到相同的输出哈希冲突。这就解释了为什么有时候流量不均匀。假设你有一个服务器到存储的备份流量源IP和目的IP都是固定的只有端口号在变。如果你用的负载分担模式是src-dst-ip那么所有报文的哈希输入都一样结果就是所有流量都走同一条链路其他链路完全空闲。这时候你就需要改成src-dst-ip-sport-dport把端口号也纳入哈希计算流量就能分散开了。再举个例子如果网络里主要是PC访问互联网的流量源IP是变化的目的IP也是变化的那么src-dst-ip模式就能很好地分担。但如果所有PC都访问同一个服务器目的IP固定源IP变化那么src-ip模式就足够了。负载分担模式适用场景注意事项src-ip源IP变化、目的IP固定服务器集群访问同一目标dst-ip目的IP变化、源IP固定单台服务器访问多个目标src-dst-ip源和目的都变化通用场景默认推荐src-dst-ip-sport-dport端口号变化丰富服务器备份、存储流量src-dst-mac二层转发为主接入层到汇聚层4.3 实际项目中如何选择负载分担模式我的经验是不要一上来就改默认配置。先用默认的src-dst-ip跑一段时间观察各成员链路的流量统计。如果发现流量严重不均再根据业务特征调整。查看各成员链路流量的命令是display interface brief或者display eth-trunk 1 verbose。在真机上你可以看到每个成员接口的入向和出向速率。如果发现某条链路长期跑满其他链路利用率很低那就说明负载分担模式需要调整。还有一个容易被忽略的点负载分担是逐流的不是逐包的。也就是说同一条TCP流的所有报文会走同一条成员链路。这样做是为了避免报文乱序。如果逐包分担同一个TCP流的报文可能走不同的链路到达对端的时间不同导致乱序TCP性能反而下降。所以即使负载分担算法很完美单条TCP流的带宽上限还是一条成员链路的带宽。如果你需要单条流突破这个限制那就不是链路聚合能解决的了需要考虑更上层的方案。提示在ENSP里查看流量统计可能不太直观因为模拟器的流量本身就不大。建议在真机上做这个验证或者用打流工具在ENSP里生成大流量。不过ENSP的打流工具功能有限真机验证更靠谱。5. 那些年我踩过的Eth-Trunk坑配置链路聚合看起来不难但实际项目中出问题的地方往往不在配置本身而在一些细节上。下面分享几个我亲身踩过的坑希望能帮你省点排查时间。5.1 成员接口配置不一致导致聚合起不来这是最常见的问题。Eth-Trunk的成员接口必须具有相同的属性包括接口类型都是电口或都是光口接口速率都是千兆或都是万兆双工模式都是全双工流控配置都开启或都关闭接口的链路类型都是trunk或都是access允许通过的VLAN列表我遇到过一种情况两台交换机之间用三条线互联其中两条是千兆电口一条是千兆光口。配了Eth-Trunk之后光口那条死活加不进去。后来查了半天才发现光口和电口的默认配置有差异需要手动把光口的某些参数调成和电口一致。真机上可以用display interface逐个对比ENSP里报错信息可能不够详细。还有一个更隐蔽的坑接口的STP配置。如果成员接口的STP状态不一致比如一个接口是Forwarding另一个是Discarding聚合也可能出问题。建议在加入Eth-Trunk之前先把成员接口的STP关掉或者确保状态一致。5.2 两端模式不匹配引发的广播风暴这个坑比较严重。有一次在客户现场一端配了LACP另一端配了手工模式。结果两端协商不起来但物理层又是通的。交换机把成员接口当成了独立接口STP没有阻塞任何一条形成了环路。广播报文在环里疯狂转发整个网络瞬间瘫痪。后来复盘发现问题出在配置流程上。正确的做法是先在一端配好Eth-Trunk但先不要加入成员接口然后在另一端配好Eth-Trunk也不要加入成员接口最后两端同时加入成员接口。这样能最大程度避免中间状态出环。如果实在无法同时操作至少要在加入成员接口之前先在成员接口上配置STP边缘端口或者临时关闭STP等聚合起来之后再恢复。不过这只是权宜之计根本的解决办法还是确保两端模式一致。5.3 LACP超时时间与切换速度的权衡前面提到过LACP默认使用慢速报文超时时间90秒。这意味着如果一条活跃链路故障LACP需要90秒才能检测到然后才切换到备用链路。90秒对于很多业务来说太长了用户早就投诉了。改成快速报文后超时时间缩短到3秒切换速度快很多。但快速报文会增加CPU负担因为LACPDU的发送频率从每30秒一次变成每秒一次。在成员接口很多的场景下CPU可能会吃不消。我的建议是核心链路用快速报文接入链路用慢速报文。核心链路对切换速度要求高CPU资源也相对充裕。接入链路数量多用慢速报文减轻CPU压力。另外如果物理层能快速检测到故障比如光模块失光LACP的切换速度其实取决于物理层跟LACP超时时间关系不大。所以光口链路用慢速报文也问题不大电口链路如果中间有传输设备物理层检测慢就需要LACP快速报文来兜底。5.4 ENSP模拟器与真机的差异ENSP是个好工具但它毕竟是模拟器和真机有一些差异。比如ENSP里接口的up/down状态切换是瞬间的真机上可能有几秒的延迟ENSP里LACPDU的收发可能不够真实有时候协商状态显示不对ENSP里不支持某些真机上的高级特性比如Eth-Trunk的静态LACP优先级抢占ENSP里流量统计不准确无法真实反映负载分担效果所以在ENSP里配通了不代表真机上一定没问题。真机上还需要注意接口的实际协商速率、光模块的兼容性、线缆质量等因素。我一般建议在ENSP里把配置逻辑跑通然后到真机上做最终验证。注意真机上配置Eth-Trunk之前建议先保存当前配置。万一配错了导致网络中断可以快速回滚。另外如果是在生产环境操作一定要申请变更窗口不要在业务高峰期做。6. 从单设备聚合到跨设备聚合的演进思路单台设备上的Eth-Trunk解决了链路级冗余但设备本身还是单点。如果SW1整机故障所有链路都断了网络照样瘫痪。这时候就需要跨设备链路聚合也就是华为的M-LAG或者堆叠技术。M-LAG跨设备链路聚合的思路是两台交换机通过Peer-Link互联然后共同和一个下游设备做Eth-Trunk。下游设备看到的是两条链路分别连到两台交换机但它认为这是一条逻辑链路。当其中一台交换机故障时流量自动切换到另一台业务不中断。这个技术比单设备Eth-Trunk复杂得多涉及到Peer-Link配置、双主检测、一致性检查等。但核心思想是一样的把多条物理链路捆绑成一条逻辑链路只不过这次捆绑的链路跨越了两台设备。如果你已经掌握了单设备Eth-Trunk下一步可以研究M-LAG。在实际的数据中心场景里M-LAG的应用非常广泛尤其是服务器双归接入的场景。服务器两块网卡分别连到两台交换机通过M-LAG实现冗余比传统的堆叠方案更灵活升级维护也更方便。不过M-LAG的配置细节很多一致性检查尤其重要。如果两台交换机的配置不一致M-LAG可能起不来或者出现流量黑洞。这个坑比单设备Eth-Trunk更深需要更细致的规划和验证。我在实际项目中的体会是链路聚合这个技术配置本身不难难的是理解它的工作边界和适用场景。它不是万能的不能解决所有带宽和冗余问题。但在它适用的场景里它是最简单、最可靠、最成熟的方案之一。把基础打牢后面学M-LAG、学VXLAN、学SDN都会轻松很多。