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
- -n Ping報文的個數，缺省值爲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) 現象描述
組網圖如下：
圖1-1 案例：A能Ping通B，B就一定能Ping通A嗎？
在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命令，發現該路由器的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命令觀察變化情況，以定位和排除問題。