【吐血推荐】网络医院的故事----连载2，共35篇(ZT)

Away

[故事之七]布线环境不符合标准，导致网络性能急剧下降
[症状]某证券企业求诊，要求查找错误源。近日股市火爆，新增不少用户，但一周内已经三次出现交易数据错误，数据恢复也进行了三次。虽然涉及的金额不大，与证券交易所的资料核对不上，昨晚对历史记录和当日交易记录进行了比较，发现在同一时刻往往有几个用户的交易数据出错。怀疑存在病毒或恶意用户捣乱的可能，用多套App查杀病毒，并重新安装系统，恢复备份的数据。不料今日故障现象依旧出现。

[诊断过程]该网络99年2月进行了改扩建，全部采用NT平台。最近又新增家50个站点。根据一般经验，先对新增加的工作站极其联网系统的状况进行常规检查。由于现在已经休市，网上错误无法观察。用流量发生器模拟网上流量进行体能检查，结果如下：正常数据帧下限帧长64Byte各类型帧体能检查，网络致瘫流量为99％,上限帧长1518Byte的致瘫流量为99.5％，错误帧50Byte短帧致瘫流量为90％，错误帧4000Byte超长帧致瘫流量为97％，碰撞最高时为6.4％，略偏高。无新的错误类型出现。从交换机处测试只发现少数传输延迟数据包，以上数据说明，被检查的网络是一个“身体素质”相当好的证券网络。仔细研究发生错误的工作站，发现是在同一个新增用户的集线器组当中，该网段通过一交换机接口与服务器相连。除了对交易服务器和行情服务器分别进行体能检查外，对该网段内的工作站也进行体能检查，各站表现正常。各工作站模拟流量和交易也都正常。可以基本判定，该网络是一个承受能力很强的优秀网络。由此大家怀疑可能存在“恶意用户”(注：恶意用户是指在工作站上安装自备软硬件或将工作站网卡插头拔下并将自带笔记本电脑私自接入的用户，其目的叵测)。为了跟踪数据出错的情况，将F683网络测试仪接入该网段作长期监测。第二天故障现象没有出现。第三天下午开始后10分钟，即13:10分，网络测试仪监测到该网段大量错误出现，其中FCS帧错误占15％，幻象干扰占85％，约持续了1分钟。FCS帧涉及本网段的3个用户。该证券系统装备有CCTV闭路视频监控系统，从长时录像机中可以发现故障对应时刻13:10有一个用户使用了手机，仔细辨别图像画面发现其使用的是对讲机。
无风不起浪，对讲机的功率比微蜂窝手机的功率要大得多，使用频率也更接近网络基带传输的频带，容易对网络造成近距离辐射干扰。但是，一个合格的、完整的UTP电缆系统在5米外还完全能抵抗不超过5W的辐射功率。从故障现象推断，本网络的电缆或接地系统可能有一些问题。随即决定查找本网段50个站点的布线系统(扩容时没有经过认证测试)，用Fluke的DSP2000电缆测试仪进行测试，测试结果全部通过。只在中心集线器与交换机端口的插头发现接头线做得很差，外包皮与接头之间有15厘米的缺失，线缆散开排列，双绞关系被破坏。交换机的物理位置离用户仅隔一面玻璃幕墙，直线距离1.5米左右。可以基本断定，对讲机发出的较大功率的辐射信号就是由此处串入系统的。重新按TIA568B标准的要求打线，连接好系统。

[诊断评点]出问题的网线接头是扩容施工时的最后一根遗漏的网线，为本部工作人员自己临时增补上的。他们不了解TIA568B所要求的打线标准，乃随意为之。系统中串入干扰的途径有多种，比如大动力线与网线并行距离太近或干脆就在同一个走线槽内；与某些辐射源(包括日光灯、电焊机、对讲机、移动电台等)距离太近；系统设备的接地回路不良等等。本案是由散列的网线接头引入近距离的辐射干扰造成。由于对讲机用户比较特殊，他们的干扰是短时的，查找时有时需要“守株待兔”。当然，如果网线全部经过严格的测试，应该不会出现本例故障。

[诊断建议]建议按标准化的布线环境来设计布线系统，更改系统结构后一定要测试电缆。合格的UTP电缆系统抵抗辐射干扰的能力是很强的，但要求电缆系统必须经过严格的测试(事实上多数布线系统只测试过物理连通性，未做严格认证测试，存在着大量的隐患)。大量的问题都出在不起眼的接头上。建议年检时将布线系统作为年检内容全部检查一遍(也可以以一年或两年为周期平时进行轮测，测试标准可选用北美标准TIA568A/568B或ISO11801等)。营业室内最好禁止使用大功率对讲机，部分大功率模拟手机也要列入禁用清单。故障检测中，应重点检查最近动过的或变更过的设备，此为经验之谈。不过，一个有趣的现象是，当你向某个事后证明他确实更改过设置的用户询问时，经常得到的答复却是：没有动过任何东西。

[故事之八]插头故障
[症状]某电信移动计费中心，用户反映，近三个月移动用户总数增加了近30％，但移动计费的营业收入却只增加了5％，怀疑计费系统是不是有问题。从计费服务器查看收费记录，没有发现什么问题。检查计费服务器App，工作正常。从路由器另一侧的财务服务器检查，内部的财务服务器显示的计费数据与计费服务器的数据没有差错。查找电话局局端记录，发现记录次数超出移动计费的记录次数。最后作实地测试，用移动电话拨打50次，记录次数45次，记录时间与实际通话时间一致的次数为30次。历时一周，还不能确定故障位置。

[诊断过程]计费服务器连接到一台16端口交换机Bay28115的第一插槽5号端口。第6号端口下挂一个100Mbps的以太网，网管机HP Open View也设置在此。打开网管系统，准备观察5号端口的工作情况，这时才发现无法打开5号端口的工作表数据记录。询问网络管理人员，告知3个月前因交换机故障自行更换过备用的Bay28115交换机，更换后系统工作很正常。查看维护工作记录登记和日志，没有任何关于Bay18115的维护说明，也没有关于网络工作参数的记录(记录上显示的还是系统开通时的原始数据)。询问网管人员为何不设置并打开交换机工作表的Mib。答曰网管系统是一年前安装的，平时只用来看看系统设备是否连接以及是否有报警信号，更多的功能也不会用。前任网络管理员已调任工作岗位，实际上现在已没有人会使用和设置网管系统。由于系统开通是有系统承包商负责的，自行更换交换机后没有发现什么问题，也没再 仔细检查。用网络测试仪的协议对话分析功能从网管机所在网段观察计费服务器的工作情况，发现服务器对约有1/3的数据包没有回应。为了不影响系统工作，于凌晨3:00在移动用户使用率底的时候用F683网络测试仪模拟服务器测试5号端口，显示链路工作于10Mbps速率(原始记录显示此端口的速度应该是100Mbps)。由于交换机没有启动SNMP支撑功能，故临时在5号端口安装了一只10Mbps的集线器与服务器连接，用网络测试仪从这个集线器的任意端口对计费服务器发送数据并观察服务器数据流工作情况。发现大量碰撞和错误的FCS帧，当流量为30％时，碰撞及错误流量占21％。用电缆测试仪检查服务器电缆，发现靠交换器一端的插头处近端串扰NEXT严重超差。重新更换插头并正确打线，碰撞率下降为0.5％，错误率为0％。去掉临时集线器，重新启动交换器的SNMP功能，从交换器某空闲端口向服务器发送流量，用网管系统观察5号计费服务器端口，当流量为40Mbps时，碰撞率、错误率、广播率等参数均表现优良。服务器自适应恢复为100Mbps链路速度。
重新进行两组各50次实际拨打测试，计费数据完全正确。可以基本肯定计费功能已全部恢复正常。

