前言

这几天协助处理了一个故障，觉得很有意思，就想着把这个故障讲出来，也是给从事这行业的工程师一个经验分享。

某医院新增一栋病房楼，网络建设完成后，这栋楼医生和护士一直反馈他们的医护系统使用比较卡顿。因为医院其他病房楼使用该医护系统没有卡顿现象，最后医院定位是新建网络问题。

医院运维工程师找当时负责调试的工程师协助处理，反反复复去了几次也没有找到故障原因，后来就推说是弱电井没有空调，设备温度比较高导致网络卡顿。

眼瞅着这天凉了下来，医护系统使用状况不但没有好转，反而向着“病危”的方向奔去，原来只是白天访问医护系统卡顿，现在晚上也频繁出现卡顿现象导，导致医嘱和护士输入数据丢失问题频发，信息科每日都背负医生和护士投诉的压力。

或许是信息科对于当时调试的工程师技术水平彻底失去信心，医院就找到了我们希望帮助他们排查下具体的问题原因。

网络结构和配置

客户现场配置和网络架构很简单，典型的接入、汇聚、核心三层架构，网关在汇聚交换机上，汇聚交换机和核心SVI接口互联，启用动态OSPF路由协议。

拓扑图

配置（配置做了简化和修改）

汇聚区域交换机配置。

vlan batch 11 to 14 64

lacp priority 100

interface Vlanif11

ip address 172.16.11.254 255.255.255.0

interface Vlanif22

ip address 172.16.12.254 255.255.255.0

interface Vlanif13

ip address 172.16.13.254 255.255.255.0

interface Vlanif14

ip address 172.16.14.254 255.255.255.0

interface Vlanif64

ip address 172.16.64.254 255.255.255.0

interface Eth-Trunk1

port link-type trunk

port trunk allow-pass vlan 2 to 4094

loopback-detect enable

mode lacp

max active-linknumber 2

interface Eth-Trunk2

port link-type trunk

port trunk allow-pass vlan 2 to 4094

loopback-detect enable

mode lacp

max active-linknumber 2

interface XGigabitEthernet0/0/1

eth-trunk 1

lacp priority 100

interface XGigabitEthernet0/0/2

eth-trunk 2

interface XGigabitEthernet1/0/1

eth-trunk 1

lacp priority 100

interface XGigabitEthernet1/0/2

eth-trunk 2

ospf 10 router-id 172.12.3.30

area 0.0.0.0

network 172.16.91.0 0.0.0.255

network 172.16.92.0 0.0.0.255

network 172.16.93.0 0.0.0.255

network 172.16.94.0 0.0.0.255

network 172.16.104.0 0.0.0.255

通过查看配置是中规中矩，并无配置遗失或不妥之处。

现在要做的是梳理整个排查思路。

排查思路及结果

在故障范围已经确定：整栋楼都有访问业务系统卡顿。因为所有楼层交换机数据都先到达汇聚，所以确定先排查汇聚交换机信息。

1. 查看汇聚交换机内存、cup、温度、风扇状态。即设备硬件状态。
2. 汇聚交换机堆叠状态。
3. 确定汇聚交换机上联核心和下联接入端口数据信息，即流量和报文信息。
4. 确定用户终端访问网关是否有延迟和丢包。
5. 查看交换机自身日志信息是否异常。

排查结果

1、交换机内存、cup、温度和硬件状态正常。

2、汇聚交换机堆叠状态正常。

3、汇聚交换机上联核心、下联接入交换机流量未达到阈值，无异常单播、组播报文。

但是在上联核心交换机的接口下发现有CRC校验错误数据。

4、终端ping网关无延迟和丢包问题。

5、查看交换机日志，确定汇聚和核心上联接口状态存在DOWN和UP反复震荡问题。

判断

汇聚到核心两个物理链路接口都有CRC校验错误，并且两个物理链路汇聚接口上都有反复DOWN和UP的日志提示。

由此可以判断是物理线路问题。

剩下的问题就是需要确定的是光模块还是光缆问题。

因为是在网业务运行时间，无法使用替换排除法。所以只能通过命令来查看确定。通过查看光模块光衰，并无异常信息。

但是接口下CRC校验值和日志里面端口反复UP和DOWN震荡信息也可以判定确实光纤线路问题，但光模块下的光衰数据显示无异常！

