H3C三层聚合配置详解：从原理到排错

华三交换机上的三层聚合配置，其实没那么玄乎，但翻车的人真不少。前阵子一个朋友找我排障：核心到汇聚之间明明做了链路聚合配置，带宽却始终只走一条线，另一条链路闲得发慌。登上去一看，聚合组、端口模式、IP地址全对，最后定位到是哈希因子设置不合理，两条物理口的流量分布完全偏向一边。这种问题在链路聚合配置里太典型了，尤其三层聚合，因为它和二层聚合虽然命令上只差一个接口类型，但背后的协商逻辑、适用场景、排错思路完全是两码事。

这篇文章不打算只给你甩命令，我会把三层聚合从原理、选型、配置到排错、调优讲透。适合正准备做核心-汇聚三层互联的网工，也适合考H3C认证、用HCL模拟器做综合实验的学生。看完你能明白为什么两条物理链路不能直接配IP，为什么动态聚合比静态聚合更稳，以及带宽没跑满时该从哪几个方向查。

1. 三层聚合到底解决了什么问题

1.1 二层聚合与三层聚合的分工

H3C交换机上，二层聚合接口叫Bridge-Aggregation，三层聚合接口叫Route-Aggregation。很多人第一次听到“三层聚合”会懵：聚合接口还能分二三层？其实不奇怪。Bridge-Aggregation是一个二层逻辑口，你只能在上面做trunk、access、放通VLAN，它本身没有IP，想要三层互通就得再建一个Vlan-interface绑定到它上边。而Route-Aggregation天生就是一个路由口，创建后直接就能配IP，物理成员口加入后，整个捆绑体作为一条三层链路参与路由转发。

这两种接口对应的场景差异很大。下层接入交换机做端口捆绑，把多台服务器接入到交换机，或者把接入交换机上联到汇聚交换机，通常用二层聚合，因为走的是VLAN trunk。而核心交换机与汇聚交换机之间的互联、汇聚与防火墙之间的互联，通常走三层路由，这时候就需要在三层聚合口上配地址，用Route-Aggregation。记住这个分界线，后面配置时就不会犯“建了Bridge-Aggregation却想直接配IP”的错。

1.2 三层聚合解决的三个痛点

三层聚合本质上是把多条物理链路抽象成一条逻辑路由链路，解决的核心问题有三个。第一个是带宽扩展。两条千兆口捆绑后，理论上能承载接近2Gbps的吞吐，注意我说的是“接近”，不是简单的1+1=2，具体原因后边会讲。第二个是链路冗余。一条成员口断了，流量自动切到剩下那条，聚合口本身不会down，对路由协议和上层业务完全透明，这种故障切换比路由收敛快得多，因为不用等路由协议重算。第三个是管理简化。原来需要维护两条物理接口上的IP、策略、ACL，现在全部收敛到一个Route-Aggregation接口上。

这三个痛点放到一张园区网里看，价值非常明显。核心和汇聚之间如果只有一条物理链路，一旦光纤被挖断或者光模块老化，整片区域直接失联；如果配两条物理口各配一个IP，则要面对路由环路和下一跳不确定的问题。用三层聚合，把两条甚至四条光口捆成一个逻辑口，既扩展了带宽，又拿到了冗余，一举两得。

1.3 直接接两根物理链路会怎样

有人会问：我不做聚合，直接在交换机的两个三层口上分别配10.0.0.0/30和10.0.1.0/30两个网段，然后跑动态路由，不是也能用两条链路吗？能用，但问题的复杂度上来了。

首先，你引入了两条不同的三层网段，路由表里会出现两条等价明细路由，流量怎么分配由路由协议选路决定，而路由协议的负载均衡通常是把不同目的地址散到不同下一跳，并不感知链路实时负载，很容易一条链路打满另一条空闲。其次，一旦其中一条链路断了，路由协议需要重新收敛，即使是OSPF这种收敛快的协议，也要等Hello超时，一般要几十秒，业务早就中断了。再者，万一中间设备配了冗余网关或者出现了物理环路，三层口的ARP表和路由表可能震荡，故障定位难度成倍增加。三层聚合把这些复杂性全部收进了设备内部，由聚合模块统一协商、统一选路、统一切换，对上层路由协议来说，它只看到一个稳定存在的接口。

2. 配置前必须想清楚的四个决定

2.1 静态聚合还是动态LACP

H3C的聚合分为静态聚合和动态聚合两种。静态聚合不跑协议，两端设备靠手工把物理口加进聚合组，逻辑上认为它们是一条链路。动态聚合则启用LACP协议，成员口通过交换LACPDU报文来协商选中哪些端口。

