1.网络排错常用诊断工具介绍
主流网络设备产品提供了一套完整的命令集,可以用于监控网络互联环境的工作状况和解决基本的网络故障。主要包括以下命令:
- Ping命令
- Traceroute命令
- Show命令
- Clear命令
- Debug命令
1.1 Ping命令
1.原理:
“ping”这个词源于声纳定位操作,指来自声纳设备的脉冲信号。Ping命令的思想与发出一个短促的雷达波,通过收集回波来判断目标很相似;即源站点向目的站点发出一个ICMP Echo Request报文,目的站点收到该报文后回一个ICMP Echo Reply报文,这样就验证了两个节点间IP层的可达性--表示了网络层是连通的。
2.功能
Ping命令功能用于检查IP网络连接及主机是否可达。
3.RGNOS平台的ping命令
在RG系列设备上,Ping命令的格式如下:
ping ip-address
例如,向主机10.15.50.1 Ping报文
RG# ping 10.15.50.1 //ping通的情况
Switch>PING
Target IP address or host: 10.15.50.1 //目的IP
Repeat count [5]: 2 //执行次数
Datagram size [100]: 8100 //数据包大小
Timeout in milliseconds [2000]: 5000 //延迟时间
Extended commands [n]:
Sending 2, 8100-byte ICMP Echos to 10.15.50.1,
timeout is 5000 milliseconds.
!!
Success rate is 100 percent (2/2)
Minimum = 21ms Maximum = 22ms, Average = 21msRG
# ping 10.15.50.1 //ping不通的情况
Sending 5, 100-byte ICMP Echos to 10.15.50.1,
timeout is 2000 milliseconds.
.....
Success rate is 0 percent (0/5)
4.Windows平台的Ping命令
在PC机上或Windwos为平台的服务器上,Ping命令的格式如下:
Ping [ -n number ] [ -t ] [ -l number ] ip-address
- -nPing报文的个数,缺省值为5;
- -t持续地ping 直到人为地中断,Ctr+Breack暂时中止ping命令并查看当前的统计结果,而Ctr+C则中断命令的执行。
-
-l设置Ping报文所携带的数据部分的字节数,设置范围从0至65500。
例:向主机10.15.50.1 发出2个数据部分大小为 3000 Bytes的ping报文
C:\>ping -l 3000 -n 2 10.15.50.1
Pinging 10.15.50.1 with 3000 bytes of data
Reply from 10.15.50.1: bytes=3000 time=321ms TTL=255
Reply from 10.15.50.1: bytes=3000 time=297ms TTL=255
Ping statistics for 10.15.50.1:
Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 297ms, Maximum = 321ms, Average = 309ms
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) 现象描述
组网图如下:
在RouterA上配置一条指向2.0.0.0/8的静态路由:
RouterA(config)# ip route 2.0.0.0 255.0.0.0 1.1.1.1
在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地址。
1.2 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命令的格式如下:
Traceroute host 『destination』
例如:查看到目的主机10.15.50.1 中间所经过的网关。
RG# traceroute 10.15.50.1
Type esc/CTRL^c/CTRL^z/q to abort.
traceroute 192.168.0.1 ......
1 10.110.40.1 1 4 ms 5 ms 5 ms
2 10.110.0.64 10 ms 5 ms 5 ms
3 10.110.7.254 10 ms 5 ms 5 ms
4 10.3.0.177 175 ms 160 ms 145 ms
5 129.9.181.254 185 ms 210 ms 260 ms
6 10.15.50.1 230 ms 185 ms 220 ms
Trace complete successfully.
4.Windows平台的Tracert 命令
在PC机上或Windwos为平台的服务器上,Tracert命令的格式如下:
tracert [ -d ] [ -h maximum_hops ] [ -j host-list ] [ -w timeout ] host
- -d不解析主机名;
- -h指定最大TTL大小;
- -j设定松散源地址路由列表;
-
-w用于设置UDP报文的超时时间,单位毫秒;
例如: 查看到目的主机10.15.50.1 中间所经过的前两个网关。
C:\>tracert -h 2 10.15.50.1
Tracing route to 10.15.50.1 over a maximum of 2 hops:
1 3 ms 2 ms 2 ms 10.110.40.1
2 5 ms 3 ms 2 ms 10.110.0.64
Trace complete.
5.使用Traceroute命令进行故障排除
案例一:使用Traceroute命令定位不当的网络配置点
(1) 现象描述
组网情况如下图所示:
某校园网中,RouterB和RouterC同属于一个运行RIPv2路由协议的网络,主机4.0.0.2访问数据库服务器5.0.0.2,用户抱怨访问性能差。
(2) 相关信息显示
在主机上ping 5.0.0.2显示如下:
C:\Documents and Settings\c>ping -n 10 -l 1000 5.0.0.2
Pinging 5.0.0.2 with 1000 bytes of data:
Reply from 5.0.0.2: bytes=1000 time=552ms TTL=250
Reply from 5.0.0.2: bytes=1000 time=5735ms TTL=250
Reply from 5.0.0.2: bytes=1000 time=551ms TTL=250
Reply from 5.0.0.2: bytes=1000 time=5734ms TTL=250
Reply from 5.0.0.2: bytes=1000 time=549ms TTL=250
Reply from 5.0.0.2: bytes=1000 time=5634ms TTL=250
Reply from 5.0.0.2: bytes=1000 time=555ms TTL=250
Reply from 5.0.0.2: bytes=1000 time=5738ms TTL=250
Reply from 5.0.0.2: bytes=1000 time=455ms TTL=250
Reply from 5.0.0.2: bytes=1000 time=5811ms TTL=250
原因分析
上面的Ping显示出一个规律:奇数报文的返回时长短,而偶数报文返回时长很长(是奇数报文的10倍多)。可以初步判断奇数报文和偶数报文是通过不同的路径传输的。现在我们需要使用Traceroute命令来追踪这不同的路径。在RouterC上,Traceroute远端RouterA的以太网接口5.0.0.1。
RouterC(config)#traceroute
Target IP address or host: 5.0.0.1
Maximum number of hops to search for target [30]:10
Repeat count for each echo[3]:8
Wait timeout milliseconds for each reply [2000]:
Type esc/CTRL^c/CTRL^z/q to abort.
traceroute 5.0.0.1 ......
1 6 ms 4 ms 4 ms 4 ms 4 ms 4 ms 4 ms 4 ms 4.0.0.1
。。。。。。(中间省略)
5 20 ms 16 ms 15 ms 16 ms 16 ms 16 ms 16 ms 16 ms 3.0.0.2
6 30 ms 278 ms 25 ms 279 ms 25 ms 278 ms 25 ms 277 ms 5.0.0.1
RouterC(config)#
从上面的显示可看到,直至3.0.0.2,UDP探测报文的返回时长都基本一致,而到5.0.0.1时,则发生明显变化,呈现奇数报文时长短,偶数报文时长长的现象。于是判断,问题发生在RouterB和RouterA之间。
通过询问该段网络的管理员,得知这两路由器间有一主一备两串行链路,主链路为2.048Mbps(s0口之间),备份链路为128Kbps(s1口之间)。网络管理员在此两路由器间配置了静态路由。
RouterB上如下配置:
RouterB(config)# ip route 5.0.0.0 255.0.0.0 1.0.0.2
RouterB(config)# ip route 5.0.0.0 255.0.0.0 2.0.0.2
RouterA上如下配置:
RouterA(config)# ip route 0.0.0.0 0.0.0.0 1.0.0.1
RouterA(config)# ip route 0.0.0.0 0.0.0.0 2.0.0.1
于是问题就清楚了。例如RouterB,由于管理员配置时没有给出静态路由的优先级,这两条路由项的管理距离就同为缺省值1,于是就同时出现在路由表中,实现的是负载分担,而不能达到主备的目的。
(3) 处理过程
可以有两种处理方法:
-
继续使用静态路由,进行配置更改
RouterB上进行如下更改:
RouterB(config)# ip route 5.0.0.0 255.0.0.0 1.0.0.2 (主链路仍使用缺省1)
RouterB(config)# ip route 5.0.0.0 255.0.0.0 2.0.0.2 100(备份链路的降低至100)
RouterA上进行如下更改:
RouterA(config)# ip route 0.0.0.0 0.0.0.0 1.0.0.1
RouterA(config)# ip route 0.0.0.0 0.0.0.0 2.0.0.1 100
这样,只有当主链路发生故障,备份链路的路由项才会出线在路由表中,从而接替主链路完成报文转发,实现主备目的。
- 在两路由器上运行动态路由协议,如OSPF,但不要运行RIP协议(因为RIP协议是仅以hop作为Metric的)
(4) 建议和总结
本案例的目的不是为了解释网络配置问题,而是用来展示Ping命令和Traceroute命令的相互配合来找到网络问题的发生点。尤其在一个大的组网环境中,维护人员可能无法沿着路径逐机排查,此时,能够迅速定位出发生问题的线路或路由器就非常重要了。
案例二:使用Traceroute命令发现路由环路
(1) 现象描述
组网情况如下图所示:
三台路由器均配置静态路由,完成后,登录到RouterA上Ping主机4.0.0.2,发现不通。
(2) 相关信息显示
RouterA# ping 4.0.0.2
Sending 5, 100-byte ICMP Echos to 4.0.0.2,
timeout is 2000 milliseconds.
.....
Success rate is 0 percent (0/5)
RouterA# traceroute 4.0.0.2
Type esc/CTRL^c/CTRL^z/q to abort.
traceroute 4.0.0.2 ......
1 6 ms 4 ms 4 ms 1.0.0.1(RouterB)
2 8 ms 8 ms 8 ms 1.0.0.2(RouterA)
3 12 ms 12 ms 12 ms 1.0.0.1(RouterB)
4 16 ms 16 ms 16 ms 1.0.0.2(RouterA)
。。。。。。
(3) 原因分析
从上面的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的配置如下:
RouterB(config)# no ip route 4.0.0.0 255.0.0.0 1.0.0.2
RouterB(config)# ip route 4.0.0.0 255.0.0.0 3.0.0.1
故障排除。
(5) 建议和总结
Traceroute命令能够很容易发现路由环路等潜在问题。当路由器A认为路由器B知道到达目的地的路径,而路由器B也认为路由器A知道目的地时,就是路由环路发生了。使用Ping命令只能知道接收端出现超时错误,而Traceroute能够立即发现环路所在――如果Traceroute命令两次或者多次显示同样的接口。
当通过Traceroute发现路由环路后,如果配置为:
- 静态路由:几乎可以肯定是手工配置有问题,如本案例所示。
- OSPF协议:可能是地址聚合产生的问题。
- 多路由协议:可能是路由引入产生的问题。
1.3 Show命令
Show命令是用于了解路由器的当前状况、检测相邻路由器、从总体上监控网络、隔离互连网络中故障的最重要的工具之一。几乎在任何故障排除和监控场合,Show命令都是必不可少的。
例如:基于RGNOS路由平台的Show命令选项如下所示:
RG#show ?
access-group MAC access-group
access-lists List access lists
accounting Accounting configurations parameters
address-bind address binding table
AggregatePort AggregatePort IEEE 802.3ad
arp ARP table
class-map Show QoS Class Map
clock Display the system clock
cluster Cluster information
configure Contents of Non-Volatile memory
cpu CPU statistics
debugging State of each debugging option
detect detect user ip
dot1x IEEE 802.1X information
file Show filesystem information
gvrp GVRP configure command
host IP dns host table
interfaces Interface status and configuration
ip IP information
ip-auth-mode Show IP authentication mode
key Key information
line TTY line information
lldp LLDP information
logging Show the contents of logging buffers
mac MAC information
mac-address-table MAC forwarding table
member Show members information
memory Memory statistics
mls Show MultiLayer Switching information
monitor Show a SPAN session
policy-map Show QoS Policy Map
port-security Show secure port information
privilege Show current privilege level
radius-server Show RADIUS query parameters
rate-control Rate control configuration information
reload Halt and perform a cold restart
rmon rmon statistics
running-config Current operating configuration
security Security Settings
service Show network management services
smp-server SMP Server Parameters
snmp snmp statistics
snmp-server Show SNMP parameters
sntp show sntp parameter
spanning-tree Spanning tree topology
storm-control Show packet storm control configuration
time-range Show time-range information
version System hardware and software status
vlan VLAN status
在此仅介绍部分最常用的、全局性的show命令。
1. Show Version命令
Show Version命令是最基本的命令之一,它用于显示路由器硬件和软件的基本信息。因为不同的版本有不同的特征,实现的功能也不完全相同,所以,查看硬件和软件的信息是解决问题的重要一步。在进行故障排除时,我们通常从这个命令开始收集数据。该命令将帮助用户收集下列信息:
- RGNOS软件版本
-
是哪一系列的产品
输出示例如下,请找到上述提及的相应项。
Switch #sh ver
System description : Red-Giant Gigabit Intelligent Switch(S2126G) By
Ruijie Network
System uptime : 1d:2h:41m:11s
System hardware version : 3.3
System software version : 1.66(3) Build Sep 7 2006 Rel
System BOOT version : RG-S2126G-BOOT 03-02-02
System CTRL version : RG-S2126G-CTRL 03-11-02
Running Switching Image : Layer2
2.Show running-config和Show startup-config命令
- Show running-config用于查看当前的配置信息。
- Show startup-config用于显示NVRAM或Flash中的路由器配置文件,即路由器下次上电启动时所用的配置文件。
配置文件为一文本文件,其格式如下:
- 以命令格式保存;
- 为节约空间,只保存非缺省的常数命令;组织以命令模式为基本框架,同一命令模式的命令组织在一起,形式一节,节与节间以注释行隔开(以“!”开始的语句为注释行)
- 节的顺序安排:全局配置、物理接口配置、逻辑接口配置、路由协议配置等;
- 以end为结束。
示例如下:
Switch#show running-config
System software version : 1.66(3) Build Sep 7 2006 Rel
Building configuration...
Current configuration : 287 bytes
!
version 1.0
!
hostname Switch
vlan 1
!
enable secret level 14 5 $2,1u_;C3&-8U0<D4'.tj9=GQ+/7R:>H
enable secret level 15 5 $2H.Y*T73C,tZ[V/4D+S(\W&QG1X)sv'
!
interface vlan 1
no shutdown
ip address 192.168.0.221 255.255.255.0
!
ip default-gateway 192.168.0.1
end
Switch#
强烈建议维护或管理人员保存一份启动配置文件的拷贝存放到路由器以外的其他设备上。这有几点好处:
- 这将使维护人员能够迅速配置一个替代的路由器;
- 这个保存在外部的文本文件也可以按上述规定的格式脱机编辑然后使用Download命令加载到路由器上;
- 可以将该配置文件通过E-mail形式发给相关厂商技术支持人员以帮助定位配置问题。
3.Show interface命令
Show interface
命令可以显示所有接口的当前状态,如果只是想查看特定接口的状态,请在该命令后输入接口类型和接口号,例如:
show interface FastEthernet 0/13
命令将查看以太口0/3的运行状态和相关信息。
Switch#show interface FastEthernet 0/13
Interface : FastEthernet100BaseTX 0/13
Description :
AdminStatus : up
OperStatus : up
Hardware : 10/100BaseTX
Mtu : 1500
LastChange : 0d:22h:32m:50s
AdminDuplex : Auto
OperDuplex : Full
AdminSpeed : Auto
OperSpeed : 100
FlowControlAdminStatus : Off
FlowControlOperStatus : Off
Priority : 0
Broadcast blocked :DISABLE
Unknown multicast blocked :DISABLE
Unknown unicast blocked :DISABLE
1.4 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
观察到端口有如下统计数据:
Interface : Fa0/13
5 minute input rate : 76208 bits/sec, 53 packets/sec
5 minute output rate : 340600 bits/sec, 53 packets/sec
InOctets : 53193982
InUcastPkts : 253095
InMulticastPkts : 32
InBroadcastPkts : 10655
OutOctets : 416202081
OutUcastPkts : 336100
OutMulticastPkts : 1740
OutBroadcastPkts : 12981
Undersize packets : 0
Oversize packets : 0
collisions : 0
Fragments : 0
Jabbers : 0
CRC alignment errors : 16
AlignmentErrors : 0
FCSErrors : 0
dropped packet events (due to lack of resources): 0
packets received of length (in octets):
64:157041, 65-127: 127987, 128-255: 10115,
256-511: 7169, 512-1023: 14593, 1024-1518: 297698
我们发现端口收发有了错误,但这些错误是否是最近产生的呢?可用
Clear counters interface FastEthernet 0/13
来进行刷新,再通过Ping一组报文测试路由器端口的收发,最后再使用
Show interface FastEthernet 0/13 counters
看结果统计。如果仍然显示发生错误,那么我们就需要分析原因进行故障排除了。
1.5 Debug命令
1. Debug命令概述
RG系列产品提供大量的debug命令支持,可以帮助用户在网络发生故障时获得路由器中交换的报文和帧的细节信息,这些信息对网络故障的定位是至关重要的。
打开相应的调试开关
例如:打开IP packet调试开关,命令为:
RG# debug ip packet
2. Debug命令使用注意事项
由于调试信息的输出在CPU处理中赋予了很高的优先级,许多形式的debug命令会占用大量的CPU运行时间,在负荷高的路由器上运行debug命令可能引起严重的网络故障(如网络性能迅速下降)。但debug命令的输出信息对于定位网络故障又是如此的重要,是维护人员必须使用的工具。因此,我们总结了一些使用debug命令的注意要点,如下:
- 应当使用debug命令来查找故障,而不是用来监控正常的网络运行。
- 尽量在网络使用的低峰期或网络用户较少时使用,以降低debug命令对系统的影响性。
- 在没有完全掌握某debug命令的工作过程以及它所提供的信息前,不要轻易使用该debug命令。
- 不要轻易使用类似debug all之类将产生大量输出的命令。仅当寻找某些类型的流量或故障并且已将故障原因缩小到一个可能的范围时,才使用某些特定的debug命令。
- 在使用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
处于打开状态。由于设备需要记录每一个被转发的IP报文,大大降低了路由器的处理速度,导致变慢。debug ip packet
关闭该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命令则不能告诉路由表的变化情况,两者的配合使用,才能全面了解正在发生的事情。