为何VLAN间互相影响

2016-11-26 05:19
网络安全和信息化 2016年5期
关键词:分中心交换机端口

引言:某专线单位出现网络故障,远端服务器不能正常访问。通过梳理网络拓扑结构,按照网络层次逐级排查的办法,将故障定位在设备端口损坏,从而导致VLAN之间互相影响。在更换设备端口后故障排除。

故障现象

近日,某集团客户向我们反映不能正常访问指挥分中心的服务器,得知这一故障后,我们迅速展开排查。为了理清思路我们先了解下网络拓扑结构(如图1)。

通过图1我们可以看到,这次集团客户专线项目主要依托目前的城域网进行数据传输,城域网是由中心站、科苑站、解放站和神道站四个基站组成,每个基站都将EPON和EOC作为接入层设备连接至基站的传输设备上,然后采用就近的原则将摄像头数据送达至指挥分中心,从而实现指挥分中心辖区的摄像头数据在本地汇聚存储。最后,通过城域网中心基站C5566设备将数据送达至指挥中心,实现了指挥中心对各分中心视频资料的实时查看和调取。

图1 某集团客户专线网络拓扑图

在指挥中心和16个指挥分中心均采用了三层交换机,在交换机上创建不同VLAN,并设置默认路由,实现分中心与指挥中心之间的数据通讯。具体做法是,各分中心的交换机通过默认路由实现与指挥中心交换机的通讯,指挥中心的交换机通过静态路由的方式与各分中心的交换机进行数据通讯。这样,每个分中心的业务VLAN不相同,然后使用VLAN2作为分中心和指挥中心的互联VLAN,实现分中心和指挥中心的数据通信。

故障分析

既然指挥中心访问分中心是通过路由,首先在指挥中心的交换机上对故障分中心交换机地址10.0.0.10执行Ping测试,结果是失败的。互联地址都Ping不通,当然Ping故障分中心的业务VLAN地址37.56.73.1也是不通的,因为故障分中心的服务器网关为37.56.73.1,所以才出现故障开头的那一幕,指挥中心无法访问某分中心的服务器。

根据网络拓扑结构,我们决定按照自下而上顺藤摸瓜的方式排除故障。首先测量故障分中心交换机的接收光功率-14db,属于正常范围。然后查看了的交换机的连接情况,该交换机上的网口上连接了服务器、硬盘录像机和磁盘阵列。

为了排除该交换机本身连接设备的嫌疑,我们只保留了该交换机的上联口,将交换机上连接服务器等设备的端口关闭后,在指挥中心的交换机上Ping该分中心交换机依然不通。在这台交换机上使用命令dis logbuffer查看告警信息,也没有发现异常信息。在该交换机上还发现了一个特殊的现象,同在一台交换机下的服务器、硬盘录像机和磁盘阵列互相Ping会出现丢包严重的现象。

为了排除故障,我们配置了该分中心的备用交换机,问题依然存在,但是只要断开该交换机的上联口,这些设备之间互相Ping是没有问题的。

通过上面一系列的排查可以确定,引起故障的环节不在分中心。

接下来继续排查上游设备——城区传输设备C5566。使用命令show interface查看了连接分中心的端口流量已经达到了100%,可是据该分中心摄像头总数不足20路,怎么会有这么大的流量呢?

该传输设备上共连接了3个分中心,目前其他两个分中心业务正常,只是视频监控画面出现了卡顿的现象。使用命令show interfacer gig1/18查看了传输设备连接OLT端口的利用率,已经达到87%。为了保证OLT至传输设备间的链路畅通,我们决定使用链路聚合来实现两台设备间的链路扩容,配置命令如下:

上面我们分别在C5566和OLT上配置了链路聚合,做完这些操作后,可以看到流量已经逐渐在两个端口上进行分担,这说明已经实现了链路的扩容。完成这一小插曲后,继续处理指挥中心至分中心的网络故障。为了进一步排查故障,尝试将该传输设备上的其他在用的端口都关闭,发现问题依然存在。

在文章的开头我们介绍了分中心和指挥中心的通讯依靠的是路由,即VLAN2,然后通过VLAN2达到调看分中心图像的目的,这样就会在C5566和OLT之间使用TRUNK端口,即允许互联VLAN2和业务VLAN120通过,我们上面所做的Ping测试都是在10.0.0.1上Ping的 10.0.0.10,这是互联VLAN2的地址。在这里我们做一个假设,如果将该端口的VLAN120删除那么VLAN2会正常吗?按照这一思路我们将该端口的VLAN120删除后,果然可以在指挥中心Ping通分中心VLAN2的地址10.0.0.10。故障分析到这里变得扑朔迷离起来,那么为什么端口一加入VLAN120,就会影响VLAN2通讯呢?

故障解决

按照网络层次的划分,仔细检查了端口的配置,均没有发现问题。既然数据链路层没有发现问题,那么就需要对物理层展开排查。物理层两台设备互联无非的物理端口、光纤和光模块,光纤和光模块我们进行了更换,均没有奏效。因为C5566上已经没有了空余端口,索性将该分中心连接到了OLT上,就在配置完OLT的端口并且连接完光纤后,网络恢复了正常,在指挥中心可以正常Ping通分中心的互联地址,同时调看分中心的视频图像也是没有问题的,这样故障就排除了。

故障总结

经过这次故障的排除,我们可以断定,是C5566上的端口出现了故障。为了验证这一说法,我们将C5566连接的其他正常分中心业务的端口,连接到出现故障的分中心上,网络也是正常的,也就是说C5566上连接故障分中心的端口出现了问题,才导致指挥中心访问分中心出现故障。

在以往处理网络故障的时候,我们时常遇到交换机端口损坏的情况。但是在这次故障的排查过程中,遇到光口损坏还是第一次,而且该端口损坏后,出现的现象还很特殊,即端口利用率达到100%和VLAN之间互相影响。

其实在这次网络故障的处理过程中,从得知故障现象后,我们按照自上而下的方式进行排查,先后在分中心、数据基站采用了排除法和假设的办法,最终将故障的原因锁定在了C5566的光口上,最后通过更换端口的方式达到了处理故障的目的。在此过程中我们还完成了设备间链路聚合的小插曲。

猜你喜欢
分中心交换机端口
自然资源部国土空间大数据工程技术创新中心武汉分中心
一种端口故障的解决方案
基于地铁交换机电源设计思考
交换机生成树安全
修复损坏的交换机NOS
国家测绘地理信息局卫星测绘应用中心河南分中心
端口阻塞与优先级
使用链路聚合进行交换机互联
高速公路监控分中心网络配置探析
各地分中心 海选现场