Link Flapping故障排查寄存器证据解析 - 第1节
Link Flapping 是什么？
说白了，Link Flapping 就是端口状态在 Up 和 Down 之间来回跳。你想想看，一个接口刚起来，马上又掉下去了，过几秒又起来，几分钟内反复好几次。这就是我们常说的「端口震荡」。
我记得刚入行那会儿，在数据中心调一个交换机堆叠，端口日志里全是 UP/DOWN 消息。一开始我以为只是哪个小模块接触不良，结果一查，整条链路上几十个端口都在抖。那会儿才真正明白——链路抖动不是小事，轻则丢包，重则路由震荡。
为什么会抖？三大根源
1. 物理层问题——最老实的元凶
光模块坏了、光纤弯折、端口静电、电源不稳……这些硬件坑，我踩过不止一次。去年帮一个客户排查 IDC 机柜，最后发现是一根尾纤被机柜门夹出了微弯，光功率刚好在接收阈值附近来回跳。
- 光模块故障：发光功率不稳定或接收灵敏度下降
- 线缆问题：网线断芯、光纤端面脏污、接头松动
- 端口硬件：PCB 焊点虚焊、电容老化、电源纹波过大
- 环境干扰：强电磁场、温度剧烈变化
2. 协议层问题——看不见的推手
不是所有抖动都是物理的。我记得有一次，一个三层交换机上联口一直在翻，光功率正常，换模块也没用。最后查了寄存器才发现是 STP 协议反复计算——邻居交换机发了错误的 BPDU 导致端口状态在 Forwarding 和 Blocking 之间来回切。
- 生成树协议 (STP/RSTP/MSTP)：拓扑变更导致端口状态切换
- 链路聚合 (LACP)：对端协商超时或 Actor 状态不一致
- Keepalive 超时：OSPF/BFD 邻居因延迟抖动反复断开
- 自协商失败：两端速率/双工模式不匹配
3. 配置与软件问题——人为的坑
最常见的，就是配了 errdisable recovery 但 recovery 间隔设得太短。比如端口因为 BPDU Guard 被 Error-Disable，30 秒后自动恢复，恢复后又被 Guard 关了，无限循环。我见过有工程师把 recovery 间隔设为 5 秒，结果端口 5 秒一翻，日志刷屏。
- Error-Disable 自动恢复：恢复间隔过短导致反复振荡
- 接口监控/故障转移：监控脚本误判，强行 shutdown/no shutdown
- 电源/风扇联动：低端交换机在电源不稳时强制下电端口
- 软件 Bug：特定固件版本下端口状态机异常
interface down 指令。教训就是：先看日志，别急着换硬件。
Link Flapping 的影响链
一次端口抖动，影响的绝不仅仅是那根线。拿我经历过的一个大型园区网来说，一台汇聚交换机的上联口抖了 3 秒，结果引发了以下连锁反应：
- 该端口上的 VLAN 全部退出，ARP 表项被老化
- 上游路由器检测到邻居 Down，撤销对应路由
- OSPF 泛洪 LSA，所有交换机重新计算 SPF
- 部分接入交换机因 STP 变更，端口进入 Listening 状态
- 视频会议系统大量丢包，用户投诉
3 秒的抖动，恢复了大概 40 秒才稳定。这还是在中等规模网络下。
如何用寄存器证据说话？
传统方式靠 ping 和日志，但日志是事后总结，寄存器才是实时快照。我个人习惯在排查链路抖动时，第一时间抓以下几个寄存器证据：
| 寄存器/计数器 | 能看出什么 |
|---|---|
ifInErrors / ifOutErrors |
物理层错包激增，预示光模块或线缆问题 |
ifInDiscards / ifOutDiscards |
队列溢出或协议控制面限速导致丢包 |
dot3StatsAlignmentErrors |
帧对齐错误，典型的上游链路故障 |
stpPortState |
STP 状态频繁切换，说明拓扑不稳 |
lacpActorState / lacpPartnerState |
LACP 协商超时或角色冲突 |
bfdSessionState |
BFD 会话频繁 Down/Up，链路质量差 |
这些寄存器数据比日志更「硬」。日志可能被限速或丢弃，但寄存器计数器是硬件实时累加的。我会先看 error 和 discard 的增长率，再查协议状态机寄存器。
本章知识体系
下面这张图归纳了整个链路抖动的核心逻辑：从根源到影响，再到排查证据链。
图中从三大根源开始，最终都归结到端口状态频繁切换，然后引发路由震荡、流量中断、CPU过载三个主要影响，而排查的立足点就是寄存器证据。在后面的章节里，我会逐一拆解每个场景对应的寄存器怎么读、怎么分析。