免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
楼主: ciolmy
打印 上一主题 下一主题

网络医院的故事----连载 [复制链接]

论坛徽章:
0
81 [报告]
发表于 2006-10-05 11:43 |只看该作者
[诊断过程]网络医院接报后立即赶往票务中心计算机网络的机房,网管人员告知在节日期间已经出现过类似的现象,只是持续的时间不很长(有时会持续2小时左右),速度虽有变慢,但基本上不影响出票速度。经过与网关人员和系统集成商的工程技术人员简单交流后,分析故障原因可能有五,一是票务结算软件问题;二是病毒或内部人员尤其是网络管理人员误操作或更改设置,比如删除不应该删除的文件,私自在系统上运行了冲突软件或破坏性软件;三是系统平台故障,比如NT平台受到干扰后出现硬损伤(指不能恢复的改变,必须重新安装系统才能正常运行);四是网络设备问题,五是其它网络问题。由于已经更换过票务服务器和交换机等网络设备,所以先暂不考虑第一、四种可能性;为了节省故障诊断时间,暂不考虑第二、三种可能性(如对系统进行一次详细检查和协议测试或重新安装一次NT平台并做好相应的设置、数据恢复等需要较长时间),而首先就第五种可能性对网络进行测试。查看其它服务器CPU资源利用率,都在25%以下。\r\n        查看网络拓扑结构图,将网络测试仪F683随即接入网络中的一台工作组交换机,观察整个网络的工作情况。先查看网络设备的工作情况,显示交换机、路由器等本身均正常。核心交换机与票务服务器的连接端口为第二插曹第7端口,设置为100Mbps,流量实测为84%,偏高。查看整个网段的MAC对话矩阵,也显示票务服务器的访问流量很高,进一步查看IP对话矩阵,与MAC矩阵基本一致,比其它对话矩阵中的成员高出500倍以上。追查访问的数据来源,发现一台内部账务处理PC机与票务服务器之间的对话流量很高。从MAC矩阵上观察其流量很高,从IP矩阵上观察流量稍低于MAC流量。为了提高处理速度,票务服务器按设计是直接与核心交换机相连的,而账务处理用的PC机通过桌面交换机—工作组交换机—核心交换机后与票务服务器相连。询问票务处理PC机的操作人员,答曰节前该机工作就不正常,速度慢。曾向网络维护人员报告过故障,但因邻近节日,维护工作量大,维护人员计划待节日以后再处理账务PC机的问题。\r\n        将账务PC关机,系统故障立即消失,整个系统恢复正常,一片欢呼。为了确认该PC机具体的故障位置,将其移动到局办公网上接入网络,重新设置后工作正常!!!为了慎重起见,网管人员还是决定启用一台新机器代替账务PC接入网络,同时观察网络的工作状态。发现网络完全恢复正常,故障排除。\r\n        用网络测试仪测试办公网,流量为2%,很低,无错误数据包。将集线器串入账务PC与交换机的连接通道,用网络测试仪和协议分析仪接入观察。从F683网络测试仪上观察,显示网络流量为79%!!错误37%(其中90%为长帧,其余为短帧),网络测试仪指示流量来源于账务PC,数据包中有约36%左右指向了一个未知的IP地址,其它数据包虽然指向该地址但来源地址比较混乱且无规律可循,协议分析仪上解析的地址经网管人员确认后证实36%的指向地址是票务服务器的IP地址,其它来源地址也是原票务网中地址范围内的地址。如果该PC机携带能模仿IP地址的病毒程序,则原系统有可能还会发生类似故障,所以我们先将账务工作站PC的网卡更换,更换后该机表现正常(说明病毒在捣乱的可能性很小),不再发送非法帧。将故障网卡重新安装驱动程序,故障现象依旧,集线器上测试的错误仍是长帧和短帧,再次表明网卡本身故障的可能性最大,病毒感染的可能性很小。

