网络医院的故事----连载

ciolmy

[故事之十五]私自运行Proxy发生冲突，服务器响应速度“变慢”，网虫太“勤快”\r\n\r\n[症状]某市工商局信息中心今日向网络医院“报案”，报告其关键的企业数据服务器经常出现“阻塞”，起因是分布在各地的各个业务受理局、所等的工作人员时常向信息中心抱怨在进行企业数据调用、核查和进行新企业登记操作时经常遇到“梗阻”，速度变慢或业务出现暂时性的停顿的现象。由于故障现象不是持续存在，虽然检查过多次，也杀过多次“毒”，更换速度更快的服务器后情况好转，但未从根本上能解决问题，始终没有找到真正的“病根”所在。要求帮助查找“元凶”。\r\n走进该工商信息中心崭新明亮的机房，可以看到正面的墙上有一幅巨大的网络结构拓扑示意图，上面非常清楚的标明了各种网上设备和网络设备的型号、名称、位置、速度、链路类型和连接关系等等。初步感觉这样的网络器管理水平应该是不错的。\r\n但，经过了解获知，目前实际的网络的结构比较特殊，与拓扑图上的结构有较大区别：用于业务网的大部分机器还设在旧的信息中心机房中，只有企业数据服务器等关键设备安装在新工商大厦的信息中心机房中，且同办公网连通。新大厦和旧信息中心相距约2000米，中间通过光缆和路由器连接起来，并在办公网侧设置了防火墙。办公网的多数用户都可以通过WAN链路访问internet国际互联网。信息中心主任对此的解释是：按工程规划的要求，需要把原信息中心机房的全部设备和人员搬迁到新大厦的信息中心机房，但因发现新大厦存在建筑质量问题，两个月前只搬迁了少部分设备和绝大部分的人员。为了不影响业务，在对设备采取临时性的重新布局后即投入了运行。工作状况一直正常。多数业务设备还留在了旧机房中，由2名留守人员负责管理。大约一个月前开始出现故障征兆。\r\n该信息中心负责下辖8个工商分局，76个工商所的网络连接和业务保障工作。局和分局之间用帧中继链路连接，工商所和分局之间用DDN、ISDN连接，少数用拨号方式连接。业务网与办公网之间用防火墙隔离。业务网中的用户除分局的少数用户外按设计要求均不能上互联网。

ciolmy

[诊断过程]从安装在办公网中的网管系统上观察，企业数据服务器流量为28％，属正常。就近从办公网用网络测试仪F683对服务器进行连通性测试，损失率为0％。这说明至少在此时此刻服务器是工作状态是不错的。用网络助理(网络一点通)对服务器发送10％的流量，观察服务器的使用情况。从数据包交换对话矩阵中发现，服务器对办公网中的用户均有响应，而对原业务网中的用户则有少数几个“不响应”的记录。由此可以推断故障原因绝大多数可能还在原业务网中。\r\n        将网络测试仪移动到信息中心旧楼中进行测试，结果如下：网络流量为45％(略高)，碰撞率为3％，错误率0％，广播7％(略高)。总体基本正常。进而观察网络协议的分布状态，基本正常。查看数据包对话矩阵，则发现凡是对企业数据服务器的访问数据包均有部分“不响应”记录。该记录涉及面很广，几乎40％的工作站均有牵连。\r\n为了验证是否是数据链路的问题，进行了ICMP Ping和ICMP Monitor测试，前者报告有两个MAC地址响应，后者则报告记录到大量的目标不可达、重定向、拥塞告警等数据帧。这说明网络的数据链路中有重复的IP地址，而且网络对数据帧的路由运算也存在问题。启动网络测试仪的网段自动搜寻功能，自动查询网络连接结构，结果发现有多余路由解析操作(Proxy)，但没有发现重复的IP地址(这说明重复的IP地址不在该网段，而存在于数据访问通道中)。\r\n因网管人员没有MAC地址备份文档，故建议将旧楼中的所有本地工作站关机，此时网络立即恢复正常。为确定与服务器重名的工作站，再分批打开所有工作站，结果发现留守人员的2台机器中有1台IP地址与企业数据服务器重名。进一步检查该工作站，还发现其私自安装并运行了Proxy代理，与网段搜索的结构一致。

ciolmy

