网络故障汇编

网络故障汇编
案例一： 
　　最近调试ADSL网络，遇到一些问题，提供一些解决方案如下：
　　笔者所在地区为河南，ADSL采用河南通信公司统一的虚拟拨号软件，大致原理为DHCP加上Web认证，当输入帐户与密码，马上可以连接到internet，但是该拨号软件与许多杀毒软件、防火墙还有其它的一些程序兼容性不好，经常出现一些网络故障，造成拨号上网不成功。
　　ADSL局域网，工作站二十台，服务器采用Win98/Win2000 Server系统，代理软件分别采用sygate和操作系统自带的ICS连接共享，但是一旦服务器无法拨号，工作站就无法正常上网，严重影响公司的正常使用，而且sygate还有连接共享经常出现异常情况，其中包括服务器可以正常上网，而工作站却不能上网，工作站可以上网的时候，此时服务器却不能上网，为了整个网络的稳定性，决定不再单独设置服务器。
　　经过一段时间的使用，笔者发现，该虚拟拨号软件采用动态分配IP地址，其DHCP的租约期限一般情况下为一天，就是说，在一天之内再次拨号，通常还是保留上一次IP地址，该虚拟拨号软件要求计算机必须自动获取IP，根据这种情况，可以使用ipconfig /all来显示上一次拨号的IP地址，并将IP地址、子网掩码、网关、DNS指定在对应的网卡上。在每一台计算机上都可以通过拨号上网以后，记下IP地址，将其绑定在网卡上，当然，每台计算机的IP地址都各有不同。
　　 例如：IP地址:218.29.228.41
　　　　　子网掩码:255.255.255.0
　　　　　网关: 218.29.228.254
　　　　　DNS：202.102.224.68 　　202.102.227.68
　　需要注意一点，由于ADSL虚拟拨号获得的IP地址是可以被外界访问的IP地址，所以通过这种方式可以强行绑定一个公网IP，使用起来肯定是比较方便的，可以不通过拨号直接上网，但是由于设备与技术方面的种种原因，用户使用固定的公网IP也是比较容易遭受攻击的，具体使用哪一种方式上网，当然要根据实际情况而定。
　　经过一段时间的使用，大家都感觉比较好用，至少原来的服务器不能上网的时候，不再影响其它的工作站，但是又发现了一个新的故障，就是无论怎么设置，整个局域网上网的时间最多不超过一个小时，观察ADSL信号以及局域网的传输信号一切正常。但是，将ADSL调制解调器的电源切断，然后再接通电源，等过一分钟以后，ADSL完成与局端的同步，整个局域网就又全部可以正常上网，但这却最多还是维持几十分钟。
　　根据笔者维护网络的经验，初步判断是数据包传输碰撞，造成的网络风暴，以至于电信局端传输过来的ADSL数字信号不能有效地到达工作站，ADSL现在的接入方式是插到hub上，其它计算机与其并联。由于hub不能有效地对数据进行交换，笔者建议购买交换机。
　　自从使用交换机以后，整体上网就非常稳定，不再出现掉线等其它现象，任何一台电脑可以不通过拨号开机直接连入Internet。

案例二： 
   [症状]某大型化工股份有限公司信息中心报告网络故障，新近进行网络的更新升级和扩容，由10M网全部提升为100M以太网，核心交换机为千兆以太网。完工后系统试机时发现，大部分的网络成员感觉速度慢，有时数据出错，但子网段内拷贝数据速度基本不受影响。Ping测试检查所有工作站和服务器均正常。遵照网络医院上周的建议他们对网络布线系统进行严格认证测试，布线施工质量优良，全部电缆光缆链路按超五类标准测试参数均合格，没有发现任何问题。由于信息中心除了电缆和光缆的认证测试仪外，没有其它测试维护工具，无法对网络进行评测。虽然仔细进行了网络系统及平台的重新安装，仍无济于事。由于总公司希望全面提高ERP系统的覆盖范围，新增的网络设备比较多，网上成员也增加了二倍多，工作站从原来的220台猛增至680台，办公区和生产区之间、生产区和生产区之间均用光缆和路由器连接起来，因此洪主任抱怨现在网络的管理成了问题，查找故障不象从前那样容易了，一来网络规模比以前大多了，故障数量和种类增多，二来网络结构变得比以前复杂多了，故障的定位分析和隔离变得比较困难。 
   该网络各子网段基本上采用核心交换机和工作组交换机作网络骨架，用桌面交换机和集线器混用的方式构成基层用户接入平台，核心交换机之间为千兆以太网连接，用户全部为100M到桌面。为了便于维护和管理，同时也从安全角度考虑，设计方案中将大多数数据服务器均安装在了网管中心。 
   [诊断过程]网络为新扩容的网络，从拓扑图上看不出网络结构设计有何不合理之处。由于在各子网段内拷贝数据时速度基本不受影响，所以分析数据多在跨网段时受阻。将网络测试仪接入办公区网络的网管中心，打开网段内的全部4个路由器的端口观察，网段间的流量为27％～42％之间，由于网络没有多媒体应用启用，因此如此高的流量记录是不正常的。我们需要观察这些流量的走向，于是在办公区将网络测试仪串入路由器与交换机之间(100M端口)监测，启动IP矩阵监测和以太网MAC矩阵监测功能，观察数据流向。结果如下，大部分的数据流向均指向办公区的WINS服务器，而WINS响应流量极少。查看拓扑图，该WINS服务器直接与一台工作组交换机相连，打开工作组交换机的端口记录检查，流量记录为13％，伴随少许碰撞指示记录。为了不影响用户的使用，下班后我们从测试仪所在端口向WINS服务器所在交换机端口P32的邻近端口P31发送高额流量，选值为90Mbps流量冲击，并在此邻近端口P31观察接收到的流量记录，记录显示为89.7Mbps，这说明端口P31的通道测试是合格的。然后对准WINS服务器所在端口P32发送90Mpbs的高额流量，观察P32端口流量冲击记录，结果显示为13.5％，并出现大量延迟帧，表明该端口通道测试不合格。将流量发送方向指向与该端口连接的上游端口P17，观察P17流量显示为90Mbps。问题很清楚，被丢弃和延迟的流量就在P32口。对WINS本身作WINS查询，10次测试响应只有2次，响应地址正确，响应率20％。重新测试WINS链路电缆，合格。测试WINS服务器网卡，合格；测试交换机的端口P32，低效。在此临时将WINS服务器端口P32改接到端口P33，重新启动系统，5分钟后进行上述测试，全部合格。为了验证P32口低效，用网络测试仪接入该端口并向P17发送90M流量，收到流量为12%。由于这台工作组交换机为新品，尚在保用期之内，因此建议立即更换之。 
   [诊断评点]网络中的大多数数据服务器由于设置在办公区的网管中心，所以公司整个系统的工作依赖集中式系统中的这些专用数据服务器，链路连接和数据交换时需要WINS服务器提供服务。与WINS服务器连接的链路中，交换机一侧的端口P32发射能力低效，使得发送的信号幅度不符合要求，由于链路长度不长，所以并不是对所有的数据包WINS服务器都无响应。有些数据被作为部分错误和碰撞数据由端口记录之，大部分从交换机各端口送往P32端口的的数据因链路接口问题被延迟和丢弃，造成记录数据中有用流量正常，而网络用户速度普遍偏慢的假象。交换机、网卡、集线器和路由器等网络设备的端口一般从工作2～3年开始出现低效现象，5年比例为3％～18％(这取决于不同的厂商产品质量，也取决于同一厂商的不同系列产品的产品质量)。由于系统中有大量的端口，所以在网络维护周期建议中要求每半年对端口性能进行定期测试。每一～二年对布线系统进行一次轮测，尤其对重要的网络设备如服务器、交换机、路由器等应该坚持定期测试，这样做对提高网络的可靠性有莫大的帮助。 
   [诊断建议]建议“病人”所有网络设备进行一次普查，将全部端口都进行备案测试，并列入定期维护的内容之一。 
   [后记]经处理被告之，上班后所有网络用户都惊喜地发现，网络速度比之以前有了惊人的表现，速度真正大幅提高，皆大欢喜。
案例三：【多协议使用，设置不良，服务器超流量工作】 
   [症状]今天的故事发生在某机电进出口公司来电告知他们的网络昨天刚刚进行了升级，从10M以太网桌面应用全部升级为100M以太网交换到桌面，结果出现局域网内网络访问速度反而比升级前慢的现象。有的访问很长时间没有结果，有的则出错。他手里有几款侦测网络流量的软件，启动运行后也没有发现任何问题。对服务器的Ping测试平均小于1ms，应该不会慢，但不知何故会如此表现。 
   [诊断过程]这个故障看起来比较简单，实际诊断却颇费周折。该网络由4个路由器经帧中继线路与国内总部和国际分部链接，占据4层楼面，由2台千兆核心交换机和二级5台工作组交换机(每层一台)以及20台桌面交换机(每层4台)组成，100M交换到桌面，结构比较典型。从故障现象看，网络联通性尚可，但速度受影响。一般来说，速度慢的原因有很多，比如网上设备速度跟不上要求，网络设备出现阻塞或瓶颈效应，电缆光缆系统问题使得网络数据出错或产生高额碰撞，网络协议设置错误造成无效的重复访问，应用软件或协议设置错误访问受阻等等。由于刚更新了网络，原来的电缆系统又没有经过认证测试，根据以往的经验，电缆系统存在问题的可能性最大，所以我们决定先检查电缆系统。鉴于所有网络成员都有速度问题，我们先抽取部分电缆尤其是主要服务器的网络电缆进行现场认证测试。 
   系统电缆采用的是超五类线，用电缆认证测试仪测试20条电缆链路，结果出伏出乎意料地全部合格！改用网络测试仪对抽测的电缆人工模拟发送流量，结果当发送至75％流量时，碰撞率仍不超过5％，表明网络布线系统虽然在工程完工后没有进行认证测试，但电缆品质和施工品质还是不错的，实属少见。转而进行网络健康指标评测，除了服务器流量严重超标以外，其它如错误、碰撞、广播等都合格。检测流量分布，基本上都集中在服务器链路上，平均流量达91％。令任意两台工作站之间进行拷贝文件操作，速度很快。说明问题很可能就出在服务器与工作站的协议流程障碍上。启动F683网络测试的ICMP Ping、Scan Host、ICMP Monitor等功能测试，检查其IP协议的工作质量，结果显示正常。这说明，网络连接通道性能是可以的，问题出在协议的5层以上。 
   启动网络测试仪的协议分布侦测功能Protocol Mix，结构发现其Apple Talk和BanyanVines协议流量分别为47％和39％，合计流量为86％。进一步显示运行该协议的是两台主服务器。 
   询问网络部主任网络设计运行的是什么协议，答曰全部是基于视窗环境的单一的IP协议。为何会出现Apple Talk和Banyan Vines？答曰根本未知。 
   由于这两种协议有没有参与该公司的业务流程尚且不明，故暂时不能贸然将其删除。必须尽快核实现在的业务软件是否依赖这两种协议。网络部主任告知他是一年前接手网络部主任一职的，对业务流程软件并不熟悉，但知道现在运行各软件的供应商。我们请他立即与该软件开发商联系，15分钟后对方发来传真明确说明该公司的软件只在Windows平台上运行，不支持Apple Talk和Banyan Vines等应用平台。为慎重起见，我们请各业务部门的代表集中辨认并统计现在各自所用的操作平台和软件，结果都不包括Apple Talk和Banyan Vines。至此，我们决定对该协议平台进行卸载。一边操作一边请林先生查阅以前网络档案，结果发现了这两种平台的安装软盘和应用软件安装软盘。 
   完成协议清理作业后，重新启动网络，网络访问立即恢复正常。 
   [诊断评点]非工作协议是指在网规划和络设计中未被选用的协议和应用，但他们存在于各种网络平台之中。作为网络上的“游魂”之一，他们会耗用少量网络带宽。常用的被捆绑于视窗平台的协议如IPX、IP、NetBEUI基本上没有冲突。所以许多用户虽然没有同时使用这几种协议但也会时常同时捆绑这些协议。NetBIOS设置有多种平台协议的输入输出接口，有助于众多协议的交互工作和各种协议平台及其应用的并存。但从网络性能优化的角度看，各种协议平台和应用版本是由不同厂商开发的，兼容性始终是一个动态适应的过程。没有一种始终能紧密跟踪各种协议平台和应用协议变化、相容和协调的有效方法。从这个意义上讲，多协议工作的冲突是不可避免的。 
   翻阅六年前网络档案我们发现，该网络多年以前一直使用的是Apple Talk和Banyan Vines平台协议，当时是请ALP国际公司提供的应用软件并负责安装工程。直到三年前才全部安装启用视窗平台和基于IP协议的新的应用软件，但APL公司的人员没有将老平台卸载，而是简单地停止启动运行。后继的网管人员在交接时因不熟悉这些协议及其用途，没有进行清理。最近的这次的网络升级工程安装调试时根据原先的网管记录和服务器平台的提示重新安装并启动运行了这些软件。询问负责软件安装的网管人员是否了解这些软件的用途，答曰因为在老平台的窗口中一直看见这些软件，其间也曾询问过一直任职的财务经理，证实有用，所以才重新安装之。实则该平台的设置与新的应用软件之间有严重冲突，并同时干扰现行应用软件的有效工作。两台服务器之间一直在互相询问并重新发送无法处理的无效数据包，除了干扰其它协议外，直接的结果就是占用大量的网络带宽，破坏数据的传输和处理，致使网络速度变慢并时常出错。 
   另外，网络部手里的诊断软件都是基于视窗环境的应用软件，无法观察其它应用的流量。 
   [诊断建议]协议的无缝互联和互操作是软件开发工程中的难点。实际的应用软件品质并不如开发商所标榜的那样乐观。为了使网络的工作效率达到最佳，网管人员需要经常监测网络协议数量及其工作状态。对于无用的协议要即时清理之。重要网络在协议监测对新出现的协议还要监测其操作过程，查找其来源。因为许多网络在遭到黑客攻击时常会伴随某些新协议的活动。 
   [后记]经过一周的观察，删除无用协议后网络一直工作正常。其网络部将其它一些无用协议进行了清理，现在的网络速度可以说是非常地“爽”。
案例四：【水晶头损坏引起大型网络故障】
　
   [症状]某大公司规模发展很快，两周前对网络实施了一次比较大的扩容工程，新增加了200台工作站(为新员工配备)，网络规模由2000个站点增加到2200个站点，全部在一个网段中。该公司采用100BaseT以太网结构，用两个路由器实现与生产基地和开发基地的连接(新换2个155ATM骨干)，以前我曾建议他们将网段划分小一些，以便管理和隔离故障，但因网络未出现什么大的故障，加上公司网络管理员的丰富经验和自信以及维护经费未落实等原因，网络一直保持了这种大型网段的“危险结构”。这次扩容同时将两条广域网骨干链路升级到155ATM，但网段结构仍然未作根本调整，计划留待下期工程时再作打算。本周内网络已多次出现阻塞现象，每天至少两次，每次阻塞时间10～30分钟不等。逐个仔细检查了新安装的200台工作站，没有发现任何问题。由于故障不是持续存在，Boss催得又紧，故令公司网络管理员颇有些“精疲力尽”的感觉。
   [诊断过程]上午10:00，打开路由器的MIB库，记录的参数基本正常，网络平均流量13％。其中有约1.5％左右的碰撞，表明网络结构的绝大部分构件是好的。给新增加的200台工作站Share一个软件，然后每40台一组同时下载并操作该软件，结果证明200台工作站工作基本正常。将F683网络测试仪接入网络，同时将F693网络流量分析仪也接入网络进行监测。下午14:21分，网络阻塞现象出现，持续时间15分钟，F693流量分析仪监测的流量正常，平均流量从9％上升到13％，一分钟后下降为8％，但F683网络测试仪的流量报告为84％左右，其中碰撞帧占82％～87％，少量FCS损坏帧(约2％～4％左右)。记录该时间前后的Protocol Matrix协议对话图谱，发现在15分钟阻塞时间内共有137个工作站曾发送或接收过数据，其中4个工作站一直在持续收发数据，有一个工作站发送的数据包流量一直占其它工作站流量总和的15倍左右。幸好公司网络管理员以前对站点的Mac地址做过文档备案，依据仪器显示的Mac地址我们立即确定了这4个工作站的使用者(流量最大者是财务科陈小姐的地址)。随即询问他们最近有无更动过硬件和网线，有无增删或调整过软件，回答均是“没有”。询问陈小姐刚才在使用何种软件与生产基地的小张联络 (Protocol Matrix协议矩阵指示为小张的工作
站)。回答是“机器一直就连在网上，但刚才没有使用计算机”。将网络测试仪连接到陈小姐的台式机网卡接口上，模拟发送流量，结果碰撞随流量的增加而大幅增加。测试该链路的网卡和网线，显示插头为3类插头，链路近端串扰超差比较多。重新更换5类插头后，网络恢复正常。
   经过私下再三询问原因，陈小姐才道出了实情。
   [诊断评点]本故障是由更换不适当的3类插头引起的。新员工小张是陈小姐的多年不见的同学，也是个网虫。此次与陈小姐在新公司相遇，自然倍感亲切。一周前小张在帮陈小姐安装新声卡时不慎将插头损坏，随意用一个3类插头更换之。临近新年，陈小姐在小张的指点下从网上陆续下载了不少大容量的贺年卡，均为动态电影格式，可以在网络上实时传送播放并加上双方对话，非常有趣。该站点平时使用的财务软件无论是传输速度和数据量都很小(3k左右)，对整个网络系统影响不大。但在向小张放送解压后的动态电影贺年卡时数据流量约在3~4Mbps左右。由于网线问题，事后推算传输的数据帧约有13％是有效的，其余均被反射和串绕所破坏须重新发送，表现为网络上大量的碰撞帧和少量的FCS帧。
   [建议]大型网络不划分网段既不便于管理又很难隔离网络故障，此种结构是非常少见的，同时也是非常危险的。该公司网络大部分采用的是集线器，只有很少几台交换机，这对故障隔离也是不利的。另外，一定要对员工进行上机前教育，不能随意增删、更改软件和网络设置。所幸的是公司网络管理员本人经验非常丰富，平时已将文档备案工作做得很细致(国内多数网络在文档备案时不将网卡的Mac地址备案)，否则是不可能在半小时内查出本故障，一般来讲，可能会耗费1～3天左右的时间才行。
   [后记]公司网络管理员经过此次“洗礼”，也悟出一点当好IT经理经理的绝招。至少他已不再认为仅凭经验就可以“打遍天下无敌手”。网络维护是一门艺术，更是一门科学或工程，没有适用的工具和科学的方法是达不到这最高的“艺术境界”的。至于陈小姐，我们还是愿意善意地再为她，也为小张保守一段时间的“秘密”。

案例五：【网线制作不标准，引起干扰，发生错误】 
   [症状]某证券公司求诊，要求查找错误源。近日股市火爆，新增不少用户，但一周内已经三次出现交易数据错误，数据恢复也进行了三次。虽然涉及的金额不大，与证券交易所的资料核对不上，昨晚对历史记录和当日交易记录进行了比较，发现在同一时刻往往有几个用户的交易数据出错。怀疑存在病毒或恶意用户捣乱的可能，用多套软件查杀病毒，并重新安装系统，恢复备份的数据。不料今日故障现象依旧出现。
[诊断过程]该网络99年2月进行了改扩建，全部采用NT平台。最近又新增家50个站点。根据一般经验，先对新增加的工作站极其联网系统的状况进行常规检查。由于现在已经休市，网上错误无法观察。用流量发生器模拟网上流量进行体能检查，结果如下：正常数据帧下限帧长64Byte各类型帧体能检查，网络致瘫流量为99％,上限帧长1518Byte的致瘫流量为99.5％，错误帧50Byte短帧致瘫流量为90％，错误帧4000Byte超长帧致瘫流量为97％，碰撞最高时为6.4％，略偏高。无新的错误类型出现。从交换机处测试只发现少数传输延迟数据包，以上数据说明，被检查的网络是一个“身体素质”相当好的证券网络。仔细研究发生错误的工作站，发现是在同一个新增用户的集线器组当中，该网段通过一交换机接口与服务器相连。除了对交易服务器和行情服务器分别进行体能检查外，对该网段内的工作站也进行体能检查，各站表现正常。各工作站模拟流量和交易也都正常。可以基本判定，该网络是一个承受能力很强的优秀网络。由此我们怀疑可能存在“恶意用户”(注：恶意用户是指在工作站上安装自备软硬件或将工作站网卡插头拔下并将自带笔记本电脑私自接入的用户，其目的叵测)。为了跟踪数据出错的情况，将F683网络测试仪接入该网段作长期监测。第二天故障现象没有出现。第三天下午开始后10分钟，即13:10分，网络测试仪监测到该网段大量错误出现，其中FCS帧错误占15％，幻象干扰占85％，约持续了1分钟。FCS帧涉及本网段的3个用户。该证券系统装备有CCTV闭路视频监控系统，从长时录像机中可以发现故障对应时刻13:10有一个用户使用了手机，仔细辨别图像画面发现其使用的是对讲机。
   无风不起浪，对讲机的功率比微蜂窝手机的功率要大得多，使用频率也更接近网络基带传输的频带，容易对网络造成近距离辐射干扰。但是，一个合格的、完整的UTP电缆系统在5米外还完全能抵抗不超过5W的辐射功率。从故障现象推断，本网络的电缆或接地系统可能有一些问题。随即决定查找本网段50个站点的布线系统(扩容时没有经过认证测试)，用Fluke的DSP2000电缆测试仪进行测试，测试结果全部通过。只在中心集线器与交换机端口的插头发现接头线做得很差，外包皮与接头之间有15厘米的缺失，线缆散开排列，双绞关系被破坏。交换机的物理位置离用户仅隔一面玻璃幕墙，直线距离1.5米左右。可以基本断定，对讲机发出的较大功率的辐射信号就是由此处串入系统的。
   重新按TIA568B标准的要求打线，连接好系统。
　
   [诊断评点]出问题的网线接头是扩容施工时的最后一根遗漏的网线，为本部工作人员自己临时增补上的。他们不了解TIA568B所要求的打线标准，乃随意为之。系统中串入干扰的途径有多种，比如大动力线与网线并行距离太近或干脆就在同一个走线槽内；与某些辐射源(包括日光灯、电焊机、对讲机、移动电台等)距离太近；系统设备的接地回路不良等等。本案是由散列的网线接头引入近距离的辐射干扰造成。由于对讲机用户比较特殊，他们的干扰是短时的，查找时有时需要“守株待兔”。当然，如果网线全部经过严格的测试，应该不会出现本例故障。
　
   [诊断建议]建议按标准化的布线环境来设计布线系统，更改系统结构后一定要测试电缆。合格的UTP电缆系统抵抗辐射干扰的能力是很强的，但要求电缆系统必须经过严格的测试(事实上多数布线系统只测试过物理连通性，未做严格认证测试，存在着大量的隐患)。大量的问题都出在不起眼的接头上。建议年检时将布线系统作为年检内容全部检查一遍(也可以以一年或两年为周期平时进行轮测，测试标准可选用北美标准TIA568A/568B或ISO11801等)。营业室内最好禁止使用大功率对讲机，部分大功率模拟手机也要列入禁用清单。
   故障检测中，应重点检查最近动过的或变更过的设备，此为经验之谈。不过，一个有趣的现象是，当你向某个事后证明他确实更改过设置的用户询问时，经常得到的答复却是：没有动过任何东西。 
   [后记]按约定时间接到了该证券公司的通报，系统已稳定地工作了两周，没有再出现同类问题。施放干扰的用户是一位具有合法使用对讲机权利的公务人员(在此不便披露具体细节)，利用工作之便业余炒股，每天会到股市“例行巡查”一番，已接受劝告。