论坛徽章:
0
82 [报告]
发表于 2006-10-05 11:43 |只看该作者
[诊断评点]现在可以让我们来事后模拟叙述一下整个网络故障的进程。以便读者了解故障的进程和原因。\r\n票务网络中的一台不起眼的工作站的网卡发生了故障。最初的故障发生于节日前,故障现象是发送错误帧。由于工作站与桌面交换机相连,而该桌面交换机是存储转发型性交换机,所以发送的错误帧被交换机过滤掉了。所以这些错误帧只能对本工作站造成影响,对网络不构成威胁。随着网卡的进一步物理性损坏,网卡变得不能清除发送过的IP地址,并将目标地址“定格”在访问联系最多的票务服务器,开始发送不受限制的数据包。这些数据包不断请求票务服务器处理重复查询计算同一张票的出票业务。由于其不受发送速度的限制(即该网卡不管网络流量是否超高,都会不加理会地向网络发送流量),网络中的交换机随即将大量的垃圾包送往票务服务器,占用大量网络带宽资源,同时迫使票务服务器消耗大量资源处理这些垃圾包,使得其它正常的网络访问受阻。还由于这些数据包的可操作性很差,服务器会进一步耗用额外的资源来处理这些数据。\r\n        在上一篇故事中我们曾提到过,网卡故障后有两类基本的表现,一类是安静型,即不再进行正常的网络通信并且不再向网络发送任何数据,这是比较友好的“醉汉”。对网络基本上没有破坏性。另一类是“狂躁型”,发生故障后向网络发送不受限制的数据包。这些数据包可能是正常格式的,也可能是非正常格式的(即错误数据包)。两种格式的数据包都可能对网络性能造成严重影响甚至破坏。错误格式的数据包一般不能通过存储转发型的交换机,所以本故障的网络监测看不到错误数据包,只能看到正常格式的故障数据包。当接入集线器后才可以观察到错误数据包。

论坛徽章:
0
83 [报告]
发表于 2006-10-05 11:43 |只看该作者
[诊断建议]该网络由于系统成员数量少,在建网规划时没有配备网管系统和测试工具。所以故障早期没有任何超流量报警信号提示,这对于网络故障的迅速定位和排除是不利的。现存的许多网络在维护工作中都基本上采取事后维护的方法,即出了问题才去查找和处理,这对于可靠性要求高的网络是非常危险的。因为我们不能侥幸地“期盼”不管是网络设备,还是网上设备,他们出了问题以后都表现为“安静型”。只有坚持定期地对网络进行监测才是避免重大网络事故的有力措施。其实在本例中,如果每日坚持用3分钟时间监测一下网络,就完全可以在故障的早期排除之,避免后期重大事故的发生。