[诊断评点]故障原因有三。原因之一:是IP地址重复,原因之二:是运行非法路由代理。当业务网用户要求进一步的地址解析分析时，留守机与数据服务器发生冲突，多数的数据流向发生混乱(注意，此时的数据帧结构仍正常)，使用户的访问发生“梗阻”。应用软件则经常要求重新联络和重传数据，导致流量偏高、业务流程速度变慢。由于冲突基本限制在原信息中心网络中，所以企业数据服务器的流量显示正常！网管系统也无错误数据包报告！原因之三：对留守人员的管理出现真空。留守人员因“无聊”(员工自述)而渴望“越权”连接互联网，并由此开始迅速成为一名“白日网虫”，进而干扰正常业务流程。由于其操作并不一定持续存在，从而导致问题出现一个多月不能解决。其实，办公网中的互联网用户也会或多或少地受到影响，只不过因白天用户的使用频率低未曾察觉而已。\r\n        \r\n[诊断建议]网络管理的漏洞大多数来自于内部管理人员，建立严格的内部管理机制是非常必要的。同时，建议将MAC地址的备份列入必备文档。另外，每日对网络进行状态自动搜寻会有助于很快发现并清除非法用户。\r\n健康的网络维护方案中其实早就有关于定期测试(包括每日测试和每日循环测试)的项目，只要坚持每日必要的测试和检查，就可以保证99.9％的网络不会有超过2天而解决不了的严重网络问题存在。

ciolmy

[故事之十六]网线共用，升级100Mbps后干扰服务器\r\n        \r\n[症状]今天的“病人”是某移动电话公司计费中心。据该中心的网络主管人员介绍，为了缓解移动电话用户解交电话费难的问题，该中心三个月前投巨资对原计费中心的网络进行了调整和升级。与四家被委托代收手机费的银行之间的网络连接速度从标准的64Kbps速率DDN专线全部扩展为E1(2.048Mbps)速率，计费中心网络从10Mbps以太网全部升级为以交换机为主的100Mbps以太网。升级前各委托收费银行经常反映网络连接时常莫名其妙地中断，但一般能迅速恢复，业务妨碍不算大。升级后网络速度提高了很多，但其下辖的各营业网点(共计120个)在为手机用户办理交费收费手续时计算机屏幕上常会提示“网络远端故障，无法提供数据”或“数据传输不稳定，请检查网络”，此时营业网点的收费服务会暂停，用户意见很大。有时虽然还能提供服务，不过数据处理速度明显变慢，最差的时候处理一笔业务查询竟然需要反反覆覆操作5、6分钟(正常时一般在10秒钟以内)。比网络设备升级前反而要慢得多。此故障每星期都要出现1到2次，每次从1小时到2小时不等。\r\n由于一直没有查明升级前网络时常中断的真正故障原因，网络管理人员在做此次网络升级规划时曾心存侥幸地寄希望于通过设备升级来彻底排除这些遗留网络故障。遗憾的是，他们的运气实在太差，非但老问题没有解决，反而惹出了更大的新问题。遂向网络医院“挂号”求诊。

ciolmy

