路由器一般故障的解决方法

　　故障一：病毒引起路由器过载

　　此次故障发生地的拓扑结构是这样的：使用一台EnterasysSSR8000作为边界路由器，同时也用它把校园内部划分为8个虚网，每个虚网各有一个堆叠的二层交换机作为台式机和笔记本的接入设备，主干为千兆，百兆到桌面。

　　那天，我接到一个同事的求助电话，说他的机器不能上网了。这个同事的主机所在的虚网和网络中心不在同一个虚网中。听同事介绍说5分钟前还好的（能够上网），现在不知道为什么就不好上网了。而且他的机器（安装的系统为WindowsXP）最近没有安装什么新的程序，没有移动过电脑，也没有拔过网线。

　　首先，排查网络客户端的错误配置。进入MSDOS方式使用IPCONFIG命令检查主机的IP地址配置：

　　C:>ipconfig

　　Windows IP Configuration

　　Ethernet adapter 本地连接:

　　Connection-specific DNS Suffix . :

　　IP Address. . . . . . . . . . . . : 210.16.2.30

　　Subnet Mask . . . . . . . . . . . : 255.255.255.0

　　Default Gateway . . . . . . . . . 210.16.2.1

　　上面显示的配置是正确的，然后ping自己的IP地址

　　C:> ping 210.16.2.30

　　Reply from 210.16.2.30: bytes=32 time<1ms TTL=128

　　Reply from 210.16.2.30: bytes=32 time<1ms TTL=128

　　这说明IP地址是生效的，网卡工作正常。

　　再使用PING命令，测试从本机到网关的连接情况：

　　C:> ping 210.16.2.1 –t

　　Reply from 210.16.2.1: bytes=32 time<1ms TTL=128

　　Reply from 210.16.2.1: bytes=32 time<1ms TTL=128

　　……

　　从主机向网关发送的数据包，全部都得到了回应，线路是连通的。打开浏览器，也能够正常上网，一点儿都没问题。现在的网络是正常的！？正在怀疑的时候，发现网络又不通了！发现ping出的数据包未能到达网关。奇怪，刚才还好的，怎么现在又不通了呢？难道是网卡或者系统有问题？谁知过了一会儿，发现又通了。幸亏那天带了笔记本，于是我把台式机上的网线插到我的电脑上，配置好IP地址后ping网关，也出现时断时续的情况。断开的现象大概持续了50秒钟，然后又恢复正常。这回可以基本排除主机的问题了，因为两台不相干主机同时出现同样此类问题的几率几乎为零。鉴于此现象，我首先排除了连接线缆的故障，因为连接的线缆不可能出现这种时断时续的情况，故障最有可能会出在线缆的另一端——二层交换机上。于是来到这栋楼的设备间，查看交换机的状态，这是一个由两台交换机的堆叠，其中一台交换机上有一个上联的千兆端口。我把笔记本接到交换机的其中一个端口上，再ping网关。还是同样的故障，而且还发现每过4分钟到10分钟，网络就会断一次，并且40到50秒后又恢复正常。经过观察发现：没有发现端口指示灯的异常情况，说明交换机的各个端口均正常。难道真是交换机的内部系统出现故障了？算了，索性把交换机重启一下。谁知重启后，故障依旧。可能交换机真的出了问题，我正想是否要把堆叠模块换到另外一个交换机上的时候，我的手机响了，又一个同事告诉我他的机器也出现相同的故障现象。而这个同事的主机在另外一个虚网中，同时出现相同的时通时断情况，那极有可能是连接这两个虚网的路由器出了问题。

　　这回问题集中到路由器上了。我急忙回到网络中心，从路由器的外部指示灯上看，没什么异常现象。在我的网管机上ping路由器的地址（我的网管机是直接连在路由器的百兆模块上的），也是时通时断。我又继续观察了一段时间，发现每过4分钟到10分钟，路由器所有模块的指示灯都会同时熄灭，接着控制模块上的“HBT”灯闪烁，然后“OK”灯亮起，最后所有模块的指示灯均显示Online。我解释一下，“HBT”灯闪烁表示路由器正在启动，也就是说正在自动重启，而且40秒左右的网络断开时间正好是路由器的重启所需的时间。现在问题的查找工作已经结束，肯定是路由器出了故障。具体是什么问题，还需要进一步的检测。

