我把笔记本接到交换机的其中一个端口上,再ping网关。还是同样的故障,而且还发现每过4分钟到10分钟,网络就会断一次,并且40到50秒后又恢复正常。经过观察发现:没有发现端口指示灯的异常情况,说明交换机的各个端口均正常。难道真是交换机的内部系统出现故障了?算了,索性把交换机重启一下。谁知重启后,故障依旧。可能交换机真的出了问题,我正想是否要把堆叠模块换到另外一个交换机上的时候,我的手机响了,又一个同事告诉我他的机器也出现相同的故障现象。而这个同事的主机在另外一个虚网中,同时出现相同的时通时断情况,那极有可能是连接这两个虚网的路由器出了问题。
这回问题集中到路由器上了。我急忙回到网络中心,从路由器的外部指示灯上看,没什么异常现象。在我的网管机上ping路由器的地址(我的网管机是直接连在路由器的百兆模块上的),也是时通时断。我又继续观察了一段时间,发现每过4分钟到10分钟,路由器所有模块的指示灯都会同时熄灭,接着控制模块上的“HBT”灯闪烁,然后“OK”灯亮起,最后所有模块的指示灯均显示Online。我解释一下,“HBT”灯闪烁表示路由器正在启动,也就是说正在自动重启,而且40秒左右的网络断开时间正好是路由器的重启所需的时间。现在问题的查找工作已经结束,肯定是路由器出了故障。具体是什么问题,还需要进一步的检测。
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端口的web
根据该病毒的传播机理,立刻在路由器上设置访问控制列表(ACL),以阻塞UDP协议的69端口(用于文件下载)、TCP的端口135(微软
! --- 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