企业官网建设流程全解析

排障的时候总有人问我：服务器两个千兆口分别接到交换机两个口上，业务就是跑不满，能不能把两条链路合并成一条用？能，而且我强烈建议用LACP而不是手工静态聚合——除非你有非常明确的理由。这篇文章围绕华为交换机上二层场景下的LACP链路聚合配置展开，覆盖从原理、模式选型、配置命令到验证排查的完整过程，还会分享一些真正部署时容易踩的坑。不管你是刚接触网络的工程师，还是已经配过不少设备但没细想过LACP细节的同行，这个主题都能直接派上用场。

1. 链路聚合到底解决什么问题：从项目需求谈起

1.1 单链路瓶颈与带宽叠加

很多项目的起点是“带宽不够”。一个典型场景：服务器上插了两块千兆网卡，分别接到汇聚交换机的两个不同端口，业务流量是一路视频存储写入，一路数据库同步。如果只是简单给两个网口配两个不同网段的IP，让它们各走各的路，问题马上就来了：某一路流量一旦增大，单块网卡就顶不住，另一块网卡反而闲着。你说气不气人。

LACP链路聚合想解决的正是这种“有带宽却用不上”的尴尬。它把两条甚至更多条物理链路捆绑成一个逻辑接口，华为对应概念叫Eth-Trunk，流量会根据HASH算法分散到不同成员链路上。从交换机角度看，Eth-Trunk就是一个正常的二层接口，上层完全感知不到物理链路的数量。

不过这里必须说清楚一个常见误区：“叠加带宽”不等于两条1G链路就变成一个2G的无脑管道。单条会话（也就是一条流）的报文只会走其中一条成员链路，不会出现一条流横跨两条链路的情况。真正收益在于多条流同时承载时，聚合后的总吞吐能接近各成员链路之和。比如同时有100条业务流，HASH打散后均匀分布在两条千兆链路上，总吞吐才有可能接近2G水平。如果你的业务里只有少数几条大流量长连接，聚合效果会打折扣，这一点在项目选型阶段就要想明白。

1.2 LACP与手工聚合的取舍

华为交换机上链路聚合有两种典型形态：手工聚合（manual load-balance）和LACP聚合。手工聚合不跑协商协议，只要两端配置一致就能工作，配置很简单，但对端状态异常时故障感知完全依赖物理链路状态，收敛速度慢，而且无法自动区分本端和对端链路的健康状况。

LACP则是IEEE 802.3ad/802.1ax标准定义的链路聚合控制协议，两端通过LACPDU报文交互系统优先级、接口优先级、操作Key等信息，协商出哪些成员口能进入Selected状态成为活动链路。一旦某条链路断开或协商异常，LACP可以快速把流量重新HASH到其他健康成员链路上。华为的lacp-static模式还支持手工指定活跃链路数量上限，方便做一些特殊的主备规划。

我个人的建议是：无论是交换机互联、交换机接服务器、还是接入层上联汇聚层，只要对端设备支持LACP，优先用lacp-static模式。它既保留了LACP协商的可靠性，又不依赖纯动态协议，排障时状态比较直观。手工聚合可以用在对端设备老旧、确实不支持LACP的场合，但一定要额外做好链路质量监控，否则某条链路悄悄劣化了你可能毫无感知。

1.3 二层聚合与三层聚合的边界

标题里写了“二层聚合”，很多人配置时会困惑：怎么其他文章里还有三层聚合？这两种聚合在配置上的区别主要体现在Eth-Trunk接口承载的业务类型上。

二层聚合是Eth-Trunk作为二层接口使用，接口下只有access、trunk、hybrid这类二层属性，放通对应VLAN后作为二层转发通道。典型场景是接入交换机上联、服务器双网卡接入、交换机之间的二层级联。这种模式下，聚合口本身不配置IP地址，IP地址在三层交换机对应的VLANIF或者终端本身。

三层聚合则是把Eth-Trunk当三层接口用，直接在聚合口上配置IP地址，常用于路由器、三层交换机之间的三层互联。它们的本质都是同一个Eth-Trunk框架，只是配置属性不同。二层聚合配置时要注意，成员口必须同属二层类型，且VLAN放通情况一致，否则成员口无法正常加入或状态异常。搞懂这个边界，配置时就不会把VLANIF之类的配置往Eth-Trunk上乱放，排查问题思路也更清晰。

2. 配置前的关键认知：模式、优先级与约束条件

2.1 LACP工作模式与协商方向

