网管日志-06.08.18 - 升级版生活日记 - 51CTO技术论坛

社区导航: 专家门诊网络技术操作系统数据库程序设计系统应用考试认证 CIO及信息化站长交流综合交流下载基地 51CTO产品服务

【设为首页 | 收藏本站】

51CTO技术论坛» 升级版生活日记 » 网管日志-06.08.18 [ 打印] [ 订阅] [ 收藏] [ 推荐给朋友] [ 本帖文本页]

论坛跳转:

冰雪寒

超级版主

帖子 2871
精华 45
无忧币 68720
积分 42127
阅读权限 200
来自 (保密)

注册日期 2006-1-19

最后登录 2008-11-5

离线

[查看资料] [发短消息] [Blog]

发表于:2006-8-19 22:39　　标题：网管日志-06.08.18
＜上一帖 | 下一帖＞

网络改造的问题还没有忙完，技术支持工程师在前沿给客户解决网络故障时遇到了些麻烦，需要我的支持，并且非常着急，我只好放下手中的工作全力支持他们，以客户为中心，这可是公司的技术人员做事的中心原则。　　大体了解了该客户的网络环境以及出现的故障，详细内容如下：
　网络环境：vdsl接入，2m独享带宽，一台华为1820路由器，三台华为3com交换机，大约50多台客户端计算机，加上两台服务器。
　　网络故障：网络断断续续，经常中断，只能通过重启路由器及vdslmodem设备才会有所改善，但时间不长，仍然出现中断故障。
　　分析解决：
（1）首先排查客户设备上端接入设备（我公司的设备）—vdsl交换机，通过进入vdsl交换机ios，查询客户的接入端口信息：crc错误包及丢弃包非常多，流量非常大。这个信息告诉我下一步测试端口、线路、带宽、设备处理能力及客户端数据包的分析等工作。
（2）从客户处进行测试，首先在加网络负载（即客户网络正常运转）的情况下测试的，使用icmp（ping命令）测试，结果很明显，到网关延时达到了100多ms（正常情况下应该是在3ms左右），并且丢包现象严重。然后再去掉任何负载的情况下进行测试，效果当然要好了许多，没有丢包，但仍有几十ms的延时，这个现象也不正常。
我想应该是中间节点或者中间线路接触不良，也有可能是上端节点端口故障造成的。第一个反映就是检查端口速率及工作模式并作了相应调整，都无济于事，最后也更换了端口，还是不行，看来问题不是出在上端端口。
（3）我开始进行单机测试线路，从离上端设备最近的节点进行了测试，测试结果都正常，然后一个一个节点进行测试，最终确定线路也没有问题。问题究竟出在哪里？难道是客户端局域网问题，客户端局域网是有问题，流量过大造成的，可以扩带宽来解决，但为什么进行不加负载情况下，也有较大延时？
（4）客户带宽的问题，我已经解决了，为该客户扩容到了4m独享专线。但仍有问题，由于客户的华为3com不支持span（端口镜像和监控）又没有hub等共享式设备，无法进行sniffer数据分析，很难判断局域网内部状况。还有一个非常重要的信息就是华为的这款1820路由器cpu负载到了92%以上，这个是非常不正常的，因为作为路由交换设备，cpu负载一般维持在60％以下，对网络的影响还是可以接受的，但如果超过了这个值，网络状况将会很糟糕，甚至down掉的。从这里还可以分析出一个问题，这款路由器本身处理能力有限。
（5）在进行测试之前也考虑到了客户局域网络的p2p传输(bt迅雷电驴等下载)问题，也有可能是病毒原因，但由于不便于做限制，所以没有从这方面进行解决，因为我也从侧面了解到客户的业务是做娱乐视频方面的，需要经常使用p2p方面的软件进行传输。
（6）考虑到这些情况，我认为应该做以下几项工作：一是要更换处理能力更好的路由及交换设备；二是要进行数据包的分析与监测；三是以上如果还不能解决，就需要更换其他上网方式比如直接光纤接入，不走vdsl交换机。
（7）想到就要做到，我先把我测试使用的cisco3620路由器替换了客户的华为路由器，进行测试，效果要好得多，延时减少了，丢包也很少发生，但根本问题仍没有彻底解决，通过观测，流量在急剧上涨，带宽将超越4m带宽，crc错误包减少了，但仍有相当数量的错误包。并且cisco3620的路由器处理能力还是相对比较强大的，但cpu占用率也达到了30%-40%左右，对于思科设备在这个网络环境下能达到这个值，说明内网的确存在重大问题。
（8）之后，我又从公司取了两款交换机，其中一款是cisco2924系列的，支持span，可以进行端口镜像和监控，另一台是cisco2950，现在要做的是替换下客户的华为低端非网管交换机，看看是不是交换机处理能力在作怪，接上了cisco设备，也开启了sniffer，首先开始对其内网进行分析，的确有大量机器进行p2p及其他大数据量的传输，并且更令人可怕的事情发生了，cisco两台交换机ios全部死机，无法进入，而交换机端口之间数据交换仍在进行，只是无法进入到交换机中，即使把所有负载去掉，交换机ios仍然无法进入，我意识到交换机ios彻底损坏了，可能需要重新灌入ios了。但客户的网络问题还没有解决，我也试过其他方法，比如使用相应软件如p2p终结者将其网内的p2p传输进行限制，只是网络流量降下来了，延时小了些，但网络故障依旧。
（9）这些方法只能缓解了部分网络恶劣状况，看来最根本的问题还是没有解决，另外，我通过sniffer抓包分析发现，网络内的超过1400byte的数据包占的比例最大，有的相当数量的数据接近mtu值，甚至超过了以太网的mtu值。根据这些，我想到刚才设备死机及cpu占用率过高的问题，在数据分析的时候，已经排除了病毒的问题，应该是数据巨帧过多，导致设备端口进行转发时无法及时处理，导致端口堵塞造成的，并且这个不仅仅是内网的设备端口，同样在上端设备端口（vdsl交换机）也受到影响，可能是上端vdsl交换机端口不能及时处理巨帧所致？也可是传输介质不能满足数据传输要求（因为vdsl是通过2芯双绞线跳转到客户端的）？
（10）那我就实施最后一种办法，通过光纤直接入户，并且跳过vdsl交换设备，直接接入边界路由器接入互联网。但由于客户着急下班，又正值周五，明天就是周末，所以最后这项工作还没有做，只好安排到了周一继续。

在期间，这些工作都是由几位工程师来配合我的思路完成的，要是一个人来做，头脑都会炸个稀巴烂的。我也想好好休息个周末。
（未完待续）