OLT端口更换闹故障

故障现象

近日，某专线用户向我们反映多处业务通讯失败，具体表现是，在专线单位服务器不能实现对客户端设备的管理。

故障分析

首先梳理一下网络拓扑结构，具体网络拓扑结构如图1所示。

图1 网络拓扑结构

通过图1我们可以看到，该专线采用ONU接入，上联至数据机房专线OLT，各基站专线业务依托环网设备，最终也汇聚到数据机房专线OLT。整个网络结构比较简单，可以简单理解成是EPON系统组网。知悉了网络拓扑结构，接下来我们开始排查。

具体的排查步骤是自上而下，采用顺藤摸瓜的方式。首先在该专线OLT上使用命令show mac-address-table l2-address vlan 17查看设备全局VLAN17的MAC地址，可以看到很多MAC地址上线，但是仔细观察发现，这些MAC地址都是该OLT的PON口学习上来的，而上联中心基站的端口并没有学习到VLAN17的MAC地址。

既然VLAN17的MAC地址都是从PON口学习到的，那么上联口是什么情况呢？使用命令show mac-addresstable l2-address port 28，查看上联端口28学习到MAC地址的情况，结果只能看到VLAN1的MAC地址上来，这是为什么呢？同样在环网设备连接专线OLT的端口依然学习不到VLAN17的MAC地址，问题分析到这里，进一步排查到两侧设备端口都处于UP状态，端口VLAN数据均没有发现问题，那么为什么MAC地址学习不到呢？

我们对两侧设备学习到的VLAN1的MAC地址进行比对，也就是说在专线OLT端口28学习到的MAC地址，应该是环网设备的MAC地址。但是我们并没有在环网设备上发现该地址，这一发现可以断定，OLT的28口连接的不是环网设备。发现此问题后，为了验证端口是否正确，我们关闭了OLT的28口，但是环网设备上连接专线OLT的端口依然UP，这样就可以断定是设备间互联端口出现了问题。

故障解决

得出这一结论后，我们在OLT处发现上联端口25、27和28口均处于Up状态，根据端口描述其中端口25上联BRAS设备，27口连接服务器，28口连接环网设备，但是28口当前是通过网线连接，28口连接环网设备肯定是光口，而这里使用的是电口。由于该OLT上联口是光电混用的，而连接服务器的27口连接的是光口，这样我们将27口的尾纤恢复到28口上，然后就可以看到端口28可以正常学习到VLAN17的MAC地址，这样故障就得到解决。进一步通过专线单位核实，服务器和客户端设备通信恢复正常。

经验总结

上面我们得知故障，通过使用一系列show命令查看MAC地址的学习情况，并结合网络拓扑结构进行MAC地址的比较排查，最终找到故障原因，再将端口光纤恢复后故障解决。虽然故障的出现十分偶然，但原因后面却深藏着制度上的漏洞。

后期我们通过调查得知是同事整理机柜线缆时，将光纤和网线插拔错误从而导致了该故障的发生。借鉴此故障的发生，我们对机房整理线缆制定了规范，认真做好线缆标签，杜绝此类事件的发生。并制定了相应的网络设备线缆优化调整制度，涉及到调整前端口和线缆信息的记录；调整中线缆的规范走向，调整后网络的比较验证以及端口核对信息等，通过一系列的举措，最大程度地保障网络的高质量稳定运行。