网络故障处理案例分析.docx

网络故障处理案例分析网络故障处理案例分析对网络整体结构的掌握,是处理网络故障的前提，下面是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%(这取决于不同的厂商产品质量，也取决于同一厂商的不同系列产品的产品质量)。由于系统中有大量的端口，所以在网络维护周期建议中要求每半年对端口性能进行定期测试。每一～二年对布线系统进行一次轮测，尤其对重要的网络设备如服务器、交换机、路由器等应该坚持定期测试，这样做对提高网络的可靠性有莫大的帮助。[诊断建议] 建议“病人”所有网络设备进行一次普查，将全部端口都进行备案测试，并列入