案例六：【插头故障】 
   [症状]某电信移动计费中心，用户反映，近三个月移动用户总数增加了近30％，但移动计费的营业收入却只增加了5％，怀疑计费系统是不是有问题。从计费服务器查看收费记录，没有发现什么问题。检查计费服务器软件，工作正常。从路由器另一侧的财务服务器检查，内部的财务服务器显示的计费数据与计费服务器的数据没有差错。查找电话局局端记录，发现记录次数超出移动计费的记录次数。最后作实地测试，用移动电话拨打50次，记录次数45次，记录时间与实际通话时间一致的次数为30次。历时一周，还不能确定故障位置。 
   [诊断过程]计费服务器连接到一台16端口交换机Bay28115的第一插槽5号端口。第6号端口下挂一个100Mbps的以太网，网管机HP Open View也设置在此。打开网管系统，准备观察5号端口的工作情况，这时才发现无法打开5号端口的工作表数据记录。询问网络管理人员，告知3个月前因交换机故障自行更换过备用的Bay28115交换机，更换后系统工作很正常。查看维护工作记录登记和日志，没有任何关于Bay18115的维护说明，也没有关于网络工作参数的记录(记录上显示的还是系统开通时的原始数据)。询问网管人员为何不设置并打开交换机工作表的Mib。答曰网管系统是一年前安装的，平时只用来看看系统设备是否连接以及是否有报警信号，更多的功能也不会用。前任网络管理员已调任工作岗位，实际上现在已没有人会使用和设置网管系统。由于系统开通是有系统承包商负责的，自行更换交换机后没有发现什么问题，也没再 仔细检查。
   用网络测试仪的协议对话分析功能从网管机所在网段观察计费服务器的工作情况，发现服务器对约有1/3的数据包没有回应。为了不影响系统工作，于凌晨3:00在移动用户使用率底的时候用F683网络测试仪模拟服务器测试5号端口，显示链路工作于10Mbps速率(原始记录显示此端口的速度应该是100Mbps)。由于交换机没有启动SNMP支持功能，故临时在5号端口安装了一只10Mbps的集线器与服务器连接，用网络测试仪从这个集线器的任意端口对计费服务器发送数据并观察服务器数据流工作情况。发现大量碰撞和错误的FCS帧，当流量为30％时，碰撞及错误流量占21％。用电缆测试仪检查服务器电缆，发现靠交换器一端的插头处近端串扰NEXT严重超差。重新更换插头并正确打线，碰撞率下降为0.5％，错误率为0％。去掉临时集线器，重新启动交换器的SNMP功能，从交换器某空闲端口向服务器发送流量，用网管系统观察5号计费服务器端口，当流量为40Mbps时，碰撞率、错误率、广播率等参数均表现优良。服务器自适应恢复为100Mbps链路速度。
   重新进行两组各50次实际拨打测试，计费数据完全正确。可以基本肯定计费功能已全部恢复正常。 
   [诊断评点]本次故障的原因非常简单(一个插头问题)，但表现出来的现象则稍微复杂一些。该服务器使用的是一个10/100Mbps的自适应以太网卡，设计链路速度为100Mbps。网管人员在更换交换器时曾不小心将插头拉坏，随即更换了接头，但确留下隐患，不过，维护人员并未及时发现速度方面异常。服务器链路此时的实际工作速度已经下降为10Mbps。新交换器没有启动SNMP支持功能，网管系统也就不能观察计费服务器的端口工作状态。在平时的维护工作中，该计费中心的维护人员基本上不用网管系统定期观测并记录网络的工作参数，当故障出现时就不能觉察到服务器工作速度的变化。有趣的是，如果电缆没有问题，即使将链路速度设置为10Mbps，计费服务器应该还是能正常工作的(计费信息的网络流量一般不高)。在本故障中，计费服务器繁忙时由于碰撞率和错误率太高，服务器无法处理一部分数据包，其中已经被“挂号”的部分数据包将被丢弃，造成计费数据不准确。 
   [诊断建议]布线系统平时要定期轮测(一至两年轮测意义遍)。更换链路元件后一定要对链路进行测试(尤其是100Mbps链路，必须用电缆测试仪测试)。网管系统要指定专人进行维护使用，一般来讲，网管系统可以覆盖约35％左右的网络故障，因此强烈建议重要的网络要安装支持SNMP或RMON协议(多数网络设备都支持SNMP协议，部分支持RMON)，启动已有SNMP、RMON等功能的网络设备，否则网管系统将形同虚设。维护工作要求有及时完整的记录，这对提高处理故障的速度是非常必要的。 
   [后记]经过一个月的运行，收费系统“贡献”了35％的收入额，大喜。
[案例七]5类线Cat5勉强运行千兆以太网 
   [症状]某期货交易所，网络改造为千兆以太网后只有1个网段能正常工作，其它12个网段工作均不正常，数据时有出错，连接经常会莫名其妙地中断。每个网段用千兆以太网连接起来，下挂的网段均是100Mbps用户端口。起初怀疑是系统运行的平台或者软件有问题，经过多次重新安装和设置仍不能解决问题，而且同样的系统在其它地方的交易网络中应用是正常的。因而转向怀疑是否是布线系统的问题，比如电缆不合格或是有干扰信号串入以及接地系统等方面的问题。每个网段均利用升级前铺设的电缆系统连接起来，未作大的更改。由于计算机网络的布线系统采用的是标准的5类线方案，根据千兆网的设计标准，采用4对线全双工工作，5电平编码，占用的信号物理带宽正好是100MHz，故5类线应该是完全可以胜任的，况且一般情况下期货交易网络现有的流量水平远不能达到满载运行的程度，流量很低。重新用专业电缆测试仪作过严格的认证测试，显示参数合格并且不存在脉冲噪声干扰或接地方面的问题。
   所谓能工作的那一个网段是因为行情和交易服务器都安装在该网段中，本网段内的工作站与服务器除了个别站点外都可以上网连接工作，进行行情浏览和交易割接。其它网段内的服务器对内连接时除了个别工作站外也基本正常，共同特点都是不能与行情服务器和交易服务器所在网段实现良好连接。系统升级时原布线电缆全部保留不动，经过测试也全部合格，不知原因何在？ 
   [诊断过程]不能连接的因素很多，象网络硬件设备的功能设置问题、布线系统的问题、操作平台的安装设置问题、应用软件的安装设置和软件冲突方面的问题等等。从用户所反映的情况分析，各个网段内的站点基本上全部能工作，网段之间的连接比较困难，可以初步确定故障出现在网络设备设置和布线系统性能等方面的可能性大一些。
   将网络测试仪F68X接入能连接服务器和交易服务器的网段(100Mbps)，观察网络流量5分钟平均为12％，FCS帧校验错误帧约11％，碰撞率1.7％(正常范围)。显然FCS帧校验错误比例偏高，查看错误源，显示为其它网段站点产生FCS帧错误的比例占错误帧总量的97%。各网段的错误帧比例差别不大。由于有大量的FCS帧普遍存在，所以各网段内的各站点同时出问题的可能性很小，用F683向各网段内的服务器或站点发送流量，FCS帧错误随流量增高而迅速增加，各站点或服务器反映基本一致。启动网络测试仪的ICMP Ping功能，统计对各网段内选定的站点和交换机、路由器等的测试结果，表现基本一致，即：ICMP Ping断层约96%，ICMP Monitor显示目标不可达占91％。改在其它网段内作同样内容的测试，对行情服务器和交易服务器所在网段的路由器和交换机结果基本与前项测试相同。所不同的一点是，对其它网段内的交换机和路由器等网络设备的测试结果显示是正常的，数值为：ICMP Ping断层为0％，全部可以通达，ICMP Monitor目标不可达为0％。基本可以肯定，故障出在行情服务器网段与其它网段的连接链路上。用FLUKE公司的DSP-4000电缆认证测试仪选用TIA Cat5n Channel UTP100标准测试，显示长度为25米，链路测试不合格。其中，回波损耗RL和衰减串扰比ACR等参数超差。改用同样长度的一根超5类线Cat5e代用之，启动系统，除了各网段内个别站点外，整个网络恢复正常。监测高峰时的流量，服务器所在网段最高时平均流量为3％，可见故障时12％的流量主要都来自大量的重发帧流量。 
   [诊断评点]千兆以太网可以满足网络用户对大带宽应用的“贪婪”胃口，无疑是网络下一步的重点发展方向。千兆以太网的设计者在选用电缆类型时对5类线Cat5已经存在的应用规模考虑比较多，所以选择的物理带宽为100MHz。这样，原则上5类线是可以运行千兆以太网的。但实际的统计结果表明，仍有1％～5％的用户不能上网或连接出现断续和困难。也就是说，千兆以太网对5类线的参数要求更严格一些。只要用户对5类线布线系统进行过严格的认证测试，可以保证绝大多数的站点是可以联网工作的。少数站点因为某些参数余量小可能有上网困难的现象。影响比较大的参数有综合近端串扰PS NEXT、综合远端串扰PS FEXT、等效远端串扰ELFEXT、综合等效远端串扰PS ELFEXT、回波损耗RL、衰减串扰比ACR等。此时需要对5类线进行Cat5n标准测试，该标准是专为用5类线运行千兆以太网的用户准备的，如果依循该标准测试都合格，则可以放心地用5类线系统运行千兆以太网。新的Cat5n标准中，回波损耗对系统的影响比较大，并且，由于电缆匹配方面的阻抗不连续问题，越短的电缆链路反而越容易出问题。本例中，由于电缆长度为25米，虽然衰减串扰比ACR参数也不合格，但，回波损耗引起本故障的可能性要大些。 
   [诊断建议]对5类线的认证测试可以适当考虑选用Cat5n标准进行测试，这样可保运行千兆以太网网时不出问题。如果选用超5类线Cat5e进行布线，则一般不会有不能运行千兆以太网之虞。对用Cat5n标准诊断出来有问题的5类线链路，为了以最小的成本换来网络性能的提高，一个最简单的办法就是用超5类线Cat5e代换参数不良的个别链路。注意，联结模块最好一并更换，以保证链路的安装质量。 
   [后记]遵循我们的建议，两周后该期货交易所将全部的安装链路用DSP-4000电缆测试仪选用TIACat5n标准进行了测试，全部站点数为1300个，不合格链路21个。对不合格的链路改用超5类电缆后所有站点均工作正常，网络状态保持优良(该网络平均流量高峰时才3％)

[案例八]电缆超长，LAN可用，WAN不可用
　
   [症状]今天的病人是某进出口公司，开通DDN专线后部分用户抱怨数据交换的速度变慢，且经常有联结中断的现象。网络支持人员虽经多方查找仍不得要领，故请求网络医院出诊援救。
   该公司的网络结构原先是单纯的局域网，分布在三层楼面中，共有300个站点，每个楼层有100个左右的用户。配线间设在最上面一层的楼层中，用交换机将各楼层共分成三个网段。以前员工均使用拨号上网方式实现与Internet的联结，自我感觉网络速度还比较快，工作一直很正常。新近增加了路由设备，并申请开通了DDN专线。每个楼层用集线器将用户联结起来，结果最低楼层的员工反映有时速度很慢，并常有莫名其妙的中断现象。由于该公司没有配备任何网络监测工具，且在局域网内传输数据不受影响，只在上Internet网时才有麻烦，故直到工程竣工两周后才向网络医院求援。
[诊断过程]该公司的网络为10Base-T局域网，此次只增加了DDN设备和路由器，其它配置基本不变。故将网络测试仪F68X从最低楼层的某个用户端接入网络进行观察，平均流量为1.2％，未发现异常。改用流量发送功能作流量逐级递增的体能测试，也未发现任何异常。表面上看，该网段似乎没有什么问题。为快速定位网络故障，将流量发送到其它网段，同时观察网络状况。随着发送流量的增加，1分钟后发现错误帧，帧类型为FCS错误帧，并指示FCS帧来自第二层的某个用户。显然，只据此现象就判断故障原因为该工作站的网卡损坏或网卡驱动程序错误，似乎显得“证据不足”，因为整个楼层的用户反映的故障现象是相同的。继续观察到5分钟，发现FCS错误帧数量增加为10个用户左右，由此可以断定不是某个工作站的问题。为此，令其它楼层多个用户与故障楼层用户交换数据(比如拷贝文件)，结果发现多个FCS帧错误。打开交换机端口工作表观察，本楼层的记录中也显示FCS帧错误，而其它的交换机端口工作表中没有FCS错误记录(交换机为非切发型交换机)，这说明是本网段内存在者线缆超长的链路。再试着向Internet某个已知用户发送流量，并且进行ICMP Ping测试，结果发现损失率为90％左右。由于刚才本网段内的体能测试未发现异常，所以只能是集线器与交换机联结的单条链路有问题。测试该电缆，长度指示为175米！超长。 
   [诊断评点]根据网络规范，以太网为碰撞侦听共享介质方式工作的。每个工作站到集线器的网线长度应不超过100米，方可保障无延迟碰撞(同轴电缆)或FCS帧错误。由于175米超常链路在集线器和交换机之间，所以本网段内的用户在交换数据时可以顺利进行。但与其它网段的用户交换数据时就可能处问题。但由于网络平均流量低，虽然在整个局域网内存在FCS帧错误影响，对低流量局域网内的数据交换而言，其对速度的影响甚微。当同时有多个用户通过DDN进行WAN数据交换时，FCS帧错误将导致64K的出口流量浪费加大。这是因为64K比10Mbps的速度要低得多，流量中错误帧的比例较高，进入WAN链路时可能要经过多次重发才能实现远程数据交换，感觉网络速度明显变慢。且由于经常有FCS错误帧，较容易引起WAN链路联结时因错误而中断，综合表现为故障楼层的所有用户都抱怨速度变慢且常中断。 
   [诊断建议]网络速度低时很多故障现象都将被掩盖起来。建议网络拥有者在新的网络工程结束时应该进行两项验收：网络布线系统现场认证测试和网络验收测试(最起码要作体能测试和加载条件下的逐个工作站的模拟上网测试)。
   [后记]一周后该公司重新划分网段施工结束，用户来电报告一切正常。

[案例九]线缆连接错误，误用3类插头，致使网络升级到100BaseTX网络后无法上网
　
   [症状]某船运公司，为满足日益增长的业务需求，三周前开始网络升级改造工程，按设计规划将10BaseT网络全部升级为100BaseTX以太网，电缆系统不作任何改动。昨天设备安装调试工程全部结束，今天凌晨开始网络割接作业。所有工作站更换100BaseTX以网太网卡，然后分批接入网络。此时工程人员发现一些奇怪现象，比如：有些工作站不能联入网络；有些工作站第一次可以联入网络，过一段时间再次连接则无法进入；有的工作站开始时能联入网络并且工作很正常，但过一段时间后则出现连接断续或数据出错的现象。集成商起先以为是网络平台安装不当，遂将系统平台重新清理并安装了一次，出问题的工作站系统软件和应用软件也进行了重新安装，结果毫无改善。“折腾”了将近一整天，也无法为用户提供服务，业务基本中断。 
   [诊断过程]接到报告后立即赶到“出事地点”，启动包括故障工作站在内的全部系统成员进入网络运行。用F683网络“万用表”对故障网络首先作常规健康测试，一分钟后测试结果如下：网络利用率1.3％(此时员工已经全部下班)，碰撞率8％，错误率11％，广播9％。显然网络碰撞率和错误率比较高，打开错误诊断定位功能，显示FCS帧错误、本地碰撞、碎帧等错误计数。这说明网络可能存在网卡工作失常、电缆系统故障、干扰或接地回路等方面的问题。查看具体的FCS错误帧测试结果，发现有许多工作站发出错误的FCS数据帧。一般来将，同时存在多个网卡失效的故障是不大可能的，此时的FCS帧错误多数由电缆问题尤其是有超长链路的电缆问题所引起而不是由网卡所引起。但为慎重起见，我们先随机抽查其中两张网卡进行测试，结果正常，再测试对应的集线器端口，其物理参数结果正常，工作协议匹配无异。由此则可以有把握地确定故障的原因是由电缆系统的问题引起的。
   用户告知，本系统采用的是五类线，共有270台工作站，划分为6个网段，有一个专网路由器和一个公网路由器，升级前一直工作在10BaseT以太网状态，整个系统除了业务一部经常反映网络速度偏慢和偶尔的连接断续外，其它部门使用状况一直很正常(业务一部工作量最大)。今天开始升级工作后部分工作站出现上面提到的各种故障现象，涉及范围大约有近三分之一的工作站。询问用户以前是否对布线系统进行过测试，答曰：“只测试过通断，因为在10BaseT以太网一直能上网，所以布线系统应该不会有问题。”为快速定位故障，随机抽取了其中10条有问题的链路进行测试，结果为：一分二插座故障8个，3类线连接模块3个，综合近端串扰PS NEXT参数不合格4个。检测结论：该系统布线工程存在严重问题。 
   [诊断评点]网络布线工程的低劣质量一直是综合布线工程中的一个让人担心的严重问题。目前虽然有成熟的测试标准和方法，但多数用户并不知悉或不要求按标准进行现场认证测试。本系统的电缆故障存在多种原因，均是由于工程设计、施工和验收不规范造成。现分述如下：
   a)一分二插座故障：系由接线错误所至。用户在设计时没有考虑到扩容的需要，所以在新增用户时采用了这种不规范的一分二插座，一个插座可以连接2个PC机。从原理上讲这种用法是基本上可行的，这种接法要求将1-2/3-6两线对联接一台PC机，而将4-5/7-8两线对联接到另一台PC机上。但实际的测试结果却发现线对接法是1-2/3-6和4-5/3-6，用户把3-6线对当成了直接的“共享媒体检测总线”！！在10BaseT网络中这种错误接法可以勉强工作。虽然这会造成全部网络流量中的数据帧会存在不少错误，但由于多数现存网络的利用率(流量)不高，用户是难于察觉布线中程中的此种异常情况的。100BaseTX网络对阻抗不匹配和近端串扰比较敏感，升级后这种错误接法会导致上网困难；(注：同轴电缆可以用三通匹配连接器将工作站接入网络，此时阻抗仍保持连续，但双绞线不可以直接并联，否则阻抗异常。)
   b)该系统在用户数增加，网线数量不敷使用时网管人员进行了自行扩容，不幸的是他们选用的是假冒的5类插头(实际上是3类插头)。在10BaseT网络3类插头不会影响网络正常运行，但升级后近端串扰NEXT等参数将严重影响工作站与网络连接并经常导致数据出错。不经测试，此3类插头将会长期潜伏而不被发现。
   c)由于采用一分二插座，测试电缆的近端串扰指标时必须考虑其它线对的综合影响(非一分二接头的链路多数只使用两对线的网卡)，因此，在数据流量大时，综合近端串扰PS NEXT等参数不合格的链路有可能出错或导致工作站连接困难。 
   [诊断建议]网络投入运行前，布线系统(电缆、光缆)要首先进行认证测试，用户可以选择的标准很多，目前多建议选用TSB-67或ISO11801等国际流行标准进行测试。只测试物理通断后就认为链路肯定可用，这一认识是非常片面的也是非常有害的。采用一分二插座的链路一定要测试综合近端串扰、综合远端串扰等高端参数，最好选择Cat5n标准进行认证测试。为此，我们建议船运公司将全部布线链路连夜进行测试和清理，并对清理后PS NEXT等高端参数仍不合格的链路进行最后标记，以便日后进行更换。 
   [后记]第二天清晨，测试工作全部结束，共发现连接错误的一分二插座88个(全部接错)，误用3类插头54个。在纠正了所有插座故障和误用的3类线插头后，除了少数几条链路外，所有工作站均能投入正常运行。中午时分，中断了一天多的各项业务终于得以全面恢复。随后进行的网络性能评测也基本合格。对于个别高端参数不合格的链路，我们建议网管人员随后更换链路或先暂时取消一分二的连接方式，以保证数据传输的正确性。

[案例十]网线共用，升级100Mbps后干扰服务器
　
   [症状]今天的“病人”是某移动电话公司计费中心。据该中心的网络主管人员介绍，为了缓解移动电话用户解交电话费难的问题，该中心三个月前投巨资对原计费中心的网络进行了调整和升级。与四家被委托代收手机费的银行之间的网络连接速度从标准的64Kbps速率DDN专线全部扩展为E1(2.048Mbps)速率，计费中心网络从10Mbps以太网全部升级为以交换机为主的100Mbps以太网。升级前各委托收费银行经常反映网络连接时常莫名其妙地中断，但一般能迅速恢复，业务妨碍不算大。升级后网络速度提高了很多，但其下辖的各营业网点(共计120个)在为手机用户办理交费收费手续时计算机屏幕上常会提示“网络远端故障，无法提供数据”或“数据传输不稳定，请检查网络”，此时营业网点的收费服务会暂停，用户意见很大。有时虽然还能提供服务，不过数据处理速度明显变慢，最差的时候处理一笔业务查询竟然需要反反覆覆操作5、6分钟(正常时一般在10秒钟以内)。比网络设备升级前反而要慢得多。此故障每星期都要出现1到2次，每次从1小时到2小时不等。由于一直没有查明升级前网络时常中断的真正故障原因，网络管理人员在做此次网络升级规划时曾心存侥幸地寄希望于通过设备升级来彻底排除这些遗留网络故障。遗憾的是，他们的运气实在太差，非但老问题没有解决，反而惹出了更大的新问题。遂向网络医院“挂号”求诊。 
   [诊断过程]由于银行网和电信计费网不在同一个地方，出了“网络医院”我们需要决定先去哪里？从上述的故障现象初步分析，银行络网和移动通信公司计费中心网络以及其连接的链路都有可能存在问题。计费中心的网络设备和路由设备大部分在此次升级时都更换过，升级后故障依旧存在且表现更严重，基本可以排除新入网设备存在严重问题的可能性。网络测试可以从银行网络和计费网络同时着手。途中从银行各营业厅网络使用者处了解到，手机收费出现“麻烦”时银行的其它业务流程均保持正常，并不受此影响(此时电信计费中心网络的用户也没有反映网络异常)。这说明银行网络存在问题的可能性要比计费网络及其连接链路存在问题的可能性低。而问题出现在手机计费网络和与银行网络的路由设备范围内的可能性比较大，故我们决定先前往设在移动通信公司机房的手机计费网络进行检查测试，首先检查计费网络及其连接链路。
   第一次网络测试是在网络没有出现故障时进行的，结果显示各项测试指标都显示网络工作完全正常。将F683网络测试仪接入计费网络的交换路由器，监测网络的工作状况，显示路由器利用率为1％(相当于E1链路中有20Kbps左右的业务流量)，错误统计为0%，与网管系统观察的数据完全一致，将F683网络测试仪改为与计费服务器并联的方式监测，测试结果相同，这表明此时网络工作很正常。在与计费网络所在地的局域网使用和维护人员交谈中了解到，网络工作人员从来没有感觉到他们的LAN有异常情况，虽然他们也知道手机用户在经常抱怨，但从计费LAN处检查不出什么实质问题，计费服务器表现也正常。故障出现时从网管系统上观察，路由器、交换机、计费服务器都没有问题。用OneTouch网络助理(即网络故障一点通)仿真用户流量对银行的路由器、银行网业务转接服务器(以上测试在银行进行)、移动通信公司的计费网络与银行网络的连接路由器、网络通道上的交换机、计费服务器等进行2分钟80%持续流量冲击测试(上述测试在计费中心)，用F683网络测试仪监测移动监测各关键设备，结果基本相同，利用率为均80%，无错误出现，除了计费服务器处的碰撞率2%外，其它各处均为0%；ICMP Ping测试均在3ms以内，ICMP监测测试无拥塞、数据不可达、重定向、数据参数错误等显示，这说明，网络的通道测试结果是比较好的。在这种情况下，一般可以采用两种测试方法继续检查故障，一种是被动监测法，即将网络测试仪、流量分析仪、网管等监测设备启动，对网络实施不间断监测，等待问题的重新出现；另一种是主动测试法，即将所有涉及到的网络设备和终端设备及其业务均启动或进行人为地仿真模拟，然后监测网络的工作状态，进行故障定位。为了尽快定位故障，经与计费网、银行网网络管理人员商定，我们决定采用第二种方法进行监测和测试(注意，此测试方案需要动用很多的人力和物力)，即将所有有关的网络设备网络终端设备启动，并安排人员进行业务流程模拟操作。
   第二次测试在当天业务结束后进行。在启动所有网络设备5分钟后，预期的故障现象果然出现。从网管系统上观察，计费网和银行网的连接路由器流量上升为3％，交换机流量增加1倍，计费服务器流量减少70％，网络没有发现异常情况。用F683网络测试仪对整个计费通道的有关链路和设备进行移动监测，结果显示：路由器和交换机的数据与网管系统的观察结果一致，而计费服务器的流量为68％，正常数据7%，错误数据61％(幻象干扰Ghosts、FCS错误碎帧等)。很显然，计费服务器与交换机之间的这条链路很可能有问题。
   暂停业务，从计费服务器网卡上拔下电缆插头进行电缆测试，结果显示只有1-2和3-6两对电缆，4-5和7-8线对没有连接。网管人员解释，升级后除了新增加的布线外，电缆系统多数没有变动，只有少数链路进行了调整。进一步检查发现4-5和7-8线对连接到了另一台备份服务器上，该服务器用于每周两次人工对各种关键数据进行审查、备份并上报局有关单位。恢复业务，启动备份服务器进行数据备份和传输，结果故障现象出现。将备份服务器临时用一条新链路单独连接，故障彻底消失。对换下的电缆进行测试，近端串扰NEXT不合格(超差－2dB，综合近端串扰PSNEXT－8dB)
   [诊断评点]网络电缆内含4对(8根)细电缆线，一般的10Base-T和100Base-Tx网络只使用其中的1-2和3-6线对，4-5和7-8线对不用，在10Base-T网络中曾流行将4-5或7-8线对用来传输电话，或者用4-5和7-8线对用来连接另一台电脑。在100Base-Tx以太网中，由于网络工作频率和数据率很高，串扰量很大，故这类用法是不被允许的。计费网络升级前有部分站点用一条电缆连接两台计算机，升级后这部分电缆没有变动，由于离新增加的交换机比较近，故将备份服务器接入了并用电缆。备份服务器平时虽然基本不用，但连接脉冲仍然会对计费服务器造成干扰，只是干扰量很少而已，这就是我们在交换机链路中观察到2%碰撞率记录的产生原因。由于该电缆的综合近端串扰PSNEXT不合格，数据备份服务器在工作时对计费服务器会产生很大干扰，破坏传输数据，使得同一个数据包不得不多次重传和多次重新处理，真实流量急剧上升到68％，重处理流量由0%上升到6.98％。由于服务器使用的是价格便宜的工作组交换机，所以网管系统无法从交换机端口发现链路中存在的严重问题。
   升级前业务偶然有中断的现象，这也是由于并用线缆串扰造成的，由于当时是10Base-T网络，速度低，所以这种影响比较小，往往只是偶尔且是瞬间的影响。 
   [诊断建议]在10Base-T以太网中存在着大量的非标准化布线以及大量不合格的布线链路，由于10Base-T网络工作速度低，这些严重质量问题往往被掩盖起来。直到升级到100Base-Tx以太网后这些问题才会明显地暴露出来。10Base-T网络布线系统中表现不明显的问题同时也给集成商、工程商和广大用户造成一种错觉，认为布线系统只要是物理上联通的就不会有问题，从而忽视了影响链路质量的布线产品品质问题、施工工艺问题对网络造成的严重影响。
   建议网络设计者首先采用标准化的设计方案，且只有工程商和用户在签订建造网络的合同时选用标准化的施工工艺和标准化的现场认证测试方案，才能初步保证综合布线系统的质量。《网络测试和维护方案》中一般建议每年(必要时每半年)对布线系统轮测一遍，以保证布线系统的性能合格，排除因布局变动、用户数量增删和人为调整等原因对布线系统造成的损害。另外，网络的业务工作和故障情况要有比较准确完整的记录，这样才能有助于故障的查找。如果“病人”对自己网络的业务流程比较熟悉，则可以避免动用众多人员加班配合排除故障。
　
   [后记]一周后电话回访该“病人”，得知已经全部将并用链路更换为单独的合格链路，计费网络工作非常良好，手机用户再没有“交费难”的抱怨了。

