VLAN缺失惹故障

近日，我们接到某专线单位的报修，故障现象是该单位位于某十字路口的终端设备无法采集数据。

故障分析

为了更好地排除故障，我们首先了解一下网络拓扑结构，如图1所示。

按照故障现象和网络拓扑结构，首先根据资料在解放站OLT上查找到该终端设备连接的ONU，使用命令show interface onu 1/4/13 uni ethernet information查看到该ONU下的终端设备连接状态是正常的。然后再使用命令show interface onu 1/4/13 mac-address-table l2-address uni ethernet 1 dynamic查看到该ONU的端口1能学习到终端设备的MAC地址，即8ce7.48e9.b01b。

图1 网络拓扑结构

既然在ONU上能够学习到终端设备的MAC地址，那么就按照至下而上顺藤摸瓜的方法开始排查OLT。使用show命令依然可以在OLT上学习到终端设备的MAC地址，按照图1的网络拓扑结构在该专线单位ONU（中心站OLT）的上联口也可以学习到终端设备的MAC地址。

通过这样一个流程排查下来似乎没有问题，既然MAC地址能够正常学习到，但是数据采集不上来，会不会是终端设备的IP地址丢失或者是该终端设备出现故障呢？带着这个疑问我们赶到故障现场，使用笔记本连接到ONU上，笔记本电脑的IP地址设置成终端设备的IP地址，然后Ping专线单位的服务器，结果是不通的。问题分析到这里，可以断定该终端设备没有问题，问题还应该出在整个传输通道上。

回到故障发生的原点，即ONU所属的解放站OLT上进行故障排查，打算在OLT上设置一个地址直接Ping专线单位服务器和终端设备。在OLT上配置IP地址的具体步骤如下：

在OLT上配置完IP地址后，分别对专线单位服务器10.0.16.153和终端设备进行Ping测试，可以正常Ping通终端设备，但是不能Ping通服务器。既然能在OLT上正常学习到服务器的MAC地址，为什么Ping不通呢？使用命令查看该OLT的ARP表项即，如图2所示。

通过ARP表项我们可以清晰地看到，在OLT上能学习到服务器的IP地址对应关系，而且对应关系也是正确的，问题分析到这里似乎找不到头脑了。

故障解决

我们重新梳理一下思路，该终端设备可以在OLT上Ping通，这证明从OLT至终端设备这一段距离是没有问题的，那么问题应该出在解放站OLT之上。按照这个思路继续排查城域网解放站传输设备CP5566，就在我们使用命令在CP5566上查看连接OLT端口MAC地址表的时候，观察到两者互联使用了链路聚合。问题会不会出在链路聚合上呢？

在这里给大家简要介绍一下链路聚合的概念。链路聚合通过将多个物理以太网端口聚合在一起形成一个逻辑上的聚合组，并把同一聚合组内的多条物理链路视为一条逻辑链路。链路聚合可以实现流量在聚合组各成员端口之间的负载分担，在有效的提高设备之间链路可靠性的同时，还增大了带宽。

了解完链路聚合的相关知识后，我们先查看一下OLT上配置的链路聚合配置：

图2 查看ARP表项

通过上面的配置我们可以看到，在OLT上创建了一个链路聚合组1，成员是端口3和4，其中端口3和4的配置应该是一致的，但是仔细观察后发现，端口4的VLAN比端口3少了一个，缺少的VLAN就是VLAN230，这个会不会是引起网络故障的原因呢？立即将端口4的配置进行了修正，具体配置即：

在端口4上增加了VLAN230后，在OLT上对专线单位的服务器进行Ping测试，结果是正常的。经过确认，专线单位对终端设备的数据采集也恢复了正常。

经验总结

上面我们从得知故障现象后，按照自下而上顺藤摸瓜的方式逐级排查网络设备，广泛使用了show命令，并配合学习到的MAC地址表进行分析，最终将故障根源锁定到了链路聚合的配置上。经过对端口配置的修正，网络恢复了正常，后期我们了解到，开通此专线业务时，两台设备间并没有配置链路聚合，由于为了业务发展的需要，同事在配置链路聚合的时候粗心地将其中一个端口漏配置了VLAN230，所以才出现文章开头的那一幕。

根据这个故障，我们后期查阅了资料，得知在同一个链路聚合组中，参与负载分担的成员端口必须具有一致的配置，否则数据转发存在问题。而端口4正是违背了这一规则而导致了网络故障。通过这一故障的排查，作为网络运维人员，在配置设备时，要时刻提醒自己认真对待每一次设备的调试，细心做好每一步配置，要坚决杜绝配置错误事情的发生。