用SpaceSniffer可视化C盘空间，告别爆满与盲删
2026/9/29 16:40:03
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后，聚合口上的每个成员口会周期性发送LACPDU（Link 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 short（fast） | period long（slow） |
|---|---|---|
| LACPDU发送周期 | 1秒 | 30秒 |
| 失联判定时间 | 约9秒 | 约270秒 |
| 适用场景 | 服务器双网卡绑定、需要快速感知链路故障 | 传统设备互联、对协议报文频率敏感的环境 |
| H3C命令 | lacp period short | lacp period long |
| 常见服务器驱动叫法 | LACP rate: fast | LACP 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是Long，Partner是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-Trunk，H3C设备上叫Bridge-Aggregation；华为的命令体系和H3C也有差异。最简单的对照是：
| 配置项 | H3C设备 | 华为eNSP/VRP |
|---|---|---|
| 聚合接口名称 | Bridge-Aggregation | Eth-Trunk |
| 动态聚合模式 | link-aggregation mode dynamic | mode lacp-static（具体以版本为准） |
| LACP超时时间 | lacp period short / long | lacp timeout fast / slow |
| 成员口加入聚合组 | port link-aggregation group 1 | trunkport 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 | 更新网卡驱动，或把服务器侧改为slow |
4.5 关于短超时的一些额外提醒
短超时不是万能药。它让故障感知变快，但代价是LACPDU发送频率提高，设备CPU和中断开销略有上升。对于动辄几十个聚合口的汇聚交换机，如果全部配成short，LACPDU风暴造成的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改成0（slow），让服务器去适配交换机。但实际交付时，我一般倾向于让交换机去适配服务器，因为服务器网卡驱动更新频繁，厂商默认策略经常改，交换机改一条命令比在每台服务器上改驱动参数要快得多。
链路聚合本身不复杂，可一旦涉及LACP超时、对端驱动这些细节，就很容易踩坑。希望这篇基于真实故障的复盘，能让你下次再看到聚合口反复Selected和Unselected时，第一时间想到去看Actor和Partner的Timeout字段，而不是先把光模块和网线换一遍。