遇到網(wǎng)絡故障的時候，你一般會最先使用哪條命令進行排障？

01

Ping的原理&功能

“ping”這個詞源于聲納定位操作，指來自聲納設備的脈沖信號。

Ping命令的思想與發(fā)出一個短促的雷達波，通過收集回波來判斷目標很相似：

即源站點向目的站點發(fā)出一個ICMP Echo Request報文，目的站點收到該報文后回一個ICMP Echo Reply報文。

這樣就驗證了兩個節(jié)點間IP層的可達性——表示了網(wǎng)絡層是連通的。

Ping命令功能主要是用于檢查IP網(wǎng)絡連接及主機是否可達。

02

RGNOS平臺的ping命令

在RG系列設備上，Ping命令的格式是這樣的：

pingip-address

比如說，向主機10.15.50.1 Ping報文

03

Windows平臺的Ping命令

在PC機上或Windwos為平臺的服務器上，Ping命令的格式如下：

Ping[-nnumber][-t][-lnumber]ip-address

-n：Ping報文的個數(shù)，缺省值為5；

-t：持續(xù)地ping 直到人為地中斷，Ctr+Breack暫時中止ping命令并查看當前的統(tǒng)計結(jié)果，而Ctr+C則中斷命令的執(zhí)行。

-l：設置Ping報文所攜帶的數(shù)據(jù)部分的字節(jié)數(shù)，設置范圍從0至65500。例：向主機10.15.50.1 發(fā)出2個數(shù)據(jù)部分大小為 3000 Bytes的ping報文。

04

巧用Ping進行故障排除

排障案例①連通性問題還是性能問題？

案例描述：

工程師小C，在配置完一臺路由器之后執(zhí)行Ping命令檢測鏈路是否通暢。

發(fā)現(xiàn)5個報文都沒有Ping通，于是檢查雙方的配置命令并查看路由表，卻一直沒有找到錯誤所在。

最后又重復執(zhí)行了一遍相同的Ping命令，發(fā)現(xiàn)這一次5個報文中有1個Ping 通了——原來是線路質(zhì)量不好存在比較嚴重的丟包現(xiàn)象。

工程師小C又配置了一臺路由器，然后執(zhí)行Ping命令訪問Internet上某站點的IP地址，但沒有Ping通。

有了上次的教訓小L，再一次Ping了20個報文，仍舊沒有響應。于是小L斷定是網(wǎng)絡故障。

但是在費勁周折檢查了配置鏈路之后仍沒有發(fā)現(xiàn)任何可疑之處。

最后小L采取逐段檢測的方法對鏈路中的網(wǎng)關進行逐級測試，發(fā)現(xiàn)都可以Ping 通，但是響應的時間越來越長，最后一個網(wǎng)關的響應時間在1800ms左右。

會不會是由于超時而導致顯示為Ping 不同呢？

受此啟發(fā)，小L將Ping 命令報文的超時時間改為4000ms，這次成功Ping通了，顯示所有的報文響應時間都在2200ms 左右。

建議和總結(jié)：

真的是Ping不通嗎？這個問題需要定位清楚。

因為連通性問題和性能問題排錯的關注點是不一樣的——問題定位錯誤必然會導致排錯過程的周折。

使用一般的Ping命令，缺省是發(fā)送5個報文的，超時時長是2000ms。

如果Ping不通情況發(fā)生，最好能夠再用帶參數(shù)-c和-t的Ping命令再執(zhí)行一遍。

如：Ping -c 20 -t 4000 ip-address，即連續(xù)發(fā)送20個報文，每個報文的超時時長為4000ms，這樣一般可以判斷出到底是連通性問題還是性能問題。

排障案例②使用大包ping對端進行MTU不一致的故障排除

案例描述：

某次開局，使用RG路由器與其他廠商的某路由器互連，并運行OSPF協(xié)議。

數(shù)據(jù)配置完畢后，一切正常，并在今后相當長的時間內(nèi)設備運轉(zhuǎn)穩(wěn)定。但兩個月后，用戶反饋網(wǎng)絡中斷。

