第三章：常见故障类型深度解析
大家好，我是老张。这一章咱们聊聊光纤专线最常见的三类故障。
说实话，干运维这些年，我处理过的故障少说也有上千起。总结下来，90%的问题都跑不出这三个层面：物理层、链路层、网络层。
你想想看，光缆断了、模块坏了，这是物理层的事。CRC错误、协商失败，这是链路层的事。路由黑洞、环路，这是网络层的事。搞懂这三层，你就抓住了故障排查的命门。
核心观点：故障排查要分层进行。从物理层开始，逐层向上。千万别一上来就抓包分析，那是在浪费时间。
3.1 物理层故障：光缆中断与光模块损坏
物理层故障，说白了就是硬件层面的问题。我处理过的故障里，物理层占了将近一半。
3.1.1 光缆中断
光缆中断是最常见的故障。施工挖断、老鼠咬断、接头松动，原因五花八门。
我的经验：有一次凌晨两点接到告警，某银行专线全断。赶到现场发现，是市政施工把光缆挖断了。从那以后，我要求所有重要线路必须走不同路由的双光缆。
判断光缆中断的方法很简单：
- 查看光功率：正常值一般在 -20dBm 到 -25dBm 之间
- 如果光功率为 -40dBm 或更低，基本可以断定光缆断了
- 用 OTDR 测试，能精确定位断点位置
# 查看光模块信息
show interface transceiver
# 输出示例
Interface: GigabitEthernet0/0/1
Temperature: 35°C
Voltage: 3.3V
Current: 10mA
Tx Power: -3.5dBm
Rx Power: -22.1dBm ← 正常范围
3.1.2 光模块损坏
光模块损坏也很常见。静电击穿、温度过高、插拔不当，都可能导致模块报废。
避坑指南：我曾经遇到过一批光模块，用了不到半年就坏了。后来发现是机房空调故障，温度长期超过40度。光模块的工作温度最好控制在25度以下。
光模块故障的典型表现：
- 端口指示灯不亮或闪烁异常
- 光功率异常（Tx 或 Rx 为 0）
- 日志中出现 "transceiver not supported" 或 "module error"
3.2 链路层故障：CRC错误与协商失败
链路层的问题，往往比物理层更隐蔽。你看着端口是 up 的，但数据就是不通。
3.2.1 CRC错误
CRC错误，说白了就是数据在传输过程中被破坏了。原因可能是光纤质量差、接头脏了、或者电磁干扰。
我习惯用这条命令检查：
# 查看端口统计信息
show interface GigabitEthernet0/0/1
# 重点关注
Input errors: 1234
CRC errors: 567 ← 这个数字如果持续增长，说明有问题
Frame errors: 89
关键判断：如果 CRC 错误数持续增长，哪怕只有几十个，也要重视。我曾经遇到一个案例，CRC 错误每小时增加 10 个，结果三天后线路彻底瘫痪。
解决 CRC 错误的步骤：
- 清洁光纤接头（用专用清洁工具）
- 检查光纤弯曲半径是否过小
- 更换光纤跳线
- 如果还不行，考虑更换光模块
3.2.2 协商失败
协商失败，就是两端设备谈不拢。速率、双工模式不一致，就会出问题。
为什么会这样？
- 一端是 1000M 全双工，另一端是 100M 半双工
- 自协商失败，两端都降速到 10M
- 手动配置和自动协商冲突
我的建议：对于光纤专线，我强烈建议两端都手动配置成相同的速率和双工模式。不要依赖自协商，它有时候会坑你。
# 手动配置示例（华为设备）
interface GigabitEthernet0/0/1
speed 1000
duplex full
negotiation disable
3.3 网络层故障：路由黑洞与环路
网络层的问题，往往是最难排查的。因为物理层和链路层都正常，但数据就是到不了目的地。
3.3.1 路由黑洞
路由黑洞，说白了就是路由器收到了数据包，但不知道往哪转发。结果就是丢包。
常见原因：
- 路由表缺失（没有配置静态路由或动态路由没学到）
- 路由汇总导致的不精确匹配
- 路由过滤策略误配置
避坑指南：我曾经遇到一个案例，某条专线时通时断。查了三天，最后发现是路由汇总把 /30 的网段汇总成了 /24，导致部分流量被黑洞了。从那以后，我要求所有路由汇总必须精确计算。
# 检查路由表
display ip routing-table
# 重点关注
Destination/Mask Proto Pre Cost NextHop Interface
10.0.1.0/30 Static 60 0 192.168.1.1 GigabitEthernet0/0/1
10.0.1.4/30 Static 60 0 192.168.1.2 GigabitEthernet0/0/2
3.3.2 路由环路
路由环路，就是数据包在两个路由器之间来回转发，永远到不了目的地。TTL 耗尽后才会被丢弃。
环路的表现：
- ping 延迟极高（超过 1000ms）
- TTL 值逐渐减小
- CPU 使用率飙升
排查技巧：用 traceroute 命令，如果看到 IP 地址在两个路由器之间反复出现，基本就是环路。我习惯用扩展 traceroute，设置最大 TTL 为 10，这样能快速定位。
# 使用 traceroute 检测环路
traceroute 10.0.1.1
# 输出示例（环路情况）
1 192.168.1.1 1ms
2 192.168.2.1 2ms
3 192.168.1.1 3ms ← 又回来了！
4 192.168.2.1 4ms
5 192.168.1.1 5ms ← 明显是环路
解决环路的方法：
- 启用 RPF（反向路径转发）检查
- 配置路由优先级，避免多条等价路由
- 使用 BGP 的 AS-PATH 属性防止环路
3.4 故障排查实战流程
最后，我总结一个实战排查流程。你照着做，能省不少时间。
| 排查步骤 | 检查内容 | 常用命令 | 预期结果 |
|---|---|---|---|
| 第一步 | 物理层：光功率、端口状态 | show interface transceiver | Rx Power > -25dBm |
| 第二步 | 链路层：CRC错误、协商状态 | show interface | CRC errors = 0 |
| 第三步 | 网络层：路由表、连通性 | display ip routing-table | 目标路由存在 |
| 第四步 | 端到端测试 | ping / traceroute | 延迟 < 10ms |
我的习惯：每次排查故障，我都会记录时间、现象、操作、结果。这样下次遇到类似问题，直接翻笔记就行。嗯，好记性不如烂笔头嘛。
好了，这一章的内容就到这里。记住，故障排查要分层进行，从物理层开始，逐层向上。别一上来就怀疑路由协议，先看看光模块是不是坏了。
公众号:蓝海资料掘金营，微信deep3321