论坛徽章:
0
84 [报告]
发表于 2006-10-05 11:44 |只看该作者
[诊断过程]这个故障看起来比较简单,实际诊断却颇费周折。该网络由4个路由器经帧中继线路与国内总部和国际分部链接,占据4层楼面,由2台千兆核心交换机和二级5台工作组交换机(每层一台)以及20台桌面交换机(每层4台)组成,100M交换到桌面,结构比较典型。从故障现象看,网络联通性尚可,但速度受影响。一般来说,速度慢的原因有很多,比如网上设备速度跟不上要求,网络设备出现阻塞或瓶颈效应,电缆光缆系统问题使得网络数据出错或产生高额碰撞,网络协议设置错误造成无效的重复访问,应用软件或协议设置错误访问受阻等等。由于刚更新了网络,原来的电缆系统又没有经过认证测试,根据以往的经验,电缆系统存在问题的可能性最大,所以我们决定先检查电缆系统。鉴于所有网络成员都有速度问题,我们先抽取部分电缆尤其是主要服务器的网络电缆进行现场认证测试。\r\n        系统电缆采用的是超五类线,用电缆认证测试仪测试20条电缆链路,结果出伏出乎意料地全部合格!改用网络测试仪对抽测的电缆人工模拟发送流量,结果当发送至75%流量时,碰撞率仍不超过5%,表明网络布线系统虽然在工程完工后没有进行认证测试,但电缆品质和施工品质还是不错的,实属少见。转而进行网络健康指标评测,除了服务器流量严重超标以外,其它如错误、碰撞、广播等都合格。检测流量分布,基本上都集中在服务器链路上,平均流量达91%。令任意两台工作站之间进行拷贝文件操作,速度很快。说明问题很可能就出在服务器与工作站的协议流程障碍上。启动F683网络测试的ICMP Ping、Scan Host、ICMP Monitor等功能测试,检查其IP协议的工作质量,结果显示正常。这说明,网络连接通道性能是可以的,问题出在协议的5层以上。\r\n        启动网络测试仪的协议分布侦测功能Protocol Mix,结构发现其Apple Talk和BanyanVines协议流量分别为47%和39%,合计流量为86%。进一步显示运行该协议的是两台主服务器。询问林先生网络设计运行的是什么协议,答曰全部是基于视窗环境的单一的IP协议。为何会出现Apple Talk和Banyan Vines?答曰根本未知。\r\n        由于这两种协议有没有参与该公司的业务流程尚且不明,故暂时不能贸然将其删除。必须尽快核实现在的业务软件是否依赖这两种协议。林先生告知他是一年前接手网络部主任一职的,对业务流程软件并不熟悉,但知道现在运行各软件的供应商。我们请他立即与该软件开发商联系,15分钟后对方发来传真明确说明该公司的软件只在Windows平台上运行,不支持Apple Talk和Banyan Vines等应用平台。为慎重起见,我们请各业务部门的代表集中辨认并统计现在各自所用的操作平台和软件,结果都不包括Apple Talk和Banyan  Vines。至此,我们决定对该协议平台进行卸载。一边操作一边请林先生查阅以前网络档案,结果发现了这两种平台的安装软盘和应用软件安装软盘。\r\n        完成协议清理作业后,重新启动网络,网络访问立即恢复正常。

论坛徽章:
0
85 [报告]
发表于 2006-10-05 11:44 |只看该作者
[诊断评点]非工作协议是指在网规划和络设计中未被选用的协议和应用,但他们存在于各种网络平台之中。作为网络上的“游魂”之一,他们会耗用少量网络带宽。常用的被捆绑于视窗平台的协议如IPX、IP、NetBEUI基本上没有冲突。所以许多用户虽然没有同时使用这几种协议但也会时常同时捆绑这些协议。NetBIOS设置有多种平台协议的输入输出接口,有助于众多协议的交互工作和各种协议平台及其应用的并存。但从网络性能优化的角度看,各种协议平台和应用版本是由不同厂商开发的,兼容性始终是一个动态适应的过程。没有一种始终能紧密跟踪各种协议平台和应用协议变化、相容和协调的有效方法。从这个意义上讲,多协议工作的冲突是不可避免的。\r\n翻阅六年前网络档案我们发现,该网络多年以前一直使用的是Apple Talk和Banyan Vines平台协议,当时是请ALP国际公司提供的应用软件并负责安装工程。直到三年前才全部安装启用视窗平台和基于IP协议的新的应用软件,但APL公司的人员没有将老平台卸载,而是简单地停止启动运行。后继的网管人员在交接时因不熟悉这些协议及其用途,没有进行清理。最近的这次的网络升级工程安装调试时根据原先的网管记录和服务器平台的提示重新安装并启动运行了这些软件。询问负责软件安装的网管人员是否了解这些软件的用途,答曰因为在老平台的窗口中一直看见这些软件,其间也曾询问过一直任职的财务经理,证实有用,所以才重新安装之。实则该平台的设置与新的应用软件之间有严重冲突,并同时干扰现行应用软件的有效工作。两台服务器之间一直在互相询问并重新发送无法处理的无效数据包,除了干扰其它协议外,直接的结果就是占用大量的网络带宽,破坏数据的传输和处理,致使网络速度变慢并时常出错。\r\n        另外,林先生手里的诊断软件都是基于视窗环境的应用软件,无法观察其它应用的流量。\r\n        \r\n[诊断建议]协议的无缝互联和互操作是软件开发工程中的难点。实际的应用软件品质并不如开发商所标榜的那样乐观。为了使网络的工作效率达到最佳,网管人员需要经常监测网络协议数量及其工作状态。对于无用的协议要即时清理之。重要网络在协议监测对新出现的协议还要监测其操作过程,查找其来源。因为许多网络在遭到黑客攻击时常会伴随某些新协议的活动。