[诊断过程]由于银行网和电信计费网不在同一个地方，出了“网络医院”我们需要决定先去哪里？从上述的故障现象初步分析，银行络网和移动通信公司计费中心网络以及其连接的链路都有可能存在问题。计费中心的网络设备和路由设备大部分在此次升级时都更换过，升级后故障依旧存在且表现更严重，基本可以排除新入网设备存在严重问题的可能性。网络测试可以从银行网络和计费网络同时着手。途中从银行各营业厅网络使用者处了解到，手机收费出现“麻烦”时银行的其它业务流程均保持正常，并不受此影响(此时电信计费中心网络的用户也没有反映网络异常)。这说明银行网络存在问题的可能性要比计费网络及其连接链路存在问题的可能性低。而问题出现在手机计费网络和与银行网络的路由设备范围内的可能性比较大，故我们决定先前往设在移动通信公司机房的手机计费网络进行检查测试，首先检查计费网络及其连接链路。\r\n        第一次网络测试是在网络没有出现故障时进行的，结果显示各项测试指标都显示网络工作完全正常。将F683网络测试仪接入计费网络的交换路由器，监测网络的工作状况，显示路由器利用率为1％(相当于E1链路中有20Kbps左右的业务流量)，错误统计为0%，与网管系统观察的数据完全一致，将F683网络测试仪改为与计费服务器并联的方式监测，测试结果相同，这表明此时网络工作很正常。在与计费网络所在地的局域网使用和维护人员交谈中了解到，网络工作人员从来没有感觉到他们的LAN有异常情况，虽然他们也知道手机用户在经常抱怨，但从计费LAN处检查不出什么实质问题，计费服务器表现也正常。故障出现时从网管系统上观察，路由器、交换机、计费服务器都没有问题。用OneTouch网络助理(即网络故障一点通)仿真用户流量对银行的路由器、银行网业务转接服务器(以上测试在银行进行)、移动通信公司的计费网络与银行网络的连接路由器、网络通道上的交换机、计费服务器等进行2分钟80%持续流量冲击测试(上述测试在计费中心)，用F683网络测试仪监测移动监测各关键设备，结果基本相同，利用率为均80%，无错误出现，除了计费服务器处的碰撞率2%外，其它各处均为0%；ICMP Ping测试均在3ms以内，ICMP监测测试无拥塞、数据不可达、重定向、数据参数错误等显示，这说明，网络的通道测试结果是比较好的。\r\n        在这种情况下，一般可以采用两种测试方法继续检查故障，一种是被动监测法，即将网络测试仪、流量分析仪、网管等监测设备启动，对网络实施不间断监测，等待问题的重新出现；另一种是主动测试法，即将所有涉及到的网络设备和终端设备及其业务均启动或进行人为地仿真模拟，然后监测网络的工作状态，进行故障定位。为了尽快定位故障，经与计费网、银行网网络管理人员商定，我们决定采用第二种方法进行监测和测试(注意，此测试方案需要动用很多的人力和物力)，即将所有有关的网络设备网络终端设备启动，并安排人员进行业务流程模拟操作。\r\n        第二次测试在当天业务结束后进行。在启动所有网络设备5分钟后，预期的故障现象果然出现。从网管系统上观察，计费网和银行网的连接路由器流量上升为3％，交换机流量增加1倍，计费服务器流量减少70％，网络没有发现异常情况。用F683网络测试仪对整个计费通道的有关链路和设备进行移动监测，结果显示：路由器和交换机的数据与网管系统的观察结果一致，而计费服务器的流量为68％，正常数据7%，错误数据61％(幻象干扰Ghosts、FCS错误碎帧等)。很显然，计费服务器与交换机之间的这条链路很可能有问题。\r\n        暂停业务，从计费服务器网卡上拔下电缆插头进行电缆测试，结果显示只有1-2和3-6两对电缆，4-5和7-8线对没有连接。网管人员解释，升级后除了新增加的布线外，电缆系统多数没有变动，只有少数链路进行了调整。进一步检查发现4-5和7-8线对连接到了另一台备份服务器上，该服务器用于每周两次人工对各种关键数据进行审查、备份并上报局有关单位。恢复业务，启动备份服务器进行数据备份和传输，结果故障现象出现。\r\n        将备份服务器临时用一条新链路单独连接，故障彻底消失。对换下的电缆进行测试，近端串扰NEXT不合格(超差－2dB，综合近端串扰PSNEXT－8dB)

ciolmy

[诊断评点]网络电缆内含4对(8根)细电缆线，一般的10Base-T和100Base-Tx网络只使用其中的1-2和3-6线对，4-5和7-8线对不用，在10Base-T网络中曾流行将4-5或7-8线对用来传输电话，或者用4-5和7-8线对用来连接另一台电脑。在100Base-Tx以太网中，由于网络工作频率和数据率很高，串扰量很大，故这类用法是不被允许的。计费网络升级前有部分站点用一条电缆连接两台计算机，升级后这部分电缆没有变动，由于离新增加的交换机比较近，故将备份服务器接入了并用电缆。备份服务器平时虽然基本不用，但连接脉冲仍然会对计费服务器造成干扰，只是干扰量很少而已，这就是我们在交换机链路中观察到2%碰撞率记录的产生原因。由于该电缆的综合近端串扰PSNEXT不合格，数据备份服务器在工作时对计费服务器会产生很大干扰，破坏传输数据，使得同一个数据包不得不多次重传和多次重新处理，真实流量急剧上升到68％，重处理流量由0%上升到6.98％。由于服务器使用的是价格便宜的工作组交换机，所以网管系统无法从交换机端口发现链路中存在的严重问题。\r\n升级前业务偶然有中断的现象，这也是由于并用线缆串扰造成的，由于当时是10Base-T网络，速度低，所以这种影响比较小，往往只是偶尔且是瞬间的影响。