[诊断评点]本次故障的原因非常简单(一个插头问题)，但表现出来的现象则稍微复杂一些。该服务器使用的是一个10/100Mbps的自适应以太网卡，设计链路速度为100Mbps。网管人员在更换交换器时曾不小心将插头拉坏，随即更换了接头，但确留下隐患，不过，维护人员并未及时发现速度方面异常。服务器链路此时的实际工作速度已经下降为10Mbps。新交换器没有启动SNMP支撑功能，网管系统也就不能观察计费服务器的端口工作状态。在平时的维护工作中，该计费中心的维护人员基本上不用网管系统定期观测并记录网络的工作参数，当故障出现时就不能觉察到服务器工作速度的变化。有趣的是，如果电缆没有问题，即使将链路速度设置为10Mbps，计费服务器应该还是能正常工作的(计费信息的网络流量一般不高)。在本故障中，计费服务器繁忙时由于碰撞率和错误率太高，服务器无法处理一部分数据包，其中已经被“挂号”的部分数据包将被丢弃，造成计费数据不准确。

[诊断建议]布线系统平时要定期轮测(一至两年轮测意义遍)。更换链路元件后一定要对链路进行测试(尤其是100Mbps链路，必须用电缆测试仪测试)。网管系统要指定专人进行维护使用，一般来讲，网管系统可以覆盖约35％左右的网络故障，因此强烈建议重要的网络要安装支撑SNMP或RMON协议(多数网络设备都支撑SNMP协议，部分支撑RMON)，启动已有SNMP、RMON等功能的网络设备，否则网管系统将形同虚设。维护工作要求有及时完整的记录，这对提高处理故障的速度是非常必要的。
[故事之九]交换机软故障：电路板接触不良

[症状]今天的“病人”是某大型证券企业，在全市有近11个营业网络。以下是该企业信息中心工程师对故障现象的描述：
一段时间以来，整个网络交易时常中断，有时一天内会出现2～3次。起初每次持续的时间很短，没有引起大家的足够重视；大家做过简单的测试，约几秒钟至十几秒钟不等，规律性不太明显，一般开市时都正常。随后一段时间“病情”不断加重，发病频率不断增加。好几个“资深”用户曾向老总抱怨，近来碰到几次原本估计十拿九稳的网上交易不能及时成交：“当我按下交易确认键时，计算机对此却没有任何响应，也不知道成交了没有，只好再等上一会儿。我给伙伴们先容的绝招是，过半分钟再试，计算机就会显示成交。不是每次都这样灵光，但以前极少遇到这种事，而最近一周已经遇到好几次了，好象一天比一天利害，搞得大家的神经紧张兮兮的。”
昨天15:26，临近下午闭市时，故障现象再次出现：行情数据的显示和更新都正常，就是普遍不响应交易命令(但不是绝对不响应，其中仍有少数交易能成交)，11个子交易网络均反映受阻。网管人员初步判断是中心网络的问题，马上在电脑科计算中心检查交易服务器，CPU利用率、协议交换及包交换等指示正常，试验重新登录服务器和Ping测试也正常。时间到，转为休市状态。休市后保持交易网络继续运行，启动模拟交易功能模块，进入故障诊断作业程序。在计算中心LAN内连续作了40笔模拟交易均成功。同时在3个子交易网处作对内和对外的模拟交易，对内100％，对外成功率约15％左右。基本上可以肯定故障在网络本身。保持模拟交易连续工作状态，启用计算中心的网管系统查看网络，服务器工作状况指示正常。检查与其它11个营业网络的联系的交换器端口，有流量指示，但时有停顿。对其作Ping测试，偶尔会有中断(约有3％Ping测试不响应)。用DSP-100电
缆分析仪检查与交换机连接的端口电缆链路(服务器、网管机均在此网段内)，没有问题。这说明服务器所在网段是正常的，怀疑是交换机端口损坏。将与服务器网段的电缆改插在别的交换器端口并作相应设置，网络恢复正常工作，故障消失，确认为交换机端口损坏，心想总算可以松一口气了。不料，今日开市后不久故障依旧如期“光临”。

[诊断过程]晚上19:50大家赶到该证券企业所在地，马上启动系统，自检显示正常。然后启动模拟交易系统，观察与子交易网络的通信情况，表现正常。网络拓扑图上显示各子交易网络是用DDN专线通过路由器与计算中心本地网段的交换器联系起来。打开各Router的工作表Mib检查，无异常和错误记录。逐个检查交换机各端口工作表Mib，亦无异常和错误记录。交易服务器和网管机同在一个网段，通过一个智能型集线器连接到交换机端口。打开集线器工作表，记录数据正常。将F683网络测试仪接入集线器端口进行连续监测。同时启动测试仪流量发送功能，抽查3个子网的通道性能，并做体能测试，持续流量承受能力为98％，说明网络很正常且表现相当优秀。
本故障属于软故障。可以由网络设备、应用App、供电设备、外来干扰等故障引起。由于故障时检查过本地网络，登录服务器和进行Ping测试也是正常的，所以可基本判定集线器下挂网段是正常的。为了定位网络故障，在某个选定的远端子交易网络处和网管中心同时用F683网络测试仪双向发送流量作通道性能测试和故障监测，并作ICMP Ping连续测试和ICMP监测。为便于观察和比较，流量发送的帧长都设定为100字节，流量总和约30％(各占15％约10K左右)。在21:30故障如期出现。ICMP Ping测试出现断层，马上打开交换机和路由器的工作表，记录的流量等数据出现停顿或断续，并显示出现FCS帧错误。从远端打开相应工作表的结果是：路由器接转流量为17％，交换机接转流量为2％，ICMP Ping断层损失90％。ICMP监测显示不可达97％左右。从中心打开路由器和交换机工作表Mibs，接转流量均为0.5％~0.9％。这表明远端数据可以顺利到达路由器但不能在交换机端口顺利进行交换。最后用F43电源谐波测试仪测试UPS电源参数，验证UPS电源合格。可以判定确实是交换机的问题。由于网管中心没有备用的交换机，已知原交换机供应商已经停产该型号产品，所以只能考虑更换新型交换机。为了应付明天开市，试着确定一个好的代用端口，这样可以将服务器网段临时连接入网，防止明日开市遇到不测事件发生。
查看交换机与路由器一侧的连接端口，发现工作表是正常的。因此只需要代换与服务器连接的端口即可，询问网管工程师上次故障时曾经更换过的是那个端口，答曰第4插槽上的空闲端口都试过。改用第5插槽上仅剩下的一个端口试验连接，网络恢复正常。由于故障时隐时现，故怀疑第4插槽存在软故障。重新将端口还原为第4插槽，故障已经消失。为重复故障现象，试着用改锥木柄敲击第4插槽，故障出现，再次连续敲击，则故障时隐时现。取下第4插槽的电路板观察，发现插针有较厚的氧化层(黑色氧化物)。用0000#细砂纸打磨插针并用酒精清洗，重新安装好电路板，故障彻底消除，并且不再随着敲击电路板而时隐时现。为保险起见，顺便检查其它7个插槽的电路板，插针均没有黑色氧化痕迹，证明只有4号插槽的插针在生产时使用了一组不合格的接插元件。交换机应属于不合格产品。暂时确定用第5号插槽的空余端口作代用端口，并要求网络不停机持续运行直到第二天休市为止，进行连续观察。

