【吐血推荐】网络医院的故事----连载3，共35篇(ZT)

Away

[故事之十八]中心DNS服务器主板“失常”，占用带宽资源并攻击其它子网的服务器
[症状]有“病人”来电报告网络的一个子网突然变慢，中心主网络则基本正常。以下是“病人”的主述“症状”：“病人”是某市电信多媒体网络服务企业(163、169)，该市为地级市，为本市及市辖县的普通用户提供本地热线网站服务和Internet接入服务。昨天，先是其服务的用户反映网络速度很慢，Email需要等待超过60秒以上的时间才能联通，随即其市营业厅(即子网所在地)报告速度突然变慢，影响业务。“病人”在主机房安装有网管系统，网管人员从网管系统上观察发现除了营业厅子网路由器流量很高以外(测试为97％)，中心网络的路由器与其它子网的交互流量均为40％以下。没有其它特别现象，应该说网络速度不会受影响。由于维护人员没有配备其它网络测试工具，又不能在白天断开网络停止用户服务来进行检查。经人先容遂请网络医院派员帮助检查。

[诊断过程]这个故障表现比较简单，检查的时候只要查出子网的路由通道流量来源就可以很快确定故障方向，进一步则马上可以查出流量源。由于用户没有配备分析网络流量的工具，大家估计故障在子网的可能性较大，所以直接驱车驶向子网所在地，即电信营业厅。从总网络拓扑图上看，营业厅子网与中心网络的链路为E1，是营业厅网络的业务通道。由于该通道一般只用于传输一些业务数据，其子网的网站数量只有45台，所以断定网管报告97％的流量肯定是过高了。有一种情况可以比较多地占用E1通道的有效流量，那就是营业厅子网内有站点与中心网络的站点或服务器之间存在多媒体动态图象传输应用，比如VOD等。这种情况在不少地方时有发生，但它要求必须有动态图象源才可以实施“点播”，而中心网络的所有服务器目前不提供这种宽带视频服务(当然，大家不排除存在系统管理员私自安装的可能性)。
营业厅网络由于规模小，中心网络的网管系统只支撑到路由器一级的管理。营业厅子网的交换机和服务器等采用的是低价的桌面交换机，所以无法支撑网络管理。大家将网络测试仪F683接入交换机进行测试，启动便携网管功能，可以看到路由器的流量和网管系统观测的到的流量是相同的，均为97％左右。查看中心网络与此相连的路由器通道流量，也是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监测中“重定向”数据包Redirect占82％，“目标不可达”数据包Destination Unreachable 数量占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服务器的工作平台和应用App以及网卡驱动程序全部重新安装一遍，然后选择深夜用户数量最少的时候接入网络使用，查看转换表是否正常；其次，如果仍然不正常，则更换网卡，主板等硬件，逐步缩小故障范围。

[诊断建议]为了防止DNS服务不稳定造成业务中断或出错，不少网管人员在设置DNS服务器时都安装了备用DNS服务器，亦即安装不只一台DNS服务器。但这样做也会带来一个潜在的危险：即主DNS服务器出问题，备用DNS服务器自动投入运行，这样会牺牲一定的网络带宽，使得系统总体性能有所下降。危险在于，性能的下降常常是在不知不觉中来到的。所以，为了保证网络经常处于良好的工作状态，网络管理人员需要定期检查DNS服务器的转换表。这也是“周维护”(即每周定期维护项目)中建议的内容之一(当然，要保持网络的优良性能不只是要检查路由优化性能，还有其它许许多多工作需要做。比如：性能评测、基准测试、通道测试、应用监测、拓扑结构的有效管理、定期维护等等，有关这方面内容读者如感兴趣可参阅《网络测试技术概况》)。本故障中的DNS指向错误导致用户的IP数据包对准了子网中的一台服务器，由于子网通道窄引发“速度问题”。如果对准的不是子网服务器而是中心网络本地网段中的某台机器，则故障强度会减弱，用户不会感到非常明显的速度变慢(主网均为100BaseT链路)。这样，“病人”可能不会感到明显的“身体不适”从而使得网络长期带病运行。就象人一样，定期的体检对及时发现疾病及其隐患是非常必要的。而如何及时发现路由优化方面的问题，也是网络定期项目测试中的内容之一，对大型网络则更有必要，必须坚持定期维护和测试。
许多网络设备如路由器、交换机、智能集线器等都支撑SNMP网管功能，但为了全面监测网络通道功能，还需要网络设备支撑全面的RMON和RMON2。用这样的设备组建起来的网络其管理和故障诊断功能是很不错的。但现实的问题是，这样的网络设备价格是普通网络设备的6～10倍左右，用户难以接受。因此，为了随时监测网络的服务应用流量及其比例、来源、工作记录以及必要时进行解包分析，建议用户在重要的服务器通道、核心交换通道或路由通道上安装监测接口。以便必要时可以随时将流量分析仪、网络测试仪等接入通道进行监测和分析。如此，本故障的查找时间可以缩短到20分钟左右。当然，如果资金允许，也可以将流量分析仪长期接入通道对多个重要的网络设备进行全速率透明流量监测，这样甚至可以把故障定位时间缩短到1分钟以内。

[故事之十九]电梯动力线干扰，占用带宽，整个楼层速度降低
[症状]某大型家电制造企业计算机中心主任，今天极其沮丧地了报告了该企业的一起顽固的网络故障。该故障表现虽奇特但比较有规律，具体表现是：企业主办公楼的网络在员工上班的时候运行速度会变得很慢，下班后速度回升，有时基本上能回复到往常水平。故障时间大约三个月，准确“发病”的日期已无从记起。每天上午8:00左右开始发作，症状范围是三楼的整个楼层，现象是速度突然变慢，无论是从互联网上下载文件、收发电子邮件都很慢且经常中断和出错。本楼层中的用户之间在传输文件时、与其它楼层的用户传送文件时或是其它楼层的用户与本楼层的用户交换文件时都要用很长时间，但其它楼层的用户之间互相交换文件则不受影响。第一此发作，故障一直持续了三天大家也没有查明原因。由于三楼是企业设计开发部门，每日都要使用网络环境进行大量的数据交换、资料查询等工作，为了不影响新产品开发进度，当时将研发部的工作时间暂时推迟到下午6:00上班。两周后情况仍未见好转，故障仍然存在。不得以企业决定将研发部与二楼的行政管理部门临时对调，以保证已经开始习惯于上“夜班”研发部员工正常的作息时间。谁知一“临时”就是三个月之久。网管人员将布线系统、网络平台、所有主机和服务器、路由器都彻底检查或互换过，一直未能查出故障琐在。听某知名系统集成商先容可能是电缆系统的问题，随即将布线系统进行了一次认证测试。结果还真的查出了不少严重问题。比如，原来的5类线系统全部不合格，系采用假冒伪劣的5类线，现场测试只能通过三类线指标。为正宗的“假货”。接插件和模块也大部分不能通过5类线标准测试。进一步对整个大楼的布线进行检查，发现与三楼的情况相同。企业网络基本上还是10Mbps系统，工作一直正常。由于布线工程是三年前做的，现在已经无法联系上当时的系统集成商。企业董事会责成计算机中心将整个布线系统全部更新。经过一个月的紧张施工，工程于前天结束，满心希翼通过这次工程能将原有的故障及隐患彻底清理干净，谁曾想，昨天开机调试系统时发现原来的故障依然“顽强”地存在！虽想尽了办法，面对大家的艰苦努力，第三楼层的网络系统仍“无动于衷”。计算机中心的全体员工均感倍受打击，且愧于无法向研发部的员工和董事会“交差”。

[诊断过程] 根据以往的统计，越是顽固的故障对“网络医院”来说往往越可能是最简单的“病因”引起的。从“病人”“主述”的情况看，布线系统还存在问题的可能性不大。由于网络的设备都经过多次的检查，发生问题的概率应该是比较低的。如果说是网络有关平台安装、应用App安装和使用以及路由通道等方面的有问题，那么其它楼层的用户应该有类似的问题。分析故障出现的特点，由于故障出现的时间是上班时间，所以故障原因应该与某些定时工作的设备或工作环境有很大关联性。故障造成整个楼层速度受影响，为公共部分故障的概率较高。根据计算机中心主任先容，包括其它楼层在内的每台设备都进行过逐个关机筛选检查，每台供电设备都进行过替代检查，所以可以保证设备都是正常且合格的。
分析网络的拓扑结构，每个楼层都是用集线器搭建的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管内。本来，有一次机会可以解决故障，那就是如果在这次网络更新工程时能严格地按标准化施工，那么这根电源线将会被分开安装，更新后的网络便可能正常运行。另外，由于有多根网线同时受到干扰，所以在采用“二分法”分割故障区域时只能得出干扰与设备数量有关系这一模糊结论，此非但不能有助于定位真正的故障部位，反而可能将故障诊断工作复杂化。

[诊断建议]标准化设计、标准化施工、标准化验收(认证测试)是保证网络工程质量的重要手段和方法。其中一条就是要求动力线和计算机网络布线系统必须分开走线。如果采用金属穿管的方法近距离屏蔽，则金属管必须要有良好的接地措施。否则极易获得“得不偿失”的回报。
测试统计显示，现阶段并不是所有动力线谐波含量都很大，多数动力线谐波含量还是很小的。但用电环境的变化趋势是非线性用电设备的用量越来越多，谐波污染也会越来越严重，且呈加速趋势。为了避免后患，还是少存侥幸心理为妙。

