一个正常工作的网络给人们带来方便和快捷是不言而喻的，而一个带病工作的网络也常常给人带来无穷的烦恼甚至是巨大的损失。因此作为安恒公司的一名网络测试工程师，多年的测试经历使我非常希望将网络维护方面的经验与同行们分享。这里介绍的案例是一个比较典型的分析过程，为了方便起见我将这里的真实用户信息作了替换。

某日，某机关信息中心的网管张先生给我公司打电话希望能帮助排查一下其内部办公网络的故障，这个故障已经影响他们的网络运行一段时间了。在我们到达现场后，张先生给我们介绍了他们单位的网络情况（见图一网络拓扑）和网络故障表现。据张先生介绍，基本上所有的网络成员访问服务器2时的速度都非常缓慢，Ping测试联通性表现良好，均在2ms以内，从服务器上拷贝一个30Mbytes的文件竟需要5分钟左右。为此他们作过了很多的调整，甚至考虑到要将服务器升级和将网络升级。

图一、网络的结构示意

通常这种看似简单的故障实际上很难直接判断其产生的原因，有时可能是网络本身的问题，或是网络应用的问题，还有时可能与网络或服务设备的配置有关。因此从哪里入手进行测试变成关键问题。为了进一步了解用户网络的整体情况，我们决定首先安装一套美国福禄克公司的网络监测管理软件，以便能获得更多的网络信息。这套软件采用分布式结构，我们在用户的各个网段内分别安装一个监测站，用我们的笔记本电脑作为监测控制台与各监测站通信，获取信息并集中显示（见图二）。
 

图二（点击放大）

从上述图中，我们可以概括了解每个网段中都有哪些设备（服务器、交换机、路由器、RMON设备等）？这些设备是否出现了严重的问题（注意红色的圆点）？每个站点的流量情况是否有异常（柱状图中是否出现红色的部分）？在确定没有太大问题后，我们开始查看网段的详细信息并找到了用户抱怨的服务器，见图三。

图三

在没有得到直接有价值的信息后，我们使用“交换路由追踪”功能测试一下某一个客户端到该服务器的传输链路情况，见图四。从图中我门可以看出该客户机和问题服务器2正好连接在同一个Cisco交换机的端口3和端口5上。该交换机连接客户机的端口3开启了历史记录功能，可以方便地得到流量、广播、冲突和错误方面的统计信息，图中显示该端口没有任何网络层的问题。而连接服务器的端口5则没有启动历史记录功能，因此无法得到服务器方面的统计数据。

图四、交换路由追踪

问题的根源是不是在服务器这一边？我们立即在图一的3位置将Optiview便携式网络综合协议分析仪接入服务器所在的网段。通过网络搜索功能很快找到这台Cisco交换机并查看连接服务器的交换机第5端口的流量情况，见图五。发现该端口流量并不大，不应该造成客户端访问慢的故障。转而检查端口错误情况也没有发现错误的数据包，但是存在冲突的现象。

图五、第5端口的流量情况

图六

这个异常情况引起了我们的注意，该端口只连接服务器唯一一个设备，怎么会有冲突呢？我们切换到交换机列表状态进一步检查该端口的信息（见图六）发现连接速率是10M/半双工，而该交换机是支持全双工连接方式的，有没有可能是服务器和交换端口双工不匹配的原因？在征得用户同意后，我们断开服务器与交换机的连线，串接进去一个网络万用表进行测试，得到的结果证实了我们的推测（见图七）。服务器的网卡工作在全双工模式，而交换机端口自适应功能失败，使其只工作于半双工模式，这样就造成两端的双工模式不匹配，产生冲突错误。初步找到故障原因后，用户临时将服务器的网络设定为半双工模式后，我们同样从服务器上拷贝一个30Mbytes的文件只需要十几秒钟，而且采用Optiview监视也没有发现冲突现象。问题得到确认，解决问题的方法竟如此简单，只需将图七中显示的交换机的端口工作模式手工设置成全双工的模式即可。

图七、双向箭头显示着全/半双工的工作状况

背景知识：
那么不匹配的双工模式为什么会产生冲突，进而影响整个网络的数据传输呢？因为运行全双工的设备不遵从（带冲突检测的载波侦听多路访问）过程。如果全双工设备有数据帧要发送，它就直接发送而不关心当前是否在接收数据。此时，如果与其相连的一个半双工设备恰巧也正在发送数据，则必定发生冲突。遵从CSMA/CD的半双工设备会立即发送一个阻塞信号，在退避延时时间过后，它将重新发送数据并引发网络性能的下降。

如果交换机内部开启了SNMP或具有RMON功能，则会统计冲突数量并记录在MIB库中。当我们接入Optiview网络综合协议分析仪后，通过其读取交换机中MIB库的信息就可发现冲突发生的历史记录，正是这一统计信息引导我们找到了困扰用户很长时间的网络故障。

 

经验与总结
在排除比较复杂网络的故障时，我们常常要通过多种的角度来测试和分析故障的现象确定故障点，我们会采用自上（网管系统）而下（现场测试）相结合的方法，还要采用理论和经验相结合的技术背景。

在分析和解决互联的网络中访问性能的问题时，我们通常有这么几个分析的模型和方法：

１． 七层的网络结构分析模型方法：从网络的七层结构的定义和功能上逐一地进行分析和排查，这时传统的而且最基础的分析和测试方法。
这里有自下而上和自上而下的两种思路。自下而上：从物理层的链路开始检测直到应用。自上而下：从应用协议中扑捉数据包，分析数据包统计和流量统计信息以获得有价值的资料。

２． 网络连接结构的分析方法：从网络的连接构成来看我们可以大致分成客户端、网络链路、服务器端三个模块。

a) 在分析和检测中故障可能来自客户端的各种情况，客户端也具备网络的七层结构，也会出现这样那样的故障，从硬件到软件，从驱动到应用程序，从设置错误到病毒等等。所以在分析和测试客户端的过程中要有大量的背景知识，有时ＰＣ的发烧经验也会有所帮助。在实际的测试过程中可以在现场询问客户端的用户，他们反映的问题是个性的还是共性的，这个问题会非常有助于决定对客户端的进一步检测的决定。
b) 来自网络链路的问题通常需要网管、现场测试仪、甚至是协议分析仪来帮助确定问题的性质和原因。这个方面的问题分析要有坚实的网络知识和实战经验，有时实战经验会决定排除故障的时间。
c) 在分析服务器端的情况时更需要有网络应用方面的丰富知识，我曾经排除过这样的一个故障，最终定位在服务器上的数据库参数设置上！要了解服务器的硬件性能及配置情况、系统性能及配置情况、网络应用及对服务器的影响情况。

３． 工具型分析方法：有强大的各种测试工具和软件，它们的自动分析和专家系统能快速的给出网络的各种参数甚至是故障的分析结果，这对解决６０％的常见网络故障有效。

４． 综合及经验型分析方法：靠时间、错误与成功的积累，在大多数的网络测试工程师的工作中都是采用这个方法，再结合网管和测试工具迅速定位网络的故障。

本案例的分析中，我们首先要确定问题是否是共性的、然后试探确定问题是否发生再网络链路上、有幸的是这个问题的测试过程就到这里结束了，否则不知要动用多少的脑筋和设备进行更多的分析了。

通过这个典型案例不难看出，要快速有效地排查网络故障，简单依靠单一手段和测试设备是很难的，只有通过多种测试仪器和经验的相互配合，采用排除法逐步缩小故障范围才能最终查找出故障原因加以排除。本案例已经加入到安恒网络维护学院的《网络维护经典案例分析》中。