[诊断评点]网络故障分硬件故障和App故障，有时是软硬件相结合的故障。某些情况下从网络表现出的故障现象不能马上确定是那一类故障。本故障是由硬件设备接触不良引起的故障，原因是计算中心用作分隔网段的交换机其第4插槽的插针接触不良，使得与交换机第4插槽有关的接口工作都不太正常，出现断续和停顿。设备在刚启动的一段时间内，机器的元器件温度较低，工作正常，随着元器件温度的升高，器件受热膨胀，出现接触不良的故障，所以每天开市后的一段时间网络一般都不出问题。多次重复这一过程故障现象就会由较低频率的时隐时现转为较高频率的时隐时现，故障每此持续时间也会延长，最终可能会演变为持续的硬故障现象(硬故障在故障诊断时反而容易些！)。当网络维护人员作停机检查并更换端口后由于元器件温度降低的关系，网络也会正常工作一段时间。这往往给人一种错觉，以为故障排除了，但第二天开市一段时间后故障又会重新出现。
由于本故障的故障点在交换机向中心网络的一侧，所以从计算中心不能准确地观察路由器和交换机的工作情况，这样要从网管系统一侧判断故障是很有困难的。若改由从路由器的另一侧对路由器和交换机的工作状况进行实时监测，就会发现流量不均衡的故障现象，加上ICMP Ping测试的损失率为90％以及ICMP监测结果，定位故障就很容易了。由此确定是交换机的问题。
时隐时现的故障大家称作软故障(注意，不是App故障的含义)，可以由App故障引起，也可以是硬件故障引起，是难度比较高的一类故障。这除了需要网络维护和管理人员具备一定的软硬件故障诊断常识外，对诊断经验的积累也有一定的要求。目前，多数的网络维护和管理人员是由计算机专业的人员来担任，对硬件设备的诊断还比较地不熟悉。

[诊断建议]如何选择合适的检测工具对故障监测点进行测试是很有讲究的。许多故障需要进行多点测试才能定位，这时非常需要的是便携式的测试工具。网络故障的诊断发展方向是测试工具的网络化和故障诊断的网络化。一般的网络设备和网上设备只支撑有限的网管功能，所以监测网络性能和快速定位网络故障需要一些必要的固定测试工具(如固定探头、网管系统等)和移动测试工具(如网络测试仪、流量分析仪等)。对重要的网络设备要准备适当的备用设备，至少要留足备用通道。网络关键设备不一定要选用最昂贵和功能最齐全的设备，但一定要选用应用比较成熟，可靠性高、用户数量大的设备，这样技术支撑的难度就会降低。如果将关键网络设备的维护工作交给集成商或厂商来做，那用户就得准备将网络的命运完全交给集成商或厂商来控制，而这是非常危险的。因此对人员进行适当的培训并配备合适的、易懂易用的工具是做好网络维护工作的必要条件之一。尤其对占维护队伍总数90％以上的初级和中级网络维护技术人员和工程人员，这一点更具有实际意义，因为操作复杂、参数难懂难记、培训时间长、价格昂贵的工具对他们来说是豪无实际意义的。

[故事之十]5类线Cat5勉强运行千兆以太网

[症状]某期货交易所，网络改造为千兆以太网后只有1个网段能正常工作，其它12个网段工作均不正常，数据时有出错，连接经常会莫名其妙地中断。每个网段用千兆以太网连接起来，下挂的网段均是100Mbps用户端口。起初怀疑是系统运行的平台或者App有问题，经过多次重新安装和设置仍不能解决问题，而且同样的系统在其它地方的交易网络中应用是正常的。因而转向怀疑是否是布线系统的问题，比如电缆不合格或是有干扰信号串入以及接地系统等方面的问题。每个网段均利用升级前铺设的电缆系统连接起来，未作大的更改。由于计算机网络的布线系统采用的是标准的5类线方案，根据千兆网的设计标准，采用4对线全双工工作，5电平编码，占用的信号物理带宽正好是100MHz，故5类线应该是完全可以胜任的，况且一般情况下期货交易网络现有的流量水平远不能达到满载运行的程度，流量很低。重新用专业电缆测试仪作过严格的认证测试，显示参数合格并且不存在脉冲噪声干扰或接地方面的问题。
所谓能工作的那一个网段是因为行情和交易服务器都安装在该网段中，本网段内的工作站与服务器除了个别站点外都可以上网连接工作，进行行情浏览和交易割接。其它网段内的服务器对内连接时除了个别工作站外也基本正常，共同特点都是不能与行情服务器和交易服务器所在网段实现良好连接。系统升级时原布线电缆全部保留不动，经过测试也全部合格，不知原因何在？

[诊断过程]不能连接的因素很多，象网络硬件设备的功能设置问题、布线系统的问题、操作平台的安装设置问题、应用App的安装设置和App冲突方面的问题等等。从用户所反映的情况分析，各个网段内的站点基本上全部能工作，网段之间的连接比较困难，可以初步确定故障出现在网络设备设置和布线系统性能等方面的可能性大一些。
将网络测试仪F68X接入能连接服务器和交易服务器的网段(100Mbps)，观察网络流量5分钟平均为12％，FCS帧校验错误帧约11％，碰撞率1.7％(正常范围)。显然FCS帧校验错误比例偏高，查看错误源，显示为其它网段站点产生FCS帧错误的比例占错误帧总量的97%。各网段的错误帧比例差别不大。由于有大量的FCS帧普遍存在，所以各网段内的各站点同时出问题的可能性很小，用F683向各网段内的服务器或站点发送流量，FCS帧错误随流量增高而迅速增加，各站点或服务器反映基本一致。启动网络测试仪的ICMP Ping功能，统计对各网段内选定的站点和交换机、路由器等的测试结果，表现基本一致，即：ICMP Ping断层约96%，ICMP Monitor显示目标不可达占91％。改在其它网段内作同样内容的测试，对行情服务器和交易服务器所在网段的路由器和交换机结果基本与前项测试相同。所不同的一点是，对其它网段内的交换机和路由器等网络设备的测试结果显示是正常的，数值为：ICMP Ping断层为0％，全部可以通达，ICMP Monitor目标不可达为0％。基本可以肯定，故障出在行情服务器网段与其它网段的连接链路上。用FLUKE企业的DSP-4000电缆认证测试仪选用TIA Cat5n Channel UTP100标准测试，显示长度为25米，链路测试不合格。其中，回波损耗RL和衰减串扰比ACR等参数超差。改用同样长度的一根超5类线Cat5e代用之，启动系统，除了各网段内个别站点外，整个网络恢复正常。监测高峰时的流量，服务器所在网段最高时平均流量为3％，可见故障时12％的流量主要都来自大量的重发帧流量。