[故事之二十]网络黑客程序激活，内部服务器攻击路由器，封闭网络
[症状]某大型连锁超市集团计算机中心中心IT经理钟小姐，今天上午向网络医院报告网络出现严重故障。其中心网络的局域网速度很慢，与各地连锁店管理中心的资金结算和物流调配速度更慢。故障开始出现于两周前，先是感觉网络运行速度有明显下降，而后病情一天天加重，直至今天基本上处于近似瘫痪状态。内部数据调用需要3分钟(以前只需要3秒钟)，与其它连锁管理中心之间每笔业务结算和物流配送出入栈登记都要花费差不多2分钟时间(以前只需要最多5秒钟)。造成大量货物配送无法履行相关手续，部分连锁店被迫采用手工记帐接受货物配送，大多数连锁店则减慢了货物配送的进程，超市货架已有不少断档供应，人手紧张。
钟小姐先容，由于货物配送出入栈登记和结算中心设在中心网络，所以他们的网络维护人员最先对中心网络实行紧急抢修程序。Ping测试所有重要的服务器、路由器、外地路由器、外地服务器，结果都在15ms以内。说明联通性还基本良好。关闭中心网络系统，暂时停止业务，再重新启动运行。刚开始速度还比较快，但很快就在10分钟内迅速下降至病态水平。全部启动5台备用服务器，顶替原服务器当中的5台投入运行，网络速度有明显提高。不过好景不长，约2小时后，从网管系统观察，服务器流量比平常高，路由器流量基本满负荷。关闭一半的服务器和站点，网络速度有所提高，似乎网络流量与站点数量有关联，所以无法定位网络故障的准确地点。于是怀疑是否是有“病毒”在做崇，将所有站点和服务器用多种查杀毒App杀毒，启动系统后故障依然如故。

[诊断过程]故障地点可能就在中心网络，但也不排除受其它远程网络影响的可能。所以从网络医院出来大家决定先前往该超市集团总部的计算机中心网络所在地。30分钟后大家抵达了目的地。大家将F68X网络测试仪接入中心网络交换机进行观察，逐个观察核心交换机和工作组交换机每个端口的Mib代理，发现除了端口流量偏高外，网络一切正常。不过，也发现一个奇怪的现象，那就是各端口的流量都基本相同，为50％～60％左右；询问钟小姐有无以前的基准测试记录和近期的网络健康测试记录，回答是没有。本网络自半年前建成以来一直工作优良，偶尔出点小毛病网管人员很快就能解决，所以除了机器档案和网络结构拓扑图外，再没有其它网络维护的文档。
可以肯定的是，如此高的网络流量必定意味着某种故障的存在。大家此时需要确认2点：一是网络平时主要的工作协议是哪些，二是这些流量是否是正常工作所需的流量。而这些数据都是该网络现在无法提供的。为此大家将F69X流量分析仪接入全部8个服务器和交换机之间，观察网络主干流量的应用流量分布。结果如下：各服务器均接受大约50％流量的cc:mail数据包，其它按服务器编号依次是Oracle应用占3％，HTTP应用占2％，MS-SQL server应用占1％，DNS应用占1％，Oracle应用占0.5％，Informix应用占0.1％，FTP应用占0.7％。可见影响网络流量的主要是cc:mail应用。
观察cc:mail数据包的对话情况，基本上中心网络内的站点和服务器都有记录，并且有通过路由向外发送的数据包，这也就是说，中心网络的每个成员都在向该局域网内的所有成员发送邮件数据包cc:mail ！问题是，这些邮件数据包是如何进入各服务器和工作站的。大家同网管人员一起回顾了一下病情发作过程，今天是1月13日，故障是2周前出现的，也就是2000年元旦前几天开始发病的。大家请大家一起帮助回忆是否在网络上运行过非法App，包括贺卡之类电子的邮件。钟小姐回忆当时曾发现网管人员互相传阅过一个很有趣的电子圣诞卡，钟小姐本人也很喜欢这张贺卡，但出于职责和管理制度的规定还是制止了。会不会是这张卡在“作怪”呢？
大家选择3台主服务器和10台站点作格式化硬盘并重新安装系统，将备份数据还原到服务器中，此时只允许远程连锁管理中心与计算机中心的3台服务器进行业务数据传递和计算。其它服务器和工作站则暂时关机。启动系统进行正常操作，同时监测交换机相应端口的流量，均小于4％。网络一直工作正常。这说明格式化以后的服务器不再运行cc:mail应用程序。坚持到晚上22:00所有连锁店打佯，启动未曾格式化的服务器和工作站，并请下辖11个远程连锁管理中心网管人员配合模拟进行网络业务操作，约10分钟后，端口流量开始迅速上升。从流量分析仪上观察到的现象是：非法的cc:mail应用流量首先从6号服务器，然后紧接着从17号、42号、31号工作站和其它服务器陆续出现。在出现cc:mail应用流量以前均有FTP协议应用流量出现。检查这几台机器均安装运行过贺卡程序“My World Is In Fever”。
现在，大家可以得出初步的诊断结论了：首先，非法的网络应用可能从贺卡开始，然后在数据交换的时候“Fever”程序自行展开成为黑客程序，对准所有有过数据交换的站点发送cc:mail应用数据。由于该程序具有传染性，很快局域网内的所有站点都会感染上此黑客程序并依次发作。由于应用流量设计不是很高，所以发作过程相对较长，每个交换机端口通过的流量也基本对等，表现为50％左右。将捕获的数据包进行解码分析，邮件为单向传输，无回应。内容循环显示为：
“My world is in fever ,I love you”
停止网络运行，将所有网络设备断电(包括路由器)，并将所有服务器和工作站格式化，将人员分组，重新安装系统和应用程序，恢复备份数据，经过近4小时的紧张工作，于次日7时重新启动网络运行。至中午12:00监测的数据流量端口小于5％，服务器小于4％。

[诊断评点]网络应用中的危险因素很多，为了净化网络环境，最起码的要求是不允许在专用网络上运行任何非法程序和盗版App。本故障由于网管人员私自运行了携带黑客程序的App，导致网络遭受高流量冲击，几乎近于瘫痪。本黑客程序的发作机理比较隐蔽，先逐个感染局域网内的服务器或工作站，然后逐渐在有数据应用时展开程序进行流量争用，使得网络流量逐渐增高。路由器采用的是DDN和部分ISDN链路，因瓶颈效应的存在更容易被堵塞。所以网络速度表现为局域网速度变慢而广域链路则更慢。由于网络流量分布比较均衡，所以当网管流量报警门限设置比较宽松时，网管系统将不会出现报警信号(该网管没有进行报警门限设置)。而此时网络的总体流量负荷却已经接近于极限值，路由通道更是拥挤不堪。

[诊断建议]基准测试是网络定期测试的项目之一，坚持基准测试可以帮助网络维护和管理人员掌握网络的变化趋势和故障出现的方向和规律。比如，基准测试数据显示网络平时的平均流量小于6％，网络工作协议共有15种，那么当流量出现超过6％时就能引起网管人员的注意并即时监测其变化，核对工作协议以确定是否有非法协议运行。以“此案”为例，网络合法的工作协议中并没有cc:mail协议，而此时出现了这种协议，网管人员就必须马上对其进行清理。比照网络基准测试的文档备案资料，本故障本可以马上得到纠正；另外，流量管理是网络管理进行到高级阶段时必须实施的监测和管理手段，对于监测网络应用、跟踪黑客、净化网络协议、查找网络疑难故障、先容网络运行费用、优化网络结构等都有着非常大的帮助。最后，从预防网络故障的角度出发，加强内部管理，加强用户教育的工作要始终认真坚持并严格实行。

[故事之二一]“水漫金山”，始发现用错光纤接头类型，网络不能联通
[症状]某新落成的甲级办公大厦，按智能大厦标准设计，其中的计算机综合布线系统包括用超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)可以直接从仪器的屏幕上观察到回波曲线的不连续状态，有经验的测试者一般可以马上判定是链路混用的问题。

[诊断建议]首先，尽快更换误用的单模接头。第二，根据标准化施工施工和验收要求对所有光纤链路都要进行双向测试。第三，大家发现该大厦的设计图纸上无光纤链路的衰减量计算值标注，只标注了光纤的设计长度。由于实测的光纤衰减量无论是表现正常的链路或是不正常的链路其结果都比设计值偏高，估计存在使用劣质光纤和劣质接头的情况，且不排除用多段零碎光纤拼接链路的可能性。所以建议业主要求集成商检查所有实际的接头和熔接头数量。

[故事之二十二]网卡故障，用户变“狂人”，网络运行速度变慢

[症状]今天的病人是某大型寻呼企业，刚更新了高速寻呼设备，增加了信息服务的业务内容，并对计算机网络进行了比较大的扩容和调整。调试工程一直比较顺利，但好景不长，刚正式开通工作一天就出现严重问题。技术中心严经理报告的故障现象如下：最初是在工作台上偶尔观察到在键入寻呼的用户数据时键盘更新出现等待现象，后来愈来愈严重，从刚开始的一秒钟左右到现在的10秒钟以上。网络服务速度很快就变得非常缓慢，寻呼业务员在操作台上键入数据时，屏幕显示有时甚至要等待1分钟以上才会更新。基本上在10秒钟和1分钟之间波动。在业务高峰时处理寻呼的速度赶不上要求，用户排队现象严重。设备管理人员查看过集线器、交换机，发现他们的指示灯一直闪烁不停，好象比以前印象中的快了不少，怀疑网络流量可能很高。用App查看主服务器的CPU资源利用率，达到93％。查看了5个工作台上的计算机CPU，显示资源利用率85％以上。时逢4月26日，怀疑是不是有病毒在做崇。用了三种杀毒App先后进行扫毒，之后发现故障现象依旧。由于寻呼中心机房没有配备网络维护的硬件工具，工程承包商对此现象更是手足无措，故向网络医院挂急诊求治。

