路由器一般故障到特殊故障的解决.docx

上传人:b****6 文档编号:4666122 上传时间:2022-12-07 格式:DOCX 页数:20 大小:35.68KB
下载 相关 举报
路由器一般故障到特殊故障的解决.docx_第1页
第1页 / 共20页
路由器一般故障到特殊故障的解决.docx_第2页
第2页 / 共20页
路由器一般故障到特殊故障的解决.docx_第3页
第3页 / 共20页
路由器一般故障到特殊故障的解决.docx_第4页
第4页 / 共20页
路由器一般故障到特殊故障的解决.docx_第5页
第5页 / 共20页
点击查看更多>>
下载资源
资源描述

路由器一般故障到特殊故障的解决.docx

《路由器一般故障到特殊故障的解决.docx》由会员分享,可在线阅读,更多相关《路由器一般故障到特殊故障的解决.docx(20页珍藏版)》请在冰豆网上搜索。

路由器一般故障到特殊故障的解决.docx

路由器一般故障到特殊故障的解决

路由器一般故障到特殊故障的解决

   路由器的一般故障分类和排障步骤   路由器相比于集线器和交换机而言,对大家来说可能会有点陌生。

因为很多小型局域网使用代理服务器或者软件路由,很少使用专用的硬件路由器。

但随着局域网的快速发展,路由器在局域网中的应用也逐渐增加,各种路由器故障也随之接踵而来。

   

   从前面的介绍我们了解到路由器也和计算机一样由硬件和软件组成,当然问题可以出现在硬件也可以在软件上。

也许是因为很多管理员对路由器不熟悉或了解不深入的原因,有很大一部分故障都出现在软件上。

笔者总结了以下几种故障分类,方便各位读者排障。

   

   1)硬件故障

   

   路由器的硬件包括RAM/DRAM、NVRAM、FLASH、ROM、CPU、各种端口以及主板和电源。

硬件故障一般可以从LED指示灯上看出。

比如:

电源模块上有一个绿色的PWR(或POWER)状态指示灯。

当这个指示灯亮着时,表示电源工作正常。

接口模块上的ONLINE和OFFLINE指示灯以及TX、RX指示灯。

Rx指示灯为绿色表示端口正在接收数据包;如果为橙色,则表示正在接收流控制的数据包。

Tx指示灯为绿色表示端口正在发送数据包;如果为橙色,则表示正在发送流控制的数据包。

不同的路由器有不同的指示灯表示不同的意义,所以你最好先看说明书。

   

   硬件故障有时也可以从启动日志中查出或者在配置过程中看出。

由于路由器在启动时首先会进行硬件加电自检,运行ROM中的硬件检测程序,检测各组件能否正常工作。

在完成硬件检测后,才开始软件的初始化工作。

如果路由器在启动时能够检测到硬件存在故障,会在系统的启动日志中会记录下来,以便后查。

如果在配置路由器时,当你进入某个端口配置时,系统一直报错,那就有可能是端口的问题了。

   

   此外还要做好路由器运行环境的建设,比如:

防雷接地以及稳定的供电电源、室内温度、室内湿度、防电磁干扰、防静电等,消除各种可能的故障隐患。

   

   2)系统丢失

   

   这里是指IOS(InternetworkOperatingSystem),它就是路由器的一切配置运行的基础--操作系统。

它保存在FLASH中,有时因操作失误或其他不可预料的原因(如:

突然断电),致使FLASH中的IOS丢失,导致路由器无法正常启动。

   

   出现此情况时,还可以使用保存在ROM中的备份操作系统软件,这个备份IOS通常比FLASH中的IOS版本低一点,但足以让路由器启动和工作。

为了让路由器正常工作,必须重新下载新的IOS到FLASH中。

如果FLASH的空间足够大,还可以保存多个IOS软件,并可以选择使用哪个版本的系统。

为了能够在发生此类故障后迅速恢复,最好先把IOS软件保存在安全的服务器中,以便急需。

   

   3)系统缺陷

   

   像WINDOWS系统经常受各种病毒的侵扰而死机一样,IOS的系统缺陷也会致使路由器瘫痪,比如:

红色代码就曾使某些着名品牌的路由器重启。

IOS也有安全上的缺陷,如果不及时升级,不怀好意的人会把你的路由器作为他攻击目标。

随着路由器的发展,现在有的路由器有自动防御攻击的功能,比如:

