交换机配置不良使得网络性能劣化

    某网站IT经理顾先生是我们的老朋友了，三年前在Cisco大会上认识，彼此“情投意合”，“兄弟”几个经常在一起交流一些网民心得。他原先在一家国有大型企业中任信息中心主任，负责网络的规划、设计建设和管理维护事宜。有好长一段时间没有他的消息，免费的信箱失效，加之后来换了工作就失去了联系。正思量怎么设法跟他重新取得联络，没想到他却不请自到，来了个“自投罗网”，昨天他因网络问题来网络医院咨询时方知其现在已经辞职到了现在的网站。顾不上仔细询问对方的近况，他便直接进入主题：顾先生所负责的网站最近出现一些问题。白天时常会出现短暂的拥塞，上网用户反映访问购物频道之网上在线商城时经常点击无效，多次重复后仍没有任何反应。此现象已经持续的两周，网站老总责令他必须在两天内找出原因，解决用户无法点击购物的问题，否则……

    故障出现在什么时候？一般是白天，晚上基本不出现。何时开始出现故障征兆的？没有什么征兆，突然出现又突然消失，很不稳定且没有什么规律。

    那么从第一次故障现象出现到今天为止有多久了？就两周。

    两周前你们对网络干了什么？比如调整网络结构、增加或删除网络设备、增加服务器、增删和更改网络用户等？没有。不过网站内容到是几乎天天在变，但这应该不会有什么影响。因为我们装有网管系统，可以随时查看网络个链路的流量状态。对链路的流量还分别设置了门限报警，如果出现流量异常值班人员会马上知道。再说，我们的内部网都是用的100Mbps的网卡，核心交换机使用千兆以太网连接。而网站出口只是8Mbps，出问题时检查过出口流量，从来就没有超过2Mbps，还不如不出故障时的访问流量大。因此，说由于出口瓶颈的原因在访问流量大造成访问困难显然是站不住脚的。对网上商场的服务器仔细检查并用备用服务器试着更换过，但没有任何作用。该用的办法都用过了，实在查不出问题出在哪里。

    有没有做过捕包分析或延迟分析？做过，首先对有关的服务链路进行网管监察，发现链路流量一般只有5%左右，捕包分析发现出现故障是有较大延迟，但Ping包正常。当时试验在故障时在网站内任选一台工作站从网上商城服务器拷贝一个1000M的文件，拷贝速度很快。用协议分析仪的专家诊断系统对捕获的包进行分析，除了发现HSRP协议帧有3000个，其它未见异常。

    诊断过程

    三刻钟后，我们随顾先生来到该网站所在大厦。准备着手进行检查。

    分析故障现象，指示网络主要的问题是访问某个指定的服务器时慢。一般的原因主要有：服务器资源不足，比如接口速度低、CPU速度低、内存不够、开通的应用窗口过多等；访问通道出现瓶颈，访问速度受限；通道上的设备出现处理延迟，影响通道访问的速度等。从内部网的反应看，拷贝文件的延迟很小，速度正常。基本说明网站的内部网络应该没有大问题。

    为了确认访问通道上的是否有流量瓶颈或延迟超长，我们将网络故障一点通接入路由器的出口，将网络综合协议分析仪OptiView接入在线商城服务器通道。从路由器出发送50Mbps(50%)高流量Ping包指向OptiView，这种方法是为了检查该通道的通道能力。可以看到最大的通道能力是95Mbps(发送的流量相应的流量加上为95Mbps)，将流量帧改为一般的IP帧，无须服务器响应，流量仍为50%，此时安装在服务器链路中的OptiView收到的流量是50Mbps，说明网络一点通发送的50Mbps的流量已经全部“安全抵达”服务器。此时的网络状态非常“正常”。从OptiView测试对路由器Ping包的响应，显示时间为12微秒(0.012ms)，结论：此时此刻网络工作正常。

    由于是不稳定出现的“软故障”，接下来我们需要在故障出现时进行测试，好在该故障每天白天都会出现，不怕它不来。

    50分钟后，从外线来的电话报告“故障出现”。我们迅速用OptiView的移动网管查看该通道的流量状态，显示均小于10%，从OptiView上对网站的路由器做Ping检查，时间是1200ms。立即从OptiView发送50Mbps流量给网络一点通，报告收到的流量只有5M，看来不光45M的流量被通道给“滤除”了，而且还引入了很大延迟。检查网站的拓扑图，从图上标注的状况来看该访问通道应该都是100Mbps的以太网链路，中间经过5台交换机到达服务器。在OptiView上对路由器做路径“TraceSwitch”检查。结果显示路径已经改变！整个路径中多出了3台交换机，从而使得原来需要经过5台交换机就能到达服务器的访问包现在需要经过8台交换机才能到达服务器！追踪查看这3台交换机，发现相应链路端口工作状态都是100Mbps。逐级检查延迟响应时间，发现1200ms的延迟就出现在新增加的第一台交换机通道节点上。由于有备份交换机，为了缩短故障诊断时间，试着更换此交换机。10分钟后，交换机更换完毕，开机试验，故障现象消失。

    继续监测至下午收工时间，故障均未再出现。

    诊断评点

    此故障是由于交换机的问题引发的。白天工作时该交换机会不稳定地处在较大时间延迟状态，并且会改变交换机对协议的传输路径。从该故障的表现和OptiView监测到部分STP/HSRP协议来分析，一般配置不良的交换机会出现类似情况。比如，使用STP或HSRP协议可以对端口的连接状态进行监测和从新依据传输的带宽、允许或限制的协议进行端口连接分配。这在高档交换机中是正常的功能，但如果设置不佳或网络出现异常未设定点流量，交换机也会依据设定点条件进行端口路径的检查、运算和重新连接构图，或者对流量带宽进行分配。

    网络的配置文档是很重要的检查故障的参照系，准确的文档备案更是快速故障检测的有力辅助手段。反之，没有配置文档的备案资料会给故障检测带来不少麻烦。维护人员往往不能断定检测的参数到底是正常还是异常。一份不准确的文档备案有时甚至比没有文档病案更糟糕，它可能会把故障检测工作引向"万劫不复"的境地。那时有多少头痛药都是无济于事的。维护人员神经、耐心和体力都会收到很大的挑战。

    诊断建议

    由于时间关系，我们来不及对更换下来的交换机进行检查。根据以往经验，可以初步断定此交换机很可能是配置不良而不一定是有质量问题。我们希望顾先生安排专门时间将此交换机的设置仔细检查一番。如果能找到原来的初始配置文档则参照检查会方便许多。

    后记

    一周后，顾先生告知我们检查结果：该交换机某些端口被人设置为流量选择转发状态。处于这种设置状态的交换机会对链路流量在达到一定值时进行端口路径的重新分配，目的是均衡整个链路的负载。也可以对设置的协议进行端口路径转移，使得按设置要求的在某些协议或流量出现异常时转移交换端口或重新分配端口流量。

    本故障经检查是由于最近安装了Oracle应用软件所至。当启用该数据库流量时，原来的端口只允许部分流量用来处理在线商城的用户访问流量，其它的带宽要用来保证新增加的应用流量对带宽的需要。

    由于顾先生对Oracle关系数据库不熟悉，该项应用工程是承包给一家系统集成商做的。系统集成商在安装系统时为了一次验收合格，故对交换机的配置进行了更改。这一点顾先生的一名配合系统集成商工作的手下是知道的，但他对网站的拓扑结构根本不了解，以为此举对网络没有什么影响，并没有将此情况告之顾先生。

    由于该网站平时就没有定期检查和文档备案的制度，这位老兄当然也不会把这一情况登记入档。这使得我们的检查效率也不会高到哪里去，端时间内要查验出该故障挠度是会很大的。