[诊断过程]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％。这样，网络上的站点处理本机应用程序的速度会受较大影响。有趣的是，很多用户也是在把机器从网络上退出时才发现站点的故障与网络有关。而之前却一直以为是工作站的问题，且最容易被误判为病毒发作。许多网管和网络维护人员通常的做法和遭遇都会象下面所描述的“故事”：首先，启用多种杀毒App进行查杀毒操作，无效。然后，把所有工作站格式化，重新安装其操作系统和应用App。但由于问题出在服务器，所以仍然不见效。最后，不得不将所有机器(当然也包括服务器)格式化以后重新安装系统平台及应用App。如果是服务器网卡驱动程序安装错误(比如安装的驱动程序版本不符合，虽然能工作但不顺畅)，则故事可能因重新安装了正确的驱动程序而到此结束。如果是网卡“狂躁型”故障，则故事还会延续很长时间。因为“狂躁型”病人不理会网络的游戏规则而向网络发送大量非法帧流量，占用带宽，影响所有网络成员。
不幸的是，狂躁型病人在网络故障统计中所占的比例不是很低！

[诊断建议] “网络健康测试”和“网络基准测试”都是为了实时和长时间监测网络流量的变化规律，帮助维护人员掌握网络应用和流量变化的规律，即时发现和处理网络故障。“网络维护方案”中建议健康测试是每日必须测试的内容，要求实时监测网络的流量/利用率、碰撞、广播、错误等基本健康参数，也可以简化监测程序，选择在每天网络最繁忙的一段时间进行测试。这样网络的异常可以被马上发现(因为许多网络故障在网络流量低、比较清闲时并不表现或明显地表现出来)。当然，比较稳妥的方法是对网络进行认证测试。除了布线系统外还对工作的网络进行认证测试。以便在网络投入正常运行前就发现并根除网络存在的故障和潜在的性能问题，最大程度地优化网络的性能。

[故事之二十三]PC机网卡故障，攻击服务器，速度下降

[症状]今天是五一节假期的最后一天，某大型铁路枢纽站来电，报告其售票系统出现很大问题，最先是枢纽所在局本地的售票系统报告售票速度比平时慢几倍，车站售票厅前已经排起了长队，乘客意见很大。其它市内预售处也受到影响，出票速度也很慢。随后，是各联网局均有报告网络的票务查询速度慢，邻近局报告更频繁一些。维护人员认为是中心票务服务器有问题，随即决定系统暂停业务并将备份服务器很快启动投入系统运行，非但未能见效，反而速度更加缓慢。急招该系统的工程集成商立即处理系统问题，观察中心票务服务器CPU资源利用率达到了97％，基本上是满负荷运行，其它服务器和工作站等网上设备均为发现问题。短时间断开预售点和其它路局的连接路由，故障现象依旧。系统集成商随即将票务中心机房内的其它网络设备如交换机、集线器、网关等全部更换，启动系统故障依旧。故障累计已经近7小时，路局承受的压力越来越大，已经开始准备紧急启动本地人工售票预案。

[诊断过程]网络医院接报后马上赶往票务中心计算机网络的机房，网管人员告知在节日期间已经出现过类似的现象，只是持续的时间不很长(有时会持续2小时左右)，速度虽有变慢，但基本上不影响出票速度。经过与网关人员和系统集成商的工程技术人员简单交流后，分析故障原因可能有五，一是票务结算App问题；二是病毒或内部人员尤其是网络管理人员误操作或更改设置，比如删除不应该删除的文件，私自在系统上运行了冲突App或破坏性App；三是系统平台故障，比如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分钟时间监测一下网络，就完全可以在故障的早期排除之，避免后期重大事故的发生。

[故事之二十四]多协议使用，设置不良，服务器超流量工作

[症状]今天的故事发生在某机电进出口企业，网络部主任林先生来电告知他们的网络昨天刚刚进行了升级，从10M以太网桌面应用全部升级为100M以太网交换到桌面，结果出现局域网内网络访问速度反而比升级前慢的现象。有的访问很长时间没有结果，有的则出错。他手里有几款侦测网络流量的App，启动运行后也没有发现任何问题。对服务器的Ping测试平均小于1ms，应该不会慢，但不知何故会如此表现。

[诊断过程]这个故障看起来比较简单，实际诊断却颇费周折。该网络由4个路由器经帧中继线路与国内总部和国际分部链接，占据4层楼面，由2台千兆核心交换机和二级5台工作组交换机(每层一台)以及20台桌面交换机(每层4台)组成，100M交换到桌面，结构比较典型。从故障现象看，网络联通性尚可，但速度受影响。一般来说，速度慢的原因有很多，比如网上设备速度跟不上要求，网络设备出现阻塞或瓶颈效应，电缆光缆系统问题使得网络数据出错或产生高额碰撞，网络协议设置错误造成无效的重复访问，应用App或协议设置错误访问受阻等等。由于刚更新了网络，原来的电缆系统又没有经过认证测试，根据以往的经验，电缆系统存在问题的可能性最大，所以大家决定先检查电缆系统。鉴于所有网络成员都有速度问题，大家先抽取部分电缆尤其是主要服务器的网络电缆进行现场认证测试。
系统电缆采用的是超五类线，用电缆认证测试仪测试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？答曰根本未知。
由于这两种协议有没有参与该企业的业务流程尚且不明，故暂时不能贸然将其删除。必须尽快核实现在的业务App是否依赖这两种协议。林先生告知他是一年前接手网络部主任一职的，对业务流程App并不熟悉，但知道现在运行各App的供应商。大家请他马上与该App开发商联系，15分钟后对方发来传真明确说明该企业的App只在Windows平台上运行，不支撑Apple Talk和Banyan Vines等应用平台。为慎重起见，大家请各业务部门的代表集中辨认并统计现在各自所用的操作平台和App，结果都不包括Apple Talk和Banyan Vines。至此，大家决定对该协议平台进行卸载。一边操作一边请林先生查阅以前网络档案，结果发现了这两种平台的安装软盘和应用App安装软盘。
完成协议清理作业后，重新启动网络，网络访问马上恢复正常。

[诊断评点]非工作协议是指在网规划和络设计中未被选用的协议和应用，但他们存在于各种网络平台之中。作为网络上的“游魂”之一，他们会耗用少量网络带宽。常用的被捆绑于视窗平台的协议如IPX、IP、NetBEUI基本上没有冲突。所以许多用户虽然没有同时使用这几种协议但也会时常同时捆绑这些协议。NetBIOS设置有多种平台协议的输入输出接口，有助于众多协议的交互工作和各种协议平台及其应用的并存。但从网络性能优化的角度看，各种协议平台和应用版本是由不同厂商开发的，兼容性始终是一个动态适应的过程。没有一种始终能紧密跟踪各种协议平台和应用协议变化、相容和协调的有效方法。从这个意义上讲，多协议工作的冲突是不可避免的。
翻阅六年前网络档案大家发现，该网络多年以前一直使用的是Apple Talk和Banyan Vines平台协议，当时是请ALP国际企业提供的应用App并负责安装工程。直到三年前才全部安装启用视窗平台和基于IP协议的新的应用App，但APL企业的人员没有将老平台卸载，而是简单地停止启动运行。后继的网管人员在交接时因不熟悉这些协议及其用途，没有进行清理。最近的这次的网络升级工程安装调试时根据原先的网管记录和服务器平台的提示重新安装并启动运行了这些App。询问负责App安装的网管人员是否了解这些App的用途，答曰因为在老平台的窗口中一直看见这些App，其间也曾询问过一直任职的财务经理，证实有用，所以才重新安装之。实则该平台的设置与新的应用App之间有严重冲突，并同时干扰现行应用App的有效工作。两台服务器之间一直在互相询问并重新发送无法处理的无效数据包，除了干扰其它协议外，直接的结果就是占用大量的网络带宽，破坏数据的传输和处理，致使网络速度变慢并时常出错。
另外，林先生手里的诊断App都是基于视窗环境的应用App，无法观察其它应用的流量。

[诊断建议]协议的无缝互联和互操作是App开发工程中的难点。实际的应用App品质并不如开发商所标榜的那样乐观。为了使网络的工作效率达到最佳，网管人员需要经常监测网络协议数量及其工作状态。对于无用的协议要即时清理之。重要网络在协议监测对新出现的协议还要监测其操作过程，查找其来源。因为许多网络在遭到黑客攻击时常会伴随某些新协议的活动。

[故事之二十五]千兆网升级工程，主服务器不可用，自制跳线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采用的电缆为仿冒的超五类线，加之其它服务器也偶尔有数据错误和停顿的表现，故建议她将所有的服务器超五类链路重新进行检查，以确保网络的工作质量。

[故事之二十六]交换机设置不良，加之雏菊链效应和接头问题，100M升级失败

[症状]某化工交易中心华东企业，今日报告网络从10M升级到100M后，约有一半的工作站无法提速，他们都在同一个楼层。另一楼层的5台工作站则无法入网。另外，两个楼层中都有少数工作站工作速度比升级前更慢，而且并不是对所有的服务器或其它工作站访问都慢，对少数服务器的访问速度还“凑合”。该企业没有配备任何用于网络维护的工具，所以，除了可以观察服务器的CPU利用率以外，只能用App间接观察网络的流量和碰撞率。观察到的碰撞率偏高的微网段可以达到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帧校验序列错误出现，工作站在发送数据帧时常因无法发送完整无错的帧而被迫多次重复发送。除了占用带宽就是增大了有效数据帧的等效延迟时间，表现为用户的速度很可能比升级前更慢。另一些用户则表现为虽然速度有所提高但仍达不道预期的速度。

[诊断建议]建议用户将布线系统进行全面测试，对交换机进行设置，清理有可能出现的雏菊链效应结构，对实在有困难的集线器组则可以考虑增加交换机数量，以便分割和缩短雏菊链。

[故事之二十七]用错链路器件，超五类线系统工程验收，合格率仅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％也要更换，这样才能确保该超五类线电缆系统在相当长的时间内保持合格水平(比如十五年质保期内)。

