企业官网建设流程全解析

写这篇的时候，我其实挺有感触的。当年刚接触网络工程，第一次在项目现场配链路聚合，心里还嘀咕着“不就是把几根网线绑一起当一根用嘛”，结果被现实狠狠教育了一课。后来系统过了一遍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最大的区别在于：成员链路在加入聚合组后，需要先通过LACPDU（Link 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带来的故障感知和能力太重要了，尤其在上联核心这种关键链路上，链路坏没坏不能靠人去机房看灯。

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/4），SW-Agg下行侧也有对应的四个万兆口。四根光纤分别连接两端，物理链路都可达，现在要做成一条Eth-Trunk，提高上联带宽并做冗余。

规划参数如下：

这里把核心交换机的系统优先级调成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-Trunk10's 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 port's configuration is not identical to Eth-Trunk's”，还有的直接沉默地让端口保持在Down状态。

遇到成员口加入失败，按下面这个顺序排查基本能解决问题：

1. 确认成员口没有被其他业务占用。路由器、交换机上同一个物理口只能属于一个聚合组，如果之前在别的Eth-Trunk里，先执行undo eth-trunk退组。
2. 检查字段级一致性。端口速率、双工模式、缺省VLAN、链路类型（Access/Trunk/Hybrid）和允许VLAN列表，必须和Eth-Trunk逻辑接口完全一致。其中最隐蔽的是VLAN列表不一致，比如Eth-Trunk上允许VLAN 10到30，成员口上残留了VLAN 40，报错是免不了的。
3. 检查端口是否被其他功能绑定。比如有的端口配置了端口安全、DHCP Snooping信任、风暴控制策略，这些不会直接阻止加入，但会影响加入后的转发行为，建议先清理干净。

命令上看display eth-trunk verbose，可以确认成员口的加入结果，如果端口状态显示为“Up”但角色还是“Standby”，说明协商还在进行或参数不匹配。

6.2 链路全部Up，但带宽就是跑不满

这个问题的典型表现是：display eth-trunk看到四根链路全是Up，Operate 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。

7. 备考速记：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-static（LACP）或者保持默认（手工模式不需要显式配置）。 第三步，把物理成员口加进聚合组：在每个物理口视图下执行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的状态输出，再看成员口的流量统计，最后才动配置。很多问题光靠看状态就能定位，别一上来就改配置，改坏了更难收场。