打印本文 打印本文  关闭窗口 关闭窗口  
把好网络设备关 交换机引发的故障
作者:陈鹏  文章来源:eNet  点击数  更新时间:2009/9/11 23:32:02  文章录入:陈鹏  责任编辑:陈鹏

我公司是一家县级供电企业,由于服务客户的需要,在上级部门的统一部署下,我们也建立了 95598 客户语音服务系统,如下图所示:我公司放置一台 Avaya G250 排队机,下面有几台 IP 电话。语音服务的相关 CTI、语音服务器等设备,正常的流程是当客户拨入电话后,先通过 G250,经过C6509 交换机,接入到上级网络的 CTI等服务器进行处理,当客户进入转人工后,再通过 C6509 交换机,转给 G250,然后转给 IP电话进行处理。

故障现象及解决:

前些天,我们发现 IP 电话经常无法接电话,但可以外拨电话。用 PC ping 上级网络上的服务器,ping 了一个晚上,只丢了一个包,看来网络也是正常的,当时怀疑是 G250 有问题。因为只要 G250 重启后,头几个电话都可以正常接通。所以,我们只好把厂家技术人员找来了。

网络故障


厂家人员来公司后,进行系统自测,没有发现问题。但登录到上级网络的设备上后发现我公司的 G250 在不断地登录上级设备,而其他县供电公司的设备没有问题。厂家人员怀疑我的网络防火墙有问题,可能阻止了某些端口。但我把防火墙撤离了,问题依旧。由于一时也找不到问题出在哪里,我抱着试试看的心理打开了 OmniPeek,对网络进行扫描。但看起来网络很正常呀,没有 ARP极具特点的大量的 Arp Response 广播包,网络上的其他广播包也不多,正当我准备关闭 OmniPeek时,一个数据包引起我的注意。

网络故障


公司的一台华为交换机发 Arp Response,宣称自己是网关!但是和 Arp 病毒不同的是,它在五分钟多的时间里只发了一个包。由于这个交换机是其他部门的,我没有口令,只好把交换机的端口关闭掉,然后再测试 95598,问题就解决了。登录到 C6509,运行 show log 命令,发现如下日志:

*Dec 29 15:27:04: %IP-4-DUPADDR: Duplicate address 10.141.122.254 on Vlan122, sourced by000f.e21d.0632

*Dec 29 15:27:34: %IP-4-DUPADDR: Duplicate address 10.141.122.254 on Vlan122, sourced by000f.e21d.0632

*Dec 29 15:28:04: %IP-4-DUPADDR: Duplicate address 10.141.122.254 on Vlan122, sourced by000f.e21d.0632

*Dec 29 15:28:34: %IP-4-DUPADDR: Duplicate address 10.141.122.254 on Vlan122, sourced by000f.e21d.0632

*Dec 29 15:29:04: %IP-4-DUPADDR: Duplicate address 10.141.122.254 on Vlan122, sourced by000f.e21d.0632

*Dec 29 15:29:34: %IP-4-DUPADDR: Duplicate address 10.141.122.254 on Vlan122, sourced by000f.e21d.0632

*Dec 29 15:30:04: %IP-4-DUPADDR: Duplicate address 10.141.122.254 on Vlan122, sourced by000f.e21d.0632

*Dec 29 15:30:34: %IP-4-DUPADDR: Duplicate address 10.141.122.254 on Vlan122, sourced by000f.e21d.0632

*Dec 29 15:31:04: %IP-4-DUPADDR: Duplicate address 10.141.122.254 on Vlan122, sourced by000f.e21d.0632

*Dec 29 15:31:34: %IP-4-DUPADDR: Duplicate address 10.141.122.254 on Vlan122, sourced by000f.e21d.0632

*Dec 29 15:32:04: %IP-4-DUPADDR: Duplicate address 10.141.122.254 on Vlan122, sourced by000f.e21d.0632

--More—

估计是由于该交换机启动后和交换机的地址冲突造成的。

事后我找到该交换机的所属部门,查看设备配置,发现他们竟然将自己的 vlan 地址设置成 C6509交换机的地址!修改配置后,再将该交换机接入网络,问题不见了。

经验教训:

从这件事情上,我们可以总结如下:

1、 必须对接入自己网络的设备进行把关,尤其是交换机之类的设备。
2、 在检查网络故障时,不能只看数据量大的包,有些数据包,一个可能就成为造成网络故障的“毒药“ 。
打印本文 打印本文  关闭窗口 关闭窗口