[故事之二十八]六类线作跳线，打线错误造成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秒以内全部服务器链路都能完成。

[诊断建议]服务器安装商误用朗讯的六类线来制作超五类线跳线，使得原本根本不能上网的服务器能够勉强上网，并同时造成其它参数健康指标不合格。一般来讲，采用六类线制作的跳线其性能会优于五类线。所以建议用户可以保留六类线制作的超五类链路跳线，只需将打线顺序改正即可。

[故事之二十九]交换机端口低效，不能全部识别数据包，访问速度慢

[症状]某大型化工股份有限企业信息中心主任洪先生向网络医院报告网络故障：最近进行了一项网络系统的更新升级和扩容工程，所有的用户由10M以太网全部提升为100M以太网用户，核心交换机选用千兆以太网交换机。扩容完工后进行了系统调试，结果发现，大部分的网络用户感觉速度变慢，有时数据出错，但如果在子网段内让两个任意用户之间拷贝数据文件，则速度却基本上不受什么影响。Ping测试检查所有工作站和服务器的联通性均正常。遵照网络医院上周的建议他们对网络布线系统进行严格认证测试，结果显示布线施工的质量优良，全部电缆链路按超五类标准测试参数均为合格，光缆链路逐个检查测试也没有发现任何问题。由于信息中心除了电缆和光缆的认证测试仪外，没有其它测试维护工具，无法对网络本身的进行评测。虽然仔细进行了网络系统及平台的重新安装，仍无济于事。由于总企业希翼全面提高ERP系统的覆盖范围，新增的网络设备比较多，网上平台、应用系统和网上成员进行了调整和合并，网络用户数量也增加为原来的两倍多，工作站从原来的220台猛增至680台，由于网络区域比较分散，地理跨度最远达30公里，办公区和生产区之间、生产区和生产区之间均用光缆和路由器连接起来。洪主任抱怨现在网络的管理成了问题，信息中心的工程师基本上是每天忙于处理“报警电话”，中心配置的工程车辆就没有闲下来的时候。查找故障不象从前那样容易了，一来网络规模比以前大多了，无论用户数量还是用户分布范围都比以前大了很多，故障数量和种类增多，二来网络结构变得比以前复杂多了，故障的定位分析和隔离变得愈来愈困难。
该网络各子网段基本上采用核心交换机和工作组交换机作网络骨架，用桌面交换机和集线器混用的方式构成基层用户接入平台，核心交换机之间为千兆以太网连接，用户全部为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％，并出现大量延迟帧记录，表明该端口通道测试不合格。
造成通道测试不合格的原因很多，如通道节段本身故障、通道中的每个汇流/分流节点有问题或出现流量竞争、交换机路由器的配置不良或错误、端设备故障或负荷太重等。从本故障测试结果看，交换机的端口P31结果正常，端口P32结果异常，可以基本确定故障就在交换机本身。为了确认这一判断是否正确，将流量发送方向指向与端口P32连接的上游交换机的端口P17，观察上游交换机的端口P17流量记录，显示为90Mbps，说明判断正确。
问题很清楚，被丢弃和延迟的流量就在P32口。而端口出现数据丢弃和延迟的现象一般有如下一些原因：端口的数据处理程序出问题，端口的物理介质和工作参数(光电参数)有问题，端口及相关器件有问题，端口与端口之间的内部连接有问题，端口同与之相连的电缆有问题或不匹配，WINS服务器网卡有问题，WINS服务器网卡与机器的主办及上层协议有问题。
大家对WINS本身作WINS查询，10次测试响应只有2次，响应地址正确，响应率只有20％。用电缆分析仪重新测试WINS链路电缆，合格。用网络测试仪测试WINS服务器网卡，合格；用网络一点通代替WINS服务器接收流量，仍然只有13.5％；用网络测试仪测试交换机的端口P32，仪器显示：端口低效。临时将WINS服务器端口从P32改接到端口P33，重新启动系统，5分钟后进行上述测试，结果全部合格。为了验证P32口是否真正低效，用网络测试仪接入该故障端口并向端口P17发送90M流量，收到流量为12%，并出现大量错误帧，其中包括：碰撞帧、延迟碰撞帧、干扰帧、碎帧等，共占90M流量当中约88％左右的比例。如果只是交换机某个端口出现低效或失效，问题还不是很大，因为用户可以启用其它端口。为了更进一步确认交换机端口问题涉及的范围，对该交换机的48个端口全部做高流量通道测试，结果发现P32、P1、P25均有类似问题，推测是交换机内部电路有问题。由于这台工作组交换机为新品，尚在保用期之内，因此建议马上更换之。

[诊断评点]网络中的大多数数据服务器由于设置在办公区的网管中心，所以企业整个系统的工作依赖集中式系统中的这些专用数据服务器，从安全防护和数据灾难恢复及数据备份的角度来讲，这样做的好处是明显的。链路连接和数据交换时需要WINS服务器提供解析服务。与WINS服务器连接的链路中，交换机的端口P32发射能力低效，使得发送的信号幅度不符合要求，由于链路长度短，所以并不是对所有的数据包WINS服务器都无响应。有些数据被作为部分错误和碰撞数据由端口记录之，大部分从交换机各端口送往P32端口的的数据因链路接口问题被延迟和丢弃，造成记录数据中有用流量正常，而网络用户速度普遍偏慢的假象。从网管上看不出流量有异常，只有用仪器接入做全部信号信息的监测才能发现大量的错误数据。从经验数据大家知道，交换机、网卡、集线器和路由器等网络设备的端口一般从工作2～3年开始出现低效现象，5年低效的比例为3％～18％(这取决于不同的厂商产品质量，也取决于同一厂商的不同系列产品的产品质量)。由于系统中有大量的端口，所以在网络维护周期建议中的要求是每半年对端口性能进行定期测试。每一～二年对布线系统进行一次轮测，尤其对重要的网络设备如服务器、交换机、路由器等应该坚持定期测试，这样做对提高网络的可靠性，加快故障处理速度有莫大的帮助。

[诊断建议]建议“病人”对所有网络设备进行一次普查，将全部端口都进行备案测试，并将这种测试列入整个网络系统的定期维护的内容之一。

[故事之三十]六类线施工工艺要求高，一次验收合格率仅80％

[症状]某著名布线工程商及系统集成商，采用六类线为某市新建的电信大厦布线，点数虽然不多，只有共1,800点，很快就完工，但在验收测试时遇到一些小麻烦：合格率一次性测试通过值只有80％，其余的20％近360条链路不合格。布线商采用的都是某电缆生产商的正规产品，包括全套的电缆和连接模块，其质量在施工前进行过验收，抽查过其中三卷产品，均合格。承担施工的队伍也是有近四年工程经验的下属布线工程企业，曾经有10万条链路的成功施工经验。此次工程项目为第一个六类线试点工程，对企业的布线施工队伍也是一次考验，结果却不尽人意。如果360条链路全部返工，计算下来也是一笔不小的损失。因此企业决定先对剩余的六类线及模块再行进行产品质量抽查，以确定是否是产品的问题；然后再安排如何更换或修复这些不合格链路。
抽测结果如下，抽测的10卷产品，每卷产品截下90米，按90米六类线“Basic Link”基本链路连接后进行现场认证测试，结果有7卷产品不合格。由于该工程商同时也是厂商的产品代理商，厂商的销售代表也无法说明测试结果。接着再进行了第二次抽查，结果10卷产品的90米模拟链路仍有6卷不合格，遂请“网络医院”帮助确认原因。

[诊断过程]到达现场后部分抽测了不合格的链路，共抽测了20条，结果全部不合格。打开电缆测试仪DSP4000中保存的参数，查看其主要不合格的参数有回波损耗“RL”，综合衰减串绕比“PSACR”等，比例占80％左右，其次是近端串扰“NEXT”、综合等效远端串扰“PSELFEXT”、 综合近端串扰“PSNEXT”等。对工程商原来抽测过的链路进行复检，结果与上述结果基本一致,仍然是不合格。
仅靠生产商提供的产品证明和产品附带的检验证书、合格证书等似乎已不足以证明其产品是否满足工程施工现场认证测试的要求，因为这些标识是生产商自己提供的，并不是由第三方独立检验机构提供的。为了确认是否是厂家电缆产品和接插件、连接模块等本身的问题，大家建议布线工程商将他们代理的另外一家电缆生产商供应的产品拿来与本项工程采用的电缆进行对比。对比方法如下：用别的厂家产品同样制作10条标准链路，测试条件与上述抽查时的测试条件相同，然后统计测试结果，与前面的测试结果进行对比，以便验证是否是产品本身的问题。
一小时后，工程商依此建议制作了两组共20条用另外两家电缆生产商提供的电缆产品“加工”成的标准90米基本链路，每家10条链路。大家分别对这些链路进行测试，结果如下：
链路合格率为A产品80％，B产品70％；且合格的参数当中各有20％的参数比较靠近测试标准的边缘，“RL”和“NEXT”等主要参数一般只有0.5～1.3左右的富余量。仪器在合格的标示右上角加了一个“*”号提示，表明参数虽然合格，但非常接近不合格的边沿，考虑的标准规定的仪器误差才视此参数为“勉强合格”。
由此看来，另两个电缆生产商提供的产品有着相近的产品合格率，加上出问题的厂商的产品，共有三家产品合格率太低。这岂不等于说三个电缆生产商提供的产品都有问题？根据逻辑分析只能有以下几种可能：原因一是产品质量确实有问题，但本例中有问题的比例为何如此一致呢？可能性似乎不大；原因二是测试仪器或测试环境有问题，比如仪器误差偏差或损坏，测试环境有大量电磁干扰源或干扰信号。施工现场和试验测试地相距达400米，电磁环境相异甚多，且周围没有其它使用特殊电磁设备的邻居和大型用电设备、强功率辐射源等，这条原因似乎也不象；原因三是施工方法、施工工具、施工工艺和现场测试的方法有问题，但工程商承担施工的人员都是有至少一年以上施工经历的员工。且为验证产品是否有问题在试验链路上打线的人员已经为该企业工作了两年半，技术上应该没有问题。打线工具经过目测检验也没有问题，并且工程施工中的打线工具不是刚才试验链路制作时的同一个工具。
大家暂时假定产品没有问题，采用另一台自身携带的DSP4000电缆测试仪和工程商自备的同一型号的电缆测试仪进行对比测试，各测试结果一致性相当好，说明测试仪没有问题。为了定位故障位置，使用DSP4000电缆测试仪中的“HDTDX”高精度时域串扰分析功能和“HDTDR”高精度时域反射分析功能进行故障图谱分析，结果发现不合格参数的“突出位置”都在接插件和连接模块的位置，这说明要么接插件和连接模块有质量问题，要么就是施工工艺存在问题。接下来将不合格链路中的接插件和连接模块重新更换一遍以后进行测试，结果三家产品各自10条链路中有一家全部合格，两家只有一条不合格。将不合格的链路再“回炉”一次，进行第三次测试，结果全部通过测试。再对20％参数靠近边沿的链路认真“回炉”进行测试，结果一次重新测试就全部通过！！
这说明，接插件、连接模块、电缆的安装施工工艺是链路认证测试不合格的重要原因。
下一步，为了验证是否是电磁干扰等可能原因，回到工程现场，选取20条原来测试不合格的链路也如法炮制，重新“回炉”，将接插件和连接模块重新“认认真真”制作一遍，结果除了4条电缆不合格外全部合格。不合格的电缆经过仪器的诊断，结果判明其回波损耗“RL”、近端串扰“NEXT”不均匀，取出电缆观察有明显的扭结和擦伤的痕迹，且均垂直导出金属管。更换电缆后测试，全部合格。

