1. 链路聚合的运行原理与核心价值1.1 链路聚合到底做了什么链路聚合在华为设备上叫 Eth-Trunk在思科叫 Port-Channel在服务器网卡驱动里常叫 Bonding 或 Teaming。名字各不相同干的却是同一件事把两条以上的物理链路捆成一条逻辑链路。这件事听起来简单实际解决的问题相当实在——带宽叠加和链路冗余。先说说带宽叠加。这个比较好理解两根千兆网线绑一起逻辑上变成一条两千兆的管道。但这里有一个很多人容易踩的误区两千兆不代表任何一份流量都能跑满两千兆。聚合后的带宽是给“多份流量”用的而不是给“一份流量”提速度的。后面我会专门展开讲。链路冗余的价值同样重要。如果没有聚合两根线同时接到交换机上交换机的生成树协议STP为了防环会直接阻塞其中一根带宽不升反降。有了聚合后两条链路互为备份一根断了流量自动切到另一根对业务来说几乎无感知。这个特性在核心业务场景里价值巨大很多金融、政务网络的核心区都在用。从网络架构角度看链路聚合还顺带解决了单点故障问题。交换机端口、网线、对端设备接口任何一个环节出问题聚合都能通过链路切换兜底。这也是为什么服务器双网卡、交换机上联、防火墙双出口这些场景里链路聚合几乎成了标配。1.2 两条千兆口为什么叠不出两千兆这个问题几乎每次培训都会被问到。我先给结论单条 TCP 连接或者单份大数据流在聚合链路上只能走一条物理链路跑死也只有千兆。原因在于聚合的转发机制。交换机在做负载分担时不是按字节把流量平分到各条链路上而是按“流”来分。交换机提取报文里的某些字段比如源目 IP、源目 MAC、端口号做一次哈希运算得到一个哈希值然后拿这个值去映射到某一条成员链路。同一个流的所有报文哈希结果一样所以永远走同一条链路。这样做的好处是避免报文乱序。如果同一份数据的前半段走 A 线、后半段走 B 线到达对端时顺序错乱TCP 协议就要重传性能反而断崖式下跌。所以网络设备的设计者选择了按流哈希这条路。这意味着什么用大白话说一个用户在下载一个大文件这条下载流只会吃满一根千兆线但十个用户各自下载不同的文件十条流哈希到两条线上就能把两千兆的容量用起来。所以部署聚合时你问的第一句话应该是我的业务是单流大吞吐还是多流并发前者聚合帮不上忙后者才是聚合的主场。1.3 聚合链路工作的前提条件链路聚合不是简单地拿两根线接上就行它有一套隐含的约定。最基本的条件是成员链路的速率和双工模式必须一致否则对端设备无法正确协商成员链路必须放通相同的 VLAN否则聚合后 VLAN 转发会乱套。华为交换机在把物理接口加入 Eth-Trunk 时会检查这些参数。如果你把千兆口和百兆口捆在一起或者两条链路一个 trunk 口放通 VLAN 10另一个放通 VLAN 20系统会提示配置冲突甚至直接拒绝加入。更隐蔽的问题是成员链路本身不能有环路。很多人刚接触聚合时会困惑我明明已经配了 Eth-Trunk为什么交换机还在告警说检测到环路大概率是接口配置顺序出了问题。正确的做法是先把物理接口清空用 default 命令恢复出厂视图再逐个加入 Eth-Trunk最后才配置 VLAN 和 trunk 属性。2. 两种聚合模式到底怎么选2.1 手工模式简单直接但全靠手工保证一致性华为交换机上链路聚合分为手工模式manual和 LACP 模式lacp-static。手工模式是纯静态的不运行任何协商协议只要你在两端把同样的物理接口加入 Eth-Trunk链路就生效。手工模式的优点是配置简单适合对端设备不支持 LACP 协议的场景。老一点的服务器网卡、某些防火墙设备、部分第三方交换机只支持静态捆绑这时候手工模式是最稳的选择。但它的缺点也很明显链路是否正常、对端是否也做了同样的配置完全靠人工保障。如果对端配置有误本端是感知不到的流量可能悄悄地丢。另外手工模式下如果链路出现故障本端设备只能通过物理层 Down 来判断无法做快速响应。这一点在后面讲故障排查时会有实际的坑。2.2 LACP 模式让协议帮你兜底LACPLink Aggregation Control Protocol是 IEEE 802.3ad 标准定义的链路聚合控制协议华为设备上的“静态 LACP”模式就是启用这个协议进行成员链路的动态协商。LACP 的优势是握手确认。本端发出 LACP 报文对端收到后回复两边一握手就确认“我这边两根线你那边也是两根线参数一致”聚合链路才正式 UP。这比手工模式凭空猜对端配置要靠谱得多。LACP 还有一个杀手级功能备份链路。你可以在 Eth-Trunk 里设置活动接口数量的上限。比如 Eth-Trunk 有四个成员口设置活动接口上限为 2那只有两个口转发流量另外两个口作为备份。当活动口出故障时备份口自动顶上。这是手工模式做不到的手工模式所有成员口都是激活状态没有备份概念。所以只要对端设备支持 LACP我都会优先建议用 LACP 模式。它多花不了多少配置时间却换来更高的可靠性。2.3 实际选型建议具体怎么选我给一个实操判断框架。对端是华为交换机或绝大多数主流交换机、服务器网卡优先选 LACP 模式对端是老旧设备或不支持 LACP 的嵌入式设备退而求其次选手工模式跨厂商对接时建议先确认两边对 LACP 的实现有无兼容性问题省得后期查得头大。还有一点需要提醒华为设备上 LACP 模式全称叫“静态 LACP”这个“静态”两个字容易让人误解。它不是让你手工指定活动链路而是说聚合本身是手工创建的但成员链路的协商是动态的。另外一个叫法“动态 LACP”在华为设备上并不存在别在命令行里敲 lacp dynamic 这种不存在的关键字。3. 华为交换机链路聚合配置全过程3.1 配置前的规划我以一台华为 S5720 交换机和一台服务器双网卡对接为例演示完整的配置流程。先讲规划。拓扑大概是这样的服务器装了两块千兆网卡分别接到交换机的 GigabitEthernet0/0/1 和 GigabitEthernet0/0/2。服务器网卡上做链路聚合交换机上做 Eth-Trunk两边配成 LACP 模式逻辑上形成一条 2Gbps 的上联链路。规划阶段要确定四件事Eth-Trunk 编号、成员接口、负载分担算法、放通的 VLAN。编号方面S5720 支持多个 Eth-Trunk编号范围是 1 到 128随便选一个即可我习惯把和服务器对接的聚合口编号为 1。VLAN 方面如果服务器跑的是 VLAN 10那聚合口就要以 trunk 方式加入并放通 VLAN 10。这里强调一点负载分担算法不要随手选。S5720 支持 dst-ip、src-ip、src-dst-ip、dst-mac、src-dst-mac 等模式。和服务器对接时经典做法是用 src-dst-ip 或者 src-dst-mac。因为服务器和外部通信时源目 IP 和 MAC 的多样性会带来比较好的哈希分布。如果你只有一个源 IP 和一个目的 IP 做测试那再怎么换算法都只会挑一条链路走这不是设备问题是测试方式问题。3.2 创建 Eth-Trunk 并绑定成员接口先进入系统视图创建 Eth-Trunksystem-view interface Eth-Trunk 1此时 Eth-Trunk 已经存在但里面还没有成员接口默认模式是手工模式。我需要修改模式并绑定物理口interface Eth-Trunk 1 mode lacp-static quit interface GigabitEthernet0/0/1 eth-trunk 1 quit interface GigabitEthernet0/0/2 eth-trunk 1 quit这几条命令的逻辑是先定义通道再让物理口加入通道。注意物理口加入 Eth-Trunk 之后物理口自身的配置就失效了包括 IP 地址、VLAN 配置等以后所有配置都要在 Eth-Trunk 接口下做。有句经验之谈绑好的物理口不要再单独配任何业务命令。我在现场见过有人图方便直接在物理口下敲了 port link-type trunk结果配置冲突导致物理口始终起不来。规范的做法是物理口只管加入 Eth-Trunk剩下的全部交给 Eth-Trunk 接口配置。3.3 配置 LACP 模式和优先级LACP 模式配好后两端会自动协商。但有一个参数需要按需设置系统 LACP 优先级和接口 LACP 优先级。优先级的作用是决定“谁是主动端”。主动端的设备会决定哪些链路是活动链路哪些是备份链路。默认情况下所有设备的系统 LACP 优先级都是 32768如果两台设备优先级一样就靠 MAC 地址来比较MAC 小的成为主动端。如果我在 S5720 上接入了一台服务器服务器的网卡聚合是由驱动实现的LACP 行为可能和交换机不太一样。为了保证稳定我通常把交换机的系统优先级调低让它成为主动端interface Eth-Trunk 1 lacp system-priority 100再设置活动接口数的上限。假设我要两个口都做活动口不设备份口也可以不配。但如果想留一个口做备份可以这样interface Eth-Trunk 1 lacp max active-linknumber 2这条命令的意思是成员口最多只有 2 个是活动链路。如果 Eth-Trunk 下有 3 个成员口第三个自动成为备份口。这个特性在实际运维里很有用但多口场景下要注意别把 max active-linknumber 设得太小导致带宽白白浪费。3.4 配置负载分担与 VLAN 放通负载分担要在 Eth-Trunk 接口下配置interface Eth-Trunk 1 load-balance src-dst-ipS5720 的负载分担模式是全局性的还是支持按 Eth-Trunk 单独设置这个不同型号有差异。部分老款设备只能在系统视图下全局配置新款设备支持在 Eth-Trunk 下单独指定。配之前可以用 display eth-trunk 1 检查如果模型不支持会出现提示信息。VLAN 配置和普通 trunk 口一样interface Eth-Trunk 1 port link-type trunk port trunk allow-pass vlan 10注意这里是 Eth-Trunk 接口变更为 trunk 口不是物理口。改完这个之后Eth-Trunk 接口的最终配置就成型了。3.5 验证配置与结果判断配置完成后最重要的验证命令是这两条display eth-trunk 1 display trunkmembership eth-trunk 1第一条命令能看到 Eth-Trunk 的工作模式、成员口状态、哪些是活动链路、流量负载分担算法。重点关注状态那一栏如果是 Selected说明这条链路是活动的如果是 Unselected说明是备份链路或者协商失败。第二条命令能看到 Eth-Trunk 的 VLAN 放通情况。检查 VLAN 10 是否存在如果列表里没有后面的业务流量就会在交换机这一侧被丢弃。再在服务器上观察网卡链路状态。正常情况下服务器网卡会显示速率 2Gbps或者显示为聚合模式并报告两个成员口都处于 UP 状态。如果服务器显示的还是两个独立的千兆口说明两端协商没有成功八成是模式不匹配或者 VLAN 不一致。4. 隔着设备怎么聚合对接服务器与上联交换机的配置要点4.1 服务器双网卡聚合的三种模式和交换机打交道多了就会发现链路聚合最核心的对接场景有两类一类是交换机连服务器另一类是交换机上联另一台交换机。服务器这块的门道尤其多。Linux 服务器的双网卡绑定通常有三种模式mode 1主备模式、mode 4LACP 动态聚合、mode 6负载均衡但不协商。Windows 服务器则是通过 NIC Teaming 功能实现也支持静态聚合和 LACP 两种方式。这里最容易出问题的是 mode 4 和交换机 LACP 状态的匹配。Linux 的 mode 4 对应的是 802.3ad 动态链路聚合它要求交换机侧必须开启 LACP也就是华为交换机上的 lacp-static 模式。如果你交换机侧配了手工模式服务器侧又是 mode 4两边根本谈不拢链路起不来。反过来Linux 的 mode 6 是自适应负载均衡不依赖对端但它也不跑 LACP所以交换机侧反而配置手工模式更合适。很多初学者在这里绕晕核心原因是没有理清“LACP 是一种协议必须两端都跑才生效”。4.2 华为交换机与服务器对接的配置要点和服务器对接时有几个细节我不止一次踩过坑。第一个是服务器网卡的驱动和 bond 支持情况。有些网卡在 BIOS 里就把两个口的 SR-IOV 或者 VLAN 卸载功能打开了这会导致 LACP 报文被接口硬件处理掉交换机侧看到的 LACP 协商状态是空的。遇到这种情况先进服务器 BIOS 关掉无关的硬件卸载功能再试。第二个是服务器网卡如果用的是 Intel 的 i350 系列建议把两个口的 LLDP 功能关闭。因为部分网卡固件会周期性地发出 LLDP 报文在某些交换机型号上会被当成非法报文处理进而影响整个 Eth-Trunk 的协商状态。这不是普遍问题但我在 S5735 上真实遇到过关掉 LLDP 后问题消失。第三个是线缆问题。接入服务器时很多人随手扯两根同颜色的网线接上去没注意线序和速率协商情况。如果两根线一根协商成了千兆全双工另一根协商成了百兆Eth-Trunk 虽然也能起来但带宽直接缩水一大截。查问题时第一件事永远是检查物理口的速率双工状态。4.3 上联汇聚交换机的聚合设计交换机上联另一台交换机时聚合的目的一般有两层第一层是带宽扩容第二层是路径冗余。三层组网里接入交换机做 Eth-Trunk 上联汇聚交换机汇聚交换机同样做 Eth-Trunk 对接两端都要配置对应模式。上联场景的负载分担算法要和下联业务匹配起来想。假如接入交换机下面挂的都是监控摄像头流量是从下往上走的每条流的源 IP 是各摄像头目的 IP 是录像服务器。这类多源单目的流量用 src-ip 做哈希可能不够均匀建议用 src-dst-ip 或者 src-dst-mac让不同摄像头分流到不同上行链路。另外上联场景要注意两台交换机之间的链路聚合和 STP 的协作。虽然 Eth-Trunk 本身解决了环路问题但如果 Eth-Trunk 接口的 STP 开销计算不当在部分复杂拓扑下可能造成阻塞。我一般建议在核心交换机的 Eth-Trunk 上启用 STP 边缘端口或者使用 PortFast 相关特性减少不必要的收敛等待时间。5. 高频故障与排查实录5.1 聚合接口一直是 DOWN这个问题的排查思路其实和普通接口 DOWN 差不多但多了一个维度。先看物理口状态display interface GigabitEthernet0/0/1如果物理口是 DOWN检查网线、光模块、对端设备是否开启。如果物理口是 UP 但 Eth-Trunk 是 DOWN问题多半出在协商环节。LACP 模式下用下面的命令看 LACP 报文收发计数display lacp statistics如果能看到报文计数在增长说明协商报文正在交互只是某个参数不匹配导致无法达成一致。此时重点核对两端模式、接口速率、双工模式、允许的 VLAN 是否一致。如果报文计数为 0说明一端根本没有发出 LACP 报文优先查对端设备的模式是否配置正确以及接口是否被 shutdown。5.2 流量全走一条物理链路流量不均匀是聚合部署后最常见的抱怨。遇到这种情况先不要怀疑设备故障严格执行以下排查顺序。第一步确认流量是单流还是多流。单流场景下流量集中在一根链路上是正常现象哈希机制决定的换哪种算法都一样。第二步查看 Eth-Trunk 下负载分担的算法display eth-trunk 1看 Load-balance 字段如果显示 dst-ip 或者 src-ip而你的业务是典型的多源多目流量可以换成 src-dst-ip 或者 src-dst-mac 再观察。第三步用流量统计确认各成员口实际转发字节数是否均衡display interface GigabitEthernet0/0/1 display interface GigabitEthernet0/0/2对比两个口的 Input/Output 字节数。如果差距很大大概率是哈希算法不合适或者哈希因子里的特征字段在业务流量里变化不大。比如业务是服务器之间的大文件备份源目 IP 就那几对无论用什么哈希算法都会固定映射到同一条链路上。5.3 业务时通时断这种问题最头疼因为表面看链路是 UP 的。经验告诉我时通时断大概率是物理链路不稳定或者成员口频繁抖动导致聚合反复重协商。先用日志排查。在系统视图下执行display logbuffer看有没有接口 Down/Up 的反复记录。如果有检查光模块的光功率或网线的水晶头质量。尤其是光模块使用时间长了之后光衰会加大初期表现为偶发 CRC 错误后期就是接口频繁闪断。再检查 Eth-Trunk 的成员口统计display interface GigabitEthernet0/0/1看 CRC 错误和 Input Error 是否持续增长。如果有基本可以定位是物理层问题链路聚合在这里是背锅的真正的故障点在对端设备、光模块或者线缆上。还有一种可能VLAN 配置不一致导致部分报文被丢弃。比如交换机侧 Eth-Trunk 放通了 VLAN 10 和 VLAN 20但服务器网卡侧只配了 VLAN 10 的 IP。VLAN 20 的流量到了服务器后无法处理应用层面就会出现间歇性不通。排查时用 display vlan 和服务器侧网卡配置逐一核对。5.4 聚合链路成员口配置冲突这个坑出现在把物理口加入 Eth-Trunk 的瞬间。如果物理口之前配过 port link-type、port default vlan 之类的命令加入 Eth-Trunk 时可能会报错比如 “Error: The port is a member of a link aggregation group” 或者 “Error: Please remove the ports configuration first”。解决办法是在加入之前把物理口配置清干净。华为设备上恢复接口默认配置的命令是interface GigabitEthernet0/0/1 default执行后接口回到初始状态再绑定 eth-trunk 1就不会有历史配置干扰。这个操作在生产设备上要谨慎它会清掉该接口下的所有业务配置操作前务必确认接口没有承载在线业务。5.5 排查命令速查表场景排查命令关键结果查看聚合状态display eth-trunk 1成员口 Selected/Unselected 状态查看LACP协商明细display lacp statistics报文收发计数是否正常查看成员口物理状态display interface GigabitEthernet0/0/1端口Up/Down、CRC错误、速率双工查看负载分担结果display eth-trunk 1Load-balance 算法、各成员口流量占比查看VLAN放通display trunkmembership eth-trunk 1VLAN列表是否包含业务VLAN查看历史日志display logbuffer接口闪断记录、协议协商告警最后再分享一个小经验。链路聚合这类问题八成以上不是配置错而是物理层或者模式不匹配导致的。我在现场排查时永远先看物理口状态、再看协议计数、最后才动配置。配置改来改去最浪费时间而且容易把原来正常的配置改坏。链路聚合本身不复杂复杂的是它藏在各种协议、物理介质、业务模型交织的角落里。把上面这些排查思路吃透你处理聚合问题的速度会快很多。 链路聚合原理与华为Eth-Trunk配置及故障排查实战
1. 链路聚合的运行原理与核心价值1.1 链路聚合到底做了什么链路聚合在华为设备上叫 Eth-Trunk在思科叫 Port-Channel在服务器网卡驱动里常叫 Bonding 或 Teaming。名字各不相同干的却是同一件事把两条以上的物理链路捆成一条逻辑链路。这件事听起来简单实际解决的问题相当实在——带宽叠加和链路冗余。先说说带宽叠加。这个比较好理解两根千兆网线绑一起逻辑上变成一条两千兆的管道。但这里有一个很多人容易踩的误区两千兆不代表任何一份流量都能跑满两千兆。聚合后的带宽是给“多份流量”用的而不是给“一份流量”提速度的。后面我会专门展开讲。链路冗余的价值同样重要。如果没有聚合两根线同时接到交换机上交换机的生成树协议STP为了防环会直接阻塞其中一根带宽不升反降。有了聚合后两条链路互为备份一根断了流量自动切到另一根对业务来说几乎无感知。这个特性在核心业务场景里价值巨大很多金融、政务网络的核心区都在用。从网络架构角度看链路聚合还顺带解决了单点故障问题。交换机端口、网线、对端设备接口任何一个环节出问题聚合都能通过链路切换兜底。这也是为什么服务器双网卡、交换机上联、防火墙双出口这些场景里链路聚合几乎成了标配。1.2 两条千兆口为什么叠不出两千兆这个问题几乎每次培训都会被问到。我先给结论单条 TCP 连接或者单份大数据流在聚合链路上只能走一条物理链路跑死也只有千兆。原因在于聚合的转发机制。交换机在做负载分担时不是按字节把流量平分到各条链路上而是按“流”来分。交换机提取报文里的某些字段比如源目 IP、源目 MAC、端口号做一次哈希运算得到一个哈希值然后拿这个值去映射到某一条成员链路。同一个流的所有报文哈希结果一样所以永远走同一条链路。这样做的好处是避免报文乱序。如果同一份数据的前半段走 A 线、后半段走 B 线到达对端时顺序错乱TCP 协议就要重传性能反而断崖式下跌。所以网络设备的设计者选择了按流哈希这条路。这意味着什么用大白话说一个用户在下载一个大文件这条下载流只会吃满一根千兆线但十个用户各自下载不同的文件十条流哈希到两条线上就能把两千兆的容量用起来。所以部署聚合时你问的第一句话应该是我的业务是单流大吞吐还是多流并发前者聚合帮不上忙后者才是聚合的主场。1.3 聚合链路工作的前提条件链路聚合不是简单地拿两根线接上就行它有一套隐含的约定。最基本的条件是成员链路的速率和双工模式必须一致否则对端设备无法正确协商成员链路必须放通相同的 VLAN否则聚合后 VLAN 转发会乱套。华为交换机在把物理接口加入 Eth-Trunk 时会检查这些参数。如果你把千兆口和百兆口捆在一起或者两条链路一个 trunk 口放通 VLAN 10另一个放通 VLAN 20系统会提示配置冲突甚至直接拒绝加入。更隐蔽的问题是成员链路本身不能有环路。很多人刚接触聚合时会困惑我明明已经配了 Eth-Trunk为什么交换机还在告警说检测到环路大概率是接口配置顺序出了问题。正确的做法是先把物理接口清空用 default 命令恢复出厂视图再逐个加入 Eth-Trunk最后才配置 VLAN 和 trunk 属性。2. 两种聚合模式到底怎么选2.1 手工模式简单直接但全靠手工保证一致性华为交换机上链路聚合分为手工模式manual和 LACP 模式lacp-static。手工模式是纯静态的不运行任何协商协议只要你在两端把同样的物理接口加入 Eth-Trunk链路就生效。手工模式的优点是配置简单适合对端设备不支持 LACP 协议的场景。老一点的服务器网卡、某些防火墙设备、部分第三方交换机只支持静态捆绑这时候手工模式是最稳的选择。但它的缺点也很明显链路是否正常、对端是否也做了同样的配置完全靠人工保障。如果对端配置有误本端是感知不到的流量可能悄悄地丢。另外手工模式下如果链路出现故障本端设备只能通过物理层 Down 来判断无法做快速响应。这一点在后面讲故障排查时会有实际的坑。2.2 LACP 模式让协议帮你兜底LACPLink Aggregation Control Protocol是 IEEE 802.3ad 标准定义的链路聚合控制协议华为设备上的“静态 LACP”模式就是启用这个协议进行成员链路的动态协商。LACP 的优势是握手确认。本端发出 LACP 报文对端收到后回复两边一握手就确认“我这边两根线你那边也是两根线参数一致”聚合链路才正式 UP。这比手工模式凭空猜对端配置要靠谱得多。LACP 还有一个杀手级功能备份链路。你可以在 Eth-Trunk 里设置活动接口数量的上限。比如 Eth-Trunk 有四个成员口设置活动接口上限为 2那只有两个口转发流量另外两个口作为备份。当活动口出故障时备份口自动顶上。这是手工模式做不到的手工模式所有成员口都是激活状态没有备份概念。所以只要对端设备支持 LACP我都会优先建议用 LACP 模式。它多花不了多少配置时间却换来更高的可靠性。2.3 实际选型建议具体怎么选我给一个实操判断框架。对端是华为交换机或绝大多数主流交换机、服务器网卡优先选 LACP 模式对端是老旧设备或不支持 LACP 的嵌入式设备退而求其次选手工模式跨厂商对接时建议先确认两边对 LACP 的实现有无兼容性问题省得后期查得头大。还有一点需要提醒华为设备上 LACP 模式全称叫“静态 LACP”这个“静态”两个字容易让人误解。它不是让你手工指定活动链路而是说聚合本身是手工创建的但成员链路的协商是动态的。另外一个叫法“动态 LACP”在华为设备上并不存在别在命令行里敲 lacp dynamic 这种不存在的关键字。3. 华为交换机链路聚合配置全过程3.1 配置前的规划我以一台华为 S5720 交换机和一台服务器双网卡对接为例演示完整的配置流程。先讲规划。拓扑大概是这样的服务器装了两块千兆网卡分别接到交换机的 GigabitEthernet0/0/1 和 GigabitEthernet0/0/2。服务器网卡上做链路聚合交换机上做 Eth-Trunk两边配成 LACP 模式逻辑上形成一条 2Gbps 的上联链路。规划阶段要确定四件事Eth-Trunk 编号、成员接口、负载分担算法、放通的 VLAN。编号方面S5720 支持多个 Eth-Trunk编号范围是 1 到 128随便选一个即可我习惯把和服务器对接的聚合口编号为 1。VLAN 方面如果服务器跑的是 VLAN 10那聚合口就要以 trunk 方式加入并放通 VLAN 10。这里强调一点负载分担算法不要随手选。S5720 支持 dst-ip、src-ip、src-dst-ip、dst-mac、src-dst-mac 等模式。和服务器对接时经典做法是用 src-dst-ip 或者 src-dst-mac。因为服务器和外部通信时源目 IP 和 MAC 的多样性会带来比较好的哈希分布。如果你只有一个源 IP 和一个目的 IP 做测试那再怎么换算法都只会挑一条链路走这不是设备问题是测试方式问题。3.2 创建 Eth-Trunk 并绑定成员接口先进入系统视图创建 Eth-Trunksystem-view interface Eth-Trunk 1此时 Eth-Trunk 已经存在但里面还没有成员接口默认模式是手工模式。我需要修改模式并绑定物理口interface Eth-Trunk 1 mode lacp-static quit interface GigabitEthernet0/0/1 eth-trunk 1 quit interface GigabitEthernet0/0/2 eth-trunk 1 quit这几条命令的逻辑是先定义通道再让物理口加入通道。注意物理口加入 Eth-Trunk 之后物理口自身的配置就失效了包括 IP 地址、VLAN 配置等以后所有配置都要在 Eth-Trunk 接口下做。有句经验之谈绑好的物理口不要再单独配任何业务命令。我在现场见过有人图方便直接在物理口下敲了 port link-type trunk结果配置冲突导致物理口始终起不来。规范的做法是物理口只管加入 Eth-Trunk剩下的全部交给 Eth-Trunk 接口配置。3.3 配置 LACP 模式和优先级LACP 模式配好后两端会自动协商。但有一个参数需要按需设置系统 LACP 优先级和接口 LACP 优先级。优先级的作用是决定“谁是主动端”。主动端的设备会决定哪些链路是活动链路哪些是备份链路。默认情况下所有设备的系统 LACP 优先级都是 32768如果两台设备优先级一样就靠 MAC 地址来比较MAC 小的成为主动端。如果我在 S5720 上接入了一台服务器服务器的网卡聚合是由驱动实现的LACP 行为可能和交换机不太一样。为了保证稳定我通常把交换机的系统优先级调低让它成为主动端interface Eth-Trunk 1 lacp system-priority 100再设置活动接口数的上限。假设我要两个口都做活动口不设备份口也可以不配。但如果想留一个口做备份可以这样interface Eth-Trunk 1 lacp max active-linknumber 2这条命令的意思是成员口最多只有 2 个是活动链路。如果 Eth-Trunk 下有 3 个成员口第三个自动成为备份口。这个特性在实际运维里很有用但多口场景下要注意别把 max active-linknumber 设得太小导致带宽白白浪费。3.4 配置负载分担与 VLAN 放通负载分担要在 Eth-Trunk 接口下配置interface Eth-Trunk 1 load-balance src-dst-ipS5720 的负载分担模式是全局性的还是支持按 Eth-Trunk 单独设置这个不同型号有差异。部分老款设备只能在系统视图下全局配置新款设备支持在 Eth-Trunk 下单独指定。配之前可以用 display eth-trunk 1 检查如果模型不支持会出现提示信息。VLAN 配置和普通 trunk 口一样interface Eth-Trunk 1 port link-type trunk port trunk allow-pass vlan 10注意这里是 Eth-Trunk 接口变更为 trunk 口不是物理口。改完这个之后Eth-Trunk 接口的最终配置就成型了。3.5 验证配置与结果判断配置完成后最重要的验证命令是这两条display eth-trunk 1 display trunkmembership eth-trunk 1第一条命令能看到 Eth-Trunk 的工作模式、成员口状态、哪些是活动链路、流量负载分担算法。重点关注状态那一栏如果是 Selected说明这条链路是活动的如果是 Unselected说明是备份链路或者协商失败。第二条命令能看到 Eth-Trunk 的 VLAN 放通情况。检查 VLAN 10 是否存在如果列表里没有后面的业务流量就会在交换机这一侧被丢弃。再在服务器上观察网卡链路状态。正常情况下服务器网卡会显示速率 2Gbps或者显示为聚合模式并报告两个成员口都处于 UP 状态。如果服务器显示的还是两个独立的千兆口说明两端协商没有成功八成是模式不匹配或者 VLAN 不一致。4. 隔着设备怎么聚合对接服务器与上联交换机的配置要点4.1 服务器双网卡聚合的三种模式和交换机打交道多了就会发现链路聚合最核心的对接场景有两类一类是交换机连服务器另一类是交换机上联另一台交换机。服务器这块的门道尤其多。Linux 服务器的双网卡绑定通常有三种模式mode 1主备模式、mode 4LACP 动态聚合、mode 6负载均衡但不协商。Windows 服务器则是通过 NIC Teaming 功能实现也支持静态聚合和 LACP 两种方式。这里最容易出问题的是 mode 4 和交换机 LACP 状态的匹配。Linux 的 mode 4 对应的是 802.3ad 动态链路聚合它要求交换机侧必须开启 LACP也就是华为交换机上的 lacp-static 模式。如果你交换机侧配了手工模式服务器侧又是 mode 4两边根本谈不拢链路起不来。反过来Linux 的 mode 6 是自适应负载均衡不依赖对端但它也不跑 LACP所以交换机侧反而配置手工模式更合适。很多初学者在这里绕晕核心原因是没有理清“LACP 是一种协议必须两端都跑才生效”。4.2 华为交换机与服务器对接的配置要点和服务器对接时有几个细节我不止一次踩过坑。第一个是服务器网卡的驱动和 bond 支持情况。有些网卡在 BIOS 里就把两个口的 SR-IOV 或者 VLAN 卸载功能打开了这会导致 LACP 报文被接口硬件处理掉交换机侧看到的 LACP 协商状态是空的。遇到这种情况先进服务器 BIOS 关掉无关的硬件卸载功能再试。第二个是服务器网卡如果用的是 Intel 的 i350 系列建议把两个口的 LLDP 功能关闭。因为部分网卡固件会周期性地发出 LLDP 报文在某些交换机型号上会被当成非法报文处理进而影响整个 Eth-Trunk 的协商状态。这不是普遍问题但我在 S5735 上真实遇到过关掉 LLDP 后问题消失。第三个是线缆问题。接入服务器时很多人随手扯两根同颜色的网线接上去没注意线序和速率协商情况。如果两根线一根协商成了千兆全双工另一根协商成了百兆Eth-Trunk 虽然也能起来但带宽直接缩水一大截。查问题时第一件事永远是检查物理口的速率双工状态。4.3 上联汇聚交换机的聚合设计交换机上联另一台交换机时聚合的目的一般有两层第一层是带宽扩容第二层是路径冗余。三层组网里接入交换机做 Eth-Trunk 上联汇聚交换机汇聚交换机同样做 Eth-Trunk 对接两端都要配置对应模式。上联场景的负载分担算法要和下联业务匹配起来想。假如接入交换机下面挂的都是监控摄像头流量是从下往上走的每条流的源 IP 是各摄像头目的 IP 是录像服务器。这类多源单目的流量用 src-ip 做哈希可能不够均匀建议用 src-dst-ip 或者 src-dst-mac让不同摄像头分流到不同上行链路。另外上联场景要注意两台交换机之间的链路聚合和 STP 的协作。虽然 Eth-Trunk 本身解决了环路问题但如果 Eth-Trunk 接口的 STP 开销计算不当在部分复杂拓扑下可能造成阻塞。我一般建议在核心交换机的 Eth-Trunk 上启用 STP 边缘端口或者使用 PortFast 相关特性减少不必要的收敛等待时间。5. 高频故障与排查实录5.1 聚合接口一直是 DOWN这个问题的排查思路其实和普通接口 DOWN 差不多但多了一个维度。先看物理口状态display interface GigabitEthernet0/0/1如果物理口是 DOWN检查网线、光模块、对端设备是否开启。如果物理口是 UP 但 Eth-Trunk 是 DOWN问题多半出在协商环节。LACP 模式下用下面的命令看 LACP 报文收发计数display lacp statistics如果能看到报文计数在增长说明协商报文正在交互只是某个参数不匹配导致无法达成一致。此时重点核对两端模式、接口速率、双工模式、允许的 VLAN 是否一致。如果报文计数为 0说明一端根本没有发出 LACP 报文优先查对端设备的模式是否配置正确以及接口是否被 shutdown。5.2 流量全走一条物理链路流量不均匀是聚合部署后最常见的抱怨。遇到这种情况先不要怀疑设备故障严格执行以下排查顺序。第一步确认流量是单流还是多流。单流场景下流量集中在一根链路上是正常现象哈希机制决定的换哪种算法都一样。第二步查看 Eth-Trunk 下负载分担的算法display eth-trunk 1看 Load-balance 字段如果显示 dst-ip 或者 src-ip而你的业务是典型的多源多目流量可以换成 src-dst-ip 或者 src-dst-mac 再观察。第三步用流量统计确认各成员口实际转发字节数是否均衡display interface GigabitEthernet0/0/1 display interface GigabitEthernet0/0/2对比两个口的 Input/Output 字节数。如果差距很大大概率是哈希算法不合适或者哈希因子里的特征字段在业务流量里变化不大。比如业务是服务器之间的大文件备份源目 IP 就那几对无论用什么哈希算法都会固定映射到同一条链路上。5.3 业务时通时断这种问题最头疼因为表面看链路是 UP 的。经验告诉我时通时断大概率是物理链路不稳定或者成员口频繁抖动导致聚合反复重协商。先用日志排查。在系统视图下执行display logbuffer看有没有接口 Down/Up 的反复记录。如果有检查光模块的光功率或网线的水晶头质量。尤其是光模块使用时间长了之后光衰会加大初期表现为偶发 CRC 错误后期就是接口频繁闪断。再检查 Eth-Trunk 的成员口统计display interface GigabitEthernet0/0/1看 CRC 错误和 Input Error 是否持续增长。如果有基本可以定位是物理层问题链路聚合在这里是背锅的真正的故障点在对端设备、光模块或者线缆上。还有一种可能VLAN 配置不一致导致部分报文被丢弃。比如交换机侧 Eth-Trunk 放通了 VLAN 10 和 VLAN 20但服务器网卡侧只配了 VLAN 10 的 IP。VLAN 20 的流量到了服务器后无法处理应用层面就会出现间歇性不通。排查时用 display vlan 和服务器侧网卡配置逐一核对。5.4 聚合链路成员口配置冲突这个坑出现在把物理口加入 Eth-Trunk 的瞬间。如果物理口之前配过 port link-type、port default vlan 之类的命令加入 Eth-Trunk 时可能会报错比如 “Error: The port is a member of a link aggregation group” 或者 “Error: Please remove the ports configuration first”。解决办法是在加入之前把物理口配置清干净。华为设备上恢复接口默认配置的命令是interface GigabitEthernet0/0/1 default执行后接口回到初始状态再绑定 eth-trunk 1就不会有历史配置干扰。这个操作在生产设备上要谨慎它会清掉该接口下的所有业务配置操作前务必确认接口没有承载在线业务。5.5 排查命令速查表场景排查命令关键结果查看聚合状态display eth-trunk 1成员口 Selected/Unselected 状态查看LACP协商明细display lacp statistics报文收发计数是否正常查看成员口物理状态display interface GigabitEthernet0/0/1端口Up/Down、CRC错误、速率双工查看负载分担结果display eth-trunk 1Load-balance 算法、各成员口流量占比查看VLAN放通display trunkmembership eth-trunk 1VLAN列表是否包含业务VLAN查看历史日志display logbuffer接口闪断记录、协议协商告警最后再分享一个小经验。链路聚合这类问题八成以上不是配置错而是物理层或者模式不匹配导致的。我在现场排查时永远先看物理口状态、再看协议计数、最后才动配置。配置改来改去最浪费时间而且容易把原来正常的配置改坏。链路聚合本身不复杂复杂的是它藏在各种协议、物理介质、业务模型交织的角落里。把上面这些排查思路吃透你处理聚合问题的速度会快很多。