经典故事:网络医院的故事（二）

　　光纤接头因雨水侵蚀和污染,导致网络瘫痪

　　[症状]

　　周末，要下班了，我正在计划如何安排假期，接某银行来电，报告该行某支行下辖的西区营业部网络瘫痪，营业部所管理的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类型的错误，此错误往往被人忽视。

　　昨天重装系统后因天气转晴，光纤接头性能有所好转，症状减轻。昨夜暴雨又使网络陷入灾难境地。加上今天测试光纤链路显示正常，致使故障排除陷于停顿，束手无策。

　　[建议]

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

　　[故事之四]

　　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经理经理的绝招。至少他已不再认为仅凭经验就可以"打遍天下无敌手"。网络维护是一门艺术，更是一门科学或工程，没有适用的工具和科学的方法是达不到这最高的"艺术境界"的。至于陈小姐，我们还是愿意善意地再为她，也为小张保守一段时间的"秘密"。