[诊断评点]综合布线的施工工艺看似简单实则要求不低。在三类线的施工过程中，大量的布线商采用临时性的施工人员，经过两小时培训后就上岗工作，工程验收合格率仍比较高。而在五类线和超五类的施工过程中，工艺问题开始出现并反应到最终的测试结果中，这逐渐引起工程商的重视，但一般不足以形成本例中如此大面积高达20％的链路不合格的严重后果。也就是说，五类线只要电缆和模块是合格的，一般来将施工验收的合格率均不会低于95％，超五类链路一般不会低于92％。而在六类线的施工过程中，对施工工艺的要求被放到了非常重要的位置，在布线、打线、安装模块时稍有不慎就会使整条链路的现场认证测试不通过，这是工程商和厂商在产品推广的开始阶段均始料不及的。其实，诊断具体的故障位置方法很简单，使用电缆测试仪的高精度时域串扰分析技术“HDTDX”和高精度时域反射分析技术“HDTDR”两项故障诊断功能就可以非常方便地显示出故障的实际位置。施工人员可以据此马上采取修复措施，比如根据仪器的提示更换电缆、模块或重新加工即可，一般都能获得满意结果，而不至于等到进行现场认证测试和验收时再“现眼”或“出洋相”了。
六类电缆频带由100MHz增加到250MHz，对特性阻抗及其分布连续性的要求提高了很多，另外对近端串扰、等效远端串扰、衰减串绕比等参数的要求随着频率增加的平方数或3/2指数成正比(不同线缆有区别)提高。上述参数的PowerSum(功率和)参数也被提高到非常严格的程度，表现在施工工艺中比较突出问题就是接插件和连接模块的制作工艺、电缆的布线工艺等对整条链路的影响变得非常突出。所以严格的施工工艺要求需要引起布线工程商的高度重视，只有这样才能避免造成影响工期的大面积返工和资源的浪费。否则，一次性验收测试一般只会停留在80％左右。如果加上仪器配套使用的“基本链路”测试适配器的使用时间较长，使用保管不当，则有时甚至会导致近60％以上的链路出现测试不通过的结果。给安装上带来巨大的麻烦。并迫使安装上采取“投机取巧”的方法回避某些必测参数的测试。比如对超五类链路、六类链路均要求进行回波损耗“RL”测试，而安装商由于测试很难通过则选择放弃对该项参数的测试，致使用户利益受损。所测试的结果就不能称其为严格意义上的认证测试，就好象您养了一只断了一条腿的猫，虽然不至于马上影响其生命的持续，但您恐怕再也不能指望它如往昔般飞快地冲向一只贪吃的“硕鼠”了。
关于六类链路测试中基本链路适配器由于使用和保管不当将如何给厂商和集成商、安装商带来麻烦，大家将在第33期连载故事中向读者详细先容。

[诊断建议]将不合格的360条链路重新严格制作一遍，并对参数靠近边沿2dB以内的的360条链路也采取同样改进措施，以确保工程品质。对经模块、接头等重新制作仍不合格的链路，遂将电缆重新更换。另外，施工队伍的严格培训和强调施工工艺的严格性也必须认真对待之。

[故事之三十二]服务器、交换机、工作站工作状态不匹配，访问速度慢

[症状]网络建好了，对于系统集成商来说，设备的安装调试一旦完成，一般都要安排一个小小的庆贺仪式。而对于一家承担过十几项大型工程的系统集成商来说，面对一个400个用户的中型网络，设备调试的工作应该不是难事。但是，直接从庆贺仪式的准备现场赶来网络医院“报警”的病人今天还是第一此遇到。
某著名系统集成商专门负责政府网建设的项目经理罗先生今天十万火急地到网络医院电话急诊，请求紧急支援。原因是下午的“竣工验收”仪式和晚宴已经定好，本工程又是他们企业首次采用六类线电缆系统的样板工程，邀请的十几个重要客人今天下午均会相继“出场”。按原工程计划的进度安排，网络的调试工作用三天时间进行，应该于前天上午完工。而直到今天上午10:00为止，调试工作因遇到拦路虎，还没有成功通过系统调试。如果今天下午15:00以前不能调试成功，那么请来参观和观摩的客人自不必说，单就企业的声誉来讲，恐怕无可避免地将受到严重影响，且进一步的业务深入也将会受到严重影响。
罗先生反应的网络故障表现很简单：基本上所有的网络成员访问网络资源的速度都非常缓慢，Ping测试联通性表现良好，均在2ms以内，从服务器上拷贝一个20Mbytes的文件竟需要5分钟。
调试人员曾试着从相邻的工作站上拷贝一个20Mbytes，对比结果显示同样也需要5分多种的时间。怀疑是操作系统和系统App平台安装上的问题，特别是服务器安装上的问题。调试人员已经将所有用户重新安装过两遍，凭借以往安装系统的丰富经验，他们十分有把握地保证操作系统和App平台安装设置没有问题。为了了解数据包在网络中传输的对话情况，又从朋友哪里借了一台协议分析仪对收发包进行测试，结果显示包的收发反应时间基本正常，只是包的转发时间间隔很长，无法进一步确定是哪个环节的问题所至。网络的公共部分是一台10/100核心交换机和三台服务器，服务器直接与核心交换机相连，其它工作站则通过下属的工作组交换机和集线器等与之相连。起初怀疑是交换机的问题，试着更换了一台同型号的交换机，故障依旧。从另一家主代理商哪里借来一台服务器作替换试验也无效。

[诊断过程]大家马上随罗先生赶往“事故现场”，10分钟后抵达现场。首先从一台工作站上Ping服务器和任意选定的位子网内其它5台的工作站，响应时间均小于1ms，说明联通性尚可。调试人员怀疑是交换机问题的可能性是存在的，但大家认为证据不足。这是因为从邻近的工作站直接拷贝文件也很慢，这时数据包不经过核心交换机，有的虽通过工作组或桌面交换机，但有的则直接通过集线器。所以故障的公共部位比较可能的是新的布线系统、操作系统和系统App平台、关键网络设备本身的故障或错误、网卡驱动程序错误等等。
用网络测试仪实施流量贯通测试，选择从任意一台工作站到服务器为一条通道，再任意选择该工作站到其它5台工作站直接的通道，共6条测试通道作试验样本。从测试仪上分别发送正常的IP包流量到上述6个对象，流量选定为健康指标的上限值，即40％。用网络一点通在被测试的站点模拟网络设备配合接收流量，结果发现收到的流量都不足1%，且广播包占20％以上。
缩短流量贯通路径，直接向邻近的工作站发送流量，结果收到的流量有两种明显的结果。一是流量大量增加，达28%左右，其路径是通过集线器连接的通道，属于正常表现。另一种结果同前面观察到的现象一致，收到约1％左右流量帧。观察收到的28％帧流量的结构，其中92%~98%为碰撞帧，少量FCS帧。由于邻近的工作站是用集线器连接的，发生如此高的碰撞最大的可能性是电缆系统的问题。大家随即测试该六类链路，并任意抽查了其它5条六类线链路，测试全部合格。说明链路的物理联通性是合格的。但因为集线器、交换机等的物理接口是超五类的元件，六类线链路从理论上和厂家的承诺上讲应该与其能兼容。观察用于发送40％流量的网络测试仪自身的流量记录，其监测到的碰撞率与上面的结果一致，也是92%～98%左右。这提示该六类线链路可能与10/100M的网络设备阻抗不匹配。如果真是这样的话，那么问题牵涉的范围就比较广泛而且严重了。这是因为这涉及到六类链路与超五类器件的通用性和向下兼容性的问题，而这是六类线电缆厂家承诺和保证的优越性之一：采用五类和超五类设备的网络可以与六类链路任意对接，如果今后需要使用更快速的网络设备，则只要更换支撑六类链路的网络设备就可以达到超高速的应用。
从网络的表现来看，因为这是首次安装的六类样板链路，并且是在六类链路上挂接超五类端口的网络设备，而网络的表现范围广、现象比较一致：出现大面积内的速度慢故障。协议分析仪解包显示包交换正常，不能证明是网络操作系统和App平台的问题。所以，安装了影响全局的部分只有六类线布线系统，这也是调试人员重点怀疑的网络部位。大家当然不能由此就认定是网络设备端口的问题或是六类线链路与端口不匹配。为了慎重起见，大家用两条超五类线缆连接两台相邻的工作站，再次试验拷贝文件，结果故障依旧。这说明六类线系统不是真正的故障原因。剩下的问题就是需要确认端口匹配性、工作站工作协议、配置、驱动程序、物理参数是否与网络匹配了。方法很简单，将在线型网络万用表串入工作站和网络端口(大家分别选择了一个集线器和一台交换机的端口)。结果显示如下：一台工作站的工作速度为100M，端口设置为全双工，而对应的集线器设置为100M半双工；另一台工作站工作速度为100M，端口设置为半双工，对应的交换机设置为半双工。罗先生告知，网络中的网卡使用了三家企业的产品，都是非常知名的厂商。A企业的产品占90％，其余则为B企业的产品，另外，服务器使用的是服务器厂商C企业自己的网卡。
大家抽测了A企业的10张网卡，用网络万用表测试，显示设置全部是全双工；而抽测的5张B企业的网卡则全部是半双工设置。大家选择相邻的两台安装了B企业网卡的工作站拷贝文件，结果发现拷贝速度非常快，约3秒钟。
接下来大家把两台安装有A企业网卡的相邻工作站用A企业随配的App将网卡强制改为半双工状态，20Mbytes文件拷贝时间也是3秒钟。
选择被试工作站到服务器的通道，它们通过一台集线器，两台交换机后到达服务器。依次测试链路中的速度和工作状态，结果发现服务器网卡也是全双工设置状态。更改后试验从服务器上拷贝一个100Mbytes的文件，耗时约13秒。说明性能比较优良。