[诊断评点]千兆以太网可以满足网络用户对大带宽应用的“贪婪”胃口，无疑是网络下一步的重点发展方向。千兆以太网的设计者在选用电缆类型时对5类线Cat5已经存在的应用规模考虑比较多，所以选择的物理带宽为100MHz。这样，原则上5类线是可以运行千兆以太网的。但实际的统计结果表明，仍有1％～5％的用户不能上网或连接出现断续和困难。也就是说，千兆以太网对5类线的参数要求更严格一些。只要用户对5类线布线系统进行过严格的认证测试，可以保证绝大多数的站点是可以联网工作的。少数站点因为某些参数余量小可能有上网困难的现象。影响比较大的参数有综合近端串扰PS NEXT、综合远端串扰PS FEXT、等效远端串扰ELFEXT、综合等效远端串扰PS ELFEXT、回波损耗RL、衰减串扰比ACR等。此时需要对5类线进行Cat5n标准测试，该标准是专为用5类线运行千兆以太网的用户准备的，如果依循该标准测试都合格，则可以放心地用5类线系统运行千兆以太网。新的Cat5n标准中，回波损耗对系统的影响比较大，并且，由于电缆匹配方面的阻抗不连续问题，越短的电缆链路反而越容易出问题。本例中，由于电缆长度为25米，虽然衰减串扰比ACR参数也不合格，但，回波损耗引起本故障的可能性要大些。

[诊断建议]对5类线的认证测试可以适当考虑选用Cat5n标准进行测试，这样可保运行千兆以太网网时不出问题。如果选用超5类线Cat5e进行布线，则一般不会有不能运行千兆以太网之虞。对用Cat5n标准诊断出来有问题的5类线链路，为了以最小的成本换来网络性能的提高，一个最简单的办法就是用超5类线Cat5e代换参数不良的个别链路。注意，联结模块最好一并更换，以保证链路的安装质量。

[故事之十]防火墙设置错误，合法用户进入受限

[症状]今天的“病人”是某市社会保险局，昨天下午全局工作人员加班，配合网络管理部门于18:30安装好了一套新的防火墙系统，重新启动整个保险网络系统，反应良好，防火墙工作也很正常。但好景不长，今天上班时，许多Intranet内部有权用户就打电话反映在查询和操作保险资料时出现无法进行数据调用和修改的故障现象，此时屏幕提示登录者为“非法用户”；系统管理员同时还发现只有从防火墙处可以访问网络并修改数据。同时，一个有趣的现象却是，Internet外部普通用户在查询各种用户资料时却没有问题，他们无论从何处都可以顺利地访问Web服务器。他们投诉的对象主要是“业务部门”：“为何都一天了，还在借口计算机网络故障不受理业务，到底能不能弄好，什么时候能弄好”。
由于Intranet主要是供内部系统业务机构的各级有权网络用户使用，所以系统的许多正常功能无法正常启用，致使员工和业务对象反响都很强烈。
该社会保险局的网络结构比较复杂，含业务专用网，OA网，Intranet网和Internet网等。其中，Intranet设计为内部业务网，主要进行业务服务。Internet主要是为电话接入访问的用户提供服务， OA网通过LAN内的以太网交换机同Web服务器实现联结。无论是Intranet用户还是Internet用户
均可以在网上申报和查询资料。业务数据的安全设计为双Web服务器，Internet用户和Intranet用户各用一个。Intranet的Web服务器兼有备份数据的功能，两个Web服务器互联，之间的业务数据同时更新。Internet用户只能浏览、查询数据并可以进行网上申报等各种服务，不能更改数据。对Intranet内部用户实行有权访问和申报、数据修改特权限制等体制。局内的OA网用户可以象Internet用户那样随时访问和查询Internet的Web数据服务器，其中设置了部分有权用户，他们可以访问Intranet业务网的Web服务器。安装的防火墙对IP包进行过滤，只允许合法IP用户进入。从“病人”传真过来的网络结构图看，Intranet的用户用PSTN公用电话系统、DDN数据专线将各地、县、区的业务网络节点联结起来， 使用者都是地点固定的内部用户(员工)。

[诊断过程]显然，故障现象与昨天新安装的防火墙系统有很大关系。将网络测试仪F683接入服务器所在网段，启动网段搜索功能，可以发现Internet用户的Web服务器，但不能发现Intranet的Web服务器。去掉防火墙，则可以搜索到该服务器。说明确实是防火墙的问题。但昨天安装防火墙时整个系统是正常的，所以查找故障的焦点要放在安装防火墙以后有无更改过防火墙参数。此即故障排除经验中的所谓“动则有过”故障查找原则。如果能弄清网管人员都动过哪些参数和设置，查找故障的工作会便捷得多。经常让人感到遗憾且奇怪的是，多数维护管理人员都不会承认更动过网络的任何设置，这次也同以往一样。
用网络测试仪连续作ICMP类型PING测试发现，Web服务器是存在的，且反应率为百分之百。说明Web服务器在网络上且可以正常工作。同时用网络一点通One Touch选择Web服务器的IP地址为目标地址发送流量，启动网络测试仪的协议分析功能，发现数据帧指向防火墙以后就没有任何反应了：任何回应数据帧都未出现。将网络助理One Touch的IP地址设置成任何一个已经存在的有权用户的IP地址，然后对Web服务器发送流量，这时网络测试仪可以观察到防火墙有回应数据帧出现。这说明防火墙对合法IP地址的有权用户是有反应的，但一般返回的数据帧是非法用户的提示信息。注意到前述现象中提到过只有防火墙能访问Web服务器，大家就将网络测试仪的MAC地址改为与防火墙相同的MAC地址，用网络测试仪假冒防火墙进入网络，启动网段搜索时则可以看到久别了的Web服务器。
以上现象说明，该防火墙的功能比较强，除了能过滤IP地址外，还能对各站点的MAC地址进行过滤，以防止“拥有合法IP地址的非法用户”进入系统，是一个比较好的“看门人”。但让人疑惑的是昨天安装防火墙时，网络管理人员只启动了IP包过滤功能，并未启动MAC地址鉴别功能，那么，MAC地址滤波功能是谁启动的呢？答案是：不得而知。查看防火墙帮助文件，按提示揿下Format下拉式中的MAC地址过滤菜单，关闭MAC地址过滤功能，系统随即恢复正常。