　　趁着路由器正常工作的时候，把笔记本的COM口使用路由器的专用CONSOLE线连接起来，建立超级终端。在管理模式下使用命令“system show bootlog”查看系统的启动记录，发现各个模块的加载均属正常。造成路由器重启的原因，最大的可能就是CPU的利用率达到100％。使用“system show cpu-utilization”命令查看CPU的使用率：

　　SSR# system show cpu-utilization

　　CPU Utilization (5 seconds): 50%

　　(60 seconds): 60%（前者是指5秒钟内CPU平均使用率为50％，

　　后者是60秒钟内CPU平均使用率为60％）

　　果然，连续使用此命令后得知CPU利用率正在逐渐上升，当达到95％的时候路由器便自动重启。看来路由器的负载太大了，因为平时正常情况下，CPU的使用率仅为1％—6％左右。当网络使用高峰期的时候CPU的利用率会稍微高一点。但到底是什么让路由器过载呢？幸好以前曾经给路由器设置过日志记录，并把日志发送到一个日志服务器上。但是打开这台服务器所记录的日志并未能找到有用的线索。因为当路由器负载过大时，它已经不能往日志服务器上发送日志了，我只能用“system show syslog buffer”命令来查看当前系统缓存中的日志记录：

　　SSR# system show syslog buffer

　　2003-09-10 09:28:32 %ACL_LOG-I-DENY, ACL [out]

　　on "uplink" ICMP 210.16.3.82 -> 210.55.37.72

　　2003-09-10 09:28:32 %ACL_LOG-I-PERMIT, ACL [out]

　　on "uplink" ICMP 210.16.3.82 -> 61.136.65.13

　　2003-09-10 09:28:32 %ACL_LOG-I-DENY, ACL [out]

　　on "uplink" ICMP 210.16.3.82 -> 202.227.100.65

　　2003-09-10 09:28:32 %ACL_LOG-I-DENY, ACL [out]

　　on "uplink" ICMP 210.16.3.82 -> 193.210.224.202

　　2003-09-10 09:28:32 %ACL_LOG-I-DENY, ACL [out]

　　on "uplink" ICMP 210.16.3.82 -> 218.32.21.101

　　………………

　　很明显，“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

　　acl deny-virus deny icmp any any

　　! --- block TFTP

　　acl deny-virus deny udp any any any 69

　　! --- block W32.Blaster related protocols

　　acl deny-virus deny tcp any any any 135

　　acl deny-virus permit tcp any any any any

　　acl deny-virus permit udp any any any any

　　最后再把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映像文件。至此，路由器故障全部解决。

　　从这场故障处理中，我们可以得到这样的教训：时刻关注网络上事态的发展，并作出相应的解决方案，而且付诸实施。教育网用户可以在http://www.ccert.edu.cn网站上订阅安全公告服务，一旦有新的漏洞出现，CCERT安全响应小组会自动发送邮件给你。当时暑假期间得知“冲击波”后，由于及时在路由器上做了设置，所以“冲击波”病毒没有在网内泛滥，但随后的“冲击波杀手”没有及时设置相应的ACL，所以才导致这次的网络瘫痪。实际上，在这次的“冲击波”和“冲击波杀手”的袭击中，很多城域网也因此陷入瘫痪。这些经历一次又一次的警告我们：时刻关注网络安全，及时积极的应对。

　故障二：ICMP Redirect

　　这是个什么问题呢？首先给大家描述一下。虽然路由器在运行时没有出现明显的异常现象，但是却经常看到这样的日志：

　　Jul 09 15:54:21 %ACL_LOG-I-PERMIT, ACL [out]

　　on "uplink" ICMP 209.24.79.200 -> 219.157.38.52

　　Jul 09 15:54:21 %ACL_LOG-I-PERMIT, ACL [out]

　　on "uplink" ICMP 209.24.79.200 -> 219.167.139.16

　　Jul 09 15:54:21 %ACL_LOG-I-PERMIT, ACL [out]