[诊断评点]故障的原因已经很清楚，该系统集成商选用了三家企业的网卡，而其中的A企业网卡被全部被默认设置为全双工状态(原因不详，但可以调整)，服务器也被偶然地设置为全双工状态。但系统中的交换机、集线器等都工作在半双工状态，所以，凡事先安装有A企业网卡的工作站工作速度都很长慢。其它安装了B企业网卡的工作站，虽然自身设置是正确的，但由于数量少，只站不足10％，加之服务器也被设置为全双工状态，所以调试时很可能与A企业或C企业的网卡进行数据对接，这样速度就无法正常。如果偶然地与同类B企业网卡进行数据交换，则调试人员应该会有机会发现虽然所有的工作站与服务器连接速度慢，但并不是所有的工作站之间直接联络时的速度都慢这一现象。不过，因为A工商产品数量居多，服务器设置又不正常，所以这样的机会不多。
网卡的协议设置和工作设置会直接影响工作站的速度。一般来讲，工作站的协议设置多数时候不容易出错，但是否与网络的工作协议一致则有时会弄混。比如，工作站使用SMTP协议收发邮件，而网络的邮件服务器使用的是POP协议收发邮件，则工作站将无法进行邮件收发操作。比较容易出错的是10/100M设置状态、全双工半双工设置状态、链路数字脉冲极性选择等，这些方面的错误由于网络维护人员和安装调试人员的有意无意地疏忽，加上没有合适的检测方法和工具，往往会给系统集成商造成很大的麻烦，而故障原因却是如此地简单。很多时候调试人员使用网卡和交换机的自适应功能，这是比较好的原始状态，缺点是个别端口可能适应不良或不能按需要达到适应的结果。比如，用户需要自适应状态最终为100M全双工，但自适应的结果可能是100M半双工或10M全双工状态。因此部分用户使用App进行人工设置，这样可以达到需要的状态。缺点是人工强行设置的状态不一定与网络实际能达到的状态一致，且经常的情况是无法对设置的结果进行验证或检测。本例故障应该就属于这一类。
随着网络状态和元器件参数的改变，原先的设置有可能需要更改，但如果维护人员没有相关的档案，则难于检测实际的连接状态。所以在网络定期维护方案中，一般建议一年左右对端口做一次定期检查，除了检查端口工作状态匹配性外，还顺便检查协议匹配、端口老化程度等。
本故障的诊断走了一些弯路。因为是新安装的六类线系统，使得故障诊断时有意地倾向于首先怀疑是否是此新系统与100M超五类系统(实际上，超五类系统是为1000M以太网准备的)不匹配方面的问题。如果首先在相邻工作站与交换机或集线器之间检查链路工作状态的检查，则可以在10分钟内找到问题。本故障实际耗时约100分钟，赶在13:00以前收工。
罗先生紧急动员所有调试人员马上检查并用App调整全部的A企业网卡，只用了不到一个小时就将全部设置改为了半双工状态。

[诊断建议]网络维护人员和部分安装调试人员往往错误地认为网络的维护和管理就是去管理服务器、工作平台、工作站、打印机等其它网上设备，这是片面和有害的。其实网络维护人员真正需要下功夫维护和管理的地方是网络设备而不是网上设备。网络设备通常是指路由器、网关、桥、交换机、集线器、广域传输设备、电缆光缆等等。这些是被许多网络维护人员和部分安装调试人员忽视的地方。有的则是因所学专业的限制有意无意地忽视之，特别是对光电参数的验证和测试更是如此。有的则是设置参数配置不合理，比如交换机和路由器的工作参数配置不合理等等。

[故事之三十三]六类线测试链路模型不科学，导致测试通过率低

[症状]一上班就接到某著名计算机电缆生产商品质部经理江先生的电话，要求给他们一个合理的说明。说他们发现近来生产的电缆被分销商和工程商纷纷要求退货和换货，理由是工程验收合格率不高，达不到合同要求。智能建筑的业主常以此为由拒绝给分销商或工程商支付工程款项，分销商和工程商的资金占用严重，强烈要求生产厂商紧急提高生产质量，并赔偿由于业主拒付或减付、重新更换电缆或其它链路器件、以及由此造成的其它相关费用。问题的症结在于，生产商重新检查了生产工艺流程和品质保障条件，并仔细对生产的电缆进行严格地测试，并没有发现分销商和工程商所提出的问题。因此拒绝赔偿请求。双方争论的焦点在于，生产商出据的产品检验报告是合格的，而工程商在工程完结后进行的测试也是按国际标准进行的，测试结果确出乎所有人的意外：合格率不超过90％！
生产商拒绝赔付的理由是：交到工程商手中的产品经过再次严格检验是合格的，因此链路现场认证测试的不合格结果与生产商无关。至于因产品保存不妥当，施工不规范等原因，不属于生产商而责任范围。分销商和工程商索赔的理由则是：大家是严格按照产品说明上要求的施工方法和工艺进行的施工安装，产品的运输和库存管理也没有不当之处。尤其是“事件”出了以后，分销商和工程商专门就运输和保存过程进行全程检查，确认没有问题，而就是这没有问题的电缆当中，施工后链路合格率仍然超不过90％，所以，链路检验不合格不是工程商的责任。即便是按现有的施工工艺要求进行施工，不合格的原因也是生产商编制的施工工艺及要求有问题，工程商也绝没有义务承担链路检验不合格的责任。双方都希翼网络医院帮助他们就施工工艺规范是否存在不合理的地方给出一些明确的建议和求证方法。

[诊断过程]大家在电话中与江先生约定了检验的方法：先在生产现场对生产的电缆进行品质检验，确定其是否合格；然后将合格的电缆确保在条件良好的环境下运送到施工现场进行实地施工(距离200公里)，挑选熟练的施工人员铺设50条较长的链路，同时全程监测施工工艺是否符合要求。最后对铺设好的链路进行现场认证测试，如果98％以上合格，则基本可以证明产品没有问题。不合格的原因应该首先在施工人员是否严格按照规范进行施工等方面去查找，由此可以较大程度上避免承担大额损失。如果合格率低于98％，则可判定施工工艺规范需要重新考核和修改。
对生产商来说，这可是有点“玩悬”。江先生说，我对此事一点也不乐观，不管测试通不通过，似乎责任都与生产商有关：其一曰，即便测试通过，证明是施工工艺不合规范为主要原因，那么大家生产商也要担上“产品敏感性高，施工难度大”的“恶名”，于今后进一步的市场竞争很不利；其二曰，万一测试通不过，将被迫重新修订施工工艺规范，并会牵涉进一步的繁杂求证过程和大范围的赔偿诉讼。对于大家的产品我是非常有信心的，真希翼能有第三种结果出现。
关于如何在现场验证产品，如何运输和安装“样本链路”，在此不予详表。
测试结果出来了：50条链路41条合格，合格率92％，低于98％的要求值。不合格的参数主要是回波损耗，9条，少许是近端串扰，2条(即有2条链路的回波损耗和近端串扰均不合格)。使用的是江先生自备的测试仪。江先生神色黯然，一言不发。显然，测试结果对生产商非常不利。
江先生不死心，提出对测试仪器进行校验以后再行测试，理由也很简单：万一是测试仪器本身的问题比如精度偏差造成检验结果不合格则检验结果有失公允性。此时参与测试的工程商们虽个个喜形于色，但还是同意了江先生的要求。由于仪器校验需要较长周期(送检需要3～5天)，于是工程商们提出一个变通做法：因为工程商手中都有仪器，所以对50条样本链路可以分别用不同厂家的仪器去检验，并且每种仪器都用两台同型号仪器进行比对检验，如果结果相同，则说明仪器的偏差可以被排除在外，检验结果有效。江先生同意了此方案…
在场参加测试的人员谁都没料到的是，江先生的这一最后“坚持”竞真的引出了令人惊喜的第三种结果。第二轮测试使用两种测试仪各两台进行了4组测试。测试结果如下：
A厂家的两台测试仪器测试结果基本相同，结果显示33/35条合格，17/15条不合格，不合格的参数全部集中在回波损耗“RL”上。且其中并有近端串扰4/4条不合格。
B厂家(Fluke)的两台仪器测试结果相差很大，一台测试结果显示38条合格，12条不合格，不合格参数也全部集中在回波损耗“RL”上；且其中近端串扰2条不合格，1条告警。江先生额头直冒冷汗，轻生自语道：“这下死定了！”。
真可谓“山穷水复疑无路，柳暗花明又一春”。此刻，另一台仪器的测试结果出来了，出乎所有参试者意料，显示50条链路全部合格！！
啊？？！！
为什么不同厂家的测试仪会有不同的测试结果？又为何同一厂家的不同仪器竟也会得出不同的测试结果？测试仪可不是玩具，江先生和工程商均希翼大家就此结果给出合理说明，否则…
大家仔细检查了这4台测试仪，测试模型使用的都是基本链路模型，因此测试适配器(测试跳线)都选用基本链路适配器。A厂家两台仪器基本是九成新，使用期限均在精度校验的保证期限以内(也就是说还没有到精度需要做年检的时候)。B厂家一台是八成新，一台是全新。也都在精度校验的保证期限内。检查测试仪配用的测试跳线(测试适配器)，除了B厂家全新仪器外，插拔接头均有不同程度磨损。大家建议江先生用B厂商全新仪器的测试跳线去替换B厂家八成新仪器的测试跳线重新进行一遍测试。看看结果如何？江先生和工程商们商定以后界定采纳这一方案…
测试结果终于出来了：八成新仪器配用全新仪器的测试跳线后测试结果竟然全部合格！！
江先生非常激动，工程商们也非常激动。看来只要使用新的测试适配器就可以解决问题和争端，这意想不到的第三种结果可令生产商们、工程商们、业主们均皆大欢喜，高奏凯歌。
为了进一步核实测试结果的可靠性，大家用随带的永久链路测试适配器装在B厂商的两台仪器上进行了最后一轮测试，结果也全部通过。

