网络故障处理案例分析

网络故障处理案例分析网络故障处理案例分析对网络整体结构的掌握，是处理网络故障的前提，下面是YJBYS收集的网络故障的案例分析，希望对你有帮助!案例二：［网络故障］某大型化工股份有限公司信息中心报告网络故障，新近进行网络的更新升级和扩容，由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网络测试的'ICMPPing、ScanHost、ICMPMonitor等功能测试，检查其IP协议的工作质量，结果显示正常。这说明，网络连接通道性能是可以的，问题出在协议的5层以上。启动网络测试仪的协议分布侦测功能ProtocolMix，结构发现其AppleTalk和BanyanVines协议流量分别为47%和39%，合计流量为86%。进一步显示运行该协议的是两台主服务器。询问网络部主任网络设计运行的是什么协议，答曰全部是基于视窗环境的单一的IP协议。为何会出现AppleTalk和BanyanVines?答曰根本未知。由于这两种协议有没有参与该公司的业务流程尚且不明，故暂时不能贸然将其删除。必须尽快核实现在的业务软件是否依赖这两种协议。网络部主任告知他是一年前接手网络部主任一职的，对业务流程软件并不熟悉，但知道现在运行各软件的供应商。我们请他立即与该软件开发商联系，15分钟后对方发来传真明确说明该公司的软件只在Windows平台上运行，不支持AppleTalk和BanyanVines等应用平台。为慎重起见，我们请各业务部门的代表集中辨认并统计现在各自所用的操作平台和软件，结果都不包括AppleTalk和BanyanVines。至此，我们决定对该协议平台进行卸载。一边操作一边请林先生查阅以前网络档案，结果发现了这两种平台的安装软盘和应用软件安装软盘。完成协议清理作业后，重新启动网络，网络访问立即恢复正常。［诊断评点］非工作协议是指在网规划和络设计中未被选用的协议和应用，但他们存在于各种网络平台之中。作为网络上的“游魂”之一，他们会耗用少量网络带宽。常用的被捆绑于视窗平台的协议如IPX、IPNetBEUI基本上没有冲突。所以许多用户虽然没有同时使用这几种协议但也会时常同时捆绑这些协议。NetBIOS设置有多种平台协议的输入输出接口，有助于众多协议的交互工作和各种协议平台及其应用的并存。但从网络性能优化的角度看，各种协议平台和应用版本是由不同厂商开发的，兼容性始终是一个动态适应的过程。没有一种始终能紧密跟踪各种协议平台和应用协议变化、相容和协调的有效方法。从这个意义上讲，多协议工作的冲突是不可避免的。翻阅六年前网络档案我们发现，该网络多年以前一直使用的是AppleTalk和BanyanVines平台协议，当时是请ALP国际公司提供的应用软件并负责安装工程。直到三年前才全部安装启用视窗平台和基于IP协议的新的应用软件，但APL公司的人员没有将老平台卸载，而是简单地停止启动运行。后继的网管人员在交接时因不熟悉这些协议及其用途，没有进行清理。最近的这次的网络升级工程安装调试时根据原先的网管记录和服务器平台的提示重新安装并启动运行了这些软件。询问负责软件安装的网管人员是否了解这些软件的用途，答曰因为在老平台的窗口中一直看见这些软件，其间也曾询问过一直任职的财务经理，证实有用，所以才重新安装之。实则该平台的设置与新的应用软件之间有严重冲突，并同时干扰现行应用软件的有效工作。两台服务器之间一直在互相询问并重新发送无法处理的无效数据包，除了干扰其它协议外，直接的结果就是占用大量的网络带宽，破坏数据的传