抵御DOS攻击,防止密码猜测等。

   

   IOS的系统缺陷一般不是通过补丁程序来修补,而是替换为全新的IOS.一旦发现系统BUG,路由器厂商会及时在网站上公布BUG、受影响的系统和相应的新的IOS软件,您必须选择适合你的路由器型号的版本。

思科公司曾称,他们将使用“零故障”的高端路由器软件,它能够消除由电路或人为因素造成的数据或信息丢失故障,即使有错误发生,数据包仍然能够转发下去,从而能够预防网络出现故障,这样就会减少网管的负担。

   

   4)密码丢失

   

   路由器中的密码有两个地方需要设置。

从前面的介绍可以知道访问路由器时有两个基本的访问模式:

用户模式和管理模式。

为安全起见,在进入这两个模式时均需要设置密码。

虽然大家都知道密码是管理员的拥有最大权限的钥匙,但还是有人会把它给忘了。

甚至有人设置的密码太简单以至于被黑客恶意进入并修改了密码。

其实,只要我们细心一点,这些低级错误都是可以避免的。

   

   万一密码丢失,别怕,因为路由器提供了密码恢复方法。

路由器除了两个基本访问模式(用户模式和管理模式)外,还有一种RXBOOT模式,在这个模式下可以很方便的恢复路由器密码。

当然只有计算机通过CONSOLE口建立超级终端连接后才能进入。

还有些路由器在面板上提供了更方便的RESET键,只要复位几次,即可恢复原始密码。

   

   5)配置文件丢失

   

   这也是一个经常发生的故障。

我们首先来看一下路由器的启动过程:

   

   

(1)系统硬件加电自检。

运行ROM中的硬件检测程序,检测各组件能否正常工作。

完成硬件检测后,便进入下一步。

   

   

(2)运行ROM中的BootStrap引导程序。

   

   (3)寻找并载入IOS系统文件

   

   (4)IOS装载完毕,系统首先在NVRAM中搜索保存的Startup-Config文件,进行系统的配置。

如果NVRAM中存在Startup-Config文件,则将该文件调入RAM中并逐条执行。

随后依据配置文件中的命令进行接口地址设置、路由处理等工作。

如果不能成功引导Startup-Config文件,系统则进入Setup模式,以人机对话方式进行路由器的初始配置。

   

   也就是说如果启动配置文件丢失,系统不能对路由器进行具体配置,无法完成所需的功能。

若要恢复配置文件,必须先连接到路由器上,通过TFTP方式将计算机上的备份配置复制到NVRAM上。

所以我们每次修改过路由器的配置后,都要做好备份工作。

   

   6)配置错误

   

   任何一个管理员在初学路由器时,都会出现各种意想不到的配置错误,比如:

路由协议配置错误、IP地址和掩码错误、ACL(访问控制列表)错误、修改配置后没有保存等等、。

比如:

访问控制列表错误就是一个典型的配置错误。

ACL是一张应用于路由器某个接口的一组命令列表,这个列表告诉路由器哪种数据包应该接收,哪种必须禁止,从而达到数据过滤的效果,这是一个有效控制网络安全的手段。

这个列表的书写涉及到源地址、目标地址、端口号这几个参数。

ACL是顺序执行的,而且在所有ACL的最后会有一个默认的、不可见的“denyany”语句,即禁止任何通信。

所以在定义某个ACL时,至少有一个PERMIT语句,否则这个访问列表是没有意义的。

初学者往往会忽略这一点而导致网络不通,还有可能会写错ACL中使用的端口号,ACL语句的顺序不恰当,或者通配符(WILDCARD,可能会和掩码混淆)不正确,接口应用错误(OUT和IN混淆)等等。

   

   这些配置上的错误是不可避免的,关键是我们能否在这些一次又一次的错误中学会正确的配置。

所以说一个好的管理员一定是喜欢学习、喜欢研究的。

   

   7)外部因素

   

   这是指除路由器之外的因素导致疑似路由器故障。

比如:

客户端计算机的网卡故障、线缆接头不正确、线缆串扰等原因可能会发生数据碰撞、网络流量增大、路由器负载增加,网络变慢甚至瘫痪。

如果拨号路由器的WAN口线路发生故障,就会导致不能拨号。

   

   以上的几种分类也许还有不太全面的地方,在实际的应用过程中,还会碰到各种意想不到的问题。

笔者从平时的工作中得出了一些经验,望与大家分享。

   

   路由器相比于交换机和集线器而言,它有强大的系统检测和日志记录功能。

