1. 为什么同是链路聚合，我却建议你选LACP模式
1.1 静态聚合与LACP的本质差别
有一次半夜被叫起来处理某个托管机房的网络故障，现象很典型：业务时断时续，交换机上两根千兆物理链路都显示Up，但流量严重掉包，光看接口状态根本看不出问题。最后拔掉一根线故障立刻消失，插回去又复现，这才定位到是“两台设备之间配置了静态聚合，但物理接线上有一根误跳到了别的设备”。这种场景我遇到过不止一次，根子就在聚合模式的选型上。
华为设备上做链路聚合，常见的是两条路线：一个是手工模式的静态聚合（Eth-Trunk手动加入成员口，不协商），另一个就是标题里说的LACP模式。手工模式最大的问题是“不协商”：只要本地把端口加入Eth-Trunk，接口就直接参与转发，不管对端是否真的在同一条聚合里、不管中间有没有串接其他设备、也不管对端端口有没有启用。好处是很简单，坏处是物理接错线时它不会主动“纠错”，反而会把流量双发、打环，把业务搞挂。
LACP（Link Aggregation Control Protocol，链路聚合控制协议）则完全不同。它会在聚合两端周期性发送LACPDU报文，双方确认彼此的身份、端口属性、优先级之后，才决定哪些物理链路能成为活动成员，哪些只能作为备份。换句话说，它是在“握手成功”之后才让链路转发流量，而不是“硬凑在一起”。所以当物理拓扑变动、某根线被误插到别的设备时，LACP的协商状态会立刻异常，端口要么不进入聚合，要么链路抖动，至少能从状态里看出问题，而不会悄悄引流。
1.2 手工模式与LACP怎么选
选型其实不复杂，核心就看对端能不能配合协商。
如果两端都是支持LACP的设备（华为交换机之间、华为设备与主流服务器网卡、虚拟化平台之间），优先用LACP模式，也就是命令里的mode lacp-static。它能保证成员口只有在双方确认后才转发，同时还能配合活动链路数量限制、端口抢占、快速超时这些特性，这是手工模式给不了的。
只有一种情况迁就手工模式：对端是非常老的设备、某些嵌入式网卡驱动不完整、或者对端只支持静态聚合而完全没法开启LACP。这时候用mode manual硬聚合是可以接受的，但必须接受它“不协商”的风险，物理接线、对端口状态都要人工确认到位。另外一个不少见的坑是：对端网卡支持LACP，但接口默认是被动模式（passive），两边都在等对方先发报文，结果协商迟迟不成功。这种场景要么把华为侧配成主动LACP，要么把对端网卡也改成主动模式，不能两端都卡在被动上。
1.3 为什么很多故障本质上是“没协商成”
后来做了这么多年网络，我越来越觉得LACP最核心的不是那些配置命令，而是协商机制本身。网上教程大多是教“怎么配对、怎么敲命令”，很少有文章讲清楚它为什么可以防环、为什么有的链路协商成功却不转发、为什么聚合口Up了流量还是走单根。
只要把“协商”这个底子理解透，后面所有排查都顺了：LACP报文里带着系统优先级、系统MAC、端口优先级、端口号、操作Key等信息，两端通过这些信息比对，选出活动链路、确定主备关系。协商的过程中，只要有一项对不上，端口就不会进入正常的聚合状态。所以排查的时候，与其瞎猜，不如直接看协商结果，哪一项没对齐就改哪一项，这就是LACP排障的基本思路。
2. 配置前必须吃透的三个底层机制
2.1 LACPDU里到底协商了什么
LACP的工作基础是LACPDU（Link Aggregation Control Protocol Data Unit）。这个报文很小，包含了几组关键信息：
- 系统优先级和系统MAC：用来确认“我是谁”，两端配对时比对的是这套身份信息。
- 端口优先级和端口号：用来确认“哪个成员口是哪个”，并参与活动链路的选择。
- 操作Key：相当于聚合组的“身份标签”，两端只有Key匹配的端口才会被拉进同一个Eth-Trunk。
- 状态标志和超时字段：包括本端是否处于Active、是否已同步、对端状态是否聚合等。
处理链路聚合故障时，我几乎必看display lacp negotiation verbose，里面会把本端Actor和对端Partner的详细信息都列出来。很多“协商失败”其实一眼就能看出来：比如系统ID对不上（两端接的不是同一台设备）、操作Key不一致（成员口被其他配置影响）、超时字段不匹配等等。这个时候再去查配置、查接线，方向就非常明确。
2.2 华为LACP的优先级体系
华为数通设备里LACP涉及两级优先级，很多人配完也没完全搞懂，这里展开说。
第一个是系统LACP优先级，缺省32768，数值越小越优先。它决定的是两端协商时谁拥有“主导权”。当链路数量超过活动链路上限时，是让本端的端口优选，还是让对端的端口优选，是由系统优先级高的一端来决定的。一般建议在网络核心侧调低系统优先级，让核心设备掌握活动链路的选择权。
第二个是接口LACP优先级，也缺省32768，同样数值越小越优先。它决定的是“一旦链路数量受限，哪些端口优先成为活动链路”。比如一个Eth-Trunk里有4个成员口，但设置了lacp max active-linknumber 2，那么接口优先级高的两个口成为活动链路，另外两个口自动进入备份状态；活动链路故障后，备份口再顶上来。这个机制非常有用，可以在保证带宽的同时保留冗余资源。
我见过不少朋友对这两个优先级不设区分，全程用缺省值，结果出现链路上限时两台设备“各说各话”，选出的活动口不是预期的那几根。实际操作中建议在重要的框式设备上把系统优先级调小，在关键板卡或高速率端口上把接口优先级调小，这样活动链路的选择就是可控的。
2.3 超时机制与快速收敛
LACP报文不是一直狂发，它按照超时机制决定发送周期和老化速度。华为设备上常见两种：
- 慢超时（Long Timeout）：默认的30秒周期，对端3倍时间内没收到报文就判定链路超时。适合多数静态场景，开销小。
- 快超时（Short Timeout）：1秒周期，对端3倍时间内没收到就判定超时，适合要求快速检测链路故障的场景。
超时的作用是感知链路故障：如果某根成员链路物理层还Up，但中间链路异常、报文过不来，LACP超时后会让该端口从聚合中退出，业务会迅速切换到其他活动链路上。很多人问“物理链路都Up，聚合怎么还会踢端口”，其实就是这个超时机制在起作用。
需要说明的是，超时机制与对端必须匹配，两端不一致时协商结果虽然也能起来，但收敛行为会变得不可预期。华为设备上如果需要快速收敛，可以在成员接口视图配置lacp timeout fast，同时确认对端也配置了相同的快速超时。
2.4 活动链路与备份链路的关系
前面提到了活动链路上限，这里再展开说清楚。LACP模式下，一个Eth-Trunk的成员口可以大于实际转发所需的链路数。超出上限的端口处于备份状态，不转发数据，但持续参与协商、持续监控链路状态。一旦活动链路故障导致可用链路数低于上限，备份端口能自动切换为活动链路。这个特性在核心侧尤其有意义：四根链路做聚合，平时只跑两根，另外两根热备，既保带宽又保冗余，还不增加日常转发负担。
顺带提醒一个容易误会的点：备份链路虽然不转发数据，但它仍然占用端口、仍在收发LACPDU，所以排障时看到端口有少量报文计数并不代表业务流量在走它。要区分活动链路和备份链路，直接看display eth-trunk里的状态即可。
3. 华为设备LACP配置全流程（可直接套用）
3.1 准备阶段的物理口检查
配置LACP之前，我习惯先把物理层条件过一遍。这里的“物理层条件”不只是说线缆插没插好，而是包含几个经常被忽略的细节：
- 所有成员口的速率和双工模式必须一致。LACP不会自动纠正速率不一致的问题，协商时会出现端口属性不匹配，导致部分成员口无法加入聚合。
- 所有成员口必须处于未shutdown状态。有的设备在长期维护中某个口被手动shutdown过，重新做聚合时很容易漏掉。
- 成员口不能有残留的VLAN、ACL、QoS、镜像等业务配置，加入Eth-Trunk前最好先清空。
- 如果是三层物理口，需要先切换到二层模式（华为设备上常见
undo portswitch），然后再加入Eth-Trunk，或者提前确认该系列设备支持直接在三层口上创建三层聚合。
这些检查和LACP本身关系不大，但十次配置问题里有八次出在这种“前戏”上。
3.2 创建Eth-Trunk并设置LACP模式
以常见VRP命令行举例，核心过程如下，不同系列和版本命令细节会有出入，但整体套路一致：
system-view interface Eth-Trunk 1 mode lacp-static load-balance src-dst-ip lacp max active-linknumber 2 lacp preempt enable quit这里逐条说明：
mode lacp-static：把Eth-Trunk 1设为静态LACP模式。这条命令是最关键的，它决定了这个聚合口走的是LACP协商而不是手工聚合。load-balance src-dst-ip：设置负载分担算法。具体算法选型后面有专门章节讲，这里先用最常见的源目的IP组合。lacp max active-linknumber 2：限制最大活动链路数为2。如果你的场景不需要限制，可以不加这条，让所有成员口全部参与转发。lacp preempt enable：使能端口抢占。意思是当高优先级的端口恢复后，可以重新抢占成为活动链路。如果不开启抢占，恢复的端口只能等现有活动链路故障后才有机会顶替。
3.3 加入成员口
加入成员口有两种常见方式。第一种是在Eth-Trunk视图下批量加入：
interface Eth-Trunk 1 trunkport GigabitEthernet0/0/1 to GigabitEthernet0/0/4 quit第二种是逐个进入物理接口视图加入：
interface GigabitEthernet0/0/1 eth-trunk 1 quit interface GigabitEthernet0/0/2 eth-trunk 1 quit两种方式都能用，我更喜欢批量方式，少敲几行命令也少犯错。不过批量方式在某些设备上仅对二层口生效，如果物理口有特殊配置，稳妥起见还是逐口加入。
一个细节：成员口一旦加入Eth-Trunk，原有的接口配置就不能独立生效了，相关二层/三层配置要在Eth-Trunk接口上统一配置。很多新手把VLAN配在物理口上，又在Eth-Trunk上配了一遍，看起来状态正常，实际上转发行为错乱。记住一个原则：物理口加入聚合后，它只是“成员”，所有对外业务配置一律在Eth-Trunk口上做。
3.4 配置后的状态确认
配置完不要急着测流量，先确认协商状态。必看三个命令：
display eth-trunk 1 display lacp negotiation verbose display interface Eth-Trunk 1display eth-trunk 1：查看聚合口整体状态、成员口列表、活动链路与备份链路分布。重点看Actor/Partner是否都为Selected，以及每个口的成员状态。display lacp negotiation verbose：查看详细的LACP协商信息，适合排查协商不到一起的问题，比如系统优先级、操作Key是否匹配。display interface Eth-Trunk 1：查看聚合口流量计数和速率，用于后续观察负载是否均匀。
一个可复现的检查思路是：先把display eth-trunk 1里每个成员口的状态记下来，再和物理拓扑对照。如果某个物理口始终是Unselected或者不在聚合里，优先怀疑物理层或配置残留，而不是怀疑命令敲错了。
3.5 关键参数速查
下面这个表格是配置时经常涉及的参数和它们的影响，收藏起来方便对照：
| 参数 | 缺省值 | 作用 | 建议 |
|---|---|---|---|
| 系统LACP优先级 | 32768 | 决定谁主导活动链路选择 | 核心侧调小，如4096 |
| 接口LACP优先级 | 32768 | 决定哪些端口优先成为活动链路 | 高速端口/主用板卡调小 |
| 活动链路上限 | 不限制 | 超过上限的端口进入备份状态 | 按带宽与冗余平衡设置 |
| 抢占 | 关闭 | 高优先级端口恢复后能否重新成为活动链路 | 核心场景建议开启 |
| 超时机制 | 慢超时 | 影响链路故障检测速度 | 对端支持时建议快超时 |
| 负载分担算法 | 按设备默认 | 决定数据流如何分配到各成员链路 | 按业务流量特征选择 |
4. 华为设备与服务器、虚拟化平台的LACP对接细节
4.1 与Linux服务器bonding对接
Linux服务器做网卡绑定时，LACP对应的就是bonding的mode 4（802.3ad）。华为侧配置静态LACP模式后，Linux侧建议这样处理：
# 加载bonding模块 modprobe bonding # 创建bond接口 ip link add bond0 type bond mode 802.3ad # 设置LACP报文速率，可选fast或slow echo fast > /sys/class/net/bond0/bonding/lacp_rate # 将两块网卡加入bond ip link set ens33 master bond0 ip link set ens34 master bond0对接时最容易踩的坑是两侧协商模式不匹配：华为侧虽然配置了mode lacp-static，但如果Linux bond的LACP没有被正确激活（比如网卡驱动没加载、bond0没有正确设置mode），协商永远起不来。排查时在服务器上执行cat /proc/net/bonding/bond0，确认LACP状态是否已经转为Negotiated，再回到交换机上看协商信息。
另一个常见问题是Linux侧的流量均衡算法和华为侧不一致。Linux bond mode 4默认使用基于哈希的发送策略，可以通过xmit_hash_policy调整；而华为侧也要选择对应的负载分担算法。否则即使协商成功，也会出现出口流量集中在某一根物理链路上的情况。建议在两侧都采用包含IP、端口等二元组/四元组哈希的策略，保证离散度。
4.2 与VMware虚拟化平台对接
VMware场景下，LACP一般出现在两个层面：标准交换机的网卡绑定，或者分布式交换机上开启LACP支持。前者通常是在vSwitch属性里把负载均衡策略设为“基于IP哈希的路由（Route based on IP hash）”，后者则要配置LACP组。
对接VMware时有几个必须注意的点：
- 交换机侧必须配置为主动LACP，即华为的
mode lacp-static。VMware的LACP默认是被动等待还是主动发送，要按实际版本确认后再决定要不要保留被动模式。 - 虚拟化主机的多张物理网卡必须连接到同一台交换机（或同一个堆叠系统）的对应端口上，不能一张网卡接接入交换机A、另一张网卡接交换机B，除非这个场景本身用的是堆叠状态下的跨设备链路聚合。
- VMware的“基于IP哈希的路由”本质上也是哈希分配流量，单条TCP连接仍然只会走一根物理链路。如果虚机里跑的是大型文件传输，该TCP会话还是只能占满一根链路，多根链路的带宽不会叠加到单会话上。
在ESXi主机上核查时，可以通过图形界面查看“物理适配器”的负载状态，再回到华为侧对比每个成员口的流量计数，确认两个方向上的分布是否合理。
4.3 与Windows网卡Teaming对接
Windows网卡Teaming（Windows Server网卡绑定）对接华为设备时，模式选择要对应清楚：
- Windows“静态成组（Static Teaming）”对应华为的手工静态聚合模式。
- Windows“动态成组（Dynamic Teaming）”对应华为的LACP模式。
- 如果华为侧配了
mode lacp-static，Windows侧就选动态成组，不要选静态成组，否则协商状态会异常。
Windows Teaming里还有一个“交换机独立模式（Switch Independent）”的选项，这种模式并不依赖交换机侧做聚合，通常配合“地址哈希”分配流量，跟LACP没有直接关系。如果客户明确要求华为侧做LACP，Windows侧一定不能用交换机独立模式，否则交换机上看到的只会是两个独立端口，流量分配逻辑也是乱的。
4.4 各种对接场景的通用建议
对接外部设备（服务器、防火墙、负载均衡器、存储设备）时，我建议按四个步骤走：先确认对端支持什么协议，再确认对端是主动还是被动模式，然后统一两端超时机制，最后核对负载分担策略。这四个点都对齐了，聚合起来就是水到渠成的事；任何一个点没对齐，后面大概率要反复查。
5. 链路聚合起不来的排查实战：从命令到根因
5.1 先看物理层，别让配置背锅
LACP起不来时，第一步不是改配置，而是先把物理层过一遍。我就见过很多次“协商状态一直显示Init”的情况，最后发现是某根网线的水晶头松了，重插一下就好。
排查时按这个顺序来：
display interface GigabitEthernet0/0/1看物理口是否Up、是否有CRC错误、是否有大量input/output error。如果有错误计数持续增长，优先怀疑线缆问题或光模块问题，哪怕物理状态显示Up也不能排除。接着逐口检查所有成员口，确认有没有被shutdown。很多项目在前期调试时临时shutdown过端口，后来做聚合时忘了恢复，这类问题从配置上找是找不到的。
5.2 再查协商状态，定位是哪一项没对齐
物理层没问题，就要看协商了。display lacp negotiation verbose里会有Actor和Partner两组状态，我把重点字段列出来：
| 字段 | 含义 | 常见问题 |
|---|---|---|
| Actor System ID | 本端系统标识 | 对端看到的值不是预期设备，说明接线错 |
| Partner System ID | 对端系统标识 | 显示为0或异常，说明没收到对端LACPDU |
| Actor Key / Partner Key | 操作Key | 不一致时端口无法进入聚合 |
| Actor State / Partner State | 协商状态 | State里包含Activity、Timeout、Synchronization等标志 |
如果Partner System ID一直是0，说明本端根本没收到对端的LACPDU，问题出在对端是否启用LACP、中间链路是否阻断、对端是否因为某种原因不发报文。如果两端系统ID都有，但状态一直在“Expired”或“Defaulted”之间切换，重点看中间链路有没有丢包、超时机制是否匹配。
5.3 常见配置冲突与环路隐患
协商成功了，不代表万事大吉。有几个配置冲突在不熟悉LACP的人手里很容易被漏掉：
- 成员口上残留了Access VLAN或Trunk VLAN配置，而Eth-Trunk口上又配了另一套VLAN，两层配置打架，表现为聚合口转发异常但协商状态正常。
- 成员口分别属于不同板卡或不同模块，在某些老设备上跨板卡聚合需要额外条件，不是所有设备都支持随意跨板。遇到协商成功但流量不均或端口频繁Down时，要检查板卡归属。
- 有中间串接设备。LACP只能用于物理上直连的链路聚合，如果中间串了一台二层交换机，LACPDU和业务流量都会受到干扰，极有可能出现链路反复横跳、Eth-Trunk状态时好时坏。这一点常被忽视，但在托管机房、跨机柜跳线场景里非常常见。
5.4 一个典型的协商成功但业务抖动的案例复盘
有一次在某项目上，客户报核心交换机与接入交换机之间聚合不稳定，现象是Eth-Trunk显示多条链路协商成功，但接口流量曲线像锯齿，掉包率在高峰期飙到百分之十几。我按照上面的排查顺序走了一遍：
先看物理层，所有成员口都Up，错误计数也正常。再看协商，Actor和Partner都握手成功，状态是Selected，看起来一切正常。然后看VLAN配置，居然发现成员口上还保留着旧的PVID配置，接口上既有Switchport配置又有Eth-Trunk配置，立刻怀疑这里有冲突。清掉成员口上的残留配置后，掉包率下降了一些，但流量仍然不稳定。
继续查才发现，拓扑里四根线有三根是直连核心和接入的，第四根线被机房施工时跳到了另一台设备上，那台设备也在跑LACP，两个不同系统在同一个聚合里争夺协商权。处理办法很简单：把第四根线从其他设备上拆掉，按直连关系重新插回接入交换机。重新查看display eth-trunk 1，所有成员口状态稳定，业务掉包消失。
这个案例给了我一个很深的印象：LACP协商成功，只能说明双方“身份对上了”，并不能说明物理拓扑一定正确。一旦怀疑接线问题，不要怕麻烦，把每一根线捋清楚，尤其是聚合链路这种多条线并行的场景，标签混乱是常态。
5.5 配置回滚与重新加入的规范操作
排查过程中如果确认是配置问题，不要直接删Eth-Trunk重加，不然可能引起业务闪断。我通常的做法是：
- 先把有问题的成员口从Eth-Trunk中移除（
undo eth-trunk）。 - 再清理该物理口上的残留配置（undo switchport、undo vlan等）。
- 确认物理口恢复正常独立状态后，再重新加入Eth-Trunk。
- 每次只动一根链路，观察业务影响，确认无误后再动下一根。
这样可以把影响面控制到最小，也便于在中间态定位问题。
6. 流量不均、单链路打满？负载分担算法调优实测
6.1 聚合后流量不均衡，先看流量特征
LACP聚合后的总带宽是多条物理链路相加，但有个本质限制：一条数据流只会经过某一根物理链路，不会在中间被拆到多条链路上。以最常见的TCP会话为例，同一个五元组的流量会通过同一根成员链路转发，不会因为聚合就自动“分片并行”。所以如果业务里存在少量大流量会话（比如大文件复制、视频监控流、数据库同步），很可能出现三根链路基本空闲、一根链路长期打满的现象。
这个限制不是设备问题，而是链路聚合的通用原理。理解了这一点，调优方向就清晰了：要么从流量特征出发选择更合理的哈希算法，要么在业务层面做多流拆解，比如把大的数据会话拆成多个连接。
6.2 华为负载分担算法的选型思路
华为设备上常见的负载分担算法包括按目的MAC、源MAC、目的IP、源IP、源目的IP、源目的MAC等。算法没有绝对的对错，关键看流量模型：
| 场景 | 推荐算法 | 理由 |
|---|---|---|
| 二层交换为主，大量MAC离散 | src-dst-mac | MAC地址离散度好，分配更均匀 |
| 三层路由为主，跨网段流量多 | src-dst-ip | IP地址哈希最适合路由场景 |
| 下行流量远大于上行 | dst-ip | 目的IP离散度高，下行分配均匀 |
| 出口NAT场景 | src-dst-ip | 兼顾源和目的，避免单一方向哈希走偏 |
| 数据中心东西向流量 | src-dst-ip + 端口（设备支持时） | 多维度哈希更均匀 |
配置算法时要注意：修改负载分担算法会导致哈希结果变化，业务瞬间会重新分布到各链路，但这属于正常的重新负载均衡，不会丢包。不过为了稳妥，还是建议在业务低峰期调整，再观察各成员口流量分布。
6.3 实测验证：怎么看均匀不均匀
调完算法不能光靠感觉，要看数据。方法很简单：
display interface Eth-Trunk 1这条命令会把聚合口下每个成员口的瞬时速率都打出来。我一般会连续观察3-5分钟，取几个时间点作对比，如果某条物理链路长期占用率超过80%，而其他链路只有20%-30%，说明哈希算法和流量模型不匹配，需要换算法再测。
还有一种强行均匀的用法是配置每包轮询，某些专业设备上叫增强负载分担或逐包负载分担。但逐包转发会破坏TCP报文顺序，对性能要求高的场景可能造成重传，这里不做推荐。常规的做法还是选择高维度的哈希算法，让流量自然散开。
6.4 客户最常见的误解：聚合等于单流加速
做网络越久，越觉得“翻译”比“实现”更重要。很多业务同事看到四根千兆做了聚合，第一反应是“下载速度应该到4G”。但实际上聚合是把多个大流分配到不同链路，单个TCP连接依然只能走一条物理链路。两个大流可以同时各走各的，一个大流永远跑不满聚合总带宽。
所以项目前期如果客户明确有大带宽单流需求，我会建议直接上高带宽物理链路（如万兆），而不是靠多根千兆聚合硬扛。这虽然不是LACP本身的问题，但在选型讨论中经常被扯进来，提前把预期说清楚，能省掉后续很多扯皮。
7. 跨设备场景与那些容易被忽略的实战细节
7.1 跨设备链路聚合不是随便做的
LACP本身是点对点的概念，物理上要求聚合链路两端设备直连。但数据中心里经常出现“跨设备”需求：核心侧有两台框式交换机，接入侧交换机希望同时连接两台核心，形成双归接入。这种场景必须借助堆叠、集群或跨设备链路聚合技术，把两台核心在逻辑上“变成一台设备”，然后接入交换机再用Eth-Trunk对接。
如果两台核心没有做堆叠，只是简单地把接入交换机的两张上联分别接到两台独立的交换机上，然后在接入交换机上做一个Eth-Trunk，这种做法在某些设备上可能协商不起来，即使协商起来了，对端两台设备因为没有统一协商状态，极可能形成环路或转发黑洞。所以遇到跨设备聚合需求，第一件事确认对端是否具备堆叠/集群基础，再确认是否支持对应的跨设备Eth-Trunk特性。
7.2 中间链路与串接设备问题
前面案例里已经提到中间串接设备的危害，这里单独再强调一次：LACP的协商和流量都要求两条链路之间是干净的物理直连。中间不能有独立的交换机、分光器、光电转换器、转发器之类的设备。原因是中间设备一旦参与转发，LACPDU的到达时间、内容都可能被改，两端协商出来的结果就和实际拓扑不一致，流量路径也未必沿着聚合成员口转发。
在工程实施时，我会在聚合链路两端做好明确的标签和标识，避免运维后期插错。曾经有个机房项目，几条聚合链路走向混乱，最后是靠着标签和链路追踪一条条捋出来的，那次的教训让我对“布线规范”这件事有了更高的敬畏。
7.3 升级和替换设备时的顺序问题
升级固件或者替换设备时，聚合链路最容易出问题。常见错误是：先把新设备上电，再把两根聚合链路同时插到新设备上，而旧设备侧还留着聚合配置，中间过程可能产生环路，也可能出现一台设备还没协商完成就开始转发流量，造成广播风暴。
我推荐的安全做法是：先在旧设备上把Eth-Trunk的成员口数量降为1（临时保留单活），同时在新设备上把LACP配置准备好，然后一根一根切换线路，每根线切换后立即确认协商状态和流量是否正常，最后再逐步恢复多成员。虽然过程繁琐，但比业务中断要好得多。
7.4 关于LACP的一些经验谈
做了这么多年网络，对LACP最深的体会就是它其实是个“很讲道理”的协议：双方协商成功才转发，协商条件不满足就乖乖待着。这份“讲道理”在平时显得啰嗦，但在拓扑混乱、维护频繁的生产环境里，反而能帮你挡住很多灾难。
我自己养成的几个习惯，分享出来供参考：配置完成后一定先看一眼display eth-trunk，确认每个成员口的状态；每次变更前保存当前配置和状态截图，出了问题能快速回退；物理链路的标签上除了写“几楼几柜几设备”，还要写明“聚合组编号”。这些看似琐碎的习惯，在真正出故障的时候，往往比任何高级特性都有用。
如果你手头也有LACP场景，不管是华为设备之间，还是华为设备对接服务器、虚拟化、防火墙，建议不要只停留在“把命令敲上去”的阶段，多花点时间把协商、优先级的逻辑理一遍。配置只是最后一步，理解才是真正的护城河。
