用ping ，mtr ，traceroute 進行網路丟包分析
用ping ，mtr ，traceroute 進行網路丟包分析
一、丟包原因
網路丟包原因很多，但是一般都是鏈路問題：
骨幹擁塞
鏈路某個交換機背板壞了
交換機負載不均導致
此外，還有主機本身原因：
系統CPU負載高，資料包到網絡卡後CPU不能及時處理，但是緩衝區溢位，從而丟包。
網絡卡故障
丟包時一般先分析下網路層面的，主機本身的還是原因較少的
2.2 分析方法
一般對丟包IP之間做ping、mtr、traceroute測試，對於十分明顯的，可以很容易分析出丟包點在哪裡。但是對於故障現象不明顯的我們可以做以下測試：
1、抓包：從源IP ping 目的IP，然後在源端抓reply包，在目的端抓request包
b)如果目的端收到的request包為400，但是源端收到的reply包少於400，則重點關注從目的端到源端的mtr和traceroute圖
c) 如果我在對端抓包，抓不到任何資料包，這種情況一般是資料包在中間路徑就丟了。此時對比MTR分析，可以很明顯的看到路徑是不完整的或者是有迴路。
抓包小技巧：因為我們測試一般是在監控機測試，但是作為監控機，一定會收到大量的ICMP包，對抓包會造成影響。為了避免這種影響，我們可以為傳送的資料包指定伊特特殊的長度，比如1016。此時的表示式為：
2、路由對比
對比兩個IDC之間的丟包路由圖和不丟包的路由圖，檢視路徑是否一致（一般都會有明顯區別的），然後分析在哪個網段開始丟包。
3、路由逐跳ping
對於mtr或者traceroute的結果做一個逐跳ping測試，同時還需要對每一跳做一個traceroute，這是為了檢視逐跳ping路由和之前的mtr路徑是否一致，如果逐跳ping不丟包但是路由又不一致，這種結果是不能夠作為判斷的。如下：
[[email protected] ~]# mtr -c 400 -i 0.1 -n -r <公司IP，不方便公佈>
HOST: xxxx Loss% Snt Last Avg Best Wrst StDev
- <公司IP，不方便公佈> 0.0% 400 2.7 2.3 1.7 10.8 0.8
- <公司IP，不方便公佈> 0.0% 400 0.7 0.6 0.4 17.1 0.9
- 120.221.17.85 99.0% 400 1.0 1.0 0.9 1.0 0.1
- 211.137.196.233 67.2% 400 1.5 5.3 1.2 44.7 10.0
- 120.192.97.9 86.8% 400 6.0 5.8 5.6 7.0 0.2
- 221.183.12.205 0.0% 400 5.2 7.1 5.1 89.8 7.0
- 221.183.10.26 12.8% 400 38.2 38.7 28.3 127.0 9.2
- 221.183.23.170 9.8% 400 61.8 65.0 53.3 186.8 12.5
- 221.176.20.186 11.5% 400 51.9 53.4 40.0 123.6 11.9
- 183.203.27.218 10.5% 400 51.7 51.1 41.3 70.0 3.9
- 183.203.21.138 11.0% 399 63.1 62.2 50.9 76.7 3.2
- 221.180.20.170 13.0% 399 55.8 228.3 48.2 1004. 275.5
- ??? 100.0 399 0.0 0.0 0.0 0.0 0.0
- <公司IP，不方便公佈> 12.0% 399 60.9 62.6 53.4 74.8 3.8
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
看MTR，第7跳可能存在問題，但是我ping測時時不丟包，然後做traceroute圖對比，發現路由在第3跳已經發生了變化。因此這個逐跳ping無效。有的IDC經常做這種測試“忽悠人”，這時我們可以叫機房拿出測試路由對比圖。因為整個網路的傳輸鏈路很多，可能是某個鏈路的問題，一般很難查到，必須對比，以便配合運營商更快的解決問題。
[[email protected] ~]# traceroute -n <公司IP，不方便公佈>
traceroute to <公司IP，不方便公佈> (<公司IP，不方便公佈> ), 30 hops max, 60 byte packets
1 <公司IP，不方便公佈> 11.330 ms 11.774 ms 11.859 ms
2 <公司IP，不方便公佈> 0.551 ms 120.221.17.25 11.146 ms 120.221.17.253 0.793 ms
3 120.221.16.13 0.838 ms 223.99.224.25 0.897 ms 0.965 ms
4 211.137.196.233 27.478 ms * *
5 221.183.12.229 1.201 ms 221.183.12.61 0.683 ms 221.183.27.181 16.531 ms
6 <公司IP，不方便公佈> 39.187 ms 38.786 ms 45.546 ms
1
2
3
4
5
6
7
8
2.3
mtr報告各列含義
Loss% 表示在每一跳的丟包率
Snt 每個中間裝置收到的傳送的報的數目（上圖為400個包），MTR會同 時對所有中間節點發送ICMP包進行測試。
Last 最後一個數據包往返時間（ms）
Avg 資料包往返平均時間（ms）
Best 資料包往返最小時間（ms）
Wrst 資料包往返最大時間（ms）
StDev 標準偏差。如果標準偏差越高，說明資料包在這個節點上的延時越 不相同
1
2
3
4
5
6
7
MTR報告分析
對於MTR報告我們主要關注丟包率和延時。如果在Loss% 列有丟包，說明這一跳可能有問題。但是，ISP會人為的限制ICMP的速率，這也會導致丟包現象。
如何排除限速干擾了？我們只需要觀察丟包的下一跳或者後面幾跳是否有丟包率為0的情況，如果有，則說明是裝置本身的干擾。判定理由：如果中間路由某跳確實丟包，那麼後續節點肯定收不到預定的資料包數量了。因此在圖一我們可以看到，前5跳都是有丟包的，但是第6跳沒有丟包，因此可以認為之前5跳的丟包率的是由於裝置上的ICMP策略導致的。
注意：ICMP限制和丟包可能同時存在！如果在這種情況下中間節點全部是丟包的，那麼我們要用最低百分比來衡量。如下圖：
Paste_Image.png
第6跳丟包57%，但是後面幾跳的丟包率又下降了，第7跳相對於後續幾跳，丟包率也是偏高的，因此可以認為6、7跳不僅有丟包原因，還是有ICMP限速原因導致的。
對於MTR測試結果，一般首先看最後一跳，如果最後一跳有丟包，那麼這個分析才是有意義的。因此判斷是否丟包，丟在哪裡，看最後幾跳是最明顯的。
帶尺寸的圖片: 
居中的圖片: 
居中並且帶尺寸的圖片:
當然，我們為了讓使用者更加便捷，我們增加了圖片拖拽功能。
如何插入一段漂亮的程式碼片
去部落格設定頁面，選擇一款你喜歡的程式碼片高亮樣式，下面展示同樣高亮的 程式碼片.
// An highlighted block
var foo = 'bar';
生成一個適合你的列表
- 專案
- 專案
- 專案
- 專案
- 專案1
- 專案2
- 專案3
- 計劃任務
- 完成任務
建立一個表格
一個簡單的表格是這麼建立的：
| 專案 | Value |
|---|---|
| 電腦 | $1600 |
| 手機 | $12 |
| 導管 | $1 |
設定內容居中、居左、居右
使用:---------:居中
使用:----------居左
使用----------:居右
| 第一列 | 第二列 | 第三列 |
|---|---|---|
| 第一列文字居中 | 第二列文字居右 | 第三列文字居左 |
SmartyPants
SmartyPants將ASCII標點字元轉換為“智慧”印刷標點HTML實體。例如：
| TYPE | ASCII | HTML |
|---|---|---|
| Single backticks | 'Isn't this fun?' | ‘Isn’t this fun?’ |
| Quotes | "Isn't this fun?" | “Isn’t this fun?” |
| Dashes | -- is en-dash, --- is em-dash | – is en-dash, — is em-dash |
建立一個自定義列表
-
Markdown
- Text-to- HTML conversion tool Authors
- John
- Luke
如何建立一個註腳
一個具有註腳的文字。1
註釋也是必不可少的
Markdown將文字轉換為 HTML。
KaTeX數學公式
您可以使用渲染LaTeX數學表示式 KaTeX:
Gamma公式展示 Γ ( n ) = ( n − 1 ) ! ∀ n ∈ N \Gamma(n) = (n-1)!\quad\forall n\in\mathbb N Γ(n)=(n−1)!∀n∈N 是通過尤拉積分
Γ ( z ) = ∫ 0 ∞ t z − 1 e − t d t . \Gamma(z) = \int_0^\infty t^{z-1}e^{-t}dt\,. Γ(z)=∫0∞tz−1e−tdt.
你可以找到更多關於的資訊 LaTeX 數學表示式here.
新的甘特圖功能，豐富你的文章
- 關於 甘特圖 語法，參考 這兒,
UML 圖表
可以使用UML圖表進行渲染。 Mermaid. 例如下面產生的一個序列圖：
這將產生一個流程圖。:
- 關於 Mermaid 語法，參考 這兒,
FLowchart流程圖
我們依舊會支援flowchart的流程圖：
- 關於 Flowchart流程圖 語法，參考 這兒.
匯出與匯入
匯出
如果你想嘗試使用此編輯器, 你可以在此篇文章任意編輯。當你完成了一篇文章的寫作, 在上方工具欄找到 文章匯出 ，生成一個.md檔案或者.html檔案進行本地儲存。
匯入
如果你想載入一篇你寫過的.md檔案，在上方工具欄可以選擇匯入功能進行對應副檔名的檔案匯入，
繼續你的創作。
註腳的解釋 ↩︎