ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

华三交换机链路聚合配置实战:从原理到排障

华三交换机链路聚合配置实战:从原理到排障 1. 这个需求背后到底要解决什么问题1.1 链路聚合不是“两根线插一起”这么简单先说点实际的。接到“华三交换机链路聚合”这个需求最常出现的场景是服务器双网卡想合并带宽、核心交换机到汇聚交换机之间两条光路想打满、或者监控平台NVR接入带宽不够用。很多刚入行的朋友第一反应是“多插几根网线不就行了”但真这么做会出大问题——STP生成树协议会把冗余链路里的某一条Block掉环路直接给你掐断带宽不但没提升反而只有一条线路在干活。链路聚合Link Aggregation解决的核心问题有两个一是把多条物理链路逻辑上绑成一条虚拟链路带宽可以叠加二是物理链路之间形成冗余断一根线业务不中断。华三体系里这个技术叫Bridge-Aggregation对应的接口叫BAGG口成员端口通过聚合组统一管理上层业务看到的只是一条逻辑链路跑路由、跑VLAN、跑ACL都不受影响。做网络的朋友都清楚这叫“逻辑归一、物理冗余”本质上是把网络拓扑从网状收敛成树状/星状从根上规避环路风险。1.2 静态聚合还是动态聚合方案选型思路很多初学者做链路聚合上来就敲命令结果对端设备一换模式就全乱套。这里先说清楚两种模式的取舍后面配置才能心里有底。静态聚合华三也叫手工聚合所有成员口加入聚合组之后不需要协商直接全部选中汇聚带宽立马上来。优点是实现简单、兼容性好缺点是两端配置没有握手校验一旦对端某根线断了或者拔了本端感知不到业务流量可能往坏链路上硬塞出现丢包。适用于设备同品牌、链路质量有保障、网络规模较小的场景。动态聚合走的是LACPIEEE 802.3ad标准本端和对端通过LACPDU报文协商端口状态双方确认无误的端口才会被选中转发流量。两端有一端的成员口配置有问题这个端口就会被自动排除在聚合组之外不会出现“明明线断了还在转发”的蠢事。华三交换机上绝大多数生产环境我建议用动态聚合因为网络是动态变化的协商机制能省掉很多半夜排障的麻烦。选择模式时还要考虑对端设备。如果对端是服务器Windows下的NIC Teaming、Linux下的bonding、hyper-v虚拟交换机的外部虚拟交换机这些都有各自的协商模式要和对端对齐。如果对端是华为、锐捷的交换机虽然都是LACP协议但各家实现细节还是有差异建议优先用标准LACP模式兼容性最好。1.3 哪些场景真正需要链路聚合链路聚合不是摆设但它也不是万能的。根据我这些年接触过的项目真正值得上的场景集中在几类第一类是服务器接入带宽扩容尤其是数据库、备份服务器、存储网关单块千兆网卡跑备份能跑一整天双千兆聚合之后虽然不可能翻倍到2000Mbps要看流量哈希是否均匀但实际能跑到1200Mbps到1600Mbps体感提升巨大。第二类是交换机之间级联或上联比如办公网两台汇聚交换机之间或者汇聚上联核心两条满载的万兆/千兆链路做聚合既提升带宽又做高可用。第三类是监控网络的核心侧现在动辄几十路400万像素摄像头核心交换机到NVR之间不打聚合并发流量一高就丢帧。但也要泼一盆冷水一条千兆带宽都没跑满的业务链路聚合除了多做一套配置外没有任何意义三条以上光路聚合收益递减出问题排查复杂度指数上升。所以动手之前先看流量监控数据别为了“听起来很专业”而上聚合。2. 华三链路聚合的底层逻辑不懂原理配置就是碰运气2.1 聚合组、成员端口、选中状态是怎么协同的华三交换机的链路聚合核心组件有三个聚合接口Bridge-Aggregation Interface、聚合组Aggregation Group、成员端口Member Ports。聚合接口是网络工程师眼中真正参与三层/二层转发的逻辑口它有自己的接口编号比如Bridge-Aggregation 1可以配置IP、VLAN、Trunk属性。聚合组是成员端口的集合本质上是一张“候选端口清单”。成员端口就是物理口它们的职责是“出苦力”——实际转发数据报文。聚合组里的端口有三种状态Selected选中、Unselected未选中、Standby备用。只有Selected状态的端口才会真正转发业务流量Unselected端口虽然加入聚合组但不转发可能因为速率、双工模式、对端配置等问题被排除Standby是动态聚合特有的概念当Selected端口超过最大可用端口数时多出来的就进Standby备用一旦前面端口故障就顶上。这里有一个华三特有的点同一个聚合组里的Selected端口要求速率和双工模式必须一致一个千兆口和一个百兆口硬要凑在一起低速率那个会被强制Unselected。这个在组网接入层很常见扩容时新换的千兆交换机和老的百兆设备对接一定要检查两端速率。2.2 参考端口是怎么选出来的华三设备在协商链路聚合状态时会从聚合组里挑一个“参考端口”Reference Port以它的属性作为标准其他端口只有属性全一致才有资格成为Selected。参考端口的选择顺序有讲究我梳理成了一张表方便记忆优先级判断条件说明1端口是否UP优先选状态为UP的端口2全双工优先全双工端口优先于半双工3端口速率高速率优先于低速率4端口编号编号小的优先举个真实场景聚合组里A口是千兆全双工UPB口是百兆全双工UP那A口就是参考端口B口因为速率不一致被Unselected。如果A、B速率一样A口编号小A口是参考端口。这一切都是设备自动完成的不需要人工指定。但理解参考端口的意义在于排查问题的时候你第一件事就是看哪几个口是Selected而不是傻盯着VLAN配置。2.3 流量到底怎么分摊出去链路聚合的带宽叠加靠的是哈希分发Load Sharing不是“发一个包轮着走”这么简单。华三默认的聚合负载分担方式是根据报文的源MAC和目的MAC做异或运算算出哈希值后映射到某个成员端口上。方向不同分担粒度不同二层转发看MAC三层转发看源目IP四层还可以看源目端口。这个机制带来一个关键的认知链路聚合提升的是“多流并发”的总带宽而不是“单条流”的带宽。比如你从服务器往客户端传一个大文件这条大流量属于同一条流哈希只会打在某个固定成员口上即使聚合了4条物理链路单流速度也上不去。想提升单流性能唯一的办法是让应用程序支持多连接并发或者用基于IP/端口的负载分担让不同连接散出去。华三设备支持修改负载分担模式命令在系统视图下配link-aggregation load-sharing mode destination-ip按目的IP分担link-aggregation load-sharing mode source-ip按源IP分担link-aggregation load-sharing mode source-mac destination-mac按源目MAC分担具体选哪种要看业务模型是“多对一”监控流量汇聚还是“一对多”服务器分发。我常用的思路转发模型以服务器为主就在核心交换机上改成按目的IP分担以接入交换机收敛为主就按源目MAC分担。改完要观察一段时间流量分布别指望哈希一次就完美均匀。2.4 二层聚合和三层聚合的边界要分清楚华三的Bridge-Aggregation接口根据配置的链路类型分为二层聚合和三层聚合。二层聚合口需要和成员口一起配置PVID、Trunk、Hybrid属性业务流量按普通二层转发三层聚合口直接给BAGG接口配IP地址做路由口用常用于交换机之间的三层互联、VRRP上行口等场景。二层转三层或者三层转二层不能直接敲命令改必须先把聚合口undo掉重新创建。这个坑不少人在开局配置时踩过建了BAGG 1做二层Trunk后来想改成三层互联直接在上面配IP提示错误原因就是接口类型没变。所以开局就要规划好这个聚合口是走二层还是三层不要图省事后面硬改。3. 手把手实操从登录到命令交付的完整流程3.1 登录设备与现状摸底配置链路聚合之前先花五分钟做现状摸底能省掉后面一半的排障时间。登录方式不展开说了Console线、Telnet、SSH都行。重点是四条命令H3C system-view [H3C] display interface brief [H3C] display stp brief [H3C] display vlan第一条看接口的物理状态和速率第二条看生成树状态避免聚合后STP产生阻塞同时心里有数第三条看VLAN规划。这个阶段重点确认几点物理光口/电口的速率双工是否一致、对端设备型号和接口编号、业务VLAN范围。我习惯把这些信息记在草稿纸上配的时候对照着来不容易错。3.2 静态链路聚合配置全流程华三默认V7版本里创建聚合口后聚合口默认就是静态模式不需要额外敲模式命令。下面是完整配置示例以一个核心交换机上联另一个交换机为例H3C system-view # 创建二层聚合口 [H3C] interface Bridge-Aggregation 1 [H3C-Bridge-Aggregation1] port link-type trunk [H3C-Bridge-Aggregation1] port trunk permit vlan 10 20 30 [H3C-Bridge-Aggregation1] quit # 把GigabitEthernet1/0/1加入聚合组1 [H3C] interface GigabitEthernet1/0/1 [H3C-GigabitEthernet1/0/1] port link-aggregation group 1 [H3C-GigabitEthernet1/0/1] quit # 把GigabitEthernet1/0/2加入聚合组1 [H3C] interface GigabitEthernet1/0/2 [H3C-GigabitEthernet1/0/2] port link-aggregation group 1 [H3C-GigabitEthernet1/0/2] quit这里强调一个细节成员口加入聚合组后物理口上的VLAN、Trunk、Hybrid配置全部失效统一以聚合口配置为准。所以你不需要也不应该在物理口上再敲port link-type trunk之类的命令配了也没用还容易让人误解。要检查静态聚合是否生效最核心的验证命令是H3C display link-aggregation summary输出结果里会看到聚合组1成员端口GigabitEthernet1/0/1和1/0/2状态如果都是Selected说明聚合成功带宽已经逻辑合并。如果状态是Unselected基本就是速率/双工不一致或对端未配置。3.3 动态LACP聚合配置全流程动态聚合在我这边的生产网里使用率更高。相比静态聚合多一步配置在聚合口上开启LACP模式。命令如下H3C system-view # 开启动态LACP聚合模式 [H3C] interface Bridge-Aggregation 1 [H3C-Bridge-Aggregation1] link-aggregation mode dynamic [H3C-Bridge-Aggregation1] port link-type trunk [H3C-Bridge-Aggregation1] port trunk permit vlan 10 20 30 [H3C-Bridge-Aggregation1] quit # 成员口加入聚合组 [H3C] interface GigabitEthernet1/0/1 [H3C-GigabitEthernet1/0/1] port link-aggregation group 1 [H3C-GigabitEthernet1/0/1] quit [H3C] interface GigabitEthernet1/0/2 [H3C-GigabitEthernet1/0/2] port link-aggregation group 1 [H3C-GigabitEthernet1/0/2] quit如果链路两侧都是华三到这里就完成了。验证命令一样用display link-aggregation summary但对端必须也启用LACP并且优先级一致否则协商不会通过聚合口状态可能是Down的。动态LACP模式下还可以调整系统LACP优先级用于决定哪一端作为协商主导方[H3C] lacp system-priority 100一般情况下默认值就够用只有两端设备型号差异特别大、协商出问题时才需要改这一项。我不建议新手随便改优先级改错了反而容易把正常链路搞僵。3.4 配置下发后必须做的三项验证配置敲完不验证等于白干。我每次交付链路聚合配置固定跑三遍验证聚合组状态验证display link-aggregation summary确认Selected端口数目和预期一致。如果做了4条聚合这里应该全部Selected少一个都要查。业务转发验证在两端接入的服务器或终端之间持续ping同时拔掉一根物理网线观察丢包时间。正确的行为是断线瞬间有一两秒丢包甚至不丢包随后业务自动恢复如果一直丢包说明聚合没真生效或者STP在捣乱。流量分担观察display link-aggregation load-sharing mode确认分担模式有条件的话登录对端设备、或者用流量监控工具看各成员口的流量计数确认两条线都在跑流量而不是只有一条满载。这里提醒一句v7版本下查看流量计数我习惯用H3C display interface GigabitEthernet1/0/1看Input/Output方向的速率和总字节数两根线的计数如果都往上涨说明流量在分担如果只有一根涨别急着下结论先看是不是单流传输导致的前面讲过哈希的局限。4. 真实场景拆解核心交换机与服务器、跨厂商设备怎么对接4.1 服务器双网卡聚合的配合姿势这个场景太常见了服务器两块千兆网卡想聚合交换机侧就是一台华三层交换机。华三侧配置和前面一样关键是服务器侧的模式要对上服务器bond模式交换机侧要求适用场景Linux mode 0 (round-robin)静态聚合均衡但兼容性差不建议生产Linux mode 1 (active-backup)不需要聚合普通access口即可冗余为主带宽不叠加Linux mode 2 (xor)静态聚合按哈希分担交换机必须配聚合Linux mode 4 (lacp)动态LACP聚合标准推荐生产首选Windows NIC Teaming (LACP)动态LACP聚合与Linux mode 4同理以Linux服务器为例最常见的生产配置是动态LACPbalance-alb或802.3ad。操作分两步第一步配置交换机[H3C] interface Bridge-Aggregation 10 [H3C-Bridge-Aggregation10] link-aggregation mode dynamic [H3C-Bridge-Aggregation10] port link-type access [H3C-Bridge-Aggregation10] port access vlan 100 [H3C-Bridge-Aggregation10] quit [H3C] interface GigabitEthernet1/0/24 [H3C-GigabitEthernet1/0/24] port link-aggregation group 10 [H3C-GigabitEthernet1/0/24] quit第二步Linux侧加载bonding模块并配置。以RHEL/CentOS系为例使用nmcli最直观nmcli con add type bond ifname bond0 mode 802.3ad ipv4.method manual ipv4.addresses 192.168.100.10/24 ipv4.gateway 192.168.100.1 nmcli con add type ethernet ifname eth0 master bond0 nmcli con add type ethernet ifname eth1 master bond0 nmcli con up bond0这里有个容易踩的坑服务器bond的LACP模式虽然标准但Linux内核默认的发送速度不是立即协商有时要等几秒到十几秒聚合才up。如果交换机侧配了STP边缘端口portfast等价物华三对应的是stp edged-port enable这个等待时间会大大缩短。很多运维在机房插线后看服务器网络起不来其实是LACP还在协商等一会儿就好不是配置错了。4.2 与华为、锐捷等跨厂商设备对接的坑链路聚合在跨厂商对接时踩坑概率比同品牌对接高不少。华为交换机的链路聚合口叫Eth-Trunk锐捷叫AP口或Aggregate Port虽然概念一样但命令和默认行为有差异。跨厂商对接最重要的原则把动态聚合和静态聚合明确分开。两边都用动态LACP时LACP协议是标准IEEE 802.3ad通常能协商成功。两边都用静态聚合时没有协商过程只要成员口都加入聚合组链路就up简单粗暴但也好使。最怕的是本端动态、对端静态这种配下去聚合组永远起不来。拿华为对接华三举例子华为侧配置示意HUAWEI system-view [HUAWEI] interface Eth-Trunk 1 [HUAWEI-Eth-Trunk1] mode lacp-static [HUAWEI-Eth-Trunk1] trunkport GigabitEthernet0/0/1 [HUAWEI-Eth-Trunk1] trunkport GigabitEthernet0/0/2 [HUAWEI-Eth-Trunk1] port link-type trunk [HUAWEI-Eth-Trunk1] port trunk allow-pass vlan 10 20华三侧只要对应开启动态LACP即可。如果你发现两边模式都对了还是协商不起来重点检查两端聚合组的VLAN配置是否一致、Trunk放行VID是否一致以及光模块是否兼容这个在跨厂商对接里经常出幺蛾子华三和华为都习惯用自家模块混着插有时候光功率不够导致物理口频繁UP/DOWN。锐捷的接口命名和华三比较像聚合口叫AggregatePort接入成员口命令是port-group 1模式上锐捷默认是静态。对接的时候注意模式翻译成同一套逻辑别被界面上的术语搞晕。4.3 办公网改造5个VLAN部门子网的聚合实战再举个例子之前做过一次办公网改造公司5个部门划了5个子网A部门100台主机、B部门50台、C部门20台业务VLAN 10/20/30/40/50核心换成了华三S5500系列下联汇聚交换机之间用两根千兆光路做聚合。这个场景有一个隐藏需求链路聚合不仅要通还要保证不同VLAN之间互访不因聚合哈希不均导致某个VLAN流量挤占。我当时的配置思路是核心和汇聚两端都做动态LACP聚合Trunk放行全部业务VLAN负载分担模式改成按源目IP分担因为跨VLAN互访多半是三层流按IP分担才能让5个VLAN的流量均匀散到两根物理链路上。# 核心交换机侧 [H3C] interface Bridge-Aggregation 1 [H3C-Bridge-Aggregation1] link-aggregation mode dynamic [H3C-Bridge-Aggregation1] port link-type trunk [H3C-Bridge-Aggregation1] port trunk permit vlan 10 20 30 40 50 [H3C-Bridge-Aggregation1] quit [H3C] link-aggregation load-sharing mode source-ip destination-ip [H3C] interface GigabitEthernet1/0/25 [H3C-GigabitEthernet1/0/25] port link-aggregation group 1 [H3C-GigabitEthernet1/0/25] quit [H3C] interface GigabitEthernet1/0/26 [H3C-GigabitEthernet1/0/26] port link-aggregation group 1 [H3C-GigabitEthernet1/0/26] quit汇聚交换机侧配置完全镜像。配置完检查display link-aggregation summary时发现一个问题两条物理链路都Selected了但用华三的display link-aggregation load-sharing mode看分担模式发现核心侧已经被我改成IP分担汇聚侧还是默认的MAC分担。华三的动态聚合要求两端分担模式尽量一致否则哈希结果不一致会出现流量在本端被分到1口、对端回包分到2口的情况虽然同一条流最终也能走通但来回路径不对称延迟和丢包率会变难看。所以注意负载分担模式在聚合链路两端都要设置不是只改一端。5. 常见问题与排障实录我踩过的那些坑5.1 聚合口就是不UP先查这四个点链路聚合配完发现聚合口Down不要慌按优先级排查物理口状态。display interface brief先看光口/电口是否物理UP光模块松了、光纤收发接反了、对端设备没开电源这些“低级问题”占了故障原因的一半以上。成员口是否真的加入了聚合组。display link-aggregation summary看聚合组里有没有成员或者成员口是不是处于独立状态。很多人配完发现成员口上少敲了一句port link-aggregation group 1导致物理口独立转发和聚合口形成二层环路或者干脆不通。两端模式是否一致。静态对静态、动态对动态这中间最容易出的岔子是从华三设备往华为对接时华为Eth-Trunk默认模式是静态华三侧配了动态两边没有协商。解决办法是统一两边模式。两端VLAN配置是否一致。聚合口Trunk放行的VID集合要一致PVID最好也一致。不一致时LACP协商可能正常但业务VLAN不通很多人误以为聚合失败其实是VLAN清单没对齐。5.2 带宽上不去流量全挤在一根线上这个现象我说一下原理哈希分配看的是报文特征不是端口流量实时负载。当聚合组里只有两条链路时哈希结果落入某一条链路的概率是50%如果恰好业务流量全部来自同一个源MAC或去往同一个目的IP比如数据库集群同步日志那么所有流量哈希到同一个成员口另一根线完全空闲。遇到这种问题先确认是不是单流场景然后看现有分担模式能不能适配业务模型。如果业务本身就是“多对一”收敛比如多台办公电脑访问一台文件服务器那单靠哈希很可能不均建议把分担模式改成按源MAC让不同终端散到不同物理链路效果立竿见影。另外要提醒万兆以太网聚合后的实际吞吐还受交换机背板、缓存、CPU转发能力的限制如果设备本身是低端接入型号即使聚了4条万兆口实际线速也达不到全部叠加。别拿小交换机硬扛大流量。5.3 断线闪断之后聚合起不来这个坑我碰到过不止一次拔掉一根线测试冗余结果业务彻底中断了聚合组再也起不来。后面排查发现问题出在对端设备上——对端交换机侧某根光路物理DOWN之后LACP收不到对端LACPDU于是本端把对应端口置为Unselected这是正常的。但恢复链路后如果光模块协商速度慢两端LACP协商超时聚合组迟迟不恢复期间业务就断了。解决方案是把LACP超时时间调短让协商更快恢复[H3C] interface Bridge-Aggregation 1 [H3C-Bridge-Aggregation1] lacp period shortlacp period short让LACPPDU每1秒发一次检测故障更快默认是长超时30秒。在核心链路上我会开short牺牲一点点CPU开销换切换速度非常划算。5.4 华三模拟器复现与验证引入没有现成真机的时候用华三官方模拟器HCLH3C Cloud Lab可以在虚拟环境里把链路聚合配一遍。有个使用细节HCL里部分老镜像对LACP支持不太好设备启动失败也常见。我的经验是选新版本镜像配置过程和真机几乎一致用于练命令和验证逻辑足够。模拟器里复现静态聚合、动态聚合、确认link-aggregation summary的展示格式至少让你在真机操作前不慌。不过模拟器里没法验证Optical模块、线缆质量问题所以排障经验还是得靠真机积累模拟器只是“练手和预演”的定位。5.5 一个隐蔽问题生成树与聚合的相互作用华三交换机默认开启STP链路聚合口上STP和LACP之间可能会有微妙冲突。比如成员口如果之前单独跑过STP可能在端口状态上残留了Blocking加入聚合组后状态更新不及时导致流量不走这个口。我通常的处理方法对下联服务器的聚合口开启边缘端口stp edged-port enable让端口快速进入转发状态对上联交换机之间的聚合口保持STP正常参与但确认聚合口本身不会因为某条成员口的变化频繁触发STP重收敛。如果发现拔一根线导致整个聚合口RSTP拓扑变更可以检查display stp brief看聚合口状态必要时调整STP优先级或启用收敛优化。6. 避坑指南与个人体会链路聚合这个技术说难不算特别难说简单也不简单它牵涉到端口状态机、协商协议、VLAN转发、哈希负载分担等多个层面任何一个环节出问题最终表现都是“业务不通”或“带宽不达标”。在这里把最后几点个人经验写出来希望能帮你少走弯路。第一配置前一定画一张拓扑草图标明设备型号、接口编号、聚合口编号、模式、VLAN清单。很多人开局不画图配到一半忘记哪根线接在哪最后全靠抓瞎。草图不用多专业自己能看懂就行。第二聚合口的编号规划要有规律。我的习惯是上联核心用BAGG 1-10下联服务器用BAGG 11-20跨越多个机房的还要加机柜编号前缀这样display link-aggregation summary一刷出来就知道哪里在跑什么业务千万不要一天一个聚合口创建得乱七八糟。第三配置和变更一定要留底。改华三配置前先display current-configuration导出整机配置存档改完再导一份对比。真出了问题至少能快速回退到变化前的状态。我见过太多人改完没存档半夜出问题只能靠回忆回滚那种压力没经历过的人不会懂。第四链路聚合部署完成后一定要在业务低峰期做断线演练。拔一根线、插回去观察业务是否自动切换、聚合组是否自动恢复把冗余能力先验证到位。等到故障真正来的时候才测试冗余那是拿生产环境做赌博。第五也是最后一点链路聚合不是万能的它无法替代三层路由冗余无法解决服务器单点故障更无法解决交换机本身硬件故障。聚合只是网络高可用拼图中的一块靠谱的网络设计还需要VRRP、堆叠、双上联这些技术配合。做网络别贪多稳才是王道。
返回列表