大部分的故障都有详尽的描述,通过日志很方便的查找到故障原因。

   

   首先,排查路由器之外的故障,并检查路由器的外部表象,可有效的辨别硬件故障所在。

比如:

是否有客户端计算机的故障,是否有外部线路上的故障,是否下联的交换机有故障,是否有接头上的故障,电源模块、端口模块等插槽的LED指示灯是否有故障指示,风扇是否旋转,端口的连接是否正确等等。

虽然这些外部指示灯有时不能提供具体的故障原因,但它能够为我们快速的发现故障提供直接线索。

比如:

有一个路由器的风扇不能工作了,首先检查电源线是否和提供电源的电源模块是否正确连接,并检查电源指示灯。

如果是绿色,说明风扇有电源连接,则风扇模块可能没有正确安装或已经损坏;如果是红色,说明至少有一个风扇发生故障,可先检查风扇是否被卡住。

如果排除了风扇被卡住的情况,问题还存在的话,请更换风扇;如果指示灯不亮,则是电源被关闭。

   

   其次,检查系统和启动日志。

使用路由器提供的专用线缆,将计算机的串口连接到路由器的CONSOLE端口上。

如果启动路由器,便可在超级终端上清楚的看到路由器的启动过程,在硬件自检过程中,如果发现错误会在终端上显示错误提示信息,并记录在启动日志中。

如果路由器能够找到IOS文件,并成功的引导,则说明IOS没有问题。

如果在FLASH中没有找到IOS软件,则需要重新下载IOS到FLASH中。

从路由器的启动过程可以看出,IOS引导完毕后,便将Startup-Config文件调入内存。

如果不能成功从NVRAM中找到启动配置文件,也需要重新下载。

对于IOS和启动配置文件丢失的情况,我们可以在紧急情况下,进入启动模式(这是一个常用于故障处理的模式),使用TFTP协议从计算机(此机的网卡必须使用交叉线连接到路由器的以太网管理端口上)上启动和调入配置文件,临时救急。

   

   再次,检查配置文件。

配置文件有两个存在方式:

启动配置文件和活动配置文件。

前者是指保存在NVRAM上的启动文件。

路由器启动后便调入此文件,进行路由器的具体配置,关机后不会丢失。

活动配置文件是指在路由器的内存中正在运行的配置文件,关机或重启后,即会丢失。

如果路由器刚刚启动,两者是一样的。

如果管理员对路由器的配置进行了修改,并在内存中激活,这时两者是不一样的。

为了方便管理员检查,有的系统还提供了专门的命令。

比如,在EnterasysXP-Edition中,可以使用“diffstartup”命令,快速查找出活动配置文件和启动配置文件的区别。

很多初学者,常常忘记把修改后的活动配置文件保存入启动配置文件,当路由器下次启动后没有启用修改后的配置仍然使用原来的配置文件,以至于怀疑路由器出现某种故障。

   

   然后,检查配置内容。

这是路由器故障检查的重中之重,因为路由器的各种功能的实现都是由配置文件中一条一条的命令来实现的。

比如:

接口地址的配置、路由协议的配置、ACL的配置、SNMP的配置、日志的配置、QOS的配置、RMON的配置、NAT地址转换、端口的开关等等。

如果在配置中出现语法错误的语句,路由器会在初始化时显示错误提示,在CLI(CommandLineInterface命令行接口)中配置时,也有错误提示,并都会记录在系统日志中。

配置过程中,因为有的语句必须放在某些语句的后面,所以要注意某些语句的顺序,同时还要注意注释语句的使用。

   

   最后,检查硬件。

在以上的步骤中确定了某一方面的故障后,如果发现是硬件故障,则需要拆机更换硬件部件。

不过这一过程一般不需要你亲自动手,往往是供应商或厂商的工程师来实施的。

   还有,我们遇到自己无能为力的故障时,除了凭借自己的经验、产品说明书、厂商网站以外,要迅速的想到你的产品供应商,并与之联系,以帮助问题的快速解决。

如果时间拖得越长,就会超出产品包修、包换的期限。

   

   路由器一般故障到特殊故障的解决【2】

   

   故障一:

病毒引起路由器过载   此次故障发生地的拓扑结构是这样的:

