以下是小编为大家收集的路由器中ICMP故障的解析和处理（共含6篇），欢迎参阅，希望可以帮助到有需要的朋友。同时，但愿您也能像本文投稿人“会看眼瞎的”一样，积极向本站投稿分享好文章。
在一些设置中，我们常会遇到ICMP故障，那么对于路由器中的这类故障我们如何解决呢？下面我们就例举了一些情况，来帮助大家进行一下分析，以及给出了一些解决方法，
这是个什么问题呢？首先给大家描述一下。虽然路由器在运行时没有出现明显的异常现象，但是却经常看到这样的日志：其中“209.24.79.200”是路由器的上联接口地址，我不知道为什么会出现这么多从路由器发到这些没有规律的IP的ICMP故障。
ICMP故障
一切准备就绪后，接着就是开始端口镜像。使用计算机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所在的目录，输入命令：
（上面的记录已做过筛选。第一句的参数“-N”表示IP地址或者端口号转换为主机名或端口名，第二句表示windump开始在所选网卡上监听，第三句开始就是WINDUMP记录的信息。）同样在计算机B上也运行WINDUMP：查看路由器上的日志，我任意找到其中一条关于ICMP的记录：
查，在计算机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地址会找校内的计算机呢？从采集的数据分析不难发现，这些外部主机主要是找内部的固定的三个计算机。经过历史日志的检查，可以发现这三台计算机的主要相同的记录：
这三台主机连接目标主机的端口固定在6881到6889之间，而这些端口正是现在比较流行的BT下载的常用端口。难怪以前没有出现过此类日志，直到最近BT流行时，才出现的。主要原因是，这些主机使用BT下载时，在BT服务器上留下了记录，以便其他的主机到这些主机上下载资源，而当这些主机关机后，路由器就告诉它们找不到这些主机了。
由于日志服务所记录的是第三层以上的信息，而路由器接收到的数据包在第二层上就被丢弃了，所以没有在日志中记录这些输入的异常数据包。为了减少路由器的日志量，在配置模式下使用“ip disable icmp-messages destination-unreachables”来禁止此类信息的转发。
这个ICMP故障均由ICMP引发，而且从某种角度上讲都不是系统配置上的问题，而是由于外部因素引起的。此类ICMP故障需要我们经过一定的分析才能查出原因，再作相应的配置才能排除ICMP故障。
编辑推荐TCP/IP协议专题
TCP/IP（传输入控制地议/网际协议）是一种网络通信协议，它规范了网络上的所有通信设备，尤其是一个主机与..
NFS Server故障分析和解决路由器常见故障解决方法集锦检测排除TP-LINK路由器故障四类ADSL故障的剖析和处理ICMP协议工作流程详解
广域网是一种跨地区的数据通讯网络，使用电信运营商提供的设备作为信息传输平台，对照OSI参考模型，广域网技术主要位于底层的3个层次，分别是物理层，数据链路层和网络层。下图列出了一些经常使用的广域网技术同OSI参考模型之间的对应关系。 下面有关广域网故障处理的分析，让我们以问答的形式向大家说明：
问：不同速率的POS接口是否能够加入同一个IP-Trunk？
答：可以将不同速率的POS接口加入到同一个IP-Trunk，但是建议不要将转发能力不同的接口捆绑到同一个IP-Trunk中。此时每个接口的转发能力，只能达到能力最低的接口的水平。例如，将一个10G的POS接口和一个2.5G的POS接口加入到同一个IP-Trunk中，那么此时10G的POS接口只能达到2.5G的传输能力，而整个IP-Trunk的传输能力为5G，而不是12.5G。
问：采用HDLC协议互连时，发送介于两端MTU之间大小的ping报文，为什么能够ping通？
答：HDLC协议不会协商两端接口的MTU值，按照这个原理，发送大于较小MTU值的报文应该不能通过。但是，缺省情况下，华为路由器上发送的ping报文是允许分片的。路由器会根据接口的MTU值进行分片，因此，即使ping报文的长度大于某一端的MTU值，仍然可能ping通。在一般情况下，为了保证所有的转发业务正常，互连的端口MTU值要配置成一致。
问：传输设备的倒换会对POS接口产生什么影响？
答：当POS接口通过传输设备与对端互连时，如果传输设备进行主备倒换，可能会引起POS接口瞬间闪断，并且收到SDH告警。如果在主用链路中断的瞬间，主用链路信号失效，POS接口检测到短暂的通道信号失效，会将接口的物理状态置为Down，同时上报相应的SDH告警。传输设备根据检测到的信号失效发起倒换，倒换完成后，业务将转到备用链路，信号恢复正常，
POS接口也会检测到正常的信号，同时将接口的物理状态恢复为Up。
问：短序列方式的MP-Group能否和长序列方式的MP-Group互通？（NE80/40）
答：可以。对于路由器，当一端配置为短序列方式，一端没有配置时，两端会进行协商，协商结果为长序列方式。报文头中的序列字（sequence number）用于表示分片报文的顺序，MP报文的报文头有长序列字和短序列字两种格式：
长序列字在报文头中占24位。
短序列字在报文头中占12位。
在实际使用中，建议将两端配置为相同的序列方式。
问：光模块的接收光功率和接收灵敏度、过载光功率有什么关系？
答：接收光功率是指光模块接收到的光的功率。接收灵敏度是光模块能够正常接收的光的功率下限。过载光功率是光模块能够正常接收的光的功率上限。只有当光模块的接收光功率不低于接收灵敏度，而且不高于过载光功率时，光模块才能够正常工作。当光模块的接收光功率低于接收灵敏度时，接口的物理状态可能会反复震荡。
问：两端的CRC校验位必须要一致吗？
答：是的。如果两端的CRC校验位不同，接口的链路层状态可能为Down。特别是与其他厂商设备对接时，两端的缺省配置可能不同，需要配置为两端一致。
问：在VT接口上配置了MPLS相关参数后，需要重启接口吗？（NE20/20E）
答：必须要重启与VT接口有绑定关系的所有串口，才能够使新的MPLS参数生效。如果只在VT接口进行MPLS相关参数配置，与VT有绑定关系的串口并没进入MPLSCP opened状态，所以MPLS业务不通。对绑定到VT的所有串口进行shutdown/undo shutdown操作，使virtual-access重新生成，VT才能进行MPLSCP协商进入opened状态，这样MPLS业务才能正常工作。
无线路由器故障分析是我们解决网络故障的重要途径，了解无线路由器故障发生机理，可以有效地预防问题的发生，而且在一定程度上还可以改善我们的网络环境，提高无线网络质量，那么，下面就举出一个校园网络中的无线路由器故障分析。
阿D遇到的小问题
阿D是一个大三在校生，由于所学专业的原因，每天需要浏览国外设计网站，因此6个人的寝室就办理了宽带，6个人共享上网就需要一台无线路由器（由于现在的孩子都有钱，5个是笔记本另外一个是台式机）。用了一段时间感觉还可以，网速虽然不快，但还是可以接受的。可是好景不长，随着临近期末考试的到来，阿D越发感到无线上网速度非常之慢而且有时还掉线，但检查硬件之后也没有发现故障所在，阿D和寝室的兄弟很是郁闷，便找了一位“高手”解决问题（这里说明一下：阿D使用的是Dink的DIR－615无线路由器，五个笔记本的无线网卡11N和11b都有，台式机则是使用了一款老的11M的无线网卡），看了之后终于发现了问题所在，就是对无线路由器的设置上有差错，所以产生了问题。
阿D遇到的问题相信大家也遇到过，虽然不是什么严重的问题，但要是出现也很郁闷。刚才出现的这种情况也许不少消费者不是很清楚，不知道出在什么地方，下面笔者就给大家详细解答一下。
两种无线路由器故障分析与解决办法
前面提到的故障是有两种可能性的，一个是：混合无线网络经常掉线，另外一个是：IEEE 802。11g传输速率较低。下面一起来看一下故障分析与解决办法。
混合无线网络经常掉线
无线路由器故障现象
使用笔记本自带的网卡和Dink的DIR－615无线路由器构建无线局域网，它们使用的都是IEEE 802。11g协议，网络中还存在少数802。11N网卡。当使用DIR－615进行连接时经常掉线。
无线路由器故障分析
从理论上说，IEEE 802。11n协议是向下兼容802。11g协议的，使用这两种协议的设备可以同时连接至使用IEEE 802。11n协议的无线路由器。
但是，从实际经验来看，只要网络中存在使用IEEE 802。11g协议的网卡，那么整个网络的连接速度就会降至54Mb／s（IEEE 802，
11g协议的传输速度）。
故障解决
在混用IEEE 802。11g和IEEE 802。11n无线设备时，一定要把无线路由器设置成混合（MIXED）模式，使用这种模式，就可以同时兼容IEEE 802。11n和802。11g两种模式。
IEEE 802。11g传输速率较低
无线路由器故障现象
为了保证无线网络标准的兼容性，我们在选择无线产品时，一般都会选取支持IEEE 802。11b／g的无线AP和无线网卡。然而，在实际的网络测试中，我们发现，在没有干扰和传输距离有限的情况下，无线链路的传输速率仍然较低，不能达到标称的54Mb／s。
无线路由器故障分析
IEEE 802。11g不但具有54Mb／s的传输速度，而且，还能很好的兼容IEEE 802。11b无线设备，从而能够将802。11b无线网络平滑升级到802。11g无线网络。
故障解决
为了兼容现有的802。11b无线局域网设备，802。11g除了和802。11b使用相同的2。4GHz频带外，还采用了两种不同的OFDM（正交频分复用）编码技术，以和相对应的802。11b或者802。11g设备通信。也就是说，在混合使用802。11b和802。11g无线设备的网络中，使用802。11g的无线设备既可以以54Mb／s的速率和802。11b设备通信，也可以以11Mb／s的速率和802。11b设备进行通信。
总结：
生活中像阿D这样的情况还是时常发生的，作为普通消费者的我们遇到了肯定会比较郁闷，虽说目前的许多无线路由器在功能上和WEB界面上，设置的都很人性化，都在尽量不给用户带来使用上的不便，但毕竟不能避免一些小故障的发生，所以掌握一些简单的解决问题的办法还是比较实用的。由于环境的不同，也许你的使用环境不会像阿D那样需要连接6个终端，一般的家庭都会保持在2至3台终端左右，但从发生故障的原理上看都是相通的。混合无线网络经常掉线和IEEE 802。11g传输速率较低，这两个只是众多故障中的一小部分，一些具体的情况还有根据实际的情况分析，我们自己可以先做好一部分功课，剩下的要在实践中学习了。
只要是使用路由器上网的网友们，都遇到整个网络断网的情况，表现为所有电脑都无法上网，这时我们应该怎么办呢?
通常这种情连较为复杂，本文就以H3C路由为例提供一个解决的思路，相信你看完后心中有数，处理这种情况就相对简单些了，
一、掉线时，查看电脑能否登陆路由器管理界面，如果不能登录，那么基本就是路由器的原因，尝试重新启用路由器，如果还是不行，那么参考本站华为路由器设置，其中有解决的办法，首先要解决这个问题。
二、检查是否WAN口掉线，如果WAN口是PPPOE拨号上网方式，看第三步，如果是静态IP或动态IP接入方式，看第四步，
三、检查路由器运行状态，WAN口状态是否显示已连接，有连接时有IP地址等参数，如果未连接，则代表拨号掉线，选择系统日志，将路由器日志信息保存下来，如果已连接，选择系统工具，诊断工具，ping外网，看是否通。
四、检查WAN口端口状态是否显示已连接，如果显示未连接，则检查WAN口网线连通性;如果显示已连接。
五、WAN口诊断不通，则可能是线路问题，可将前端线路的MODEM重启或重新接入。若仍不能恢复，则需要联系ISP解决。
六、WAN口诊断为通，则掉线属于内网问题，注意检查内网是否存在病毒攻击等，可尝试将电脑直接连接到路由器尝试是否可以上网以及检查路由器的配置是否正确。
经过上面的介绍，大家对网络突然断网的原因应该有所了解了吧，当出现这种情况时，只要按上面的步骤检查，相信你必定可以解决掉线的原因，使网络重新正常运行。
路由器故障处理是我们网络管理员的日常工作，那么如何做好这项工作呢？，那么下面就向你介绍了一个具体的路由器故障处理实例，希望那个对你有所帮助，
路由器故障处理的起因：
笔者附近的一家中型企业的网络出了故障。管理员反应的主要症状为：公司网络网速缓慢，且出现延迟现象，登录服务器很久都没有响应，时常提示超时。笔者初步判断是网络中有异常数据流，因为网络中的交换机和路由器灯长明、狂闪。
网络环境：
该公司内网在三层交换处划分了VLAN，最后通过路由器与Internet 连接，网内大概有200台电脑。
路由器故障处理之原因分析：
笔者作为一名协助人员对这家企业的网络故障进行了分析。可能是该公司网络管理力度不够，网络部署不够严密，网络中可能存在ARP欺骗。ARP 风暴吞噬了网络带宽，影响了网络响应的速度。
由于该公司主机数量比较大，逐个手动查找肯定很麻烦，于是我们决定通过网络分析软件来查找故障主机。经过一些镜像设置，笔者将科来网络分析软件安装到笔记本上，并接入到该公司的中心交换设备的镜像端口处抓包。30分钟以后，停止捕获并开始分析。关键数据很多，通过查看捕获的数据包，笔者第一感觉是该公司的网络可能感染了蠕虫病毒，该病毒在网络中感染其他主机，产生了数据风暴，使网络性能下降。
我首先查看“诊断视图”，发现在“诊断视图”中显示的“TCP重复的连接尝试”居然达到了31126次。这是很不正常的情况。为了找到更多的证据来证明，笔者在“端点视图”按网络连接排序，发现IP为10.8.24.11的主机网络连接次数名列榜首。
此时笔者决定定位分析这台主机，查看“会话视图”中的TCP 连接情况，发现全是该主题向目的主机的445端口发起的连接。这恰好证明了笔者的猜测：该主机可能感染了蠕虫病毒，且该病毒正在试图感染其他主机。然后，笔者在“概要统计”里查看IP为10.8.24.11的主机的TCP数据包情况，发现在30分12秒的时间里，该主机共发出了29622个TCP 同步数据包，而结束数据包和复位数据包分别是3253和1387个。结合以上对该主机连接的分析，笔者基本上确定了该主机感染了蠕虫病毒。
3lian素材
路由器故障处理方案：
IP为10.8.24.11的主机感染蠕虫病毒后，病毒自动通过网络与其他主机的TCP445端口建立连接，试图感染其他主机，严重耗费了网络资源，造成网络整体性能的下降，严重时可使网络大面积感染病毒，导致网络上的主机全部瘫痪，
笔者将IP为10.8.24.11的主机与网络隔离，并对其进行病毒查杀，查杀后重新接入网络。
路由器故障处理过后的问题：
本来以为问题已经解决，谁知不到一天，该公司的网管员又告诉笔者，公司的网络流速不稳定，虽然没有上次那样大面积长时间的停滞，但是还会很有规律地在上班时间发生网络拥堵，网速缓慢。
再次分析：
笔者首先用网络分析软件在网络的中心节点上进行抓包，时间为20分钟。通过分析，笔者发现有大流量的数据从外网通过路由器转发到一个MAC地址为00-0A-E6-98-84-B7的主机上。这个数据流占了从外网流入数据的80%以上。笔者通过查看管理员整理的MAC列表找到了这台主机。这是一台文件服务器，主要用来实现企业内部文件的共享。为什么会有外网的数据转发到这个服务器呢？笔者马上对这台服务器进行检查。检查结果让该企业的管理员非常惊讶——这台文件服务器竟然被配置成了代理主机！
难道这台文件服务器被人入侵了？事情没有那么简单，入侵者为什么要把它配置成代理服务器呢？难道入侵的不仅仅是这台服务器，连路由器也被入侵了吗？笔者通过管理员登录路由器，果然发现有人在路由器上做了设置，有许多端口转发到了这台文件服务器上。
现在原因很清楚了：有人入侵了文件服务器，并把它配置成代理服务器；然后利用管理员密码控制了路由器，在路由器上设置了端口转发，把外网的数据转发到文件服务器上，最后在自己的主机上设置代理上网，通过P2P软件下载大型文件或者看电影、玩游戏，造成网络拥堵。
那么，入侵者为什么要这样做呢？原来该企业规定员工不能联入Internet，网管在路由器上做了限制。肯定是有员工通过这个方式在上班时间联入Internet。那他又是如何控制路由器的呢？笔者了解到，路由器采用的是默认的用户名，密码是英文和数字的组合，是姓名和电话号码的组合。显然，入侵者通过社会工程学获取了路由器的密码，然后控制了路由器。
路由器故障处理的最终方案：
接下来的是就是找到入侵者，笔者采用的方法还是运用网络分析软件。笔者首先取消这台文件服务器的文件共享功能，简化数据捕获，设置好网络监控软件后蹲点。没过多久，软件就获得了大量的数据。通过对数据的分析，笔者很快就确定了几个可疑的MAC地址，并根据MAC地址列表找到了相关的主机。接着，笔者恢复文件服务器的共享功能，取消代理，并给路由器重新设置复杂的密码。
事后，笔者了解到，确实是该公司一名员工突破了文件服务器和路由器后进行了设置，然后还告知了几个朋友通过代理上网。
路由器故障处理总结：
这两起与路由器有关的案例，实际上其问题都是人为因素造成的。因此，做为网管员，一定要保护好网络的关键组件，设置强密码。另外，我们在解决网络故障的时候，如果能够灵活运用网络分析软件，就能起到事半功倍的效果。
路由器故障处理实例的相关内容就向你介绍到这里，希望对你了解和学习掌握路由器故障处理的思路有所帮助。
日常的工作和学习中，我们使用的一些系统以及相应的操作中，难免会遇到一些故障问题，那么对于NFS故障的分析和解决我们在下文中为大家做了具体的分析和处理，希望本文的总结对您处理问题能够有所帮助。
NFS故障1、NFSD没有启动起来
首先要确认 NFS 输出列表存在,否则 nfsd 不会启动.可用 exportfs 命令来检查,如果 exportfs 命令没有结果返回或返回不正确,则需要检查 /etc/exports 文件.
NFS故障2、mountd 进程没有启动
mountd 进程是一个远程过程调用 (RPC) ,其作用是对客户端要求安装（mount）文件系统的申请作出响应.mountd进程通过查找 /etc/xtab文件来获知哪些文件系统可以被远程客户端使用.另外,通过mountd进程,用户可以知道目前有哪些文件系统已被远程文件系统装配,并得知远程客户端的列表.查看mountd是否正常启动起来可以使用命令rpcinfo进行查看,在正常情况下在输出的列表中应该象这样的行:
1000051udp1039mountd 1000051tcp1113mountd 1000052udp1039mountd 1000052tcp1113mountd 1000053udp1039mountd 1000053tcp1113mountd
如果没有起来的话可以检查是否安装了PORTMAP组件.
rpm -qa|grep portmap
NFS故障3、fs type nfs no supported by kernel
kernel不支持nfs文件系统,重新编译一下 KERNEL就可以解决.
NFS故障4、can't contact portmapper: RPC: Remote system error - Connection refused
出现这个错误信息是由于SEVER端的PORTMAP没有启动.
NFS故障5、mount clntudp_create: RPC: Program not registered
NFS没有启动起来,可以用 showmout -e host命令来检查NFS SERVER是否正常启动起来.
NFS故障6、mount: localhost:/home /test failed, reason given by server: Permission denied
这个提示是当 client要mount nfs server时可能出现的提示,意思是说本机没有权限去mount nfs server上的目录.解决方法当然是去修改NFS SERVER咯.
NFS故障7、被防火墙阻挡
这个原因很多人都忽视了,在有严格要求的网络环境中,我们一般会关闭linux上的所有端口,当需要使用哪个端口的时候才会去打开.而NFS默认是使用111端口,所以我们先要检测是否打开了这个端口,另外也要检查 TCP_Wrappers的设定.
