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

mazu

[故事之三]光纤接头因雨水侵蚀和污染,导致网络瘫痪
        [症状]周末，要下班了，我正在计划如何安排假期，接某银行来电，报告该行某支行下辖的西区营业部网络瘫痪，营业部所管理的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类型的错误，此错误往往被人忽视。
昨天重装系统后因天气转晴，光纤接头性能有所好转，症状减轻。昨夜暴雨又使网络陷入灾难境地。加上今天测试光纤链路显示正常，致使故障排除陷于停顿，束手无策。

[建议]交换器对均衡网络负荷、隔离故障网段对网络的影响有很好的效果，但也因此经常成为网管系统监测中的“黑洞”。用网络测试仪定期监测网络可以将故障消灭在萌芽状态之中。定期测试分很多种，我们将在以后的连载中陆续介绍。本故障如不及时处理，其它光纤接头连接的网络也会陆续出现严重问题。

mazu

[故事之四]3类插头代替5类插头，数据帧被反射和串绕破坏，导致网络中产生大量的碰撞帧和少量的FCS帧
[症状]某大公司IT经理黄先生是我的朋友，新年将近，喜事却不多。今天来电要求帮忙查找“元凶”。
事情是这样的，公司规模发展很快，两周前对网络实施了一次比较大的扩容工程，新增加了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经理经理的绝招。至少他已不再认为仅凭经验就可以“打遍天下无敌手”。网络维护是一门艺术，更是一门科学或工程，没有适用的工具和科学的方法是达不到这最高的“艺术境界”的。至于陈小姐，我们还是愿意善意地再为她，也为小张保守一段时间的“秘密”。

mazu

[故事之五] 雏菊链效应导致网络速度变慢
        [症状]下午某市工商局信息中心来电，其下辖的某县工商局今晨与市局的联网出现问题，速度与往常相比速度慢了许多。其中与该县工商大厦七楼的计算机基本上不能进行数据交换。而与其它楼层的计算机通信虽然速度较慢但还基本上能维持正常的数据交流。由于该市在规划计算机网络广域联网方案时没有考虑将来自身维护的问题，只是简单地在工程合同中将维护工作交给工程承包商负责，自己没有配备专门的工具和培训专门的人员来维护网络。该工程承包商当时负责此项工程的人员早已离开这家公司，故对今日的故障只能表示爱莫能助。经人介绍找到了网络医院。
       
[诊断过程]我们当晚即乘火车抵达该市并连夜开始查找故障。该市网络规模挺大，下辖7县6区87个工商所，市县局之间用64K的DDN链路连接，工商所与县区局之间用电话线连接。从市局向故障的县局用F683网测试仪作通道测试，速度4K时就上不去了，响应时间804ms，ICMP Ping显示县局路由器连接成功率在1/7左右。将县局网下挂的所有网络设备断电并拔下所有与路由器相连的联线插头，只留下路由器和一台集线器、一台笔记本电脑与之相连，再作通道测试速度为54k，响应时间46ms，ICMP Ping成功率100％。由此证明故障不在DDN链路，而在县局网络本身。
        驱车前往县局工商大楼，恢复大楼网络设备的供电，插上全部线缆插头，然后将Fluke公司的F683网络测试仪接入网络进行网段扫描，30秒后显示双路由器IP地址错误，伴随少量FCS类型帧错误。显然，故障与地址设重的这台路由器有直接关系，但网管人员不知道这另一台路由器来自何方，查机器文档备案资料也无此路由器的资料。经再三询问网络管理人员，才想起原来有一个废弃的备份路由器，半年前就早已经不工作了。虽未从早期不用机架上拆下来，但一直未让其上电工作(电缆联线也未摘下)。我们检查该路由器时却发现它正在上电工作！！，系何人所为暂且不查，立即将电源插头拔下另路由器断电，一分钟后市局来电网络速度恢复正常。此时F683网络测试仪虽然显示双重地址消失，但仍然有少量FCS类型帧错误，这说明网络还存在问题，而且主要是布线及链路设备的问题。联系七楼数据交换比其它楼层困难的故障现象，用F683向各楼层的计算机定点发送流量，结果发现与一楼、二楼和市局的定点数据发送FCS帧错误明显增高，其它楼层正常。基本可以断定是由于雏菊链效应造成的典型故障。据网络管理人员介绍，本网络平时就感觉七楼与市局和一楼、二楼的网络连接速度有时变慢，偶尔会有中断现象。查工程图纸，上面只标有一到五楼的布线及网络设备的分布图。六楼七楼的设备由于是半年前该局自己增加的，所以没有标示。无赖我们只得沿集线器布线方向查找网络连接结构。简单的计数就可以知道，七楼的设备与一楼、二楼的设备(路由器在二楼)集线器总数为5个，这很容易引起数据包的延迟碰撞(在10Base-T网络中则表现为FCS类型错误帧)。
       