使用一台EnterasysSSR8000作为边界路由器,同时也用它把校园内部划分为8个虚网,每个虚网各有一个堆叠的二层交换机作为台式机和笔记本的接入设备,主干为千兆,百兆到桌面。

   

   那天,我接到一个同事的求助电话,说他的机器不能上网了。

这个同事的主机所在的虚网和网络中心不在同一个虚网中。

听同事介绍说5分钟前还好的(能够上网),现在不知道为什么就不好上网了。

而且他的机器(安装的系统为WindowsXP)最近没有安装什么新的程序,没有移动过电脑,也没有拔过网线。

   

   首先,排查网络客户端的错误配置。

进入MSDOS方式使用IPCONFIG命令检查主机的IP地址配置:

   

   C:

>ipconfig

   

   WindowsIPConfiguration

   

   Ethernetadapter本地连接:

   

   Connection-specificDNSSuffix .:

   

   IPAddress............:

 210.16.2.30

   

   SubnetMask...........:

255.255.255.0

   

   DefaultGateway.........210.16.2.1

   

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

   

   C:

>ping210.16.2.30

   

   Replyfrom210.16.2.30:

bytes=32time<1msTTL=128

   

   Replyfrom210.16.2.30:

bytes=32time<1msTTL=128

   

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

   

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

   

   C:

>ping210.16.2.1–t

   

   Replyfrom210.16.2.1:

bytes=32time<1msTTL=128

   

   Replyfrom210.16.2.1:

bytes=32time<1msTTL=128

   

   ……

   

   从主机向网关发送的数据包,全部都得到了回应,线路是连通的。

打开浏览器,也能够正常上网,一点儿都没问题。

现在的网络是正常的!

?

正在怀疑的时候,发现网络又不通了!

发现ping出的数据包未能到达网关。

奇怪,刚才还好的,怎么现在又不通了呢?

难道是网卡或者系统有问题?

谁知过了一会儿,发现又通了。

幸亏那天带了笔记本,于是我把台式机上的网线插到我的电脑上,配置好IP地址后ping网关,也出现时断时续的情况。

断开的现象大概持续了50秒钟,然后又恢复正常。

这回可以基本排除主机的问题了,因为两台不相干主机同时出现同样此类问题的几率几乎为零。

鉴于此现象,我首先排除了连接线缆的故障,因为连接的线缆不可能出现这种时断时续的情况,故障最有可能会出在线缆的另一端--二层交换机上。

于是来到这栋楼的设备间,查看交换机的状态,这是一个由两台交换机的堆叠,其中一台交换机上有一个上联的千兆端口。

我把笔记本接到交换机的其中一个端口上,再ping网关。

还是同样的故障,而且还发现每过4分钟到10分钟,网络就会断一次,并且40到50秒后又恢复正常。

经过观察发现:

没有发现端口指示灯的异常情况,说明交换机的各个端口均正常。

难道真是交换机的内部系统出现故障了?

算了,索性把交换机重启一下。

谁知重启后,故障依旧。

可能交换机真的出了问题,我正想是否要把堆叠模块换到另外一个交换机上的时候,我的手机响了,又一个同事告诉我他的机器也出现相同的故障现象。

而这个同事的主机在另外一个虚网中,同时出现相同的时通时断情况,那极有可能是连接这两个虚网的路由器出了问题。

   

   这回问题集中到路由器上了。

我急忙回到网络中心,从路由器的外部指示灯上看,没什么异常现象。

在我的网管机上ping路由器的地址(我的网管机是直接连在路由器的百兆模块上的),也是时通时断。

我又继续观察了一段时间,发现每过4分钟到10分钟,路由器所有模块的指示灯都会同时熄灭,接着控制模块上的“HBT”灯闪烁,然后“OK”灯亮起,最后所有模块的指示灯均显示Online.我解释一下,“HBT”灯闪烁表示路由器正在启动,也就是说正在自动重启,而且40秒左右的网络断开时间正好是路由器的重启所需的时间。

现在问题的查找工作已经结束,肯定是路由器出了故障。

具体是什么问题,还需要进一步的检测。

   

   趁着路由器正常工作的时候,把笔记本的COM口使用路由器的专用CONSOLE线连接起来,建立超级终端。

在管理模式下使用命令“systemshowbootlog”查看系统的启动记录,发现各个模块的加载均属正常。

造成路由器重启的原因,最大的可能就是CPU的利用率达到100%.使用“systemshowcpu-utilization”命令查看CPU的使用率:

   

   SSR#systemshowcpu-utilization

   

   CPUUtilization(5seconds):

 50%

   

   (60seconds):