论坛徽章:
0
86 [报告]
发表于 2006-10-05 11:45 |只看该作者
[故事之二十五]千兆网升级工程,主服务器不可用,自制跳线RL参数不合格        \r\n\r\n[症状]某知名的大型电信产品开发商,最近对网络进行了升级,其负责通信及计算机网络的IT经理Grace小姐今天向网络医院报告,有数台新安装的服务器基本不能用,其它服务器也偶尔存在数据出错和访问速度停顿的问题,有的明显,有的则不太明显。在网络用户少时,对服务器进行Ping测试一般都能通过,但用户数量稍微增加时则有10%~30%的Ping测试损失。这几台服务器即使在用户数量很少时,也不能很好地登录和访问。奇怪的是,登录过程有时候很顺利,有时候则根本无法登录,等待时间最高能达到5分钟,方能进入。\r\n骨干网原计划用ATM架构,后更改设计为千兆以太网交换机作骨干交换机。公司总部所在大厦内的用户近3000个,楼高28层,每层用一台千兆以太网交换机作为核心交换机,下面则只设一级100兆工作组交换机,然后直接100兆交换到桌面。服务器安装的都是千兆以太网卡,直接与各层分布的千兆以太网交换机相连。网络维护人员对服务器工作平台进行了多次彻底地检查,并重新安装了工作平台,但现象依旧。经人指点,曾经怀疑是电缆问题,遂对相关的服务器连接电缆全部用Fluke公司的DSP100电缆测试仪进行了测试,结果都合格。试着更换部分电缆,无效。观察这几台服务器,多数时候访问流量不足1%。不知道何故?

论坛徽章:
0
87 [报告]
发表于 2006-10-05 11:45 |只看该作者
[诊断过程]服务器访问受阻,而且是同时有几台受阻,这其中的故障原因必定有某些共性存在。Grace告知,本次新安装的服务器共有17台,其中7台有明显问题,另10台大致正常。负责安装的是同一个人,由公司资深网络工程师潘先生直接执行,应该不存在由于安装上的差异而导致部分可用部分不可用的问题。\r\n        我们将网络测试仪接入用户端对网络工作状态进行初步了解。观察有明显连接问题的7台服务器与交换机的连接端口,发现流量均低于1%,但延迟数据包的比例很高,占86%~93%左右,错误的FCS帧比例也不低,约为5%~11%左右。这说明确实有大量的数据包指向了服务器而服务器却没有理会。另外的5%~11%的FCS错误数据包则可能来自服务器。对准服务器做ICMP Ping测试,损失约为90%~100%之间。以上故障提示电缆问题和电缆与服务器、交换机的接口物理性能有问题。用DSP-4000电缆分析仪测试服务器与交换机之间的硬跳线,7台有问题的服务器均显示回波损耗RL(Return Loss)参数不合格!继续测试另10台服务器与交换机的跳线,其回波损耗RL参数也全部不合格!用电缆分析仪定位的RL不合格点就在跳线电缆的端头处。故重新制作接头并测试,仍不合格。换用我们随身携带的软跳线接入一台服务器,服务器工作立刻恢复正常。看来确实是跳线电缆的问题。用我们提供的合格接头重新制作一段跳线,测试还是不合格。由此可知,问题出在跳线材料上。我们将随身携带的仅有的4根软跳线接入其中4台服务器中,这4台服务器全部恢复正常。用DSP4000选择五类线测试标准对电缆进行测试,全部合格。查看电缆外包皮则为Cat5e。

