网络设备故障排除命令之ping、traceroute、show、clear、debug

由 · 发布日期 · 已更新  

0    78    1

Tags：

👉 本文共约8718个字，系统预计阅读时间或需33分钟。

本页目录 隐藏
网络排错常用诊断工具介绍
Ping命令
1.原理：
2.功能
3.RGNOS平台的ping命令
4.Windows平台的Ping命令
5.巧用Ping命令进行故障排除
案例一：连通性问题还是性能问题？
案例二：使用大包ping对端进行MTU不一致的故障排除
案例三：A能Ping通B，B就一定能Ping通A吗？
Traceroute 命令
1.原理
2.功能
3.RGNOS平台的Traceroute命令
4.Windows平台的Tracert 命令
5.使用Traceroute命令进行故障排除
案例一：使用Traceroute命令定位不当的网络配置点
案例二：使用Traceroute命令发现路由环路
Show命令
1. Show Version命令
2.Show running-config和Show startup-config命令
3.Show interface命令
Clear命令
Debug命令
1. Debug命令概述
2. Debug命令使用注意事项
案例一：忘记关闭debug开关引起的路由器报文转发速度变慢的故障排除
案例二：通过串口telnet到路由器，在该串口上打开debug命令产生问题
3.show命令和debug命令的配合使用
参考
相关文章

网络排错常用诊断工具介绍

主流网络设备产品提供了一套完整的命令集，可以用于监控网络互联环境的工作状况和解决基本的网络故障。主要包括以下命令：

  • Ping命令
  • Traceroute命令
  • Show命令
  • Clear命令
  • Debug命令

Ping命令

1.原理：

“ping”这个词源于声纳定位操作，指来自声纳设备的脉冲信号。Ping命令的思想与发出一个短促的雷达波，通过收集回波来判断目标很相似；即源站点向目的站点发出一个ICMP Echo Request报文，目的站点收到该报文后回一个ICMP Echo Reply报文，这样就验证了两个节点间IP层的可达性－－表示了网络层是连通的。

2.功能

Ping命令功能用于检查IP网络连接及主机是否可达。

3.RGNOS平台的ping命令

在RG系列设备上，Ping命令的格式如下：

例如，向主机10.15.50.1 Ping报文

4.Windows平台的Ping命令

在PC机上或Windwos为平台的服务器上，Ping命令的格式如下：

  • -n Ping报文的个数，缺省值为5；
  • -t 持续地ping 直到人为地中断，Ctr+Breack暂时中止ping命令并查看当前的统计结果，而Ctr+C则中断命令的执行。
  • -l 设置Ping报文所携带的数据部分的字节数，设置范围从0至65500。 例：向主机10.15.50.1 发出2个数据部分大小为 3000 Bytes的ping报文

5.巧用Ping命令进行故障排除

案例一：连通性问题还是性能问题？

(1) 案例描述

工程师小C，在配置完一台路由器之后执行Ping命令检测链路是否通畅。发现5个报文都没有Ping通，于是检查双方的配置命令并查看路由表，却一直没有找到错误所在。最后又重复执行了一遍相同的Ping命令，发现这一次5个报文中有1个Ping 通了－－原来是线路质量不好存在比较严重的丢包现象。

工程师小C又配置了一台路由器，然后执行Ping命令访问Internet上某站点的IP地址，但没有Ping通。有了上次的教训小L，再一次Ping了20个报文，仍旧没有响应。于是小L断定是网络故障。但是在费劲周折检查了配置链路之后仍没有发现任何可疑之处，最后小L采取逐段检测的方法对链路中的网关进行逐级测试，发现都可以Ping 通，但是响应的时间越来越长，最后一个网关的响应时间在1800ms左右。会不会是由于超时而导致显示为Ping 不同呢？受此启发，小L将Ping 命令报文的超时时间改为4000ms，这次成功Ping通了，显示所有的报文响应时间都在2200ms 左右。

(2) 建议和总结：

真的是Ping不通吗？这个问题需要定位清楚，因为连通性问题和性能问题排错的关注点是不一样的――问题定位错误必然会导致排错过程的周折。使用一般的Ping命令，缺省是发送5个报文的，超时时长是2000ms。如果Ping不通情况发生，最好能够再用带参数-c和-t的Ping命令再执行一遍，如：Ping -c 20 -t 4000 ip-address，即连续发送20个报文，每个报文的超时时长为4000ms，这样一般可以判断出到底是连通性问题还是性能问题。