实际组网里，H3C设备之间的三层互联，我基本无脑推荐动态聚合。原因很直接：动态聚合有协议协商机制，对端状态、链路质量、两端配置是否匹配都能通过LACPDU体现出来，某条链路有问题时，端口会自动被置为Unselected，不会把坏链路纳入转发。静态聚合则全靠人工保证两端配置一致，端口接错了、对端没加组、速率不匹配，这些问题设备不会主动告诉你，表现出来就是业务不通，非常难查。

不过静态聚合也不是一无是处。有些老设备、防火墙、路由器不支持LACP，或者只支持静态捆绑，那你就只能迁就它用静态。跨厂商对接时尤其要注意，先确认对端支持哪种模式，再决定自己这边怎么配。如果一端动态一端静态，协商大概率失败，表现为端口迟迟选不中。

2.2 成员口怎么选

选成员口看起来是小事，却直接决定聚合链路稳不稳。我的习惯是优先选同一板卡上连续编号的端口，速率、双工、光模块类型保持一致。比如用GigabitEthernet1/0/1和GigabitEthernet1/0/2，就不要混搭一个千兆口和一个百兆口。万兆口和千兆口混在一个聚合组里，协商时按最低速率对齐，整个聚合接口的速度会被拉低，白白浪费高速端口。

跨板卡捆绑是另一条路。框式交换机上把成员口分布在两块板卡上，即使一块板卡整板故障，另一块板卡上的成员口还能维持聚合链路存活，这是更高级的冗余设计。但代价是流量哈希可能会受板卡转发芯片影响，做跨板聚合前要确认设备硬件是否支持跨板链路聚合。对于盒式交换机，通常只要保证端口速率类型一致、空闲可用就行。

2.3 负载分担因子怎么定

负载分担因子其实就是哈希因子，决定设备用报文的哪些字段计算哈希，从而把流量散到不同成员口上。三层聚合里常见的因子有源IP、目的IP、源目IP、源目IP+端口等。不同型号默认值不一样，有的默认按源目MAC，有的默认按源目IP，配置前最好用display link-aggregation load-sharing mode查一下当前默认值。

定因子前先想清楚业务流量长什么样。如果业务是客户端访问多台服务器，源IP很多、目的IP也多，用源目IP组合效果通常不错。如果所有流量都访问同一个VIP，目的IP完全相同，那按目的IP哈希必然撞车，这时候应该改成按源IP哈希。如果业务是数据库同步这类单一大流，哈希因子怎么调都很难让两条链路都用上，因为一条TCP流只能走一个成员口。这个决定不要抄模板，要看你的实际流量模型。

2.4 跨厂商对接时的兼容性

三层聚合经常出现在核心和防火墙之间、或跨品牌交换机互联的场景。H3C和华为对接时，两边都支持标准的LACP协议，理论上动态聚合可以互通，但有个坑：LACP的系统优先级和端口优先级如果设置不当，可能造成两端选出的选中端口不一致。举个例子，H3C端选了成员口1和2，华为端却被系统优先级比较高的端口抢占，只选了1，另一条链路变成Unselected，带宽直接减半。

跨厂商对接我一般会先做两步。第一步，把两端的聚合模式都配成动态LACP，这是最稳的。第二步，检查两端的System ID和端口优先级，必要时手动指定优先级，确保双方选口结果一致。如果对端是比较老的第三方设备，不支持LACP，那就老老实实配静态聚合，别逞强。静态聚合跨厂商同样要求两端成员口一一对应，接错线不会有人提醒你。

3. 配置全流程：从物理口到Route-Aggregation的完整命令

3.1 配置前该查什么

千万别上来就敲命令。我会先花两分钟确认设备和端口的现状，这能避免半小时的迷惑。

第一，用display version确认设备软件版本。不同版本对聚合组数量的限制、命令细节会有差异，你拿旧版本的记忆去配新版本，有可能命令直接不识别。第二，用display interface brief看打算捆绑的物理口当前状态和模式。重点是看Mode字段，Comware设备上接口默认可能是二层口，带个二层标志，这样的物理口直接加入Route-Aggregation组会失败，必须先用port link-mode route切成三层口。第三，确认物理口上没有残留配置。有些端口之前当过trunk口，身上带着VLAN配置，切成三层模式后这些配置不清掉，后面会冒出各种奇怪问题。

3.2 静态三层聚合配置

