网络医院的故事----连载7

[故事之二十二]网卡故障，用户变“狂人”，网络运行速度变慢
       
[症状]今天的病人是某大型寻呼公司，刚更新了高速寻呼设备，增加了信息服务的业务内容，并对计算机网络进行了比较大的扩容和调整。调试工程一直比较顺利，但好景不长，刚正式开通工作一天就出现严重问题。技术中心严经理报告的故障现象如下：最初是在工作台上偶尔观察到在键入寻呼的用户数据时键盘更新出现等待现象，后来愈来愈严重，从刚开始的一秒钟左右到现在的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％。这样，网络上的站点处理本机应用程序的速度会受较大影响。有趣的是，很多用户也是在把机器从网络上退出时才发现站点的故障与网络有关。而之前却一直以为是工作站的问题，且最容易被误判为病毒发作。许多网管和网络维护人员通常的做法和遭遇都会象下面所描述的“故事”：首先，启用多种杀毒软件进行查杀毒操作，无效。然后，把所有工作站格式化，重新安装其操作系统和应用软件。但由于问题出在服务器，所以仍然不见效。最后，不得不将所有机器(当然也包括服务器)格式化以后重新安装系统平台及应用软件。如果是服务器网卡驱动程序安装错误(比如安装的驱动程序版本不符合，虽然能工作但不顺畅)，则故事可能因重新安装了正确的驱动程序而到此结束。如果是网卡“狂躁型”故障，则故事还会延续很长时间。因为“狂躁型”病人不理会网络的游戏规则而向网络发送大量非法帧流量，占用带宽，影响所有网络成员。
        不幸的是，狂躁型病人在网络故障统计中所占的比例不是很低！
       
[诊断建议] “网络健康测试”和“网络基准测试”都是为了实时和长时间监测网络流量的变化规律，帮助维护人员掌握网络应用和流量变化的规律，即时发现和处理网络故障。“网络维护方案”中建议健康测试是每日必须测试的内容，要求实时监测网络的流量/利用率、碰撞、广播、错误等基本健康参数，也可以简化监测程序，选择在每天网络最繁忙的一段时间进行测试。这样网络的异常可以被立即发现(因为许多网络故障在网络流量低、比较清闲时并不表现或明显地表现出来)。当然，比较稳妥的方法是对网络进行认证测试。除了布线系统外还对工作的网络进行认证测试。以便在网络投入正常运行前就发现并根除网络存在的故障和潜在的性能问题，最大程度地优化网络的性能。
。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

[故事之二十三]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分钟时间监测一下网络，就完全可以在故障的早期排除之，避免后期重大事故的发生。

。。。。。。。。。。。。。。。。。。。。。。。。。。。

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

[症状]今天的故事发生在某机电进出口公司，网络部主任林先生来电告知他们的网络昨天刚刚进行了升级，从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公司的人员没有将老平台卸载，而是简单地停止启动运行。后继的网管人员在交接时因不熟悉这些协议及其用途，没有进行清理。最近的这次的网络升级工程安装调试时根据原先的网管记录和服务器平台的提示重新安装并启动运行了这些软件。询问负责软件安装的网管人员是否了解这些软件的用途，答曰因为在老平台的窗口中一直看见这些软件，其间也曾询问过一直任职的财务经理，证实有用，所以才重新安装之。实则该平台的设置与新的应用软件之间有严重冲突，并同时干扰现行应用软件的有效工作。两台服务器之间一直在互相询问并重新发送无法处理的无效数据包，除了干扰其它协议外，直接的结果就是占用大量的网络带宽，破坏数据的传输和处理，致使网络速度变慢并时常出错。
        另外，林先生手里的诊断软件都是基于视窗环境的应用软件，无法观察其它应用的流量。
       
[诊断建议]协议的无缝互联和互操作是软件开发工程中的难点。实际的应用软件品质并不如开发商所标榜的那样乐观。为了使网络的工作效率达到最佳，网管人员需要经常监测网络协议数量及其工作状态。对于无用的协议要即时清理之。重要网络在协议监测对新出现的协议还要监测其操作过程，查找其来源。因为许多网络在遭到黑客攻击时常会伴随某些新协议的活动。