1. 故障现象业务跑着跑着就丢包聚合口在“抖”一听到链路聚合很多兄弟第一反应就是把两根网线并起来带宽翻倍、链路冗余心里踏实。但真实运维里链路聚合尤其是H3C交换机上的Eth-Trunk/Bridge-Aggregation动态聚合恰恰是半夜工单的高发区。我之前处理过一台H3C S5560X-EI的故障服务器双万兆口做了动态链路聚合上联交换机做了IRF堆叠业务平时很稳可一到流量高峰期就出现周期性丢包ping网关的丢包率在5%到10%之间晃。服务器网卡重启一下能好一阵子过几个小时又复发。最后反复看聚合状态发现两个成员口在Selected和Unselected之间来回跳十几秒就翻一次流量也跟着在单链路和双链路之间切换。这种“半死不活”的状态比直接断网还难查。这起故障的根因说出来可能很多人不信就是LACP的超时时间没对上。服务器网卡驱动用的是短超时period short对应的fast模式而H3C交换机动态聚合口默认是长超时long。两边互相发LACPDU握手包的时候各自对“多久没收到协议报文就判定对方掉线”的理解完全不一致。一个觉得对方已经失联了一个还在按30秒一次的慢节奏发心跳结果聚合口反复协商、反复超时业务自然跟着遭殃。这篇文章我不打算讲大而全的LACP原理就围绕这个“超时时间”展开把H3C交换机上lacp period short这条命令背后的机制、实际排查步骤、和服务器网卡绑定的配合方法以及我踩过的坑全部写出来。如果你正在处理Linux bonding或者Windows NIC Teaming对接H3C交换机时出现的聚合口不稳定、成员口反复Selected/Unselected这篇文章应该能直接帮到你。2. LACP超时时间到底在超什么period short与period long的区别2.1 LACPDU心跳报文里的两个关键状态位要理解超时时间先得知道LACP是怎么协商的。动态聚合口启用LACP后聚合口上的每个成员口会周期性发送LACPDULink Aggregation Control Protocol Data Unit报文里带着系统优先级、端口优先级、操作Key等信息。双方通过交换这些报文决定谁做Actor、谁做Partner最终把成员口协商成Selected状态并开始转发流量。这个过程有点像两个人在互相喊话“我这边端口配置正常吗”“我这边也在线咱俩能配合。”LACPDU里有两个容易被忽略的状态位一个是Activity决定本端是主动发还是被动等对应Active/Passive另一个就是Timeout决定双方的心跳频率和超时判定规则。H3C的命令行里这个Timeout状态位就是用lacp period short和lacp period long来控制的。很多人第一次看到这条命令以为它只是设置“多久超时”实际上它同时影响“多久发一次LACPDU”和“多久收不到LACPDU就判定对端超时”两个方向。2.2 短超时和长超时的具体数值按照LACP的标准行为短超时模式下LACPDU的发送周期是1秒一次超时判定是3个周期没收到对端报文也就是大约3秒乘以3约9秒。长超时模式下LACPDU发送周期是30秒一次超时判定是90秒乘以3约270秒。这两个数字之间的差距非常大。我把两组参数整理成了下面这个表方便对照参数方向period shortfastperiod longslowLACPDU发送周期1秒30秒失联判定时间约9秒约270秒适用场景服务器双网卡绑定、需要快速感知链路故障传统设备互联、对协议报文频率敏感的环境H3C命令lacp period shortlacp period long常见服务器驱动叫法LACP rate: fastLACP rate: slow服务器的双网卡绑定为什么偏爱短超时因为服务器上跑的是业务链路断了必须尽快切换。如果一根物理网线被拔掉要等270秒才认定链路故障业务早就中断了。交换机为什么默认用长超时因为交换机面对的是大量对端设备如果每个端口都每秒发一次协议报文整机CPU和中断开销会明显上升而且很多老设备对高频LACPDU的兼容性并不好。所以厂商默认取了一个“保守”的长超时。2.3 为什么协商成功之后还会反复断开这是整个故障里最让人困惑的点刚开始接口up的时候双方交换了最初的几个LACPDU聚合口明明已经建起来了为什么运行一阵子又会断开答案在于“握手节奏”不同步。假设H3C交换机保持long模式按30秒一次的频率发LACPDU而服务器网卡要求short模式按1秒一次的频率发并且以9秒作为超时判定线。接口刚up时双方都在高频地发送初始LACPDU所以能在短时间内建立协商。可一旦进入稳定期交换机切换回慢速30秒一次的心跳服务器那边9秒内没等到下一包立刻判定对端失联把聚合状态变成未同步。服务器网卡发现聚合异常后又会重新发起LACP协商交换机响应后恢复一阵子。于是聚合口就在“协商成功—超时失联—重新协商—再次成功”这个循环里反复横跳业务丢包也呈现出周期性特征。这种问题用一句话概括对端要求你1秒发一次消息你却30秒才回一句对方当然觉得你掉线了。3. 实操排查从display命令到定位超时不匹配3.1 完整配置回顾动态聚合加period short先看H3C交换机上正确的动态聚合配置长什么样。以二层聚合口Bridge-Aggregation 1为例interface Bridge-Aggregation1 description To-Business-Server port link-type trunk port trunk permit vlan 20 30 link-aggregation mode dynamic lacp period short # interface Ten-GigabitEthernet1/0/1 port link-aggregation group 1 # interface Ten-GigabitEthernet1/0/2 port link-aggregation group 1这里有两个关键动作。第一个是link-aggregation mode dynamic它把聚合模式从静态改成动态LACP才开始工作。第二个是lacp period short它把本端LACP超时时间设置为短超时和服务器网卡的fast模式对齐。注意静态聚合模式下不需要也不能配置lacp period short因为静态聚合根本不做LACP协商如果你在静态聚合口下敲这条命令H3C会直接报错或者忽略。另外提醒一句成员口一旦加入聚合组成员口自己的VLAN、双工、速率配置会被聚合口覆盖。所以不要在成员口上去配Trunk和VLAN统一在Bridge-Aggregation口上配置。否则容易出现“配置进去了但没生效”的情况。3.2 用display命令确认Actor和Partner的超时状态H3C排查看聚合第一条命令通常是display link-aggregation summary[H3C] display link-aggregation summary Aggregation Interface Type: BAGG1: Bridge-Aggregation Interface Status Ports BAGG1 Up 2 XGE1/0/1 Selected XGE1/0/1 XGE1/0/2 Unselected XGE1/0/2看到两个成员口一个是Selected一个是Unselected先不要急着怀疑光模块和线缆第二步马上看display link-aggregation verbose[H3C] display link-aggregation verbose Bridge-Aggregation 1 Bridge-Aggregation1: Aggregation Mode: Dynamic Actor System ID: 0x8000, 741f-4a52-0001 Partner System ID: 0x8000, 001c-2333-0001 Actor Timeout: Long Partner Timeout: Short Port Status Selected Port Priority Oper-Key XGE1/0/1 Up Unselected 32768 2 XGE1/0/2 Up Unselected 32768 2注意看Actor Timeout和Partner Timeout这两行。如果Actor是LongPartner是Short那么问题基本就锁定了本端按长超时工作对端按短超时工作。这种情况下即使物理链路和VLAN都正常也会出现上一节描述的“协商起来又断掉”的循环。再配合display lacp statistics看看LACPDU的收发计数[H3C] display lacp statistics interface Ten-GigabitEthernet 1/0/1 Interface XGE1/0/1: LACPDU packets transmitted : 1345 LACPDU packets received : 1348 Bad packets received : 0如果收发计数都在增长说明LACP报文链路本身是通的问题不在互连而在超时行为。如果收包一直是0那才需要查物理层、光模块和对端是否启用了LACP。3.3 去服务器上核对网卡绑定的LACP rate交换机侧查完必须去服务器端交叉验证。只有两边信息对上故障才能定性。Linux bonding的验证最简单cat /proc/net/bonding/bond0输出里有一行LACP rate: fast这个就是short超时如果是LACP rate: slow那就是long超时。很多发行版的bonding默认是slow但有些虚拟化平台或者双网卡绑定脚本会显式配置成fast。如果你看到的是fast而交换机是long基本就是同一个故障。Windows NIC Teaming则用PowerShell查看Get-NetLbfoTeam -Name Team1 | Format-List Get-NetLbfoTeamMember -Team Team1在网卡高级属性里有一个LacpTimer的选项可以设置Fast或Slow。Windows Server的NIC Teaming如果选择LACP动态模式默认是Fast对应short超时。这一点恰恰和很多H3C交换机默认的long超时形成冲突。3.4 修复动作与验证结果把H3C交换机上对应的聚合口执行下面的命令interface Bridge-Aggregation1 lacp period short然后重新确认状态[H3C] display link-aggregation verbose Bridge-Aggregation 1 Actor Timeout: Short Partner Timeout: Short两边都变成Short之后聚合口的两个成员口会稳定在Selected状态不会再反复跳。我处理的那台设备在配置完成后连续观察了一周display link-aggregation summary里两个成员口始终都是Selected业务丢包也彻底消失。还可以做一个更直观的验证拔掉一根物理网线看业务切换需要多久。在short超时下从拔线到流量切换到另一条成员链路通常在几秒内完成如果保持long超时可能要等几十秒甚至几分钟业务早就报警了。4. 常见问题速查命令报错、日志误导、版本差异4.1 为什么敲lacp period short会报错或者不生效这个命令报错的原因主要有两种。第一种是聚合口还在静态模式下静态聚合不做LACP协商所以没有“超时时间”的概念。先确认是否已经执行了link-aggregation mode dynamic没有的话先切换动态模式。第二种是命令进错了视图lacp period short必须在聚合接口视图下配置比如interface Bridge-Aggregation1而不是在物理成员口上敲。在物理口上敲这条命令H3C会直接提示找不到相关配置。还有一点要注意H3C不同版本之间的差异。Comware V7之后的设备普遍支持lacp period short但一些老款S系列交换机或者更早的Comware V5版本命令形式和支持情况可能有区别。现场操作之前最好先display version确认软件版本再看一下设备的命令手册避免在割接窗口里对着一个不存在的关键字发呆。4.2 别被Windows的DCOM超时报错带偏和这个故障同期Windows服务器的系统日志里经常出现一条报错服务器{某个GUID}没有在要求的超时时间内向DCOM。很多同事第一次看到这个报错会误以为是Windows组件或者应用程序出了问题开始去调DCOM配置、改注册表。实际上这个DCOM报错是应用层面的组件通信超时和链路聚合里的LACP超时完全是两回事。网络闪断、聚合口抖动会导致依靠网络通信的Windows组件响应超时从而产生这条日志。DCOM报错是“结果”LACP超时才是“原因”。排查的时候一定要先把网络链路层的证据收集齐比如交换机聚合状态、LACPDU收发计数、服务器bonding状态确认无误之后再去处理上层日志。如果一上来就陷进DCOM的坑里方向就错了。同样网上搜索“超时时间”还会出现数据库MHA设置超时时间之类的文章那是数据库高可用切换里的参数跟链路聚合没有任何关系。应用层超时和链路层超时是两个维度不要被关键词带偏。4.3 eNSP模拟器里的链路聚合命令和H3C并不完全一样搜索记录里还有一个高频词是ensp链路聚合配置。华为的eNSP模拟器里链路聚合口叫Eth-TrunkH3C设备上叫Bridge-Aggregation华为的命令体系和H3C也有差异。最简单的对照是配置项H3C设备华为eNSP/VRP聚合接口名称Bridge-AggregationEth-Trunk动态聚合模式link-aggregation mode dynamicmode lacp-static具体以版本为准LACP超时时间lacp period short / longlacp timeout fast / slow成员口加入聚合组port link-aggregation group 1trunkport eth-trunk 1很多初学者在eNSP里练会了一套命令到真机上发现H3C提示命令不存在就是因为没有做这个转换。如果你手头的是H3C设备不要直接照搬华为教程里的Eth-Trunk命令。不同分支的命令差异解决起来不难但第一次遇到时很耽误时间。4.4 排查速查表把现场最常见的几种情况和对应处理方式整理成一个速查表方便截图保存现场现象可能原因处理动作成员口反复Selected/Unselected服务器网卡LACP rate为fast交换机LACP超时配置为long在聚合口配置lacp period short聚合口协商不起来LACPDU收包计数为0对端未启用LACP、物理链路异常、光模块故障检查对端配置排查物理链路两个成员口都是Up但只有一个Selected成员口速率/双工不一致或操作Key异常统一成员口速率双工检查端口配置聚合口状态正常但业务切换很慢两端都使用long超时故障感知时间太长根据业务需求评估是否切换为short配置lacp period short后成员口仍频繁跳变服务器网卡驱动/固件对LACP实现有bug更新网卡驱动或把服务器侧改为slow4.5 关于短超时的一些额外提醒短超时不是万能药。它让故障感知变快但代价是LACPDU发送频率提高设备CPU和中断开销略有上升。对于动辄几十个聚合口的汇聚交换机如果全部配成shortLACPDU风暴造成的CPU占用不能忽略。我在生产环境里的原则是连接服务器的接入侧聚合口配short没问题交换机之间、核心与汇聚之间的互联聚合口保持默认long更稳妥。另外short超时环境下如果网络本身存在轻微丢包LACP误判的概率也会增加。因为9秒判定窗口太短偶发丢包就可能触发重新协商。所以不要认为“short一定比long好”它只是更适合服务器接入场景。5. 动态聚合交付的三个习惯这起故障之后我给自己定了一条规矩凡是给服务器做动态链路聚合交付前必须检查三件事。第一确认聚合口是link-aggregation mode dynamic静态聚合没有LACP协商也就没有超时时间可言。第二确认lacp period short或者long与对端网卡绑定的LACP rate一致。第三确认两个成员口分别落在堆叠/IRF的不同设备上这样才能真正实现设备级冗余。如果两个成员口都在同一台物理设备上那聚合口再稳也不能避免单点故障。检查超时状态的时候我习惯直接过滤显示display link-aggregation verbose | include Timeout一条命令能看到所有聚合口的Actor和Partner超时状态比逐个翻页面效率高很多。另外还有一个实用技巧配置前后都保存一下配置文件并且把关键输出存到本地留档。这种“聚合口来回跳”的问题往往是间歇性的如果当时没有截图留证据过一会儿状态恢复成正常后面复盘就说不清了。先留证据再动手改配置是非常好的习惯。最后说个小经验如果你发现服务器网卡驱动里强制LACP rate为fast而交换机又因为某些原因不能改配置可以试着在服务器侧把bonding的lacp_rate改成0slow让服务器去适配交换机。但实际交付时我一般倾向于让交换机去适配服务器因为服务器网卡驱动更新频繁厂商默认策略经常改交换机改一条命令比在每台服务器上改驱动参数要快得多。链路聚合本身不复杂可一旦涉及LACP超时、对端驱动这些细节就很容易踩坑。希望这篇基于真实故障的复盘能让你下次再看到聚合口反复Selected和Unselected时第一时间想到去看Actor和Partner的Timeout字段而不是先把光模块和网线换一遍。