[诊断评点]不少防火墙是靠对IP地址进行过滤和用户密码识别等方法来鉴别有权用户及其合法性等级的，一般不对网卡的MAC地址进行识别。安全性要求高的用户则需要对用户的MAC地址进行鉴别，以便阻止获悉了密码的非法用户模仿IP地址(用户可以在2分钟内随意更改工作站的IP地址)访问网络，部分防火墙和网管系统具有类似功能。大家知道，一般网卡的MAC地址是按制造商的编码设置的，从原理上讲世界上没有两块具有完全相同MAC地址的网卡，而多数网卡地址在制造时就永久地固定在ROM中，用户是不能更改的。对于具有固定用户的Intranet网络，具有MAC地址过滤功能的防火墙是非常有效的，它可以阻止对网络的各种试探性进攻。对于Internet用户，这一功能不能启用，所以需要采用两台Web服务器，一个用于查询和申报，另一个作备份，并可以按有权体系修改相应数据。可以肯定，系统管理人员昨天在防火墙安装完成以后可能出于好奇或是其它原因擅自将防火墙的MAC识别功能按钮有意无意地按下了，从而启动了MAC识别功能，致使今天整个系统工作不畅。

[诊断建议]对Intranet网络固定有权用户和部分OA网络固定有权用户设置MAC地址鉴别功能对于系统安全和阻止非法用户、恶意用户的进攻是有效的。这类用户多数来自于网络内部的成员，对加权识别设置和安全口令有一定了解，容易钻空子。设置MAC识别功能后，除非是在对应的那台唯一的机器上进行操作，否则是无法进入网络的。大家向该社会保险局建议将防火墙安装分两步走：先将系统内的网络成员的所有网卡的MAC地址备份，在备份工作完成以前，暂时不启动MAC地址鉴别功能；第二步，启动MAC地址识别功能，以提高系统的可靠性。稍微麻烦的是，有权用户在更换网卡时必须向防火墙管理员申请重新设置合法的MAC地址档案才能进网工作。这样，网络固定有权用户的任何成员在需要更改机器的IP地址以及更换网卡或新机器时都必须向系统管理原申报备案后才能进行。

[故事之十一]电缆超长，LAN可用，WAN不可用
[症状]今天的病人是某进出口企业，开通DDN专线后部分用户抱怨数据交换的速度变慢，且经常有联结中断的现象。网络支撑人员虽经多方查找仍不得要领，故请求网络医院出诊援救。
该企业的网络结构原先是单纯的局域网，分布在三层楼面中，共有300个站点，每个楼层有100个左右的用户。配线间设在最上面一层的楼层中，用交换机将各楼层共分成三个网段。以前员工均使用拨号上网方式实现与Internet的联结，自我感觉网络速度还比较快，工作一直很正常。新近增加了路由设备，并申请开通了DDN专线。每个楼层用集线器将用户联结起来，结果最低楼层的员工反映有时速度很慢，并常有莫名其妙的中断现象。由于该企业没有配备任何网络监测工具，且在局域网内传输数据不受影响，只在上Internet网时才有麻烦，故直到工程竣工两周后才向网络医院求援。

[诊断过程]该企业的网络为10Base-T局域网，此次只增加了DDN设备和路由器，其它配置基本不变。故将网络测试仪F68X从最低楼层的某个用户端接入网络进行观察，平均流量为1.2％，未发现异常。改用流量发送功能作流量逐级递增的体能测试，也未发现任何异常。表面上看，该网段似乎没有什么问题。为快速定位网络故障，将流量发送到其它网段，同时观察网络状况。随着发送流量的增加，1分钟后发现错误帧，帧类型为FCS错误帧，并指示FCS帧来自第二层的某个用户。显然，只据此现象就判断故障原因为该工作站的网卡损坏或网卡驱动程序错误，似乎显得“证据不足”，因为整个楼层的用户反映的故障现象是相同的。继续观察到5分钟，发现FCS错误帧数量增加为10个用户左右，由此可以断定不是某个工作站的问题。为此，令其它楼层多个用户与故障楼层用户交换数据(比如拷贝文件)，结果发现多个FCS帧错误。打开交换机端口工作表观察，本楼层的记录中也显示FCS帧错误，而其它的交换机端口工作表中没有FCS错误记录(交换机为非切发型交换机)，这说明是本网段内存在者线缆超长的链路。再试着向Internet某个已知用户发送流量，并且进行ICMP Ping测试，结果发现损失率为90％左右。由于刚才本网段内的体能测试未发现异常，所以只能是集线器与交换机联结的单条链路有问题。测试该电缆，长度指示为175米！超长。

[诊断评点]根据网络规范，以太网为碰撞侦听共享介质方式工作的。每个工作站到集线器的网线长度应不超过100米，方可保障无延迟碰撞(同轴电缆)或FCS帧错误。由于175米超常链路在集线器和交换机之间，所以本网段内的用户在交换数据时可以顺利进行。但与其它网段的用户交换数据时就可能处问题。但由于网络平均流量低，虽然在整个局域网内存在FCS帧错误影响，对低流量局域网内的数据交换而言，其对速度的影响甚微。当同时有多个用户通过DDN进行WAN数据交换时，FCS帧错误将导致64K的出口流量浪费加大。这是因为64K比10Mbps的速度要低得多，流量中错误帧的比例较高，进入WAN链路时可能要经过多次重发才能实现远程数据交换，感觉网络速度明显变慢。且由于经常有FCS错误帧，较容易引起WAN链路联结时因错误而中断，综合表现为故障楼层的所有用户都抱怨速度变慢且常中断。

[诊断建议]网络速度低时很多故障现象都将被掩盖起来。建议网络拥有者在新的网络工程结束时应该进行两项验收：网络布线系统现场认证测试和网络验收测试(最起码要作体能测试和加载条件下的逐个工作站的模拟上网测试)。

[故事之十二]路由器工作不稳定，自生垃圾太多，通道受阻

[症状]今天的“病人”很特殊，是某电力信息部门的主管。称其特殊是是因为该部门主管曾多次打电话要求网络医院为期诊断广域连接的问题，但每次都会在15分钟内来电通知“故障已排除”。询问其排除方法，回答基本上都是“Reset”整个系统。由于该用户只安装了一套价格不菲的“网管系统”来管理整个网络，没有配备其它用于网络维护的工具，网络医院为此曾建议专门为其做一次全面的体检，对该信息网络的各个布线系统、网络设备、工作协议、负荷均衡性、负荷能力、错误帧耐受能力等做详细检测，但一直因各种原因未实施。今天的症状还是老毛病：某电厂的信息网络与电力信息中心的网络联系不畅，数据传输速度不稳定，连接时断时续，有所不同的是系统Reset后仍然不起作用。

