单位网络结构图如图1所示。为了确保重要设备的稳定性和冗余性，核心层交换机使用两台Cisco 4507，通过Trunk线连接。在接入层使用了多台Cisco 3560交换机，图示为了简洁，只画出了两台。在核心交换机上连接有单位重要的服务器，如DHCP、E-MAIL服务器、WEB服务器等。单位IP地址的部署，使用的是C类私有192网段的地址。DHCP服务器的IP地址为192.168.10.1，E-MAIL服务器的IP地址是192.168.3.1。Cisco 4507和Cisco 3560之间也是Trunk连接。

　　图1 单位网络结构图

　　公司根据部门性质的不同，把它们划入到不同的VLAN中。服务器都位于VLAN 2至VLAN 10中，对应的网络号是192.168.2.0~192.168.10.0，如DHCP服务器位于VLAN 10中，流媒体服务器位于VLAN 2中。服务器的IP地址、默认网关和DNS都是静态配置的。VLAN 11至VLAN 100是属于业务部门使用的，对应的网络号是192.168.11.0~192.168.100.0。VLAN 101至VLAN 200是属于办公部门使用，对应的网络号是192.168.101.0~192.168.200.0。VLAN号和网络号之间都是对应的。VLAN中的PC都是通过Cisco 3560接入到网络中，3560都是二层配置，三层的配置都在Cisco 4507上，也就是VLAN间的路由都是通过4507完成的。PC的IP地址、默认网关和DNS都是自动从DHCP服务器上获得的，不用手工静态配置。

　　一、故障发生的过程

　　公司流媒体服务器位于VLAN 2中，IP地址为192.168.2.8/24。网络中有权限的用户可以进入到服务器中下载、上传和编辑一些视频剪辑。一天早上，业务网VLAN 12中的很多用户反映它们部门的人员都不能访问流媒体服务器，也不能进入服务器中流媒体应用系统的Web界面。

　　但是VLAN 12中的用户访问其它VLAN中服务器上的应用，都很正常中，如都能正常访问VLAN 3中的E-MAIL服务器。而且办公网和业务网中除了VLAN 12，其它VLAN中的用户，都能正常访问流媒体服务器，也就是只有VLAN 12中的用户访问不了。因为流媒体应用是单位业务中一项很重要的应用，若长时间不能用的话，可能会影响到公司业务正常运转，所以必须尽快排除故障。

　　二、排查故障的步骤

　　1、通过对故障信息的收集，我们确定了网络故障的大概示意图，如图2所示。不能访问流媒体服务器的用户IP地址的网络号都是 192.168.12.0/24。他们访问流媒体服务器的路径先是到Cisco 3560，通过Cisco 4507，最后到达服务器。

　　图2 存在故障的网络示意图

　　2、我们到不能访问流媒体服务器的部门，查看了用户的PC，发现电脑上的IP地址，默认网关、DNS都是正确的。然后我们在用户电脑的"命令行"中执行"ping 192.168.2.8"命令，结果ping不通。然后又执行了ping VLAN 12网关地址的命令"ping 192.168.12.254"，发现能ping通。为了确定出具体的故障部位，又在"命令行"中执行了"tracert 192.168.2.8"命令，显示的结果如下所示：

　　C:\ >tracert 192.168.2.8Tracing route to 192.168.2.8 over a maximum of 30 hops1 <1 ms <1 ms <1 ms 192.168.12.2542 * * * Request timed out.3 * * * Request timed out.

　　上面命令的显示结果还有27行省略了，因为数据包不能到达目的地，后面27项和第2、3项的内容一样。

　　从上面的结果可以看出，用户访问流媒体服务器时，数据包只能到达192.168.12.254，再往下路径就发生了故障，不能到达目的地。从前面的介绍知道Cisco 3560上是没有IP地址配置的，它们都是作为二层交换机接入到网络中的，所有三层的地址都是在Cisco 4507上配置的。也就是用户访问流媒体服务器的数据能到达4507，然后再往下就不知道哪出现了故障。可能是流媒体服务器故障，也可能是连接流媒体服务器和核心交换机4507之间的链路发生了故障。

　　3、为了确定是服务器故障，还是服务器和4507之间链路的故障。我们把连接服务器的千兆网线接头拔下来，然后把接头接入到一台状态良好的PC上，PC上的IP地址、默认网关、DNS的配置和流媒体服务器上的配置完全一样。接着，再次在不能访问流媒体应用的用户电脑上执行了"ping 192.168.2.8"，结果一切正常，网络是通的。