[案例十一]电梯动力线干扰，占用带宽，整个楼层速度降低 
   [症状]某大型家电制造企业计算机中心主任，今天极其沮丧地了报告了该公司的一起顽固的网络故障。该故障表现虽奇特但比较有规律，具体表现是：公司主办公楼的网络在员工上班的时候运行速度会变得很慢，下班后速度回升，有时基本上能回复到往常水平。故障时间大约三个月，准确“发病”的日期已无从记起。每天上午8:00左右开始发作，症状范围是三楼的整个楼层，现象是速度突然变慢，无论是从互联网上下载文件、收发电子邮件都很慢且经常中断和出错。本楼层中的用户之间在传输文件时、与其它楼层的用户传送文件时或是其它楼层的用户与本楼层的用户交换文件时都要用很长时间，但其它楼层的用户之间互相交换文件则不受影响。第一此发作，故障一直持续了三天我们也没有查明原因。由于三楼是公司设计开发部门，每日都要使用网络环境进行大量的数据交换、资料查询等工作，为了不影响新产品开发进度，当时将研发部的工作时间暂时推迟到下午6:00上班。两周后情况仍未见好转，故障仍然存在。不得以公司决定将研发部与二楼的行政管理部门临时对调，以保证已经开始习惯于上“夜班”研发部员工正常的作息时间。谁知一“临时”就是三个月之久。网管人员将布线系统、网络平台、所有主机和服务器、路由器都彻底检查或互换过，一直未能查出故障琐在。听某知名系统集成商介绍可能是电缆系统的问题，随即将布线系统进行了一次认证测试。结果还真的查出了不少严重问题。比如，原来的5类线系统全部不合格，系采用假冒伪劣的5类线，现场测试只能通过三类线指标。为正宗的“假货”。接插件和模块也大部分不能通过5类线标准测试。进一步对整个大楼的布线进行检查，发现与三楼的情况相同。公司网络基本上还是10Mbps系统，工作一直正常。由于布线工程是三年前做的，现在已经无法联系上当时的系统集成商。公司董事会责成计算机中心将整个布线系统全部更新。经过一个月的紧张施工，工程于前天结束，满心希望通过这次工程能将原有的故障及隐患彻底清理干净，谁曾想，昨天开机调试系统时发现原来的故障依然“顽强”地存在！虽想尽了办法，面对我们的艰苦努力，第三楼层的网络系统仍“无动于衷”。计算机中心的全体员工均感倍受打击，且愧于无法向研发部的员工和董事会“交差”。 
   [诊断过程]根据以往的统计，越是顽固的故障对“网络医院”来说往往越可能是最简单的“病因”引起的。从“病人”“主述”的情况看，布线系统还存在问题的可能性不大。由于网络的设备都经过多次的检查，发生问题的概率应该是比较低的。如果说是网络有关平台安装、应用软件安装和使用以及路由通道等方面的有问题，那么其它楼层的用户应该有类似的问题。分析故障出现的特点，由于故障出现的时间是上班时间，所以故障原因应该与某些定时工作的设备或工作环境有很大关联性。故障造成整个楼层速度受影响，为公共部分故障的概率较高。根据计算机中心主任介绍，包括其它楼层在内的每台设备都进行过逐个关机筛选检查，每台供电设备都进行过替代检查，所以可以保证设备都是正常且合格的。
   分析网络的拓扑结构，每个楼层都是用集线器搭建的10Base-T传统网络。各楼层以及邻近大楼的网络用户之间用一台故障前添置的核心交换机连接起来，端口为10Mbps，路由器与核心交换机经过128k帧中继链路与Internet连接，其它分部及分公司则用DDN和ISDN、VPN连接。在计算机中心设有一台网管机，但没有配置其它维护工具。由于故障只影响一个楼层，很可能是在一个碰撞域内的问题。因公司网络与Internet相连，所以我们从网络医院对该公司的网络先简单地做一下远程诊断。启动网络测试仪F683的便携网管功能，由该中心主任输入其公司路由器密码后，查看路由器和交换机的端口管理信息库，结果发现交换机上与三楼连接的接口存在大量碰撞和错误帧记录。数据如下：流量2％，错误为35％，其中CRC错误占83％，传输延迟96％，碰撞10％。中心主任说从网管机上也看到过类似的数据，只是不清楚其含义，也不知道这些数据会与故障诊断有关(网管机从来不用)！我们需要确定这些数据的具体来源，故第二天抵达现场进行测试。
   将网络测试仪F683接入三楼网络观察，显示网络流量在67％～95之间摆动，错误的流量则在60％～90％之间摆动。其中多数为Ghost错误，占错误流量的77％，其次为碰撞和FCS帧错误，合计占23％。Ghosts错误(幻象干扰)一般指示网络存在严重的干扰。由于干扰比特没有以太网的帧结构特征，在碰撞域内又可以随处游荡，所以这类故障在没有测试工具的条件下一般很难进行诊断。
   用F43电力谐波分析仪测试供电质量，谐波含量指标较大，但未超标，说明电力质量尚可。用场强计测试970MHz以内的空间电场强度，合格。那么干扰信号是从何处进入网络的呢？一般可以用如下方法检查：检查接地系统，检查设备接地，检查周边大型用电设备，检查无线通信环境，采用“二分法”断电检查串入位置。从故障的特点看，为定期定时故障发生，所以与周边大型用电设备的关系比较大。由于是办公楼，大型用电设备一般以空调、电梯和照明系统等为主，故决定先将电梯、空调等供电系统切断。当切断电梯电源时，故障消失。重新接通电梯电源，故障重现。说明接地或布线系统串如了电梯动力强干扰谐波。检查三楼布线系统，发现一台饮水机的用电电源与布线系统走线槽在一起。立即测试饮水机电源，发现大量高强度干扰谐波，请电工从配电室切断这条电缆，故障消失。 
   [诊断评点]故障原因是电梯动力干扰经过新散装的饮水机电源线传递到网络布线系统，致使网络中的干扰比特流量占很大数值，争用网络有效带宽，破坏网络正在传输的有效数据(表现为大量的FCS帧错误)，使得网络速度大大下降，网络“垃圾”骤增。由于电梯在上下班时间一直有人使用，所以网络工作也“定期”受到严重干扰。下班后，电梯运行频次降低，干扰减少，网络逐步回复到正常运行速度。以下是电工和研发部员工的回忆。
   原来，为了改善工作环境，公司于三个月前为每个部门和科室配备了冷热饮水机。由于三楼休息室电源插座无电，电工检查后发现该插座的电缆没有与配电盘相连(建筑施工时遗留问题)，于是随意将其联线的远端连接到电梯供电动力线的配电盘上为饮水机供电。当时正值炎夏，员工们本来好不开心，心想从此可以随意冷热饮“自助”，没料想却是从此恶梦不断，网络工作异常，严重影响到了他们的正常工作和生活。
   没有人记得这条供电电缆与布线系统安装在了同一个线槽内，并与三楼布线系统穿入同一根PVC管内。本来，有一次机会可以解决故障，那就是如果在这次网络更新工程时能严格地按标准化施工，那么这根电源线将会被分开安装，更新后的网络便可能正常运行。另外，由于有多根网线同时受到干扰，所以在采用“二分法”分割故障区域时只能得出干扰与设备数量有关系这一模糊结论，此非但不能有助于定位真正的故障部位，反而可能将故障诊断工作复杂化。
   [诊断建议]标准化设计、标准化施工、标准化验收(认证测试)是保证网络工程质量的重要手段和方法。其中一条就是要求动力线和计算机网络布线系统必须分开走线。如果采用金属穿管的方法近距离屏蔽，则金属管必须要有良好的接地措施。否则极易获得“得不偿失”的回报。
  测试统计显示，现阶段并不是所有动力线谐波含量都很大，多数动力线谐波含量还是很小的。但用电环境的变化趋势是非线性用电设备的用量越来越多，谐波污染也会越来越严重，且呈加速趋势。为了避免后患，还是少存侥幸心理为妙。 
   [后记]一周后电话回访用户，得知经过检查，还发现其它楼层的布线系统也存在电缆线与布线系统同槽敷设的情况，该电缆上谐波污染可能比较小，没有造成严重的网络“不良反映”。现在已经全部更改，并计划对其它相关建筑的布线也进行一次全面检查。

[案例十二]三类线仿冒5类线，加上网卡出错，升级后比升级前速度反而慢
　
   [症状]病人抱怨他的大多数站点上网连接速度比系统升级前还慢，有的站点时断时续，有的则根本不能上网。原来用的是10M以太网，工作非常稳定，性能优良。升级后全部更换为100M系统，出现上述症状。用户总数未有增加，也没有启用大型软件或多媒体应用软件。重装系统软件、应用软件，重新设置服务器和网站，查杀病毒，Reset所有联网设备均不奏效。其中，有两台机器换到另一地点后能基本正常工作。用笔记本连接到这两个不正常链路的集线器端口上网，也能正常工作。更换这两根网线后现象依旧。将机器还原到原位置，更换网卡(原卡商标为3COM卡)后恢复正常，不知何故。由于以太网大多数用户不能工作，只好暂时退回到10M以太网系统。
　
   [诊断过程]从10M系统的网管上观察，网络的平均流量为3%，低于40％，由于未运行大型软件和多媒体软件，应该不会感到任何速度上的“折扣”。将FLUKE的F683网络测试仪接入Hub端口，测试网络流量为35％。碰撞率为23％，远远高于5％的健康标准。报告的错误类型有：延迟碰撞、FCS帧错误、少量本地错误。基本可以断定是布线系统的严重问题。遂对线缆进行测试，结果显示除了测试点的两根电缆线外，其余所有布线链路的衰减和近端串扰均不合格，用3类标准测试这些电缆则显示全部合格。查看线缆外包装上印有Lucent Cat5的字样，可以断定是仿冒产品。测试两台工作站的链路长度分别为78米和86米，测试其网卡端口，显示网卡发射能力(信号幅度)不足，并且仪器上没有内置的3COM厂商标记显示。
　
   [诊断点评]用3类线外覆5类线产品标记在假冒伪劣产品中为数不少。用户在10M以太网环境中不会出现应用上的问题，一旦升级到100M环境在只有少数短链路能勉强使用。对于两台更换地点后能正常工作的网站，查明链路长度只有3米，且为标准的5类线(平时此站点用于临时测试)。原地点测试长度为45米和37米，由于网卡发射能力弱，信号在100M系统衰减大，造成上网困难。改在3米链路连接时，衰减的影响小，故可以正常上网。网卡测试显示为仿冒卡。
　
   [后记]一个月后，“病人”打电话告述我，重新布线后网络工作完全正常，即使跑一些多媒体软件也丝毫没有停顿的感觉。不好的消息是，原来的系统集成商已不知去向，无法索赔了。

[案例十三]UPS电源滤波质量下降，接地通路故障，谐波大量涌入系统，导致网络变慢、数据出错
　
   [症状]今天的病人是一家著名的证券公司。上午9:45，用户来电请求紧急救援，说大户室中的一群声称遭受巨额无端损失的愤怒的股民们正聚集在营业部计算中心的机房门前，质问为什么实时交易的动态信息显示屏幕出现大片空白，数据刷新和交易的速度都极慢，且经常中断，根本无法进行交易。扬言如果不立即恢复交易，将砸掉证券交易所的计算机。交易大厅的散户门也开始向机房云集，如果不及时处理，情绪激动的股民们很可能真的会将营业部计算中心的网络设备砸个希巴烂。放下电话直立即直奔该营业部，途中继续用移动电话了解得知，该网络为10M以太网，用户数为230个。从卫星接收广播的行情数据，并回传交易信息。由于从卫星接收机监测口观察接收数据完全正常，故网管人员初步判定是网络系统的问题。两个月前就开始有传输数据错误的现象出现，有时数据更新出现空白，数据更新速度偶尔变慢，有时出现断续。虽用网管和协议分析仪检查过，但因这种“症状”并不连续出现，且对网络的速度和股民的交易基本没有影响，故一直心存侥幸，没有彻底查找真正的故障根源。前天参加“第二轮证券系统Y2K统一认证测试”，顺利通过。利用剩余时间对硬件设备进行了检测和维护，之后进行联网检查，网络表现正常。不料今天开市就出现严重问题。
　
   [诊断过程]用F683网络测试仪监测网络30秒，观察网络流量为81％(但网管报告为0.2%)，错误帧97.6%。错误类型为Ghosts(占93％)、FCS错误(又称CRC错误)和Jabber，即幻象干扰、帧校验错误和超长帧，这表明网络中有大量的非法数据包存在。此类症状一般以电磁干扰和接地回路方面的问题居多。为了确定干扰源的准确位置，将大部分与工作站相连的集线器组电源关断，服务器继续工作，观察错误率降为87％，仍然很高。重新打开集线器组电源，用F43电源谐波测试仪观察，发现谐波含量严重超标(最高970mV)。该网络用一台大型UPS电源给所有网络设备供电，测试UPS输入电源谐波，约为输出电源谐波含量的30％，明显低于输出端的指标，断定为内谐波含量超标。启动小型备用UPS后，网络恢复正常工作(为减少负荷，网络设备分批轮换接入)，但网络测试仪显示仍有错误存在，错误率(幻象干扰)下降为1.3％。再次关断集线器组的电源，类型为Ghosts的幻象干扰错误率下降为0.8％，证实仍存在由接地回路串入的幻象干扰，且应该是从主通道进入。摇动卫星接收机的数据输出电缆，幻象干扰时有时无，拔下电缆则干扰消失。网管人员回忆前日维护机器时曾动过该电缆。由此造成连接不良。为使股民能继续交易，稳定情绪，在更换电缆后又将原UPS启动继续工作提供服务。收市后再更换大型UPS，故障彻底排除。
　
   [诊断点评]故障原因有二，一是UPS对电源的净化能力下降，网络外谐波容易从电源系统串入网络系统，为重大故障的发生提供了基础，但只是累积的内谐波超标还不足以引发致命问题。二是接地回路问题，给大量的内谐波串入网络提供了通道。内谐波是指从电源净化设备的输出端比如UPS的输出端测得的谐波功率，由各种用电设备产生(网络设备绝大多数都采用开关电源，本身就是一个较大的谐波源)。本案中，大量的内谐波功率叠加后从卫星接收机数据输出电缆串入交易网络，一方面以幻象干扰的形式侵蚀网络带宽(此时网络测试仪监测到的错误类型即为Ghosts)，当以太网的网络总流量高于80％时，会导致绝大多数的网络瘫痪；另一方面，串入的内谐波将干扰正常数据传输(与正常的卫星广播数据叠加，表现为FCS帧错误和少量长帧)，使卫星接收机接收到的数据出错，显示屏出现大片空白或不能实时更新数据。本故障为累积故障，两个月前因UPS性能下降就开始出现少量干扰超标，不过这没有引起网管人员的足够重视。前天维护设备后又增加了电缆接地回路的干扰问题。但因当时未将卫星接收机连入网络，网管人员仅检查了网络部分的工作状况，所以此时的网络表现肯定是正常的。直到今天临近股市开市，当接通卫星广播数据的输入通道时，问题才爆发出来。此时内谐波干扰信号大举入侵网络，几乎造成网络瘫痪。
   关断集线器组电源，内谐波总功率下降，干扰信号强度减弱，错误率自然有所下降。更换UPS电源后，错误率大幅下降(理论上应降为零)。但因接地回路问题使50Hz电源及其高次谐波感应信号仍能进入网络形成较小数量的错误帧。需要注意的一点是，一般人在更换UPS后看到网络恢复正常工作即认为故障已经排除，因此很容易忽视仪器监测指示仍存在的少量错误(1.3％)，这可能使“接地回路问题”这一重大故障隐患得以长期存在下去。此故障的诊断网管系统基本上无能为力。
　　
   [建议]电源谐波功率含量和网络错误率要定期测试，当发现错误帧时一定不要掉以轻心。另外，一路电源能带动的工作站建议不要超过30台，否则应象划分网段那样重新划定供电区域。以免内谐波功率累积过大，超过设备的容许范围。如果您的网络可靠性要求很高，或者您的网络对您来说非常重要，那么建议您将主要的网络设备如服务器、路由器等，在网络规划设计时就选择由单独的UPS供电。


[案例十四]光纤链路造侵蚀损坏
　
   [症状]周末，要下班了，我正在计划如何安排假期，接某银行来电，报告该行某支行下辖的西区营业部网络瘫痪，营业部所管理的33台ATM取款机也全部不能提供取款服务，用户反响强烈。已经两天了，解决都没有问题，要求网络医院立即派人帮助排除。西区营业部和支行在同一个大院的两幢大楼内，之间用一对90米的光纤将营业部的网络与支行的网络连接起来，路由器、服务器等都设在支行计算中心(100BaseT以太网)。营业部的网络结构为10BaseT以太网，五天前发现网络速度变慢，用户抱怨ATM取款机等待时间太长。由于营业部没有配备任何网络测试和维护的工具，为了定位故障，请支行计算中心的网管人员协助检查。从支行一端的网络监测显示，一切正常。从计算中心打开营业部交换器的Mib，观察流量正常，为5％，发现只有很少量CRC/FCS错误，没有发现严重异常，用协议分析仪捕捉数据包观察，也未发现严重的问题，遂怀疑是病毒侵害营业部子网。昨日夜间进行了查杀病毒，重装系统，恢复数据等工作，症状大大减轻。但未能经受住昨夜暴风雨的考验(本周天气除昨天下午间晴外，连续降雨)，最终于今晨“死网”。
   为便于观察，支行网管人员在计算中心将连接营业部的交换机用集线器暂时取代，结果导致支行网络速度也变慢。检查营业部内的交换数据无障碍，断定是传输通道的问题。拔下光纤，支行速度恢复正常，插上光纤则上述现象重新出现。进一部测试光纤链路，连接和衰减均符合要求。故障排除工作陷于停顿。 
   [诊断过程]据网管人员介绍的上述情况，光纤和交换机已经过了网管人员初步检测，基本正常。可以初步判定问题出在链路通道上。将F683网络测试仪接入营业部交换机，观察网络基本正常。进行通道测试，检测营业部到支行的ICMP Ping测试结果，成功率约0.8％，路由追踪支行服务器，成功率约0.5％。从支行集线器上观察，流量18％，属正常范围，但发现大量“幻象干扰”错误“Gosts”(16％)，拔除光纤，则错误为0％，至此可以肯定错误与营业部网络及其通道有关。将营业部与支行连接的交换机接口串入一个4端口的集线器，用F683网络测试仪观察网络，流量5％，发现大量幻象干扰(97％)，拔除光纤，错误消失。寻找光纤接线箱，发现支行一侧的接线箱外包装已被撞击变形、破损(据说是半年前安装空调时被吊车臂碰坏)，雨水已将3号接头完全浸蚀(3号接头用于连接营业部)。清洁接线箱内的所有光纤接头，用电吹风加热干燥光纤的插头插座，重新更换并密封接线箱，故障彻底消失。 
   [诊断评点]光纤链路经常被忽视。本故障中，光纤接头因雨水侵蚀和污染，从营业部送来的信号被大量反射，此时若只测试光纤链路的物理性能是合格的。但由于此段光纤只有90米，强反射信号经过较少的衰减后与正常信号叠加，破坏了数据的结构(包括数据帧帧头信号格式)，网络测试仪即认为这是幻象干扰信号而不是正常的数据信号。此时只有少数信号可能侥幸通过。由于集线器和交换器不具备前期碰撞的识别能力，所以从网管上只能观察到数据帧后半部分被破坏后所表现出来的少量FCS/CRC类型的错误，此错误往往被人忽视。昨天重装系统后因天气转晴，光纤接头性能有所好转，症状减轻。昨夜暴雨又使网络陷入灾难境地。加上今天测试光纤链路显示正常，致使故障排除陷于停顿，束手无策。 
   [建议]交换器对均衡网络负荷、隔离故障网段对网络的影响有很好的效果，但也因此经常成为网管系统监测中的“黑洞”。用网络测试仪定期监测网络可以将故障消灭在萌芽状态之中。定期测试分很多种，我们将在以后的连载中陆续介绍。本故障如不及时处理，其它光纤接头连接的网络也会陆续出现严重问题。