[诊断过程]该网络下辖9个电厂子网络，一个子网络用X.25连接，8子网络个从去年起陆续更换为DDN链路。其中一条专线DDN线路(7#线路)偶尔会出现连接中断的现象，恢复系统时必须将路由器Reset才能重新连接。今天按老经验，故障现象出现时重复以往的操作程序却发现此办法不管用了，系统仍然不能连接。直到大家赶到现场时系统还未能恢复正常。将网络测试仪接入信息中心网络，可以看到与各电厂子网连接的路由器，查看7#路由器工作表，有少许传输延迟错误记录，通道流量30秒记录为7帧，其它线路的30秒记录则从170帧～2700帧不等，明显高于7#线路；对7#子网络做通道测试，最高为2kbps，远低于64kbps的线路最高速率，说明DDN链路传输正常数据的能力很弱。由于该路由器支撑的错误识别和统计功能有限，用网管系统不能查看更详细的统计信息，故改用F69x流量分析仪串入WAN通道进行测试，发现少量未定义帧类型，其记录标识不稳定。也就是说，通道上有一些是网络不需要的且不稳定的比特流。这些比特流不便于分类，流量不稳定，时高时低，表明网络可能存在“垃圾”，且比较象窜入系统的干扰信号。这些垃圾严重影响正常数据的交换和传输。
为了验证其影响程度，大家用F683网络测试仪向远端子网络作ICMP Ping测试，损失率为10％，不算高，作ICMP Monitor测试，目标不可达50％，重定向20％，拥塞85％，这说明路由通道存在很严重的问题。从中心网络的主网段检测没有发现网络上有干扰比特流，测试为7#路由器供电的UPS输入输出电源谐波含量，显示正常，由此基本上可以排除垃圾比特来自于网外窜入干扰比特的可能性。将其它路由器与7#路由器掉换，重新设置后启动系统，故障依旧。由于垃圾比特数量少，不可能引发网络通道传输速率性能大幅度降低，因此推断“垃圾比特”极有可能是来自于专线DDN链路或远端子网络的路由器。本地信息中心没有配备测试DDN链路的工具，在没有足够证据怀疑就是DDN链路的问题(DDN链路系租用的电信线路)的时候，大家只能先从远端子网络查起。远端子网络没有任何网络维护工具，从中心网络的网管系统又看不到远端路由器存在异常数据，大家只能马上启程赶往7#电厂所在地。4小时后，大家抵达目的地并开始测试。先检测7#子网的工作状态，LAN内部数据交换正常，没有垃圾比特流存在。打开路由器工作表，其中的错误数据记录有少量帧延迟数据包，WAN连接数据交换故障现象依旧，网络测试仪测试的通道测试数据基本与中心网络相同。用F69x流量测试仪测试通道流量，发现大量“垃圾比特”，数量为55kbps，其中35％指示数据来自远端路由器。由此可以断定故障是由远端路由器或靠近路由器一段的DDN链路(可能性很小)造成。更换从信息中心带来的备用路由器后，故障消失。

[诊断评点]WAN通道故障可由多种原因造成。一般来讲，通道测试不合格就表明含路由器在内的WAN链路有问题。由于WAN链路可以由多种传输介质及传输协议组成，比如ATM、DDN、ISDN、Frame Relay、SDH等等，所以针对不同链路类型严格地讲要用专门的测试工具进行测试。
但因为一般用户都不配备WAN测试工具(部分集成商有相应配置)，所以用户或系统集成商只能先用排除法首先确定是否是路由器(含路由器)以内的网络问题，然后，才能向WAN链路运营商提出检查服务通道的要求。本故障是由远端路由器故障造成，路由器除了传送正常数据外还向WAN链路方向发送大量垃圾比特，从而占用通道流量，严重影响正常数据传输。早期路由器工作虽然不稳定，但每次故障时间不长，所以在“15分钟”内故障能自愈(此类故障大家称其为软故障)。本次故障由软故障转变为不能自愈的“硬故障”，反而为排除故障提供了有利条件。由于多数数据被DDN专线链路给“过滤”掉了，且远端路由器对错误数据的统计识别功能有限，所以从信息中心观测到的垃圾比特比较少，观察远端路由器也不能发现详细的错误统计。但ICMP Ping测试、ICMP Monitor等测试错误数据较大，与远端测试数据基本相等，同时从远端测试到的垃圾比特流很大(“F69x流量分析仪＋F68x网络测试仪组合”具有极强的检测功能，支撑完整的错误识别和统计功能，这也是为什么大家认为DDN链路出故障的可能性小的原因)，所以断定故障出在远端路由器。其实，如果远端子网络配备有合适的测试工具的话，本故障在很短的时间内就可以排除。

[诊断建议]工欲善其事，必先利其器。大型网络配置一些备用网络设备是必要的，还需要按网络规模和使用级别、维护人员的技术等级配备相应的维护工具，并建立一整套测试维护的方案和规定，这样才能保证网络的可靠性，并保证能及时处理各种网络故障。
因为一般的网络设备都具备部分网管功能，能统计并识别30％～40％左右的网络错误和故障信息，所以，有时这给人一种错觉：认为只要具备网管功能，就能发现网络的一切故障。其实，进一步的性能测试需要专用工具，要求这类工具不光能能识别各种正常的工作协议，还要能识别形形色色的“网上垃圾”。一般来讲，除了配备相应的LAN测试工具外，由于WAN链路的测试维护由WAN链路运营商(比如电信企业)负责，但网络用户和系统集成商也需要配备一定数量的WAN测试工具以备性能评测、故障救急以及定期测试的需要。

[故事之十三]PC机开关电源故障，导致网卡工作不正常，干扰系统运行

[症状]今天的病人很有趣，是某电信局网管中心，十万火急地要求网络医院帮助马上解决燃眉之急。放下电话大家马上启程奔往“目标”所在地。为提高效率，途中继续与该中心主任进行通讯联络了解“病情”。网管中心所在地为一地区中心，下辖两个县级市和7个县，安装在地区网管中心的网管系统在两个月前发出了报警信号，提示某县级市的网络有异常情况。一个月前省局工作组在检查工作时发现该县级市不在网管中心的网络拓扑显示图上，询问原因，当时答曰：今天正好赶上该县级市进行工程施工，所以将网络管理功能暂时关闭，故在网管机显示器上的拓扑图中无该县级市的网络图标。现在所谓“十万火急”的问题即是：明天工作组将要进行第二次验收检查，而网管系统是此次的重点检查项目之一，不可能再用网络工程在施工为由回避检查该子网的状况。因为网络拓扑图上的报警信息仍在，该县级市的问题也一直没有彻底解决(县级市子网却一直报告网络正常，速度很快！对定位故障一直不太主动)，明日检查恐怕无法“过关”，所以才想到引入“紧急外援”。另外需说明的一点是，该故障在初期时隐时现，最近才由飘忽不定演变为高频发作甚至是持续存在的故障现象。
针对这一情况，大家决定先不去地区中心，而是直接转道前往该县级市网管中心，因为从网管指示的范围看问题很可能出在此处。另外，该中心距大家现在的位置比地区中心也更近一些。

[诊断过程]半小时后即抵达目的地，马上投入“体检”工作。根据地区网管中心提供的线索，该子网的路由器报告错误数据流量较高，因此直接对该子网进行测试。该子网为用交换机连接的多网段结构，含8个10BaseT和18个100BaseT以太网。用网络测试仪接入网络作自动监测，测试路由器平均错误流量记录为3％，有效流量为7％(广域连接用的是E1链路)。观察交换机自身提示的错误流量系指向第一插槽的3＃端口所连接的子网段，其它子网段测试正常。3＃子网段为拥有97个工作站的100BaseT以太网网段，DNS服务器、IP服务器和其它主要的业务服务器也挂在该子网段内。测试3＃端口的错误计数统计值为25％，随即将F683“网络万用表”(即网络测试仪)移动到3＃网段进行监测。结果指示：错误类型为帧校验错误和其它未分类错误(这可以是为无帧头结构的、且非碰撞类型的自由帧、离散帧等)，比例分别为27％和11％，其中正常数据包流量为3％。27％的错误统计值与交换机提示的错误统计值基本一致，但还有11％的错误交换机和路由器等不能识别，需要进行定位。断开路由器，错误指标略有降低。这表明故障确实是在该子网，与WAN链路基本无关。由于子网段全部由集线器堆叠而成(8×16Port)，故进一步观察网络测试仪F683指示的全部错误定位数据。仪器提示97个工作站和5个服务器均发出类型为FCS帧校验错误的数据包，数量不等。
由于全部工作站均发出FCS帧校验错误帧，所以不认为是所有的工作站网卡都有问题(这种可能性微乎其微)，而故障原因很可能是电缆故障(全部电缆打线有误或采用了假冒伪劣电缆)和干扰窜入，如信号干扰、接地干扰、电源干扰、辐射干扰等等(包含在未分类错误类型中)。网管人员认为，由于电缆系统在竣工验收时全部都采用ISO11801标准进行过认证测试，测试工作是网管中心自己承担的，所以应该没有问题。
为快速定位故障，采用通常的“二分法”隔离网段：先将一半的集线器断电，故障依旧，再次将其中一半集线器(即总量的四分之一)断电，故障消失。恢复供电，逐个拔掉该四分之一集线器(两个集线器)上的工作站电缆插头，当拔下6号集线器的7＃端口连接的工作站电缆插头时，网络万用表上的错误指示全部消失！
网管人员断定，故障为该工作站之网卡的可能性不大，因为所有的网卡昨天为了迎接检查验收都进行过相邻三组网卡的两两互换试验和三台相邻整机的两两换位试验(该中心没有配备其它的网络测试工具，只好采用这种常用的但经常是有效的所谓“笨办法”)。用网络测试仪对此故障工作站的网卡进行测试，结果其端口的物理参数和工作协议都正常。由此可以大体断定故障出在工作站的其它部位，且基本是干扰类型的错误(属于未分类帧错误类型)，不排除线缆引入过量噪声的可能。拔下网卡一侧的电缆插头，故障消失，说明故障不是由电缆噪声引起。靠近该工作站可以闻到一股虽不是十分明显，但却比其它工作站都强烈的电器“烧焦”味(不过，还远未到令机器冒烟的地步)。贴近机器可以听到开关电源中发出的明显的“咝咝”响声。测试工作站与服务器的联络情况，可以看到大量的重发帧和无效帧。更换备用的开关电源，故障排除。

[诊断评点]故障原因比较简单，是由单台工作站开关电源故障产生的放电干扰信号窜到网卡输出端口后进入网络所造成。该干扰信号进入网络后占用大量的网络带宽，破坏其它工作站的数据包(即表现为“患者”众多的FCS帧校验错误类型的数据包，其比例随各个工作站实际的正常流量而定)；同时该干扰信号还干扰服务器、路由器的工作(重发帧、无效帧等)，使得地区中心的网管机屏幕上经常有报警状态提示。由于网络总流量为41％左右(低于40％的平均流量时用户基本不会感到网络变慢)，有效流量只有3％，所以县级市子网上的用户虽然自己发出的数据包有很多被破坏而需要重发，同时接收到的数据包有很多已被破坏而需要重收，但是基本上不会感到网络速度有明显的变慢！！

[诊断建议]网管系统通常只能发现约30％～40％的网络故障(这取决与被管理设备支撑网管的能力和分析、记录网络异常流量的能力)。当有故障报警后，多数情况下需要进一步迅速确定具体的故障位置和故障属性。本次故障不能精确定位并马上排除的原因是多方面的，其一，县级网由于没有网络维护工具，仅靠网络维护人员的经验和从互联网上下载的某些App来监测自己的网络，这是直接导致了此次故障长时间无法解决的原因。现阶段，按不同的网络维护规模和级别为相应技术水平的网管人员及运行维护人员配置合适的工具到目前为止一直是让网络规划人员、计划单位和网络维护人员自己都搞不清的事情。其二，本次故障本来原因比较简单，但因维护体制方面存在的问题从而导致在故障查找过程中不能密切配合和协作，使得问题长期未能解决。其实，如何比较全面、有效、快速和低成本地实施网络的管理和维护已经有许多成熟的方案和做法。建议网管人员和运行维护人员在忙于快速建网、不断跟踪网络新技术和接触新设备的同时也要抽出部分精力来研究有关网络维护的理论、方法和成熟的方案，力争达到事半功倍的效果。比如，进行完整的网络文档备案工作、定期测试、网络基准测试、性能监测、体能测试、通道测试、协议监测、流量分析等工作就一直是一些大型网络成功地防止严重事故发生的有效而简便的手段。
你知道吗，与你见到的和想象的都不一样，消防队平时更重要的工作并不是救火，而是防火！！网络维护工作亦莫不如是！可以完全相比拟。

[故事之十四]线缆连接错误，误用3类插头，致使网络升级到100BaseTX网络后无法上网

[症状]某船运企业，为满足日益增长的业务需求，三周前开始网络升级改造工程，按设计规划将10BaseT网络全部升级为100BaseTX以太网，电缆系统不作任何改动。昨天设备安装调试工程全部结束，今天凌晨开始网络割接作业。所有工作站更换100BaseTX以网太网卡，然后分批接入网络。此时工程人员发现一些奇怪现象，比如：有些工作站不能联入网络；有些工作站第一次可以联入网络，过一段时间再次连接则无法进入；有的工作站开始时能联入网络并且工作很正常，但过一段时间后则出现连接断续或数据出错的现象。集成商起先以为是网络平台安装不当，遂将系统平台重新清理并安装了一次，出问题的工作站系统App和应用App也进行了重新安装，结果毫无改善。“折腾”了将近一整天，也无法为用户提供服务，业务基本中断。

[诊断过程]接到报告后马上赶到“出事地点”，启动包括故障工作站在内的全部系统成员进入网络运行。用F683网络“万用表”对故障网络首先作常规健康测试，一分钟后测试结果如下：网络利用率1.3％(此时员工已经全部下班)，碰撞率8％，错误率11％，广播9％。显然网络碰撞率和错误率比较高，打开错误诊断定位功能，显示FCS帧错误、本地碰撞、碎帧等错误计数。这说明网络可能存在网卡工作失常、电缆系统故障、干扰或接地回路等方面的问题。查看具体的FCS错误帧测试结果，发现有许多工作站发出错误的FCS数据帧。一般来将，同时存在多个网卡失效的故障是不大可能的，此时的FCS帧错误多数由电缆问题尤其是有超长链路的电缆问题所引起而不是由网卡所引起。但为慎重起见，大家先随机抽查其中两张网卡进行测试，结果正常，再测试对应的集线器端口，其物理参数结果正常，工作协议匹配无异。由此则可以有把握地确定故障的原因是由电缆系统的问题引起的。
用户告知，本系统采用的是五类线，共有270台工作站，划分为6个网段，有一个专网路由器和一个公网路由器，升级前一直工作在10BaseT以太网状态，整个系统除了业务一部经常反映网络速度偏慢和偶尔的连接断续外，其它部门使用状况一直很正常(业务一部工作量最大)。今天开始升级工作后部分工作站出现上面提到的各种故障现象，涉及范围大约有近三分之一的工作站。询问用户以前是否对布线系统进行过测试，答曰：“只测试过通断，因为在10BaseT以太网一直能上网，所以布线系统应该不会有问题。”
为快速定位故障，随机抽取了其中10条有问题的链路进行测试，结果为：一分二插座故障8个，3类线连接模块3个，综合近端串扰PS NEXT参数不合格4个。检测结论：该系统布线工程存在严重问题。

[诊断评点]网络布线工程的低劣质量一直是综合布线工程中的一个让人担心的严重问题。目前虽然有成熟的测试标准和方法，但多数用户并不知悉或不要求按标准进行现场认证测试。本系统的电缆故障存在多种原因，均是由于工程设计、施工和验收不规范造成。现分述如下：
a)一分二插座故障：系由接线错误所至。用户在设计时没有考虑到扩容的需要，所以在新增用户时采用了这种不规范的一分二插座，一个插座可以连接2个PC机。从原理上讲这种用法是基本上可行的，这种接法要求将1-2/3-6两线对联接一台PC机，而将4-5/7-8两线对联接到另一台PC机上。但实际的测试结果却发现线对接法是1-2/3-6和4-5/3-6，用户把3-6线对当成了直接的“共享媒体检测总线”！！在10BaseT网络中这种错误接法可以勉强工作。虽然这会造成全部网络流量中的数据帧会存在不少错误，但由于多数现存网络的利用率(流量)不高，用户是难于察觉布线中程中的此种异常情况的。
100BaseTX网络对阻抗不匹配和近端串扰比较敏感，升级后这种错误接法会导致上网困难；(注：同轴电缆可以用三通匹配连接器将工作站接入网络，此时阻抗仍保持连续，但双绞线不可以直接并联，否则阻抗异常。)
b)该系统在用户数增加，网线数量不敷使用时网管人员进行了自行扩容，不幸的是他们选用的是假冒的5类插头(实际上是3类插头)。在10BaseT网络3类插头不会影响网络正常运行，但升级后近端串扰NEXT等参数将严重影响工作站与网络连接并经常导致数据出错。不经测试，此3类插头将会长期潜伏而不被发现。
c)由于采用一分二插座，测试电缆的近端串扰指标时必须考虑其它线对的综合影响(非一分二接头的链路多数只使用两对线的网卡)，因此，在数据流量大时，综合近端串扰PS NEXT等参数不合格的链路有可能出错或导致工作站连接困难。

