Eth-Trunk链路聚合实战:手工负载分担与LACP模式详解

发布时间:2026/10/23 5:34:19
Eth-Trunk链路聚合实战:手工负载分担与LACP模式详解
写这篇的时候我其实挺有感触的。当年刚接触网络工程第一次在项目现场配链路聚合心里还嘀咕着“不就是把几根网线绑一起当一根用嘛”结果被现实狠狠教育了一课。后来系统过了一遍HCIP/HCIE备考体系里Eth-Trunk的考点才发现手工负载分担和LACP这两种模式背后藏着的门道远比“绑网线”三个字复杂。这篇是备考宝典系列的第十三篇我把Eth-Trunk链路聚合知识点从头到尾捋一遍重点放在手工负载分担和LACP这两种实现方式上既照顾考试也照顾真实项目里会踩的坑。正在备考HCIP/HCIE Datacom的朋友或者准备做园区网络改造、数据中心接入扩容的同行这篇都值得花十分钟认真读完。1. 为什么要学Eth-Trunk链路聚合到底解决了什么1.1 带宽不够用的时候别急着换板卡先从一个最朴素的场景说起一台汇聚交换机上联核心单根千兆链路扛不住高峰期流量带宽跑满、丢包率飙升、业务投诉不断。这时候摆在面前的有两条路一是升级万兆板卡和光模块成本高、周期长还得动现网二是在两台设备之间多拉几根线把多条物理链路绑成一个逻辑链路让它看起来像“一根更粗的管子”。后者就是链路聚合华为体系里叫Eth-Trunk。很多人把链路聚合理解成“带宽直接翻倍”这个说法不够严谨。Eth-Trunk的核心价值在于三个层面带宽扩展、链路冗余、负载均衡。带宽扩展不是说流量进来之后被平均切成四份从四条线同时发出去而是流量按照某种哈希规则被分散到不同的成员链路上每条链路上的实际流量相互错开整体吞吐能力逼近四条链路之和。冗余价值在于某一条成员链路故障后流量自动切换到健康链路上业务不中断。负载均衡则是通过哈希算法实现流量的合理分布避免“一条撑死、三条饿死”的局面。理解了这三个核心价值再回头看为什么不用多物理直连替代Eth-Trunk就清晰多了。两条独立的物理链路直连交换机在生成树协议面前会被判定为环路STP会阻塞其中一条冗余效果直接归零。Eth-Trunk把多条物理口抽象成逻辑口后生成树只会看到一个逻辑接口不会阻塞负载分担和冗余备份同时成立这就是Eth-Trunk在园区网、数据中心里成为“标配”的根本原因。1.2 生成树困局的破解思路STP生成树协议的逻辑很简单网络里不允许存在物理环路有环路就阻塞掉冗余路径防止广播风暴和MAC地址漂移。这就产生了一个尴尬我想多做几条上联链路做冗余但STP不答应。Eth-Trunk的设计恰好绕开了这个矛盾——把多条物理链路封装成一个逻辑链路对外只呈现一个接口。STP看到的是单条链路不会触发环路计算而实际上流量在物理层面还是走了多条线。这里有个容易被忽略的细节Eth-Trunk接口本身也是要参与STP计算的。默认情况下接口会开启STP管理员可以先在逻辑接口上执行stp disable或调整STP参数取决于网络设计需求。实际操作中如果两端都是交换机且下联口没有冗余路径很多人会直接在这个接口上关掉STP减少收敛影响但如果是核心层到汇聚层的三角组网逻辑链路上可能还有别的环路风险这时候该开STP还是得开只是Eth-Trunk让STP只看到一个逻辑口而已。1.3 负载均衡的真实含义为什么四条线跑不出四倍速“把四条千兆绑一起下载速度应该到400MB/s吧”这是我见过最多的误解。Eth-Trunk的负载分担方式分为逐流和逐包两种主流模型具体取决于设备和哈希算法配置华为产品默认基本都采用逐流方式。逐流的意思是同一个业务流比如一个TCP连接只会从同一条成员链路上走不会把一条流的报文拆散到多条链路上转发。这么做是为了防止报文乱序——如果同一个TCP流的报文从四条线分别到达对端对端收到报文的顺序就会乱TCP栈要花大功夫重排序性能反而更差。所以Eth-Trunk的“带宽叠加”是有条件的。理想情况下如果网络里有成千上万条不同的流哈希算法能把它们均匀地打散到四条链路上汇聚带宽确实能逼近四倍。但如果跑的是少数几条大流量专线哈希算法怎么分都只能落在有限的几条链路上其他成员链路闲置整体速率就上不去。这一点在项目里非常关键后面第六章我会专门讲怎么排查流量不均的问题。理解了逐流的本质你才会明白为Eth-Trunk选择正确的哈希算法、了解流量模型是比“把线插满”更重要的事。2. 两种核心模式手工负载分担与LACP到底差在哪2.1 手工负载分担简单直接但没有“自我修复”能力手工负载分担Manual Load Balancing华为命令行里也常叫手工模式或静态模式。配置方式非常直观创建Eth-Trunk逻辑接口把物理成员口加进去再选择负载均衡算法完事。所有成员链路都是Active状态只要物理层是Up就会参与流量转发。它的核心特点是不运行任何聚合协商协议两端设备不需要通过协议报文的交互来确认彼此的状态。这个模式最大的优势是兼容性强。对方设备如果是老款交换机或者不是华为体系的设备不支持标准LACP协议用手工模式也能完成链路捆绑。但代价也明摆着没有协议层面的握手和探测设备只能依赖物理层的Up/Down来判断链路是否可用。如果出现“物理层还通着但对端已经收不到数据”这类故障手工模式无法感知流量还继续往这条坏链路上发业务受影响而管理员毫无察觉。这种模式适合网络规模小、链路可靠性要求不高、对端设备无法配合LACP的场景。2.2 LACP模式让两端设备先“握手”再干活LACP的全称是Link Aggregation Control Protocol链路聚合控制协议基于IEEE 802.3ad标准。相比手工模式LACP最大的区别在于成员链路在加入聚合组后需要先通过LACPDULink Aggregation Control Protocol Data Unit链路聚合控制协议数据单元报文进行握手协商确认双方都认可这条链路属于同一个聚合组才能进入转发状态。LACPDU报文里携带了设备的系统优先级、系统MAC、接口优先级、接口号、操作Key等信息。两端的设备通过持续交换报文判断彼此的配置是否匹配匹配的链路被设置为Selected选中状态参与转发不匹配或多余的链路进入Standby备份状态不转发数据。LACP模式下还能设置活动链路数的上限比如四条物理链路参与聚合但只允许两条处于Selected状态剩余两条作为热备份平时闲置一旦活动链路故障就自动顶上。华为配置LACP模式时命令行里写的是mode lacp-static所以有人也习惯叫它“静态LACP”。这里的“静态”指的是两端不需要通过动态学习来建立聚合关系成员口的加入是手工指定的但链路状态是通过LACP协议协商维护的。还有一种“动态LACP”可以配合堆叠、集群等虚拟化技术使用成员口可以动态加入聚合组这种在HCIP里也有涉及不过日常项目里静态LACP已经是绝对主力考试也更爱考这个。2.3 两种模式对比一张表看穿要害考试里很喜欢让考生对比这两种模式我把核心差异整理成一张表对比项手工负载分担静态LACP协商协议不运行LACP协议运行LACP协议交换LACPDU链路状态判断只依赖物理Up/Down通过协议协商确定Selected和Standby故障感知能力弱无法感知逻辑故障强对端异常可快速感知冗余机制全部成员口都转发无备份链路概念可设置活动链路上限多余链路自动备份配置复杂度低略高跨厂商兼容性更好需要对方支持标准LACP适用场景小型网络、对端不支LACP大中型园区网、数据中心、可靠性要求高的场景项目里我做链路聚合只要条件允许优先选LACP。手工模式能用的场景越来越窄主要是LACP带来的故障感知和能力太重要了尤其在上联核心这种关键链路上链路坏没坏不能靠人去机房看灯。3. 手工负载分担模式配置三步走但细节全在“一致性”3.1 最基础的配置模板与成员口一致性手工负载分担的配置本质上是三段式操作。第一段创建Eth-Trunk逻辑接口第二段把物理成员口加进来第三段配置负载均衡算法和允许通过的VLAN。我用华为设备语法示例# interface Eth-Trunk1 port link-type trunk port trunk allow-pass vlan 10 20 30 load-balance src-dst-ip # interface GigabitEthernet0/0/1 eth-trunk 1 # interface GigabitEthernet0/0/2 eth-trunk 1 # interface GigabitEthernet0/0/3 eth-trunk 1 #看到这里很多人会问成员口的eth-trunk命令加到物理口上跟直接在Eth-Trunk接口里加成员有什么区别华为的命令风格是“物理口归属聚合口”在物理接口视图执行eth-trunk 1就是把该物理口“认领”进聚合组。Eth-Trunk逻辑接口下不需要再重复执行加入成员的命令这跟某些厂商“在聚合接口里追加成员”的命令模式不一样考试选择题容易在这个细节上挖坑。成员口加入后真正决定能不能聚合成功的是一致性检查。华为设备会自动检查成员口的速率、双工模式、缺省VLAN、链路类型、允许通过的VLAN列表等参数。只要有一项不一致成员口就加入失败或者直接Error-Down。实际操作中最常见的问题是三个成员口原本都是Access口其中一个改过PVID加入聚合组后报“Error: The port is not a hybrid port”或者成员口起不来。所以正式配置前先把所有候选成员口重置成一致性状态是我的习惯动作——清掉端口下的VLAN配置、关闭STP边缘口设置、统一速率和双工协商模式再执行eth-trunk命令。3.2 负载均衡算法怎么选别再无脑选“五元组”很多人配置load-balance的时候习惯性打出src-dst-ip就收工觉得“反正五元组哈希最均匀”。这个思路在真实场景里不一定成立。华为设备支持的哈希类型包括源MAC、目的MAC、源目的MAC、源IP、目的IP、源目的IP、增强模式有些版本叫enhanced mode等。选错哈希轻则流量不均重则某条链路直接被打满。用一个生活化类比理解哈希分配一个快递分拣中心如果按目的地分拣恰好某个片区的包裹特别多这个片区对应的传送带就会堆积如山如果按发件人分拣某一个发件大户能把一条传送带堵死。Eth-Trunk的哈希算法也是同一个道理它只是把报文的某些字段塞进哈希函数算出结果后映射到某条成员链路。选哪个字段做哈希决定了流量分散的维度。具体怎么选我给一个实操建议二层业务为主的环境比如服务器接入、虚拟机迁移网络优先用src-dst-mac三层业务为主的环境比如核心到汇聚、出口路由场景优先用src-dst-ip不确定流量模型又想让设备自己判断的用增强模式它会根据报文特征自适应选择哈希因子。考试不会考到“某项目该选哪种”但会考每种哈希类型对应的命令和基本原理这里需要记得扎实。3.3 手工模式的局限链路故障了设备还在“闷头转发”手工模式没有协议层面的健康检查这是它的硬伤。物理链路断了、光模块掉了接口状态会变成Down设备自然不往这条链路上发流量。但现实故障往往没那么简单——光纤被误踩导致接收光功率过低接口还没Down误码率却在飙升或者接收方向断了但发送方向还通着对端设备收到的是残缺报文。这种“半死不活”的链路故障手工模式完全无感流量依然会被哈希到这条坏链路业务抖动排查起来极其困难。我建议能上LACP尽量上LACP手工模式只作为跨厂商对接或应急场景的备用方案。考试里也有对应的判断题手工负载分担模式不能检测成员链路和对端间的故障答案是对的。这个点记住了选择题稳拿一分。4. LACP模式深入选举机制、超时参数与主备链路4.1 系统优先级和接口优先级LACP怎么决定谁转发谁备份LACP模式配置完成后两端设备会通过LACPDU互相交换优先级信息然后各自在本地执行端口角色的选举逻辑。选举涉及两个优先级数值系统优先级LACP System Priority和接口优先级LACP Port Priority。系统优先级的默认值是32768数值越小优先级越高。接口优先级的默认值也是32768同样数值越小优先级越高。选举时设备会综合比较对端信息和本端信息最终决定每条成员链路是进入Selected状态还是Standby状态。配置活动链路数上限后比如max active-linknumber 2系统会从所有成员链路里挑出优先级最高的两条作为活动链路其余自动成为备份链路不转发数据。实际操作中接口优先级的调整非常有用。比如四条万兆链路其中两条的物理路径更短、光衰更小我希望优先使用这两条那就把它们接口下的lacp priority改成100其余保持32768设备选举时自然会优先选择这两条。考试题里经常会给出一个场景两端系统优先级相同、接口优先级不同问哪条链路是活动链路只要记住“数值小者优”这个规则这类题就是送分题。4.2 超时机制短超时和长超时别小看这个参数LACP协议维护链路状态靠的是持续发送LACPDU报文。对方多久不发报文就判定链路失效由超时机制决定。华为设备支持两种LACPDU超时时间短超时Fast和长超时Slow。短超时模式下LACPDU每1秒发送一次连续3次未收到对端报文即3秒判定链路故障长超时模式下LACPDU每30秒发送一次同样连续3次未收到判定周期是90秒。配置命令在Eth-Trunk接口视图下执行interface Eth-Trunk10 lacp timeout fast很多工程师习惯性把超时配成fast觉得“检测快点总没错”。但要注意短超时会显著增加LACPDU的发送频率和CPU处理开销如果对端是老旧设备可能承受不住这个频率的协议报文反而引发告警风暴。实际项目中数据中心内部设备性能好用fast提升收敛速度跨厂商对接或设备性能偏低时用slow更稳妥。考试里会问短超时和长超时对应的发送周期和故障判定时间把“1秒/3秒”“30秒/90秒”这两组数据记到条件反射级别。4.3 从LACPDU报文读懂协商过程如果你有条件用Wireshark在交换机镜像口上抓包会看到LACP的报文其实是IEEE 802.3ad定义的Slow Protocol目的MAC地址固定为01:80:c2:00:00:02。报文里最核心的信息是Actor和Partner两个角色字段。Actor表示发送方的自身信息Partner表示发送方记录的“对端信息”。每台设备发出的LACPDU都携带两组信息我这边的状态、我看到的你那边的状态。两端通过持续交换这些信息逐步收敛出一致的链路状态视图。这个过程类似两个人互相对话确认“我是A我认为你是B”“我是B我也认为你是A”两边对得上链路才能进入Selected状态。这个机制解释了为什么LACP能做到故障感知只要对端设备宕机或者链路中断本端连续几个周期收不到对方的LACPDU就会立刻把这条链路从Selected状态降级触发流量切换。而这种能力手工模式是没有的。报文里的状态信息还包括LACP Activity、Timeout、Aggregation、Synchronization、Collecting、Distributing等标志位备考时可以简单了解遇到排障时再深入看。5. 配置实战模拟项目X双核心上联LACP模式完整部署5.1 拓扑与规划我用一个模拟项目X来演示完整配置过程。两台设备核心交换机作为主设备假设叫SW-Core汇聚交换机作为对端SW-Agg。SW-Core上联侧有四个万兆口XGE0/0/1到XGE0/0/4SW-Agg下行侧也有对应的四个万兆口。四根光纤分别连接两端物理链路都可达现在要做成一条Eth-Trunk提高上联带宽并做冗余。规划参数如下参数项核心交换机SW-Core汇聚交换机SW-AggEth-Trunk编号1010工作模式lacp-staticlacp-static系统优先级100200接口优先级XGE0/0/1-2设为100其余默认32768全部默认32768活动链路上限44负载均衡算法增强模式src-dst-ip增强模式src-dst-ipVLAN允许VLAN 10-30允许VLAN 10-30这里把核心交换机的系统优先级调成100汇聚交换机保持默认值32768或调成200数值小者优确保核心交换机在LACP协商中处于主导地位两端对链路状态的判断以核心侧为准。这在多设备环境里是一种常见的标准化做法避免两端因优先级相同产生争议。5.2 核心交换机配置步骤先配置SW-Core的Eth-Trunk模式和相关参数# sysname SW-Core # lacp system-priority 100 # interface Eth-Trunk10 mode lacp-static load-balance enhanced port link-type trunk port trunk allow-pass vlan 10 to 30 max active-linknumber 4 lacp timeout fast # interface XGigabitEthernet0/0/1 eth-trunk 10 lacp priority 100 # interface XGigabitEthernet0/0/2 eth-trunk 10 lacp priority 100 # interface XGigabitEthernet0/0/3 eth-trunk 10 # interface XGigabitEthernet0/0/4 eth-trunk 10 #这里有个细节max active-linknumber 4在四根物理链路全在的情况下所有链路都会是活动链路配置这个参数的意义在于显式声明上限防止未来误加第五根成员口时设备自动把链路全部启用超出规划。如果只希望其中两根作为主用另两根热备就把这个值改成2并配合接口优先级来指定到底是哪两根成为主用。接着配置SW-Agg内容和核心侧类似区别在于系统优先级保持默认或设为200接口优先级统一默认# sysname SW-Agg # interface Eth-Trunk10 mode lacp-static load-balance enhanced port link-type trunk port trunk allow-pass vlan 10 to 30 max active-linknumber 4 lacp timeout fast # interface XGigabitEthernet0/0/1 eth-trunk 10 # interface XGigabitEthernet0/0/2 eth-trunk 10 # interface XGigabitEthernet0/0/3 eth-trunk 10 # interface XGigabitEthernet0/0/4 eth-trunk 10 #5.3 验证命令与流量观测配置完成后核心的验证命令是display eth-trunk 10重点关注Eth-Trunk的状态、工作模式、系统优先级、活动链路数量和成员状态。输出模版大概是Eth-Trunk10s state information is: WorkingMode: LACP Hash arithmetic: Enhanced System Priority: 100 Max Active-linknumber: 4 Operate status: up Number Of Up Port In Trunk: 4 Port Status Priority XGE0/0/1 Selected 100 XGE0/0/2 Selected 100 XGE0/0/3 Selected 32768 XGE0/0/4 Selected 32768看到四个Port都是Selected状态且Operate status为up说明聚合协商成功。接着要检查流量分布用display interface Eth-Trunk 10可以看整个逻辑接口的收发流量但更关键的是看每个成员口的流量占比。可以分别查看display interface XGigabitEthernet0/0/1的Input/Output速率对比四个口的数值是否接近。如果发现某一根链路的速率明显高于其他链路说明哈希算法没有把流量打散。此时可以检查流量模型如果大部分都是三层IP流量把load-balance改成src-dst-ip如果还是不均匀用增强模式试试。增强模式是华为设备里比较“聪明”的选项能根据报文特征自动选择合适的哈希因子但要注意两端必须配置相同的算法否则对端去重和流量重组会有问题。抓包验证LACP报文也是个好习惯。在SW-Core任意一个成员口上做镜像抓到的报文里会周期性出现LACPDU源MAC是交换机成员口的MAC目的MAC是01:80:c2:00:00:02协议类型为0x8809。看到这些报文基本可以确认两端LACP协商是正常工作的。5.4 跨设备链路聚合的简单扩展如果你关注过华为的堆叠和集群方案会发现Eth-Trunk还有一个进阶玩法跨设备链路聚合。两台交换机做成堆叠后Eth-Trunk的成员口可以分布在两台不同的物理设备上逻辑上还是一个聚合组。这样即使某一台设备整机故障另一台上的成员链路还能继续承载流量实现了设备级别的冗余。这个特性在HCIP考试里属于加分项在真实的双核心部署里几乎是标配。它的配置和单设备Eth-Trunk没有本质区别但要求两台设备先完成堆叠Eth-Trunk的接口视图下会看到成员口来自不同的堆叠成员故障切换时由堆叠系统统一协调。这个内容单独写一篇都绰绰有余这里先留一个楔子备考的朋友可以顺着“跨设备Eth-Trunk”和“E-Trunk”这两个关键词继续深挖。6. 常见问题排查从聚合不上到流量不均6.1 成员口加入失败先查一致性我在项目里遇到最多的Eth-Trunk故障就是成员口加不进去。设备报错的方式各不相同有的是“Error: The port is already a member of another Eth-Trunk”有的是“Error: The ports configuration is not identical to Eth-Trunks”还有的直接沉默地让端口保持在Down状态。遇到成员口加入失败按下面这个顺序排查基本能解决问题确认成员口没有被其他业务占用。路由器、交换机上同一个物理口只能属于一个聚合组如果之前在别的Eth-Trunk里先执行undo eth-trunk退组。检查字段级一致性。端口速率、双工模式、缺省VLAN、链路类型Access/Trunk/Hybrid和允许VLAN列表必须和Eth-Trunk逻辑接口完全一致。其中最隐蔽的是VLAN列表不一致比如Eth-Trunk上允许VLAN 10到30成员口上残留了VLAN 40报错是免不了的。检查端口是否被其他功能绑定。比如有的端口配置了端口安全、DHCP Snooping信任、风暴控制策略这些不会直接阻止加入但会影响加入后的转发行为建议先清理干净。命令上看display eth-trunk verbose可以确认成员口的加入结果如果端口状态显示为“Up”但角色还是“Standby”说明协商还在进行或参数不匹配。6.2 链路全部Up但带宽就是跑不满这个问题的典型表现是display eth-trunk看到四根链路全是UpOperate status也是up但跑业务的时候整体速率只有单链路的1.5倍而不是接近四倍。根因几乎都出在负载均衡算法和流量模型的匹配度上。举个例子某模拟项目X里汇聚交换机上跑的是大量虚拟机迁移流流量特征是少量大流、每条流持续时间长。如果哈希算法配的是src-dst-ip理论上应该打散到四条链路但虚拟机迁移流通常只有几个固定IP对哈希结果高度集中实际上只有一到两条链路在忙。后来把算法改成src-dst-mac情况依然没有明显好转因为MAC数量也不多。最后换成增强模式让设备根据报文的多种特征做综合哈希链路利用率才基本拉平。这个案例说明了一个朴素的道理哈希算法没有绝对的优劣只有“跟流量模型契不契合”。排查时我习惯先做一次“流量画像”看看是少量大流还是海量小流源目地址分布广不广再决定选哪种算法。6.3 手工模式对端配合失误引发广播风暴有一次做跨厂商设备对接对方老设备不支持LACP只能用双方的手工负载分担模式。我对接侧配置好Eth-Trunk后业务却出现了广播风暴排查了很久才发现问题出在对方设备对方只在两台设备间拉了两根线但没有在交换机侧做任何聚合配置等于两根物理链路各自独立转发交换机之间出现了物理环路STP又没来得及收敛广播报文在环路上反复循环。这个教训让我养成一个习惯手工模式对接前必须跟对端工程师确认清楚他们那边是把两根线绑进了一个逻辑口还是只把两根线都插上就完事。前者没问题后者就是灾难。考试里如果考手工负载分担的缺点这个“无法通过对端协商避免环路风险”的场景就是标准答案之一。6.4 LACP协商不了先看两端基础参数LACP协商失败首先要怀疑的不是协议本身而是物理层和基础配置。先看两端成员口的物理状态是否都是Up再看两端Eth-Trunk的模式是否一致——一端配了lacp-static另一端配了manual load-balance协商绝对不可能成功。再检查两端的系统优先级是否配置成了极端值以及接口优先级调整是否造成了双方角色判断不一致。还有一个容易忽略的问题LACP报文需要穿越二层网络时中间设备的VLAN策略可能会过滤掉组播MAC地址01:80:c2:00:00:02。正常情况下LACP报文只在直连链路间传递但如果两台设备之间的链路中间还隔了透传设备就要确认透传设备没有因为MAC地址过滤或端口隔离而丢弃这些报文。抓包时如果本端一直发LACPDU但收不到对端回应大概率是报文在半路被丢弃或者对端接口没启用LACP。故障现象可能原因排查动作成员口加入失败参数不一致或端口被占用检查VLAN、速率、双工确认未加入其他聚合组链路全Up但带宽不足哈希算法与流量模型不匹配观察流量画像调整load-balance算法手工模式出现广播风暴对端未正确配置聚合核对对端配置确认链路已正确捆绑LACP协商失败模式不匹配或LACPDU被丢弃检查两端模式、系统优先级、二层透传和抓包分析短超时导致告警频繁对端CPU处理能力不足将lacp timeout改为slow7. 备考速记HCIP/HCIE链路聚合的考点清单7.1 易考选择判断题归纳备考阶段我把Eth-Trunk相关考点归纳成几类一类一类过链路聚合的基本概念——Eth-Trunk能做什么带宽提升、冗余、负载均衡。判断题里喜欢说“Eth-Trunk可以将多条物理链路捆绑成一个逻辑链路增加带宽的同时还能实现冗余”正确。STP之间的关系——加入Eth-Trunk后STP只计算逻辑接口而不是物理接口因此不会阻塞成员链路。选择题里如果出现“Eth-Trunk中每个成员口都独立参与STP计算”这是错的。两种模式差异——手工负载分担模式下所有成员口都转发流量没有备份链路的概念LACP模式下可以通过max active-linknumber限制活动链路数其余链路自动备份。考试常在这两类模式的功能差异上做文章。LACP优先级——系统优先级和接口优先级默认值都是32768数值越小越优接口优先级影响具体哪条链路成为Selected系统优先级影响设备间的主导关系。LACP超时——短超时发送周期1秒3倍判定故障长超时发送周期30秒90秒判定故障。这个数据考得非常频繁。负载均衡算法——逐流保证报文有序逐包可能乱序华为默认逐流负载分担哈希因子可选MAC、IP、增强模式等。7.2 配置命令的记忆方法Eth-Trunk的命令记忆可以按“五步走”的框架来组织不容易乱第一步创建逻辑接口并进入视图interface Eth-Trunk10。 第二步配置工作模式mode lacp-staticLACP或者保持默认手工模式不需要显式配置。 第三步把物理成员口加进聚合组在每个物理口视图下执行eth-trunk 10。 第四步调整聚合参数load-balance、max active-linknumber、lacp priority、lacp timeout。 第五步验证display eth-trunk 10、display lacp statistics。这个框架对记忆命令很有效考试画图题或配置命令排序题基本都能覆盖。7.3 实验环境建议备考HCIP/HCIE纸上谈兵是不够的。有条件的话用eNSP搭一个小环境把手工负载分担和LACP模式各做一遍再模拟故障看切换时间实验过程中得到的直觉比背二十个考点都值钱。实验步骤建议先用三台交换机两台做Eth-Trunk对接中间跑一个VLAN业务然后分别配置手工模式和LACP模式观察display eth-trunk输出的状态差异接着手动shutdown一条成员链路看流量是否自动切换到其他链路最后修改哈希算法和接口优先级对比成员口状态的变化。这一套实验做完链路聚合这个知识点就算真正吃透了。我个人在实际项目中的一个体会是Eth-Trunk这类基础技术往往在关键时刻决定网络稳不稳。聚合配得不好四条万兆可能还不如一条万兆靠谱配好了带宽和冗余可以兼得。备考的朋友如果时间有限优先把LACP的选举规则和两种模式的差异背熟再把实验做一遍剩下的交给真实项目慢慢积累。最后再分享一个小技巧现场排障时先看display eth-trunk的状态输出再看成员口的流量统计最后才动配置。很多问题光靠看状态就能定位别一上来就改配置改坏了更难收场。