案例二：使用大包ping对端进行MTU不一致的故障排除

(1) 现象描述：

某次开局，使用RG路由器与其他厂商的某路由器互连，并运行OSPF协议。数据配置完毕后，一切正常，并在今后相当长的时间内设备运转稳定。但两个月后，用户反馈网络中断。

(2) 相关信息显示：

  • 登录到两台路由器上，发现双方连接正常，可以相互Ping通对端地址。但OSPF协议中断；
  • 登录RG路由器查看邻居状态，发现邻居状态机处于Exstart状态。打开相应的debug开关查看相应的报文信息，发现双方都可以收到Hello报文，但RG路由器发送DD报文后，一直没有收到对方回应的DD报文；
  • 登录其他厂商的那台路由器，打开相应的debug开关，发现对方收到RG路由器发送的DD报文后，一发送了相应的DD报文予以回应。

(3) 原因分析：

初步断定，RG路由器没有收到DD回应报文，但对方确实发出来了。

既然可以接收到HELLO 报文说明链路是通畅的，而且多播报文的收发也没有问题。那么有可能是对方发送的DD 报文有错误导致RG路由器拒收，但查看相应的信息，并没有报告接收到错误的DD 报文。

仔细查看某厂商路由器的调试信息发现这个DD报文很大有2000 多字节。会不会是由于报文太大导致的问题呢？试着Ping了一个2000字节的报文，结果不通。那么故障原因很可能是－－由于双方的MTU不一致导致大包不通。

(4) 处理过程：

检查配置，发现对方路由器的MTU设置为4000多而RG路由器的MTU设置为1500，于是修改对端路由器的MTU为1500。故障排除。

那么为什么工程初期没有问题呢？这是因为前期DD报文长度小于1500字节，而后来网络扩容导致路由信息过多使DD 报文的长度超过了1500 字节。

(5) 建议和总结：

由于Ping 缺省报文是56 个字节，所以显示的Ping 通信息只是表示56字节的报文可以通而并不一定表示其他大小的报文仍旧可以通。所以，应当善于使用Ping的其他参数来进行故障排除。

案例三：A能Ping通B，B就一定能Ping通A吗？

(1) 现象描述

组网图如下：

网络设备故障排除命令之ping、traceroute、show、clear、debug图1-1 案例：A能Ping通B，B就一定能Ping通A吗？

在RouterA上配置一条指向2.0.0.0/8的静态路由：

在RouterA 上Ping RouterB 的以太网地址2.2.2.2，显示可以正常Ping通；但是在RouterB上Ping RouterA的以太网地址3.3.3.3，却无法Ping通。

(2) 原因分析：

由于在RouterB 上却没有相应的配置到3.0.0.0/8 路由，所以从RouterB 上Ping不通RouterA的以太网口3.3.3.3 。

但是为何在A上可以Ping 通2.2.2.2 呢？同样是没有回程路由呀？打开路由器上的IP报文调试开关发现，原来从RouterA上发出的ICMP报文的源地址填写的是1.1.1.1而不是3.3.3.3，由于两台路由器的s0口处于同一网段，所以响应报文可以顺利到达RouterB。

(3) 建议和总结：

A能够Ping通B则B一定能够Ping通A（不考虑防火墙的因素）,这句话的对错取决于A和B到底是指主机还是指路由器。

  • 如果是指两台主机，那么这句话就是正确的。
  • 如果是指两台路由器那就是错误的，因为路由器通常会有多个IP地址。现在就有如下问题：当从一台路由器上执行Ping命令它发出的ICMP Echo报文的源地址究竟选择哪一个呢？实际情况是路由器选择发出报文的接口的IP地址。

Traceroute 命令

1.原理

Traceroute是为了探测源节点到目的节点之间数据报文所经过的路径。利用IP报文的TTL域在每经过一个路由器的转发后减一，当TTL=0时则向源节点报告TTL超时这个的特性。Traceroute首先发送一个TTL为1的Icmp request报文，因此第一跳发送回一个ICMP错误消息以指明此数据报不能被发送（因为TTL超时），之后Traceroute再发送一个TTL为2的报文，同样第二跳返回TTL超时，这个过程不断进行，直到到达目的地，此时由于数据报中使用了无效的端口号（缺省为33434）此时目的主机会返回一个ICMP的目的地不可达消息，表明该Traceroute操作结束。Traceroute记录下每一个ICMP TTL超时消息的源地址，从而提供给用户报文到达目的地所经过的网关IP地址。