　　on "uplink" ICMP 209.24.79.200 -> 61.132.1.43

　　Jul 09 15:54:23 %ACL_LOG-I-PERMIT, ACL [out]

　　on "uplink" ICMP 209.24.79.200 -> 24.232.18.109

　　Jul 09 15:54:23 %ACL_LOG-I-PERMIT, ACL [out]

　　on "uplink" ICMP 209.24.79.200 -> 211.146.112.211

　　…………………….

　　其中“209.24.79.200”是路由器的上联接口地址，我不知道为什么会出现这么多从路由器发到这些没有规律的IP的ICMP数据包。查查这些IP，有的来自国内各省，有的来自日本，有的来自美国、阿根廷、新加坡，毫无规律。难道是有人在攻击路由器？或者是内部有肉机被人用来攻击？而且奇怪的是只有出去的数据包的记录，却没有记录进入的数据包？

　　说起ICMP，大家肯定是熟悉不过的了。最常见的ping命令就是使用ICMP的。ICMP的全称是Internet Control Message Protocol（网间报文控制协议），它是IP不可分割的一部分，用来提供错误报告。一旦发现各种错误类型就将其返回原主机，基于ICMP的攻击方法也多种多样。到底是什么原因导致生成这样的日志？让我带大家一起来查一查。

　　我校的拓扑结构是一个简单的星型结构，中心节点就是一台三层交换式路由器（Enterasys 公司的SSR8000）。其中一个端口上联到CERNET，其他端口都是内部连接，且为内部网络基于端口划分了多个VLAN。为了查看该信息是否从网络内部发出，又给内部VLAN的各个接口设置了日志，还是没有相关的ICMP记录（原先的日志只是记录上联接口的数据）。排除了内部计算机发出ICMP数据包的可能，那问题就可能出现在上联接口上，而日志记录只能记录到协议层的信息，不能记录更深层次的数据包。如何查看上联接口的数据包呢，比较方便的方法就是使用端口镜像功能，利用连接在镜像端口上的计算机来抓取和分析数据包。

　　首先下载数据包分析软件WINDUMP（下载地址：http://windump.polito.it）。在A计算机上，安装之，然后连接到将要镜像的RJ45端口上。再在B计算机上，也安装WINDUMP，并连接到当前的VLAN1（网关：222.222.222.1，掩码：255.255.255.0）中。

　　一切准备就绪后，接着就是开始端口镜像。使用计算机B登录到路由器，进入配置模式，输入以下命令：

　　SSR(config)# port mirroring dst-ports et.1.3 src-ports gi.4.1

　　上面的命令把上联端口（gi.4.1）镜像到目标端口（et.1.3），目标端口就是计算机A连接的端口。在计算机A上，进入DOS提示符，转到WINDUMP所在的目录，输入命令：

　　C:\> WINDUMP –N

　　windump30alpha: listening on \Device\NPF_{911DB410-C01E-49E8-B524-50132C6A56A8}

　　………

　　15:57:17.516203 IP 222.222.222.17.80 > 221.215.142.50.1264:

　　. 46721:48181(1460) ack 0 win 16336 (DF)

　　15:57:17.516337 IP 222.222.222.17.80 > 221.215.142.50.1264:

　　. 48181:49641(1460) ack 0 win 16336 (DF)

　　15:57:17.518043 IP 220.198.22.202.3196 > 222.222.222.99.8882:

　　. 137236:138676(1440) ack 260501 win 64800 (DF)

　　15:57:17.518162 IP 218.79.246.212.64627 > 222.222.222.191.16881:

　　S 2898301189:2898301189(0) win 64240 (DF)

　　15:57:17.518558 IP 209.24.79.200> 218.79.246.212: icmp 36:

　　host 222.222.222.191 unreachable (DF)

　　………..

　　（上面的记录已做过筛选。第一句的参数“-N”表示IP地址或者端口号转换为主机名或端口名，第二句表示windump开始在所选网卡上监听，第三句开始就是WINDUMP记录的信息。）

　　同样在计算机B上也运行WINDUMP：

　　C:\> WINDUMP –N

　　windump30alpha: listening on \Device\NPF_{911DB410-C01E-49E8-B524-50132C6A56B4}