　　4、到现在就能确定，问题出现在流媒体服务器上。不过，现在还不能确定是服务器上流媒体的应用系统有问题，还是服务器上的网络设置方面有问题。接着我们查看了服务器上网络方面的设置，如图3所示，是在服务器"命令行"中执行"ipconfig /all"显示出的结果。

　　图3 流媒体服务器的IP地址配置

　　到这里已基本确定引起网络故障的原因，就是因为在流媒体服务器的网卡上配置了两个IP地址，其中192.168.12.18/24就是引起故障的错误配置。

　　5、在流媒体服务器控制面板的"网络连接"中，找到和IP地址192.168.2.8对应的"本地连接"，然后双击"本地连接"图标，在"属性"→"Internet协议(TCP/IP)，属性"→"高级"，找到了添加错误IP地址192.168.12.18的地方，如图4所示。

　　图4 添加/删除IP地址示意图

　　在图4中，选中IP地址192.168.12.18，然后点击"删除"按钮，就把网卡上错误的IP地址删除了。这时，VLAN 12中的用户也可以正常访问流媒体服务器中的应用了。

　　三、总结

　　1、如图5所示，是网络故障期间，在流媒体服务器的"命令行"中执行"route print"命令得到的结果。其中，红线标出的，就是上面在用户的电脑上执行"tracert 192.168.2.8"命令后，数据包不能从流媒体服务器返回到VLAN 12用户PC的原因所在。

　　图5 流媒体服务器中的路由表

　　因为在VLAN 12中的用户PC上执行"tracert 192.168.2.8"的命令后，Tracert数据包中的目的IP地址是192.168.2.8，PC根据电脑中的默认网关地址192.168.12.254，先把数据包传输到Cisco 3560，然后再到达Cisco 4507。4507查看了Tracert数据包中的目的IP地址是192.168.2.8，知道它是要去往VLAN 2中的，然后4507把Tracert数据包传输到流媒体服务器。

　　当流媒体服务器收到Tracert数据包后，发现数据包的目的IP地址正是自己的IP地址，它把数据包收下后。然后根据Tracert命令的约定，它还要给VLAN 2中的用户PC返回一个Tracert数据包，这时返回的这个数据包的目的IP地址，对应的网络地址就是192.168.12.0/24，接着流媒体服务器就在自己的路由表查找到达目的网络192.168.12.0/24的路由，结果它就在自己的路由表中就找到了图5中红线标出的路由项目，在其中它找到网络192.168.12.0/24，是和自己的链路，也就是网卡直接相连的，因为路由项目中显示的"网关"对应项是"在链路上"。这种情况下流媒体服务器就不会把要返回的Tracert数据包路由到VLAN 2之外。结果VLAN 12中的用户也就不会收到返回的Tracert数据包。

　　2、通常在计算机网卡、交换机和路由器的端口上都能配置两个或多个IP地址，在前两者上的主要作用是为了实现连接在同一局域网上不同网段之间的通讯。一般由于一个网段中所包含的IP地址对于用户来说不够用，就可以采用配置多个IP地址的办法来扩大接入到局域网中用户的数量。而在路由器的端口上配置两个或多个IP地址主要是实现连在同一路由器端口的不同网段的通讯，但这时要注意启用端口上的IP重定向功能，因为一般路由器不允许从同一端口进来的IP数据包又发回到原端口中。启用了重定向功能，就允许在同一端口进入路由器的IP数据包由原端口再发送回去。但是在计算机网卡、交换机和路由器的端口上配置多个IP地址常常会给网络带来意想不到的故障，所以一般没有特殊需求，不要在同一端口上配置多个IP地址。

　　3、这次公司流媒体服务器的故障也是因为，在故障的前一天晚上，负责流媒体应用系统软件开发的厂商在公司调试软件，因为软件测试的需要，要在流媒体服务器的网卡上临时再配置一个IP地址，技术人员就随便配置了192.168.12.18这个地址。测试完成后，技术人员离开公司时忘了把这个IP地址删除掉，结果就导致了第二天早上的网络故障。

　　按照单位的规定，对机房服务器上每一步重要的操作，都要记录在服务器日志登记本上。完成操作后，要逐项查看登记本，是否把服务器恢复到了初始的正常状态。但因为双方的技术人员都没有严格执行机房房管理规定，从而造成了意外的疏漏。看来网络管理无小事，必须从点滴做起，从我做起。