2.功能

Traceroute 命令用于测试数据报文从发送主机到目的地所经过的网关，主要用于检查网络连接是否可达，以及分析网络什么地方发生了故障。

3.RGNOS平台的Traceroute命令

例如在锐捷RG系列路由器上，Traceroute命令的格式如下：

例如：查看到目的主机10.15.50.1 中间所经过的网关。

4.Windows平台的Tracert 命令

在PC机上或Windwos为平台的服务器上，Tracert命令的格式如下：

  • -d 不解析主机名；
  • -h 指定最大TTL大小；
  • -j 设定松散源地址路由列表；
  • -w 用于设置UDP报文的超时时间，单位毫秒； 例如： 查看到目的主机10.15.50.1 中间所经过的前两个网关。

5.使用Traceroute命令进行故障排除

案例一：使用Traceroute命令定位不当的网络配置点

(1) 现象描述

组网情况如下图所示：

网络设备故障排除命令之ping、traceroute、show、clear、debug图1-2 案例：使用Traceroute命令定位不当的网络配置点

某校园网中，RouterB和RouterC同属于一个运行RIPv2路由协议的网络，主机4.0.0.2访问数据库服务器5.0.0.2，用户抱怨访问性能差。

(2) 相关信息显示

在主机上ping 5.0.0.2显示如下：

原因分析

上面的Ping显示出一个规律：奇数报文的返回时长短，而偶数报文返回时长很长（是奇数报文的10倍多）。可以初步判断奇数报文和偶数报文是通过不同的路径传输的。现在我们需要使用Traceroute命令来追踪这不同的路径。在RouterC上，Traceroute远端RouterA的以太网接口5.0.0.1。

从上面的显示可看到，直至3.0.0.2，UDP探测报文的返回时长都基本一致，而到5.0.0.1时，则发生明显变化，呈现奇数报文时长短，偶数报文时长长的现象。于是判断，问题发生在RouterB和RouterA之间。

通过询问该段网络的管理员，得知这两路由器间有一主一备两串行链路，主链路为2.048Mbps（s0口之间），备份链路为128Kbps（s1口之间）。网络管理员在此两路由器间配置了静态路由。

RouterB上如下配置：

于是问题就清楚了。例如RouterB，由于管理员配置时没有给出静态路由的优先级，这两条路由项的管理距离就同为缺省值1，于是就同时出现在路由表中，实现的是负载分担，而不能达到主备的目的。

(3) 处理过程

可以有两种处理方法：

  • 继续使用静态路由，进行配置更改 RouterB上进行如下更改：

RouterA上进行如下更改：

这样，只有当主链路发生故障，备份链路的路由项才会出线在路由表中，从而接替主链路完成报文转发，实现主备目的。

  • 在两路由器上运行动态路由协议，如OSPF，但不要运行RIP协议（因为RIP协议是仅以hop作为Metric的）

(4) 建议和总结

本案例的目的不是为了解释网络配置问题，而是用来展示Ping命令和Traceroute命令的相互配合来找到网络问题的发生点。尤其在一个大的组网环境中，维护人员可能无法沿着路径逐机排查，此时，能够迅速定位出发生问题的线路或路由器就非常重要了。

案例二：使用Traceroute命令发现路由环路

(1) 现象描述 组网情况如下图所示：

网络设备故障排除命令之ping、traceroute、show、clear、debug

三台路由器均配置静态路由，完成后，登录到RouterA上Ping主机4.0.0.2，发现不通。

(2) 相关信息显示

(3) 原因分析

本人提供Oracle(OCP、OCM)、MySQL(OCP)、PostgreSQL(PGCA、PGCE、PGCM)等数据库的培训和考证业务，私聊QQ646634621或微信db_bao，谢谢！

从上面的Traceroute命令的显示可以立即发现，在RouterA和RouterB间产生了路由环路。由于是配置的是静态路由，基本可以断定是RouterA或RouterB的静态路由配置错误。 检查RouterA的路由表，配置的是缺省静态路由：ip route 0.0.0.0 0.0.0.0 1.0.0.1，没有问题。

检查RouterB的路由表，配置到4.0.0.0网络的静态路由为：ip route 4.0.0.0 255.0.0.0 1.0.0.2――下一跳配置的是1.0.0.2，而不是3.0.0.1。这正是错误所在。

(4) 处理过程

修改RouterB的配置如下：

故障排除。