60%(前者是指5秒钟内CPU平均使用率为50%,

   

   后者是60秒钟内CPU平均使用率为60%)

   

   果然,连续使用此命令后得知CPU利用率正在逐渐上升,当达到95%的时候路由器便自动重启。

看来路由器的负载太大了,因为平时正常情况下,CPU的使用率仅为1%-6%左右。

当网络使用高峰期的时候CPU的利用率会稍微高一点。

但到底是什么让路由器过载呢?

幸好以前曾经给路由器设置过日志记录,并把日志发送到一个日志服务器上。

但是打开这台服务器所记录的日志并未能找到有用的线索。

因为当路由器负载过大时,它已经不能往日志服务器上发送日志了,我只能用“systemshowsyslogbuffer”命令来查看当前系统缓存中的日志记录:

   

   SSR#systemshowsyslogbuffer

   

   2003-09-1009:

28:

32%ACL_LOG-I-DENY,ACL[out]

   

   on“uplink”ICMP210.16.3.82->210.55.37.72

   

   2003-09-1009:

28:

32%ACL_LOG-I-PERMIT,ACL[out]

   

   on“uplink”ICMP210.16.3.82->61.136.65.13

   

   2003-09-1009:

28:

32%ACL_LOG-I-DENY,ACL[out]

   

   on“uplink”ICMP210.16.3.82->202.227.100.65

   

   2003-09-1009:

28:

32%ACL_LOG-I-DENY,ACL[out]

   

   on“uplink”ICMP210.16.3.82->193.210.224.202

   

   2003-09-1009:

28:

32%ACL_LOG-I-DENY,ACL[out]

   

   on“uplink”ICMP210.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(微软的DCOMRPC端口)和ICMP协议(用于发现活动主机)。

具体的ACL配置如下:

   

   !

---blockICMP

   

   acldeny-virusdenyicmpanyany

   

   !

---blockTFTP

   

   acldeny-virusdenyudpanyanyany69

   

   !

---blockW32.Blasterrelatedprotocols

   

   acldeny-virusdenytcpanyanyany135

   

   acldeny-viruspermittcpanyanyanyany

   

   acldeny-viruspermitudpanyanyanyany

   

   最后再把deny-virus这个ACL应用到上联接口(uplink)上:

   

   acldeny-virusapplyinterfaceuplinkinputoutput

   

   这样就可以把“冲击波杀手”从网络的出口处堵截住。

为了防止已经感染“冲击波杀手”的主机在校内各个虚网之间传播,还得把这个ACL应用到校内各虚网的接口上。

这时使用再“systemshowcpu-utilization”查看CPU的使用率,它又恢复到正常状态,等待了一段时间后,再没有出现重启现象。

   

   由于路由器不能自动丢弃这种病毒发出的攻击数据包,而导致了路由器重启。

为了彻底解决问题,还得升级路由器的IOS(可以使用“systemshowversion”来查看当前使用的IOS的版本)。

记得两年前在“红色代码”病毒盛行的时候,也出现过路由器因过载而不断重启的现象,升级IOS以后就恢复正常了。

于是立刻和设备供应商取得联系并获得最新的IOS映像文件。

至此,路由器故障全部解决。

   

   从这场故障处理中,我们可以得到这样的教训:

时刻关注网络上事态的发展,并作出相应的解决方案,而且付诸实施。

教育网用户可以在网站上订阅安全公告服务,一旦有新的漏洞出现,CCERT安全响应小组会自动发送邮件给你。

当时暑假期间得知“冲击波”后,由于及时在路由器上做了设置,所以“冲击波”病毒没有在网内泛滥,但随后的“冲击波杀手”没有及时设置相应的ACL,所以才导致这次的网络瘫痪。

实际上,在这次的“冲击波”和“冲击波杀手”的袭击中,很多城域网也因此陷入瘫痪。

这些经历一次又一次的警告我们:

时刻关注网络安全,及时积极的应对。

   

   路由器一般故障到特殊故障的解决【3】

   

   故障二:

ICMPRedirect    这是个什么问题呢?

首先给大家描述一下。

虽然路由器在运行时没有出现明显的异常现象,但是却经常看到这样的日志:

   

   Jul0915:

54:

21%ACL_LOG-I-PERMIT,ACL[out]

   

   on“uplink”ICMP209.2

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 高中教育 > 高中教育

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1