★ FEATURED ARTICLE 干运维这些年我越来越觉得端口聚合华为设备上叫 Eth-Trunk是交换机配置里性价比最高的功能之一。不管你是刚接手公司网络的半个新手还是天天泡机房的资深工程师只要遇到上行带宽不够、担心单条链路断掉或者觉得现有冗余链路在传统生成树里被白白浪费迟早都要跟它打交道。华为交换机的端口聚合核心思路很简单把多个物理接口绑成一个逻辑接口带宽由一根变成多根链路之间还能互为备份。这篇文章不打算从厂商PPT里抄原理就按我实际配设备时的步骤和踩过的坑来写希望能让正在为链路瓶颈发愁的人少走弯路。1. 为什么需要端口聚合从带宽和断网说起1.1 单条链路的天花板我接过最典型的需求是客户说办公网一到月底就卡成幻灯片。登录后台一看核心交换机到汇聚交换机只接了一根千兆线平时百来号人用着还行一到财务批量导数据整条链路直接逼近100%。这种情况就是典型的单链路瓶颈一根千兆口理论极限只有1000Mbps刨去二层封装开销实际可用大概900多Mbps业务峰值一旦超过这个值拥塞和丢包必然出现。有人可能会说直接换万兆口不就行了问题的关键在于万兆不仅涉及光模块和跳线成本老设备可能根本没有对应接口整机更换的预算就更大。端口聚合的价值恰好在这里用两根或四根千兆线组成一个 Eth-Trunk逻辑带宽从一根变成多根整体吞吐能成倍往上走成本和改造成本却低很多。不过要注意这种“成倍”并不是所有场景都严格等于2倍、4倍具体效果取决于负载分担算法和业务流数量后面我会单独展开讲。它可以做到的是让单根链路的带宽天花板被打破让网络拥有继续往上扩展的余地。1.2 链路冗余比带宽更重要带宽是显性收益但真正让端口聚合成为核心链路标配的是它的冗余能力。物理线路其实很脆弱光模块热了会误码光纤跳线被拉一下可能就产生光衰交换机电源波动也会导致单口掉线。单条链路一旦出问题依赖它转发业务的终端就全断了。端口聚合把多根物理线绑成一个逻辑口之后其中一根线断开流量会自动调度到其他成员口业务可能只是出现毫秒级抖动不会全线断网。可以拿交通打个比方单链路就像一个人走独木桥桥一塌就没路了聚合链路像多车道公路一条车道封闭其他车道照样能走。这个特性在服务器上联、汇聚交换机互联、存储网络接入这些场景里尤其重要。我在给核心链路做改造时基本都是把聚合当作默认选项而不是等故障发生了再去补救。1.3 与 STP 的关系很多新手会把端口聚合和生成树协议搞混甚至在一堆冗余链路上同时跑了多个物理连接结果被 STP 阻塞得带宽没叠加还整天担心环路。这里要分清楚STP 的目的是防环代价是被阻塞的冗余链路不能收发业务端口聚合则是主动把多条链路合并成一条逻辑链路由负载分担算法把流量散到各成员口既避免环路又充分利用带宽。Eth-Trunk 作为一个逻辑接口参与 STP逻辑口之间照常跑生成树成员口之间不再单独计算二层拓扑会干净很多。如果在核心链路上同时存在多个物理连接正确做法是把它们聚合成一个 Eth-Trunk而不是靠生成树把某几条阻塞掉。这是我设计网络拓扑时的第一判断能聚合就先聚合别让冗余链路闲着。2. 华为端口聚合的两种工作模式手工与 LACP2.1 手工模式简单直接的硬捆绑华为 Eth-Trunk 最早给人印象最深的就是手工模式。从名字就能看出来链路两端不跑任何协商协议直接把物理接口手工塞进同一个 Eth-Trunk绑完就生效。我早期给一台老设备做对接时对端交换机根本不支持 LACP就只能在华为侧用手工模式把两根线分别加进聚合组对端做静态聚合两边居然也跑得挺稳定。手工模式的优势是简单、兼容性好。只要对端同样具备链路聚合能力哪怕设备比较老、品牌不一样也能对接成功。但它的短板非常明显缺乏对链路质量的主动感知。如果某根光纤出现单向故障比如一端能收不能发物理层可能仍然显示 UP手工模式不会把故障成员口自动摘掉流量还会继续往这条坏链路上打丢包率瞬间拉满。这类故障在实际运维里非常难排查因为接口状态是 UP 的很容易被误判为网络正常。所以从安全角度讲现在能用 LACP 的场景我基本不建议用手工模式。2.2 LACP 模式带协商的自动聚合LACP 是 IEEE 802.3ad 标准定义的链路聚合控制协议华为交换机的 Eth-Trunk 支持把它作为工作模式官方叫法通常对应静态 LACP。它的工作机制可以理解成两端的端口通过互相发送 LACPDU 报文协商确认速率、双工、成员关系、对端能力都匹配后才把成员口置为 Selected 状态参与转发。LACP 的故障检测也很有价值。设备会持续发送 LACPDU如果一段时间收不到对端报文LACP 就认为这个成员口出问题了自动把它从聚合组里摘掉流量立刻转移到其他正常成员口。这个机制比手工模式可靠很多尤其是遇到光模块不稳定、对端板卡重启这类很难从物理层直接发现的隐患。两台华为设备对接时我几乎无脑选 LACP 模式。LACP 还分 Active主动和 Passive被动两种角力至少一端是 Active 才会开始协商。实际配置里我建议两端都配成 Active省得因为协商角色问题导致一条链路迟迟起不来。2.3 模式选择对比表对比项手工模式LACP 模式协商机制无协商两端各自绑定通过 LACPDU 协商故障感知主要依赖物理层 down支持报文超时检测配置复杂度低略高对端兼容性适合老设备与跨厂商对接需要双方支持标准 LACP典型场景简单二层聚合、非标设备对接核心链路、跨设备聚合、服务器接入一句话总结如果你想快速上线又不怕链路质量隐蔽故障手工模式可以用如果是核心链路最好把 LACP 模式当成底线。选择模式这件事比选择端口聚合本身更影响后续排障体验。3. 配置前的关键准备不规划好会白干3.1 速率、双工与 VLAN 一致性很多人在现场兴冲冲配完发现只有一根线在跑第一反应是查光路和模块结果物理层全正常。最后才发现是成员口速率不一致一根千兆、一根百兆LACP 协商后百兆口要么处于 Unselected 状态要么被直接剔除。华为对 Eth-Trunk 成员口的基本要求是速率和双工保持一致这点在动手之前必须用 display interface 确认清楚。我见过太多跳过这一步的人最后被一个隐藏在接口属性里的“speed 100”坑到怀疑人生。成员口的二层属性也要统一不能一个口是 trunk、一个口是 access更不能允许通过的 VLAN 不一致否则会出现通但丢包的奇怪现象。我的习惯是在规划表里先写下每一根线的速率、双工、VLAN、对端设备型号核对无误后才碰命令。这个方法看起来笨但能省掉后面一大半排错时间。3.2 成员数量与带宽计算华为盒式交换机一个 Eth-Trunk 最多支持 8 个成员口具体数量还要查对应设备型号的规格框式设备可能更多。我建议配置前就确认规格别等把口加进去时报错再回头查手册。带宽也别太乐观。两个千兆聚合很多非网络背景的同学直接等同于 2000Mbps实际并不是简单相加。负载分担机制是把一个个数据流通过哈希算法分到不同成员口如果只有一个大流量连接比如一个 FTP 传输这个流只会走一个成员口带宽仍然是 1G。多路并发时聚合才能体现出接近 N 倍的吞吐。所以测试聚合效果时一定用多线程传输做实测而不是只看端口 speed 和 negotiation。3.3 接口残余配置华为交换机在把物理接口加入 Eth-Trunk 时如果接口上已经存在 port link-type、port trunk allow-pass vlan 或者 shutdown 这类配置大概率会报错接口加不进去。原因在于成员口的属性必须继承 Eth-Trunk 逻辑口的属性物理口上的独立配置会和逻辑口发生冲突。现场经常有人反复敲 eth-trunk 1 一直报错其实是忘了清理残余配置。标准做法是把接口先恢复成默认状态比如挨个执行 undo shutdown、undo port link-type或者直接用 clear configuration interface 清掉再操作。另外要先创建 Eth-Trunk 逻辑口再进物理口绑定顺序反了容易出现各种莫名其妙的现象。我的经验是逻辑口先建好属性先配好物理口只是做加法这个顺序最省心。4. 完整配置实操从零做一个可用的 Eth-Trunk4.1 二层手工模式配置示例华为 S 系列交换机上一个常见的手工模式二层聚合配置可以这样写system-view sysname SW-A interface Eth-Trunk 1 port link-type trunk port trunk allow-pass vlan 10 20 quit interface GigabitEthernet0/0/1 eth-trunk 1 quit interface GigabitEthernet0/0/2 eth-trunk 1 quit注意一个关键点Eth-Trunk 逻辑口的属性是放在 Eth-Trunk 1 视图下配置的物理口下只需要写 eth-trunk 1 这一行。配完后用 display eth-trunk 1 查看本地应该能看到两个成员口状态都是 Selected。对端配置如果一致逻辑链路就通了。我习惯于把两端对接的物理口编号规划成一样的比如都使用 GE0/0/1 和 GE0/0/2。实际上华为的 Eth-Trunk 编号是本地概念不要求对端必须一致但统一编号在后续协作排查时会非常舒服。手工模式最大的特点是配置速度快几分钟就能完成一组链路但别高兴太早前面提到的链路质量感知问题会一直潜伏在现网里。4.2 二层 LACP 模式配置示例LACP 模式配置也很直接只需要在 Eth-Trunk 视图下把模式切到 lacp-static再按同样的方式加成员口system-view interface Eth-Trunk 1 mode lacp-static port link-type trunk port trunk allow-pass vlan 10 20 quit interface GigabitEthernet0/0/1 eth-trunk 1 quit interface GigabitEthernet0/0/2 eth-trunk 1 quit两端都要切成 LACP 模式至少一端保持 Active 才能协商起来。华为默认的系统优先级是 32768如果两条链路的端口优先级、系统优先级都一样系统会进一步比较系统 MAC 地址来决定主动端。大多数场景下保持默认优先级就能正常工作但我建议在核心设备上主动把优先级调清楚避免两台设备因为优先级胶着产生不必要的状态切换。配置完用 display lacp statistics 看 LACPDU 收包数量。如果一侧一直收不到对端报文优先检查两端模式和物理状态。display eth-trunk 1 也能看到 LACP 模式下 Selected 成员口数量。刚才配置过程中我一般会先把模式切好再动成员口这样即使物理口加到一半也不会出现模式不匹配导致的中间状态。4.3 三层路由口聚合有时候需要在 Eth-Trunk 上配置 IP 地址让它作为三层路由口工作。这种场景在交换机连接防火墙、路由器或服务器网关时很常见。配置的关键是先把逻辑口切换成三层口system-view interface Eth-Trunk 2 undo portswitch ip address 192.168.10.1 255.255.255.0 quit interface GigabitEthernet0/0/3 undo portswitch eth-trunk 2 quit华为 S 系列默认接口是二层口所以逻辑口要做 undo portswitch物理口也尽量先做同样操作再绑定。不同版本对“物理口自动跟随逻辑口属性”的处理方式会有差异稳妥起见还是逐口执行一遍。创建 Eth-Trunk 后要第一时间把它切成三层口再配 IP等物理口加进来之后再切部分设备会跳警告甚至提示配置失败。我的习惯是“属性先行成员后加”这个顺序能避开不少版本坑。4.4 负载分担方式与选型Eth-Trunk 的负载分担方式直接影响带宽利用率华为设备默认模式在不同版本里并不完全一致常见的是基于源目 MAC 或源目 IP。我们可以手动调整在 Eth-Trunk 视图下执行interface Eth-Trunk 1 load-balance src-dst-ip命令里的参数还有很多比如 src-mac、dst-mac、src-dst-mac、src-ip、dst-ip 等具体以设备支持为准。怎么选如果业务主要是内网终端访问服务器源和目标都是固定 IP基于源目 IP 做哈希比较合适如果是二层交换场景MAC 变化更大基于 MAC 效果更好如果集群里有大量短连接选择四元组或源目 IP 能分散得比较均匀。最怕的是单个大流量业务比如数据库全量备份、视频点播的大流它只对应一个五元组哈希算法再精巧也只能把整条流放到一个成员口上。这种情况不是聚合方案不行而是业务本身就是单流独享。实在要突破要么业务层开多线程并发要么直接换更高速率的接口。我在实际项目里见过有人因为单流测试结果不好就否定了整个聚合方案其实换多线程压测之后效果立竿见影。4.5 跨设备 Eth-Trunk华为的堆叠环境下可以把 Eth-Trunk 的成员口分布在不同成员交换机上组成跨设备聚合链路。比如两台交换机堆叠成一台逻辑交换机上联的 Eth-Trunk 1 里有两条线分别插在成员设备 1 和成员设备 2 上对端还是一个普通 Eth-Trunk就能把流量均衡散到这两条线上。即使其中一台堆叠成员宕机另一条成员口依然能承载流量核心链路不会全断。这种场景强烈建议使用 LACP 模式因为跨设备聚合需要感知对端成员状态手工模式做不到那么细致的联动。配置方法本身并不复杂仍然是在 Eth-Trunk 视图下加入不同板卡上的物理口不需要在主控上写额外魔法命令。如果你刚接触堆叠可以先把普通 Eth-Trunk 配熟理解清除成员口与逻辑口的关系之后再进阶到跨设备聚合。5. 故障排查与常见问题实录5.1 物理口加入不进去报错提示五花八门常见的有 The port is not supported、The port has been added to another Eth-Trunk或者干脆提示接口配置冲突。排查思路第一步进入接口视图执行 display this看下有没有隐藏的 eth-trunk、链路类型、shutdown 等配置第二步确认接口是不是已经被别的 Eth-Trunk 占用第三步用 clear configuration interface 清掉接口配置再重新绑定。这里要提醒清配置会导致接口 down尽量选在维护窗口操作。我遇到过一次比较隐蔽的情况接口没有报错但 display eth-trunk 一看组成员是空的业务当然不通。后来发现是接口被误加到了另一个聚合组里两边配置看起来都对实际上“身”已在别处。所以任何一次成员口变更后都要回看一下聚合组列表。5.2 逻辑口状态为 Down逻辑口 Down 不一定意味着物理口 Down排查还是一层层来。先看物理层display interface 看每个成员口的光功率、收发光状态再看两端 Eth-Trunk 编号和模式是否匹配。手工模式对端必须也配了聚合LACP 模式对端必须是 LACP模式不对会直接导致逻辑口 Down。还有个容易忽略的点对端交换机可能也建了 Eth-Trunk但成员口加错了或者只加了一根线导致带宽不对称。配置不合理的情况下Eth-Trunk 可能显示 Down也可能只有部分成员 Selected伴随业务丢包。用 display eth-trunk 1 看本端 Selected 数量如果本端正常但对端不对现象依然是逻辑口 Down。所以跨设备排查时不要让交换机只当“单机”看两端输出一定要拉在一起对比。5.3 LACP 协商不正常表现是 display lacp statistics 里收包不增长或者协议状态一直在 Init。常见原因有两端模式不一致手工模式对 LACP 模式不可能协商成功一边 Active 一边 Passive 没问题但两端都是 Passive 就永远不主动发报文物理链路本身质量问题导致报文丢失这个在长距离光路上尤其明显。LACP 的 actor system id 由系统优先级和系统 MAC 组成当两台设备的优先级和端口优先级都一样时最终会比较系统 MAC 决定主动端。如果在配置里发现角色不对可以手工降低某一端的 lacp system-priority数字越小优先级越高。修改后在两端都会重新协商通常很快就能恢复。排查 LACP 问题时我总爱说一句顺口溜先看物理再看模式最后查优先级。5.4 成员口处于 Unselected 状态Selected 才是可用状态Unselected 意味着这个口不参与转发。最常见原因是速率或双工不一致比如一根千兆、一根百兆另一个常见原因是本端选择策略和对端不匹配对端没有把对应口加进同一个聚合组。使用 display eth-trunk 1 verbose 查看时华为设备会提示端口未被选中的原因比如本地端口速率与对端不一致。真正排查时先看物理层配置再拉两端 display 输出做对比。我遇到过一例让人印象很深的问题客户两边都是千兆电口但一根线用的是五类线一根是超五类线协商速率都显示千兆可其中一根线的误码率很高被 LACP 认定为弱链路从而置为 Unselected。换了一根正规的超六类线后问题立刻消失。这类问题表面上看像配置根子其实在线缆质量。5.5 流量集中在个别成员口负载分担效果差先别急着怀疑设备坏了。打开 display interface 看每个成员口流量如果其中一根几乎满负荷、其他几根只有零星流量那大概率是哈希维度和流量模型不匹配。比如业务几乎都是同一对终端之间的长连接基于 MAC 或 IP 的哈希就区分不开流量自然压在同一个口上。这时先改负载分担模式把模式切到 src-dst-ip 试试。如果还是不行就要考虑业务本身是单流还是多流。压力测试最直观跑一个单线程大文件传输流量肯定集中在单口改成多线程并发下载就能看到多个成员口同时分摊。这个特性对运维判断很重要做扩容结论时不要拿单流测试结果去否定聚合效果至少也要用多流并发验证一轮。5.6 手工模式下的假活与 LACP 超时前面提过手工模式无法感知单向光路这是很多现网故障的背锅侠。场景很典型光纤收发异常导致一根成员口收包正常但发包异常物理层显示 UP手工聚合也不知道该摘掉它于是流量发出去就丢。排查这种问题要把接口下的入方向和出方向计数器放一起看。如果发现入方向计数增长、出方向计数不涨或剧烈异常大概率就是链路质量问题。LACP 模式通过 LACPDU 超时可以更快感知这种状态默认超时时间在不同设备上不一样通常比手工模式“看不见”的窗口短得多。实践里核心链路建议用 LACP并可以结合设备支持情况把超时时间配短一点让故障链路尽快被摘除减少丢包窗口。如果非要用手工模式一定得有配套的链路质量监控否则等于在核心链路上埋雷。5.7 聚合口对端错接引起的环路风险再补一个特别容易被忽略的坑Eth-Trunk 成员口必须连接到同一台对端设备或者连接到同一个堆叠系统。如果一根线接设备 A另一根线接设备 B而 A 和 B 之间存在二层互通Eth-Trunk 就会把两台设备通过两条独立链路连接起来拓扑上等于出现了环路很可能引发广播风暴或 STP 频繁震荡。华为设备在部分场景下能通过错误检测把端口置为 Down但不是所有型号都能完美处理。所以每次插线前一定要核对对端设备不要只看标签可以用命令确认对端信息。很多“上午还好好的下午狂掉线”的问题最后都指向一根线的物理位置差异。端口聚合配置本身再正确物理接错一样白搭这类问题在多人协作的机房里尤其容易发生。6. 多年配下来的几点实操心得6.1 配置顺序和变更习惯我自己的标准流程是先做规划清单再在维护窗口把两端 Eth-Trunk 建好配置成员口最后用 display 逐项核对。每次只加一根线观察状态稳定后再加第二根。不要图快一次性把四根线全部加进去批量变更一旦出错排错范围会变得特别大。变更前备份配置、变更后保存配置这两步永远不能省。设备重启后如果配置没保存聚合配置就会全部丢失业务直接就断。有个晚上我帮一位同行做远程支持他设备配置明明能看到但 display eth-trunk 却查不到任何成员口最后发现是上次调试后没有保存设备重启后全没了。从那以后我养成了一个习惯每次配置完顺手保存不管当天是否还要继续改动。6.2 LACP 模式是核心链路的底线能上 LACP 就尽量上这句话我已经说了好几遍因为我这些年踩过太多手工模式的坑。手工模式虽然配置起来最爽但故障感知弱面对单向光路、光电转换器异常这类故障几乎没脾气。LACP 模式再配合堆叠做跨设备聚合核心链路的可靠性能明显上一个台阶。给服务器接双网卡时还容易遇到另一个隐藏坑服务器网卡驱动里的链路聚合模式必须和交换机对齐常见是 LACP。如果服务器做普通双网卡绑定但交换机口配成手工聚合现象同样是链路协商不上。我处理过很多次虚拟机网络偶发断流的案例最后都出在这种模式不匹配上。所以配置网络之前最好先确认一下服务器操作系统和网卡驱动里支持的聚合模式到底是什么。6.3 通过计数器和负载分担视图定位问题排查 Eth-Trunk 时不要只盯着 display eth-trunk 1 看还要看每个成员口的接口计数器和错误计数器。重点看 InUti、OutUti 以及 CRC 错误、FCS 错误有没有连续增长。如果某个成员口流量长期为 0 但状态是 Selected优先怀疑负载分担算法把哈希结果集中到了别的口如果错误计数持续增长那就要怀疑光模块、光纤跳线或者网卡协商问题。另外部分华为设备版本上可以用 display load-balance info 查看当前 Eth-Trunk 实际生效的负载分担方式避免你凭记忆判断配置。把这些输出和前一天的做对比很多疑难杂症往往能被定位为三类链路质量劣化、配置漂移、哈希不均。有一次线上流量异常我把两个成员口计数器截图对比发现其中一个口 FCS 错误在持续涨最后查出来是一根跳线受到机房空调冷凝水影响换了线之后一切恢复正常。6.4 容量规划与切换演练端口聚合虽然增加了带宽和冗余但容量规划时还要考虑最坏情况。比如聚合组只有两根千兆线长期峰值跑到 1.6Gbps这个状态其实很危险因为一旦一根线故障剩下的一根只有 1Gbps必然出现拥塞。我一般建议在峰值利用率不超过单根链路容量 70% 的范围内规划留出单成员故障下的缓冲空间。另外建议定期做切换演练手动 shutdown 一个成员口观察业务是否平稳、流量是否快速切到其他成员口然后再恢复。这种演练花费时间不多却能让你提前发现聚合配置里隐藏的问题。很多人配完 Eth-Trunk 后从来没做过故障切换测试真出事的时候才发现对端模式不匹配或者负载分担异常后悔都来不及。网络运维就是这样配置成功只是开始验证和持续监控才是真正让链路稳定运行的关键。
阅读完成 · 觉得有帮助？
