因为很多小型局域网使用代理服务器或者软件路由，很少使用专用的硬件路由器。但随着局域网的快速发展，路由器在局域网中的应用也逐渐增加，各种路由器故障也随之接踵而来。
从前面的介绍我们了解到路由器也和计算机一样由硬件和 软件组成，当然问题可以出现在硬件也可以在软件上。也许是因为很多管理员对路由器不熟悉或了解不深入的原因，有很大一部分故障都出现在软件上。笔者总结了以下几种故障分类，方便各位读者排障。
1)硬件故障
路由器的硬件包括RAM/DRAM、NVRAM、FLASH、ROM、CPU、各种端口以及主板和电源。硬件故障一般可以从LED指示灯上看出。比如：电源模块上有一个绿色的PWR(或POWER)状态指示灯。当这个指示灯亮着时，表示电源工作正常。接口模块上的ONLINE和OFFLINE 指示灯以及TX、RX指示灯。Rx指示灯为绿色表示端口正在接收数据包;如果为橙色，则表示正在接收流控制的数据包。Tx指示灯为绿色表示端口正在发送数据包;如果为橙色，则表示正在发送流控制的数据包。不同的路由器有不同的指示灯表示不同的意义，所以你最好先看说明书。
硬件故障有时也可以从启动日志中查出或者在配置过程中看出。由于路由器在启动时首先会进行硬件加电自检，运行ROM中的硬件检测程序，检测各组件能否正常工作。在完成硬件检测后，才开始软件的初始化工作。如果路由器在启动时能够检测到硬件存在故障，会在系统的启动日志中会记录下来，以便后查。如果在配置路由器时，当你进入某个端口配置时，系统一直报错，那就有可能是端口的问题了。
此外还要做好路由器运行环境的建设，比如：防雷接地以及稳定的供电电源、室内温度、室内湿度、防电磁干扰、防静电等，消除各种可能的故障隐患。
2)系统丢失
这里是指IOS(Internetwork OperatingSystem)，它就是路由器的一切配置运行的基础–操作系统。它保存在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(Command LineInterface命令行接口)中配置时，也有错误提示，并都会记录在系统日志中。配置过程中，因为有的语句必须放在某些语句的后面，所以要注意某些语句的顺序，同时还要注意注释语句的使用。
最后，检查硬件。在以上的步骤中确定了某一方面的故障后，如果发现是硬件故障，则需要拆机更换硬件部件。不过这一过程一般不需要你亲自动手，往往是供应商或厂商的工程师来实施的。
还有，我们遇到自己无能为力的故障时，除了凭借自己的经验、产品说明书、厂商网站以外，要迅速的想到你的产品供应商，并与之联系，以帮助问题的快速解决。如果时间拖得越长，就会超出产品包修、包换的期限。
路由器一般故障到特殊故障的解决【2】
故障一：病毒引起路由器过载 此次故障发生地的拓扑结构是这样的：使用一台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线连接起来，建立超级终端。在管理模式下使用命令 “systemshowbootlog”查看系统的启动记录，发现各个模块的加载均属正常。造成路由器重启的原因，最大的可能就是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 showcpu-utilization”查看CPU的使用率，它又恢复到正常状态，等待了一段时间后，再没有出现重启现象。
由于路由器不能自动丢弃这种病毒发出的攻击数据包，而导致了路由器重启。为了彻底解决问题，还得升级路由器的IOS(可以使用“system showversion”来查看当前使用的IOS的版本)。记得两年前在“红色代码”病毒盛行的时候，也出现过路由器因过载而不断重启的现象，升级IOS 以后就恢复正常了。于是立刻和设备供应商取得联系并获得最新的IOS映像文件。至此，路由器故障全部解决。
从这场故障处理中，我们可以得到这样的教训：时刻关注网络上事态的发展，并作出相应的解决方案，而且付诸实施。教育网用户可以在 http://www.ccert.edu.cn网站上订阅安全公告服务，一旦有新的漏洞出现，CCERT安全响应小组会自动发送邮件给你。当时暑假期间得知“冲击波”后，由于及时在路由器上做了设置，所以“冲击波”病毒没有在网内泛滥，但随后的“冲击波杀手”没有及时设置相应的ACL,所以才导致这次的网络瘫痪。实际上，在这次的“冲击波”和“冲击波杀手”的袭击中，很多城域网也因此陷入瘫痪。这些经历一次又一次的警告我们：时刻关注网络安全，及时积极的应对。
路由器一般故障到特殊故障的解决【3】
故障二：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 MessageProtocol(网间报文控制协议)，它是IP不可分割的一部分，用来提供错误报告。一旦发现各种错误类型就将其返回原主机，基于 ICMP的攻击方法也多种多样。到底是什么原因导致生成这样的日志?让我带大家一起来查一查。
我校的拓扑结构是一个简单的星型结构，中心节点就是一台三层交换式路由器(Enterasys公司的SSR8000)。其中一个端口上联到 CERNET,其他端口都是内部连接，且为内部网络基于端口划分了多个VLAN.为了查看该信息是否从网络内部发出，又给内部VLAN的各个接口设置了日志，还是没有相关的ICMP记录(原先的日志只是记录上联接口的数据)。排除了内部计算机发出ICMP数据包的可能，那问题就可能出现在上联接口上，而日志记录只能记录到协议层的信息，不能记录更深层次的数据包。如何查看上联接口的数据包呢，比较方便的方法就是使用端口镜像功能，利用连接在镜像端口上的计算机来抓取和分析数据包。
首先下载数据包分析软件WINDUMP。在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 DeviceNPF_{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 DeviceNPF_{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都是路由器发送给源地址的“DestinationUnreachable”信息。那么为什么这些外面的 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-messagesdestination-unreachables”来禁止此类信息的转发。
这两个故障均由ICMP引发，而且从某种角度上讲都不是系统配置上的问题，而是由于外部因素引起的。此类故障需要我们经过一定的分析才能查出原因，再作相应的配置才能排除故障。