华为LACP静态聚合中，每个聚合口可以配置为Active（主动）或Passive（被动）。Active模式接口主动发送LACPDU，Passive模式接口不主动发送，只在收到对端LACPDU后才回应。换句话说，链路两端必须至少有一端是Active，协商才能建立。如果两端都是Passive，两边都不发报文，聚合口就一直无法Selected。

实际部署中，华为交换机上通常配置lacp-static且为Active，服务器网卡侧如果是Intel网卡的Teaming/LACP功能，也设置为主动协商。有些虚拟化平台的网卡Bonding模式需要设置成802.3ad，同时可以指定主动或被动，只要保证两端有一端主动就行。

还有一个容易忽略的细节是LACP超时时间。Slow超时（默认）协商周期较长，适合稳定场景；Fast超时（秒级）能更快感知链路故障，但对端必须同步使用Fast，否则协商参数不匹配也会出问题。华为参数中可以通过lacp timeout fast来调整，但一般场景下不建议随意改，保证两端默认一致最省心。这个点看起来小，但在跨厂商对接时，双方默认值不一致的情况真实存在，项目里就遇到过华为和某国外品牌交换机对接时协商一直不稳定，最后查出来就是超时参数不一致。

2.2 系统优先级与接口优先级

LACP协商依赖两个关键优先级：系统优先级（system LACP priority）和接口优先级（interface LACP priority）。系统优先级用于在两台设备互连时决定哪一端在协商过程中占据主导地位，默认值是32768，数值越小优先级越高。

接口优先级的作用更实际：当聚合组内成员口数量超过系统支持的最大Active链路数时，会按照接口优先级从高到低挑选一部分链路成为Selected活动链路，其余作为Standby。通过修改接口优先级，你可以控制“哪些端口优先被使用”。

大多数二层聚合项目里，默认优先级就够用，不需要额外改动。但有一种情况值得注意：当交换机只支持4条活动链路而你接了6条成员口时，如果不设置接口优先级，设备会按端口号顺序选择，可能把关键的物理链路排除在活动集合之外。这时候手动调整接口优先级，可以让高带宽、稳定性更好的接口先成为活动链路。不过这种场景在我实际项目中不算多，大多数时候设备默认策略已经能满足需求。

2.3 成员口加入的硬性约束

加入Eth-Trunk的成员口不是随便什么端口都行，华为设备上有几个硬性约束最容易被忽略，我直接列出来：

• 成员口的接口类型必须一致，不能是Access、Trunk和Hybrid混用。
• VLAN配置必须一致，包括缺省VLAN和允许通过的VLAN集合。
• 速率和双工模式必须一致，否则协商时会报错或状态异常。
• STP、风暴控制等二层协议属性应保持一致。
• 不能把Eth-Trunk口本身作为另一个Eth-Trunk的成员口。
• 成员口不能处于异常环路检测状态，也不能配置与其他聚合冲突的业务。

这些约束背后的逻辑很直接：Eth-Trunk从上层看是一个逻辑接口，成员口必须被“同质化”处理，否则同一份流量打在不同成员口上，对端看到的VLAN、速率、状态都不一样，处理就会出乱子。配置前花两分钟确认一下这些属性，比配完排障半小时划算得多。

3. 华为二层LACP聚合配置实操全流程

3.1 配置前环境核查

我习惯把配置前的核查列成一个检查清单，避免上线时手忙脚乱。第一确认设备型号和版本，比如S5700系列、S6700系列、CE系列等，不同系列的Eth-Trunk最大成员数和配置方式略有差异。第二确认物理接口编号和状态，执行display interface brief看看准备加入的两条链路是否都处于物理Up状态。第三确认VLAN规划，聚合口打算放通哪些VLAN，是Access还是Trunk。第四确认对端设备类型，是另一台华为交换机、服务器网卡、存储设备还是防火墙，这决定了LACP模式和对端配置方式。

一次实际项目中，我给服务器配置双网卡聚合，现场确认是千兆电口，准备接入华为S5720的GE口。检查物理口状态时发现第二块网卡对应的交换机口没有插线，幸好上线前发现了，否则配置上去后只有一条链路在工作，业务流量照样可能跑不满，甚至会出现协商异常。所以上线前必须把物理连接这一关守好，不要想当然认为线都插好了。

3.2 创建Eth-Trunk并配置二层属性

进入华为交换机的系统视图，创建Eth-Trunk并设置为LACP静态模式：

system-view interface Eth-Trunk 1 mode lacp-static port link-type trunk port trunk allow-pass vlan 10 20