静态三层聚合的配置逻辑一句话：创建Route-Aggregation口，配IP，把物理口切成路由模式，再一个个加入聚合组。以两台华三交换机CORE和LEAF背靠背互联为例，CORE侧的配置如下：

text复制system-view
sysname CORE
interface Route-Aggregation 1
 ip address 10.0.0.1 255.255.255.252
quit
interface GigabitEthernet1/0/1
 port link-mode route
 port link-aggregation group 1
quit
interface GigabitEthernet1/0/2
 port link-mode route
 port link-aggregation group 1
quit

对端LEAF交换机做同样配置，IP地址改成10.0.0.2/30，聚合组号不一定非要一样，本端组1跟对端组2也能对接，因为静态聚合是各管各的，关键是物理线缆两端必须都是加入聚合组的成员口。这里有个细节：部分交换机型号的物理口默认就是路由模式，你执行port link-mode route可能会提示“already in route mode”，这不是报错，跳过就好。

静态聚合创建出来的Route-Aggregation口默认不带link-aggregation mode配置，也就是说它天然就是静态，不需要额外指定。如果你之前在这个接口上配过动态模式，要切回静态，得先undo link-aggregation mode dynamic，然后再把物理口加进来。

3.3 动态三层聚合配置

动态聚合和静态的差别只在聚合口上多了一条link-aggregation mode dynamic命令，以及两端必须都启用LACP。CORE侧配置如下：

text复制system-view
sysname CORE
interface Route-Aggregation 1
 link-aggregation mode dynamic
 ip address 10.0.0.1 255.255.255.252
quit
interface GigabitEthernet1/0/1
 port link-mode route
 port link-aggregation group 1
quit
interface GigabitEthernet1/0/2
 port link-mode route
 port link-aggregation group 1
quit

注意顺序：先把聚合口改成动态模式，配置好IP，再加物理口。如果反过来先加物理口再改模式，部分版本会把已加入的成员口重置，需要重新协商一遍。动态模式下的物理口不需要也不能单独指定LACP模式，聚合口的模式会下发给所有成员口。

我见过不少人在动态聚合上踩一个坑：一边配了动态，另一边配了静态，然后发现物理口状态是UP但聚合口就是起不来，成员口显示Unselected。这就是LACP协商失败的典型症状。动态聚合要求两端模式一致，必须都是dynamic，否则协商报文对不上，永远选不出选中端口。

3.4 验证命令与输出解读

配置完别急着收工，先验证。最常用的命令是display link-aggregation summary，输出里看几个关键字段：

text复制display link-aggregation summary
Aggregation Mode: Dynamic
Loadsharing Type: Shar
Aggregate Interface: Route-Aggregation1
Creation Mode: Manual

然后看成员口状态，重点关注是Selected还是Unselected。Selected表示这个端口被选中参与转发，Unselected表示端口虽然加了组但没被选中，比如LACP协商失败、速率不一致、对端没有对应成员口等。正常情况两个物理口都应该是Selected，聚合接口的状态也应该是UP。

再看接口层，用display interface Route-Aggregation 1确认IP地址是否生效、接口是否up。如果要看成员口的流量统计，用display counters interface GigabitEthernet1/0/1或者display interface brief，确认两条物理链路上都有流量经过，而不是只有一条在跑。动态聚合还可以用display lacp system-id查看本端LACP系统ID，这个ID在跨厂商对接排查时非常有用。

4. 性能与负载分担：为什么带宽没有翻倍

4.1 哈希机制：一条流只能走一条链路

这是链路聚合配置里误解最多的一个点。很多人以为捆了两条千兆口，单次下载就能跑到2Gbps，实际根本不是这么回事。聚合的负载分担粒度是流，不是包。设备根据哈希因子对报文头做计算，把每条流映射到某一个成员口，同一条流的报文永远走同一个成员口，不会拆散。这样设计的目的是保证报文不乱序，TCP和UDP才能正常工作。你想象一下，如果同一个TCP连接的数据包被分到两条物理链路上，网络延迟稍有差异，接收端收到的报文顺序全乱，TCP会疯狂重传，性能反而更差。

所以“带宽翻倍”只在大量并发流同时通过时才能体现。比如几十台客户端同时访问服务器，这些连接被哈希到两条链路上，总吞吐才能接近2Gbps。单个用户下载一个文件，顶多吃掉一条链路的带宽，這是正常现象，不是配置错了。

4.2 怎么判断成员口负载是否均匀

