链路抖动的表现与确认
接口反复 up/down 会让上层协议持续震荡：路由重新收敛、会话中断、业务间歇性不可用。确认方法很直接：数内核日志里的 Link Down 事件数量，并读取接口的 carrier_changes 计数——后者是累计值，所以在业务故障前后各读一次，比较增量就能确认抖动是否发生在故障窗口内，而不是历史遗留。
基本信息
| 适用平台 | Linux（dmesg 与 /sys/class/net 均为内核自带） |
|---|---|
| 关键计数 | /sys/class/net/<接口>/carrier_changes（载波变化累计次数） |
| 日志来源 | dmesg -T 中的 link is down / link is up 事件 |
| 辅助命令 | ethtool <接口> 看协商速率与双工；ethtool -S 看错误细分 |
| 权限要求 | 读计数普通用户可做，查看完整 dmesg 可能需权限 |
典型使用场景
- 业务间歇中断但抓不到丢包：先排除接口抖动这个更底层的可能
- 机房搬迁或换线后验证：复核计数是否停止增长，确认修复有效
- 判断光模块或网线质量：结合 CRC 错误与 downshift 事件一起看
- 节能以太网（EEE）协商异常导致的对端省电跳变：优先在链路抖动排查中考虑
- 长期巡检：把 carrier_changes 纳入监控，增长速率异常即告警
确认抖动频率
确认抖动频率
dmesg -T | grep -iE 'link is (down|up)|nic link' | tail -30 # 最近的链路事件
dmesg -T | grep -ci 'link is down' # 累计 down 次数
cat /sys/class/net/eth0/carrier_changes # 载波变化累计计数
ethtool eth0 | grep -E 'Speed|Duplex|Link detected' # 当前协商结果
ethtool -S eth0 | grep -iE 'carrier|downshift' # 是否有降速或载波异常
# 修复后复核：间隔一段时间再读一次，计数不再增长才算真的解决
cat /sys/class/net/eth0/carrier_changes现象与常见成因
| 现象 | 可能成因 | 验证方式 |
|---|---|---|
| 计数持续增长且业务同时中断 | 线缆或接口物理问题 | 换线换端口后复核计数 |
| 伴随 CRC 错误增长 | 网线质量、水晶头氧化、光衰 | 结合 ip -s -s 的错误细分 |
| 只在业务繁忙时段抖动 | 电源不稳、端口供电或温度 | 对比负载曲线与抖动时间点 |
| 协商速率反复变化 | 双工或速率不匹配、EEE 协商 | ethtool 查看速度与双工历史 |
| 对端设备侧也记录到抖动 | 对端端口或模块故障 | 两端同时读计数对比 |
常见成因清单：水晶头氧化或线序不良、光模块接触不良、电源不稳、对端设备端口故障、节能以太网（EEE）协商问题。逐项排除比反复重启接口更有效。