[案例十五]“水漫金山”，始发现用错光纤接头类型，网络不能联通
　 [症状]某新落成的甲级办公大厦，按智能大厦标准设计，其中的计算机综合布线系统包括用超5类线和多模光纤组成的水平及垂直布线系统。全部电缆系统都经过了严格地选用的超5类线现场认证标准进行的验收测试和检验，现正在一边招商一边调试网络及通信系统。智能控制系统的多数信道均采用IP协议，并将原设计的各自独立的17个分系统的控制平台重新设计和整合为同一个快速100Base-Tx以太网，这样大大压缩了网络系统的造价。今天该大厦工程的布线集成商向网络医院求诊，报告其66层的网络联络中断，无法调通，而以前一直工作正常。故障开始于前天上午，第66层的网络系统用户无法与其它楼层的用户联系，也无法通过大厦的帧中继专线与互联网联接。第66层通过一对200米的多模光纤链路与2楼的网络监控中心联接，经过检查发现设在40层的光缆转接箱内的接头被上层楼面的溢水事故所污染，工程人员临时改变光缆走向，将光缆用一段跳线从另一弱电井中绕道联入，采取这样的措施后只增加了约30米的光缆长度和一个光接头。根据估算应该可以联通。原先被污染的光缆接头也已经更换，但网络仍然无法实现联接。 
   [诊断过程]从故障统计的规律看，一般在网络维护的过程中，维护人员动过或更改过的地方故障出现的概率比较高，此即所谓“动哪儿查哪儿”的故障诊断顺序第一原则。根据报告的故障情况初步判断光缆出问题的可能性比较大，当然也不排除网络设备的问题，比如光卡、交换机等同时出现故障的可能性(今天的检查过程中维护人员也插拔并检查过光卡)。20分钟后，我们抵达目的地，我们将网络测试仪接入2楼网络中心，检查网络工作状态，正常，只是无法发现66楼的用户。电话询问66楼用户，回答说平时虽然能联通，但也不是十分通畅。有时速度会很慢，偶尔还会出现连接中断的现象。我们将电缆测试仪换上多模光纤测试模块，主机移动到66楼，远端机留在2楼对这对光缆链路进行测试。A光缆测试衰减值为3.7dB，B光缆衰减为7.8分贝，虽然B光缆的衰减相当大，但因为还在一般光卡允许的接收灵敏度范围之内，应该不会影响光卡的信号接收，除非光卡正好也有灵敏度方面的问题。为了简化诊断程序，我们用邻近的光卡做替换试验，将2楼和66楼的光卡同时更换，然后从66楼用网络故障一点通(One Touch)接入网络进行测试，结果是可以发现本楼层的用户，但还是无法找到其它楼层的任何用户。这说明故障仍然在光缆链路，或者是交换机的光卡接口有问题。为了确认故障的准确地点，我们从另一弱电井倒换出一对光缆代替这对光缆，并用跳线将原来的光卡连接起来，当光卡插入交换机后网络立即恢复正常。这说明交换机及其光卡和光卡接口是正常的。重点还是要检查这对光缆链路。重新测试的结果与上此测试的结果基本一致，我们将测试方向颠倒一下再度进行测试，结果发现B光缆的衰减量为27dB，A光缆仍然为3.7dB。继续对B光缆进行分段测试，44楼以下的一段光缆测试结果为2.3dB，基本可用。跳线衰减量测试1.28dB，基本可用。44楼和66楼之间的光缆测试衰减为20dB，严重超差。说明这条链路有比较严重的问题。拧下44楼的光卡接头，用放大镜仔细观察，光缆芯线直径圆润，与其它接头并无二至。随后检查66楼光缆接头，发现其芯线直径比其它接头的芯线直径要小许多。可以判定，此接头很可能为单模光缆接头。将这对光纤的接收和发射位置对调使用，插入光卡后网络恢复正常工作。 
   [诊断评点]光缆链路在标准化的认证测试过程中按要求进行双向测试，本大厦的光缆布线系统全都只做了单向测试。当遇有光纤直径不匹配、光纤气泡或接头质量差等情况时，光纤在两个方向上的衰减量会有差异。一般来讲，差异不会超过10％。此次故障的光纤双向测试衰减量差值达20dB，故怀疑光纤直径存在严重的不匹配，且出现在接头处的可能性最大，所以我们对44楼和66楼之间的光卡接头进行检查。结果发现了误用的单模光纤接头。单模光纤的芯线直径为9微米左右，对1310微米和1550微米的单模激光衰减量较小。多模光纤芯线直径为62.5微米左右，在计算机网络中多用于850微米的多模光信号传输。单模光纤链路和多模光纤链路由于传输的光模式、优势波长和衰减机理完全不同，不可以混用。本故障的接头当从正向测试B链路的衰减量时，由于单模光纤一端与多模光纤熔接，不少多模光能量仍可以进入单模光纤，并从接头处的小直径处(单模9微米)全部射入大直径(多模62.5微米)的多模光卡的光接头内，表现为衰减量比正常链路大(实测为7.8dB)，但信号基本可用。当从逆向进行测试时，大直径的多模光能量在接头处被小接头的单模光纤大部分阻断，表现为逆向衰减量很大，实测值为27dB。由于光卡的接收灵敏度较高，衰减余量大，故“水漫金山”事件之前，光卡接收到的信号能量处在光卡灵敏度的边缘，逆向信号勉强可以使用，此时的网络表现不稳定，有时速度很慢，有时偶尔中断(受气温和空气压力的波动影响)。“水漫金山”事件后，由于在重新处理链路时增加了一段30米长的跳线和一个光接头，致使光卡的接收能量超出边缘值，网络连接因此中断。多模光卡都是成对单向使用光纤，即光卡发射用一根光纤，接收用另一根光纤，所以当对调接收和发射的光纤时，光卡接收和发射的信号都利用了单向衰减量小的方向，接收到的光信号能量较强，网络可以恢复正常运行。
   本故障如果利用光时域反射计(OTDR)可以直接从仪器的屏幕上观察到回波曲线的不连续状态，有经验的测试者一般可以立即判定是链路混用的问题。 
   [诊断建议]首先，尽快更换误用的单模接头。第二，根据标准化施工施工和验收要求对所有光纤链路都要进行双向测试。第三，我们发现该大厦的设计图纸上无光纤链路的衰减量计算值标注，只标注了光纤的设计长度。由于实测的光纤衰减量无论是表现正常的链路或是不正常的链路其结果都比设计值偏高，估计存在使用劣质光纤和劣质接头的情况，且不排除用多段零碎光纤拼接链路的可能性。所以建议业主要求集成商检查所有实际的接头和熔接头数量。 
   [后记]五天后用户来电报告：他们测试了大部分的光缆链路，实际测试的光纤衰减值(扣除接头损耗后)基本符合标准，没有发现零碎拼接的情况。但所用的连接器和接头则绝大部分都不符合标准要求，为伪劣产品。好在接头的更换比较容易，不至于严重影响已有网络用户使用，损失也相对较小，计划全部更换之。

[案例十六]千兆网升级工程，主服务器不可用，自制跳线RL参数不合格
　
   [症状]某知名的大型电信产品开发商，最近对网络进行了升级，其负责通信及计算机网络的IT经理Grace小姐今天向网络医院报告，有数台新安装的服务器基本不能用，其它服务器也偶尔存在数据出错和访问速度停顿的问题，有的明显，有的则不太明显。在网络用户少时，对服务器进行Ping测试一般都能通过，但用户数量稍微增加时则有10％～30％的Ping测试损失。这几台服务器即使在用户数量很少时，也不能很好地登录和访问。奇怪的是，登录过程有时候很顺利，有时候则根本无法登录，等待时间最高能达到5分钟，方能进入。骨干网原计划用ATM架构，后更改设计为千兆以太网交换机作骨干交换机。公司总部所在大厦内的用户近3000个，楼高28层，每层用一台千兆以太网交换机作为核心交换机，下面则只设一级100兆工作组交换机，然后直接100兆交换到桌面。服务器安装的都是千兆以太网卡，直接与各层分布的千兆以太网交换机相连。网络维护人员对服务器工作平台进行了多次彻底地检查，并重新安装了工作平台，但现象依旧。经人指点，曾经怀疑是电缆问题，遂对相关的服务器连接电缆全部用Fluke公司的DSP100电缆测试仪进行了测试，结果都合格。试着更换部分电缆，无效。观察这几台服务器，多数时候访问流量不足1％。不知道何故？ 
   [诊断过程]服务器访问受阻，而且是同时有几台受阻，这其中的故障原因必定有某些共性存在。Grace告知，本次新安装的服务器共有17台，其中7台有明显问题，另10台大致正常。负责安装的是同一个人，由公司资深网络工程师潘先生直接执行，应该不存在由于安装上的差异而导致部分可用部分不可用的问题。我们将网络测试仪接入用户端对网络工作状态进行初步了解。观察有明显连接问题的7台服务器与交换机的连接端口，发现流量均低于1％，但延迟数据包的比例很高，占86％～93％左右，错误的FCS帧比例也不低，约为5％～11％左右。这说明确实有大量的数据包指向了服务器而服务器却没有理会。另外的5％～11％的FCS错误数据包则可能来自服务器。对准服务器做ICMP Ping测试，损失约为90％～100％之间。以上故障提示电缆问题和电缆与服务器、交换机的接口物理性能有问题。用DSP-4000电缆分析仪测试服务器与交换机之间的硬跳线，7台有问题的服务器均显示回波损耗RL(Return Loss)参数不合格！继续测试另10台服务器与交换机的跳线，其回波损耗RL参数也全部不合格！用电缆分析仪定位的RL不合格点就在跳线电缆的端头处。故重新制作接头并测试，仍不合格。换用我们随身携带的软跳线接入一台服务器，服务器工作立刻恢复正常。看来确实是跳线电缆的问题。用我们提供的合格接头重新制作一段跳线，测试还是不合格。由此可知，问题出在跳线材料上。我们将随身携带的仅有的4根软跳线接入其中4台服务器中，这4台服务器全部恢复正常。用DSP4000选择五类线测试标准对电缆进行测试，全部合格。查看电缆外包皮则为Cat5e。 
   [诊断评点]我们知道，电缆内有4对双绞线，在千兆以太网链路中，由于采用是4对线全双工5电平编码工作方式，每对负担250Mbps的双向数据流量，实际的信号等效物理带宽为100MHz，也就是说，五类线就基本可以满足千兆以太网的链路要求。实际使用当中则不然，千兆以太网对其它参数的要求更高，故一般建议使用超五类线承载千兆以太网应用。五类线则一般限于100兆以太网和ATM155等以内的速率应用。如果打算用五类线运行千兆以太网，则必须增加几项测试参数。Grace介绍他们采用的是超五类电缆，但经过DSP4000电缆分析仪实地认证测试证明只是五类电缆而已，也就是说Grace采用的是用五类线仿冒的超五类线。改用Cat5n标准测试，仍然不合格。这表明他们选用的五类线芯的品质本身也比较差，不能通过五类线的千兆应用标准Cat5n测试。这是因为，正规厂商提供的五类线在增加的千兆应用Cat5n标准测试中，不合格的产品比例一般都不会超过20％。DSP100电缆测试仪只能测试五类线，所以测试结果全部合格。但工程设计采用的是超五类线，所以该仿冒的超五类线经DSP4000电缆分析仪测试被判为不合格。4台不合格的跳线，长度均在2米以内，而另10台工作不良的服务器，与交换机的连接长度均在15米以上。这也是回波损耗RL不合格的典型表现：即在RL不合格的链路中，电缆越短故障症状越严重。这是因为，RL不合格将会导致信号反射增加，短链路的衰减量小，所以，反射的能量大多数会在链路的另一段在此反射从而叠加到中常的数据信号之中，造成信号的大量畸变，反映为错误的FCS帧，另一方面，访问服务器的流量由于无法正常传递到服务器，反映到交换机则是大量的延迟帧累积。在较长的不合格RL链路中，由于信号的衰减较大，多数反射能量不能有效地叠加到正常信号之上，所以故障症状会轻一些，表现为错误较高或间歇性的停顿，尤其是流量高时错误帧较高，停顿频繁，但一般不会全部数据包都通不过链路。用户登录网络时受当时的平均流量和瞬间流量影响都很大，表现为登录时间的大幅度摆动，有时会比较顺利，因为此时的瞬间流量和平均流量都低，有时则表现为长时间等待，此时的平均流量或瞬间流量高，错误操作和重复操作大量出现。 
   [诊断建议]鉴于Grace采用的电缆为仿冒的超五类线，加之其它服务器也偶尔有数据错误和停顿的表现，故建议她将所有的服务器超五类链路重新进行检查，以确保网络的工作质量。 
   [后记]第二天Grace电话告知，他们当天共抽测了包括全部服务器链路在内的200条链路，其中工程前期敷设的电缆基本上合格，后期敷设的电缆都不合格。后期的电缆数量约站40％，显然是工程施工中出了问题。他们将在近期内将链路全部测试一遍，以便确定到底有多少链路存在品质问题。粗略估计，重新返工敷设这些电缆至少也要耗费200万以上。


[案例十七]用错链路器件，超五类线系统工程验收，合格率仅76％
　
   [症状]某著名系统集成商今天来电反映严重质量问题，其主代理的某更加著名的电缆生产商的超五类电缆产品用于一项15000点的样板工程，布线系统每条电缆链路已经经过严格的现场认证测试，全部合格。正准备安排工程款结算，但一周前业主突然提出，工程商的现场认证测试报告有问题，工程款项暂停给付。理由是：测试报告上的电缆标准与选用的电缆类型不一致。集成商重新查验了工程商的全部测试报告，认为参数没有问题。测试报告上选用的是北美五类线测试标准。业主认为必须选用相应的超五类线标准进行认证测试，才算有效。集成商遂责成工程商重新选用超五类线标准进行现场认证测试，结果约有9％的链路不合格，15％的参数告警。该工程由集成商总包，布线工程由另一家工程商负责施工。 
   [诊断过程]我们应邀立即赶往现场，随机抽取了100条链路进行测试，结果与工程商重新测试的结果基本一致，这应该是一起严重的质量事件。从抽测的参数结果统计分析，基本上是综合近端串扰PSNEXT、综合衰减串扰比PSACR和回波损耗RL三项参数不合格，最大超差分别是-1.5dB、-1.0dB和-2.8dB，占9%，15％的参数在标准规定的边沿附近波动。由于波动范围在仪器的误差限以内，所以测试参数显示为告警。启动DSP-4000电缆分析仪的自动诊断功能，仪器显示“故障”点在被测试链路的接头位置，即水平电缆的两端。仪器提示“检查接头或更换接头”。用随身携带的超五类接头/座更换之，重新测试仪器显示“PASS”。用工程商提供的连接模块连续更换了三条不合格的链路接头，然后进行验证测试，结果三条链路有两条不合格，而其中一条由原来的不合格转为合格。这说明，工程商选用的超五类电缆并未配用超五类连接模块，而是五类模块。工程商提供的数据是，电缆全部采用超五类线，接头“可能”采用的是五类线，准确信息不明。 
   [诊断评点]一般来讲，标准规定的五类线现场测试标准应该用在五类线系统的认证测试中而不能用于超五类布线系统中。许多工程商在进行超五类线工程认证测试是都选用五类线认证测试标准，理由之一是：超五类线国际标准在工程施工时还未出台，只有部分草案和建议，而厂商声称其产品的实际参数均超过即将出台的超五类线标准，所以只要不是施工工艺上的明显问题，链路参数都会合格；理由之二是：实际执行的测试程序在一段时间内大多数工程商都是事实上选用五类系统现场认证测试标准进行测试。因此本工程在上述背景下也无例外地选用了五类线标准进行现场认证测试。在与用户签订的验收测试程序中不指明使用何种具体标准进行现场认证测试。本项工程结束后，用户在验收全部合格后才“偶然”发现检测报告的标准是北美五类线标准，与选用的超五类线的电缆系统不相符，遂提出异议，并要求工程商按超五类线标准进行验收测试。我们知道，北美超五类线现场认证测试标准是二零零零年一月二十七日正式发布的，而工程是在此之前开工的，因此工程商仍决定使用北美五类线标准进行验收测试，检测结果当然100％合格。如果工程商在电缆系统中全部采用标准的超五类线元件，即电缆、接插模块均选用合格的超五类产品，则当用户要求重新测试时，测试结果合格率应该还是会接近100％。遗憾的是，工程商对超五类线系统的理解出现偏差，在选用的超五类线链路中有意无意地使用的是五类连接模块，因此当业主提出按超五类线标准重新进行现场认证测试时约有24％的链路出现问题。
   为什么不是100％的链路出现问题呢？这是因为，“五类线连接模块”＋“超五类线”构成的链路原理上应该比“纯五类线系统”稍好些，加上五类模块在设计和生产上参数留有一定余量，所以本工程仍然有76％的链路通过了超五类线标准的现场认证测试。9％的链路实在无法达到链路参数要求，15％的链路参数在“边沿”灰色区域。
[诊断建议]我们不去追究究竟是何种原因使得工程商选用了五类连接模块进行工程安装而不是按照设计规范选用超五类连接模块进行施工。从现场测试的结果来看，由此造成的返工将是不可避免的了。好在该电缆系统使用的电缆是合格的超五类线产品，返工涉及到的部分一般仅限于水平电缆两端的连接器件。
   建议集成商责成工程商将全部五类线模块更换为合格的超五类模块，即便是先前测试合格的76％链路和处在边沿附近的15％也要更换，这样才能确保该超五类线电缆系统在相当长的时间内保持合格水平(比如十五年质保期内)。 
   [后记]三周后集成商来电告知，所有模块全部更换并按北美超五类线现场认证测试标准进行了验收，全部合格，还算是个圆满的结果。不过，集成商因此而付出的代价也不菲：不算更换模块造成的损失，光支付业主索赔款就有12万(平均每条链路8元)。
[案例十八]六类线作跳线，打线错误造成100M链路高额碰撞，速度缓慢，验收余量达不到合同规定的40％
　
   [症状]周末，某著名系统集成商今日“报案”，他们为一家银行集成的新大楼在进行网络验收时达不到合同要求的40％余量指标，经多方检查仍原因不明。整个系统采用超五类线布线，系统的其它问题都已全部解决，只剩下服务器验收这一项，报告说明全部不合格。下周三就是工程验收最后期限，如果不能在周二以前解决问题，将影响用户的实际使用。集成商的声誉也将受到不利影响。集成商负责系统集成总包，布线工程由另一家信誉良好的专业布线工程商承担，布线系统全部经过超五类线现场认证测试。集成商负责网络的验收测试系统平台的开通测试。网络验收测试中的一项测试内容是通道性能测试，对包括服务器在内的关键设备进行联通性和通道能力测试。合同要求服务器留出40％的可用余量，测试方法是对服务器加上60％背景流量，然后进行联通速度测试，Ping测试在整个网段内小于2ms为优，下载20M字节的文件小于10秒为优。实际测试时Ping测试值为5ms，60％流量背景时下载速度为80秒。主观感觉服务器访问速度缓慢，原因不明。若将背景流量降为15％，测试结果则能达到要求的参数值。要求网络医院帮助查找原因。
　
   [诊断过程]服务器通道测试速度慢的原因有很多，象网络设置错误，网卡驱动程序版本不匹配，网卡协议邦定不良或有冲突，网络设备如网关、桥、交换机、路由器等设置错误或不良，链路故障或次生垃圾过多，干扰信号进入系统，系统平台设置有误，开发的应用系统程序设计优化度差，平台和终端设备不协调/匹配，服务器和网络的协议不匹配等等等等，我们需要确定具体的故障原因。一般来说，定位故障可以先从联通性和协议匹配性入手比较简单和快速。从工程人员哪里了解到，平台已经安装了三遍，网络设置和网卡驱动程序也调整过多次，鉴于网络Ping测试可以通过，因此他们倾向于故障存在于服务器与网络协议的匹配性不良。我们将网络测试仪接入网络，重复上述测试内容，证明其先前的测试数据基本属实。问题是几乎所有的服务器都出现类似的问题，所以我们必须查找与此相关的公共参数。首先，将服务器从网络上摘下，抽查14台服务中的任意4台，将网络测试仪串入链路进行“专家级”测试，检测服务器与网络的连接关系和性能。先对其网卡接口用网络测试仪的NIC测试功能进行测试，全部显示正常，然后观察网络的工作参数和工作协议，全部正常。这表明网络和服务器的网络设置、协议设置、物理工作参数、协议匹配性等是基本合格的。但因此时的网络流量是比较低(1%)，许多网络性能方面的问题都是在流量比较高的条件下才暴露出来。所以，采用如下方法选中任意一条服务器链路进行测试：用“网络测试仪”在离服务器最近的交换机端口上对被监测的服务器模拟发送流量，用网络故障一点通或网络万用表监测通道数据。当模拟链路流量曾家至3％时，被选中的链路碰撞指标开始超过5％健康底线，当流量曾至40％，碰撞率达到98％，流量60％时，碰撞率99.8％。很显然，网络的链路性能存在较大问题，对另外4条链路进行同样的测试，结果类似。在交换机紧邻的接口直接对网络故障一点通做上述类似测试，显示正常。这说明链路存在严重问题的可能性极大。与网络设备设置关系不大。询问工程人员，声称布线系统经过了严格的超五类线测试，布线工程商并信誓旦旦地保证链路不会有问题。查看布线系统认证测试报告，BasicLink超五类线认证测试全部通过。服务器是由服务器供应商指定的分销商负责安装调试的，他们当时也在场，自称安装过上百台服务器，也从来没有出现过类似问题。各方似乎都有道理，但链路存在问题是很显然的，所以我们决定对链路重新进行现场认证测试。测试刚才抽查过的链路，结果是全部都不合格，电缆测试仪提示“打线错误”。且电缆测试仪的HDTDX分析功能启动后定位出近端串扰在整个链路的远端约2～3米长的线段内超差。为分清责任，改对BasicLink测试，水平电缆测试全部通过，这说明布线工程商的施工参数确实是合格的，问题很可能出在服务器安装服务商身上。试着更换服务器链路跳线，故障现象立即消失。随即对全部服务器跳线进行更换，之后对网络重新进行验证测试，参数全部通过。
　
   [诊断评点]故障是由服务器连接跳线打线错误造成的，我们知道，打线标准中规定了568A和568B两种格式，这两种格式原理上是完全等效的，区别仅在线序不同而已。常见的打线错误是被称作“串绕”的一种，特点是将线序按1-2、3-4、5-6、7-8的自然顺序排列。这样将会造成近端串扰严重超标，一般来说会令服务器无法与网络实现100Mbps的网络连接。本案中由于跳线的线序错误按理应该导致服务器不能上网，但实际的情况确是服务器能上网，只不过碰撞率严重超标而已。由此看来其中必有蹊跷。我们专门对服务器安装商提供的电缆进行测试，近端串扰超差，重新打线后再测试，通过近端串扰参数的富余量很高。遂怀疑服务器跳线是用六类线制作的，查看电缆标记，确实是朗讯的六类线产品。改用六类线标准专门设计一条六类线BasicLink基本链路进行三接点(串入被测跳线)验证测试，不通过。电缆测试仪故障信息屏幕提示接头不合格，为六类以下器件。重新进行通道性能测试，加载60％Ping测试小于1ms，20M字节文件拷贝8秒以内全部服务器链路都能完成。
　
   [诊断建议]服务器安装商误用朗讯的六类线来制作超五类线跳线，使得原本根本不能上网的服务器能够勉强上网，并同时造成其它参数健康指标不合格。一般来讲，采用六类线制作的跳线其性能会优于五类线。所以建议用户可以保留六类线制作的超五类链路跳线，只需将打线顺序改正即可。
　
   [后记]下周二集成商来电告知，他们最终没有保留原服务器跳线，而是全部更换合格的超五类跳线。集成商由于没有自备电缆测试仪才造成如此被动，为此他们于今天专门配备了一整套布线系统认证测试工具和网络验收测试工具，希望能从此无忧少忧，并且希望能更好地进行网络的性能测试和维护，帮助快速方便地进行网络的验收测试。