[诊断建议]网络投入运行前，布线系统(电缆、光缆)要首先进行认证测试，用户可以选择的标准很多，目前多建议选用TSB-67或ISO11801等国际流行标准进行测试。只测试物理通断后就认
为链路肯定可用，这一认识是非常片面的也是非常有害的。采用一分二插座的链路一定要测试综合近端串扰、综合远端串扰等高端参数，最好选择Cat5n标准进行认证测试。为此，大家建议船运企业将全部布线链路连夜进行测试和清理，并对清理后PS NEXT等高端参数仍不合格的链路进行最后
标记，以便日后进行更换。

[故事之十五]私自运行Proxy发生冲突，服务器响应速度“变慢”，网虫太“勤快”

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

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

[诊断评点]故障原因有三。原因之一:是IP地址重复,原因之二:是运行非法路由代理。当业务网用户要求进一步的地址解析分析时，留守机与数据服务器发生冲突，多数的数据流向发生混乱(注意，此时的数据帧结构仍正常)，使用户的访问发生“梗阻”。应用App则经常要求重新联络和重传数据，导致流量偏高、业务流程速度变慢。由于冲突基本限制在原信息中心网络中，所以企业数据服务器的流量显示正常！网管系统也无错误数据包报告！原因之三：对留守人员的管理出现真空。留守人员因“无聊”(员工自述)而渴望“越权”连接互联网，并由此开始迅速成为一名“白日网虫”，进而干扰正常业务流程。由于其操作并不一定持续存在，从而导致问题出现一个多月不能解决。其实，办公网中的互联网用户也会或多或少地受到影响，只不过因白天用户的使用频率低未曾察觉而已。