　　…………

　　15:57:54.695935 arp who-has 222.222.222.191 tell 222.222.222.1

　　15:57:55.191475 arp who-has 222.222.222.136 tell 222.222.222.1

　　15:57:57.033354 arp who-has 222.222.222.210 tell 222.222.222.1

　　15:57:57.039057 arp who-has 222.222.222.69 tell 222.222.222.1

　　…………（已作筛选）

　　查看路由器上的日志，我任意找到其中一条关于ICMP的记录：

　　Jul 09 15:51:50 %ACL_LOG-I-PERMIT, ACL [out]

　　on "uplink" ICMP 210.29.42.70 -> 218.79.246.212

　　经查，在计算机A上采集的数据中，有几条记录（最后两条）包含“218.79.246.212”的IP和此记录匹配。从这两句的记录来看，第一行表明从218.79.246.212的tcp端口64627向222.222.222.191的16881端口发送报文。S标志表明设置了SYN标志，报文的流序号是2898301189，没有数据，有效的接收窗口是4096字节，最大段大小(max-segment-size)的选项，请求设置mss为1452字节。很明显，这是一个请求报文。而第二句表明路由器给218.79.246.212返回了一个“unreachable（主机不可达）”ICMP 信息。这说明在这个网段中没有找到IP地址为“222.222.222.191”的计算机。

　　原来，当路由器接收到一个不知道IP地址（也就是说，路由器不知道目标路由）的数据包时，它会尝试发送ARP广播来解析，如果有目标主机回应这个ARP广播，则路由器会把数据包转发给目标主机。如果路由器没有接收到回应，它将会为接下来的4个数据包发送ARP请求，如果当第6个数据包到达时，还没有解析出目标主机的MAC地址，默认情况下，路由器将会在接下来的20秒钟内丢弃第6个以及后续的数据包，并且返回“主机不可达”的ICMP信息给源主机。

　　从计算机B的记录中的第一句也可以得到证明，路由器向该网段中发出一个ARP查询，查找IP为“222.222.222.191”的计算机，结果没有计算机相应，路由器则认为该网段中没有目标主机，所以返回一个ICMP信息给源计算机说明目标主机不可到达，以通知源主机这里存在问题，同时丢弃原始数据包。

　　至此问题已经明朗，原来路由器记录的ICMP都是路由器发送给源地址的“Destination Unreachable”信息。那么为什么这些外面的IP地址会找校内的计算机呢？从采集的数据分析不难发现，这些外部主机主要是找内部的固定的三个计算机。经过历史日志的检查，可以发现这三台计算机的主要相同的记录：

　　07:52:19 Jul 09 07:50:02 %ACL_LOG-I-PERMIT, ACL [out]

　　on "uplink" TCP 222.222.222.136:3159 -> 61.173.209.101:6881

　　08:00:15 Jul 09 07:53:50 %ACL_LOG-I-DENY, ACL [out]

　　on "uplink" TCP 222.222.222.12:3194 -> 219.121.133.197:6883

　　08:00:15 Jul 09 07:57:59 %ACL_LOG-I-DENY, ACL [out]

　　on "uplink" TCP 222.222.222.220:3196 -> 210.238.6.177:6881

　　这三台主机连接目标主机的端口固定在6881到6889之间，而这些端口正是现在比较流行的BT下载的常用端口。难怪以前没有出现过此类日志，直到最近BT流行时，才出现的。主要原因是，这些主机使用BT下载时，在BT服务器上留下了记录，以便其他的主机到这些主机上下载资源，而当这些主机关机后，路由器就告诉它们找不到这些主机了。

　　由于日志服务所记录的是第三层以上的信息，而路由器接收到的数据包在第二层上就被丢弃了，所以没有在日志中记录这些输入的异常数据包。为了减少路由器的日志量，在配置模式下使用“ip disable icmp-messages destination-unreachables”来禁止此类信息的转发。

　　这两个故障均由ICMP引发，而且从某种角度上讲都不是系统配置上的问题，而是由于外部因素引起的。此类故障需要我们经过一定的分析才能查出原因，再作相应的配置才能排除故障。

上一页  [1] [2] [3] [4] 下一页