[案例十九]六类线工艺要求高，一次验收合格率仅80％
　
   [症状]某著名布线工程商及系统集成商，采用六类线为某市新建的电信大厦布线，点数虽然不多，只有共1,800点，很快就完工，但在验收测试时遇到一些小麻烦：合格率一次性测试通过值只有80％，其余的20％近360条链路不合格。布线商采用的都是某电缆生产商的正规产品，包括全套的电缆和连接模块，其质量在施工前进行过验收，抽查过其中三卷产品，均合格。承担施工的队伍也是有近四年工程经验的下属布线工程公司，曾经有10万条链路的成功施工经验。此次工程项目为第一个六类线试点工程，对公司的布线施工队伍也是一次考验，结果却不尽人意。如果360条链路全部返工，计算下来也是一笔不小的损失。因此公司决定先对剩余的六类线再行进行抽查，以确定是否是产品的问题；然后再安排如何更换或修复这些不合格链路。
   抽测结果如下，抽测的10卷产品，每卷产品截下90米，按90米六类线“Basic Link”基本链路连接后进行现场认证测试，结果有7卷产品不合格。由于该工程商同时也是厂商的产品代理尚，厂商的销售代表也无法解释测试结果。接着再进行了第二次抽查，结果10卷产品的90米模拟链路仍有6卷不合格，遂请“网络医院”帮助确认原因。 
   [诊断过程]到达现场后计划部分测试不合格的链路，共抽测了20条，结果全部不合格。打开电缆测试仪DSP4000中保存的参数，查看主要不合格的参数有回波损耗“RL”，“PSACR”综合衰减串绕比等，比例占80％，其次是“PSELFEXT”综合等效远端串扰、“PSNEXT”综合近端串扰等。对工程商原来抽测过的链路进行复检，结果与上述结果基本一致。仅靠生产商提供的产品证明和合格证书似乎已不足以证明其产品是否满足工程施工现场认证测试的要求。为了确认是否是厂家电缆产品和接插件、连接模块等本身的问题，我们建议布线工程商将他们代理的另外一家电缆生产商供应的产品拿来与本项工程采用的电缆进行对比。对比方法如下：同样制作10条链路，测试条件与上述抽查时的测试条件相同，然后统计测试结果，与前面的测试结果进行对比，以便验证是否是产品本身的问题。一小时后，工程商依此建议制作了两组共20条用另外两家电缆生产商提供的电缆产品“加工”成的90米基本链路，每家10条链路。我们分别对这些链路进行测试，结果如下：链路合格率为A产品80％，B产品70％；且各有20％合格的参数比较靠近测试标准的边缘，一般只有0.5~1.3左右的参数富余量。
   由此看来，各电缆生产商提供的产品都有相近的合格率，这岂不等于说各电缆生产商提供的产品都有问题？根据逻辑分析只能有以下几种可能：一是产品质量确实有问题，但有问题的比例为何如此一致呢？似乎可能性不大；二是测试仪器或测试环境有问题，比如仪器误差偏差或损坏，测试环境有大量电磁干扰源或干扰信号，但施工现场和试验测试地相距达400米，电磁环境相异甚多，且周围没有其它使用特殊电磁设备的邻居和大型用电设备、强功率辐射源等，这条原因似乎也不象；三是施工方法、施工工具和测试的方法有问题，但工程商承担施工人员的都是有至少一年施工经历的员工，且为试验链路打线的人员已经为该公司工作了两年半，技术上应该没有问题。打线工具经过目测检验没有问题，并且工程施工中的打线工具不是刚才试验链路制作时的同一个工具。
   我们暂时假定产品没有问题，采用另一台自身携带的DSP4000电缆测试仪和工程商自备的同一型号的电缆测试仪进行对比测试，各测试结果一致性相当好，说明测试仪没有问题。为了定位故障位置，使用DSP4000电缆测试仪中的“HDTDX”高精度时域串扰分析功能和“HDTDR”高精度时域反射分析功能进行故障图谱分析，结果发现不合格参数的“突出位置”都在接插件和连接模块的位置，这说明要么接插件和连接模块有质量问题，要么就是施工工艺存在问题。接下来将不合格链路中的接插件和连接模块重新更换一遍以后进行测试，结果三家产品各自10条链路中有一家全部合格，两家只有一条不合格。将不合格的链路再“回炉”一次，进行第三次测试，结果全部通过测试。对20％参数靠近边沿的链路认真“回炉”进行测试，结果全部合格。这说明，接插件和连接模块的施工工艺可能是链路认证测试不合格的重要原因。下一步，为了验证是否是电磁干扰等可能原因，回到工程现场，选取20条原来测试不合格的链路也如法炮制，重新“回炉”，将接插件和连接模块重新“认认真真”制作一遍，结果一次重新测试就全部通过！！ 
   [诊断评点]综合布线的施工工艺看似简单实则要求不低。在三类线的施工过程中，大量的布线商采用临时性的施工人员，经过两小时培训后就上岗工作，工程验收合格率仍比较高。在五类线和超五类的施工过程中，工艺问题开始被工程商重视，但一般不足以形成如此大面积高达20％的链路不合格的严重后果。而在六类线的施工过程中，施工工艺问题被推到了非常重要的位置，在打线和安装时稍有不慎就会使整条链路认证测试不合格，这是工程商始料不及的。其实，诊断具体的故障位置方法很简单，使用电缆测试仪的高精度时域串扰分析技术“HDTDX”和高精度时域反射分析技术“HDTDR”两项故障诊断功能就可以非常方便地显示出故障的实际位置。施工人员可以据此立即采取修复措施，而不会等到认证测试和验收时“去丢人现眼”“出洋相”了。六类电缆频带由100MHz增加到250MHz，对特性阻抗机器连续性的要求提高了很多，另外对近端串扰、等效远端串扰、衰减串绕比等参数的要求随着频率增加的平方数成正比。上述参数的Power Sum (功率和)参数也被提高到非常严格的程度，表现在施工工艺中比较突出问题就是接插件和连接模块的制作工艺对整条链路的影响变得非常突出。所以严格的施工工艺要求需要引起布线工程商的高度重视，只有这样才能避免造成影响工期的大面积返工和资源的浪费。否则，一次性验收测试一般会停留在80％左右。 
   [诊断建议]将不合格的360条链路重新严格制作一遍，并对参数靠近边沿2dB以内的的360条链路也采取同样改进措施，以确保工程品质。另外，施工队伍的严格培训和强调施工工艺的严格性也必须认真对待之。 
   [后记]一周后，工程商告知，经过“回炉”后，1800个链路全部验收合格。除了重新处理不合格的360条链路外，对边沿值的360条链路也进行了重新制作，参数测试富余量全部都在2dB以上，他们准备把这项工程作为该公司的样板工程。

[案例二十] 服务器网卡损坏引起广播风暴 
   [症状]今天是周末，某银行向医院求助，其西城区整个网络瘫痪，与电脑中心的联络基本中断，只偶尔有部分交易能达成，但速度很慢，不知何故。由于电脑中心的网管系统也陷于瘫痪状态，无法观察任何网上设备的情况。 
   [诊断过程]从火车站匆忙告别家人和朋友直奔该行电脑中心，途中与中心主任继续联络了解情况。系统故障是凌晨4:30左右出现的(约4小时前)，值班员当时发现网管系统有报警信号，20秒钟后网管机就基本上处于死机状态了，想进一步了解故障，遂将系统重新启动过三次，每次网管机都在20秒钟左右失效，而主服务器和网管机脱机自检均正常。
   询问各营业所网络内部工作情况，回答正常，只是交易动作无法实现。可以基本断定故障就在中心的计算机系统中。中心除了配置有HP公司的网管软件OpenView外，没有再配备其它任何网络维护工具。所以一旦网管系统不能正常工作，运行维护人员也就无从下手。东城区和西城区的网络主服务器分别在两个不同的网段中，之间用交换器连接起来。全城结算主机与东城区主服务器在同一网段。用F683网络测试仪接入东城区正常工作的网段观察，发现Cisco5500交换机的Plot3Port4(第3插槽的第4端口)有异常流量，而该端口连接的正是西城区主服务器和网管系统所在的网段。为更仔细地观察此网段的工作情况，将F683网络测试仪和协议诊断器PI接入该网段，测得网络持续流量为97％，其中错误帧占98％。错误类型为短帧40％，帧常50～60字节不等，长帧58％，帧长3000～5200字节不等，并报告了出错机器的Mac地址。依此地址查找对应的机器，遗憾的是该电脑中心没有Mac地址备份表(只有IP地址和符号名对应表)。试着用ICMP的Ping查找网管机和服务器，显示Mac地址对应的是服务器的IP地址。重装服务器网卡驱动程序，无效，用F683测试服务器端口，协议显示Unknown，更换服务器网卡，重装驱动程序并设置响应参数，重启系统即恢复正常。 
   [诊断评点]服务器网卡已经损坏，发出的数据帧错误率为98％，只有不足1％的数据正常。所以网络偶尔还有交易可以达成。我们知道，超长帧有封闭网络的作用，主要是引起网络速度变慢或网络瘫痪，而短帧达到一定流量则会对网络设备的工作协议造成一定程度的破坏，引起设备死机(实际测试中发现工作站对此更敏感些)。网管机上网时在收到高错误流量帧后约20秒钟即被破坏死机，无法观测参数。
   许多设备在自检时只检查部分参数(有些参数尤其是某些物理参数无法仅靠自检来测试)，此案例中网管机和主服务器自检表现正常，而实际上主服务器的网卡物理功能已经失效，但在自检时与操作系统的通信协议能正常工作，靠1％左右的正常帧可以维持极低的网络活性。其它网站会在高流量错误帧的“轰炸”中陆续丧生。 
   [诊断建议]交换机用来隔离网段和网络故障有较好的作用，主服务器、网管机等重要网络设备应以独享交换机端口为佳，不宜再用共享式集线器连接上其它设备，这样可以迅速孤立出故障设备，减少因网络停运造成的损失。如果恰好遇到交换器故障，那么根据网络拓扑结构图就可以迅速定位交换机的问题，提高维护工作的时效性。另外，Mac地址是文档备案的最重要内容之一，除了用于排除网络设备故障有极大方便外，对于迅速查找我们称之为“恶意用户”的非合法上网成员也有很大帮助。


[案例二十一]交换机软故障：电路板接触不良 
   [症状]今天的“病人”是某大型证券公司，在全市有近11个营业网络。以下是该公司信息中心工程师对故障现象的描述：一段时间以来，整个网络交易时常中断，有时一天内会出现2～3次。起初每次持续的时间很短，没有引起我们的足够重视；我们做过简单的测试，约几秒钟至十几秒钟不等，规律性不太明显，一般开市时都正常。随后一段时间“病情”不断加重，发病频率不断增加。好几个“资深”用户曾向老总抱怨，近来碰到几次原本估计十拿九稳的网上交易不能及时成交：“当我按下交易确认键时，计算机对此却没有任何响应，也不知道成交了没有，只好再等上一会儿。我给伙伴们介绍的绝招是，过半分钟再试，计算机就会显示成交。不是每次都这样灵光，但以前极少遇到这种事，而最近一周已经遇到好几次了，好象一天比一天厉害，搞得我们的神经紧张兮兮的。”昨天15:26，临近下午闭市时，故障现象再次出现：行情数据的显示和更新都正常，就是普遍不响应交易命令(但不是绝对不响应，其中仍有少数交易能成交)，11个子交易网络均反映受阻。网管人员初步判断是中心网络的问题，立即在电脑科计算中心检查交易服务器，CPU利用率、协议交换及包交换等指示正常，试验重新登录服务器和Ping测试也正常。时间到，转为休市状态。休市后保持交易网络继续运行，启动模拟交易功能模块，进入故障诊断作业程序。在计算中心LAN内连续作了40笔模拟交易均成功。同时在3个子交易网处作对内和对外的模拟交易，对内100％，对外成功率约15％左右。基本上可以肯定故障在网络本身。保持模拟交易连续工作状态，启用计算中心的网管系统查看网络，服务器工作状况指示正常。检查与其它11个营业网络的联系的交换器端口，有流量指示，但时有停顿。对其作Ping测试，偶尔会有中断(约有3％Ping测试不响应)。用DSP-100电缆分析仪检查与交换机连接的端口电缆链路(服务器、网管机均在此网段内)，没有问题。这说明服务器所在网段是正常的，怀疑是交换机端口损坏。将与服务器网段的电缆改插在别的交换器端口并作相应设置，网络恢复正常工作，故障消失，确认为交换机端口损坏，心想总算可以松一口气了。不料，今日开市后不久故障依旧如期“光临”。 
   [诊断过程]晚上19:50我们赶到该证券公司所在地，立即启动系统，自检显示正常。然后启动模拟交易系统，观察与子交易网络的通信情况，表现正常。网络拓扑图上显示各子交易网络是用DDN专线通过路由器与计算中心本地网段的交换器联系起来。打开各Router的工作表Mib检查，无异常和错误记录。逐个检查交换机各端口工作表Mib，亦无异常和错误记录。交易服务器和网管机同在一个网段，通过一个智能型集线器连接到交换机端口。打开集线器工作表，记录数据正常。将F683网络测试仪接入集线器端口进行连续监测。同时启动测试仪流量发送功能，抽查3个子网的通道性能，并做体能测试，持续流量承受能力为98％，说明网络很正常且表现相当优秀。
   本故障属于软故障。可以由网络设备、应用软件、供电设备、外来干扰等故障引起。由于故障时检查过本地网络，登录服务器和进行Ping测试也是正常的，所以可基本判定集线器下挂网段是正常的。为了定位网络故障，在某个选定的远端子交易网络处和网管中心同时用F683网络测试仪双向发送流量作通道性能测试和故障监测，并作ICMP Ping连续测试和ICMP监测。为便于观察和比较，流量发送的帧长都设定为100字节，流量总和约30％(各占15％约10K左右)。
   在21:30故障如期出现。ICMP Ping测试出现断层，立即打开交换机和路由器的工作表，记录的流量等数据出现停顿或断续，并显示出现FCS帧错误。从远端打开相应工作表的结果是：路由器接转流量为17％，交换机接转流量为2％，ICMP Ping断层损失90％。ICMP监测显示不可达97％左右。从中心打开路由器和交换机工作表Mibs，接转流量均为0.5％~0.9％。这表明远端数据可以顺利到达路由器但不能在交换机端口顺利进行交换。最后用F43电源谐波测试仪测试UPS电源参数，验证UPS电源合格。可以判定确实是交换机的问题。由于网管中心没有备用的交换机，已知原交换机供应商已经停产该型号产品，所以只能考虑更换新型交换机。为了应付明天开市，试着确定一个好的代用端口，这样可以将服务器网段临时连接入网，防止明日开市遇到不测事件发生。查看交换机与路由器一侧的连接端口，发现工作表是正常的。因此只需要代换与服务器连接的端口即可，询问网管工程师上次故障时曾经更换过的是那个端口，答曰第4插槽上的空闲端口都试过。改用第5插槽上仅剩下的一个端口试验连接，网络恢复正常。由于故障时隐时现，故怀疑第4插槽存在软故障。重新将端口还原为第4插槽，故障已经消失。为重复故障现象，试着用改锥木柄敲击第4插槽，故障出现，再次连续敲击，则故障时隐时现。取下第4插槽的电路板观察，发现插针有较厚的氧化层(黑色氧化物)。用0000#细砂纸打磨插针并用酒精清洗，重新安装好电路板，故障彻底消除，并且不再随着敲击电路板而时隐时现。为保险起见，顺便检查其它7个插槽的电路板，插针均没有黑色氧化痕迹，证明只有4号插槽的插针在生产时使用了一组不合格的接插元件。交换机应属于不合格产品。暂时确定用第5号插槽的空余端口作代用端口，并要求网络不停机持续运行直到第二天休市为止，进行连续观察。

   [诊断评点]网络故障分硬件故障和软件故障，有时是软硬件相结合的故障。某些情况下从网络表现出的故障现象不能立即确定是那一类故障。本故障是由硬件设备接触不良引起的故障，原因是计算中心用作分隔网段的交换机其第4插槽的插针接触不良，使得与交换机第4插槽有关的接口工作都不太正常，出现断续和停顿。设备在刚启动的一段时间内，机器的元器件温度较低，工作正常，随着元器件温度的升高，器件受热膨胀，出现接触不良的故障，所以每天开市后的一段时间网络一般都不出问题。多次重复这一过程故障现象就会由较低频率的时隐时现转为较高频率的时隐时现，故障每此持续时间也会延长，最终可能会演变为持续的硬故障现象(硬故障在故障诊断时反而容易些！)。当网络维护人员作停机检查并更换端口后由于元器件温度降低的关系，网络也会正常工作一段时间。这往往给人一种错觉，以为故障排除了，但第二天开市一段时间后故障又会重新出现。
   由于本故障的故障点在交换机向中心网络的一侧，所以从计算中心不能准确地观察路由器和交换机的工作情况，这样要从网管系统一侧判断故障是很有困难的。若改由从路由器的另一侧对路由器和交换机的工作状况进行实时监测，就会发现流量不均衡的故障现象，加上ICMP Ping测试的损失率为90％以及ICMP监测结果，定位故障就很容易了。由此确定是交换机的问题。时隐时现的故障我们称作软故障(注意，不是软件故障的含义)，可以由软件故障引起，也可以是硬件故障引起，是难度比较高的一类故障。这除了需要网络维护和管理人员具备一定的软硬件故障诊断知识外，对诊断经验的积累也有一定的要求。目前，多数的网络维护和管理人员是由计算机专业的人员来担任，对硬件设备的诊断还比较地不熟悉。 
   [诊断建议]如何选择合适的检测工具对故障监测点进行测试是很有讲究的。许多故障需要进行多点测试才能定位，这时非常需要的是便携式的测试工具。网络故障的诊断发展方向是测试工具的网络化和故障诊断的网络化。一般的网络设备和网上设备只支持有限的网管功能，所以监测网络性能和快速定位网络故障需要一些必要的固定测试工具(如固定探头、网管系统等)和移动测试工具(如网络测试仪、流量分析仪等)。对重要的网络设备要准备适当的备用设备，至少要留足备用通道。网络关键设备不一定要选用最昂贵和功能最齐全的设备，但一定要选用应用比较成熟，可靠性高、用户数量大的设备，这样技术支持的难度就会降低。如果将关键网络设备的维护工作交给集成商或厂商来做，那用户就得准备将网络的命运完全交给集成商或厂商来控制，而这是非常危险的。因此对人员进行适当的培训并配备合适的、易懂易用的工具是做好网络维护工作的必要条件之一。尤其对占维护队伍总数90％以上的初级和中级网络维护技术人员和工程人员，这一点更具有实际意义，因为操作复杂、参数难懂难记、培训时间长、价格昂贵的工具对他们来说是豪无实际意义的。 
   [后记]以后连续几天工作都正常，新购回的交换机上网试验调通后即投入了使用。原来的交换机被该计算中心作为了备份设备。

[案例二十二]防火墙设置错误，合法用户进入受限
　
   [症状]今天的“病人”是某市社会保险局，昨天下午全局工作人员加班，配合网络管理部门于18:30安装好了一套新的防火墙系统，重新启动整个保险网络系统，反应良好，防火墙工作也很正常。但好景不长，今天上班时，许多Intranet内部有权用户就打电话反映在查询和操作保险资料时出现无法进行数据调用和修改的故障现象，此时屏幕提示登录者为“非法用户”；系统管理员同时还发现只有从防火墙处可以访问网络并修改数据。同时，一个有趣的现象却是，Internet外部普通用户在查询各种用户资料时却没有问题，他们无论从何处都可以顺利地访问Web服务器。他们投诉的对象主要是“业务部门”：“为何都一天了，还在借口计算机网络故障不受理业务，到底能不能弄好，什么时候能弄好”。由于Intranet主要是供内部系统业务机构的各级有权网络用户使用，所以系统的许多正常功能无法正常启用，致使员工和业务对象反响都很强烈。该社会保险局的网络结构比较复杂，含业务专用网，OA网，Intranet网和Internet网等。其中，Intranet设计为内部业务网，主要进行业务服务。Internet主要是为电话接入访问的用户提供服务， OA网通过LAN内的以太网交换机同Web服务器实现联结。无论是Intranet用户还是Internet用户均可以在网上申报和查询资料。业务数据的安全设计为双Web服务器，Internet用户和Intranet用户各用一个。Intranet的Web服务器兼有备份数据的功能，两个Web服务器互联，之间的业务数据同时更新。Internet用户只能浏览、查询数据并可以进行网上申报等各种服务，不能更改数据。对Intranet内部用户实行有权访问和申报、数据修改特权限制等体制。局内的OA网用户可以象Internet用户那样随时访问和查询Internet的Web数据服务器，其中设置了部分有权用户，他们可以访问Intranet业务网的Web服务器。安装的防火墙对IP包进行过滤，只允许合法IP用户进入。从“病人”传真过来的网络结构图看，Intranet的用户用PSTN公用电话系统、DDN数据专线将各地、县、区的业务网络节点联结起来， 使用者都是地点固定的内部用户(员工)。 
   [诊断过程]显然，故障现象与昨天新安装的防火墙系统有很大关系。将网络测试仪F683接入服务器所在网段，启动网段搜索功能，可以发现Internet用户的Web服务器，但不能发现Intranet的Web服务器。去掉防火墙，则可以搜索到该服务器。说明确实是防火墙的问题。但昨天安装防火墙时整个系统是正常的，所以查找故障的焦点要放在安装防火墙以后有无更改过防火墙参数。此即故障排除经验中的所谓“动则有过”故障查找原则。如果能弄清网管人员都动过哪些参数和设置，查找故障的工作会便捷得多。经常让人感到遗憾且奇怪的是，多数维护管理人员都不会承认更动过网络的任何设置，这次也同以往一样。用网络测试仪连续作ICMP类型PING测试发现，Web服务器是存在的，且反应率为百分之百。说明Web服务器在网络上且可以正常工作。同时用网络一点通One Touch选择Web服务器的IP地址为目标地址发送流量，启动网络测试仪的协议分析功能，发现数据帧指向防火墙以后就没有任何反应了：任何回应数据帧都未出现。将网络助理One Touch的IP地址设置成任何一个已经存在的有权用户的IP地址，然后对Web服务器发送流量，这时网络测试仪可以观察到防火墙有回应数据帧出现。这说明防火墙对合法IP地址的有权用户是有反应的，但一般返回的数据帧是非法用户的提示信息。注意到前述现象中提到过只有防火墙能访问Web服务器，我们就将网络测试仪的MAC地址改为与防火墙相同的MAC地址，用网络测试仪假冒防火墙进入网络，启动网段搜索时则可以看到久别了的Web服务器。
   以上现象说明，该防火墙的功能比较强，除了能过滤IP地址外，还能对各站点的MAC地址进行过滤，以防止“拥有合法IP地址的非法用户”进入系统，是一个比较好的“看门人”。但让人疑惑的是昨天安装防火墙时，网络管理人员只启动了IP包过滤功能，并未启动MAC地址鉴别功能，那么，MAC地址滤波功能是谁启动的呢？答案是：不得而知。查看防火墙帮助文件，按提示揿下format下拉式中的MAC地址过滤菜单，关闭MAC地址过滤功能，系统随即恢复正常。 
   [诊断评点]不少防火墙是靠对IP地址进行过滤和用户密码识别等方法来鉴别有权用户及其合法性等级的，一般不对网卡的MAC地址进行识别。安全性要求高的用户则需要对用户的MAC地址进行鉴别，以便阻止获悉了密码的非法用户模仿IP地址(用户可以在2分钟内随意更改工作站的IP地址)访问网络，部分防火墙和网管系统具有类似功能。我们知道，一般网卡的MAC地址是按制造商的编码设置的，从原理上讲世界上没有两块具有完全相同MAC地址的网卡，而多数网卡地址在制造时就永久地固定在ROM中，用户是不能更改的。对于具有固定用户的Intranet网络，具有MAC地址过滤功能的防火墙是非常有效的，它可以阻止对网络的各种试探性进攻。
   对于Internet用户，这一功能不能启用，所以需要采用两台Web服务器，一个用于查询和申报，另一个作备份，并可以按有权体系修改相应数据。可以肯定，系统管理人员昨天在防火墙安装完成以后可能出于好奇或是其它原因擅自将防火墙的MAC识别功能按钮有意无意地按下了，从而启动了MAC识别功能，致使今天整个系统工作不畅。 
   [诊断建议]对Intranet网络固定有权用户和部分OA网络固定有权用户设置MAC地址鉴别功能对于系统安全和阻止非法用户、恶意用户的进攻是有效的。这类用户多数来自于网络内部的成员，对加权识别设置和安全口令有一定了解，容易钻空子。设置MAC识别功能后，除非是在对应的那台唯一的机器上进行操作，否则是无法进入网络的。我们向该社会保险局建议将防火墙安装分两步走：先将系统内的网络成员的所有网卡的MAC地址备份，在备份工作完成以前，暂时不启动MAC地址鉴别功能；第二步，启动MAC地址识别功能，以提高系统的可靠性。稍微麻烦的是，有权用户在更换网卡时必须向防火墙管理员申请重新设置合法的MAC地址档案才能进网工作。这样，网络固定有权用户的任何成员在需要更改机器的IP地址以及更换网卡或新机器时都必须向系统管理原申报备案后才能进行。 
   [后记]一周后，社保局网络防火墙的MAC识别功能启动。 