论坛徽章:
0
88 [报告]
发表于 2006-10-05 11:45 |只看该作者
[诊断评点]我们知道,电缆内有4对双绞线,在千兆以太网链路中,由于采用是4对线全双工5电平编码工作方式,每对负担250Mbps的双向数据流量,实际的信号等效物理带宽为100MHz,也就是说,五类线就基本可以满足千兆以太网的链路要求。实际使用当中则不然,千兆以太网对其它参数的要求更高,故一般建议使用超五类线承载千兆以太网应用。五类线则一般限于100兆以太网和ATM155等以内的速率应用。如果打算用五类线运行千兆以太网,则必须增加几项测试参数。Grace介绍他们采用的是超五类电缆,但经过DSP4000电缆分析仪实地认证测试证明只是五类电缆而已,也就是说Grace采用的是用五类线仿冒的超五类线。改用Cat5n标准测试,仍然不合格。这表明他们选用的五类线芯的品质本身也比较差,不能通过五类线的千兆应用标准Cat5n测试。这是因为,正规厂商提供的五类线在增加的千兆应用Cat5n标准测试中,不合格的产品比例一般都不会超过20%。\r\n        DSP100电缆测试仪只能测试五类线,所以测试结果全部合格。但工程设计采用的是超五类线,所以该仿冒的超五类线经DSP4000电缆分析仪测试被判为不合格。\r\n        4台不合格的跳线,长度均在2米以内,而另10台工作不良的服务器,与交换机的连接长度均在15米以上。这也是回波损耗RL不合格的典型表现:\r\n即在RL不合格的链路中,电缆越短故障症状越严重。这是因为,RL不合格将会导致信号反射增加,短链路的衰减量小,所以,反射的能量大多数会在链路的另一段在此反射从而叠加到中常的数据信号之中,造成信号的大量畸变,反映为错误的FCS帧,另一方面,访问服务器的流量由于无法正常传递到服务器,反映到交换机则是大量的延迟帧累积。在较长的不合格RL链路中,由于信号的衰减较大,多数反射能量不能有效地叠加到正常信号之上,所以故障症状会轻一些,表现为错误较高或间歇性的停顿,尤其是流量高时错误帧较高,停顿频繁,但一般不会全部数据包都通不过链路。用户登录网络时受当时的平均流量和瞬间流量影响都很大,表现为登录时间的大幅度摆动,有时会比较顺利,因为此时的瞬间流量和平均流量都低,有时则表现为长时间等待,此时的平均流量或瞬间流量高,错误操作和重复操作大量出现。\r\n        \r\n[诊断建议]鉴于Grace采用的电缆为仿冒的超五类线,加之其它服务器也偶尔有数据错误和停顿的表现,故建议她将所有的服务器超五类链路重新进行检查,以确保网络的工作质量。