(5) 建议和总结

Traceroute命令能够很容易发现路由环路等潜在问题。当路由器A认为路由器B知道到达目的地的路径，而路由器B也认为路由器A知道目的地时，就是路由环路发生了。使用Ping命令只能知道接收端出现超时错误，而Traceroute能够立即发现环路所在――如果Traceroute命令两次或者多次显示同样的接口。

当通过Traceroute发现路由环路后，如果配置为：

  • 静态路由：几乎可以肯定是手工配置有问题，如本案例所示。
  • OSPF协议：可能是地址聚合产生的问题。
  • 多路由协议：可能是路由引入产生的问题。

Show命令

Show命令是用于了解路由器的当前状况、检测相邻路由器、从总体上监控网络、隔离互连网络中故障的最重要的工具之一。几乎在任何故障排除和监控场合，Show命令都是必不可少的。

例如：基于RGNOS路由平台的Show命令选项如下所示：

在此仅介绍部分最常用的、全局性的show命令。

1. Show Version命令

Show Version命令是最基本的命令之一，它用于显示路由器硬件和软件的基本信息。因为不同的版本有不同的特征，实现的功能也不完全相同，所以，查看硬件和软件的信息是解决问题的重要一步。在进行故障排除时，我们通常从这个命令开始收集数据。该命令将帮助用户收集下列信息：

  • RGNOS软件版本
  • 是哪一系列的产品 输出示例如下，请找到上述提及的相应项。

2.Show running-config和Show startup-config命令

  • Show running-config用于查看当前的配置信息。
  • Show startup-config用于显示NVRAM或Flash中的路由器配置文件，即路由器下次上电启动时所用的配置文件。

配置文件为一文本文件，其格式如下：

  • 以命令格式保存；
  • 为节约空间，只保存非缺省的常数命令；组织以命令模式为基本框架，同一命令模式的命令组织在一起，形式一节，节与节间以注释行隔开（以“！”开始的语句为注释行）
  • 节的顺序安排：全局配置、物理接口配置、逻辑接口配置、路由协议配置等；
  • 以end为结束。

示例如下：

强烈建议维护或管理人员保存一份启动配置文件的拷贝存放到路由器以外的其他设备上。这有几点好处：

  • 这将使维护人员能够迅速配置一个替代的路由器；
  • 这个保存在外部的文本文件也可以按上述规定的格式脱机编辑然后使用Download命令加载到路由器上；
  • 可以将该配置文件通过E-mail形式发给相关厂商技术支持人员以帮助定位配置问题。

3.Show interface命令

Show interface命令可以显示所有接口的当前状态，如果只是想查看特定接口的状态，请在该命令后输入接口类型和接口号，例如：show interface FastEthernet 0/13命令将查看以太口0/3的运行状态和相关信息。

Clear命令

在介绍完毕Show命令的基本使用后，必须提及一下Clear命令的作用――用于清空当前的统计信息以排除以前积累的数据的干扰。

Clear命令中最主要的是Clear counters命令。对于端口收发的各计数器的刷新必须使用Clear counters，可通过show interface命令来观察。

Clear命令适用场合如下： 许多情况下，我们需要使用带参数的Ping命令来测试链路的通断，同时在一段时间内Ping后，通过Show ip interface x/x counters命令来查看端口报文的收发及CRC校验等情况的正确与否，从而分析报文的收发在什么地方出现了问题。但show命令的显示值是自从路由器运行以来（或上次Clear后）的所有统计值，这个值是无法分析的。因此，实际我们需要进行的步骤为：首先使用Clearcounters命令清空统计值，然后使用一系列Ping命令使路由器端口收发报文，最后使用Show命令来查看统计值。

例如：通过Show interface FastEthernet 0/13 counters观察到端口有如下统计数据：

我们发现端口收发有了错误，但这些错误是否是最近产生的呢？可用Clear counters interface FastEthernet 0/13来进行刷新，再通过Ping一组报文测试路由器端口的收发，最后再使用Show interface FastEthernet 0/13 counters看结果统计。如果仍然显示发生错误，那么我们就需要分析原因进行故障排除了。

Debug命令

1. Debug命令概述

RG系列产品提供大量的debug命令支持，可以帮助用户在网络发生故障时获得路由器中交换的报文和帧的细节信息，这些信息对网络故障的定位是至关重要的。

打开相应的调试开关

例如：打开IP packet调试开关，命令为：

2. Debug命令使用注意事项