[诊断建议]网络管理的漏洞大多数来自于内部管理人员，建立严格的内部管理机制是非常必要的。同时，建议将MAC地址的备份列入必备文档。另外，每日对网络进行状态自动搜寻会有助于很快发现并清除非法用户。
健康的网络维护方案中其实早就有关于定期测试(包括每日测试和每日循环测试)的项目，只要坚持每日必要的测试和检查，就可以保证99.9％的网络不会有超过2天而解决不了的严重网络问题存在。
[故事之十六]网线共用，升级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网络布线系统中表现不明显的问题同时也给集成商、工程商和广大用户造成一种错觉，认为布线系统只要是物理上联通的就不会有问题，从而忽视了影响链路质量的布线产品品质问题、施工工艺问题对网络造成的严重影响。
建议网络设计者首先采用标准化的设计方案，且只有工程商和用户在签订建造网络的合同时选用标准化的施工工艺和标准化的现场认证测试方案，才能初步保证综合布线系统的质量。
《网络测试和维护方案》中一般建议每年(必要时每半年)对布线系统轮测一遍，以保证布线系统的性能合格，排除因布局变动、用户数量增删和人为调整等原因对布线系统造成的损害。另外，网络的业务工作和故障情况要有比较准确完整的记录，这样才能有助于故障的查找。如果“病人”对自己网络的业务流程比较熟悉，则可以避免动用众多人员加班配合排除故障。

[故事之十七]供电质量差，路由器工作不稳定，造成路由漂移和备份路由器拥塞

[症状]今天的“病人”是位居某中心城市的一家大区银行，报告的故障现象是：故障时断时续，呈周期性“发作”，每隔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电源不出问题，一般不会影响网络的正常运行，但谐波干扰是严重影响网络性能的原因之一，一旦窜入网络则引起的故障多数都是“致瘫性”或致命性的。还由于多数用户对干扰类型的故障“相当地”不熟悉，故提请大家引起较多关注。