ciolmy

[诊断建议]在10Base-T以太网中存在着大量的非标准化布线以及大量不合格的布线链路，由于10Base-T网络工作速度低，这些严重质量问题往往被掩盖起来。直到升级到100Base-Tx以太网后这些问题才会明显地暴露出来。10Base-T网络布线系统中表现不明显的问题同时也给集成商、工程商和广大用户造成一种错觉，认为布线系统只要是物理上联通的就不会有问题，从而忽视了影响链路质量的布线产品品质问题、施工工艺问题对网络造成的严重影响。\r\n        建议网络设计者首先采用标准化的设计方案，且只有工程商和用户在签订建造网络的合同时选用标准化的施工工艺和标准化的现场认证测试方案，才能初步保证综合布线系统的质量。\r\n        《网络测试和维护方案》中一般建议每年(必要时每半年)对布线系统轮测一遍，以保证布线系统的性能合格，排除因布局变动、用户数量增删和人为调整等原因对布线系统造成的损害。另外，网络的业务工作和故障情况要有比较准确完整的记录，这样才能有助于故障的查找。如果“病人”对自己网络的业务流程比较熟悉，则可以避免动用众多人员加班配合排除故障。

ciolmy

[故事之十七]供电质量差，路由器工作不稳定，造成路由漂移和备份路由器拥塞\r\n        \r\n[症状]今天的“病人”是位居某中心城市的一家大区银行，报告的故障现象是：故障时断时续，呈周期性“发作”，每隔10分钟左右在其辖区内就有部分支行或分行打来电话报告业务流程出现问题。具体表现都很一致：先出现业务中断，1分钟后连接恢复，但速度非常慢。此故障已经持续了2天，网管人员怀疑是路由器故障，曾试着分别更换了备用的同城结算路由器和主路由器，无效。

ciolmy