这段配置的意思是：创建一个编号为1的Eth-Trunk，工作模式为LACP静态聚合，链路类型为Trunk，允许VLAN 10和20通过。

注意两点：第一，Eth-Trunk编号没有实际业务意义，只要不冲突即可；第二，lacp-static对应我们常说的静态LACP，不要和手工聚合（直接进入Eth-Trunk但不配置mode）混淆。如果端口类型需要Access，就把port link-type改成access，并设置port default vlan。

有些情况下还需要配置Eth-Trunk的负载分担模式。默认HASH可以基于源MAC、目的MAC或IP等字段，具体用哪种要看业务特征。比如纯二层转发场景，默认就够了；但如果是多VLAN环境且对不同VLAN流量都有一致性要求，可以视情况调整。配置命令是在Eth-Trunk接口视图下执行：

load-balance src-dst-mac

我通常不轻易改默认值，除非客户反馈“流量集中在某一条链路上”而且确认是多流业务。负载分担策略是个需要结合流量模型细抠的环节，不同版本支持的HASH因子可能有差异，版本升级后也建议复查一下。

3.3 成员接口加入与状态确认

创建好Eth-Trunk后，把两个物理接口加入聚合组：

interface GigabitEthernet 0/0/1 eth-trunk 1 quit interface GigabitEthernet 0/0/2 eth-trunk 1 quit

这里有一个非常容易踩的坑：如果物理接口上原来配置过Access或Trunk属性，加入Eth-Trunk时会报错，必须先把原配置清掉。安全的做法是在加入前执行：

undo port link-type

把接口恢复到默认状态，再执行eth-trunk 1。否则你会看到类似“Error: Please remove the configuration on the interface first”的提示。这个报错在实际配置中出现频率相当高，尤其当交换机端口之前被其他工程师手工改过类型时。

加入完成后，用display eth-trunk 1查看聚合状态。正常情况下能看到两个成员口状态为Selected，如果出现Unselected，大概率是协商或者属性一致性问题。这个命令是关键验证手段，我会在下一章详细讲字段含义。

3.4 对端服务器侧联动配置

如果聚合的另一端是服务器，服务器上的网卡链路聚合配置往往会让工程师头疼。以Linux系统为例，推荐使用Bonding模式4，对应802.3ad：

modprobe bonding mode=4 echo "+bond0" > /sys/class/net/bonding_masters echo "802.3ad" > /sys/class/net/bond0/bonding/mode ip link set eno1 up echo "eno1" > /sys/class/net/bond0/bonding/slaves ip link set bond0 up

如果是更常见的NetworkManager配置方式，会写一个Bond连接文件。不同发行版细节不同，但核心点一样：把两块物理网卡加入bond0，模式选择802.3ad，再给bond0配置IP地址。

Windows Server上则是在“服务器管理器-本地服务器-NIC Teaming”里创建Teaming，选择“交换机独立/LACP”模式。VMware vSphere里也有类似的“链路发现”和“负载均衡-基于IP哈希”选项，需要配合交换机的LACP策略。配置对端时的关键原则是：模式要与交换机匹配，本端服务器可以是Active也可以Passive，但一定要有一端主动协商。我曾经见过两边都默认Passive，结果链路死活协商不上的案例，最后才发现是这么小的配置问题。

4. 验证手段与故障排查实录

4.1 状态查询与关键字段解读

配置完成后，第一件事是验证而不是直接跑业务。我常用的验证命令有这么几条：

display eth-trunk 1 display lacp statistics display interface Eth-Trunk 1

display eth-trunk 1的输出里，重点是以下几个字段：

• Mode：LACP，确认当前聚合模式。
• PortStatus：Selected还是Unselected，Selected代表成员口已进入活动状态。
• ActorSystemID和PartnerSystemID：本端和对端的系统ID，协商成功时两端能看到对方的ID。
• ActorPortNumber/PartnerPortNumber：端口号信息，双方能识别对方对应端口。

如果PortStatus都是Selected，说明协商成功，聚合链路进入工作状态。如果看到Unselected，就要结合后面的排查方向来处理。

display interface Eth-Trunk 1可以看到这个逻辑接口的整体流量统计。如果只有单条物理链路有流量，另一条统计始终为零，说明HASH分流异常或者对端没有把流量均匀分布过来，需要检查负载分担策略。

4.2 常见故障场景与处理

故障一：聚合口协商不成功，所有成员口都是Unselected。