[案例二十三]路由器工作不稳定，自生垃圾太多，通道受阻
　
   [症状]今天的“病人”很特殊，是某电力信息部门的主管。称其特殊是是因为该部门主管曾多次打电话要求网络医院为期诊断广域连接的问题，但每次都会在15分钟内来电通知“故障已排除”。询问其排除方法，回答基本上都是“Reset”整个系统。由于该用户只安装了一套价格不菲的“网管系统”来管理整个网络，没有配备其它用于网络维护的工具，网络医院为此曾建议专门为其做一次全面的体检，对该信息网络的各个布线系统、网络设备、工作协议、负荷均衡性、负荷能力、错误帧耐受能力等做详细检测，但一直因各种原因未实施。今天的症状还是老毛病：某电厂的信息网络与电力信息中心的网络联系不畅，数据传输速度不稳定，连接时断时续，有所不同的是系统Reset后仍然不起作用。 
   [诊断过程]该网络下辖9个电厂子网络，一个子网络用X.25连接，8子网络个从去年起陆续更换为DDN链路。其中一条专线DDN线路(7#线路)偶尔会出现连接中断的现象，恢复系统时必须将路由器Reset才能重新连接。今天按老经验，故障现象出现时重复以往的操作程序却发现此办法不管用了，系统仍然不能连接。直到我们赶到现场时系统还未能恢复正常。将网络测试仪接入信息中心网络，可以看到与各电厂子网连接的路由器，查看7#路由器工作表，有少许传输延迟错误记录，通道流量30秒记录为7帧，其它线路的30秒记录则从170帧～2700帧不等，明显高于7#线路；对7#子网络做通道测试，最高为2kbps，远低于64kbps的线路最高速率，说明DDN链路传输正常数据的能力很弱。由于该路由器支持的错误识别和统计功能有限，用网管系统不能查看更详细的统计信息，故改用F69x流量分析仪串入WAN通道进行测试，发现少量未定义帧类型，其记录标识不稳定。也就是说，通道上有一些是网络不需要的且不稳定的比特流。这些比特流不便于分类，流量不稳定，时高时低，表明网络可能存在“垃圾”，且比较象窜入系统的干扰信号。这些垃圾严重影响正常数据的交换和传输。
   为了验证其影响程度，我们用F683网络测试仪向远端子网络作ICMP Ping测试，损失率为10％，不算高，作ICMP Monitor测试，目标不可达50％，重定向20％，拥塞85％，这说明路由通道存在很严重的问题。从中心网络的主网段检测没有发现网络上有干扰比特流，测试为7#路由器供电的UPS输入输出电源谐波含量，显示正常，由此基本上可以排除垃圾比特来自于网外窜入干扰比特的可能性。将其它路由器与7#路由器掉换，重新设置后启动系统，故障依旧。由于垃圾比特数量少，不可能引发网络通道传输速率性能大幅度降低，因此推断“垃圾比特”极有可能是来自于专线DDN链路或远端子网络的路由器。本地信息中心没有配备测试DDN链路的工具，在没有足够证据怀疑就是DDN链路的问题(DDN链路系租用的电信线路)的时候，我们只能先从远端子网络查起。远端子网络没有任何网络维护工具，从中心网络的网管系统又看不到远端路由器存在异常数据，我们只能立即启程赶往7#电厂所在地。4小时后，我们抵达目的地并开始测试。先检测7#子网的工作状态，LAN内部数据交换正常，没有垃圾比特流存在。打开路由器工作表，其中的错误数据记录有少量帧延迟数据包，WAN连接数据交换故障现象依旧，网络测试仪测试的通道测试数据基本与中心网络相同。用F69x流量测试仪测试通道流量，发现大量“垃圾比特”，数量为55kbps，其中35％指示数据来自远端路由器。由此可以断定故障是由远端路由器或靠近路由器一段的DDN链路(可能性很小)造成。更换从信息中心带来的备用路由器后，故障消失。 
   [诊断评点]WAN通道故障可由多种原因造成。一般来讲，通道测试不合格就表明含路由器在内的WAN链路有问题。由于WAN链路可以由多种传输介质及传输协议组成，比如ATM、DDN、ISDN、Frame Relay、SDH等等，所以针对不同链路类型严格地讲要用专门的测试工具进行测试。但因为一般用户都不配备WAN测试工具(部分集成商有相应配置)，所以用户或系统集成商只能先用排除法首先确定是否是路由器(含路由器)以内的网络问题，然后，才能向WAN链路运营商提出检查服务通道的要求。本故障是由远端路由器故障造成，路由器除了传送正常数据外还向WAN链路方向发送大量垃圾比特，从而占用通道流量，严重影响正常数据传输。早期路由器工作虽然不稳定，但每次故障时间不长，所以在“15分钟”内故障能自愈(此类故障我们称其为软故障)。本次故障由软故障转变为不能自愈的“硬故障”，反而为排除故障提供了有利条件。由于多数数据被DDN专线链路给“过滤”掉了，且远端路由器对错误数据的统计识别功能有限，所以从信息中心观测到的垃圾比特比较少，观察远端路由器也不能发现详细的错误统计。但ICMP Ping测试、ICMP Monitor等测试错误数据较大，与远端测试数据基本相等，同时从远端测试到的垃圾比特流很大(“F69x流量分析仪＋F68x网络测试仪组合”具有极强的检测功能，支持完整的错误识别和统计功能，这也是为什么我们认为DDN链路出故障的可能性小的原因)，所以断定故障出在远端路由器。其实，如果远端子网络配备有合适的测试工具的话，本故障在很短的时间内就可以排除。 
   [诊断建议]工欲善其事，必先利其器。大型网络配置一些备用网络设备是必要的，还需要按网络规模和使用级别、维护人员的技术等级配备相应的维护工具，并建立一整套测试维护的方案和规定，这样才能保证网络的可靠性，并保证能及时处理各种网络故障。因为一般的网络设备都具备部分网管功能，能统计并识别30％～40％左右的网络错误和故障信息，所以，有时这给人一种错觉：认为只要具备网管功能，就能发现网络的一切故障。其实，进一步的性能测试需要专用工具，要求这类工具不光能能识别各种正常的工作协议，还要能识别形形色色的“网上垃圾”。一般来讲，除了配备相应的LAN测试工具外，由于WAN链路的测试维护由WAN链路运营商(比如电信公司)负责，但网络用户和系统集成商也需要配备一定数量的WAN测试工具以备性能评测、故障救急以及定期测试的需要。 
   [后记]两天后“病人”来电告知，经过对电路板的测试，发现路由器供电直流电压不稳，进一步测试发现稳压电源IC工作电压不稳定，温度很高，更换IC后路由器恢复正常。

[案例二十四]PC机开关电源故障，导致网卡工作不正常，干扰系统运行
　
   [症状]今天的病人很有趣，是某电信局网管中心，十万火急地要求网络医院帮助立即解决燃眉之急。放下电话我们立即启程奔往“目标”所在地。为提高效率，途中继续与该中心主任进行通讯联络了解“病情”。网管中心所在地为一地区中心，下辖两个县级市和7个县，安装在地区网管中心的网管系统在两个月前发出了报警信号，提示某县级市的网络有异常情况。一个月前省局工作组在检查工作时发现该县级市不在网管中心的网络拓扑显示图上，询问原因，当时答曰：今天正好赶上该县级市进行工程施工，所以将网络管理功能暂时关闭，故在网管机显示器上的拓扑图中无该县级市的网络图标。现在所谓“十万火急”的问题即是：明天工作组将要进行第二次验收检查，而网管系统是此次的重点检查项目之一，不可能再用网络工程在施工为由回避检查该子网的状况。因为网络拓扑图上的报警信息仍在，该县级市的问题也一直没有彻底解决(县级市子网却一直报告网络正常，速度很快！对定位故障一直不太主动)，明日检查恐怕无法“过关”，所以才想到引入“紧急外援”。另外需说明的一点是，该故障在初期时隐时现，最近才由飘忽不定演变为高频发作甚至是持续存在的故障现象。针对这一情况，我们决定先不去地区中心，而是直接转道前往该县级市网管中心，因为从网管指示的范围看问题很可能出在此处。另外，该中心距我们现在的位置比地区中心也更近一些。
　
   [诊断过程]半小时后即抵达目的地，立即投入“体检”工作。根据地区网管中心提供的线索，该子网的路由器报告错误数据流量较高，因此直接对该子网进行测试。该子网为用交换机连接的多网段结构，含8个10BaseT和18个100BaseT以太网。用网络测试仪接入网络作自动监测，测试路由器平均错误流量记录为3％，有效流量为7％(广域连接用的是E1链路)。观察交换机自身提示的错误流量系指向第一插槽的3＃端口所连接的子网段，其它子网段测试正常。3＃子网段为拥有97个工作站的100BaseT以太网网段，DNS服务器、IP服务器和其它主要的业务服务器也挂在该子网段内。测试3＃端口的错误计数统计值为25％，随即将F683“网络万用表”(即网络测试仪)移动到3＃网段进行监测。结果指示：错误类型为帧校验错误和其它未分类错误(这可以是为无帧头结构的、且非碰撞类型的自由帧、离散帧等)，比例分别为27％和11％，其中正常数据包流量为3％。27％的错误统计值与交换机提示的错误统计值基本一致，但还有11％的错误交换机和路由器等不能识别，需要进行定位。断开路由器，错误指标略有降低。这表明故障确实是在该子网，与WAN链路基本无关。由于子网段全部由集线器堆叠而成(8×16Port)，故进一步观察网络测试仪F683指示的全部错误定位数据。仪器提示97个工作站和5个服务器均发出类型为FCS帧校验错误的数据包，数量不等。
   由于全部工作站均发出FCS帧校验错误帧，所以不认为是所有的工作站网卡都有问题(这种可能性微乎其微)，而故障原因很可能是电缆故障(全部电缆打线有误或采用了假冒伪劣电缆)和干扰窜入，如信号干扰、接地干扰、电源干扰、辐射干扰等等(包含在未分类错误类型中)。网管人员认为，由于电缆系统在竣工验收时全部都采用ISO11801标准进行过认证测试，测试工作是网管中心自己承担的，所以应该没有问题。为快速定位故障，采用通常的“二分法”隔离网段：先将一半的集线器断电，故障依旧，再次将其中一半集线器(即总量的四分之一)断电，故障消失。恢复供电，逐个拔掉该四分之一集线器(两个集线器)上的工作站电缆插头，当拔下6号集线器的7＃端口连接的工作站电缆插头时，网络万用表上的错误指示全部消失！网管人员断定，故障为该工作站之网卡的可能性不大，因为所有的网卡昨天为了迎接检查验收都进行过相邻三组网卡的两两互换试验和三台相邻整机的两两换位试验(该中心没有配备其它的网络测试工具，只好采用这种常用的但经常是有效的所谓“笨办法”)。用网络测试仪对此故障工作站的网卡进行测试，结果其端口的物理参数和工作协议都正常。由此可以大体断定故障出在工作站的其它部位，且基本是干扰类型的错误(属于未分类帧错误类型)，不排除线缆引入过量噪声的可能。拔下网卡一侧的电缆插头，故障消失，说明故障不是由电缆噪声引起。靠近该工作站可以闻到一股虽不是十分明显，但却比其它工作站都强烈的电器“烧焦”味(不过，还远未到令机器冒烟的地步)。贴近机器可以听到开关电源中发出的明显的“咝咝”响声。测试工作站与服务器的联络情况，可以看到大量的重发帧和无效帧。更换备用的开关电源，故障排除。
　
   [诊断评点]故障原因比较简单，是由单台工作站开关电源故障产生的放电干扰信号窜到网卡输出端口后进入网络所造成。该干扰信号进入网络后占用大量的网络带宽，破坏其它工作站的数据包(即表现为“患者”众多的FCS帧校验错误类型的数据包，其比例随各个工作站实际的正常流量而定)；同时该干扰信号还干扰服务器、路由器的工作(重发帧、无效帧等)，使得地区中心的网管机屏幕上经常有报警状态提示。由于网络总流量为41％左右(低于40％的平均流量时用户基本不会感到网络变慢)，有效流量只有3％，所以县级市子网上的用户虽然自己发出的数据包有很多被破坏而需要重发，同时接收到的数据包有很多已被破坏而需要重收，但是基本上不会感到网络速度有明显的变慢！！
　
   [诊断建议]网管系统通常只能发现约30％～40％的网络故障(这取决与被管理设备支持网管的能力和分析、记录网络异常流量的能力)。当有故障报警后，多数情况下需要进一步迅速确定具体的故障位置和故障属性。本次故障不能精确定位并立即排除的原因是多方面的，其一，县级网由于没有网络维护工具，仅靠网络维护人员的经验和从互联网上下载的某些软件来监测自己的网络，这是直接导致了此次故障长时间无法解决的原因。现阶段，按不同的网络维护规模和级别为相应技术水平的网管人员及运行维护人员配置合适的工具到目前为止一直是让网络规划人员、计划单位和网络维护人员自己都搞不清的事情。其二，本次故障本来原因比较简单，但因维护体制方面存在的问题从而导致在故障查找过程中不能密切配合和协作，使得问题长期未能解决。其实，如何比较全面、有效、快速和低成本地实施网络的管理和维护已经有许多成熟的方案和做法。建议网管人员和运行维护人员在忙于快速建网、不断跟踪网络新技术和接触新设备的同时也要抽出部分精力来研究有关网络维护的理论、方法和成熟的方案，力争达到事半功倍的效果。比如，进行完整的网络文档备案工作、定期测试、网络基准测试、性能监测、体能测试、通道测试、协议监测、流量分析等工作就一直是一些大型网络成功地防止严重事故发生的有效而简便的手段。你知道吗，与你见到的和想象的都不一样，消防队平时更重要的工作并不是救火，而是防火！！网络维护工作亦莫不如是！可以完全相比拟。 
   [后记]该地区网对下辖子网后来作了一遍比较全面的认证测试，发现了许多平时无法察觉的故障隐患，现在的网络健康水平应该是最高的。我们最近将应邀对其所属的网络进行一次总体评分，希望能有所突破(10分制，目前最高得分记录为5分)。

[案例二十五]私自运行Proxy发生冲突，服务器响应速度“变慢”，网虫太“勤快”
　
   [症状]某市工商局信息中心今日向网络医院“报案”，报告其关键的企业数据服务器经常出现“阻塞”，起因是分布在各地的各个业务受理局、所等的工作人员时常向信息中心抱怨在进行企业数据调用、核查和进行新企业登记操作时经常遇到“梗阻”，速度变慢或业务出现暂时性的停顿的现象。由于故障现象不是持续存在，虽然检查过多次，也杀过多次“毒”，更换速度更快的服务器后情况好转，但未从根本上能解决问题，始终没有找到真正的“病根”所在。要求帮助查找“元凶”。走进该工商信息中心崭新明亮的机房，可以看到正面的墙上有一幅巨大的网络结构拓扑示意图，上面非常清楚的标明了各种网上设备和网络设备的型号、名称、位置、速度、链路类型和连接关系等等。初步感觉这样的网络器管理水平应该是不错的。但，经过了解获知，目前实际的网络的结构比较特殊，与拓扑图上的结构有较大区别：用于业务网的大部分机器还设在旧的信息中心机房中，只有企业数据服务器等关键设备安装在新工商大厦的信息中心机房中，且同办公网连通。新大厦和旧信息中心相距约2000米，中间通过光缆和路由器连接起来，并在办公网侧设置了防火墙。办公网的多数用户都可以通过WAN链路访问internet国际互联网。信息中心主任对此的解释是：按工程规划的要求，需要把原信息中心机房的全部设备和人员搬迁到新大厦的信息中心机房，但因发现新大厦存在建筑质量问题，两个月前只搬迁了少部分设备和绝大部分的人员。为了不影响业务，在对设备采取临时性的重新布局后即投入了运行。工作状况一直正常。多数业务设备还留在了旧机房中，由2名留守人员负责管理。大约一个月前开始出现故障征兆。该信息中心负责下辖8个工商分局，76个工商所的网络连接和业务保障工作。局和分局之间用帧中继链路连接，工商所和分局之间用DDN、ISDN连接，少数用拨号方式连接。业务网与办公网之间用防火墙隔离。业务网中的用户除分局的少数用户外按设计要求均不能上互联网。 
   [诊断过程]从安装在办公网中的网管系统上观察，企业数据服务器流量为28％，属正常。就近从办公网用网络测试仪F683对服务器进行连通性测试，损失率为0％。这说明至少在此时此刻服务器是工作状态是不错的。用网络助理(网络一点通)对服务器发送10％的流量，观察服务器的使用情况。从数据包交换对话矩阵中发现，服务器对办公网中的用户均有响应，而对原业务网中的用户则有少数几个“不响应”的记录。由此可以推断故障原因绝大多数可能还在原业务网中。将网络测试仪移动到信息中心旧楼中进行测试，结果如下：网络流量为45％(略高)，碰撞率为3％，错误率0％，广播7％(略高)。总体基本正常。进而观察网络协议的分布状态，基本正常。查看数据包对话矩阵，则发现凡是对企业数据服务器的访问数据包均有部分“不响应”记录。该记录涉及面很广，几乎40％的工作站均有牵连。为了验证是否是数据链路的问题，进行了ICMP Ping和ICMP Monitor测试，前者报告有两个MAC地址响应，后者则报告记录到大量的目标不可达、重定向、拥塞告警等数据帧。这说明网络的数据链路中有重复的IP地址，而且网络对数据帧的路由运算也存在问题。启动网络测试仪的网段自动搜寻功能，自动查询网络连接结构，结果发现有多余路由解析操作(Proxy)，但没有发现重复的IP地址(这说明重复的IP地址不在该网段，而存在于数据访问通道中)。因网管人员没有MAC地址备份文档，故建议将旧楼中的所有本地工作站关机，此时网络立即恢复正常。为确定与服务器重名的工作站，再分批打开所有工作站，结果发现留守人员的2台机器中有1台IP地址与企业数据服务器重名。进一步检查该工作站，还发现其私自安装并运行了Proxy代理，与网段搜索的结构一致。 
   [诊断评点]故障原因有三。一是IP地址重复，二是运行非法路由代理。当业务网用户要求进一步的地址解析分析时，留守机与数据服务器发生冲突，多数的数据流向发生混乱(注意，此时的数据帧结构仍正常)，使用户的访问发生“梗阻”。应用软件则经常要求重新联络和重传数据，导致流量偏高、业务流程速度变慢。由于冲突基本限制在原信息中心网络中，所以企业数据服务器的流量显示正常！网管系统也无错误数据包报告！原因之三：对留守人员的管理出现真空。留守人员因“无聊”(员工自述)而渴望“越权”连接互联网，并由此开始迅速成为一名“白日网虫”，进而干扰正常业务流程。由于其操作并不一定持续存在，从而导致问题出现一个多月不能解决。
其实，办公网中的互联网用户也会或多或少地受到影响，只不过因白天用户的使用频率低未曾察觉而已。 
   [诊断建议]网络管理的漏洞大多数来自于内部管理人员，建立严格的内部管理机制是非常必要的。同时，建议将MAC地址的备份列入必备文档。另外，每日对网络进行状态自动搜寻会有助于很快发现并清除非法用户。健康的网络维护方案中其实早就有关于定期测试(包括每日测试和每日循环测试)的项目，只要坚持每日必要的测试和检查，就可以保证99.9％的网络不会有超过2天而解决不了的严重网络问题存在。 
   [后记]一个月后用户来电告知全部设备已经迁入新居，现在每日坚持定期项目的测试和记录，网络工作状态良好。提心吊胆的日子终于结束，可以松口气了。

[案例二十六]供电质量差，路由器工作不稳定，造成路由漂移和备份路由器拥塞
　
   [症状]今天的“病人”是位居某中心城市的一家大区银行，报告的故障现象是：故障时断时续，呈周期性“发作”，每隔10分钟左右在其辖区内就有部分支行或分行打来电话报告业务流程出现问题。具体表现都很一致：先出现业务中断，1分钟后连接恢复，但速度非常慢。此故障已经持续了2天，网管人员怀疑是路由器故障，曾试着分别更换了备用的同城结算路由器和主路由器，无效。 
   [诊断过程]我们驱车来到“病人”的计算中心，首先向网络管理人员了解故障情况。基本上与网络医院“接诊”记录报告的内容相同。从表现的故障现象来看，根据以往的经验，基本上可以初步推断是路由链路的问题。网管人员确认，业务中断时，普通Ping测试不通，此现象以前也出现过几次，很快就恢复了。因此也没有引起注意。从记录的故障报告(电话登记)看，无论是本城辖区还是大区内的远程网络都报告过路由中断现象。由于故障每隔10分钟左右就会周期性地出现，虽然比较频繁，却为故障诊断提供了很大方便。可以考虑选择任意路由进行连续的Ping测试，监测其连接状况与故障发生时刻的关系。为此我们将F683网络测试仪接入计算中心网络进行监测。选择曾报告过故障的其下辖的某郊县路由器作连续的ICMP Ping测试，响应时间为9ms，质量尚可。3分钟后，有用户报告故障出现，不过网络测试仪显示正常，说明我们监测的路由链路可能是正常的。立即改变监测方向，向报告遇到故障的用户的路由器做ICMP Monitor，结果大量的目标不可达记录出现，并出现源限制、回应请求和回应响应帧。20秒钟后，出现大量重定向帧记录，目标不可达帧记录速度减缓，源限制、回应请求和回应响应则开始大量出现。以上记录表明，路由器的动态路由表在故障出现时发生了很大变化。网络原来的路由中断后，继之被重定向路由取代。打开静态路由表，为了与动态路由作比较，我们启动F683分段路由追踪功能，追踪从测试仪到先前报告故障的远程路由器。可以看到，路由在本城出口的下一站，即大区链接的第一个路由就发生了中断。动态路由已经由备份路由取代。状态：拥塞。原路由为主路由，通道速率为E1，为ATM链路，备份路由为DDN基本速率链接，速度仅为64Kbps。打开主路由器的Mib库，观测到主路由器的流量为0.02%，错误为2％；表明它处于轻负荷状态，并有少量错误流量。观察备份路由器的Mib库，流量为100％，说明它处于超负荷运行状态。由于故障为周期故障，为了观测它的发生规律，我们在征得“病人”同意的前提下，决定不急于寻找主路由器中断和拥塞的原因，而是先观测在一个周期里故障变化的全过程并记录之。我们用第二台网络测试仪和网络故障一点通接入网络，分别观察主路由器、备份路由器、主服务器的工作流量和错误，并对主路由器作连续的ICMP 监测。约8分钟后，主路由器流量开始迅速上升，备份路由器出现重定向指示，约15秒后报告备份路由器推出优化路由，动态路由表恢复到与静态路由相同的设置。网络完全恢复正常。分析故障关系，可以断定故障的最大关联设备是主路由器。由于用户在机架上已经安装了冷备份的主路由器，我们先将冷备份路由器替换到主路由器的位置。5分钟后路由器更换完毕，开机接入网络，3分钟后网络恢复正常。但只持续了2分钟，故障现象又重新出现。看来，必须对主路由器做详细监测才能发现真正的故障所在。网络建构拓扑是，主路由器与三个外区远程路由器和一个本地路由器相连，我们可以同时监测这几个路由器的工作状况。监测结果如下：故障出现时，外区主路由器和本城路由器的路由表随着故障的出现也发生变化，而此时同城结算业务不受影响。受影响的业务方向是外地与本城、本城与外地、外地经本地跨区等。用Fluke的ATM测试仪测试远程ATM路由通道，将远端ATM交换机Loopback(环回)以后监测三个方向的通道情况，显示完全正常。再对与主路由器相关的连接电缆进行测试，全部合格。这表明主路由器的工作环境是基本正常的。此时我们需要了解主路由器链路中的“垃圾流量”的分布。但由于网络医院的流量分析仪出借给了别的“病人”，所以我们暂时不能观察主路由器的详细流量状况。实际上，我们这是也只需要检查主路由器的接地质量和供电环境即可(因为已经试验更换过主路由器)，这两个因素当中的任何一个不负荷要求，都有可能引发主路由器中断的故障。首先观测为主路由器供电的UPS电源。当故障发生时UPS显示过载，而输出回路却显示轻负荷。用F43电力质量分析仪观察也显示故障时输入谐波超差6倍。输出回路超差400倍，故障恢复后，过载指示也随之消失，但输出回路仍超差80倍。证明UPS电源低效。将主路由器的供电电源接到另一台UPS电源上，故障彻底消失。故障原因为供电质量不合格。我们注意到，该计算中心所在的大楼正在装修，网管人员说等大楼装修完毕后还要将网络设备扩容。初步干扰源很可能就来自与装修有关的部分。由于故障的周期性，经过仔细观察发现，故障出现的周期与楼旁塔吊的上下周期一致！为准确判定谐波干扰的源地点，我们将F43电力质量分析仪接入供电网络进行核实，结果发现，每当塔吊上升时，故障现象就出现(下降时谐波为上升时的三分之一，网络有少许变慢)。 
   [诊断评点]为主路由器供电的UPS电源由于失效，对外界电力干扰谐波的过滤能力下降，当为重负载的用电设备供电时，此谐波会引发许多设备出错。如果此时恰逢UPS电源滤波失效，则相关设备会受到干扰。本故障中，主路由器由于大量干扰进入，使得链路阻塞，路由器连接中断，路由变更指令使得各业务流量流向备份路由器，备份路由器的路由通道能力又不能满足，致使网络出现拥塞。这就是本次故障先中断后恢复然后阻赛的原因。同城结算数据由于多数不经过主路由器，所以未受到影响。塔吊下降时，虽然引入的干扰也不少，不过因为其干扰的绝对值未超过主路由器的承受范围，所以主路由器还能应付。大楼装修以前也出现过类似的故障，因干扰源很快消失并不再持续存在，因此不可能引起维护人员的注意。 
   [诊断建议]与电缆和光缆系统一样，电力谐波和UPS电源也是列入定期检查的内容，一般建议作半年定期检查，关键的网络建议作为周定期检查的项目。谐波干扰是经常存在的环境因素，如果此时UPS电源不出问题，一般不会影响网络的正常运行，但谐波干扰是严重影响网络性能的原因之一，一旦窜入网络则引起的故障多数都是“致瘫性”或致命性的。还由于多数用户对干扰类型的故障“相当地”不熟悉，故提请大家引起较多关注。 
   [后记]更换UPS后，该网络“从此”表现优异。让我们感到欣慰的是，“定期维护”的概念已为“病人”所接受。在网络医院的帮助下，他们制定了详细的网络健康维护方案，确定了定期维护、视情维护的详细规章。其实，这才是网络医院的工作最有价值的一部分。那就是：未雨绸缪，防患于未然。

[案例二十七]中心DNS服务器主板“失常”，占用带宽资源并攻击其它子网的服务器 
   [症状]有“病人”来电报告网络的一个子网突然变慢，中心主网络则基本正常。以下是“病人”的主述“症状”：“病人”是某市电信多媒体网络服务公司(163、169)，该市为地级市，为本市及市辖县的普通用户提供本地热线网站服务和Internet接入服务。昨天，其服务的用户反映网络速度很慢，Email经常需要等待超过60秒以上的时间才能联通，随即其市营业厅(即子网所在地)报告速度突然变慢，影响业务。“病人”在主机房安装有网管系统，从网管上观察发现除了营业厅子网路由器流量很高以外(测试为97％)，中心网络的路由器与其它子网的交互流量均为40％以下。没有其它特别现象，应该说网络速度不会受影响。由于维护人员没有配备其它网络测试工具，又不能在白天断开网络停止用户服务来进行检查。经人介绍遂请网络医院派员帮助检查。 
   [诊断过程]这个故障表现比较简单，检查的时候只要查出子网的路由流量来源就可以很快确定故障方向，进一步则立即可以查出流量源。由于用户没有配备分析网络流量的工具，我们估计故障在子网的可能性比较大，所以我们直接驱车驶向子网所在地，即电信营业厅。从网络拓扑图上看，营业厅子网与中心网络的链路为E1，平时作为业务营业厅网络的业务通道。由于营业厅网络一般只用于传输一些业务数据，其子网的网站数量为45台，网管报告97％的流量肯定是过高的。有一种情况可以比较多地占用E1通道的有效流量，那就是营业厅子网有网站与中心网络的网站或服务器之间有多媒体动态图象传输，比如VOD等。这种情况在不少地方发生过，但它要求必须有动态图象源才可以实施“点播”，中心网络目前不可能提供这种服务(但不排除私自安装的可能性)。营业厅网络由于规模小，中心网络的网管系统只支持到路由器一级的管理。交换机和服务器等采用的是廉价的桌面交换机，所以无法支持网络管理。我们将网络测试仪F683接入交换机进行测试，启动便携网管功能，可以看到路由器的流量和网管系统观测的到的流量是相同的，均为97％左右。查看中心网络处与此相连的路由器流量，也是97％左右。这说明路由器通道链路性能基本正常，不过这样高的通道流量必然导致路由器拥塞和丢包，所以从流量的角度看又是不正常的。现在需要了解的是，如此高的路由流量是从哪里来的？数据包到达路由器以后的去向等。这样就可以很快定位导致如此之高的通道流量的数据源和拥塞源。将Fluke的F695网络流量分析仪接入网络的路由器通道进行监测和分析，结果显示95％流量流向了业务数据服务器，且多数为HTTP和Email方面应用(流量分析仪专门分析包括应用层在内的网络上层的协议的应用流量)。其中，Internet访问流量占88％，本地流量占7％。查看流量分析仪指示的流量来源分布图，没有发现集中的流量应用，IP地址分布比较均衡，最高的流量只占0.5％。这些数据表明，用户的应用比例均衡，故障原因应该在应用过程中而不是某个集中的用户“轰击”，比如黑客等。也就是说，应用的过程和通道出了问题。这是因为，这些流量按通道设计不应该到达营业厅网络的业务服务器。而是应该直接从中心网络的Internet主路由器进入互联网。那么，这些流量是如何被引导到营业厅服务器方向上来的呢？我们知道，IP数据包在传输过程中会在路由器中作地址解析(ARP)，或是在本地DNS中进行域名分析。如果这些分析路径出问题，则IP数据包的传输和交换就会出问题。根据流量分析仪的指示，我们任意选择了10个IP地址做路由追踪测试，用Fluke的F683网络测试仪追踪的结果是，他们都要经过一个DNS服务器。而模仿营业厅网络成员分别对已知的本地和外地用户做ICMP监测和路由追踪测试，结果发现，ICMP监测中重定向数据包占82％，目标不可达数据包数量占13％。这表明，只有约2％的用户能一次性出入正常路由到达目标站点，其余95％的IP数据包都要经过路由竞争或重新发送才能有部分机会到达目的地。由此，可以重点检查主路由器的路由表和DNS的转换表。由于多数Internet访问流量被引导到了营业厅业务服务器，所以可以重点检查DNS服务器。用F683网络测试仪对DNS服务器做查询，观察查询结果，发现DNS转换表有相当大的比例指向了营业厅子网中的业务服务器。怀疑是DNS服务器出了问题。我们随机通知中心网络的网管人员将DNS服务器重新启动并快速设置一次，稍后网络管理人员报告网络业务恢复正常。用F683网络测试仪的Internet工具包查询DNS服务器，可以看到指向营业厅业务服务器的数据已经全部消失。这表明网络已经完全恢复了正常工作。但好景不长，约3分钟后，故障重新出现，仍有97％的通道流量被指向了子网。由于DNS服务器只设置了一台，没有备份或备用服务器。我们不得不立即来到中心网络机房，对DNS服务器及其周围设备进行检查。测试服务器网卡和与路由器的电缆，正常。为了不中断服务，我们请网管人员在另一台备用服务器上临时安装设置了DNS服务器。经过短暂的业务中断后，更换上的新DNS服务器开始投入适用。只见子网路由器的流量立刻降低到了1.5％。经过30分钟的稳定工作后，所有用户均恢复到正常工作状态。 
   [诊断评点]DNS服务器用于将用户域名转换为IP地址，一般来说不会出现什么问题。但由于某些原因，转换地址通通指向了营业厅子网的业务服务器。业务服务器不具备路由处理功能，对发送来的IP数据包要么拒收并置之不理，要么返回目标不可达或需要重定向的报告数据包。这就是我们在ICMP监测时经常观察到的现象。该地区城市中心网络的用户数量不多，与省中心网络的链路带宽为155M的ATM链路，大有富余。所以上Internet的用户其上网速度主要受子网带宽的影响。因为许多的用户要经过拥挤的无效E1链路，造成路由重定向和严重的时延。大量的IP数据包拥向只有2M带宽的子网路由器，流量达到了97％，造成子网工作速度突然变慢，路由器出现严重拥塞等现象。为了确定地址指向的错误原因，我们建议用户抽时间按下列步骤定位故障：首先，将原来的故障DNS服务器的工作平台和应用软件以及网卡驱动程序全部重新安装一遍，然后选择深夜用户数量最少的时候接入网络使用，查看转换表是否正常；其次，如果仍然不正常，则更换网卡，主板等硬件，逐步缩小故障范围。 
   [诊断建议]基为了防止DNS服务不稳定造成业务中断或出错，不少网管人员在设置DNS服务器时都安装了备用DNS服务器，亦即安装不只一台DNS服务器。但这样做也会带来一个潜在的危险：即主DNS服务器出问题，备用自动服务器投入运行，这样会牺牲一定的网络带宽，使得系统总体性能有所下降。危险在于，性能的下降常常是在不知不觉中来到的。所以，为了保证网络经常处于良好的工作状态，网络管理人员需要定期检查DNS服务器的转换表。这也是“周维护”(即美洲定期维护项目)中建议的内容之一(当然，要保持网络的优良性能不只是检查路由优化性能，还有其它许许多多工作需要做。比如：性能评测、基准测试、通道测试、应用监测、拓扑结果管理、定期维护等等，有关这方面内容读者如感兴趣可参阅《网络测试技术简介》)。本故障中的DNS指向错误导致用户的IP数据包对准了子网服务器，但如果对准的不是服务器而是中心网络本地网段中的某台机器，则故障强度会减弱，用户不会感到非常明显的速度变慢。这样“病人”可能不会感到明显的“身体不适”从而使得网络长期带病运行。就象人一样，定期的体检对及时发现疾病及其隐患是非常必要的。而如何及时发现路由优化方面的问题，也是网络定期项目测试中的内容之一，对大型网络则更有必要，必须坚持定期维护和测试。
   许多网络设备如路由器、交换机、只能集线器等都支持SNMP网管功能，但为了全面监测网络通道功能，还需要网络设备支持全面的RMON和RMON2。用这样的设备组建起来的网络其管理和故障诊断功能是很不错的。但现实的问题是，这样的网络设备价格是普通网络设备的6～10倍左右，用户难以接受。因此，为了随时监测网络的服务应用流量及其比例、来源，工作记录以及必要时进行解包分析，建议用户在重要的服务器通道或路由通道上安装监测接口。以便必要时可以随时将流量分析仪、网络测试仪接入通道进行监测和分析。这样，本故障的查找时间可以缩短到20分钟左右。当然，如果资金允许，也可以将流量分析仪长期接入通道对多个重要的网络设备进行全速率透明流量监测，这样可以把故障定位时间缩短到1分钟以内。 
   [后记]第三天，电话回访“病人”，网络表现一切正常。用户自己已经查明故障设备是原来的DNS服务器的主板。该主板工作不稳定，我们推断该服务器在应用层的数据交换和计算时或与网卡交换数据时出现程序错误。更换另一台DNS服务器的主板后功能恢复正常。“病人”已将修复的DNS服务器设置为在线工作的备用DNS服务器，以提高网络可靠性。


[案例二十八]网卡故障，用户变“狂人”，网络运行速度变慢
　
   [症状]今天的病人是某大型寻呼公司，刚更新了高速寻呼设备，增加了信息服务的业务内容，并对计算机网络进行了比较大的扩容和调整。调试工程一直比较顺利，但好景不长，刚正式开通工作一天就出现严重问题。技术中心严经理报告的故障现象如下：最初是在工作台上偶尔观察到在键入寻呼的用户数据时键盘更新出现等待现象，后来愈来愈严重，从刚开始的一秒钟左右到现在的10秒钟以上。网络服务速度很快就变得非常缓慢，寻呼业务员在操作台上键入数据时，屏幕显示有时甚至要等待1分钟以上才会更新。基本上在10秒钟和1分钟之间波动。在业务高峰时处理寻呼的速度赶不上要求，用户排队现象严重。设备管理人员查看过集线器、交换机，发现他们的指示灯一直闪烁不停，好象比以前印象中的快了不少，怀疑网络流量可能很高。用软件查看主服务器的CPU资源利用率，达到93％。查看了5个工作台上的计算机CPU，显示资源利用率85％以上。时逢4月26日，怀疑是不是有病毒在做崇。用了三种杀毒软件先后进行扫毒，之后发现故障现象依旧。由于寻呼中心机房没有配备网络维护的硬件工具，工程承包商对此现象更是手足无措，故向网络医院挂急诊求治。 
   [诊断过程]30分钟后我们来到现场。正如严经理所言，从持续闪烁的指示灯上就可以观察到网络流量肯定很高。该网络采用NT作平台，工作协议为IP，用网络测试仪F683接入网络的任意一个接口进行测试，结果如下：网络流量平均为57％～83％，偏高较多。碰撞率4.9％～5.3%，广播42％～74％，错误2％～3％。网络的正常流量波动为8.1％～0.7％。很明显，网络的非法数据帧占据了大量的网络带宽。主要的非法帧为高流量的广播帧，其次是错误帧。为了查明广播帧和错误帧的来源，我们先启动网络测试仪的错误查找统计测试功能，2秒钟后显示错误类型为超长帧、帧不全、FCS错误帧以及少量短帧。按下网络测试仪的错误统计“Error Statistic”软键，查看上述各项错误的来源，均显示错误来自为一台取名为“Cindy”的主服务器；为查找超量广播的来源，按下网络测试仪的“Top Sender”测试软键，显示广播帧超量发送者同样也是“Cindy”这台服务器。另外，“Cindy”还发送约0.8％左右的正常IP帧。将“Cindy”从网上卸下，各单机故障立即消失。为了确认是网卡本身的问题还是网卡驱动程序的问题，将“Cindy”的网卡驱动程序重新安装了一遍，之后启动机器运行，故障现象出现。说明网卡本身故障的可能性最大。更换网卡后网络恢复正常。 
   [诊断评点]网络平均流量是决定网络运行速度的一个重要条件。在以太网中，瞬间流量可以超过90％，很适合突发流量的传输。当网络的平均流量在40％以下时，网络运行速度一般不会主管感觉变慢。本故障中，服务器“Cindy”由于网卡故障，除了发送一些正常IP包外(约0.8％)，还发送约2％～3％的错误帧和主要影响网络带宽的超量广播帧(42％～74％，造成用户键盘更新在10秒～1分钟之间波动)，这里对网络影响最大的是超量广播帧。广播帧是网络设备定期不定期进行网络联络的一种手段，但过量的广播会占用不必要的带宽。一般来讲，网卡损坏以后，有多种表现类型，常见的一种表现是“安静型”，此时网卡不向网络发送任何数据，机器无法上网。另一种常见的类型是“狂躁型”，其表现颇象一个喝醉酒闹事的醉汉，嘴里喋喋不休。该网卡除了发送正常数据以外，还发送大量非法帧、错误帧。本故障发送的是大量的广播帧。广播帧可以穿过网段中的桥和交换机，所以整个网段上的设备通道都会被广播帧占用带宽，即便是不向网络发送或接收数据的站点也会因为接收大量的广播帧而导致站点的网卡向宿主机的CPU频繁地申请中断，CPU资源利用率达到了85％。这样，网络上的站点处理本机应用程序的速度会受较大影响。有趣的是，很多用户也是在把机器从网络上退出时才发现站点的故障与网络有关。而之前却一直以为是工作站的问题，且最容易被误判为病毒发作。许多网管和网络维护人员通常的做法和遭遇都会象下面所描述的“故事”：首先，启用多种杀毒软件进行查杀毒操作，无效。然后，把所有工作站格式化，重新安装其操作系统和应用软件。但由于问题出在服务器，所以仍然不见效。最后，不得不将所有机器(当然也包括服务器)格式化以后重新安装系统平台及应用软件。如果是服务器网卡驱动程序安装错误(比如安装的驱动程序版本不符合，虽然能工作但不顺畅)，则故事可能因重新安装了正确的驱动程序而到此结束。如果是网卡“狂躁型”故障，则故事还会延续很长时间。因为“狂躁型”病人不理会网络的游戏规则而向网络发送大量非法帧流量，占用带宽，影响所有网络成员。不幸的是，狂躁型病人在网络故障统计中所占的比例不是很低！ 
   [诊断建议]“网络健康测试”和“网络基准测试”都是为了实时和长时间监测网络流量的变化规律，帮助维护人员掌握网络应用和流量变化的规律，即时发现和处理网络故障。“网络维护方案”中建议健康测试是每日必须测试的内容，要求实时监测网络的流量/利用率、碰撞、广播、错误等基本健康参数，也可以简化监测程序，选择在每天网络最繁忙的一段时间进行测试。这样网络的异常可以被立即发现(因为许多网络故障在网络流量低、比较清闲时并不表现或明显地表现出来)。当然，比较稳妥的方法是对网络进行认证测试。除了布线系统外还对工作的网络进行认证测试。以便在网络投入正常运行前就发现并根除网络存在的故障和潜在的性能问题，最大程度地优化网络的性能。 
   [后记]第二天，我们应邀对该寻呼网作了一次简化程序的网络认证测试，其中流量冲击测试服务器耐受度为100％，如果不是上述故障，该网络性能总评应当是比较优秀的。

[案例二十九]PC机网卡故障，攻击服务器，速度下降
　
   [症状]今天是五一节假期的最后一天，某大型铁路枢纽站来电，报告其售票系统出现很大问题，最先是枢纽所在局本地的售票系统报告售票速度比平时慢几倍，车站售票厅前已经排起了长队，乘客意见很大。其它市内预售处也受到影响，出票速度也很慢。随后，是各联网局均有报告网络的票务查询速度慢，邻近局报告更频繁一些。维护人员认为是中心票务服务器有问题，随即决定系统暂停业务并将备份服务器很快启动投入系统运行，非但未能见效，反而速度更加缓慢。急招该系统的工程集成商立刻处理系统问题，观察中心票务服务器CPU资源利用率达到了97％，基本上是满负荷运行，其它服务器和工作站等网上设备均为发现问题。短时间断开预售点和其它路局的连接路由，故障现象依旧。系统集成商随即将票务中心机房内的其它网络设备如交换机、集线器、网关等全部更换，启动系统故障依旧。故障累计已经近7小时，路局承受的压力越来越大，已经开始准备紧急启动本地人工售票预案。 
   [诊断过程]网络医院接报后立即赶往票务中心计算机网络的机房，网管人员告知在节日期间已经出现过类似的现象，只是持续的时间不很长(有时会持续2小时左右)，速度虽有变慢，但基本上不影响出票速度。经过与网关人员和系统集成商的工程技术人员简单交流后，分析故障原因可能有五，一是票务结算软件问题；二是病毒或内部人员尤其是网络管理人员误操作或更改设置，比如删除不应该删除的文件，私自在系统上运行了冲突软件或破坏性软件；三是系统平台故障，比如NT平台受到干扰后出现硬损伤(指不能恢复的改变，必须重新安装系统才能正常运行)；四是网络设备问题，五是其它网络问题。由于已经更换过票务服务器和交换机等网络设备，所以先暂不考虑第一、四种可能性；为了节省故障诊断时间，暂不考虑第二、三种可能性(如对系统进行一次详细检查和协议测试或重新安装一次NT平台并做好相应的设置、数据恢复等需要较长时间)，而首先就第五种可能性对网络进行测试。查看其它服务器CPU资源利用率，都在25％以下。查看网络拓扑结构图，将网络测试仪F683随即接入网络中的一台工作组交换机，观察整个网络的工作情况。先查看网络设备的工作情况，显示交换机、路由器等本身均正常。核心交换机与票务服务器的连接端口为第二插曹第7端口，设置为100Mbps，流量实测为84％，偏高。查看整个网段的MAC对话矩阵，也显示票务服务器的访问流量很高，进一步查看IP对话矩阵，与MAC矩阵基本一致，比其它对话矩阵中的成员高出500倍以上。追查访问的数据来源，发现一台内部账务处理PC机与票务服务器之间的对话流量很高。从MAC矩阵上观察其流量很高，从IP矩阵上观察流量稍低于MAC流量。为了提高处理速度，票务服务器按设计是直接与核心交换机相连的，而账务处理用的PC机通过桌面交换机—工作组交换机—核心交换机后与票务服务器相连。询问票务处理PC机的操作人员，答曰节前该机工作就不正常，速度慢。曾向网络维护人员报告过故障，但因邻近节日，维护工作量大，维护人员计划待节日以后再处理账务PC机的问题。将账务PC关机，系统故障立即消失，整个系统恢复正常，一片欢呼。为了确认该PC机具体的故障位置，将其移动到局办公网上接入网络，重新设置后工作正常！！！为了慎重起见，网管人员还是决定启用一台新机器代替账务PC接入网络，同时观察网络的工作状态。发现网络完全恢复正常，故障排除。用网络测试仪测试办公网，流量为2％，很低，无错误数据包。将集线器串入账务PC与交换机的连接通道，用网络测试仪和协议分析仪接入观察。从F683网络测试仪上观察，显示网络流量为79％！！错误37％(其中90％为长帧，其余为短帧)，网络测试仪指示流量来源于账务PC，数据包中有约36％左右指向了一个未知的IP地址，其它数据包虽然指向该地址但来源地址比较混乱且无规律可循，协议分析仪上解析的地址经网管人员确认后证实36％的指向地址是票务服务器的IP地址，其它来源地址也是原票务网中地址范围内的地址。如果该PC机携带能模仿IP地址的病毒程序，则原系统有可能还会发生类似故障，所以我们先将账务工作站PC的网卡更换，更换后该机表现正常(说明病毒在捣乱的可能性很小)，不再发送非法帧。将故障网卡重新安装驱动程序，故障现象依旧，集线器上测试的错误仍是长帧和短帧，再次表明网卡本身故障的可能性最大，病毒感染的可能性很小。 
   [诊断评点]现在可以让我们来事后模拟叙述一下整个网络故障的进程。以便读者了解故障的进程和原因。票务网络中的一台不起眼的工作站的网卡发生了故障。最初的故障发生于节日前，故障现象是发送错误帧。由于工作站与桌面交换机相连，而该桌面交换机是存储转发型性交换机，所以发送的错误帧被交换机过滤掉了。所以这些错误帧只能对本工作站造成影响，对网络不构成威胁。随着网卡的进一步物理性损坏，网卡变得不能清除发送过的IP地址，并将目标地址“定格”在访问联系最多的票务服务器，开始发送不受限制的数据包。这些数据包不断请求票务服务器处理重复查询计算同一张票的出票业务。由于其不受发送速度的限制(即该网卡不管网络流量是否超高，都会不加理会地向网络发送流量)，网络中的交换机随即将大量的垃圾包送往票务服务器，占用大量网络带宽资源，同时迫使票务服务器消耗大量资源处理这些垃圾包，使得其它正常的网络访问受阻。还由于这些数据包的可操作性很差，服务器会进一步耗用额外的资源来处理这些数据。上一篇故事中我们曾提到过，网卡故障后有两类基本的表现，一类是安静型，即不再进行正常的网络通信并且不再向网络发送任何数据，这是比较友好的“醉汉”。对网络基本上没有破坏性。另一类是“狂躁型”，发生故障后向网络发送不受限制的数据包。这些数据包可能是正常格式的，也可能是非正常格式的(即错误数据包)。两种格式的数据包都可能对网络性能造成严重影响甚至破坏。错误格式的数据包一般不能通过存储转发型的交换机，所以本故障的网络监测看不到错误数据包，只能看到正常格式的故障数据包。当接入集线器后才可以观察到错误数据包。 
   [诊断建议]该网络由于系统成员数量少，在建网规划时没有配备网管系统和测试工具。所以故障早期没有任何超流量报警信号提示，这对于网络故障的迅速定位和排除是不利的。现存的许多网络在维护工作中都基本上采取事后维护的方法，即出了问题才去查找和处理，这对于可靠性要求高的网络是非常危险的。因为我们不能侥幸地“期盼”不管是网络设备，还是网上设备，他们出了问题以后都表现为“安静型”。只有坚持定期地对网络进行监测才是避免重大网络事故的有力措施。其实在本例中，如果每日坚持用3分钟时间监测一下网络，就完全可以在故障的早期排除之，避免后期重大事故的发生。 
   [后记]我们担心的“病毒”至今没有出现。

[案例三十]服务器、交换机、工作站工作状态不匹配，访问速度慢
　
   [症状]网络建好了，对于系统集成商来说，设备的安装调试一旦完成，一般都要安排一个小小的庆贺仪式。而对于一家承担过十几项大型工程的系统集成商来说，面对一个400个用户的中型网络，设备调试的工作应该不是难事。但是，直接从庆贺仪式的准备现场赶来网络医院“报警”的病人今天还是第一此遇到。
   某著名系统集成商专门负责政府网建设的项目经理罗先生今天十万火急地到网络医院电话急诊，请求紧急支援。原因是下午的“竣工验收”仪式和晚宴已经定好，本工程又是他们公司首次采用六类线电缆系统的样板工程，邀请的十几个重要客人今天下午均会相继“出场”。按原工程计划的进度安排，网络的调试工作用三天时间进行，于前天上午完工。而直到今天上午10:00为止，调试工作因遇到拦路虎，还没有成功通过系统调试。如果今天下午15:00以前不能调试成功，那么请来参观和观摩的客人自不必说，单就企业的声誉来讲，恐怕无可避免地将受到严重影响，且进一步的业务深入也将会受到严重影响。
   罗先生反应的网络故障表现很简单：基本上所有的网络成员访问网络资源的速度都非常缓慢，Ping测试联通性表现良好，均在2ms以内，从服务器上拷贝一个20Mbytes的文件竟需要5分钟。调试人员曾试着从相邻的工作站上拷贝一个20Mbytes，对比结果显示同样也需要5分多种的时间。怀疑是操作系统和系统软件平台安装上的问题，特别是服务器安装上的问题。调试人员已经将所有用户重新安装过两遍，凭借以往安装系统的丰富经验，他们十分有把握地保证操作系统和软件平台安装设置没有问题。为了了解数据包在网络中传输的对话情况，又从朋友哪里借了一台协议分析仪对收发包进行测试，结果显示包的收发反应时间基本正常，只是包的转发时间间隔很长，无法进一步确定是哪个环节的问题所至。网络的公共部分是一台10/100核心交换机和三台服务器，服务器直接与核心交换机相连，其它工作站则通过下属的工作组交换机和集线器等与之相连。起初怀疑是交换机的问题，试着更换了一台同型号的交换机，故障依旧。从主代理哪里借来一台服务器作替换试验也无效。 
   [诊断过程]我们立即随罗先生赶往“事故现场”，10分钟后抵达现场。首先从一台工作站上Ping服务器和任意选定的位子网内其它5台的工作站，响应时间均小于1ms，说明联通性尚可。调试人员怀疑是交换机问题的可能性是存在的，但我们认为证据不足。这是因为从邻近的工作站直接拷贝文件也很慢，这时数据包不经过核心交换机，有的虽通过工作组或桌面交换机，但有的则直接通过集线器。所以故障的公共部位比较可能的是新的布线系统、操作系统和系统软件平台、关键网络设备本身的故障或错误、网卡驱动程序错误等等。用网络测试仪实施流量贯通测试，选择从任意一台工作站到服务器为一条通道，再任意选择该工作站到其它5台工作站直接的通道，共6条测试通道作试验样本。从测试仪上分别发送正常的IP包流量到上述6个对象，流量选定为健康指标的上限值，即40％。用网络一点通在被测试的站点模拟网络设备配合接收流量，结果发现收到的流量都不足1%，且广播包占20％以上。缩短流量贯通路径，直接向邻近的工作站发送流量，结果收到的流量有两种明显的结果。一是流量大量增加，达28%左右，其路径是通过集线器连接的通道，属于正常表现。另一种结果同前面观察到的现象一致，收到约1％左右流量帧。观察收到28％的流量结构，其中92%~98%为碰撞帧，少量FCS帧。由于邻近的工作站是用集线器连接的，发生如此高的碰撞最大的可能性是电缆系统的问题。我们随即测试该六类链路，并任意抽查了其它5条六类线链路，测试全部合格。说明链路的物理联通性是合格的。但因为集线器、交换机等的物理接口是超五类的元件，六类线链路从理论上和厂家的承诺上讲应该与其能兼容。观察用于发送40％流量的网络测试仪自身的流量记录，碰撞率与上面的结果一致，提示该六类线链路可能与10/100M的网络设备阻抗不匹配。如果真是这样的话，那么问题牵涉的范围就比较广泛而且严重了。这是因为这涉及到六类链路与超五类器件的通用性和向下兼容性的问题，而这是六类线电缆厂家承诺和保证的优越性之一：采用五类和超五类设备的网络可以与六类链路任意对接，如果今后需要使用更快速的网络设备，则只要更换支持六类链路的网络设备就可以达到超高速的应用。从网络的表现来看，因为这是首次安装的六类样板链路，并且是在六类链路上挂接超五类端口的网络设备，而网络的表现范围广、现象比较一致：出现大面积内的速度慢故障。协议分析仪解包显示包交换正常，不能证明是网络操作系统和软件平台的问题。所以，安装了影响全局的部分只有六类线布线系统，这也是调试人员重点怀疑的网络部位。我们当然不能由此认定是网络设备端口的问题或是六类线链路与端口不匹配。为了慎重起见，我们用两条超五类线缆连接两台相邻的工作站，再次试验拷贝文件，结果故障依旧。这说明六类线系统不是真正的故障原因。剩下的问题就是需要确认工作站工作协议、配置、驱动程序、物理参数是否与网络匹配了。方法很简单，将在线型网络万用表串入工作站和网络端口(我们分别选择了一个集线器和一台交换机的端口)。结果显示如下：一台工作站的工作速度为100M，端口设置为全双工，而对应的集线器设置为100M半双工；另一台工作站工作速度为100M，端口设置为半双工，对应的交换机设置为半双工。罗先生告知，网络中的网卡使用了三家公司的产品，都是非常知名的厂商。A公司的产品占90％，其余则为B公司的产品，另外，服务器使用的是服务器厂商C公司自己的网卡。我们抽测了A公司的10张网卡，用网络万用表测试，显示设置全部是全双工；而抽测的5张B公司的网卡则全部是半双工设置。我们选择相邻的两台安装了B公司网卡的工作站拷贝文件，结果发现拷贝速度非常快，约3秒钟。接下来我们把两台安装有A公司网卡的相邻工作站改为半双工状态，20Mbytes文件拷贝时间也是3秒钟。
选择被试工作站到服务器的通道，它们通过一台集线器，两台交换机后到达服务器。依次测试链路中的速度和工作状态，结果发现服务器网卡也是全双工设置状态。更改以后试验从服务器上拷贝一个100Mbytes的文件，耗时约13秒。说明性能比较优良。 
   [诊断评点]故障的原因已经很清楚，该系统集成商选用了三家公司的网卡，而其中的A公司网卡被全部设置为全双工状态，服务器也被偶然地设置为全双工状态。但系统中的交换机、集线器等都工作在半双工状态，所以，凡事安装有A公司网卡的工作站工作速度都很长慢。其它安装了B公司网卡的工作站，虽然自身设置是正确的，但由于数量少，只站不足10％，加之服务器也被设置为全双工状态，所以调试时很可能与A公司或C公司的网卡进行数据对接，这样速度就无法正常。如果偶然地与同类B公司网卡进行数据交换，则调试人员有机会发现虽然所有的工作站与服务器连接速度慢，但并不是所有的工作站之间直接联络时的速度都慢。不过，因为A工商产品数量居多，服务器设置又不正常，所以这样的机会不多。
   网卡的协议设置和工作设置会直接影响工作站的速度。一般来讲，工作站的协议设置多数时候不容易出错，但是否与网络的工作协议一致则有时会弄混。比如，工作站使用SMTP协议收发邮件，而网络的邮件服务器使用的是POP协议收发邮件，则工作站将无法进行邮件收发操作。比较容易出错的是10/100M设置状态、全双工半双工设置状态、链路数字脉冲极性选择等，这些方面的错误由于网络维护人员和安装调试人员的有意无意地疏忽，加上没有合适的检测方法和工具，往往会给系统集成商造成很大的麻烦，而故障原因却是如此地简单。很多时候调试人员使用默认设置，并不经常验证实际的状态如何。
   本故障的诊断走了一些弯路。因为是新安装的六类线系统，使得故障诊断时有意地倾向于首先怀疑是否是此新系统与100M超五类系统(实际上，超五类系统是为1000M以太网准备的)不匹配方面的问题。如果首先在相邻工作站与交换机或集线器之间检查链路工作状态的检查，则可以在10分钟内找到问题。本故障实际耗时约100分钟，赶在13:00以前收工。
   罗先生紧急动员所有调试人员立即检查并调整全部的A公司网卡，只用了不到一个小时就将全部设置改为了半双工状态。 
   [诊断建议]网络维护人员和部分安装调试人员往往错误地认为网络的维护和管理就是去管理服务器、工作站、打印机等网上设备。这是片面和有害的。其实网络维护人员真正需要下功夫维护和管理的地方是网络设备而不是网上设备。网络设备通常是指路由器、网关、桥、交换机、集线器、广域传输设备、电缆光缆等等。这些是被许多网络维护人员和部分安装调试人员忽视的地方。有的则是因所学专业的限制有意无意地忽视之，特别是对光电参数的验证和测试更是如此。 
   [后记]15:00正式的验收仪式顺利开始，验收工作非常顺利，在此不表。 
[案例三十一]交换机设置不良，加之雏菊链效应和接头问题，100M升级失败
　
   [症状]某化工交易中心华东公司，今日报告网络从10M升级到100M后，约有一半的工作站无法提速，他们都在同一个楼层。另一楼层的5台工作站则无法入网。另外，两个楼层中都有少数工作站工作速度比升级前更慢，而且并不是对所有的服务器或其它工作站访问都慢，对少数服务器的访问速度还“凑合”。该公司没有配备任何用于网络维护的工具，所以，除了可以观察服务器的CPU利用率以外，只能用软件间接观察网络的流量和碰撞率。观察到的碰撞率偏高的微网段可以达到20％，但不知道该如何处理。据负责网络管理的Lucy小姐介绍，网络升级前所有工作站都是可以接入网络中运行的，只是部分站点速度有些问题，但可以用。公司的网络规模不大，共占有两层半楼面，拥有280台工作站，计算机室配置了三台工作组交换机，分别为三层楼面提供连接。三台交换机通过一台100M集线器共享。路由器一台，也通过工作组交换机连接帧中继网络。交换机下面通过级联100M集线器构成星型结构将链路接口连接到用户桌面。升级工程很简单，将10M交换机更换为100M交换机，10M集线器更换为100M集线器即算大公告成，机架上的设备布局基本按原样安装。用户端则全部更换为100M网卡，施工时间是利用周六、周日两天非业务时间，将全部用户都“搞定”，全部作业都有公司自己的员工负责。完工后抽查了部分工作站，工作状况良好，由此认定升级工程验收合格。可是周一上班，麻烦随之而来。 
   [诊断过程]该网络的结构比较简单随意，集中反映出的“病症”有三种：一是部分站点不能上网，二是部分站点速度变慢，三是有一半站点不能提速到期望的100M速度。这些其实都是网络升级时经常遇到的问题，也是比较典型的“网络升级症”。
我们将F683网络测试仪首先接入不能上网的站点所在的微网段，观察网络的工作情况。网络搜索的结果显示无法发现这几台工作站，但“Ping”测试却偶尔能有反映。一般来讲，出现此类“病症”的原因基本上是工作站和网络之间的匹配有问题，比如协议不匹配(一致)，驱动程序不匹配，网卡速度不匹配，Link脉冲极性不匹配，链路的接口物理参数不匹配，电缆、光缆规格不匹配(如使用了三类线等)，测试的方法比较简单，可以直接用网络测试仪、网络故障一点通、网络万用表自身具备的接口测试功能直接对网卡、集线器、电缆等进行测试。对5台工作站的网卡逐个进行测试，结果如下：网卡为自适应卡，工作速度10M，交换机端口为100M固定速度半双工设置，双方选用的协议完全匹配，物理电参数测试合格。因而进一步对从配线间到用户之间的电缆链路进行测试，结果发现5台工作站使用的电缆接头均为三类线接头。更换水晶头后用五类线标准测试均合格，5台工作站全部上网成功且速度很快。
   用网络测试仪对不能提速的工作站进行测试，当网络测试仪模拟工作站发送5M流量时，用网络故障一点通接收之，显示收到的流量为5Mbps；而当网络测试仪从集线器近旁模拟50M流量发送数据帧时，收到的流量指示仅为10Mbps。这说明，网络只能以10M的实际工作速度运行，不能提速到升级工程实施前所预期的100Mbps的速度。重复上述类似的对网络和工作站的匹配性测试，结果如下：交换机设置为10/100M自适应状态；协议测试显示完全匹配；物理电参数测试全部合格。因此怀疑仍然是链路接头的问题。抽查了10条链路，用DSP4000电缆分析仪进行现场认证测试，结果显示全部链路都不合格。按下电缆分析仪的故障诊断信息健，指示链路的两个接头均不合格。我们注意到这些故障链路都在同一楼层。改用三类线标准测试链路，合格。这说明，该楼层的链路所使用的水晶头问题普遍比较严重。
   继续对升级后速度比升级前的部分工作站进行监测，发现他们的流量为1.0％，而碰撞率为87％左右，另有12％左右的FCS帧错误。网络测试仪接入模拟工作站后仪器上的蓝色指示灯亮，说明工作状态是100Mbps。查看Lucy小姐提供网络结构拓扑图，发现速度变慢的用户共有4组17个工作站，他们的100M集线器级联数均达到了4个，出现所谓的雏菊链效应，影响网络的正常工作。碰撞数据尤其是延迟碰撞和FCS错误帧将大量出现。 
   [诊断评点]该网络出现的问题比较典型，许多网络在升级都会碰到类似的问题。首先，不少交换机产品是10/100M自适应的，交换机可以自动监测网络能够提供的工作速度，然后确定实际的工作速度和工作模式。比如，某些只能交换机现监测接口的链路脉冲，确定链路的连接速度，然后检测接口处的错误率，如果错误率低，则交换机工作在快速的“切发行”交换模式；如果错误率超过门限值，则交换机工作在速度稍慢的“存储转发型”工作模式。另外，一些交换机还允许用户手动设置端口的速度，以固定的速度模式访问网络。
   前5台工作站不能上网原因是，工作站链路因使用了假冒伪劣的五类接头(实际指标是三类接头)，工作站只能自适应为10M链路速度，但因该楼层的工作组交换机被手动设置为100M接口状态，所以接口速度无法适应，工作站不能上网连接。
   其它不能提速的工作站都在另一台工作组交换机连接的另一楼层，由于交换机没有设置为手动状态，其自适应的结果就是因假冒伪劣插头的限制链路速度被“适应”在了10Mbps的工作速度。部分升级后速度更慢的用户原因在于雏菊链效应的影响。我们知道，10M以太网允许最多4个集线器级联，而100Mbps以太网之允许2个集线器级联。集线器一般不具备自适应能力，所以升级后很容易出现雏菊链效应。此时网络中会时限大量的延迟碰撞以及由此而生成的FCS帧校验序列错误出现，工作站在发送数据帧时常因无法发送完整无错的帧而被迫多次重复发送。除了占用带宽就是增大了有效数据帧的等效延迟时间，表现为用户的速度很可能比升级前更慢。另一些用户则表现为虽然速度有所提高但仍达不道预期的速度。 
   [诊断建议]建议用户将布线系统进行全面测试，对交换机进行设置，清理有可能出现的雏菊链效应结构，对实在有困难的集线器组则可以考虑增加交换机数量，以便分割和缩短雏菊链。 
   [后记]两周后随访用户，他们已经全部将不合格的水晶头更换。测试结果显示电缆系统都合格，知道庆幸。由于当初在工程施工时为了抢进度，各楼层的布线工程是由三家不同的工程商同时进行的施工。其中一层全部采用的是假冒伪劣的水晶头，另两层除了5台链路误用不合格水晶头外(具体原因已经无从查起)，全部使用的是合格产品。对雏菊链拓扑的检查共发现7组集线器有“嫌疑”，按照我们的建议，增加了4台工作组交换机，用于分割雏菊链。网络现在工作良好。

[案例三十二]交换机端口低效，不能全部识别数据包，访问速度慢
　
   [症状]某大型化工股份有限公司信息中心主任洪先生向网络医院报告网络故障，新近进行网络的更新升级和扩容，由10M网全部提升为100M以太网，核心交换机为千兆以太网。完工后系统试机时发现，大部分的网络成员感觉速度慢，有时数据出错，但子网段内拷贝数据速度基本不受影响。Ping测试检查所有工作站和服务器均正常。遵照网络医院上周的建议他们对网络布线系统进行严格认证测试，布线施工质量优良，全部电缆光缆链路按超五类标准测试参数均合格，没有发现任何问题。由于信息中心除了电缆和光缆的认证测试仪外，没有其它测试维护工具，无法对网络进行评测。虽然仔细进行了网络系统及平台的重新安装，仍无济于事。由于总公司希望全面提高ERP系统的覆盖范围，新增的网络设备比较多，网上成员也增加了二倍多，工作站从原来的220台猛增至680台，办公区和生产区之间、生产区和生产区之间均用光缆和路由器连接起来，因此洪主任抱怨现在网络的管理成了问题，查找故障不象从前那样容易了，一来网络规模比以前大多了，故障数量和种类增多，二来网络结构变得比以前复杂多了，故障的定位分析和隔离变得比较困难。
   该网络各子网段基本上采用核心交换机和工作组交换机作网络骨架，用桌面交换机和集线器混用的方式构成基层用户接入平台，核心交换机之间为千兆以太网连接，用户全部为100M到桌面。为了便于维护和管理，同时也从安全角度考虑，设计方案中将大多数数据服务器均安装在了网管中心。 
   [诊断过程]网络为新扩容的网络，从拓扑图上看不出网络结构设计有何不合理之处。由于在各子网段内拷贝数据时速度基本不受影响，所以分析数据多在跨网段时受阻。将网络测试仪接入办公区网络的网管中心，打开网段内的全部4个路由器的端口观察，网段间的流量为27％～42％之间，由于网络没有多媒体应用启用，因此如此高的流量记录是不正常的。我们需要观察这些流量的走向，于是在办公区将网络测试仪串入路由器与交换机之间(100M端口)监测，启动IP矩阵监测和以太网MAC矩阵监测功能，观察数据流向。结果如下，大部分的数据流向均指向办公区的WINS服务器，而WINS响应流量极少。查看拓扑图，该WINS服务器直接与一台工作组交换机相连，打开工作组交换机的端口记录检查，流量记录为13％，伴随少许碰撞指示记录。为了不影响用户的使用，下班后我们从测试仪所在端口向WINS服务器所在交换机端口P32的邻近端口P31发送高额流量，选值为90Mbps流量冲击，并在此邻近端口P31观察接收到的流量记录，记录显示为89.7Mbps，这说明端口P31的通道测试是合格的。然后对准WINS服务器所在端口P32发送90Mpbs的高额流量，观察P32端口流量冲击记录，结果显示为13.5％，并出现大量延迟帧，表明该端口通道测试不合格。将流量发送方向指向与该端口连接的上游端口P17，观察P17流量显示为90Mbps。问题很清楚，被丢弃和延迟的流量就在P32口。对WINS本身作WINS查询，10次测试响应只有2次，响应地址正确，响应率20％。重新测试WINS链路电缆，合格。测试WINS服务器网卡，合格；测试交换机的端口P32，低效。在此临时将WINS服务器端口P32改接到端口P33，重新启动系统，5分钟后进行上述测试，全部合格。为了验证P32口低效，用网络测试仪接入该端口并向P17发送90M流量，收到流量为12%。由于这台工作组交换机为新品，尚在保用期之内，因此建议立即更换之。 
   [诊断评点]网络中的大多数数据服务器由于设置在办公区的网管中心，所以公司整个系统的工作依赖集中式系统中的这些专用数据服务器，链路连接和数据交换时需要WINS服务器提供服务。与WINS服务器连接的链路中，交换机一侧的端口P32发射能力低效，使得发送的信号幅度不符合要求，由于链路长度不长，所以并不是对所有的数据包WINS服务器都无响应。有些数据被作为部分错误和碰撞数据由端口记录之，大部分从交换机各端口送往P32端口的的数据因链路接口问题被延迟和丢弃，造成记录数据中有用流量正常，而网络用户速度普遍偏慢的假象。交换机、网卡、集线器和路由器等网络设备的端口一般从工作2～3年开始出现低效现象，5年比例为3％～18％(这取决于不同的厂商产品质量，也取决于同一厂商的不同系列产品的产品质量)。由于系统中有大量的端口，所以在网络维护周期建议中要求每半年对端口性能进行定期测试。每一～二年对布线系统进行一次轮测，尤其对重要的网络设备如服务器、交换机、路由器等应该坚持定期测试，这样做对提高网络的可靠性有莫大的帮助。 
   [诊断建议]建议“病人”所有网络设备进行一次普查，将全部端口都进行备案测试，并列入定期维护的内容之一。 
   [后记]第二洪先生告之，上班后所有网络用户都惊喜地发现，网络速度比之以前有了惊人的表现，速度真正大幅提高，皆大欢喜。

本文转自：http://bbs.51cto.com/thread-527349-1.html