6,185
社区成员
发帖
与我相关
我的任务
分享请发表友善的回复…
发表回复
520lostheart 2003-12-16
- 打赏
- 举报
thanks very much !
sungod8 2003-12-16
- 打赏
- 举报
网络故障排除荟萃（I）
http://expert.csdn.net/Expert/topic/2569/2569571.xml?temp=.1601679
网络故障排除荟萃（II）
http://expert.csdn.net/Expert/topic/2569/2569599.xml?temp=.5481684
网络故障排除荟萃（III）
http://expert.csdn.net/Expert/topic/2569/2569616.xml?temp=.4895746
http://expert.csdn.net/Expert/topic/2569/2569571.xml?temp=.1601679
网络故障排除荟萃（II）
http://expert.csdn.net/Expert/topic/2569/2569599.xml?temp=.5481684
网络故障排除荟萃（III）
http://expert.csdn.net/Expert/topic/2569/2569616.xml?temp=.4895746
sungod8 2003-12-16
- 打赏
- 举报
嗯,不错:)
lyp_kk 2003-12-16
- 打赏
- 举报
[案例九]网卡故障，用户变“狂人”，网络运行速度变慢
[症状]今天的病人是某大型寻呼公司，刚更新了高速寻呼设备，增加了信息服务的业务内容，并对计算机网络进行了比较大的扩容和调整。调试工程一直比较顺利，但好景不长，刚正式开通工作一天就出现严重问题。技术中心严经理报告的故障现象如下：最初是在工作台上偶尔观察到在键入寻呼的用户数据时键盘更新出现等待现象，后来愈来愈严重，从刚开始的一秒钟左右到现在的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％。这样，网络上的站点处理本机应用程序的速度会受较大影响。有趣的是，很多用户也是在把机器从网络上退出时才发现站点的故障与网络有关。而之前却一直以为是工作站的问题，且最容易被误判为病毒发作。许多网管和网络维护人员通常的做法和遭遇都会象下面所描述的“故事”：首先，启用多种杀毒软件进行查杀毒操作，无效。然后，把所有工作站格式化，重新安装其操作系统和应用软件。但由于问题出在服务器，所以仍然不见效。最后，不得不将所有机器(当然也包括服务器)格式化以后重新安装系统平台及应用软件。如果是服务器网卡驱动程序安装错误(比如安装的驱动程序版本不符合，虽然能工作但不顺畅)，则故事可能因重新安装了正确的驱动程序而到此结束。如果是网卡“狂躁型”故障，则故事还会延续很长时间。因为“狂躁型”病人不理会网络的游戏规则而向网络发送大量非法帧流量，占用带宽，影响所有网络成员。不幸的是，狂躁型病人在网络故障统计中所占的比例不是很低！
[诊断建议]“网络健康测试”和“网络基准测试”都是为了实时和长时间监测网络流量的变化规律，帮助维护人员掌握网络应用和流量变化的规律，即时发现和处理网络故障。“网络维护方案”中建议健康测试是每日必须测试的内容，要求实时监测网络的流量/利用率、碰撞、广播、错误等基本健康参数，也可以简化监测程序，选择在每天网络最繁忙的一段时间进行测试。这样网络的异常可以被立即发现(因为许多网络故障在网络流量低、比较清闲时并不表现或明显地表现出来)。当然，比较稳妥的方法是对网络进行认证测试。除了布线系统外还对工作的网络进行认证测试。以便在网络投入正常运行前就发现并根除网络存在的故障和潜在的性能问题，最大程度地优化网络的性能。
[后记]第二天，我们应邀对该寻呼网作了一次简化程序的网络认证测试，其中流量冲击测试服务器耐受度为100％，如果不是上述故障，该网络性能总评应当是比较优秀的。
lyp_kk 2003-12-16
- 打赏
- 举报
[案例八]中心DNS服务器主板“失常”，占用带宽资源并攻击其它子网的服务器
[症状]有“病人”来电报告网络的一个子网突然变慢，中心主网络则基本正常。以下是“病人”的主述“症状”：“病人”是某市电信多媒体网络服务公司(163、169)，该市为地级市，为本市及市辖县的普通用户提供本地热线网站服务和Internet接入服务。昨天，其服务的用户反映网络速度很慢，Email经常需要等待超过60秒以上的时间才能联通，随即其市营业厅(即子网所在地)报告速度突然变慢，影响业务。“病人”在主机房安装有网管系统，从网管上观察发现除了营业厅子网路由器流量很高以外(测试为97％)，中心网络的路由器与其它子网的交互流量均为40％以下。没有其它特别现象，应该说网络速度不会受影响。由于维护人员没有配备其它网络测试工具，又不能在白天断开网络停止用户服务来进行检查。经人介绍遂请网络医院派员帮助检查。
[诊断过程]这个故障表现比较简单，检查的时候只要查出子网的路由流量来源就可以很快确定故障方向，进一步则立即可以查出流量源。由于用户没有配备分析网络流量的工具，我们估计故障在子网的可能性比较大，所以我们直接驱车驶向子网所在地，即电信营业厅。从网络拓扑图上看，营业厅子网与中心网络的链路为E1，平时作为业务营业厅网络的业务通道。由于营业厅网络一般只用于传输一些业务数据，其子网的网站数量为45台，网管报告97％的流量肯定是过高的。有一种情况可以比较多地占用E1通道的有效流量，那就是营业厅子网有网站与中心网络的网站或服务器之间有多媒体动态图象传输，比如VOD等。这种情况在不少地方发生过，但它要求必须有动态图象源才可以实施“点播”，中心网络目前不可能提供这种服务(但不排除私自安装的可能性)。营业厅网络由于规模小，中心网络的网管系统只支持到路由器一级的管理。交换机和服务器等采用的是廉价的桌面交换机，所以无法支持网络管理。我们将网络测试仪F683接入交换机进行测试，启动便携网管功能，可以看到路由器的流量和网管系统观测的到的流量是相同的，均为97％左右。查看中心网络处与此相连的路由器流量，也是97％左右。这说明路由器通道链路性能基本正常，不过这样高的通道流量必然导致路由器拥塞和丢包，所以从流量的角度看又是不正常的。现在需要了解的是，如此高的路由流量是从哪里来的？数据包到达路由器以后的去向等。这样就可以很快定位导致如此之高的通道流量的数据源和拥塞源。将Fluke的F695网络流量分析仪接入网络的路由器通道进行监测和分析，结果显示95％流量流向了业务数据服务器，且多数为HTTP和Email方面应用(流量分析仪专门分析包括应用层在内的网络上层的协议的应用流量)。其中，Internet访问流量占88％，本地流量占7％。查看流量分析仪指示的流量来源分布图，没有发现集中的流量应用，IP地址分布比较均衡，最高的流量只占0.5％。这些数据表明，用户的应用比例均衡，故障原因应该在应用过程中而不是某个集中的用户“轰击”，比如黑客等。也就是说，应用的过程和通道出了问题。这是因为，这些流量按通道设计不应该到达营业厅网络的业务服务器。而是应该直接从中心网络的Internet主路由器进入互联网。那么，这些流量是如何被引导到营业厅服务器方向上来的呢？我们知道，IP数据包在传输过程中会在路由器中作地址解析(ARP)，或是在本地DNS中进行域名分析。如果这些分析路径出问题，则IP数据包的传输和交换就会出问题。根据流量分析仪的指示，我们任意选择了10个IP地址做路由追踪测试，用Fluke的F683网络测试仪追踪的结果是，他们都要经过一个DNS服务器。而模仿营业厅网络成员分别对已知的本地和外地用户做ICMP监测和路由追踪测试，结果发现，ICMP监测中重定向数据包占82％，目标不可达数据包数量占13％。这表明，只有约2％的用户能一次性出入正常路由到达目标站点，其余95％的IP数据包都要经过路由竞争或重新发送才能有部分机会到达目的地。由此，可以重点检查主路由器的路由表和DNS的转换表。由于多数Internet访问流量被引导到了营业厅业务服务器，所以可以重点检查DNS服务器。用F683网络测试仪对DNS服务器做查询，观察查询结果，发现DNS转换表有相当大的比例指向了营业厅子网中的业务服务器。怀疑是DNS服务器出了问题。我们随机通知中心网络的网管人员将DNS服务器重新启动并快速设置一次，稍后网络管理人员报告网络业务恢复正常。用F683网络测试仪的Internet工具包查询DNS服务器，可以看到指向营业厅业务服务器的数据已经全部消失。这表明网络已经完全恢复了正常工作。但好景不长，约3分钟后，故障重新出现，仍有97％的通道流量被指向了子网。由于DNS服务器只设置了一台，没有备份或备用服务器。我们不得不立即来到中心网络机房，对DNS服务器及其周围设备进行检查。测试服务器网卡和与路由器的电缆，正常。为了不中断服务，我们请网管人员在另一台备用服务器上临时安装设置了DNS服务器。经过短暂的业务中断后，更换上的新DNS服务器开始投入适用。只见子网路由器的流量立刻降低到了1.5％。经过30分钟的稳定工作后，所有用户均恢复到正常工作状态。
[诊断评点]DNS服务器用于将用户域名转换为IP地址，一般来说不会出现什么问题。但由于某些原因，转换地址通通指向了营业厅子网的业务服务器。业务服务器不具备路由处理功能，对发送来的IP数据包要么拒收并置之不理，要么返回目标不可达或需要重定向的报告数据包。这就是我们在ICMP监测时经常观察到的现象。该地区城市中心网络的用户数量不多，与省中心网络的链路带宽为155M的ATM链路，大有富余。所以上Internet的用户其上网速度主要受子网带宽的影响。因为许多的用户要经过拥挤的无效E1链路，造成路由重定向和严重的时延。大量的IP数据包拥向只有2M带宽的子网路由器，流量达到了97％，造成子网工作速度突然变慢，路由器出现严重拥塞等现象。为了确定地址指向的错误原因，我们建议用户抽时间按下列步骤定位故障：首先，将原来的故障DNS服务器的工作平台和应用软件以及网卡驱动程序全部重新安装一遍，然后选择深夜用户数量最少的时候接入网络使用，查看转换表是否正常；其次，如果仍然不正常，则更换网卡，主板等硬件，逐步缩小故障范围。
[诊断建议]基为了防止DNS服务不稳定造成业务中断或出错，不少网管人员在设置DNS服务器时都安装了备用DNS服务器，亦即安装不只一台DNS服务器。但这样做也会带来一个潜在的危险：即主DNS服务器出问题，备用自动服务器投入运行，这样会牺牲一定的网络带宽，使得系统总体性能有所下降。危险在于，性能的下降常常是在不知不觉中来到的。所以，为了保证网络经常处于良好的工作状态，网络管理人员需要定期检查DNS服务器的转换表。这也是“周维护”(即美洲定期维护项目)中建议的内容之一(当然，要保持网络的优良性能不只是检查路由优化性能，还有其它许许多多工作需要做。比如：性能评测、基准测试、通道测试、应用监测、拓扑结果管理、定期维护等等，有关这方面内容读者如感兴趣可参阅《网络测试技术简介》)。本故障中的DNS指向错误导致用户的IP数据包对准了子网服务器，但如果对准的不是服务器而是中心网络本地网段中的某台机器，则故障强度会减弱，用户不会感到非常明显的速度变慢。这样“病人”可能不会感到明显的“身体不适”从而使得网络长期带病运行。就象人一样，定期的体检对及时发现疾病及其隐患是非常必要的。而如何及时发现路由优化方面的问题，也是网络定期项目测试中的内容之一，对大型网络则更有必要，必须坚持定期维护和测试。
许多网络设备如路由器、交换机、只能集线器等都支持SNMP网管功能，但为了全面监测网络通道功能，还需要网络设备支持全面的RMON和RMON2。用这样的设备组建起来的网络其管理和故障诊断功能是很不错的。但现实的问题是，这样的网络设备价格是普通网络设备的6～10倍左右，用户难以接受。因此，为了随时监测网络的服务应用流量及其比例、来源，工作记录以及必要时进行解包分析，建议用户在重要的服务器通道或路由通道上安装监测接口。以便必要时可以随时将流量分析仪、网络测试仪接入通道进行监测和分析。这样，本故障的查找时间可以缩短到20分钟左右。当然，如果资金允许，也可以将流量分析仪长期接入通道对多个重要的网络设备进行全速率透明流量监测，这样可以把故障定位时间缩短到1分钟以内。
[后记]第三天，电话回访“病人”，网络表现一切正常。用户自己已经查明故障设备是原来的DNS服务器的主板。该主板工作不稳定，我们推断该服务器在应用层的数据交换和计算时或与网卡交换数据时出现程序错误。更换另一台DNS服务器的主板后功能恢复正常。“病人”已将修复的DNS服务器设置为在线工作的备用DNS服务器，以提高网络可靠性。
[症状]有“病人”来电报告网络的一个子网突然变慢，中心主网络则基本正常。以下是“病人”的主述“症状”：“病人”是某市电信多媒体网络服务公司(163、169)，该市为地级市，为本市及市辖县的普通用户提供本地热线网站服务和Internet接入服务。昨天，其服务的用户反映网络速度很慢，Email经常需要等待超过60秒以上的时间才能联通，随即其市营业厅(即子网所在地)报告速度突然变慢，影响业务。“病人”在主机房安装有网管系统，从网管上观察发现除了营业厅子网路由器流量很高以外(测试为97％)，中心网络的路由器与其它子网的交互流量均为40％以下。没有其它特别现象，应该说网络速度不会受影响。由于维护人员没有配备其它网络测试工具，又不能在白天断开网络停止用户服务来进行检查。经人介绍遂请网络医院派员帮助检查。
[诊断过程]这个故障表现比较简单，检查的时候只要查出子网的路由流量来源就可以很快确定故障方向，进一步则立即可以查出流量源。由于用户没有配备分析网络流量的工具，我们估计故障在子网的可能性比较大，所以我们直接驱车驶向子网所在地，即电信营业厅。从网络拓扑图上看，营业厅子网与中心网络的链路为E1，平时作为业务营业厅网络的业务通道。由于营业厅网络一般只用于传输一些业务数据，其子网的网站数量为45台，网管报告97％的流量肯定是过高的。有一种情况可以比较多地占用E1通道的有效流量，那就是营业厅子网有网站与中心网络的网站或服务器之间有多媒体动态图象传输，比如VOD等。这种情况在不少地方发生过，但它要求必须有动态图象源才可以实施“点播”，中心网络目前不可能提供这种服务(但不排除私自安装的可能性)。营业厅网络由于规模小，中心网络的网管系统只支持到路由器一级的管理。交换机和服务器等采用的是廉价的桌面交换机，所以无法支持网络管理。我们将网络测试仪F683接入交换机进行测试，启动便携网管功能，可以看到路由器的流量和网管系统观测的到的流量是相同的，均为97％左右。查看中心网络处与此相连的路由器流量，也是97％左右。这说明路由器通道链路性能基本正常，不过这样高的通道流量必然导致路由器拥塞和丢包，所以从流量的角度看又是不正常的。现在需要了解的是，如此高的路由流量是从哪里来的？数据包到达路由器以后的去向等。这样就可以很快定位导致如此之高的通道流量的数据源和拥塞源。将Fluke的F695网络流量分析仪接入网络的路由器通道进行监测和分析，结果显示95％流量流向了业务数据服务器，且多数为HTTP和Email方面应用(流量分析仪专门分析包括应用层在内的网络上层的协议的应用流量)。其中，Internet访问流量占88％，本地流量占7％。查看流量分析仪指示的流量来源分布图，没有发现集中的流量应用，IP地址分布比较均衡，最高的流量只占0.5％。这些数据表明，用户的应用比例均衡，故障原因应该在应用过程中而不是某个集中的用户“轰击”，比如黑客等。也就是说，应用的过程和通道出了问题。这是因为，这些流量按通道设计不应该到达营业厅网络的业务服务器。而是应该直接从中心网络的Internet主路由器进入互联网。那么，这些流量是如何被引导到营业厅服务器方向上来的呢？我们知道，IP数据包在传输过程中会在路由器中作地址解析(ARP)，或是在本地DNS中进行域名分析。如果这些分析路径出问题，则IP数据包的传输和交换就会出问题。根据流量分析仪的指示，我们任意选择了10个IP地址做路由追踪测试，用Fluke的F683网络测试仪追踪的结果是，他们都要经过一个DNS服务器。而模仿营业厅网络成员分别对已知的本地和外地用户做ICMP监测和路由追踪测试，结果发现，ICMP监测中重定向数据包占82％，目标不可达数据包数量占13％。这表明，只有约2％的用户能一次性出入正常路由到达目标站点，其余95％的IP数据包都要经过路由竞争或重新发送才能有部分机会到达目的地。由此，可以重点检查主路由器的路由表和DNS的转换表。由于多数Internet访问流量被引导到了营业厅业务服务器，所以可以重点检查DNS服务器。用F683网络测试仪对DNS服务器做查询，观察查询结果，发现DNS转换表有相当大的比例指向了营业厅子网中的业务服务器。怀疑是DNS服务器出了问题。我们随机通知中心网络的网管人员将DNS服务器重新启动并快速设置一次，稍后网络管理人员报告网络业务恢复正常。用F683网络测试仪的Internet工具包查询DNS服务器，可以看到指向营业厅业务服务器的数据已经全部消失。这表明网络已经完全恢复了正常工作。但好景不长，约3分钟后，故障重新出现，仍有97％的通道流量被指向了子网。由于DNS服务器只设置了一台，没有备份或备用服务器。我们不得不立即来到中心网络机房，对DNS服务器及其周围设备进行检查。测试服务器网卡和与路由器的电缆，正常。为了不中断服务，我们请网管人员在另一台备用服务器上临时安装设置了DNS服务器。经过短暂的业务中断后，更换上的新DNS服务器开始投入适用。只见子网路由器的流量立刻降低到了1.5％。经过30分钟的稳定工作后，所有用户均恢复到正常工作状态。
[诊断评点]DNS服务器用于将用户域名转换为IP地址，一般来说不会出现什么问题。但由于某些原因，转换地址通通指向了营业厅子网的业务服务器。业务服务器不具备路由处理功能，对发送来的IP数据包要么拒收并置之不理，要么返回目标不可达或需要重定向的报告数据包。这就是我们在ICMP监测时经常观察到的现象。该地区城市中心网络的用户数量不多，与省中心网络的链路带宽为155M的ATM链路，大有富余。所以上Internet的用户其上网速度主要受子网带宽的影响。因为许多的用户要经过拥挤的无效E1链路，造成路由重定向和严重的时延。大量的IP数据包拥向只有2M带宽的子网路由器，流量达到了97％，造成子网工作速度突然变慢，路由器出现严重拥塞等现象。为了确定地址指向的错误原因，我们建议用户抽时间按下列步骤定位故障：首先，将原来的故障DNS服务器的工作平台和应用软件以及网卡驱动程序全部重新安装一遍，然后选择深夜用户数量最少的时候接入网络使用，查看转换表是否正常；其次，如果仍然不正常，则更换网卡，主板等硬件，逐步缩小故障范围。
[诊断建议]基为了防止DNS服务不稳定造成业务中断或出错，不少网管人员在设置DNS服务器时都安装了备用DNS服务器，亦即安装不只一台DNS服务器。但这样做也会带来一个潜在的危险：即主DNS服务器出问题，备用自动服务器投入运行，这样会牺牲一定的网络带宽，使得系统总体性能有所下降。危险在于，性能的下降常常是在不知不觉中来到的。所以，为了保证网络经常处于良好的工作状态，网络管理人员需要定期检查DNS服务器的转换表。这也是“周维护”(即美洲定期维护项目)中建议的内容之一(当然，要保持网络的优良性能不只是检查路由优化性能，还有其它许许多多工作需要做。比如：性能评测、基准测试、通道测试、应用监测、拓扑结果管理、定期维护等等，有关这方面内容读者如感兴趣可参阅《网络测试技术简介》)。本故障中的DNS指向错误导致用户的IP数据包对准了子网服务器，但如果对准的不是服务器而是中心网络本地网段中的某台机器，则故障强度会减弱，用户不会感到非常明显的速度变慢。这样“病人”可能不会感到明显的“身体不适”从而使得网络长期带病运行。就象人一样，定期的体检对及时发现疾病及其隐患是非常必要的。而如何及时发现路由优化方面的问题，也是网络定期项目测试中的内容之一，对大型网络则更有必要，必须坚持定期维护和测试。
许多网络设备如路由器、交换机、只能集线器等都支持SNMP网管功能，但为了全面监测网络通道功能，还需要网络设备支持全面的RMON和RMON2。用这样的设备组建起来的网络其管理和故障诊断功能是很不错的。但现实的问题是，这样的网络设备价格是普通网络设备的6～10倍左右，用户难以接受。因此，为了随时监测网络的服务应用流量及其比例、来源，工作记录以及必要时进行解包分析，建议用户在重要的服务器通道或路由通道上安装监测接口。以便必要时可以随时将流量分析仪、网络测试仪接入通道进行监测和分析。这样，本故障的查找时间可以缩短到20分钟左右。当然，如果资金允许，也可以将流量分析仪长期接入通道对多个重要的网络设备进行全速率透明流量监测，这样可以把故障定位时间缩短到1分钟以内。
[后记]第三天，电话回访“病人”，网络表现一切正常。用户自己已经查明故障设备是原来的DNS服务器的主板。该主板工作不稳定，我们推断该服务器在应用层的数据交换和计算时或与网卡交换数据时出现程序错误。更换另一台DNS服务器的主板后功能恢复正常。“病人”已将修复的DNS服务器设置为在线工作的备用DNS服务器，以提高网络可靠性。
lyp_kk 2003-12-16
- 打赏
- 举报
[故事之七]供电质量差，路由器工作不稳定，造成路由漂移和备份路由器拥塞
[症状]今天的“病人”是位居某中心城市的一家大区银行，报告的故障现象是：故障时断时续，呈周期性“发作”，每隔10分钟左右在其辖区内就有部分支行或分行打来电话报告业务流程出现问题。具体表现都很一致：先出现业务中断，1分钟后连接恢复，但速度非常慢。此故障已经持续了2天，网管人员怀疑是路由器故障，曾试着分别更换了备用的同城结算路由器和主路由器，无效。
[诊断过程]我们驱车来到“病人”的计算中心，首先向网络管理人员了解故障情况。基本上与网络医院“接诊”记录报告的内容相同。从表现的故障现象来看，根据以往的经验，基本上可以初步推断是路由链路的问题。网管人员确认，业务中断时，普通Ping测试不通，此现象以前也出现过几次，很快就恢复了。因此也没有引起注意。从记录的故障报告(电话登记)看，无论是本城辖区还是大区内的远程网络都报告过路由中断现象。由于故障每隔10分钟左右就会周期性地出现，虽然比较频繁，却为故障诊断提供了很大方便。可以考虑选择任意路由进行连续的Ping测试，监测其连接状况与故障发生时刻的关系。为此我们将F683网络测试仪接入计算中心网络进行监测。选择曾报告过故障的其下辖的某郊县路由器作连续的ICMP Ping测试，响应时间为9ms，质量尚可。3分钟后，有用户报告故障出现，不过网络测试仪显示正常，说明我们监测的路由链路可能是正常的。立即改变监测方向，向报告遇到故障的用户的路由器做ICMP Monitor，结果大量的目标不可达记录出现，并出现源限制、回应请求和回应响应帧。20秒钟后，出现大量重定向帧记录，目标不可达帧记录速度减缓，源限制、回应请求和回应响应则开始大量出现。以上记录表明，路由器的动态路由表在故障出现时发生了很大变化。网络原来的路由中断后，继之被重定向路由取代。打开静态路由表，为了与动态路由作比较，我们启动F683分段路由追踪功能，追踪从测试仪到先前报告故障的远程路由器。可以看到，路由在本城出口的下一站，即大区链接的第一个路由就发生了中断。动态路由已经由备份路由取代。状态：拥塞。原路由为主路由，通道速率为E1，为ATM链路，备份路由为DDN基本速率链接，速度仅为64Kbps。打开主路由器的Mib库，观测到主路由器的流量为0.02%，错误为2％；表明它处于轻负荷状态，并有少量错误流量。观察备份路由器的Mib库，流量为100％，说明它处于超负荷运行状态。由于故障为周期故障，为了观测它的发生规律，我们在征得“病人”同意的前提下，决定不急于寻找主路由器中断和拥塞的原因，而是先观测在一个周期里故障变化的全过程并记录之。我们用第二台网络测试仪和网络故障一点通接入网络，分别观察主路由器、备份路由器、主服务器的工作流量和错误，并对主路由器作连续的ICMP 监测。约8分钟后，主路由器流量开始迅速上升，备份路由器出现重定向指示，约15秒后报告备份路由器推出优化路由，动态路由表恢复到与静态路由相同的设置。网络完全恢复正常。分析故障关系，可以断定故障的最大关联设备是主路由器。由于用户在机架上已经安装了冷备份的主路由器，我们先将冷备份路由器替换到主路由器的位置。5分钟后路由器更换完毕，开机接入网络，3分钟后网络恢复正常。但只持续了2分钟，故障现象又重新出现。看来，必须对主路由器做详细监测才能发现真正的故障所在。网络建构拓扑是，主路由器与三个外区远程路由器和一个本地路由器相连，我们可以同时监测这几个路由器的工作状况。监测结果如下：故障出现时，外区主路由器和本城路由器的路由表随着故障的出现也发生变化，而此时同城结算业务不受影响。受影响的业务方向是外地与本城、本城与外地、外地经本地跨区等。用Fluke的ATM测试仪测试远程ATM路由通道，将远端ATM交换机Loopback(环回)以后监测三个方向的通道情况，显示完全正常。再对与主路由器相关的连接电缆进行测试，全部合格。这表明主路由器的工作环境是基本正常的。此时我们需要了解主路由器链路中的“垃圾流量”的分布。但由于网络医院的流量分析仪出借给了别的“病人”，所以我们暂时不能观察主路由器的详细流量状况。实际上，我们这是也只需要检查主路由器的接地质量和供电环境即可(因为已经试验更换过主路由器)，这两个因素当中的任何一个不负荷要求，都有可能引发主路由器中断的故障。首先观测为主路由器供电的UPS电源。当故障发生时UPS显示过载，而输出回路却显示轻负荷。用F43电力质量分析仪观察也显示故障时输入谐波超差6倍。输出回路超差400倍，故障恢复后，过载指示也随之消失，但输出回路仍超差80倍。证明UPS电源低效。将主路由器的供电电源接到另一台UPS电源上，故障彻底消失。故障原因为供电质量不合格。我们注意到，该计算中心所在的大楼正在装修，网管人员说等大楼装修完毕后还要将网络设备扩容。初步干扰源很可能就来自与装修有关的部分。由于故障的周期性，经过仔细观察发现，故障出现的周期与楼旁塔吊的上下周期一致！为准确判定谐波干扰的源地点，我们将F43电力质量分析仪接入供电网络进行核实，结果发现，每当塔吊上升时，故障现象就出现(下降时谐波为上升时的三分之一，网络有少许变慢)。
[诊断评点]为主路由器供电的UPS电源由于失效，对外界电力干扰谐波的过滤能力下降，当为重负载的用电设备供电时，此谐波会引发许多设备出错。如果此时恰逢UPS电源滤波失效，则相关设备会受到干扰。本故障中，主路由器由于大量干扰进入，使得链路阻塞，路由器连接中断，路由变更指令使得各业务流量流向备份路由器，备份路由器的路由通道能力又不能满足，致使网络出现拥塞。这就是本次故障先中断后恢复然后阻赛的原因。同城结算数据由于多数不经过主路由器，所以未受到影响。塔吊下降时，虽然引入的干扰也不少，不过因为其干扰的绝对值未超过主路由器的承受范围，所以主路由器还能应付。大楼装修以前也出现过类似的故障，因干扰源很快消失并不再持续存在，因此不可能引起维护人员的注意。
[诊断建议]与电缆和光缆系统一样，电力谐波和UPS电源也是列入定期检查的内容，一般建议作半年定期检查，关键的网络建议作为周定期检查的项目。谐波干扰是经常存在的环境因素，如果此时UPS电源不出问题，一般不会影响网络的正常运行，但谐波干扰是严重影响网络性能的原因之一，一旦窜入网络则引起的故障多数都是“致瘫性”或致命性的。还由于多数用户对干扰类型的故障“相当地”不熟悉，故提请大家引起较多关注。
[后记]更换UPS后，该网络“从此”表现优异。让我们感到欣慰的是，“定期维护”的概念已为“病人”所接受。在网络医院的帮助下，他们制定了详细的网络健康维护方案，确定了定期维护、视情维护的详细规章。其实，这才是网络医院的工作最有价值的一部分。那就是：未雨绸缪，防患于未然。
[症状]今天的“病人”是位居某中心城市的一家大区银行，报告的故障现象是：故障时断时续，呈周期性“发作”，每隔10分钟左右在其辖区内就有部分支行或分行打来电话报告业务流程出现问题。具体表现都很一致：先出现业务中断，1分钟后连接恢复，但速度非常慢。此故障已经持续了2天，网管人员怀疑是路由器故障，曾试着分别更换了备用的同城结算路由器和主路由器，无效。
[诊断过程]我们驱车来到“病人”的计算中心，首先向网络管理人员了解故障情况。基本上与网络医院“接诊”记录报告的内容相同。从表现的故障现象来看，根据以往的经验，基本上可以初步推断是路由链路的问题。网管人员确认，业务中断时，普通Ping测试不通，此现象以前也出现过几次，很快就恢复了。因此也没有引起注意。从记录的故障报告(电话登记)看，无论是本城辖区还是大区内的远程网络都报告过路由中断现象。由于故障每隔10分钟左右就会周期性地出现，虽然比较频繁，却为故障诊断提供了很大方便。可以考虑选择任意路由进行连续的Ping测试，监测其连接状况与故障发生时刻的关系。为此我们将F683网络测试仪接入计算中心网络进行监测。选择曾报告过故障的其下辖的某郊县路由器作连续的ICMP Ping测试，响应时间为9ms，质量尚可。3分钟后，有用户报告故障出现，不过网络测试仪显示正常，说明我们监测的路由链路可能是正常的。立即改变监测方向，向报告遇到故障的用户的路由器做ICMP Monitor，结果大量的目标不可达记录出现，并出现源限制、回应请求和回应响应帧。20秒钟后，出现大量重定向帧记录，目标不可达帧记录速度减缓，源限制、回应请求和回应响应则开始大量出现。以上记录表明，路由器的动态路由表在故障出现时发生了很大变化。网络原来的路由中断后，继之被重定向路由取代。打开静态路由表，为了与动态路由作比较，我们启动F683分段路由追踪功能，追踪从测试仪到先前报告故障的远程路由器。可以看到，路由在本城出口的下一站，即大区链接的第一个路由就发生了中断。动态路由已经由备份路由取代。状态：拥塞。原路由为主路由，通道速率为E1，为ATM链路，备份路由为DDN基本速率链接，速度仅为64Kbps。打开主路由器的Mib库，观测到主路由器的流量为0.02%，错误为2％；表明它处于轻负荷状态，并有少量错误流量。观察备份路由器的Mib库，流量为100％，说明它处于超负荷运行状态。由于故障为周期故障，为了观测它的发生规律，我们在征得“病人”同意的前提下，决定不急于寻找主路由器中断和拥塞的原因，而是先观测在一个周期里故障变化的全过程并记录之。我们用第二台网络测试仪和网络故障一点通接入网络，分别观察主路由器、备份路由器、主服务器的工作流量和错误，并对主路由器作连续的ICMP 监测。约8分钟后，主路由器流量开始迅速上升，备份路由器出现重定向指示，约15秒后报告备份路由器推出优化路由，动态路由表恢复到与静态路由相同的设置。网络完全恢复正常。分析故障关系，可以断定故障的最大关联设备是主路由器。由于用户在机架上已经安装了冷备份的主路由器，我们先将冷备份路由器替换到主路由器的位置。5分钟后路由器更换完毕，开机接入网络，3分钟后网络恢复正常。但只持续了2分钟，故障现象又重新出现。看来，必须对主路由器做详细监测才能发现真正的故障所在。网络建构拓扑是，主路由器与三个外区远程路由器和一个本地路由器相连，我们可以同时监测这几个路由器的工作状况。监测结果如下：故障出现时，外区主路由器和本城路由器的路由表随着故障的出现也发生变化，而此时同城结算业务不受影响。受影响的业务方向是外地与本城、本城与外地、外地经本地跨区等。用Fluke的ATM测试仪测试远程ATM路由通道，将远端ATM交换机Loopback(环回)以后监测三个方向的通道情况，显示完全正常。再对与主路由器相关的连接电缆进行测试，全部合格。这表明主路由器的工作环境是基本正常的。此时我们需要了解主路由器链路中的“垃圾流量”的分布。但由于网络医院的流量分析仪出借给了别的“病人”，所以我们暂时不能观察主路由器的详细流量状况。实际上，我们这是也只需要检查主路由器的接地质量和供电环境即可(因为已经试验更换过主路由器)，这两个因素当中的任何一个不负荷要求，都有可能引发主路由器中断的故障。首先观测为主路由器供电的UPS电源。当故障发生时UPS显示过载，而输出回路却显示轻负荷。用F43电力质量分析仪观察也显示故障时输入谐波超差6倍。输出回路超差400倍，故障恢复后，过载指示也随之消失，但输出回路仍超差80倍。证明UPS电源低效。将主路由器的供电电源接到另一台UPS电源上，故障彻底消失。故障原因为供电质量不合格。我们注意到，该计算中心所在的大楼正在装修，网管人员说等大楼装修完毕后还要将网络设备扩容。初步干扰源很可能就来自与装修有关的部分。由于故障的周期性，经过仔细观察发现，故障出现的周期与楼旁塔吊的上下周期一致！为准确判定谐波干扰的源地点，我们将F43电力质量分析仪接入供电网络进行核实，结果发现，每当塔吊上升时，故障现象就出现(下降时谐波为上升时的三分之一，网络有少许变慢)。
[诊断评点]为主路由器供电的UPS电源由于失效，对外界电力干扰谐波的过滤能力下降，当为重负载的用电设备供电时，此谐波会引发许多设备出错。如果此时恰逢UPS电源滤波失效，则相关设备会受到干扰。本故障中，主路由器由于大量干扰进入，使得链路阻塞，路由器连接中断，路由变更指令使得各业务流量流向备份路由器，备份路由器的路由通道能力又不能满足，致使网络出现拥塞。这就是本次故障先中断后恢复然后阻赛的原因。同城结算数据由于多数不经过主路由器，所以未受到影响。塔吊下降时，虽然引入的干扰也不少，不过因为其干扰的绝对值未超过主路由器的承受范围，所以主路由器还能应付。大楼装修以前也出现过类似的故障，因干扰源很快消失并不再持续存在，因此不可能引起维护人员的注意。
[诊断建议]与电缆和光缆系统一样，电力谐波和UPS电源也是列入定期检查的内容，一般建议作半年定期检查，关键的网络建议作为周定期检查的项目。谐波干扰是经常存在的环境因素，如果此时UPS电源不出问题，一般不会影响网络的正常运行，但谐波干扰是严重影响网络性能的原因之一，一旦窜入网络则引起的故障多数都是“致瘫性”或致命性的。还由于多数用户对干扰类型的故障“相当地”不熟悉，故提请大家引起较多关注。
[后记]更换UPS后，该网络“从此”表现优异。让我们感到欣慰的是，“定期维护”的概念已为“病人”所接受。在网络医院的帮助下，他们制定了详细的网络健康维护方案，确定了定期维护、视情维护的详细规章。其实，这才是网络医院的工作最有价值的一部分。那就是：未雨绸缪，防患于未然。
