網絡基本功（十四）：細說診斷工具ping · 網絡基本功系列

# 網絡基本功（十四）：細說診斷工具ping **轉載請在文首保留原文出處：EMC中文支持論壇**[https://community.emc.com/go/chinese](https://community.emc.com/go/chinese) [![image001.gif](https://community.emc.com/servlet/JiveServlet/downloadImage/2-848168-100386/image001.gif)](http://service.weibo.com/share/share.php?title=%23ECN%e4%b8%ad%e6%96%87%e6%94%af%e6%8c%81%e8%ae%ba%e5%9d%9b%23 %e7%bd%91%e7%bb%9c%e5%9f%ba%e6%9c%ac%e5%8a%9f%ef%bc%88%e5%8d%81%e5%9b%9b%ef%bc%89%ef%bc%9a%e7%bb%86%e8%af%b4%e8%af%8a%e6%96%ad%e5%b7%a5%e5%85%b7ping @EMC%e6%98%93%e5%ae%89%e4%bf%a1%e4%b8%ad%e5%9b%bd%e6%8a%80%e6%9c%af%e7%a4%be%e5%8c%ba&url= https://community.emc.com/message/848168#848168) ## 介紹 ping的工作原理很簡單，一臺網絡設備發送請求等待另一網絡設備的回復，并記錄下發送時間。接收到回復之后，就可以計算報文傳輸時間了。只要接收到回復就表示連接是正常的。耗費的時間喻示了路徑長度。重復請求響應的一致性也表明了連接質量的可靠性。因此，ping回答了兩個基本的問題：是否有連接？連接的質量如何？本文主要討論這兩個問題。 ## 更多信息正常的ping操作主要是兩個特定的ICMP消息，ECHO_REQUEST和ECHO_REPLY。理論上，所有TCP/IP網絡設備都應當通過返回報文來響應ECHO_REQUEST，但實際上并不總是如此。 **ping的解析:** 大多數操作系統版本，會一直發送ECHO_REQUESTs，直到中斷為止。例如： ``` bsd1# ping www.bay.com PING www.bay.com (204.80.244.66): 56 data bytes 64 bytes from 204.80.244.66: icmp_seq=0 ttl=112 time=180.974 ms 64 bytes from 204.80.244.66: icmp_seq=1 ttl=112 time=189.810 ms 64 bytes from 204.80.244.66: icmp_seq=2 ttl=112 time=167.653 ms ^C --- www.bay.com ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 167.653/179.479/189.810/9.107 ms bsd1# ``` 這一過程被Ctrl-C中斷，此時打印出匯總統計。上述結果中，針對每一個報文的回復給出了報文大小，來源，ICMP sequence number，TTL值，以及往返時間。其中，sequence number和往返時間對于評估基本連接狀況來說是最有用的信息。當發送一個ECHO_REQUEST時，將發送時間記錄在報文里，并復制到遠端主機相應的ECHO_REPLY報文中。當接收到ECHO_REPLY時，通過比較當前時間與報文時間計算出耗費時間。如果沒有收到符合該sequence number的報文，則認為該報文丟失。耗費時間長短以及變化范圍取決于中間鏈路數量，速度，以及鏈路擁塞情況。什么值是合理的呢？這一值高度取決于網絡以及網絡質量。如果是在LAN網絡環境下，響應時間還是很快的，通常在十幾毫秒范圍之內。如果連接到外網則該值會顯著增加。如果是遠程站點，可能會耗時上百毫秒。你也可以用ping來粗略計算連接的吞吐量。在外網上發送兩個不同大小的報文，通過-s選項來完成。時間長度的差別會反映大報文中額外數據所耗費的時間。例如，假設ping 100字節耗費30ms而ping 1100字節耗費60ms，因此，往返額外花費30ms單程額外花費15ms，多發送1000字節或8000比特。吞吐量近似為每15ms 8000比特或540，000bps。兩個測量值之間的差異用來扣除開銷。當然這一估算是非常粗略的，沒有考慮到路徑上其他數據流的情況，也沒有考慮路徑上所有鏈路的情況。 TTL貌似可以估算一條路徑上的跳數，但是這有一些問題。當發送報文時，TTL字段先被初始化接著經過路徑上每個路由器都要遞減。如果達到0，報文就被丟棄了。從而對所有報文生命周期有一定限制。因而在路由回環的過程中，報文不會無期限存在于網絡上。不幸的是，TTL字段可能會，也可能不會被遠端設備重置，如果重置，也沒有一致性。因此，要使用TTL字段估算路徑中的跳數需要知道詳細的系統信息。通常一串穩定的回復意味著健康的連接。如果報文丟失或丟棄，可以在sequence number中看到跳數，以及丟失報文的編號。偶爾丟失一個報文不表示真的有什么問題。特別是跨越多臺路由器或擁塞網絡時。一個序列中的一個報文丟失或耗費明顯更長時間是很正常的，這是因為路徑中各條鏈路需對第一個報文做ARP解析。在ARP數據保存之后，后續報文就不會有這種開銷。但是，如果丟失報文比例較大，則有可能路徑上有問題。某些情況下會收到ICMP錯誤消息。通常來自路由器，這里面包含很有用的信息。例如，下例中，設備嘗試訪問一個不存在的網絡上的設備： ``` bsd1# ping 172.16.4.1 PING 172.16.4.1 (172.16.4.1): 56 data bytes 36 bytes from 172.16.2.1: Destination Host Unreachable Vr HL TOS? Len?? ID Flg? off TTL Pro? cks????? Src????? Dst 4? 5? 00 5400 5031?? 0 0000? fe? 01 0e49 172.16.2.13? 172.16.4.1 36 bytes from 172.16.2.1: Destination Host Unreachable Vr HL TOS? Len?? ID Flg? off TTL Pro? cks????? Src????? Dst 4? 5? 00 5400 5034?? 0 0000? fe? 01 0e46 172.16.2.13? 172.16.4.1 ^C --- 172.16.4.1 ping statistics --- 2 packets transmitted, 0 packets received, 100% packet loss ``` 由于路由器沒有到達該網絡的路徑，所以返回ICMP DESTINATION_HOST_UNREACHABLE信息。通常如果問題發生在運行ping命令的設備上，則會收到Destination Host Unreachable告警或 Destination Network Unreachable告警。如果問題發生在轉發報文的設備上，則只會收到一條Destination Host Unreachable。下例中，嘗試向一臺已配置拒絕從源設備接收數據流的路由器發送數據： ``` bsd1# ping 172.16.3.10 PING 172.16.3.10 (172.16.3.10): 56 data bytes 36 bytes from 172.16.2.1: Communication prohibited by filter Vr HL TOS? Len?? ID Flg? off TTL Pro? cks????? Src????? Dst 4? 5? 00 5400 5618?? 0 0000? ff? 01 0859 172.16.2.13? 172.16.3.10 36 bytes from 172.16.2.1: Communication prohibited by filter Vr HL TOS? Len?? ID Flg? off TTL Pro? cks????? Src????? Dst 4? 5? 00 5400 561b?? 0 0000? ff? 01 0856 172.16.2.13? 172.16.3.10 ^C --- 172.16.3.10 ping statistics --- 2 packets transmitted, 0 packets received, 100% packet loss 被過濾條件阻止的告警信息表明報文被丟棄。但也有可能過濾條件不顯示該告警。下例中， bsd1# ping 172.16.3.10 PING 172.16.3.10 (172.16.3.10): 56 data bytes ^C --- 172.16.3.10 ping statistics --- 6 packets transmitted, 0 packets received, 100% packet loss ``` 路由器上使用同樣的過濾條件，但應用于離開網絡的數據流，而不作用于inbound數據流。因此，沒有消息發送。這時，ping就無法告訴你為什么報文沒有收到回復。 **ping的選項:** 一些選項控制發送報文的速率和數量，-c選項允許用戶指定發送報文的數量。例如，ping –c10會發送10個報文然后停止。這一命令在腳本中很有用處。命令-f和-l用于將報文泛洪到網絡上。-f選項表明報文發送速率與接收主機能夠處理速率相同。這一參數可用于鏈路壓力測試或接口性能比較。 -l選項用于計數，盡可能快的發送該數量報文，然后恢復正常。該命令用于測試處理泛洪的能力，需要root權限執行。 -i選項用于用戶在兩個連續報文之間指定等待秒數。該命令對于將報文間隔開或用在腳本中非常有用。正常情況下，偶然的ping包對數據流的影響是很小的。但重復報文或報文泛洪影響就很大了。因此，使用以上選項時需謹慎。 -n選項將輸出限制為數字形式，這在碰見DNS問題時很有用。-v顯示更詳盡輸出，較少輸出為-q和-Q。 -s選項指定發送數據的大小。但如果設置的太小，小于8，則報文中就沒有空間留給時間戳了。設置報文大小能診斷有路徑MTU(Maximum Transmission Unit)設置或分段而導致的問題。如果不使用該選項，ping默認是64字節。 ## 參考 Network Troubleshooting Tools