[诊断过程]我们驱车来到“病人”的计算中心，首先向网络管理人员了解故障情况。基本上与网络医院“接诊”记录报告的内容相同。从表现的故障现象来看，根据以往的经验，基本上可以初步推断是路由链路的问题。网管人员确认，业务中断时，普通Ping测试不通，此现象以前也出现过几次，很快就恢复了。因此也没有引起注意。\r\n        从记录的故障报告(电话登记)看，无论是本城辖区还是大区内的远程网络都报告过路由中断现象。由于故障每隔10分钟左右就会周期性地出现，虽然比较频繁，却为故障诊断提供了很大方便。可以考虑选择任意路由进行连续的Ping测试，监测其连接状况与故障发生时刻的关系。为此我们将F683网络测试仪接入计算中心网络进行监测。选择曾报告过故障的其下辖的某郊县路由器作连续的ICMP Ping测试，响应时间为9ms，质量尚可。3分钟后，有用户报告故障出现，不过网络测试仪显示正常，说明我们监测的路由链路可能是正常的。立即改变监测方向，向报告遇到故障的用户的路由器做ICMP Monitor，结果大量的目标不可达记录出现，并出现源限制、回应请求和回应响应帧。20秒钟后，出现大量重定向帧记录，目标不可达帧记录速度减缓，源限制、回应请求和回应响应则开始大量出现。\r\n        以上记录表明，路由器的动态路由表在故障出现时发生了很大变化。网络原来的路由中断后，继之被重定向路由取代。打开静态路由表，为了与动态路由作比较，我们启动F683分段路由追踪功能，追踪从测试仪到先前报告故障的远程路由器。可以看到，路由在本城出口的下一站，即大区链接的第一个路由就发生了中断。动态路由已经由备份路由取代。状态：拥塞。\r\n        原路由为主路由，通道速率为E1，为ATM链路，备份路由为DDN基本速率链接，速度仅为64Kbps。打开主路由器的Mib库，观测到主路由器的流量为0.02%，错误为2％；表明它处于轻负荷状态，并有少量错误流量。观察备份路由器的Mib库，流量为100％，说明它处于超负荷运行状态。\r\n        由于故障为周期故障，为了观测它的发生规律，我们在征得“病人”同意的前提下，决定不急于寻找主路由器中断和拥塞的原因，而是先观测在一个周期里故障变化的全过程并记录之。我们用第二台网络测试仪和网络故障一点通接入网络，分别观察主路由器、备份路由器、主服务器的工作流量和错误，并对主路由器作连续的ICMP 监测。约8分钟后，主路由器流量开始迅速上升，备份路由器出现重定向指示，约15秒后报告备份路由器推出优化路由，动态路由表恢复到与静态路由相同的设置。网络完全恢复正常。\r\n        分析故障关系，可以断定故障的最大关联设备是主路由器。由于用户在机架上已经安装了冷备份的主路由器，我们先将冷备份路由器替换到主路由器的位置。5分钟后路由器更换完毕，开机接入网络，3分钟后网络恢复正常。但只持续了2分钟，故障现象又重新出现。看来，必须对主路由器做详细监测才能发现真正的故障所在。\r\n网络建构拓扑是，主路由器与三个外区远程路由器和一个本地路由器相连，我们可以同时监测这几个路由器的工作状况。监测结果如下：故障出现时，外区主路由器和本城路由器的路由表随着故障的出现也发生变化，而此时同城结算业务不受影响。受影响的业务方向是外地与本城、本城与外地、外地经本地跨区等。用Fluke的ATM测试仪测试远程ATM路由通道，将远端ATM交换机Loopback(环回)以后监测三个方向的通道情况，显示完全正常。再对与主路由器相关的连接电缆进行测试，全部合格。这表明主路由器的工作环境是基本正常的。此时我们需要了解主路由器链路中的“垃圾流量”的分布。但由于网络医院的流量分析仪出借给了别的“病人”，所以我们暂时不能观察主路由器的详细流量状况。实际上，我们这是也只需要检查主路由器的接地质量和供电环境即可(因为已经试验更换过主路由器)，这两个因素当中的任何一个不负荷要求，都有可能引发主路由器中断的故障。\r\n首先观测为主路由器供电的UPS电源。当故障发生时UPS显示过载，而输出回路却显示轻负荷。用F43电力质量分析仪观察也显示故障时输入谐波超差6倍。输出回路超差400倍，故障恢复后，过载指示也随之消失，但输出回路仍超差80倍。证明UPS电源低效。\r\n        将主路由器的供电电源接到另一台UPS电源上，故障彻底消失。故障原因为供电质量不合格。我们注意到，该计算中心所在的大楼正在装修，网管人员说等大楼装修完毕后还要将网络设备扩容。初步干扰源很可能就来自与装修有关的部分。由于故障的周期性，经过仔细观察发现，故障出现的周期与楼旁塔吊的上下周期一致！为准确判定谐波干扰的源地点，我们将F43电力质量分析仪接入供电网络进行核实，结果发现，每当塔吊上升时，故障现象就出现(下降时谐波为上升时的三分之一，网络有少许变慢)。

ciolmy

[诊断评点]为主路由器供电的UPS电源由于失效，对外界电力干扰谐波的过滤能力下降，当为重负载的用电设备供电时，此谐波会引发许多设备出错。如果此时恰逢UPS电源滤波失效，则相关设备会受到干扰。本故障中，主路由器由于大量干扰进入，使得链路阻塞，路由器连接中断，路由变更指令使得各业务流量流向备份路由器，备份路由器的路由通道能力又不能满足，致使网络出现拥塞。这就是本次故障先中断后恢复然后阻赛的原因。同城结算数据由于多数不经过主路由器，所以未受到影响。\r\n        塔吊下降时，虽然引入的干扰也不少，不过因为其干扰的绝对值未超过主路由器的承受范围，所以主路由器还能应付。大楼装修以前也出现过类似的故障，因干扰源很快消失并不再持续存在，因此不可能引起维护人员的注意。\r\n        \r\n[诊断建议]与电缆和光缆系统一样，电力谐波和UPS电源也是列入定期检查的内容，一般建议作半年定期检查，关键的网络建议作为周定期检查的项目。谐波干扰是经常存在的环境因素，如果此时UPS电源不出问题，一般不会影响网络的正常运行，但谐波干扰是严重影响网络性能的原因之一，一旦窜入网络则引起的故障多数都是“致瘫性”或致命性的。还由于多数用户对干扰类型的故障“相当地”不熟悉，故提请大家引起较多关注。