Chinaunix首页 | 论坛 | 博客
  • 博客访问: 593334
  • 博文数量: 805
  • 博客积分: 4000
  • 博客等级: 上校
  • 技术积分: 5000
  • 用 户 组: 普通用户
  • 注册时间: 2008-10-17 14:22
文章分类

全部博文(805)

文章存档

2011年(1)

2008年(804)

我的朋友

分类:

2008-10-17 14:42:46


  [故事之十一]网线共用,升级100Mbps后干扰
  
   
  
  [症状]今天的“病人”是某移动电话公司计费中心。据该中心的网络主管人员介绍,为了缓解移动电话用户解交电话费难的问题,该中心三个月前投巨资对原计费中心的网络进行了调整和升级。与四家被委托代收手机费的银行之间的网络连接速度从标准的64Kbps速率DDN专线全部扩展为E1(2.048Mbps)速率,计费中心网络从10Mbps以太网全部升级为以机为主的100Mbps以太网。升级前各委托收费银行经常反映网络连接时常莫名其妙地中断,但一般能迅速恢复,业务妨碍不算大。升级后网络速度提高了很多,但其下辖的各营业网点(共计120个)在为手机用户办理交费收费手续时计算机屏幕上常会提示“网络远端故障,无法提供数据”或“数据传输不稳定,请检查网络”,此时营业网点的收费服务会暂停,用户意见很大。有时虽然还能提供服务,不过数据处理速度明显变慢,最差的时候处理一笔业务查询竟然需要反反覆覆操作5、6分钟(正常时一般在10秒钟以内)。比升级前反而要慢得多。
  
  此故障每星期都要出现1到2次,每次从1小时到2小时不等。
  
  由于一直没有查明升级前网络时常中断的真正故障原因,网络管理人员在做此次网络升级规划时曾心存侥幸地寄希望于通过设备升级来彻底排除这些遗留网络故障。遗憾的是,他们的运气实在太差,非但老问题没有解决,反而惹出了更大的新问题。遂向网络医院“挂号”求诊。
  
  [诊断过程]由于银行网和电信计费网不在同一个地方,出了“网络医院”我们需要决定先去哪里?从上述的故障现象初步分析,银行络网和移动通信公司计费中心网络以及其连接的链路都有可能存在问题。计费中心的和设备大部分在此次升级时都更换过,升级后故障依旧存在且表现更严重,基本可以排除新入网设备存在严重问题的可能性。网络测试可以从银行网络和计费网络同时着手。途中从银行各营业厅网络使用者处了解到,手机收费出现“麻烦”时银行的其它业务流程均保持正常,并不受此影响(此时电信计费中心网络的用户也没有反映网络异常)。这说明银行网络存在问题的可能性要比计费网络及其连接链路存在问题的可能性低。而问题出现在手机计费网络和与银行网络的路由设备范围内的可能性比较大,故我们决定先前往设在移动通信公司机房的手机计费网络进行检查测试,首先检查计费网络及其连接链路。
  
  第一次网络测试是在网络没有出现故障时进行的,结果显示各项测试指标都显示网络工作完全正常。将F683网络测试仪接入计费网络的路由器,监测网络的工作状况,显示路由器利用率为1%(相当于E1链路中有20Kbps左右的业务流量),错误统计为0%,与网管系统观察的数据完全一致,将F683网络测试仪改为与计费并联的方式监测,测试结果相同,这表明此时网络工作很正常。在与计费网络所在地的局域网使用和维护人员交谈中了解到,网络工作人员从来没有感觉到他们的LAN有异常情况,虽然他们也知道手机用户在经常抱怨,但从计费LAN处检查不出什么实质问题,计费服务器表现也正常。故障出现时从网管系统上观察,路由器、交换机、计费服务器都没有问题。用OneTouch网络助理(即网络故障一点通)仿真用户流量对银行的路由器、银行网业务转接服务器(以上测试在银行进行)、移动通信公司的计费网络与银行网络的连接路由器、网络通道上的交换机、计费服务器等进行2分钟80%持续流量冲击测试(上述测试在计费中心),用F683网络测试仪监测移动监测各关键设备,结果基本相同,利用率为均80%,无错误出现,除了计费服务器处的碰撞率2%外,其它各处均为0%;ICMP Ping测试均在3ms以内,ICMP监测测试无拥塞、数据不可达、重定向、数据参数错误等显示,这说明,网络的通道测试结果是比较好的。
  
  在这种情况下,一般可以采用两种测试方法继续检查故障,一种是被动监测法,即将网络测试仪、流量分析仪、网管等监测设备启动,对网络实施不间断监测,等待问题的重新出现;另一种是主动测试法,即将所有涉及到的网络设备和终端设备及其业务均启动或进行人为地仿真模拟,然后监测网络的工作状态,进行故障定位。为了尽快定位故障,经与计费网、银行网网络管理人员商定,我们决定采用第二种方法进行监测和测试(注意,此测试方案需要动用很多的人力和物力),即将所有有关的网络设备网络终端设备启动,并安排人员进行业务流程模拟操作。
  
  第二次测试在当天业务结束后进行。在启动所有网络设备5分钟后,预期的故障现象果然出现。从网管系统上观察,计费网和银行网的连接路由器流量上升为3%,交换机流量增加1倍,计费服务器流量减少70%,网络没有发现异常情况。用F683网络测试仪对整个计费通道的有关链路和设备进行移动监测,结果显示:路由器和交换机的数据与网管系统的观察结果一致,而计费服务器的流量为68%,正常数据7%,错误数据61%(幻象干扰Ghosts、FCS错误碎帧等)。很显然,计费服务器与交换机之间的这条链路很可能有问题。
  
  暂停业务,从计费服务器网卡上拔下电缆插头进行电缆测试,结果显示只有1-2和3-6两对电缆,4-5和7-8线对没有连接。网管人员解释,升级后除了新增加的布线外,电缆系统多数没有变动,只有少数链路进行了调整。进一步检查发现4-5和7-8线对连接到了另一台备份服务器上,该服
  务器用于每周两次人工对各种关键数据进行审查、备份并上报局有关单位。恢复业务,启动备份服务器进行数据备份和传输,结果故障现象出现。
  
  将备份服务器临时用一条新链路单独连接,故障彻底消失。对换下的电缆进行测试,近端串扰NEXT不合格(超差-2dB,综合近端串扰PSNEXT-8dB)
  
  [诊断评点]网络电缆内含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%。由于服务器使用的是价格便宜的工作组交换机,所以网管系统无法从交换机端口发现链路中存在的严重问题。
  
  升级前业务偶然有中断的现象,这也是由于并用线缆串扰造成的,由于当时是10Base-T网络,速度低,所以这种影响比较小,往往只是偶尔且是瞬间的影响。
  
  [诊断建议]在10Base-T以太网中存在着大量的非标准化布线以及大量不合格的布线链路,由于10Base-T网络工作速度低,这些严重质量问题往往被掩盖起来。直到升级到100Base-Tx以太网后这些问题才会明显地暴露出来。10Base-T网络布线系统中表现不明显的问题同时也给集成商、工程商和广大用户造成一种错觉,认为布线系统只要是物理上联通的就不会有问题,从而忽视了影响链路质量的布线产品品质问题、施工工艺问题对网络造成的严重影响。
  
  建议网络设计者首先采用标准化的设计方案,且只有工程商和用户在签订建造网络的合同时选用标准化的施工工艺和标准化的现场认证测试方案,才能初步保证综合布线系统的质量。
  
  《网络测试和维护方案》中一般建议每年(必要时每半年)对布线系统轮测一遍,以保证布线系统的性能合格,排除因布局变动、用户数量增删和人为调整等原因对布线系统造成的损害。另外,网络的业务工作和故障情况要有比较准确完整的记录,这样才能有助于故障的查找。如果“病人”对自己网络的业务流程比较熟悉,则可以避免动用众多人员加班配合排除故障。
  
   
  
  [后记]一周后电话回访该“病人”,得知已经全部将并用链路更换为单独的合格链路,计费网络工作非常良好,手机用户再没有“交费难”的抱怨了。
  
  
  [故事之十二]电梯动力线干扰,占用带宽,整个楼层速度降低
  
  [症状]某大型家电制造企业计算机中心主任,今天极其沮丧地了报告了该公司的一起顽固的网络故障。该故障表现虽奇特但比较有规律,具体表现是:公司主办公楼的网络在员工上班的时候运行速度会变得很慢,下班后速度回升,有时基本上能回复到往常水平。故障时间大约三个月,准确“发病”的日期已无从记起。每天上午8:00左右开始发作,症状范围是三楼的整个楼层,现象是速度突然变慢,无论是从上文件、收发电子邮件都很慢且经常中断和出错。本楼层中的用户之间在传输文件时、与其它楼层的用户传送文件时或是其它楼层的用户与本楼层的用户交换文件时都要用很长时间,但其它楼层的用户之间互相交换文件则不受影响。第一此发作,故障一直持续了三天我们也没有查明原因。由于三楼是公司设计开发部门,每日都要使用网络环境进行大量的数据交换、资料查询等工作,为了不影响新产品开发进度,当时将研发部的工作时间暂时推迟到下午6:00上班。两周后情况仍未见好转,故障仍然存在。不得以公司决定将研发部与二楼的行政管理部门临时对调,以保证已经开始习惯于上“夜班”研发部员工正常的作息时间。谁知一“临时”就是三个月之久。网管人员将布线系统、网络平台、所有主机和服务器、路由器都彻底检查或互换过,一直未能查出故障琐在。听某知名系统集成商介绍可能是电缆系统的问题,随即将布线系统进行了一次认证测试。结果还真的查出了不少严重问题。比如,原来的5类线系
【责编:admin】

--------------------next---------------------

阅读(270) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~