2.3.27 时断时续的网络
江苏 王雪峰
以下描述的这次故障，曾经在很多地方发生过多次，笔者认为有必要介绍给大家。为了让大家能更清楚的了解网络的故障，首先介绍一下我校的网络结构。校园网使用一台Cabletron交换路由器作为边界路由器，同时也用它把校园内部划分为5个虚网，每个虚网各有一个堆叠的二层交换机作为台式机和笔记本的接入设备，主干为千兆，百兆到桌面。
故障出现在2003年9月初，正值学校开学之际，我接到一个同事的求助电话，说他的机器不能上网了。这个同事的主机所在的虚网和我的网络中心不在同一个虚网中，于是急急忙忙从这栋楼的3楼跑到那栋楼的6楼，到了同事的办公室后，同事说5分钟前还好的，现在不知道为什么就不好上网了。询问了情况后，得知他的机器（安装的系统为Windows XP）最近没有安装什么新的程序，没有移动过电脑，也没有拔过跳线。我首先按惯例检查了主机的IP地址配置，进入MSDOS方式，使用IPCONFIG命令查看：
C:>ipconfig |
配置是正确的，然后ping 自己的IP地址：
C:> ping 210.16.2.30 |
这说明IP地址是生效的，网卡工作正常。
再使用ping命令，测试从本机到网关的连接情况：
C:> ping 210.16.2.1 -t |
从主机向网关发送的数据包，全部都得到了回应，线路是连通的。打开浏览器，也能够正常上网，一点儿都没问题。
“这不是正常的吗？”我有点不耐烦了。
他也觉得奇怪：“神了，这电脑一到医生手里，就没病了！”
“可能是你刚才操作错误，导致误认为网络断开了。”我说。
“真是不好意思，让你白跑一趟！”他也显出遗憾的神情。（相信大家也遇到过这种事情）
我在他的一阵谢谢声中，走出办公室。
谁知刚刚走到楼梯口，他就冲了出来，“网络又不通了！”
我只得又回到他的电脑前，再ping网关。发现ping出的数据包未能到达网关。奇怪，刚才还好的，怎么现在又不通了呢？难道是网卡或者系统有问题？正在疑惑之际，发现又通了。为了排除主机出现问题的可能性，我决定更换一台主机。幸亏那天带了笔记本，于是我把台式机上的网线插到我的电脑上，配置好IP地址后ping网关，大概等待了10分钟左右，连接正常。心想，可能真是他的主机有了问题。就在这时，发现网络又断开了。断开的现象大概持续了50秒钟，然后又恢复正常。这回可以基本排除主机的问题了，因为两台不相干主机同时出现同样此类问题的几率几乎为零。鉴于此现象，我首先排除了连接线缆的故障，因为连接的线缆不可能出现这种时断时续的情况，故障最有可能会出在线缆的另一端—二层交换机上。
于是来到这栋楼的设备间，查看交换机的状态，这是一个由两台交换机的堆叠，其中一台交换机上有一个上联的千兆端口。我把笔记本接到交换机的其中一个端口上，再ping网关。发现每过4分钟到10分钟，网络就会断一次，并且40到50秒后又恢复正常。经过观察发现：交换机的各个端口均正常，没有发现端口指示灯的异常情况。难道真是交换机出现故障了？算了，索性把交换机重启一下。谁知重启后，故障依旧。可能交换机真的出了问题，我正想是否要把堆叠模块换到另外一个交换机上的时候，我的手机响了，又一个同事告诉我他的机器一会儿好上网，一会儿又不好上网。而这个同事的主机在另外一个虚网中，同时出现相同的时通时断情况，那极有可能是连接这两个虚网的路由器出了问题。
我急忙回到网络中心，在我的网管机上ping路由器的地址（我的网管机是直接连在交换路由器的百兆模块上的），也是时通时断。这时电话一个接着一个象暴风雨一样袭来，我已经招架不住了。我观察了一下，每过4分钟到10分钟，路由器所有模块的指示灯都会同时熄灭，接着控制模块上的“HBT”灯闪烁（此灯闪烁表示正在启动），然后“OK”灯亮起，最后所有模块的指示灯均显示Online（路由器启动完成）。这个现象说明路由器正在自动重启，而且40秒左右的网络断开时间正好是路由器的重启所需的时间。现在问题已经找到，肯定是路由器有问题。
趁着路由器正常工作的时候，把笔记本的COM口使用路由器的专用CONSOLE线连接起来，建立超级终端。在管理模式下使用命令“system show bootlog”查看系统的启动记录，各个模块的加载均属正常。造成路由器重启的原因，最大的可能就是CPU的利用率达到100％。使用“system show cpu-utilization”命令查看CPU的使用率：
SSR# system show cpu-utilization |
（前者是指5秒钟内CPU平均使用率为50％，后者是60秒钟内CPU平均使用率为60％）
结果果然如此。连续使用此命令后得知CPU利用率逐渐上升，当达到95％的时候路由器便自动重启。看来路由器的负载太大了，因为平时正常情况下，CPU的使用率仅为1％—6％左右。当网络使用高峰期的时候CPU的利用率会稍微高一点。但到底是什么让路由器过载呢？幸好以前曾经给路由器设置过日志记录，把日志发送到一个日志服务器上。但是打开这台服务器所记录的日志并未能找到有用的线索。因为当路由器负载过大时，它就不能往日志服务器上发送日志了，我只能用“system show syslog buffer”命令来查看当前系统缓存中的记录了：
SSR# system show syslog buffer |
很明显，“210.16.3.82”这台机器在使用ICMP协议向其他主机发起攻击.据此判断，这台主机要么是中毒，要么是被黑客利用了。鉴于当时的情况分析，可能是网络中存在中了“冲击波杀手”病毒的主机。该病毒使用类型为echo的ICMP报文来ping根据自身算法得出的ip地址段，以此检测这些地址段中存活的主机，并发送大量载荷为“aa”，填充长度92字节的icmp报文，从而导致网络堵塞。而且病毒一旦发现存活的主机，便试图使用135端口的rpc漏洞和80端口的webdav漏洞进行溢出攻击。溢出成功后会监听69（TFTP专业端口，用于文件下载）端口和666-765（通常是707端口）范围中的一个随机端口等待目标主机回连。
根据该病毒的传播机理，立刻在路由器上设置访问控制列表（ACL），以阻塞UDP协议的69端口（用于文件下载）、TCP的端口135（微软的DCOM RPC端口）和ICMP协议（用于发现活动主机）。具体的ACL配置如下：
! --- block ICMP |
最后再把deny-virus这个ACL应用到上联接口（uplink）上：
acl deny-virus apply interface uplink input output |
这样就可以把“冲击波杀手”从校园网的出口处堵截住。为了防止已经感染“冲击波杀手”的主机在校内各个虚网之间传播，把这个ACL应用到校内各虚网的接口上。这时使用“system show cpu-utilization”查看CPU的使用率，它又恢复到正常状态，等待了一段时间后，再没有出现重启现象。
由于路由器不能自动丢弃这种病毒发出的攻击数据包，从而导致路由器重启。为了彻底解决问题，还得升级路由器的IOS（可以使用“system show version”来查看当前使用的IOS的版本）。记得两年前在“红色代码”病毒盛行的时候，也出现过路由器因过载而不断重启的现象，升级IOS以后就恢复正常了。于是我立刻和设备提供商取得联系并获得最新的IOS映像文件，在笔记本上打开TFTP服务，并把IOS映像文件放在TFTP服务的默认目录中，然后在路由器上（配置模式下）使用“system image add”命令来更新路由器的IOS：
SSR# system image add 210.16.1.100 ssre9050（ssre9050是系统映像文件名，210.16.1.100是我的笔记本的地址，在使用此命令前，从路由器上ping一下主机，以确保路由器和主机已经连通）
Downloading image‘ssre9050’from host‘210.16.1.100’ |
再用“system image choose”命令选择刚刚从TFTP服务器上下载的映像文件作为下次启动的映像文件：
SSR# system image choose ssre9050 |
最后重启路由器。至此，路由器故障基本全部解决。
| 回书目 上一节 下一节 |
相关文章
