1. 这个需求背后到底要解决什么问题
1.1 链路聚合不是“两根线插一起”这么简单
先说点实际的。接到“华三交换机链路聚合”这个需求，最常出现的场景是：服务器双网卡想合并带宽、核心交换机到汇聚交换机之间两条光路想打满、或者监控平台NVR接入带宽不够用。很多刚入行的朋友第一反应是“多插几根网线不就行了”，但真这么做会出大问题——STP（生成树协议）会把冗余链路里的某一条Block掉，环路直接给你掐断，带宽不但没提升，反而只有一条线路在干活。
链路聚合（Link Aggregation）解决的核心问题有两个：一是把多条物理链路逻辑上绑成一条虚拟链路，带宽可以叠加；二是物理链路之间形成冗余，断一根线业务不中断。华三体系里这个技术叫Bridge-Aggregation，对应的接口叫BAGG口，成员端口通过聚合组统一管理，上层业务看到的只是一条逻辑链路，跑路由、跑VLAN、跑ACL都不受影响。做网络的朋友都清楚，这叫“逻辑归一、物理冗余”，本质上是把网络拓扑从网状收敛成树状/星状，从根上规避环路风险。
1.2 静态聚合还是动态聚合：方案选型思路
很多初学者做链路聚合，上来就敲命令，结果对端设备一换模式就全乱套。这里先说清楚两种模式的取舍，后面配置才能心里有底。
- 静态聚合：华三也叫手工聚合，所有成员口加入聚合组之后不需要协商，直接全部选中，汇聚带宽立马上来。优点是实现简单、兼容性好，缺点是两端配置没有握手校验，一旦对端某根线断了或者拔了，本端感知不到，业务流量可能往坏链路上硬塞，出现丢包。适用于设备同品牌、链路质量有保障、网络规模较小的场景。
- 动态聚合：走的是LACP（IEEE 802.3ad）标准，本端和对端通过LACPDU报文协商端口状态，双方确认无误的端口才会被选中转发流量。两端有一端的成员口配置有问题，这个端口就会被自动排除在聚合组之外，不会出现“明明线断了还在转发”的蠢事。华三交换机上绝大多数生产环境我建议用动态聚合，因为网络是动态变化的，协商机制能省掉很多半夜排障的麻烦。
选择模式时还要考虑对端设备。如果对端是服务器，Windows下的NIC Teaming、Linux下的bonding、hyper-v虚拟交换机的外部虚拟交换机，这些都有各自的协商模式，要和对端对齐。如果对端是华为、锐捷的交换机，虽然都是LACP协议，但各家实现细节还是有差异，建议优先用标准LACP模式兼容性最好。
1.3 哪些场景真正需要链路聚合
链路聚合不是摆设，但它也不是万能的。根据我这些年接触过的项目，真正值得上的场景集中在几类：
第一类是服务器接入带宽扩容，尤其是数据库、备份服务器、存储网关，单块千兆网卡跑备份能跑一整天，双千兆聚合之后虽然不可能翻倍到2000Mbps（要看流量哈希是否均匀），但实际能跑到1200Mbps到1600Mbps，体感提升巨大。第二类是交换机之间级联或上联，比如办公网两台汇聚交换机之间，或者汇聚上联核心，两条满载的万兆/千兆链路做聚合，既提升带宽又做高可用。第三类是监控网络的核心侧，现在动辄几十路400万像素摄像头，核心交换机到NVR之间不打聚合，并发流量一高就丢帧。
但也要泼一盆冷水：一条千兆带宽都没跑满的业务，链路聚合除了多做一套配置外没有任何意义；三条以上光路聚合，收益递减，出问题排查复杂度指数上升。所以动手之前先看流量监控数据，别为了“听起来很专业”而上聚合。
2. 华三链路聚合的底层逻辑：不懂原理配置就是碰运气
2.1 聚合组、成员端口、选中状态是怎么协同的
华三交换机的链路聚合，核心组件有三个：聚合接口（Bridge-Aggregation Interface）、聚合组（Aggregation Group）、成员端口（Member Ports）。
聚合接口是网络工程师眼中真正参与三层/二层转发的逻辑口，它有自己的接口编号（比如Bridge-Aggregation 1），可以配置IP、VLAN、Trunk属性。聚合组是成员端口的集合，本质上是一张“候选端口清单”。成员端口就是物理口，它们的职责是“出苦力”——实际转发数据报文。
聚合组里的端口有三种状态：Selected（选中）、Unselected（未选中）、Standby（备用）。只有Selected状态的端口才会真正转发业务流量；Unselected端口虽然加入聚合组但不转发，可能因为速率、双工模式、对端配置等问题被排除；Standby是动态聚合特有的概念，当Selected端口超过最大可用端口数时，多出来的就进Standby备用，一旦前面端口故障就顶上。
这里有一个华三特有的点：同一个聚合组里的Selected端口要求速率和双工模式必须一致，一个千兆口和一个百兆口硬要凑在一起，低速率那个会被强制Unselected。这个在组网接入层很常见，扩容时新换的千兆交换机和老的百兆设备对接，一定要检查两端速率。
2.2 参考端口是怎么选出来的
华三设备在协商链路聚合状态时，会从聚合组里挑一个“参考端口”（Reference Port），以它的属性作为标准，其他端口只有属性全一致才有资格成为Selected。
参考端口的选择顺序有讲究，我梳理成了一张表，方便记忆：
| 优先级 | 判断条件 | 说明 |
|---|---|---|
| 1 | 端口是否UP | 优先选状态为UP的端口 |
| 2 | 全双工优先 | 全双工端口优先于半双工 |
| 3 | 端口速率 | 高速率优先于低速率 |
| 4 | 端口编号 | 编号小的优先 |
举个真实场景：聚合组里A口是千兆全双工UP，B口是百兆全双工UP，那A口就是参考端口，B口因为速率不一致被Unselected。如果A、B速率一样，A口编号小，A口是参考端口。这一切都是设备自动完成的，不需要人工指定。但理解参考端口的意义在于：排查问题的时候，你第一件事就是看哪几个口是Selected，而不是傻盯着VLAN配置。
2.3 流量到底怎么分摊出去
链路聚合的带宽叠加靠的是哈希分发（Load Sharing），不是“发一个包轮着走”这么简单。华三默认的聚合负载分担方式是根据报文的源MAC和目的MAC做异或运算，算出哈希值后映射到某个成员端口上。方向不同分担粒度不同：二层转发看MAC，三层转发看源目IP，四层还可以看源目端口。
这个机制带来一个关键的认知：链路聚合提升的是“多流并发”的总带宽，而不是“单条流”的带宽。比如你从服务器往客户端传一个大文件，这条大流量属于同一条流，哈希只会打在某个固定成员口上，即使聚合了4条物理链路，单流速度也上不去。想提升单流性能，唯一的办法是让应用程序支持多连接并发，或者用基于IP/端口的负载分担让不同连接散出去。
华三设备支持修改负载分担模式，命令在系统视图下配：
link-aggregation load-sharing mode destination-ip按目的IP分担link-aggregation load-sharing mode source-ip按源IP分担link-aggregation load-sharing mode source-mac destination-mac按源目MAC分担
具体选哪种，要看业务模型是“多对一”（监控流量汇聚）还是“一对多”（服务器分发）。我常用的思路：转发模型以服务器为主，就在核心交换机上改成按目的IP分担；以接入交换机收敛为主，就按源目MAC分担。改完要观察一段时间流量分布，别指望哈希一次就完美均匀。
2.4 二层聚合和三层聚合的边界要分清楚
华三的Bridge-Aggregation接口根据配置的链路类型分为二层聚合和三层聚合。二层聚合口需要和成员口一起配置PVID、Trunk、Hybrid属性，业务流量按普通二层转发；三层聚合口直接给BAGG接口配IP地址，做路由口用，常用于交换机之间的三层互联、VRRP上行口等场景。
二层转三层或者三层转二层，不能直接敲命令改，必须先把聚合口undo掉重新创建。这个坑不少人在开局配置时踩过：建了BAGG 1做二层Trunk，后来想改成三层互联，直接在上面配IP提示错误，原因就是接口类型没变。所以开局就要规划好：这个聚合口是走二层还是三层，不要图省事后面硬改。
3. 手把手实操：从登录到命令交付的完整流程
3.1 登录设备与现状摸底
配置链路聚合之前，先花五分钟做现状摸底，能省掉后面一半的排障时间。登录方式不展开说了，Console线、Telnet、SSH都行。重点是四条命令：
<H3C> system-view [H3C] display interface brief [H3C] display stp brief [H3C] display vlan第一条看接口的物理状态和速率，第二条看生成树状态（避免聚合后STP产生阻塞同时心里有数），第三条看VLAN规划。这个阶段重点确认几点：物理光口/电口的速率双工是否一致、对端设备型号和接口编号、业务VLAN范围。我习惯把这些信息记在草稿纸上，配的时候对照着来，不容易错。
3.2 静态链路聚合配置全流程
华三默认V7版本里，创建聚合口后，聚合口默认就是静态模式，不需要额外敲模式命令。下面是完整配置示例，以一个核心交换机上联另一个交换机为例：
<H3C> system-view # 创建二层聚合口 [H3C] interface Bridge-Aggregation 1 [H3C-Bridge-Aggregation1] port link-type trunk [H3C-Bridge-Aggregation1] port trunk permit vlan 10 20 30 [H3C-Bridge-Aggregation1] quit # 把GigabitEthernet1/0/1加入聚合组1 [H3C] interface GigabitEthernet1/0/1 [H3C-GigabitEthernet1/0/1] port link-aggregation group 1 [H3C-GigabitEthernet1/0/1] quit # 把GigabitEthernet1/0/2加入聚合组1 [H3C] interface GigabitEthernet1/0/2 [H3C-GigabitEthernet1/0/2] port link-aggregation group 1 [H3C-GigabitEthernet1/0/2] quit这里强调一个细节：成员口加入聚合组后，物理口上的VLAN、Trunk、Hybrid配置全部失效，统一以聚合口配置为准。所以你不需要也不应该在物理口上再敲port link-type trunk之类的命令，配了也没用，还容易让人误解。
要检查静态聚合是否生效，最核心的验证命令是：
<H3C> display link-aggregation summary输出结果里会看到聚合组1，成员端口GigabitEthernet1/0/1和1/0/2状态如果都是Selected，说明聚合成功，带宽已经逻辑合并。如果状态是Unselected，基本就是速率/双工不一致或对端未配置。
3.3 动态LACP聚合配置全流程
动态聚合在我这边的生产网里使用率更高。相比静态聚合，多一步配置：在聚合口上开启LACP模式。命令如下：
<H3C> system-view # 开启动态LACP聚合模式 [H3C] interface Bridge-Aggregation 1 [H3C-Bridge-Aggregation1] link-aggregation mode dynamic [H3C-Bridge-Aggregation1] port link-type trunk [H3C-Bridge-Aggregation1] port trunk permit vlan 10 20 30 [H3C-Bridge-Aggregation1] quit # 成员口加入聚合组 [H3C] interface GigabitEthernet1/0/1 [H3C-GigabitEthernet1/0/1] port link-aggregation group 1 [H3C-GigabitEthernet1/0/1] quit [H3C] interface GigabitEthernet1/0/2 [H3C-GigabitEthernet1/0/2] port link-aggregation group 1 [H3C-GigabitEthernet1/0/2] quit如果链路两侧都是华三，到这里就完成了。验证命令一样用display link-aggregation summary，但对端必须也启用LACP并且优先级一致，否则协商不会通过，聚合口状态可能是Down的。
动态LACP模式下还可以调整系统LACP优先级，用于决定哪一端作为协商主导方：
[H3C] lacp system-priority 100一般情况下默认值就够用，只有两端设备型号差异特别大、协商出问题时，才需要改这一项。我不建议新手随便改优先级，改错了反而容易把正常链路搞僵。
3.4 配置下发后必须做的三项验证
配置敲完不验证等于白干。我每次交付链路聚合配置，固定跑三遍验证：
- 聚合组状态验证：
display link-aggregation summary，确认Selected端口数目和预期一致。如果做了4条聚合，这里应该全部Selected，少一个都要查。 - 业务转发验证：在两端接入的服务器或终端之间持续ping，同时拔掉一根物理网线观察丢包时间。正确的行为是：断线瞬间有一两秒丢包甚至不丢包，随后业务自动恢复；如果一直丢包，说明聚合没真生效或者STP在捣乱。
- 流量分担观察：
display link-aggregation load-sharing mode确认分担模式；有条件的话登录对端设备、或者用流量监控工具看各成员口的流量计数，确认两条线都在跑流量，而不是只有一条满载。
这里提醒一句，v7版本下查看流量计数我习惯用：
<H3C> display interface GigabitEthernet1/0/1看Input/Output方向的速率和总字节数，两根线的计数如果都往上涨，说明流量在分担，如果只有一根涨，别急着下结论，先看是不是单流传输导致的（前面讲过哈希的局限）。
4. 真实场景拆解：核心交换机与服务器、跨厂商设备怎么对接
4.1 服务器双网卡聚合的配合姿势
这个场景太常见了：服务器两块千兆网卡想聚合，交换机侧就是一台华三层交换机。华三侧配置和前面一样，关键是服务器侧的模式要对上：
| 服务器bond模式 | 交换机侧要求 | 适用场景 |
|---|---|---|
| Linux mode 0 (round-robin) | 静态聚合 | 均衡但兼容性差，不建议生产 |
| Linux mode 1 (active-backup) | 不需要聚合，普通access口即可 | 冗余为主，带宽不叠加 |
| Linux mode 2 (xor) | 静态聚合 | 按哈希分担，交换机必须配聚合 |
| Linux mode 4 (lacp) | 动态LACP聚合 | 标准推荐，生产首选 |
| Windows NIC Teaming (LACP) | 动态LACP聚合 | 与Linux mode 4同理 |
以Linux服务器为例，最常见的生产配置是动态LACP（balance-alb或802.3ad）。操作分两步：
第一步，配置交换机：
[H3C] interface Bridge-Aggregation 10 [H3C-Bridge-Aggregation10] link-aggregation mode dynamic [H3C-Bridge-Aggregation10] port link-type access [H3C-Bridge-Aggregation10] port access vlan 100 [H3C-Bridge-Aggregation10] quit [H3C] interface GigabitEthernet1/0/24 [H3C-GigabitEthernet1/0/24] port link-aggregation group 10 [H3C-GigabitEthernet1/0/24] quit第二步，Linux侧加载bonding模块并配置。以RHEL/CentOS系为例，使用nmcli最直观：
nmcli con add type bond ifname bond0 mode 802.3ad ipv4.method manual ipv4.addresses 192.168.100.10/24 ipv4.gateway 192.168.100.1 nmcli con add type ethernet ifname eth0 master bond0 nmcli con add type ethernet ifname eth1 master bond0 nmcli con up bond0这里有个容易踩的坑：服务器bond的LACP模式虽然标准，但Linux内核默认的发送速度不是立即协商，有时要等几秒到十几秒聚合才up。如果交换机侧配了STP边缘端口（portfast等价物，华三对应的是stp edged-port enable），这个等待时间会大大缩短。很多运维在机房插线后看服务器网络起不来，其实是LACP还在协商，等一会儿就好，不是配置错了。
4.2 与华为、锐捷等跨厂商设备对接的坑
链路聚合在跨厂商对接时，踩坑概率比同品牌对接高不少。华为交换机的链路聚合口叫Eth-Trunk，锐捷叫AP口或Aggregate Port，虽然概念一样，但命令和默认行为有差异。
跨厂商对接，最重要的原则：把动态聚合和静态聚合明确分开。两边都用动态LACP时，LACP协议是标准IEEE 802.3ad，通常能协商成功。两边都用静态聚合时，没有协商过程，只要成员口都加入聚合组，链路就up，简单粗暴但也好使。最怕的是本端动态、对端静态，这种配下去聚合组永远起不来。
拿华为对接华三举例子，华为侧配置示意：
<HUAWEI> system-view [HUAWEI] interface Eth-Trunk 1 [HUAWEI-Eth-Trunk1] mode lacp-static [HUAWEI-Eth-Trunk1] trunkport GigabitEthernet0/0/1 [HUAWEI-Eth-Trunk1] trunkport GigabitEthernet0/0/2 [HUAWEI-Eth-Trunk1] port link-type trunk [HUAWEI-Eth-Trunk1] port trunk allow-pass vlan 10 20华三侧只要对应开启动态LACP即可。如果你发现两边模式都对了还是协商不起来，重点检查两端聚合组的VLAN配置是否一致、Trunk放行VID是否一致，以及光模块是否兼容（这个在跨厂商对接里经常出幺蛾子，华三和华为都习惯用自家模块，混着插有时候光功率不够导致物理口频繁UP/DOWN）。
锐捷的接口命名和华三比较像，聚合口叫AggregatePort，接入成员口命令是port-group 1，模式上锐捷默认是静态。对接的时候注意模式翻译成同一套逻辑，别被界面上的术语搞晕。
4.3 办公网改造：5个VLAN部门子网的聚合实战
再举个例子，之前做过一次办公网改造：公司5个部门划了5个子网，A部门100台主机、B部门50台、C部门20台，业务VLAN 10/20/30/40/50，核心换成了华三S5500系列，下联汇聚交换机之间用两根千兆光路做聚合。这个场景有一个隐藏需求：链路聚合不仅要通，还要保证不同VLAN之间互访不因聚合哈希不均导致某个VLAN流量挤占。
我当时的配置思路是：核心和汇聚两端都做动态LACP聚合，Trunk放行全部业务VLAN，负载分担模式改成按源目IP分担，因为跨VLAN互访多半是三层流，按IP分担才能让5个VLAN的流量均匀散到两根物理链路上。
# 核心交换机侧 [H3C] interface Bridge-Aggregation 1 [H3C-Bridge-Aggregation1] link-aggregation mode dynamic [H3C-Bridge-Aggregation1] port link-type trunk [H3C-Bridge-Aggregation1] port trunk permit vlan 10 20 30 40 50 [H3C-Bridge-Aggregation1] quit [H3C] link-aggregation load-sharing mode source-ip destination-ip [H3C] interface GigabitEthernet1/0/25 [H3C-GigabitEthernet1/0/25] port link-aggregation group 1 [H3C-GigabitEthernet1/0/25] quit [H3C] interface GigabitEthernet1/0/26 [H3C-GigabitEthernet1/0/26] port link-aggregation group 1 [H3C-GigabitEthernet1/0/26] quit汇聚交换机侧配置完全镜像。配置完检查display link-aggregation summary时发现一个问题：两条物理链路都Selected了，但用华三的display link-aggregation load-sharing mode看分担模式发现核心侧已经被我改成IP分担，汇聚侧还是默认的MAC分担。华三的动态聚合要求两端分担模式尽量一致，否则哈希结果不一致，会出现流量在本端被分到1口、对端回包分到2口的情况，虽然同一条流最终也能走通，但来回路径不对称，延迟和丢包率会变难看。所以注意：负载分担模式在聚合链路两端都要设置，不是只改一端。
5. 常见问题与排障实录：我踩过的那些坑
5.1 聚合口就是不UP，先查这四个点
链路聚合配完发现聚合口Down，不要慌，按优先级排查：
- 物理口状态。
display interface brief先看光口/电口是否物理UP，光模块松了、光纤收发接反了、对端设备没开电源，这些“低级问题”占了故障原因的一半以上。 - 成员口是否真的加入了聚合组。
display link-aggregation summary看聚合组里有没有成员，或者成员口是不是处于独立状态。很多人配完发现成员口上少敲了一句port link-aggregation group 1，导致物理口独立转发，和聚合口形成二层环路或者干脆不通。 - 两端模式是否一致。静态对静态、动态对动态，这中间最容易出的岔子是从华三设备往华为对接时，华为Eth-Trunk默认模式是静态，华三侧配了动态，两边没有协商。解决办法是统一两边模式。
- 两端VLAN配置是否一致。聚合口Trunk放行的VID集合要一致，PVID最好也一致。不一致时LACP协商可能正常，但业务VLAN不通，很多人误以为聚合失败，其实是VLAN清单没对齐。
5.2 带宽上不去，流量全挤在一根线上
这个现象我说一下原理：哈希分配看的是报文特征，不是端口流量实时负载。当聚合组里只有两条链路时，哈希结果落入某一条链路的概率是50%，如果恰好业务流量全部来自同一个源MAC或去往同一个目的IP，比如数据库集群同步日志，那么所有流量哈希到同一个成员口，另一根线完全空闲。遇到这种问题，先确认是不是单流场景，然后看现有分担模式能不能适配业务模型。如果业务本身就是“多对一”收敛（比如多台办公电脑访问一台文件服务器），那单靠哈希很可能不均，建议把分担模式改成按源MAC，让不同终端散到不同物理链路，效果立竿见影。
另外要提醒：万兆以太网聚合后的实际吞吐还受交换机背板、缓存、CPU转发能力的限制，如果设备本身是低端接入型号，即使聚了4条万兆口，实际线速也达不到全部叠加。别拿小交换机硬扛大流量。
5.3 断线闪断之后聚合起不来
这个坑我碰到过不止一次：拔掉一根线测试冗余，结果业务彻底中断了，聚合组再也起不来。后面排查发现，问题出在对端设备上——对端交换机侧某根光路物理DOWN之后，LACP收不到对端LACPDU，于是本端把对应端口置为Unselected，这是正常的。但恢复链路后，如果光模块协商速度慢，两端LACP协商超时，聚合组迟迟不恢复，期间业务就断了。
解决方案是把LACP超时时间调短，让协商更快恢复：
[H3C] interface Bridge-Aggregation 1 [H3C-Bridge-Aggregation1] lacp period shortlacp period short让LACPPDU每1秒发一次，检测故障更快；默认是长超时30秒。在核心链路上我会开short，牺牲一点点CPU开销换切换速度，非常划算。
5.4 华三模拟器复现与验证引入
没有现成真机的时候，用华三官方模拟器HCL（H3C Cloud Lab）可以在虚拟环境里把链路聚合配一遍。有个使用细节：HCL里部分老镜像对LACP支持不太好，设备启动失败也常见。我的经验是选新版本镜像，配置过程和真机几乎一致，用于练命令和验证逻辑足够。
模拟器里复现静态聚合、动态聚合、确认link-aggregation summary的展示格式，至少让你在真机操作前不慌。不过模拟器里没法验证Optical模块、线缆质量问题，所以排障经验还是得靠真机积累，模拟器只是“练手和预演”的定位。
5.5 一个隐蔽问题：生成树与聚合的相互作用
华三交换机默认开启STP，链路聚合口上STP和LACP之间可能会有微妙冲突。比如成员口如果之前单独跑过STP，可能在端口状态上残留了Blocking，加入聚合组后状态更新不及时，导致流量不走这个口。
我通常的处理方法：对下联服务器的聚合口开启边缘端口stp edged-port enable，让端口快速进入转发状态；对上联交换机之间的聚合口，保持STP正常参与，但确认聚合口本身不会因为某条成员口的变化频繁触发STP重收敛。如果发现拔一根线导致整个聚合口RSTP拓扑变更，可以检查display stp brief看聚合口状态，必要时调整STP优先级或启用收敛优化。
6. 避坑指南与个人体会
链路聚合这个技术，说难不算特别难，说简单也不简单，它牵涉到端口状态机、协商协议、VLAN转发、哈希负载分担等多个层面，任何一个环节出问题，最终表现都是“业务不通”或“带宽不达标”。在这里把最后几点个人经验写出来，希望能帮你少走弯路。
第一，配置前一定画一张拓扑草图，标明设备型号、接口编号、聚合口编号、模式、VLAN清单。很多人开局不画图，配到一半忘记哪根线接在哪，最后全靠抓瞎。草图不用多专业，自己能看懂就行。
第二，聚合口的编号规划要有规律。我的习惯是：上联核心用BAGG 1-10，下联服务器用BAGG 11-20，跨越多个机房的还要加机柜编号前缀，这样display link-aggregation summary一刷出来就知道哪里在跑什么业务，千万不要一天一个聚合口创建得乱七八糟。
第三，配置和变更一定要留底。改华三配置前先display current-configuration导出整机配置存档，改完再导一份对比。真出了问题，至少能快速回退到变化前的状态。我见过太多人改完没存档，半夜出问题只能靠回忆回滚，那种压力没经历过的人不会懂。
第四，链路聚合部署完成后，一定要在业务低峰期做断线演练。拔一根线、插回去，观察业务是否自动切换、聚合组是否自动恢复，把冗余能力先验证到位。等到故障真正来的时候才测试冗余，那是拿生产环境做赌博。
第五，也是最后一点：链路聚合不是万能的，它无法替代三层路由冗余，无法解决服务器单点故障，更无法解决交换机本身硬件故障。聚合只是网络高可用拼图中的一块，靠谱的网络设计还需要VRRP、堆叠、双上联这些技术配合。做网络别贪多，稳才是王道。