[诊断评点]雏菊链效应是指局域网(10M网)内任何两个站点之间的集线器数量超过4个后引起的数据传输时间超长而引发的网络错误现象。本案中七楼、六楼为后来增加的网络，网络管理人员没有规划网络就想当然地将集线器按级连方式连接起来，结果出现雏菊链效应。如果不是有人昨天将备份路由器偶然接入网络造成广域网故障，雏菊链效应还将作为一隐患长期潜伏下来。
        一般来讲，路由地址竞争将引发严重的路由瓶颈问题，另外路由与服务器、交换器等地址竞争也同样会引起严重的带宽平衡问题。路由与工作站地址竞争情况会好一点。
        该市工商局的网络维护和管理可以说基本上处于空白状态，这也是国内许多网络维护管理的典型现状。如果说前几年主要精力放在了网络的建设上，那么现在该是将网络的健康维护工作提到议事日程上来的时候了。否则随着网络规模、速度和复杂性的增加将会后患无穷。
       
[诊断建议]改变六楼、七楼的集线器连接方式，或者重新做正规布线；指定专人妥善管理备份路由器；培训网络维护和管理人员，配备适当的维护工具，对网络的工作状态做一些必要的定期测试和登记。另外，网络的文档备案工作非常重要，一定要仔细做好这项日常工作，硬件备案时一定要将机器的Mac地址一一对应备案。

geniusdao

很好，希望能继续

ml2hs

好东西,细细品味

紫晶

很好接着发

mazu

[故事之六]服务器网卡物理功能的失效,导致网络瘫痪,仅在小数据量时能够维持网络活性
        [症状]某银行向医院求助，其西城区整个网络瘫痪，与电脑中心的联络基本中断，只偶尔有部分交易能达成，但速度很慢，不知何故。由于电脑中心的网管系统也陷于瘫痪状态，无法观察任何网上设备的情况。
       
[诊断过程]系统故障是凌晨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地址是文档备案的最重要内容之一，除了用于排除网络设备故障有极大方便外，对于迅速查找我们称之为“恶意用户”的非合法上网成员也有很大帮助。

mazu

[故事之七]布线环境不符合标准，导致网络性能急剧下降
        [症状]某证券公司求诊，要求查找错误源。近日股市火爆，新增不少用户，但一周内已经三次出现交易数据错误，数据恢复也进行了三次。虽然涉及的金额不大，与证券交易所的资料核对不上，昨晚对历史记录和当日交易记录进行了比较，发现在同一时刻往往有几个用户的交易数据出错。怀疑存在病毒或恶意用户捣乱的可能，用多套软件查杀病毒，并重新安装系统，恢复备份的数据。不料今日故障现象依旧出现。
       
[诊断过程]该网络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等)。营业室内最好禁止使用大功率对讲机，部分大功率模拟手机也要列入禁用清单。故障检测中，应重点检查最近动过的或变更过的设备，此为经验之谈。不过，一个有趣的现象是，当你向某个事后证明他确实更改过设置的用户询问时，经常得到的答复却是：没有动过任何东西。

fyx2008

很好呀，继续发，支持，顶。。。。。。