首查两端LACP模式。华为侧是lacp-static Active，服务器或对端交换机如果也是Passive且不主动发送LACPDU，虽然理论上可以协商，但实际中一旦参数不匹配就卡住。最稳妥的方案是两端都设成Active。其次查物理线缆，用display interface brief看物理端口是否有CRC错误、Up/Down频繁翻转，把劣化链路换掉。

故障二：成员口加入时报错，提示接口已有配置。

处理方法是先清配置，再加入Eth-Trunk。另一种可能是物理口已经被其他Eth-Trunk占用，无法重复加入。这类问题多出在复用旧端口做新聚合的场景，操作前先display接口配置确认。

故障三：Eth-Trunk正常工作，但只有一条链路有业务流量。

首先确认对端是否也做了同样的聚合配置，其次看HASH分布。如果业务只有少量大流量会话，单条链路忙而另一条闲是正常现象，不属于故障。如果确认是多流业务仍然集中，可以在华为设备上调整负载分担模式，比如把默认的MAC HASH调整为包含IP信息的HASH因子。

故障四：服务器侧聚合起来，但交换机上看到PortStatus反复跳变。

这种情况往往是对端服务器网卡在LACP协商过程中，发送的报文没有携带一致的SystemID，或者是虚拟化平台网卡的资源配置问题。可以先在交换机上执行reset lacp statistics清零统计，再观察一段时间，看看是持续抖动还是偶发。如果持续抖动，建议核对服务器网卡驱动和Bonding配置，必要时升级驱动版本。

下面我把常见问题整理成一张速查表，方便排障时对照：

4.3 配置变更与回退技巧

网络设备上做变更，最怕改错回不去。针对Eth-Trunk，我总结了几条实操经验。

修改Eth-Trunk属性前，先把成员口逐根退出聚合组，改完再重新加入，避免中途出现业务中断或协商异常。当然如果有变更窗口期，直接在聚合口上改VLAN放通也可以，但风险更高。

需要临时拆分聚合链路时，用shutdown而不是直接把Eth-Trunk删掉。shutdown掉物理口，LACP会迅速把流量切换到其他健康成员口；直接删配置可能把Eth-Trunk瞬间移除，造成断流。

回退前一定要保存当前配置，华为用save命令写入配置文件。改错了还能通过重启或加载备份配置恢复。

还有一个细节：华为支持在Eth-Trunk接口视图下直接增删允许的VLAN，但如果对端设备是手工静态聚合且不同步感知，会造成两侧VLAN放通列表不一致。碰到跨厂商互联的场景，变更前最好和对端工程师确认窗口，两边同步操作。

4.4 生产环境中的额外建议

最后说几条生产环境中比较实用的建议，算是我这些年反复吃亏后总结出来的。

上架前做好标签。Eth-Trunk是多链路逻辑接口，物理线缆一旦被误拔，靠命令行很难快速定位哪根线对应哪个成员口。建议在交换机端口、服务器网卡、线缆两头同时标注聚合组编号和链路序号，后期维护真的能省大量时间。

监控聚合口流量。很多网管软件支持监控虚拟接口（Logical Interface），把Eth-Trunk纳入监控，比分别监控两个物理口更直观，还能看到聚合后的整体流量趋势和故障切换历史。

高强度业务下注意设备CPU利用率。有的边缘型号交换机在HASH计算、LACP报文处理上会占用额外CPU，聚合了太多条链路或者开启了复杂HASH模式时，要留意设备CPU是否偏高。如果CPU持续飙高，考虑减少成员口数量或简化HASH因子。

批量上线前先在实验室搭一套最小环境验证。交换机部署和服务器Bonding配置、对端交换机互联参数，都可以先在测试环境完整走一遍，确认协商成功、负载均衡生效后再进生产。很多看似诡异的故障，其实在实验室几分钟就能暴露出来。

我个人在实际操作中的体会是：LACP本身不是一个复杂的特性，难的是两侧设备的心智模型对齐。你总觉得两边都是LACP就行了，其实协商模式、优先级、超时时间、VLAN一致性，任何一个点没对齐，链路就给你颜色看。所以每次配置完，我从来不急着跑流量，一定先花两分钟看display eth-trunk的输出，再拔一根线测试冗余切换，确认另一条链路能接管流量才收工。

最后再分享一个小技巧：如果你配置中遇到半天都协商不上的情况，先别急着怀疑设备坏了，回到“两端是否有一端为Active”和“成员口属性是否完全一致”这两个基本点上排查，八成问题就出在这里。搞定了这两条，华为的二层LACP聚合基本就稳了。