难道是CRC校验值是之前记录？

端口UP和DOWN的日志是之前的？交换机的时间没有原来的工程师没有调整？

为了验证猜想，工程师把接口的数据信息清除，同时又核验交换机的时间是否和日志事件timetrap一致。

工程师清除接口计数统计后，多次查看接口的信息，发现CRC校验错误又出现了，而且交换机的时间和日志的trap时间一致。

这样看来是汇聚交换机和核心交换机物理链路问题无疑了！

但为什么汇聚交换机搜集到的数据都是正常的呢？难道是光模块后者光模块的跳纤当时没有插紧？

抱着这个怀疑的心态，工程师重新把汇聚交换机上联核心的一个接口重新拔插了下，接着诡异的事情发生了。

工程师拔插的那个接口再也无法正常UP起来了！

更换新的模块和跳纤后，这个被拔插后的接口似乎要摆烂到底，就是不会UP了！

重新梳理思路

经过这个事件后工程师再也不敢乱动接口的任何设备了。

只能重新梳理思路。

哪些问题会引起CRC校验错误和端口无故UP、DOWN呢？

正在思考的时候，电脑屏幕上突然弹出日志，显示刚才重新拔插光模块的接口UP了，但随机又有一条DOWN的日志出现。

出现频率这么快，肯定不是生成树的影响。

正在这时，工程师的目光注意到汇聚上联到核心的光纤跳纤。

光模块型号10GBASE_LR_SFP好像是单模模块，光纤跳纤怎么是多模的呢？

破案了！

客户核心机房到汇聚机房曲曲绕绕有两公里，多模光缆最大传输距离才500米左右，所以主干光缆肯定是单模光缆，接着工程师查看了下主干光缆，确定了他的猜想，主干光缆是单模，跳纤是使用多模。

所以问题就是多模光纤跳线和单模主干光缆直接对接，导致的汇聚交换机上联端口出现大量的CRC错误和接口状态在Up和Down之间反复震荡的现象。

问题思考与总结

本案例使用的是单模模块对接的多模跳纤，在这么远的距离在设备上线之初两端设备能够端口协商成功并启动，本来就是一个奇迹。

可是为什么单模模块短距离可以使用多模光纤，但是多模模块不可以使用单模光纤呢？

首先要了解的是单模模块、单模光纤和多模模块、多模光纤的区别和工作机制。

单模模块、单模光纤和多模模块、多模光纤的区别和工作机制

单模模块是使用单一模式传输光信号，支持工作波长一般是1310nm、1550nm，通常单模光模块采用激光器发光。

而多模模块是使用多个模式传输光信号的模块，支持工作的波长一般是850nm，多模采用二极管作为发光源。

单模光纤的芯径几乎与光波波长接近，所以单模光纤在传输光信号时只允许一种模式在其中传播，即最低阶模态（LP01），这种传输方式并不会发生模式色散的问题，基本类似于光直线在光纤中传播。因此，它的传输距离非常远，适用于长距离通信。但是它的带宽容量较低，传输速度较慢，因此在短距离通信中不如多模光纤适用。

多模光纤的芯径大于光波波长，所以多模光纤在传输光信号的时可以多达数百个光模式，即除了最低阶模态（LP01）之外，还有其他高阶模态。因此具有较高的色散，其传播过程存在多次反射和折射。相反，多模可以传输多种模式的光线，因此它具有更高的带宽容量，可以在单位时间内传输更多的信息。但是，多模光纤的传输距离较短，而且需要更复杂的传输系统和接收器，因此它的成本也较高。

所以在单模模块能够在多模光纤传输的原因就是多模光纤对光模式的接收，但是因为色模发散的原因会导致低带宽和高延迟，也限制了最大的传输距离。

而多模模块在使用单模光纤时因为光源技术不一样，而且光纤对于光模式接收模式也不一样，所以导致多模模块根本无法匹配单模光纤。

总结

在网络建设过程中，单模模块一定要匹配相应的单模光纤，这样可以避免很多物理线路导致的数据传输失败的问题。

另外，万兆模块在和线缆对接的过程中，建议光纤也采用支持万兆速率的光纤跳纤。

下表是各个模块和光纤对应表：