[诊断评点]被测试的链路按其形态可以分为三种模型(模式)：通道模型“Channel”、基本链路模型“Basic Link”和永久链路模型“Permanent Link”。此次测试均选用的是基本链路模型。根据其定
义，基本链路模型对被测链路的测试结果将包含测试跳线的参数。在三类线、五类线的链路测试中，由于链路的数据率不是很高，链路物理带宽为10MHz/100MHz以内，跳线的参数对测试结果的影响不明显。所以，虽然包含了测试跳线的参数，但它与不包含测试跳线参数的测试结果非常接近。所以，测试标准就使用含测试跳线参数的结果来作为测试结果。
如果将测试结果中跳线参数的影响扣除，则可以得到另一种链路模型：永久链路。因此，从测试原理上讲，永久链路是科学的，比较精确，而基本链路则是不科学的。但因测试结果很相近，所以基本链路模型在一段较长的时间内得以推广和广泛使用。
然而在超五类链路中，测试跳线的影响已经有所“抬头”，多数情况下可以仍然用基本链路的测试结果，但少数情况下则表现出“不合格率”上升。到了六类线，基本链路的结果与精确的链路结果经常表现为不稳定。如果使用的测试跳线比较新，则测试结果较好，如果测试跳线保管不当或使用过一段时间，则测试结果的合格率会下降。经常让人啼笑皆非是同一组链路，半年前和半年后的测试结果会相差较大。半年前合格的链路，半年后再测试就完全可能不合格。随着测试跳线使用时间的增加，甚至可能出现一分钟前和一分钟后测试结果都完全不同，仪器指示的故障点也在莫名其妙地随意“漂移”。此时若换一副新的测试适配器，结果将明显稳定并改善很多。
解决这一问题的办法有：一，经常更换测试适配器(价值两三千元)，使用中尽量不要卷绕测试跳线；二，废除基本链路模型，采用永久链路模型。由于永久链路模型不包含测试跳线参数对整个被测链路的影响，所以是比较科学和精确的。ISO11801和TIA568B.2标准都建议用户使用永久链路模型进行现场认证测试。
不过，永久链路模型也遇到一点小问题。这是因为永久链路模型的测试参数是在基本链路模型的基础上扣除测试跳线的影响而得到的。那么，如果测试跳线由于经常卷绕、磨损，参数也会随之改变(这是六类线存在的目前无法克服的通病)，所以永久链路需要经常对测试适配器进行现场校准。这种校准如果达到每天甚至每次测试之前就要进行的程度，用户对此将是无法容忍的。所以永久链路的测试适配器所用的跳线不应该象基本链路模型标准中规定的六类线，而应该是一种“耐疲劳”参数非常稳定的专用跳线。
本案的“纠纷”起源于基本链路测试跳线的不稳定，所以当更换了新的测试跳线后，测试参数全部合格。这证明生产商的产品、工程商的施工工艺和水平都是合格的。

[诊断建议]由于六类线生产商目前都不能解决六类线的“抗疲劳”问题(实际上，对安装在墙中的六类线也没有必要去解决“抗疲劳”问题)，对超五类以上的链路特别是六类链路最好使用永久链路模型进行测试。这样可以保证测试结果的科学性和准确性。使用特制的具有“抗疲劳”特性的专用六类链路(向下兼容)测试跳线，则可以保证测试结果的稳定性和可靠性。大家建议在场的生产商、销售代理以及工程商、系统集成商今后尽量测试永久链路模型进行测试。

[故事之三十四]交换机配置问题使得网络拓扑结构性能劣化，用户访问速度慢

[症状]某网站IT经理顾先生是大家的老朋友了，三年前在Cisco大会上认识，彼此“情投意合”，“兄弟”几个经常在一起交流一些网民心得。他原先在一家国有大型企业中任信息中心主任，负责网络的规划、设计建设和管理维护事宜。有好长一段时间没有他的消息，免费的信箱失效，加之后来换了工作就失去了联系。正思量怎么设法跟他重新取得联络，每想到他却不请自到，来了个“自投罗网”：昨天他因网络问题来网络医院咨询时方知其现在已经辞职到了现在的网站。顾不上仔细询问对方的近况，他便直接进入主题：他所负责的网站最近出现一些问题。白天时常会出现短暂的拥塞，上网用户反映访问购物频道之网上在线商城时经常点击无效，多次重复后仍可能没有任何反应。此现象已经持续的两周，网站老总责令他必须在两天内找出原因，解决用户无法点击购物的问题，否则……
故障出现在什么时候？一般是白天，晚上基本不出现。何时开始出现故障征兆的？没有什么征兆，突然出现又突然消失，很不稳定且没有什么规律。那么从第一次故障现象出现到今天为止有多久了？就两周。两周前你们对网络干了什么？比如调整网络结构、增加或删除网络设备、增加服务器、增删和更改网络用户等？没有。不过网站内容到是几乎天天在变，但这应该不会有什么影响。因为大家装有网管系统，可以随时查看网络个链路的流量状态。对链路的流量还分别设置了门限报警，如果出现流量异常值班人员会马上知道。再说，大家的内部网都是用的100Mbps的网卡，核心交换机使用千兆以太网连接。而网站出口只是8Mbps，出问题时检查过出口流量，从来就没有超过2Mbps，还不如不出故障时的访问流量大。因此，说由于出口瓶颈的原因在访问流量大造成访问困难显然是站不住脚的。对网上商场的服务器仔细检查并用备用服务器试着更换过，但没有任何作用。该用的办法都用过了，实在查不出问题出在哪里。
有没有做过捕包分析或延迟分析？做过，首先对有关的服务链路进行网管监察，发现链路流量一般只有5％左右，捕包分析发现出现故障是有较大延迟，但Ping包正常。当时试验在故障时在网站内任选一台工作站从网上商城服务器拷贝一个1000M的文件，拷贝速度很快。用协议分析仪的专家诊断系统对捕获的包进行分析，除了发现HSRP协议帧有3000个，其它未见异常。

[诊断过程]三刻钟后，大家随顾先生来到该网站所在大厦。准备着手进行检查。分析故障现象，指示网络主要的问题是访问某个指定的服务器时慢。一般的原因主要有：服务器资源不足，比如接口速度低、CPU速度低、内存不够、开通的应用窗口过多等；访问通道出现瓶颈，访问速度受限；通道上的设备出现处理延迟，影响通道访问的速度等。从内部网的反应看，拷贝文件的延迟很小，速度正常。基本说明网站的内部网络应该没有大问题。为了确认访问通道上的是否有流量瓶颈或延迟超长，大家将网络故障一点通接入路由器的出口，将网络综合协议分析仪OptiView接入在线商城服务器通道。从路由器出发送50Mbps(50％)高流量Ping包指向OptiView，这种方法是为了检查该通道的通道能力。可以看到最大的通道能力是95Mbps(发送的流量相应的流量加上为95Mbps)，将流量帧改为一般的IP帧，无须服务器响应，流量仍为50％，此时安装在服务器链路中的OptiView收到的流量是50Mbps，说明网络一点通发送的50Mbps的流量已经全部“安全抵达”服务器。此时的网络状态非常“正常”。从OptiView测试对路由器Ping包的响应，显示时间为12微妙(0.012ms)，结论：此时此刻网络工作正常。由于是不稳定出现的“软故障”，接下来大家需要在故障出现时进行测试，好在该故障每天白天都会出现，不怕它不来。50分钟后，从外线来的电话报告“故障出现”。大家迅速用OptiView的移动网管查看该通道的流量状态，显示均小于10％，从OptiView上对网站的路由器做Ping检查，时间是1200ms。马上从OptiView发送50Mbps流量给网络一点通，报告收到的流量只有5M，看来不光45M的流量被通道给“滤除”了，而且还引入了很大延迟。检查网站的拓扑图，从图上标注的状况来看该访问通道应该都是100Mbps的以太网链路，中间经过5台交换机到达服务器。在OptiView上对路由器做路径“TraceSwitch”检查。结果显示路径已经改变！整个路径中多出了3台交换机，从而使得原来需要经过5台交换机就能到达服务器的访问包现在需要经过8台交换机才能到达服务器！追踪查看这3台交换机，发现相应链路端口工作状态都是100Mbps。逐级检查延迟响应时间，发现1200ms的延迟就出现在新增加的第一台交换机通道节点上。由于有备份交换机，为了缩短故障诊断时间，试着更换此交换机。10分钟后，交换机更换完毕，开机试验，故障现象消失。
继续监测至下午收工时间，故障均未再出现。