由于调试信息的输出在CPU处理中赋予了很高的优先级，许多形式的debug命令会占用大量的CPU运行时间，在负荷高的路由器上运行debug命令可能引起严重的网络故障（如网络性能迅速下降）。但debug命令的输出信息对于定位网络故障又是如此的重要，是维护人员必须使用的工具。因此，我们总结了一些使用debug命令的注意要点，如下：

  1. 应当使用debug命令来查找故障，而不是用来监控正常的网络运行。
  2. 尽量在网络使用的低峰期或网络用户较少时使用，以降低debug命令对系统的影响性。
  3. 在没有完全掌握某debug命令的工作过程以及它所提供的信息前，不要轻易使用该debug命令。
  4. 不要轻易使用类似debug all之类将产生大量输出的命令。仅当寻找某些类型的流量或故障并且已将故障原因缩小到一个可能的范围时，才使用某些特定的debug命令。
  5. 在使用debug命令获得足够多的信息后，应立即以“no debug xx”命令终止debug命令的执行。

可以使用show debugging命令查看当前已打开哪些调试开关并使用相应命令关闭；或干脆使用no debug all命令关闭所有调试开关。

案例一：忘记关闭debug开关引起的路由器报文转发速度变慢的故障排除

(1) 现象描述

某电信局安装了RG路由器作为接入服务器的出口网关，一段时间运转良好。某日用户反映该设备明显速度变慢。执行PING操作，PING对端路由器设备，所用时间为正常的2倍多。

(2) 相关信息收集

该路由器的日志中记录了大量的收发IP报文的信息。

(3) 原因分析

初步分析可能有以下几种原因：

  • 线路质量不好。
  • 对端设备问题，导致回应较慢。
  • 自身配置错误
  • 网络繁忙
  • 软硬件故障

(4) 处理过程

  • 检查线路，没有发现问题；
  • PING与之相连的其他路由器设备，故障依旧，说明对端设备无问题；
  • 对照以前运转良好时备份的Running-config文件，检查路由器上的配置，没有错误；
  • 当时并非上网高峰期，且只是变慢，而无丢包，应当不是网络负荷问题；
  • 检查该路由器的日志信息，发现其中记录了大量的收发IP报文的信息，执行命令show debugging命令，发现该路由器的debug ip packet处于打开状态。由于设备需要记录每一个被转发的IP报文，大大降低了路由器的处理速度，导致变慢。

关闭该debug开关后，故障排除。

(5) 建议与总结

山重水复疑无路，柳暗花明又一村。排除此类故障时应该想一下debug开关的问题。

案例二：通过串口telnet到路由器，在该串口上打开debug命令产生问题

当远程调试RG路由器时，有时需要通过某个串口telnet上该路由器，如果该串口上的链路层协议封装的是FR、PPP或HDLC，千万不能打开该串口相应的链路层调试开关（可以打开其他串口的链路层调试开关），否则由于数据流量太大，会使该串口的协议down掉。

3.show命令和debug命令的配合使用

Show命令能够提供某个时间的设备运行状况的视图（静态），而debug命令能够展示一段时间内设备运行的变化情况（动态）。因此，要在故障排除时了解系统运行的总体情况，必须同时使用这两个命令。例如：当进行OSPF协议的故障排除时，需要使用show ip route命令来了解路由器当前已经知道了哪些路由表项，需要使用debug ip ospf events命令来了解路由表是如何更新的。如果不知道路由表的当前内容，路由更新的信息对故障排除是不够的。Debug命令并不能直接告诉你设备已知到的信息，而show命令则不能告诉路由表的变化情况，两者的配合使用，才能全面了解正在发生的事情。

一般说来，Show命令不会影响系统的运行性能，而debug命令则会对系统性能造成影响。因此两者的使用应遵循如下规则：首先使用相关的多个show命令查看设备当前的运行状况，分析可能原因，缩减故障到适当范围，然后打开某个特定的debug命令观察变化情况，以定位和排除问题。

参考

https://mp.weixin.qq.com/s/w4QgbTg5zwDDnNpAw8VA1A

标签：

头像

小麦苗

学习或考证，均可联系麦老师，请加微信db_bao或QQ646634621

您可能还喜欢...

发表回复

嘿，我是小麦，需要帮助随时找我哦
  • 18509239930

  • 个人微信

  • 麦老师QQ聊天
  • 个人邮箱
  • 点击加入QQ群

  • 个人微店

  • 回到顶部
返回顶部