6,185
社区成员
发帖
与我相关
我的任务
分享请发表友善的回复…
发表回复
520lostheart 2003-12-16
- 打赏
- 举报
thanks!!
lyp_kk 2003-12-16
- 打赏
- 举报
[案例十二]交换机设置不良，加之雏菊链效应和接头问题，100M升级失败
[症状]某化工交易中心华东公司，今日报告网络从10M升级到100M后，约有一半的工作站无法提速，他们都在同一个楼层。另一楼层的5台工作站则无法入网。另外，两个楼层中都有少数工作站工作速度比升级前更慢，而且并不是对所有的服务器或其它工作站访问都慢，对少数服务器的访问速度还“凑合”。该公司没有配备任何用于网络维护的工具，所以，除了可以观察服务器的CPU利用率以外，只能用软件间接观察网络的流量和碰撞率。观察到的碰撞率偏高的微网段可以达到20％，但不知道该如何处理。据负责网络管理的Lucy小姐介绍，网络升级前所有工作站都是可以接入网络中运行的，只是部分站点速度有些问题，但可以用。公司的网络规模不大，共占有两层半楼面，拥有280台工作站，计算机室配置了三台工作组交换机，分别为三层楼面提供连接。三台交换机通过一台100M集线器共享。路由器一台，也通过工作组交换机连接帧中继网络。交换机下面通过级联100M集线器构成星型结构将链路接口连接到用户桌面。升级工程很简单，将10M交换机更换为100M交换机，10M集线器更换为100M集线器即算大公告成，机架上的设备布局基本按原样安装。用户端则全部更换为100M网卡，施工时间是利用周六、周日两天非业务时间，将全部用户都“搞定”，全部作业都有公司自己的员工负责。完工后抽查了部分工作站，工作状况良好，由此认定升级工程验收合格。可是周一上班，麻烦随之而来。
[诊断过程]该网络的结构比较简单随意，集中反映出的“病症”有三种：一是部分站点不能上网，二是部分站点速度变慢，三是有一半站点不能提速到期望的100M速度。这些其实都是网络升级时经常遇到的问题，也是比较典型的“网络升级症”。
我们将F683网络测试仪首先接入不能上网的站点所在的微网段，观察网络的工作情况。网络搜索的结果显示无法发现这几台工作站，但“Ping”测试却偶尔能有反映。一般来讲，出现此类“病症”的原因基本上是工作站和网络之间的匹配有问题，比如协议不匹配(一致)，驱动程序不匹配，网卡速度不匹配，Link脉冲极性不匹配，链路的接口物理参数不匹配，电缆、光缆规格不匹配(如使用了三类线等)，测试的方法比较简单，可以直接用网络测试仪、网络故障一点通、网络万用表自身具备的接口测试功能直接对网卡、集线器、电缆等进行测试。对5台工作站的网卡逐个进行测试，结果如下：网卡为自适应卡，工作速度10M，交换机端口为100M固定速度半双工设置，双方选用的协议完全匹配，物理电参数测试合格。因而进一步对从配线间到用户之间的电缆链路进行测试，结果发现5台工作站使用的电缆接头均为三类线接头。更换水晶头后用五类线标准测试均合格，5台工作站全部上网成功且速度很快。
用网络测试仪对不能提速的工作站进行测试，当网络测试仪模拟工作站发送5M流量时，用网络故障一点通接收之，显示收到的流量为5Mbps；而当网络测试仪从集线器近旁模拟50M流量发送数据帧时，收到的流量指示仅为10Mbps。这说明，网络只能以10M的实际工作速度运行，不能提速到升级工程实施前所预期的100Mbps的速度。重复上述类似的对网络和工作站的匹配性测试，结果如下：交换机设置为10/100M自适应状态；协议测试显示完全匹配；物理电参数测试全部合格。因此怀疑仍然是链路接头的问题。抽查了10条链路，用DSP4000电缆分析仪进行现场认证测试，结果显示全部链路都不合格。按下电缆分析仪的故障诊断信息健，指示链路的两个接头均不合格。我们注意到这些故障链路都在同一楼层。改用三类线标准测试链路，合格。这说明，该楼层的链路所使用的水晶头问题普遍比较严重。
继续对升级后速度比升级前的部分工作站进行监测，发现他们的流量为1.0％，而碰撞率为87％左右，另有12％左右的FCS帧错误。网络测试仪接入模拟工作站后仪器上的蓝色指示灯亮，说明工作状态是100Mbps。查看Lucy小姐提供网络结构拓扑图，发现速度变慢的用户共有4组17个工作站，他们的100M集线器级联数均达到了4个，出现所谓的雏菊链效应，影响网络的正常工作。碰撞数据尤其是延迟碰撞和FCS错误帧将大量出现。
[诊断评点]该网络出现的问题比较典型，许多网络在升级都会碰到类似的问题。首先，不少交换机产品是10/100M自适应的，交换机可以自动监测网络能够提供的工作速度，然后确定实际的工作速度和工作模式。比如，某些只能交换机现监测接口的链路脉冲，确定链路的连接速度，然后检测接口处的错误率，如果错误率低，则交换机工作在快速的“切发行”交换模式；如果错误率超过门限值，则交换机工作在速度稍慢的“存储转发型”工作模式。另外，一些交换机还允许用户手动设置端口的速度，以固定的速度模式访问网络。
前5台工作站不能上网原因是，工作站链路因使用了假冒伪劣的五类接头(实际指标是三类接头)，工作站只能自适应为10M链路速度，但因该楼层的工作组交换机被手动设置为100M接口状态，所以接口速度无法适应，工作站不能上网连接。
其它不能提速的工作站都在另一台工作组交换机连接的另一楼层，由于交换机没有设置为手动状态，其自适应的结果就是因假冒伪劣插头的限制链路速度被“适应”在了10Mbps的工作速度。部分升级后速度更慢的用户原因在于雏菊链效应的影响。我们知道，10M以太网允许最多4个集线器级联，而100Mbps以太网之允许2个集线器级联。集线器一般不具备自适应能力，所以升级后很容易出现雏菊链效应。此时网络中会时限大量的延迟碰撞以及由此而生成的FCS帧校验序列错误出现，工作站在发送数据帧时常因无法发送完整无错的帧而被迫多次重复发送。除了占用带宽就是增大了有效数据帧的等效延迟时间，表现为用户的速度很可能比升级前更慢。另一些用户则表现为虽然速度有所提高但仍达不道预期的速度。
[诊断建议]建议用户将布线系统进行全面测试，对交换机进行设置，清理有可能出现的雏菊链效应结构，对实在有困难的集线器组则可以考虑增加交换机数量，以便分割和缩短雏菊链。
[后记]两周后随访用户，他们已经全部将不合格的水晶头更换。测试结果显示电缆系统都合格，知道庆幸。由于当初在工程施工时为了抢进度，各楼层的布线工程是由三家不同的工程商同时进行的施工。其中一层全部采用的是假冒伪劣的水晶头，另两层除了5台链路误用不合格水晶头外(具体原因已经无从查起)，全部使用的是合格产品。对雏菊链拓扑的检查共发现7组集线器有“嫌疑”，按照我们的建议，增加了4台工作组交换机，用于分割雏菊链。网络现在工作良好。
lyp_kk 2003-12-16
- 打赏
- 举报
[案例十一]服务器、交换机、工作站工作状态不匹配，访问速度慢
[症状]网络建好了，对于系统集成商来说，设备的安装调试一旦完成，一般都要安排一个小小的庆贺仪式。而对于一家承担过十几项大型工程的系统集成商来说，面对一个400个用户的中型网络，设备调试的工作应该不是难事。但是，直接从庆贺仪式的准备现场赶来网络医院“报警”的病人今天还是第一此遇到。
某著名系统集成商专门负责政府网建设的项目经理罗先生今天十万火急地到网络医院电话急诊，请求紧急支援。原因是下午的“竣工验收”仪式和晚宴已经定好，本工程又是他们公司首次采用六类线电缆系统的样板工程，邀请的十几个重要客人今天下午均会相继“出场”。按原工程计划的进度安排，网络的调试工作用三天时间进行，于前天上午完工。而直到今天上午10:00为止，调试工作因遇到拦路虎，还没有成功通过系统调试。如果今天下午15:00以前不能调试成功，那么请来参观和观摩的客人自不必说，单就企业的声誉来讲，恐怕无可避免地将受到严重影响，且进一步的业务深入也将会受到严重影响。
罗先生反应的网络故障表现很简单：基本上所有的网络成员访问网络资源的速度都非常缓慢，Ping测试联通性表现良好，均在2ms以内，从服务器上拷贝一个20Mbytes的文件竟需要5分钟。调试人员曾试着从相邻的工作站上拷贝一个20Mbytes，对比结果显示同样也需要5分多种的时间。怀疑是操作系统和系统软件平台安装上的问题，特别是服务器安装上的问题。调试人员已经将所有用户重新安装过两遍，凭借以往安装系统的丰富经验，他们十分有把握地保证操作系统和软件平台安装设置没有问题。为了了解数据包在网络中传输的对话情况，又从朋友哪里借了一台协议分析仪对收发包进行测试，结果显示包的收发反应时间基本正常，只是包的转发时间间隔很长，无法进一步确定是哪个环节的问题所至。网络的公共部分是一台10/100核心交换机和三台服务器，服务器直接与核心交换机相连，其它工作站则通过下属的工作组交换机和集线器等与之相连。起初怀疑是交换机的问题，试着更换了一台同型号的交换机，故障依旧。从主代理哪里借来一台服务器作替换试验也无效。
[诊断过程]我们立即随罗先生赶往“事故现场”，10分钟后抵达现场。首先从一台工作站上Ping服务器和任意选定的位子网内其它5台的工作站，响应时间均小于1ms，说明联通性尚可。调试人员怀疑是交换机问题的可能性是存在的，但我们认为证据不足。这是因为从邻近的工作站直接拷贝文件也很慢，这时数据包不经过核心交换机，有的虽通过工作组或桌面交换机，但有的则直接通过集线器。所以故障的公共部位比较可能的是新的布线系统、操作系统和系统软件平台、关键网络设备本身的故障或错误、网卡驱动程序错误等等。用网络测试仪实施流量贯通测试，选择从任意一台工作站到服务器为一条通道，再任意选择该工作站到其它5台工作站直接的通道，共6条测试通道作试验样本。从测试仪上分别发送正常的IP包流量到上述6个对象，流量选定为健康指标的上限值，即40％。用网络一点通在被测试的站点模拟网络设备配合接收流量，结果发现收到的流量都不足1%，且广播包占20％以上。缩短流量贯通路径，直接向邻近的工作站发送流量，结果收到的流量有两种明显的结果。一是流量大量增加，达28%左右，其路径是通过集线器连接的通道，属于正常表现。另一种结果同前面观察到的现象一致，收到约1％左右流量帧。观察收到28％的流量结构，其中92%~98%为碰撞帧，少量FCS帧。由于邻近的工作站是用集线器连接的，发生如此高的碰撞最大的可能性是电缆系统的问题。我们随即测试该六类链路，并任意抽查了其它5条六类线链路，测试全部合格。说明链路的物理联通性是合格的。但因为集线器、交换机等的物理接口是超五类的元件，六类线链路从理论上和厂家的承诺上讲应该与其能兼容。观察用于发送40％流量的网络测试仪自身的流量记录，碰撞率与上面的结果一致，提示该六类线链路可能与10/100M的网络设备阻抗不匹配。如果真是这样的话，那么问题牵涉的范围就比较广泛而且严重了。这是因为这涉及到六类链路与超五类器件的通用性和向下兼容性的问题，而这是六类线电缆厂家承诺和保证的优越性之一：采用五类和超五类设备的网络可以与六类链路任意对接，如果今后需要使用更快速的网络设备，则只要更换支持六类链路的网络设备就可以达到超高速的应用。从网络的表现来看，因为这是首次安装的六类样板链路，并且是在六类链路上挂接超五类端口的网络设备，而网络的表现范围广、现象比较一致：出现大面积内的速度慢故障。协议分析仪解包显示包交换正常，不能证明是网络操作系统和软件平台的问题。所以，安装了影响全局的部分只有六类线布线系统，这也是调试人员重点怀疑的网络部位。我们当然不能由此认定是网络设备端口的问题或是六类线链路与端口不匹配。为了慎重起见，我们用两条超五类线缆连接两台相邻的工作站，再次试验拷贝文件，结果故障依旧。这说明六类线系统不是真正的故障原因。剩下的问题就是需要确认工作站工作协议、配置、驱动程序、物理参数是否与网络匹配了。方法很简单，将在线型网络万用表串入工作站和网络端口(我们分别选择了一个集线器和一台交换机的端口)。结果显示如下：一台工作站的工作速度为100M，端口设置为全双工，而对应的集线器设置为100M半双工；另一台工作站工作速度为100M，端口设置为半双工，对应的交换机设置为半双工。罗先生告知，网络中的网卡使用了三家公司的产品，都是非常知名的厂商。A公司的产品占90％，其余则为B公司的产品，另外，服务器使用的是服务器厂商C公司自己的网卡。我们抽测了A公司的10张网卡，用网络万用表测试，显示设置全部是全双工；而抽测的5张B公司的网卡则全部是半双工设置。我们选择相邻的两台安装了B公司网卡的工作站拷贝文件，结果发现拷贝速度非常快，约3秒钟。接下来我们把两台安装有A公司网卡的相邻工作站改为半双工状态，20Mbytes文件拷贝时间也是3秒钟。
选择被试工作站到服务器的通道，它们通过一台集线器，两台交换机后到达服务器。依次测试链路中的速度和工作状态，结果发现服务器网卡也是全双工设置状态。更改以后试验从服务器上拷贝一个100Mbytes的文件，耗时约13秒。说明性能比较优良。
[诊断评点]故障的原因已经很清楚，该系统集成商选用了三家公司的网卡，而其中的A公司网卡被全部设置为全双工状态，服务器也被偶然地设置为全双工状态。但系统中的交换机、集线器等都工作在半双工状态，所以，凡事安装有A公司网卡的工作站工作速度都很长慢。其它安装了B公司网卡的工作站，虽然自身设置是正确的，但由于数量少，只站不足10％，加之服务器也被设置为全双工状态，所以调试时很可能与A公司或C公司的网卡进行数据对接，这样速度就无法正常。如果偶然地与同类B公司网卡进行数据交换，则调试人员有机会发现虽然所有的工作站与服务器连接速度慢，但并不是所有的工作站之间直接联络时的速度都慢。不过，因为A工商产品数量居多，服务器设置又不正常，所以这样的机会不多。
网卡的协议设置和工作设置会直接影响工作站的速度。一般来讲，工作站的协议设置多数时候不容易出错，但是否与网络的工作协议一致则有时会弄混。比如，工作站使用SMTP协议收发邮件，而网络的邮件服务器使用的是POP协议收发邮件，则工作站将无法进行邮件收发操作。比较容易出错的是10/100M设置状态、全双工半双工设置状态、链路数字脉冲极性选择等，这些方面的错误由于网络维护人员和安装调试人员的有意无意地疏忽，加上没有合适的检测方法和工具，往往会给系统集成商造成很大的麻烦，而故障原因却是如此地简单。很多时候调试人员使用默认设置，并不经常验证实际的状态如何。
本故障的诊断走了一些弯路。因为是新安装的六类线系统，使得故障诊断时有意地倾向于首先怀疑是否是此新系统与100M超五类系统(实际上，超五类系统是为1000M以太网准备的)不匹配方面的问题。如果首先在相邻工作站与交换机或集线器之间检查链路工作状态的检查，则可以在10分钟内找到问题。本故障实际耗时约100分钟，赶在13:00以前收工。
罗先生紧急动员所有调试人员立即检查并调整全部的A公司网卡，只用了不到一个小时就将全部设置改为了半双工状态。
[诊断建议]网络维护人员和部分安装调试人员往往错误地认为网络的维护和管理就是去管理服务器、工作站、打印机等网上设备。这是片面和有害的。其实网络维护人员真正需要下功夫维护和管理的地方是网络设备而不是网上设备。网络设备通常是指路由器、网关、桥、交换机、集线器、广域传输设备、电缆光缆等等。这些是被许多网络维护人员和部分安装调试人员忽视的地方。有的则是因所学专业的限制有意无意地忽视之，特别是对光电参数的验证和测试更是如此。
[后记]15:00正式的验收仪式顺利开始，验收工作非常顺利，在此不表。
[症状]网络建好了，对于系统集成商来说，设备的安装调试一旦完成，一般都要安排一个小小的庆贺仪式。而对于一家承担过十几项大型工程的系统集成商来说，面对一个400个用户的中型网络，设备调试的工作应该不是难事。但是，直接从庆贺仪式的准备现场赶来网络医院“报警”的病人今天还是第一此遇到。
某著名系统集成商专门负责政府网建设的项目经理罗先生今天十万火急地到网络医院电话急诊，请求紧急支援。原因是下午的“竣工验收”仪式和晚宴已经定好，本工程又是他们公司首次采用六类线电缆系统的样板工程，邀请的十几个重要客人今天下午均会相继“出场”。按原工程计划的进度安排，网络的调试工作用三天时间进行，于前天上午完工。而直到今天上午10:00为止，调试工作因遇到拦路虎，还没有成功通过系统调试。如果今天下午15:00以前不能调试成功，那么请来参观和观摩的客人自不必说，单就企业的声誉来讲，恐怕无可避免地将受到严重影响，且进一步的业务深入也将会受到严重影响。
罗先生反应的网络故障表现很简单：基本上所有的网络成员访问网络资源的速度都非常缓慢，Ping测试联通性表现良好，均在2ms以内，从服务器上拷贝一个20Mbytes的文件竟需要5分钟。调试人员曾试着从相邻的工作站上拷贝一个20Mbytes，对比结果显示同样也需要5分多种的时间。怀疑是操作系统和系统软件平台安装上的问题，特别是服务器安装上的问题。调试人员已经将所有用户重新安装过两遍，凭借以往安装系统的丰富经验，他们十分有把握地保证操作系统和软件平台安装设置没有问题。为了了解数据包在网络中传输的对话情况，又从朋友哪里借了一台协议分析仪对收发包进行测试，结果显示包的收发反应时间基本正常，只是包的转发时间间隔很长，无法进一步确定是哪个环节的问题所至。网络的公共部分是一台10/100核心交换机和三台服务器，服务器直接与核心交换机相连，其它工作站则通过下属的工作组交换机和集线器等与之相连。起初怀疑是交换机的问题，试着更换了一台同型号的交换机，故障依旧。从主代理哪里借来一台服务器作替换试验也无效。
[诊断过程]我们立即随罗先生赶往“事故现场”，10分钟后抵达现场。首先从一台工作站上Ping服务器和任意选定的位子网内其它5台的工作站，响应时间均小于1ms，说明联通性尚可。调试人员怀疑是交换机问题的可能性是存在的，但我们认为证据不足。这是因为从邻近的工作站直接拷贝文件也很慢，这时数据包不经过核心交换机，有的虽通过工作组或桌面交换机，但有的则直接通过集线器。所以故障的公共部位比较可能的是新的布线系统、操作系统和系统软件平台、关键网络设备本身的故障或错误、网卡驱动程序错误等等。用网络测试仪实施流量贯通测试，选择从任意一台工作站到服务器为一条通道，再任意选择该工作站到其它5台工作站直接的通道，共6条测试通道作试验样本。从测试仪上分别发送正常的IP包流量到上述6个对象，流量选定为健康指标的上限值，即40％。用网络一点通在被测试的站点模拟网络设备配合接收流量，结果发现收到的流量都不足1%，且广播包占20％以上。缩短流量贯通路径，直接向邻近的工作站发送流量，结果收到的流量有两种明显的结果。一是流量大量增加，达28%左右，其路径是通过集线器连接的通道，属于正常表现。另一种结果同前面观察到的现象一致，收到约1％左右流量帧。观察收到28％的流量结构，其中92%~98%为碰撞帧，少量FCS帧。由于邻近的工作站是用集线器连接的，发生如此高的碰撞最大的可能性是电缆系统的问题。我们随即测试该六类链路，并任意抽查了其它5条六类线链路，测试全部合格。说明链路的物理联通性是合格的。但因为集线器、交换机等的物理接口是超五类的元件，六类线链路从理论上和厂家的承诺上讲应该与其能兼容。观察用于发送40％流量的网络测试仪自身的流量记录，碰撞率与上面的结果一致，提示该六类线链路可能与10/100M的网络设备阻抗不匹配。如果真是这样的话，那么问题牵涉的范围就比较广泛而且严重了。这是因为这涉及到六类链路与超五类器件的通用性和向下兼容性的问题，而这是六类线电缆厂家承诺和保证的优越性之一：采用五类和超五类设备的网络可以与六类链路任意对接，如果今后需要使用更快速的网络设备，则只要更换支持六类链路的网络设备就可以达到超高速的应用。从网络的表现来看，因为这是首次安装的六类样板链路，并且是在六类链路上挂接超五类端口的网络设备，而网络的表现范围广、现象比较一致：出现大面积内的速度慢故障。协议分析仪解包显示包交换正常，不能证明是网络操作系统和软件平台的问题。所以，安装了影响全局的部分只有六类线布线系统，这也是调试人员重点怀疑的网络部位。我们当然不能由此认定是网络设备端口的问题或是六类线链路与端口不匹配。为了慎重起见，我们用两条超五类线缆连接两台相邻的工作站，再次试验拷贝文件，结果故障依旧。这说明六类线系统不是真正的故障原因。剩下的问题就是需要确认工作站工作协议、配置、驱动程序、物理参数是否与网络匹配了。方法很简单，将在线型网络万用表串入工作站和网络端口(我们分别选择了一个集线器和一台交换机的端口)。结果显示如下：一台工作站的工作速度为100M，端口设置为全双工，而对应的集线器设置为100M半双工；另一台工作站工作速度为100M，端口设置为半双工，对应的交换机设置为半双工。罗先生告知，网络中的网卡使用了三家公司的产品，都是非常知名的厂商。A公司的产品占90％，其余则为B公司的产品，另外，服务器使用的是服务器厂商C公司自己的网卡。我们抽测了A公司的10张网卡，用网络万用表测试，显示设置全部是全双工；而抽测的5张B公司的网卡则全部是半双工设置。我们选择相邻的两台安装了B公司网卡的工作站拷贝文件，结果发现拷贝速度非常快，约3秒钟。接下来我们把两台安装有A公司网卡的相邻工作站改为半双工状态，20Mbytes文件拷贝时间也是3秒钟。
选择被试工作站到服务器的通道，它们通过一台集线器，两台交换机后到达服务器。依次测试链路中的速度和工作状态，结果发现服务器网卡也是全双工设置状态。更改以后试验从服务器上拷贝一个100Mbytes的文件，耗时约13秒。说明性能比较优良。
[诊断评点]故障的原因已经很清楚，该系统集成商选用了三家公司的网卡，而其中的A公司网卡被全部设置为全双工状态，服务器也被偶然地设置为全双工状态。但系统中的交换机、集线器等都工作在半双工状态，所以，凡事安装有A公司网卡的工作站工作速度都很长慢。其它安装了B公司网卡的工作站，虽然自身设置是正确的，但由于数量少，只站不足10％，加之服务器也被设置为全双工状态，所以调试时很可能与A公司或C公司的网卡进行数据对接，这样速度就无法正常。如果偶然地与同类B公司网卡进行数据交换，则调试人员有机会发现虽然所有的工作站与服务器连接速度慢，但并不是所有的工作站之间直接联络时的速度都慢。不过，因为A工商产品数量居多，服务器设置又不正常，所以这样的机会不多。
网卡的协议设置和工作设置会直接影响工作站的速度。一般来讲，工作站的协议设置多数时候不容易出错，但是否与网络的工作协议一致则有时会弄混。比如，工作站使用SMTP协议收发邮件，而网络的邮件服务器使用的是POP协议收发邮件，则工作站将无法进行邮件收发操作。比较容易出错的是10/100M设置状态、全双工半双工设置状态、链路数字脉冲极性选择等，这些方面的错误由于网络维护人员和安装调试人员的有意无意地疏忽，加上没有合适的检测方法和工具，往往会给系统集成商造成很大的麻烦，而故障原因却是如此地简单。很多时候调试人员使用默认设置，并不经常验证实际的状态如何。
本故障的诊断走了一些弯路。因为是新安装的六类线系统，使得故障诊断时有意地倾向于首先怀疑是否是此新系统与100M超五类系统(实际上，超五类系统是为1000M以太网准备的)不匹配方面的问题。如果首先在相邻工作站与交换机或集线器之间检查链路工作状态的检查，则可以在10分钟内找到问题。本故障实际耗时约100分钟，赶在13:00以前收工。
罗先生紧急动员所有调试人员立即检查并调整全部的A公司网卡，只用了不到一个小时就将全部设置改为了半双工状态。
[诊断建议]网络维护人员和部分安装调试人员往往错误地认为网络的维护和管理就是去管理服务器、工作站、打印机等网上设备。这是片面和有害的。其实网络维护人员真正需要下功夫维护和管理的地方是网络设备而不是网上设备。网络设备通常是指路由器、网关、桥、交换机、集线器、广域传输设备、电缆光缆等等。这些是被许多网络维护人员和部分安装调试人员忽视的地方。有的则是因所学专业的限制有意无意地忽视之，特别是对光电参数的验证和测试更是如此。
[后记]15:00正式的验收仪式顺利开始，验收工作非常顺利，在此不表。
lyp_kk 2003-12-16
- 打赏
- 举报
[案例十]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分钟时间监测一下网络，就完全可以在故障的早期排除之，避免后期重大事故的发生。
[后记]我们担心的“病毒”至今没有出现。
[症状]今天是五一节假期的最后一天，某大型铁路枢纽站来电，报告其售票系统出现很大问题，最先是枢纽所在局本地的售票系统报告售票速度比平时慢几倍，车站售票厅前已经排起了长队，乘客意见很大。其它市内预售处也受到影响，出票速度也很慢。随后，是各联网局均有报告网络的票务查询速度慢，邻近局报告更频繁一些。维护人员认为是中心票务服务器有问题，随即决定系统暂停业务并将备份服务器很快启动投入系统运行，非但未能见效，反而速度更加缓慢。急招该系统的工程集成商立刻处理系统问题，观察中心票务服务器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分钟时间监测一下网络，就完全可以在故障的早期排除之，避免后期重大事故的发生。
[后记]我们担心的“病毒”至今没有出现。
