大白帅链路聚合是我处理网络拥塞问题时的第一选择，没有之一。两个多月前，我接手一个小型办公网的故障排查：一到下午高峰期，核心交换机到接入交换机的上联口流量就顶到 90% 以上，员工访问 ERP 系统，延迟从 1ms 一路飙到 200ms，还夹杂着丢包。客户给的条件很直接——不换板卡、不加新设备，先把网络稳住。最后定的方案，就是在两台交换机之间再放一根千兆线，做链路聚合。
链路聚合这个技术，在 H3C 设备上叫 Bridge-Aggregation，在别的厂商那里又叫端口聚合、Eth-Trunk、Port-Channel，名字不同，干的都是同一件事：把两根或更多根物理以太网链路捆绑成一根逻辑链路。带宽提升、链路冗余、故障自动切换，这三件事它都能干。下面就从原理、配置、负载分担、排障四个维度，把 H3CNE 链路聚合这个知识点掰开揉碎讲清楚。不管你是备考 H3CNE，还是要给现网做链路扩容，都能直接用。
1. 链路聚合解决的三个现实问题：带宽、冗余、成本
先说我那个案例。24 口接入交换机，底下接了三十多台终端和一个 NAS，单根千兆上联白天还能扛，下午一开会、一备份，流量立刻顶满。当时摆在我面前的选择有三个：换万兆上联，要换光模块、换尾纤，预算直接大几千；加一根千兆线但什么都不配，等于多了两条平行链路，不做 STP 处理必然出环路；加一根千兆线并配置链路聚合，总带宽变成 2G，成本只是一根网线。第三个方案自然胜出，客户要求的"不换板卡、不加设备"也满足了。
1.1 聚合带宽怎么算：理想值不等于单流值
一个聚合组的逻辑带宽，理想情况下等于所有 Selected 状态成员链路带宽之和。两根千兆变成 2G，四根千兆变成 4G，物理上就是这么朴素。但这里有个前提条件特别容易被忽略：只有不同流的报文才能被分摊到不同成员链路上，同一个流（同一个五元组，或者根据哈希因子确定的键值）的报文，会固定走同一条物理链路。所以"聚合之后单条 TCP 下载速度翻倍"是个误区，单条流跑不满聚合带宽，这个我在第 4 节会专门展开。理解了这一点，就不会在客户面前说出"配了聚合带宽一定翻倍"这种外行话。
1.2 冗余和故障切换：为什么比 STP 快
在没有聚合的情况下，同一对交换机之间接两根线，STP 必然阻塞其中一个口。链路故障后要等 STP 重新收敛，传统 STP 收敛几十秒很正常，RSTP 能到秒级，但对业务来说已经是灾难。做了聚合之后，这两根线在 STP 看来只是一个逻辑口，不存在冗余路径的环路问题，某个成员口 down 掉，交换机会自动把流量哈希到剩下的成员口上，不需要 STP 重新计算，切换时间基本在秒级以内。这就是为什么核心到汇聚、汇聚到接入的互联链路，绝大部分都会用聚合，而不是让两根线裸奔、赌 STP 收敛够快。
1.3 在 H3CNE 知识体系里的前后关系
H3CNE 的链路聚合，在知识编排上一般排在职以太网交换技术部分，和 VLAN、STP 放在一个大的二层技术框架里。考试重点高度集中在五个方向：静态聚合和动态聚合的差异、成员端口的一致性条件、LACP 选举规则、负载分担的哈希因子、display 系列验证命令。这些考点不是孤立的理论，每一个都对应一个真实的故障场景。第 5 节我会把这些故障场景串起来讲，你会发现考试题本质上就是实战排障的书面化。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 聚合的底层机制：逻辑接口、成员端口、LACP 协商
2.1 Bridge-Aggregation 逻辑接口是什么
在 H3C 设备上做聚合，第一步是创建一个逻辑接口：二层场景叫 Bridge-Aggregation 口，设备上通常显示为 BAGG1；三层场景叫 Route-Aggregation 口。所有关于 VLAN、链路类型、QoS 的配置都做在这个逻辑接口上，成员物理口只负责一件事——加入这个组。成员口加入聚合组后，会继承聚合接口的配置，所以业界一直强调"先配聚合口，再加成员口"，顺序反了就容易出现成员口配置互相覆盖、踢来踢去的诡异问题。
这里顺便说一个很多人混淆的点：链路聚合是设备与设备之间的链路捆绑，IRF 是设备虚拟化。如果想把两台交换机之间的多条链路做跨设备聚合，你得先用 IRF 把两台设备虚拟成一台，再在这个逻辑设备上创建聚合口，这是另一个话题。日常运维里听到有人说"跨设备聚合"，多半指的就是 IRF + 聚合的联动方案。
2.2 静态聚合和动态聚合怎么选
H3C 的聚合模式分为静态和动态，两者最核心的区别就是有没有协商机制。我直接用一张表把差异列清楚：
| 对比项 | 静态聚合 | 动态聚合 |
|---|---|---|
| 协商协议 | 无 | LACP（IEEE 802.3ad） |
| 两端配置要求 | 必须手工完全一致 | 依靠 LACPDU 协商，一端 active 即可发起 |
| 成员口状态 | 物理 up 即 Selected | 协商成功才 Selected，否则 Unselected |
| 防环路能力 | 弱，对端未配置聚合时可能成环 | 强，协商失败端口不转发数据 |
| 适用建议 | 中间设备无法透传 LACP 的场景 | 默认首选 |
LACPDU 使用的是保留组播地址 01-80-c2-00-00-02，这是一个被交换机关留的组播地址，普通二层交换机默认不会转发它。这意味着如果两台设备中间还隔着一台普通交换机或者某种传输设备，LACP 报文不一定能穿过中间路径，这时候动态聚合可能协商不起来。实际工程里如果遇到这种情况，要么改成静态聚合，要么确认中间设备支持 LACP 报文透传，否则聚合组会一直处于"建不起来"的状态。
2.3 LACP 怎么决定哪个成员口干活
动态聚合里，并不是所有成员口都转发数据。两端先进行选举，选出来的口叫 Selected 口，负责实际转发，其余口叫 Unselected 口，处于待命状态。选举规则说起来不复杂：
- 两端设备先比 LACP 系统优先级，默认 32768，数值越小越优。
- 系统优先级相同，比系统 MAC 地址，MAC 小的获胜。
- 获胜端设备内部，成员口之间比端口优先级，默认 32768，数值越小越优。
- 端口优先级也相同，比端口编号，编号小的优先。
按这个顺序排下来，前 N 个端口进入 Selected 状态，N 取决于聚合组允许的最大活跃端口数。你还可以主动控制活跃数量，比如 4 个成员口只让 2 个转发、2 个待命，用 selected-port maximum/minimum 这组参数（不同型号命令存在差异，以设备帮助为准）。这个特性在做服务器双网卡 teaming 的时候非常实用，相当于给服务器做了一个 2 用 2 备的链路冗余池。
3. 手把手配置：两台交换机做链路聚合（附验证命令）
3.1 动手前必须过的检查清单
配置命令本身很短，但真正容易出问题的都在配置之前。我给自己的规矩是，动手前先把下面五个条件过一遍，少一个后面都要返工：
- 成员口物理状态必须 up，光模块类型和速率一致。同一个聚合组里混 100M 和 1000M 是无效的，硬件层面就不认。
- 成员口的双工模式要一致，建议都保持自协商，不要一个强制全双工、一个自动协商。
- 成员口的链路类型要一致，access、trunk、hybrid 不能混用。
- 成员口的 untagged VLAN 集合和 tagged VLAN 集合要一致，这是 LACP 协商失败最常见的原因。
- 成员口不能已经属于别的聚合组，也不能是镜像目的口、IRF 物理口等特殊角色。
3.2 配置过程：先建逻辑口，再加成员口
拿最典型的两台交换机 SW1、SW2 互连做例子，分别用 GE1/0/1 和 GE1/0/2 两根线做动态聚合。先在 SW1 上建聚合口：
code复制system-view
sysname SW1
interface Bridge-Aggregation 1
link-aggregation mode dynamic
quit
注意，如果不敲 link-aggregation mode dynamic，默认创建出来的是静态聚合。我所有新项目里默认都用动态聚合，理由就是第 2 节说的"协商失败不转发"，安全得多。接着添加成员口：
code复制interface GigabitEthernet 1/0/1
port link-aggregation group 1
quit
interface GigabitEthernet 1/0/2
port link-aggregation group 1
quit
成员口多的时候，可以用 interface range 批量操作。然后，把业务配置放到聚合口上，注意不是在成员口上逐个配：
code复制interface Bridge-Aggregation 1
port link-type trunk
port trunk permit vlan all
SW2 上执行一模一样的配置。等两边 LACPDU 协商完成，聚合组就会进入 Selected 状态。三层互联的原理完全一样，逻辑接口换成 Route-Aggregation，在上面配 IP 地址，成员口同样用 port link-aggregation group 1，这里不展开。
3.3 验证命令怎么读
配置完别急着收工，先看状态。最核心的是这条：
code复制display link-aggregation summary
输出重点看几列：Ports 表示组成员总数，Selected 表示当前真正在转发的端口数，Unselected 表示协商失败或超限的端口数。正常情况下 Selected 应该等于你期望的活跃成员数。如果出现 Unselected 甚至 Individual（个别口脱离聚合独立工作），优先排查物理链路、两端聚合模式、VLAN 配置三个方向。
再看细一点，用下面几条命令辅助判断：
| 命令 | 作用 |
|---|---|
| display link-aggregation summary | 查看聚合组概要、端口状态 |
| display link-aggregation verbose | 查看 LACP 选举和 actor/partner 详细信息 |
| display lacp statistics | 查看 LACPDU 收发统计 |
| display interface brief | 查看成员口物理状态和流量计数 |
lacp statistics 如果长时间只显示发出、不显示收到，基本可以断定对端没配置动态聚合，或者 LACP 报文被中间链路丢了。这个判断在真机和模拟器上都通用。
3.4 在 HCL 模拟器里做实验要注意什么
H3C HCL（云实验室）里做链路聚合实验，命令跟真机基本一致，BAGG 口、LACP 协商状态都能正常显示。但我实测的经验是，模拟器对哈希负载分担的实际转发行为不会像真机那么直观，你想验证"流量到底怎么分的"，最好找两台真机，或者在模拟器里用各成员口的报文计数间接判断。另外，HCL 不同镜像的 Comware 版本不一样，有的偏 V7 风格，有的还残留 V5 的痕迹，敲命令时多按问号看帮助，比死记硬背靠谱。
4. 负载分担：哈希算法决定了流量走哪条路
4.1 为什么必须按"流"而不是按"包"分担
链路聚合在转发面上的核心算法只有两个字：哈希。交换机提取报文的某些字段，做一次哈希运算，把结果映射到聚合组里的某一个成员口。这里必须反复强调，流是哈希的最小单位——同一个流的所有报文哈希值相同，走同一个成员口。如果按包轮流发，同一个 TCP 连接的报文被拆到两条物理链路上，链路的时延和缓存状态不完全一样，报文就会乱序，TCP 因为乱序疯狂重传，吞吐量直接崩掉。所以硬件上基本都是按流哈希，宁可单个流不加速，也不能把整条连接搞乱。
4.2 哈希因子：你可以自己指定
H3C 默认的哈希因子和型号有关，常见策略是：二层报文看源 MAC 和目的 MAC，三层报文看源 IP 和目的 IP，更细的四层端口号参与与否要看具体型号和配置。如果默认分布不满意，可以在聚合接口下面改。例如希望按 IP 组合做分担：
code复制interface Bridge-Aggregation 1
link-aggregation load-sharing mode source-ip destination-ip
部分型号支持全局配置 load-sharing 模式。做数据中心或服务器接入时，我一般根据业务报文特征选因子：跨网段的南北向流量，源目 IP 是关键；东西向二层流量，源目 MAC 更有效；如果业务里长连接特别多且源目 IP 都很集中，要确认设备是否支持把四层端口号加进哈希因子。没有一种因子是万能的，得看你的流量模型。
4.3 单条大流量会话为什么跑不满聚合带宽
这是我被问到最多的问题。客户配了 4 条千兆聚合，逻辑带宽 4G，然后一条 FTP 大文件下载，实测还是 1G 左右，马上来投诉"聚合没用"。原因特别简单：FTP 下载就一个 TCP 连接，源 IP、目的 IP、源端口、目的端口全部固定，哈希结果只有一个，它永远落在同一个成员口上，带宽自然被单链路限制。想让聚合带宽真正被吃满，要么同时开多个会话——多线程下载、多路请求，要么在应用层做并发分发。这不是设备故障，是哈希分担机制本身的数学约束，提前跟客户讲清楚，能省掉无数售后电话。
5. 实战翻车现场：链路聚合最容易踩的四个坑
5.1 静态聚合一边没配齐，广播风暴差点炸机房
我在一次割接里遇到过这么个事：两台接入交换机做两根千兆聚合，A 端我把静态聚合配置好了，B 端同事说"线插上就行"，结果对端压根没配聚合。静态聚合没有协商机制，A 端的两个口都处于 Selected 状态，会同时转发数据；B 端看到的是两条独立链路，如果此时 STP 没起来，或者被同事"嫌麻烦"关掉了，广播帧就会在两根线之间来回循环，广播风暴直接把两台设备的 CPU 全部打满。从那以后我给自己定了个规矩：默认只用动态聚合，没有充分理由不用静态。就算必须用静态，也会先确认对端配置完全一致，并且全程保持 STP 开启兜底。
5.2 成员口 VLAN 不一致，LACP 协商半天选不上
另一个高频坑是 VLAN 配置不一致。比如 B 端交换机的 GE1/0/1 是 access vlan 10，GE1/0/2 是 access vlan 20，你把这两个口都加进同一个聚合组。物理上两根线都 up，但 LACP 一协商就会发现两边的 untagged VLAN 集合对不上，结果其中一个口始终是 Unselected。查这类问题，先看 display link-aggregation summary 里哪个口不是 Selected，再去 display link-aggregation verbose 里对比两端的 actor/partner 信息，基本一眼就能定位。处理办法也很简单：先把聚合接口的 VLAN 配置统一，再考虑加成员口。
5.3 光模块和光纤问题让聚合组"只剩一根线"
用光口做聚合时，成员口是否 up 非常受光模块质量影响。不同厂商光模块混插、光纤跳线衰耗过大，都会让某个口反复 down。聚合组不会因为一个成员口 down 就整体挂掉，它会自动把流量哈希到剩余成员口上，但如果你只有两根线，一根 down 就意味着逻辑带宽直接砍半，业务一定会有感知。所以我在做光口聚合之前，习惯先把每个物理口单独跑一遍流量测试，确认光模块工作正常、链路质量达标，再去做聚合配置。顺序反了，等客户报障再排查，成本就高了。
5.4 流量分布不均：哈希冲突不是玄学
哈希均匀吗？理论上有随机性，实际经常不均匀。我见过最夸张的案例：聚合组 4 根线，流量全压在一个口上，另外三个口几乎空闲。原因是业务里某个源 IP 占了绝大部分流量，哈希因子又只看源 IP，所有流都撞到同一个成员口。解决办法是调整哈希因子，让参与计算的字段更分散，比如改成源目 IP 一起算；如果业务模型实在单一，也可以考虑把不同业务挂到不同聚合组。养成习惯：聚合配完之后，用 display interface brief 看一眼每个成员口的流量计数，别等客户告诉你网又卡了才知道去查。
6. 把链路聚合的知识收进 H3CNE 应试框架
6.1 考点地图：哪些是选择题的常客
从我备考和带人备考的经验看，H3CNE 链路聚合这部分，考题高度集中在几个方向：一是概念，链路聚合的作用、聚合组和成员口的关系；二是模式对比，静态和动态各自的特点，哪个依赖 LACP；三是成员口加入条件，速率、双工、VLAN 一致性；四是 LACP 选举，系统优先级和端口优先级的比较顺序；五是验证命令，display link-aggregation summary 里各种状态的含义。这些考点全部是"原理理解加命令识记"的组合，没有一个是死记硬背能躲过去的，所以你哪怕只做实验不刷题，理解到位了也能蒙对大半。
6.2 判断题的常见陷阱
刷题时我总结了几类典型陷阱，看到基本可以秒选：
- "聚合后每条流的带宽都会翻倍"——错。单流受哈希约束，跑不满聚合带宽。
- "静态聚合不需要协商，所以更安全"——错。静态聚合在对端配置不一致时反而容易成环。
- "动态聚合使用的是 LACP 协议"——对。
- "参与聚合的成员口速率必须一致"——对。速率不一致的端口不会被选为 Selected。
- "LACP 系统优先级默认 32768，数值越小越优先"——对。
这些陷阱其实都是从实战故障里提炼出来的，你把第 5 节的四个坑看明白了，这些题都是送分题。
6.3 考试和实验如何互相验证
H3CNE 是笔试，但别把它当纯理论学。我的做法是每学完一章，就在 HCL 里把实验做一遍，然后合上实验指导书，凭记忆敲命令、做验证。链路聚合这个实验尤其值得反复做，因为它的故障现象非常典型：Selected=0 先查物理层，Unselected>0 先查两端模式和 VLAN，Individual 出现就查成员口上是不是有不支持的配置。这套排查链路在真机上同样成立。
最后补一个我自己的习惯：任何一次链路聚合割接完成后，不要急着收工，用 display link-aggregation summary 和 display interface brief 把状态、每个成员口的流量都截个图存档。后面一旦出问题，这些截图就是排障的第一手资料，比任何回忆都靠谱。链路聚合这个技术看着简单，真正值钱的是你对它底层机制的理解和排障时的那份冷静。