如果怀疑流量分配不均，别猜，直接看计数器。用display interface GigabitEthernet1/0/1查看Input和Output速率，两台设备各看一遍，对比两个成员口的值。如果一条口速率持续很高，另一条长期很低，说明哈希分配有问题。

再看细一点，用display counters outbound interface GigabitEthernet1/0/1查看累计流量，结合一段时间内的增量判断趋势。测试时用一个能打多流的工具，比如iperf3开多个连接，分别从不同源IP或目的IP发起，观察两条链路的速率分布。单流测试跑不满是正常的，但多流测试如果还是一条口满一条口空，那就要考虑调节哈希因子了。

4.3 根据业务调整哈希因子

H3C盒式交换机的负载分担模式一般在系统视图下配置。以常见的S5560系列为例，命令是：

text复制system-view
link-aggregation load-sharing mode destination-ip source-ip

框式设备可能是另一条命令，比如link-aggregation global load-sharing mode destination-ip source-ip，具体以你设备的命令手册为准。配置前先display link-aggregation load-sharing mode看当前生效的默认值，做到心中有数。

选因子的逻辑很简单：找业务五元组里变化最大的字段。举例来说，园区网里大量用户访问一台OA服务器，目的IP都是同一个，哈希因子里就一定要带源IP，否则所有流量哈希到同一个成员口；出口方向访问外网，源IP基本固定（NAT后的地址），目的IP千变万化，那目的IP就比源IP更能打散流量。还有一种情况是端口因素，比如同样一批IP之间跑了很多不同应用端口，把源端口加进哈希因子往往能大幅改善均匀度。

4.4 成员口数量与分布规划

之前说过选两口、四口比较常见，但很多人没想过为什么。哈希算法的映射原理决定了成员口数量越少，单口分到的概率越大，越容易不均；数量多了以后，哈希冲突概率上升，选路结果更难预测。所以并不是口越多越好，工程上我一般建议2到4口足够，特殊高带宽场景才用8口。

还有一个细节：成员口的编号不一定连续，流量哈希是硬件芯片根据算法做的，端口编号连续与否影响不大，但跨板卡时要注意不同板卡的处理能力是否一致。我遇到过一次故障，四口聚合里两块板卡各两个口，其中一块板卡的哈希算法比较弱，实际流量几乎全部压到另一块板卡上，这种问题从配置上看完全是正常的，只能通过观察计数器发现。

5. 排错链路：三层聚合不生效的完整排查流程

5.1 第一步：先看聚合摘要

三层聚合不生效，症状通常是聚合口起不来或者物理口协商一直是Unselected。这时候不要直接看接口配置，先执行display link-aggregation summary，把聚合口和成员口的当前状态一次性看全。

看到聚合状态是UP、成员口两个Selected，说明聚合本身没有问题，问题大概率在路由、IP或对端三层配置。看到聚合口Down或者成员口Unselected，就往下面两步走。这个命令还能看出聚合模式是Dynamic还是Static，如果两端模式不一致，你基本可以锁定了。

5.2 第二步：检查物理层和接口模式

如果成员口状态不对，逐段查物理层。用display interface brief看物理口本身是不是UP，如果物理口就是Down，检查光模块、光纤、对端端口是否启用，这个和聚合没关系，是纯物理问题。

物理口UP了但成员口还是Unselected，就要检查接口模式。三层聚合要求成员口是路由模式，如果某个成员口还是二层模式，它加入聚合组后状态就会异常。用display interface GigabitEthernet1/0/1看Port Mode字段，确认是Route。不是的话，undo掉端口的二层配置，执行port link-mode route，重新加入聚合组。

还要确认两端成员口数量、速率、双工一致。一端捆了2个口，另一端只捆了1个口，能协商成功的只有两端同时物理连接的端口，多余的端口必然Unselected，这是正常现象。如果两端都捆了2个口且物理都通，但只有1个Selected，检查速率和双工设置是否一致。

5.3 第三步：看协议协商与日志

物理层和接口模式都没问题，接下来看LACP协商。动态聚合模式下，用display lacp system-id查看本端LACP系统ID，再用display link-aggregation verbose查看成员口的详细协商状态。正常情况下每个成员口会显示Actor和Partner的协商信息，比如端口状态、优先级、超时时间。如果Partner信息为空或者一直处于Init状态，说明对端没有正常回应LACPDU，要么对端没配动态聚合，要么链路本身有问题。