论坛徽章:
0
89 [报告]
发表于 2006-10-05 11:45 |只看该作者
[故事之二十六]交换机设置不良,加之雏菊链效应和接头问题,100M升级失败\r\n        \r\n[症状]某化工交易中心华东公司,今日报告网络从10M升级到100M后,约有一半的工作站无法提速,他们都在同一个楼层。另一楼层的5台工作站则无法入网。另外,两个楼层中都有少数工作站工作速度比升级前更慢,而且并不是对所有的服务器或其它工作站访问都慢,对少数服务器的访问速度还“凑合”。该公司没有配备任何用于网络维护的工具,所以,除了可以观察服务器的CPU利用率以外,只能用软件间接观察网络的流量和碰撞率。观察到的碰撞率偏高的微网段可以达到20%,但不知道该如何处理。\r\n        据负责网络管理的Lucy小姐介绍,网络升级前所有工作站都是可以接入网络中运行的,只是部分站点速度有些问题,但可以用。公司的网络规模不大,共占有两层半楼面,拥有280台工作站,计算机室配置了三台工作组交换机,分别为三层楼面提供连接。三台交换机通过一台100M集线器共享。路由器一台,也通过工作组交换机连接帧中继网络。交换机下面通过级联100M集线器构成星型结构将链路接口连接到用户桌面。\r\n升级工程很简单,将10M交换机更换为100M交换机,10M集线器更换为100M集线器即算大公告成,机架上的设备布局基本按原样安装。用户端则全部更换为100M网卡,施工时间是利用周六、周日两天非业务时间,将全部用户都“搞定”,全部作业都有公司自己的员工负责。完工后抽查了部分工作站,工作状况良好,由此认定升级工程验收合格。可是周一上班,麻烦随之而来。

论坛徽章:
0
90 [报告]
发表于 2006-10-05 11:45 |只看该作者
[诊断过程]该网络的结构比较简单随意,集中反映出的“病症”有三种:一是部分站点不能上网,二是部分站点速度变慢,三是有一半站点不能提速到期望的100M速度。这些其实都是网络升级时经常遇到的问题,也是比较典型的“网络升级症”。\r\n        我们将F683网络测试仪首先接入不能上网的站点所在的微网段,观察网络的工作情况。网络搜索的结果显示无法发现这几台工作站,但“Ping”测试却偶尔能有反映。一般来讲,出现此类“病症”的原因基本上是工作站和网络之间的匹配有问题,比如协议不匹配(一致),驱动程序不匹配,网卡速度不匹配,Link脉冲极性不匹配,链路的接口物理参数不匹配,电缆、光缆规格不匹配(如使用了三类线等),测试的方法比较简单,可以直接用网络测试仪、网络故障一点通、网络万用表自身具备的接口测试功能直接对网卡、集线器、电缆等进行测试。对5台工作站的网卡逐个进行测试,结果如下:网卡为自适应卡,工作速度10M,交换机端口为100M固定速度半双工设置,双方选用的协议完全匹配,物理电参数测试合格。因而进一步对从配线间到用户之间的电缆链路进行测试,结果发现5台工作站使用的电缆接头均为三类线接头。更换水晶头后用五类线标准测试均合格,5台工作站全部上网成功且速度很快。\r\n        用网络测试仪对不能提速的工作站进行测试,当网络测试仪模拟工作站发送5M流量时,用网络故障一点通接收之,显示收到的流量为5Mbps;而当网络测试仪从集线器近旁模拟50M流量发送数据帧时,收到的流量指示仅为10Mbps。这说明,网络只能以10M的实际工作速度运行,不能提速到升级工程实施前所预期的100Mbps的速度。重复上述类似的对网络和工作站的匹配性测试,结果如下:交换机设置为10/100M自适应状态;协议测试显示完全匹配;物理电参数测试全部合格。因此怀疑仍然是链路接头的问题。抽查了10条链路,用DSP4000电缆分析仪进行现场认证测试,结果显示全部链路都不合格。按下电缆分析仪的故障诊断信息健,指示链路的两个接头均不合格。我们注意到这些故障链路都在同一楼层。改用三类线标准测试链路,合格。这说明,该楼层的链路所使用的水晶头问题普遍比较严重。\r\n        继续对升级后速度比升级前的部分工作站进行监测,发现他们的流量为1.0%,而碰撞率为87%左右,另有12%左右的FCS帧错误。网络测试仪接入模拟工作站后仪器上的蓝色指示灯亮,说明工作状态是100Mbps。查看Lucy小姐提供网络结构拓扑图,发现速度变慢的用户共有4组17个工作站,他们的100M集线器级联数均达到了4个,出现所谓的雏菊链效应,影响网络的正常工作。碰撞数据尤其是延迟碰撞和FCS错误帧将大量出现。
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP