链路聚合原理与华为交换机Eth-Trunk配置实战

做网络这些年我碰到最多的一个看起来简单但总有人栽跟头的需求就是链路聚合。平时不显山不露水等交换机上联口流量冲到90%、监控面板一片红色告警的时候很多人第一反应是换万兆板卡或者再拉一根光纤把两个口手工绑一块儿。可现实是两根网线直接插在两台交换机之间STP会立刻把其中一条Block掉带宽一点都没多出来还给自己埋了个拓扑怎么变了的坑。真正该做的是让两条甚至多条物理链路在逻辑上捆成一个接口转发时把它们当成一个口来用故障时互相接管——这就是链路聚合Link Aggregation。华为交换机上叫Eth-TrunkCisco里叫EtherChannelLinux服务器网卡绑定里叫BondingIEEE的标准编号是802.3ad/802.1AX。这篇文章会从原理讲清楚它到底怎么工作再重点讲华为交换机上的配置过程、调试命令和验收入门最后把我在现网碰到的几个坑摊开来说。适合正好要配核心/汇聚上联、做服务器双网卡冗余或者想把聚合链路彻底搞明白再动手的同行。1. 先说清楚链路聚合到底解决什么问题1.1 带宽翻倍只是表面收益真正值钱的是冗余和拓扑简化链路聚合最直白的收益确实是带宽两条千兆口聚合理想情况下能承载接近2000M的并发流量四条就是4000M前提是流量能被哈希算法相对均匀地撒到每个成员口上。但这里要先把一个概念钉死聚合不会让单条业务流超过单个物理口的速率。它压平的是多条会话并发时整体带宽被一根链路卡住的瓶颈而不是单条TCP流能跑到两根线的速度。不过做过生产网络的人都知道真正让链路聚合不可替代的不是带宽而是故障切换。一条成员链路断了——光模块失效、光纤被踩断、对端端口down——聚合口感知后会把原本要发往该口的流量重新哈希到剩余成员口上这个切换过程对终端设备基本无感。你正在跑的数据库备份、视频会议、虚拟机迁移流量不会因为一根线断掉就整条链路中断。这种冗余还有一个容易被忽略的价值它把多条物理链路抽象成了一个逻辑拓扑。STP、路由协议、MAC地址表在看Eth-Trunk这个逻辑口的时候都把它当成一个接口来对待。原本两台交换机之间插两根线STP要花时间收敛、要Block一条、还要担心根桥变化做了聚合之后两根线是一个逻辑口逻辑上没有环STP自然用不着Block任何一条。这才是聚合真正优雅的地方你获得了多条链路的吞吐和冗余代价只是多配一个接口反而把原来复杂的拓扑收敛问题消掉了。1.2 和多链路负载均衡划清界限很多刚入行的朋友容易把链路聚合和多链路负载均衡当成一码事其实技术边界很清楚。如果两台交换机之间直接连了两根线、不做任何聚合STP会Block一条剩下一条转发多余那条只是备用。有些方案会想用策略路由或者流量镜像去分摊两条物理链路但那既不标准也不可靠STP在拓扑变化时还会重新收敛流量路径跳来跳去排查问题的时候头都要大。链路聚合的标准做法是成员口只是物理实体真正的端口类型、VLAN、三层地址全部落在Eth-Trunk逻辑口上。转发的时候交换机根据报文里的头部字段算出一个哈希值再根据哈希值决定从哪个成员口出去整个过程对协议栈和业务完全透明。所以判断我该不该用聚合我有个很实用的标尺如果两台设备之间需要多条物理链路同时工作又不想引入环路、不想让STP天天参与计算就上聚合。如果你只是想让某一条业务流跑得更快聚合解决不了得靠多流并发或者直接升级链路速率。认清这个边界后面配置才不会用错方向。2. 聚合口内部是怎么工作的分发、保序与哈希2.1 一个Eth-Trunk口背后的多成员口调度先建立一个最小模型。假设在一台接入交换机上创建了Eth-Trunk 1往里面塞了GE0/0/1到GE0/0/4四个口。对系统来说这四根物理线被抽象成一个逻辑管道。帧从内部业务比如VLANIF网关转发送到Eth-Trunk 1时交换芯片要做一个决定把它交给GE0/0/1还是GE0/0/2还是其他哪个口出去。这个决定不是随机做的而是根据报文头部特征算出一个哈希值再拿哈希值去映射成员口。核心诉求有两个**同一会话必须永远走同一个成员口。**TCP要保证顺序如果同一个连接的前后报文从不同物理口出去在网络里就可能走了不同的转发路径到达对端时乱序结果就是TCP疯狂重传、吞吐率暴跌。哈希算法保证了相同特征报文 → 相同哈希值 → 相同成员口从根上避免同一会话被拆散。**不同会话尽量均匀散布到不同成员口。**要让整体带宽被充分利用就得让会话在成员口之间尽量雨露均沾。这就需要哈希因子选得对让不同会话的哈希值尽可能分散在整个映射空间里。华为交换机的实现里Eth-Trunk有一个内部成员编号参与哈希计算这个编号相当于给每个成员口在哈希表里固定了一个位置。同一个Eth-Trunk内部成员口ID越靠前占据的哈希索引区间越靠前不同Eth-Trunk之间还会加入Eth-Trunk自己的接口索引避免多个Trunk的流量在全局哈希上重叠出新的不均匀。2.2 哈希因子怎么选负载才分得匀哈希因子是可配置的。华为交换机上常见的负载分担模式有这几档按源MACsrc-mac按目的MACdst-mac按源目的MACsrc-dst-mac按源IPsrc-ip按目的IPdst-ip按源目的IPsrc-dst-ip按源目的IP四层端口src-dst-ip-port选哪一个取决于网络里会话的粒度。如果终端产生的流量主要是一堆PC访问一台服务器源MAC和源IP都很分散用src-mac或src-ip效果都还行如果是服务器之间的东西向流量客户端相对固定而目的端是多台服务器那要选dst-mac或dst-ip让目的地址分散到哈希空间里如果设备部署在NAT边界或者充当网关进出方向的源/目的地址经常被转换那就得上四层端口参与src-dst-ip-port是最细粒度的选择代价是交换芯片计算量大一点对绝大多数交换机来说性能不是问题。我个人的经验是接入/汇聚场景直接用src-dst-mac就行因为二层转发时报文的三层头还没到芯片重点关注的阶段核心/网关设备建议换成src-dst-ip或src-dst-ip-port粒度细不容易出现一个大流量目的IP独占一个成员口的尴尬。华为很多框式交换机还支持本地优先转发之类的特性跨板卡场景下能减少跨板带宽占用配置前查一下型号支持情况。注意负载不均衡不一定是配错了。单条TCP流比如用iPerf打流测试打满一个口、其他口空着这在哈希逻辑上是正常的。要验证聚合带宽得同时发起多条并发流才能看到多个成员口都被摊到。2.3 顺序一致性为什么同一个会话不能劈腿前面提到同流同径这句话的真正含义比表面更深。哈希能保证同一会话尽量走同一成员口可如果会话数量少或者会话特征在哈希空间里恰好重叠——比如大量流量的源IP和目的IP完全相同——确实会有多个会话被分到同一个成员口。这不是错误是哈希的统计学本质只要需求是保序优先就不可能做到逐包轮询那样绝对均匀。顺带说一个底层细节顺序一致性不仅影响TCP。QoS队列、链路层重传、甚至某些应用层的状态检测防火墙都默认同一条流的报文按序到达。如果交换芯片为了追求完美负载均衡而做逐包分发接收端因为乱序丢包重传反而会把真正有效的吞吐拉低。这也是为什么所有正经交换机厂商在聚合实现上都选基于流的哈希而不是基于包的轮询。还有一种特殊情况值得留意聚合口下如果接了无线AC或者其他会做会话绑定的设备哈希因子选不好可能导致某些AP的CAPWAP隧道流量全部挤在同一条物理链路上。这种场景要用会话数最分散的哈希模式并且先做流量模型预估别指望四根链路一定分摊到每条50%。不同厂商的哈希算法细节有差异不存在一个放之四海而皆准的最佳因子现场调的时候记得多打几路并发流实测。3. 静态聚合与LACP动态聚合到底怎么选3.1 手动聚合模式简单直接但两端一致得自己盯着华为交换机上Eth-Trunk默认的聚合模式一般是手动负载分担mode manual load-balance。这种模式下本端设备只要把几个物理口加入Eth-Trunk就认为它们是一个逻辑口不需要和对端协商也不发任何聚合协议报文。手动模式的好处是简单、兼容性好对端设备只要也能配置手工聚合两边约好就行。很多老旧设备、网络打印机、部分存储设备的以太网口支持的就是这种手工绑组。坏处也明显对端端口状态完全靠人工保证。如果对端有一根线没插、端口被shutdown、或者对端根本没配置聚合本端感知不到依然会把报文往那个成员口分发丢包丢得莫名其妙。如果对端端口是通的但对端交换机没有把对应成员口加进聚合口就可能出现MAC漂移、广播环路之类的诡异现象。所以手动模式只建议在对端设备不支持LACP或者网络规模很小、链路拓扑长期不变的场景用。比如某些摄像头NVR的绑定口、老款防火墙的双WAN口它们就只认手工聚合。其余场景能用LACP就用LACP省心得多。对比项手动负载分担模式LACP模式协商机制无协议协商两端手工保证一致通过LACPDU自动协商故障感知本端只能感知本端物理口状态双方都可通过LACPDU感知对端状态成员口失效处理靠本端物理口状态对端无感知协商失败端口自动转为Unselected适用场景对端不支持LACP、设备老旧、链路长期固定核心/汇聚、服务器双网卡、需要快速切换的生产网络华为配置命令mode manual load-balancemode lacp-static3.2 LACP的握手机制和关键参数LACP就是IEEE 802.3ad/802.1AX定义的链路聚合控制协议。启用LACP后设备会周期性地在成员口上发送LACPDU报文报文里携带自己的系统优先级System Priority、系统MAC、端口优先级Port Priority、端口号、操作Key等信息。对端收到LACPDU后根据这些信息判断哪些端口能凑成一条聚合链路这个过程叫协商。协商通过的口进入Selected状态可以转发数据不满足条件的口处于Unselected状态只监听LACPDU不发数据。华为设备上还常看到一个Standby备用状态对应max active-linknumber配置产生的超额成员口。协商状态的机理由LACP状态机控制底层还有Detached、Waiting、Collecting、Distributing等状态切换日常排障不需要记那么细但看到Selected/Unselected/Standby一定要能分清。LACP的关键参数有三个配置时必须理解系统优先级全局参数默认32768数值越小优先级越高。两端都启LACP时系统优先级更高的一端掌握选谁当活动链路的话语权。常用于双设备对接时让主设备优先确定活动口避免两端各执一词。端口优先级成员口上的参数默认也是32768数值越小越优先。当活动链路数超过上限时优先级低的口会被踢到Standby备用状态。LACP超时时间分Fast1秒发送间隔重传3次和Slow30秒发送间隔。快速超时能让故障感知大约在3秒内完成对业务影响很小慢速超时控制报文开销少但故障切换要等几十秒这在生产环境通常不可接受。所以核心/汇聚之间建议用Fast服务器双网卡绑定也最好配合Fast。3.3 主备场景下的活动链路上限设计LACP模式还支持max active-linknumber。我可以把八个口都加入Eth-Trunk 1但只让其中四个作为活动口转发剩下四个作为备用链路待命。当某个活动口故障时系统会按端口优先级挑一个备用口顶上。这个特性非常实用。华为交换机堆叠iStack/CSS之后跨设备之间做Eth-Trunk上行到两层核心用max active-linknumber把主框的两个口设为高优先级做活动链路主框出问题的时候备用口自动顶上业务切换会很平滑。LACP还有一个lacp preempt enable开启后恢复的高优先级口会重新抢占活动状态不开启的话即使原来那个口恢复了也要等当前活动口故障才切换过去。这更适合追求稳定优先、不折腾的网络设备。4. 华为交换机上从建Trunk到业务放行的配置过程4.1 配置前的端口清理与VLAN梳理很多用户配置失败不是因为命令不会打而是没做配置前的资源梳理。动手前我建议先做四件检查物理端口是否被占用执行display current-configuration interface GigabitEthernet0/0/1确认端口上没有独立的VLAN配置、没有绑定其他业务。端口状态是否正常执行display interface brief确认端口都是Up速率、双工一致。VLAN规划是否清晰聚合口要放行哪些VLAN两侧交换机要完全一致。对端设备是否具备聚合能力对端是另一台交换机要确认它对Eth-Trunk模式的兼容性对端是服务器要确认网卡Teaming支持LACP还是静态绑定。把这些信息列成一张表再动手比配到一半回去查配置快得多。最忌讳的就是端口上还跑着业务你这边直接把它塞进Eth-Trunk那边流量就断了。4.2 创建Eth-Trunk、选定模式、加入成员口的完整命令以两台华为S系列交换机互连为例目标是让GE0/0/1到GE0/0/4四条口聚合作为Trunk口放行VLAN 10、20、30。下面是LACP模式推荐的完整配置流程system-view sysname SW-A # 全局设置系统优先级数值越低优先级越高可选默认32768 lacp system-priority 100 interface Eth-Trunk 1 mode lacp-static max active-linknumber 4 load-balance src-dst-ip port link-type trunk port trunk allow-pass vlan 10 20 30 q接下来把成员口加进聚合口有两种方式# 方式一直接在Eth-Trunk视图下批量加入 interface Eth-Trunk 1 trunkport GigabitEthernet0/0/1 to 0/0/4 q # 方式二逐个在物理口视图下指定归属 interface GigabitEthernet0/0/1 eth-trunk 1 q interface GigabitEthernet0/0/2 eth-trunk 1 q方式一更省事但如果你希望对不同成员口设置不同的LACP端口优先级就必须用方式二逐个进物理口设置。比如interface GigabitEthernet0/0/1 eth-trunk 1 lacp port-priority 100 q interface GigabitEthernet0/0/2 eth-trunk 1 lacp port-priority 200 q对端SW-B也要做几乎一样的配置模式、放行VLAN、成员口数量保持一致。两台都配完后在SW-A上执行display eth-trunk 1能看到成员口处于Selected状态Eth-Trunk变成Up这条聚合链路就算建起来了。如果是手动聚合模式把命令mode lacp-static换成mode manual load-balance就行其余配置一样。注意手动模式没有LACPDU协商对端也必须是手动模式一端手动、一端LACP聚合口是起不来的。4.3 三层聚合口与服务器对接的补充姿势上面是典型二层Trunk场景。如果两台设备之间要做三层互联或者做网关冗余可以直接给Eth-Trunk配IPinterface Eth-Trunk 1 mode lacp-static ip address 10.0.10.1 255.255.255.252 q三层聚合在华为VRRP/堆叠双活网关场景下非常常见两台核心各出一条Eth-Trunk接到下层下层再做同样的聚合形成无环又双活的南北向链路。这里有个细节只要进了Eth-Trunk物理口上的独立配置就会失效端口类型、VLAN列表、IP地址都必须配置在Eth-Trunk逻辑口上别跟在物理口后面补一堆命令白忙活。如果对端是Linux服务器网卡绑定模式得跟交换机对齐。服务器上bond mode 4802.3ad对应交换机的LACP模式mode 0balance-rr是逐包轮询跟交换机的Eth-Trunk哈希语义不同不建议直接对接。Windows服务器的NIC Teaming里Static Teaming对应手动聚合Dynamic Teaming对应LACP。只要模式不对称服务器侧可能显示链路Up但数据不通这个坑在虚拟化环境特别常见。4.4 跨框/堆叠场景下的Eth-Trunk配置提示聚合还有一个很多人都忽略的价值它天然适合堆叠系统。华为的iStack/CSS把多台设备虚拟化成一台后Eth-Trunk的成员口可以分散在不同物理框上。假设SW-A和SW-B做了堆叠Eth-Trunk 1的成员口一部分在A框、一部分在B框对端再做同样的跨设备聚合就组成了跨设备链路聚合。这种场景配置上没啥特别之处——堆叠系统里所有框的接口统一编址为XGE1/0/1、XGE2/0/1这样的全局接口直接trunkport XGE1/0/1 to XGE2/0/4就行。但它带来一个关键价值单框故障时另一框上的成员口仍然能转发聚合链路不会整条中断。很多双核心方案里跨设备聚合的意义就在这——从链路冗余升级到了设备冗余。如果两台设备不做堆叠又想实现类似效果就得用M-LAG这种多框链路聚合技术原理上还是LACP但实现细节更复杂配置前要找对应型号的版本手册确认支持情况。5. 配置完成后的验证与真实踩坑经历5.1 display命令怎么读出有效信息配置完不等于配置对验证环节不能省。最常用的命令就是display eth-trunk 1输出里最重要的几栏是Port、Status、Priority。Status是Selected说明该成员口正常参与转发Status是Unselected表示协商没成功如果你配了max active-linknumber多出来的成员口状态会是Standby这是正常现象不是故障。SW-A display eth-trunk 1 Eth-Trunk1s state information: WorkingMode: LACP Hash arithmetic: According to SIP-XOR-DIP LACP MUX Enable: Yes System Priority: 100 System ID: 0018-8201-0001 Least Active-linknumber: 1 Max Active-linknumber: 4 Operate Status: up Number Of Active Ports: 4 ... Port Status Priority Key GE0/0/1 Selected 100 1 GE0/0/2 Selected 100 1 GE0/0/3 Selected 200 1 GE0/0/4 Selected 200 1再看负载分担是否生效可以执行display load-balance eth-trunk 1部分版本命令是display eth-trunk 1 load-balance确认当前哈希算法是你设的那个别配完发现芯片默认跑的还是src-mac。然后做数据面验证。终端ping通对端网关只代表基本连通要验证多链路分摊建议用iPerf或者多台终端并发跑大流量再到交换机上看display interface Eth-Trunk 1的总流量速率和各成员口的速率。理想情况是几个成员口都有流量而不是全部压在一个口上。5.2 掉线切换实测拔掉一根成员口会发生什么聚合最核心的卖点是冗余所以上线前我认为必须做一次破坏性测试跑着业务流量时随机拔掉一根成员口的光纤或光模块观察业务是否中断、切换耗时多少。LACP快速超时模式下故障感知一般在3秒左右加上哈希重分布的时间业务基本无感顶多TCP出现少量重传。如果你做测试时拔线后业务断了好几十秒先别急着怀疑聚合没生效——先看LACP超时时间是不是默认的Slow再看对端服务器网卡绑定有没有开启快速故障检测。测试完记得把线插回去观察插回状态。插回后如果是手动模式链路恢复立即生效LACP模式下如果没开lacp preempt enable恢复的成员口要等状态机重新协商过程中业务不会断只是这个口暂时不参与转发看到成员口还是Standby也不用慌等协商周期走完再看一眼。5.3 我在现网踩过的坑和排查清单坑一模式不一致Eth-Trunk起不来。有一次现场物理链路全通但聚合口显示Down。两端比对半天发现一边交换机版本默认Eth-Trunk模式是manual另一边被人改成了lacp-static协商自然失败。把模式改成一致后秒起。从此我养成了习惯凡是聚合相关第一件事先两端各执行一次display eth-trunk 1看WorkingMode。坑二只把成员口配成Trunk忘了在Eth-Trunk上放VLAN。新同事第一次配先挨个把四个物理口配了port link-type trunk、port trunk allow-pass vlan all再建Eth-Trunk加成员口。结果流量不通。原因很简单物理口一旦加入Eth-Trunk物理口上的独立配置全部失效端口类型、VLAN列表必须配置在Eth-Trunk口上。这也是判断你把Eth-Trunk用对了没有的试金石。坑三以为带宽翻倍就是任意单流翻倍。客户投诉你们聚合后网速没变我用iPerf单线程测试发现确实只有一条链路在跑。跟客户解释清楚后改成并发16线程打流四个成员口全动起来了带宽接近4倍。最关键的就是这个认知聚合提升的是多会话并发总带宽不是单会话速率单条TCP流的带宽上限依然是单物理口速率。坑四堆叠场景下LACP优先级没规划好。跨设备聚合时默认端口优先级全是32768设备挂掉后备用口顶上没有任何问题但如果你希望主框的口永远优先转发就必须给主框成员口设更小的端口优先级并开启lacp preempt。否则正常情况下流量会随意分布在哪框的口上跨框转发带宽占用高不说故障恢复后的路径也不可控。坑五服务器网卡Teaming模式跟交换机对不上。虚拟化集群扩容时新服务器网卡绑定用了Dynamic Teaming交换机这端却是手动聚合两边都显示Up但流量一上来就丢包。把交换机改为LACP模式后恢复。服务器侧LACP跟交换机侧LACP才是门当户对静态绑定只能对应手动聚合。最后整理一个排查清单现场遇到问题照着查比瞎猜快现象可能原因排查思路Eth-Trunk整体Down两端模式不一致两端各自display eth-trunk看WorkingMode成员口状态Unselected速率/双工不一致、LACP协商失败查接口物理状态两端速率双工必须一致链路Up但业务不通VLAN放行列表不一致比对两端port trunk allow-pass流量集中在单个成员口哈希因子粒度不够调整load-balance模式多路并发测试拔线后业务中断几十秒LACP慢超时或对端未开快速检测检查lacp timeout配置服务器侧开启快速故障检测插回线后链路不恢复转发未开启lacp preempt按需开启抢占或手动shutdown/undo shutdown链路聚合是一门配通容易、用好难的技术。大多数人在现场卡住的点往往不是命令记不住而是没弄清我到底想让这条聚合链路完成什么——是要带宽的多进多出还是要冗余的故障切换或者两者都要。把这个想清楚模式怎么选、哈希因子怎么调、活动链路上限定多少、要不要开抢占答案自然就出来了。我自己每次动核心链路的聚合配置之前一定会把接口拓扑图画一遍标清哪根线接哪台设备的哪个口再对着图清空原有端口配置、重新建Trunk。这个习惯帮我避掉过好几次拔错了线的险情。如果你也正在调聚合建议先做一次破坏性测试别等到业务高峰期才第一次验证故障切换。