排障的时候总有人问我服务器两个千兆口分别接到交换机两个口上业务就是跑不满能不能把两条链路合并成一条用能而且我强烈建议用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模式接口主动发送LACPDUPassive模式接口不主动发送只在收到对端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.3admodprobe bonding mode4 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 1display eth-trunk 1的输出里重点是以下几个字段ModeLACP确认当前聚合模式。PortStatusSelected还是UnselectedSelected代表成员口已进入活动状态。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配置必要时升级驱动版本。下面我把常见问题整理成一张速查表方便排障时对照现象可能原因处理方式所有成员口Unselected两端LACP模式不匹配、线缆异常至少一端配置为Active检查物理口状态加入成员口报错接口已有其他配置或已加入其他Eth-Trunk先清除原配置再执行eth-trunk聚合后流量集中在一条链路HASH因子与业务流特征不匹配调整负载分担模式确认多流场景PortStatus反复跳变对端SystemID不一致、驱动异常重置统计观察检查网卡驱动和配置只有单条链路Up另一根线缆或对端口故障检查物理连接与对端端口状态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聚合基本就稳了。