[诊断评点]此故障是由于交换机的问题引发的。白天工作时该交换机会不稳定地处在较大时间延迟状态，并且会改变交换机对协议的传输路径。从该故障的表现和OptiView监测到部分STP/HSRP协议来分析，一般配置不良的交换机会出现类似情况。比如，使用STP或HSRP协议可以对端口的连接状态进行监测和从新依据传输的带宽、允许或限制的协议进行端口连接分配。这在高档交换机中是正常的功能，但如果设置不佳或网络出现异常未设定点流量，交换机也会依据设定点条件进行端口路径的检查、运算和重新连接构图，或者对流量带宽进行分配。
网络的配置文档是很重要的检查故障的参照系，准确的文档备案更是快速故障检测的有力辅助手段。反之，没有配置文档的备案资料会给故障检测带来不少麻烦。维护人员往往不能断定检测的参数到底是正常还是异常。一份不准确的文档备案有时甚至比没有文档病案更糟糕，它可能会把故障检测工作引向“万劫不复”的境地。那时有多少头痛药都是无济于事的。维护人员神经、耐心和体力都会收到很大的挑战。

[诊断建议]由于时间关系，大家来不及对更换下来的交换机进行检查。根据以往经验，可以初步断定此交换机很可能是配置不良而不一定是有质量问题。大家希翼顾先生安排专门时间将此交换机的设置仔细检查一番。如果能找到原来的初始配置文档则参照检查会方便许多。

[故事之三十五]随意级联交换机扩大网络容量并共用帐号，造成部分用户无法使用多媒体平台

[症状]某新建大学网络中心希翼网络学院帮助解决多媒体教学网络中的一揽子问题。
事情起因是这样的。黄先生最近接手负责该大学网络中心的工作，学校准备全面提升网络教学的档次：将去年完成的第一期网络工程试运行结果提交学校董事会讨论，进而确定这次的第二期工程的开工日期和投资计划。第二期工程主要是全面引进和扩大多媒体教学平台，启动学校半开放式公用数据平台的建设，所有学生在宿舍就可以实现多媒体教学的实时接收并与教师实现在线交流，随时接收公共课程的广播式播出和多媒体教学资料的在线阅读。配用的应用App允许最多可以同时打开6个图象传输通道。语音通道和文本资料的通道数不限制。每个学生宿舍配置了四个100Mbps用户接入以太网接口。教师新村(一、二村)的所有家庭均可以利用超五类线以太网链路实现节目点播。现在一期工程遇到的问题是，试验阶段的许多用户最多只能打开3个图象通道，否则会出现图象停顿和“马赛克”现象，图象伴音也随之出现停顿。从学校的网管系统上观察，有不少链路经常出现拥塞，经过调整拓扑结构，情况有所好转，速度也有所提高，但从许多被访问的服务器上观察其资源利用率比较低(一般都在25％以下)。也就是说，还可以承受一倍以上的用户访问量。一期工程当初设计的容量是可以同时为800个用户提供平均20Mbps的持续通道能力。从网上在线用户的实时调查表统计的结果是，实际用户支撑能力只有10Mbps的持续通道能力或约300个20Mbps的通道能力。结论：用户打开的图象应用窗口数量达不到设计要求。
下周需要提交一期工程试用报告，以便提供作为二期工程的投资计划参考数据。黄先生希翼能通过测试对提高网络优化度有所帮助，至少应该达到设计的指标。以便对校董事会就网络管理的“优良状态”有个过得去的交代。

[诊断过程]大家先使用网络拓扑专家App绘制了一组网络拓扑结构图。第一期工程覆盖全校的网络用户共2000个，其中800授权个用户可以实现宽带多媒体访问。经过两天的连续监测，发现实际的网络拓扑结构图和一期工程设计竣工图结构差异很大，实际的宽带授权用户累计有1200个，为了限制访问权限和访问地点，一期工程设计的用户地址是固定分配的，有权用户使用密码和匹配的IP地址进行访问，但监测到的重复的IP地址就有近300个。由于授权用户分散在校园内和园外新村的各个角落，其共享IP必然造成争用。用户抱怨出现马赛克现象多数在晚上，从链路通道流量监测记录看，此时有不少“新村”的用户在点播影片。观察“影片频道”的6个服务器，其资源利用率稍微偏高一些，但一般也在30％的资源利用率以下。
使用新绘制的、实际的、准确的网络拓扑图，大家重新设计了一份网络访问者有奖调查问卷，配合使用Fluke的网络听诊器NI、网络拓扑专家LamMapShot和流量测试仪，发现出现问题的地方都有如下规律：
一是有多个通道本身公共带宽比较窄，却挂接了超过总带宽的用户数量。这组用户在用户数量多时一般只能打开一个图象应用窗口。比较一期工程拓扑图，发现此类用户多是自行安装交换机和集线器接入网络的。而这些交换机和集线器并为经过网络中心批准或备案。这样会造成设计的拓扑结构和实际的拓扑结构差异。大家知道，网络拓扑结构在设计时是根据当时的应用流量和兼顾今后一段时间内的带宽需求设计的。总的要求是要做到负荷均衡。未经批准的交换机等网络设备任意接入后会造成带宽分布的改变，造成某些部位出现拥塞或“瓶颈效应”。据黄先生将，部分“私接用户”在设备接入时是给网络中心打了招呼的，只不过网络中心人员变化比较大，也不经常检查和备份网络资料，所以网络中有多少实际用户以及网络真实的拓扑结构并不能随时掌握。
第二是许多授权用户讲人情，将自己的IP与本网段内的用户分享，这在“新村”中的授权用户比较普遍。不少用户自购集线器与要好的邻居共同享用宽带点播带来的乐趣。有的用户并且还获得了免费访问多媒体教学网络的权利。经过检查还发现，有数条链路被连接到了校园地理区域以外的非法用户。可以不交学费就选听各科网络教学的最新课程。
针对“非法用户”过多的情况，建议黄先生采用新的一套用户访问登录验证机制，该机制只允许一个帐号同时登录使用一个用户。出现多个用户时先按设定的级别顺序查核是否合法的Mac地址、合法的IP地址。如果未限制MAC和IP地址，则只允许第一个登录者使用。如果第二个登录者才是真正的合法用户，那么他可以在线更改口令后切断已有用户的连接而转入正常连接。
没想到，如此的“试验”计划竟然引来一场风波。试验是安排在晚上进行的，刚开始10分钟，就在网络中心信箱和学校“BBS”上出现投诉和抗议信，而后是投诉电话和某位校领导的“诘问”，黄先生惊骇，没想见非法用户的威力竟是这样的“不小”。不过，当时测得的用户数量大量减少，流量瓶颈有所缓解。试验测试只进行了一小时就匆匆结束了。

[诊断评点]以太网由于其带宽大且成本低，速度不断提高，采用综合布线比较随容易达到随意构建网络连接、扩大网络用户规模的目的，所以网络拓扑结构在应用少时设计上要求比较简单。随着网络应用的增多，大容量应用和高速网络应用的增多(比如多媒体在线教学、视频点播等)，网络拓扑结构中流量通道狭窄的地方容易最先出现瓶颈效应。网络管理和维护人员需要经常监测网络各层的流量，比如，观测IP流量可以知道流量的分布情况，以便确定网络结构是否需要做优化调整，观测应用流量可以确知造成IP通道拥塞的具体是那种应用在“捣乱”，以便合理配置各种应用的使用时间和场所。长时间的观测记录还可以为网络的升级改造提供非常有用的资料。也可以随时了解网络的实际工作状态是否处于异常或边沿状态。网管系统在此项管理中是比较有帮助的。但当网络处于异常状态或联产连接终端时网管系统要么不能提供数据要么提供的数据可能不准确。因为网管系统获取的多数数据是由被归理设备提供的。这是需要在一些异常节点和通道上用专用测试工具进行全线速在线监测，才能得出准确的数据报告。流量测试和分析工作需要列入定期的监测工作中才能为随时可能进行的网络优化工作提供精确数据。使网络始终保持在优良的性能状态。
对于划分了访问权限和访问区域的网络，除了对访问者的密码限制外，对上网的地点、上网的机器有时也需要限制。部分工作可以使用全线速的内部防火墙来实现，速度低的链路可以使用App实现，但部分限制功能则需要配置网络设备如交换机、路由器来实现。不支撑此类限制功能的网络设备是比较多的。这时就需要用专用网关或内部防火墙。但这些设备在高速应用时对通道的速度和延迟性能影响较大，需要综合考虑是否选用。
本网络是由于网络拓扑管理功能和帐号管理功能没有严格地发回作用，致使网络拓扑结构被随意改变，网络带宽被随意共享，造成部分高速用户的使用问题。

[诊断建议]鉴于用户的现状和来自部分校领导压力，大家建议黄先生先采取维持现状的做法。将测试的结果提交校董事会即可作为一期工程的实际使用报告，这样更有说服力。二期工程可以将所有用户分类授权，届时再实施用户帐户和网络拓扑结构的严格管理。