相關信息顯示：

1、登錄到兩臺路由器上，發(fā)現(xiàn)雙方連接正常，可以相互Ping通對端地址。但OSPF協(xié)議中斷。

2、登錄RG路由器查看鄰居狀態(tài)，發(fā)現(xiàn)鄰居狀態(tài)機處于Exstart狀態(tài)。打開相應的debug開關查看相應的報文信息，發(fā)現(xiàn)雙方都可以收到Hello報文，但RG路由器發(fā)送DD報文后，一直沒有收到對方回應的DD報文。

3、登錄其他廠商的那臺路由器，打開相應的debug開關，發(fā)現(xiàn)對方收到RG路由器發(fā)送的DD報文后，一發(fā)送了相應的DD報文予以回應。

原因分析：

初步斷定，RG路由器沒有收到DD回應報文，但對方確實發(fā)出來了。

既然可以接收到HELLO 報文說明鏈路是通暢的，而且多播報文的收發(fā)也沒有問題。

那么有可能是對方發(fā)送的DD 報文有錯誤導致RG路由器拒收，但查看相應的信息，并沒有報告接收到錯誤的DD 報文。

仔細查看某廠商路由器的調(diào)試信息發(fā)現(xiàn)這個DD報文很大有2000 多字節(jié)。

會不會是由于報文太大導致的問題呢？

試著Ping了一個2000字節(jié)的報文，結(jié)果不通。那么故障原因很可能是——由于雙方的MTU不一致導致大包不通。

處理過程：

檢查配置，發(fā)現(xiàn)對方路由器的MTU設置為4000多而RG路由器的MTU設置為1500，于是修改對端路由器的MTU為1500。

故障排除。

那么為什么工程初期沒有問題呢？

這是因為前期DD報文長度小于1500字節(jié)，而后來網(wǎng)絡擴容導致路由信息過多使DD 報文的長度超過了1500 字節(jié)。

建議和總結(jié)：

由于Ping 缺省報文是56 個字節(jié)，所以顯示的Ping 通信息只是表示56字節(jié)的報文可以通而并不一定表示其他大小的報文仍舊可以通。

所以，應當善于使用Ping的其他參數(shù)來進行故障排除。

排障案例③A能Ping通B，B就一定能Ping通A嗎？

案例描述：

先來看個組網(wǎng)圖。

在RouterA上配置一條指向2.0.0.0/8的靜態(tài)路由：

RouterA（config）#ip route 2.0.0.0 255.0.0.0 1.1.1.1

在RouterA 上Ping RouterB 的以太網(wǎng)地址2.2.2.2，顯示可以正常Ping通。

但是在RouterB上Ping RouterA的以太網(wǎng)地址3.3.3.3，卻無法Ping通。

原因分析：

由于在RouterB 上卻沒有相應的配置到3.0.0.0/8 路由，所以從RouterB 上Ping不通RouterA的以太網(wǎng)口3.3.3.3 。

但是為何在A上可以Ping 通2.2.2.2 呢？同樣是沒有回程路由??？

打開路由器上的IP報文調(diào)試開關發(fā)現(xiàn)，原來從RouterA上發(fā)出的ICMP報文的源地址填寫的是1.1.1.1而不是3.3.3.3。

由于兩臺路由器的s0口處于同一網(wǎng)段，所以響應報文可以順利到達RouterB。

建議和總結(jié)：

A能夠Ping通B則B一定能夠Ping通A（不考慮防火墻的因素）,這句話的對錯取決于A和B到底是指主機還是指路由器。

如果是指兩臺主機，那么這句話就是正確的。

如果是指兩臺路由器那就是錯誤的，因為路由器通常會有多個IP地址。

現(xiàn)在就有如下問題：當從一臺路由器上執(zhí)行Ping命令它發(fā)出的ICMP Echo報文的源地址究竟選擇哪一個呢？

實際情況是路由器選擇發(fā)出報文的接口的IP地址。

審核編輯：劉清