这时候可以开调试看报文。命令行依次执行terminal debugging、debugging lacp、terminal monitor，然后观察LACPDU的收发情况。排错完记得undo debugging all关掉调试，避免影响设备性能。同时display logbuffer看看有没有聚合口成员口up/down的日志，很多现场问题最后的线索都在日志里。

5.4 几个非常隐蔽的坑

排错经验多了以后，你会发现三层聚合的坑往往不在聚合本身，而在周边的配置。

第一个坑是残留的VLAN配置。物理口原来是二层trunk口，身上带着一堆VLAN配置，执行port link-mode route后VLAN配置理论上应该被清掉，但个别版本里某些配置残留会导致接口加入聚合组后状态异常，最好先undo port link-type、undo port trunk permit vlan all这种命令，再切路由模式。

第二个坑是IP冲突。有人之前给某个物理口配过IP，后来懒得清理，直接把它加进聚合组，再把IP配到Route-Aggregation口上，结果设备上同时存在两个相同网段的接口地址。这种配置表面看聚合口能起，但路由和ARP可能乱掉，业务忽通忽断。

第三个坑是聚合组号不一致导致的误解。前面说过，两端的聚合组号不需要相同，但很多人以为是必须相同，发现组号不一样就反复改，改来改去反而把配置改坏了。记住一点：LACP协商是不看组号的，看的是System ID、端口优先级、端口号这些参数。

第四个坑是LACP超时时间不一致。一端用默认的Long超时（30秒），另一端被人改成了Short超时（3秒），虽然也能协商，但一端认为链路故障的判定期望和另一端完全不一样，一旦出现偶发丢包，聚合口可能频繁震荡。建议两端统一LACP超时时间，配置方法是lacp period short或lacp period long，在聚合口下设置。

6. 延伸：从三层聚合到完整组网

6.1 用模拟器复现三层聚合

如果你手头没有真机，用HCL模拟器完全可以复现整套三层聚合配置。搭建两台交换机背靠背，连线后每台交换机创建Route-Aggregation接口，配置IP，再把两个物理口加入聚合组。HCL模拟器对Route-Aggregation的支持还是比较完整的，静态和动态模式都能验证。

有一点需要注意，模拟器里部分交换机的物理口默认可能就是路由模式，没有二层模式的那些限制，配置起来比真机更顺畅。如果你想练排错，可以在模拟器里故意把一端改成动态、另一端保持静态，然后观察display link-aggregation summary里成员口一直Unselected的现象，这种对比实验非常有助于理解LACP协商逻辑。

6.2 聚合口上叠加OSPF

三层聚合最常见的搭档是动态路由协议。在Route-Aggregation口上启用OSPF，聚合口就是一条普通的三层链路，所有路由配置照常做。CORE侧大致如下：

text复制ospf 1
 area 0.0.0.0
  network 10.0.0.0 0.0.0.3

只要聚合口状态UP，OSPF邻居就能建立；聚合口下所有成员口都断了，聚合口Down，OSPF邻居随之断开，流量自动切换到其他路由路径。这种“聚合冗余+路由冗余”的组合，是园区网核心高可用的基础形态。如果你对故障切换速度有更高要求，可以在聚合口上叠加BFD检测，将感知时间从秒级压缩到毫秒级。

6.3 聚合口上的IPv6与ACL扩展

三层聚合口既然是普通三层口，IPv6地址、ACL、QoS策略这些都能直接应用。IPv6配置只需要在聚合口下执行ipv6 address 2001:db8:1::1/64，OSPFv3也能跑。ACL则把聚合口当成普通路由口，进出方向都可以绑定packet-filter。

这里想提醒一点：聚合口的策略配置会影响所有成员口，所以做变更前一定要想清楚。比如你在聚合口上绑了一条deny ACL，所有成员口的同方向流量全部被过滤，这个影响范围比单口大好几倍。我见过有人为了过滤特定流量，把ACL绑在了成员口上而不是聚合口上，结果流量哈希到另一个成员口时绕过了ACL，安全策略直接失效。记住，三层聚合的配置应该尽量集中在Route-Aggregation口上，成员口只做加入聚合组这一个动作，不要在上面堆策略。

说到底，三层聚合的技术本身并不复杂，难的是把原理、选型和排错串成一条线。我自己配置完后有个习惯动作：拔掉一根光纤，看看聚合口是否保持UP，业务是否无感切换；再用多线程工具打一轮流量，确认哈希均匀。这两步做完，这条聚合链路才算真正交付出去了。你遇到的绝大多数聚合问题，无非就是模式不匹配、成员口没选中、哈希不均这三件事，按着上面的排查思路走一遍，基本能稳。