把好网络设备关 交换机设备引发的故障

   我公司是一家县级供电企业，由于服务客户的需要，在上级部门的统一部署下，我们也建立了 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、 在检查网络故障时，不能只看数据量大的包，有些数据包，一个可能就成为造成网络故障的“毒药“ 。