用ping ，mtr ，traceroute 进行 络丢包分析

用ping ，mtr ，traceroute 进行 络丢包分析
一、丢包原因
　　 络丢包原因很多，但是一般都是链路问题：

骨干拥塞

链路某个交换机背板坏了

交换机负载不均导致

此外，还有主机本身原因：

系统CPU负载高，数据包到 卡后CPU不能及时处理，但是缓冲区溢出，从而丢包。

卡故障
　　丢包时一般先分析下 络层面的，主机本身的还是原因较少的

2.2 分析方法
　　一般对丢包IP之间做ping、mtr、traceroute测试，对于十分明显的，可以很容易分析出丢包点在哪里。但是对于故障现象不明显的我们可以做以下测试：
1、抓包：从源IP ping 目的IP，然后在源端抓reply包，在目的端抓request包
　　a)如果目的端抓到的request包少于400（目的端收到的请求包少于400，源端收到的reply包肯定少于400），则重点关注源端到目的端的mtr和traceroute图
　　b)如果目的端收到的request包为400，但是源端收到的reply包少于400，则重点关注从目的端到源端的mtr和traceroute图
　　c) 如果我在对端抓包，抓不到任何数据包，这种情况一般是数据包在中间路径就丢了。此时对比MTR分析，可以很明显的看到路径是不完整的或者是有回路。
　　抓包小技巧：因为我们测试一般是在监控机测试，但是作为监控机，一定会收到大量的ICMP包，对抓包会造成影响。为了避免这种影响，我们可以为发送的数据包指定伊特特殊的长度，比如1016。此时的表达式为：

2、路由对比

对比两个IDC之间的丢包路由图和不丢包的路由图，查看路径是否一致（一般都会有明显区别的），然后分析在哪个 段开始丢包。

3、路由逐跳ping
　　对于mtr或者traceroute的结果做一个逐跳ping测试，同时还需要对每一跳做一个traceroute，这是为了查看逐跳ping路由和之前的mtr路径是否一致，如果逐跳ping不丢包但是路由又不一致，这种结果是不能够作为判断的。如下：

[root@xxxx ~]# mtr -c 400 -i 0.1 -n -r <公司IP，不方便公布>
HOST: xxxx Loss% Snt Last Avg Best Wrst StDev

1. <公司IP，不方便公布> 0.0% 400 2.7 2.3 1.7 10.8 0.8
2. <公司IP，不方便公布> 0.0% 400 0.7 0.6 0.4 17.1 0.9
3. 120.221.17.85 99.0% 400 1.0 1.0 0.9 1.0 0.1
4. 211.137.196.233 67.2% 400 1.5 5.3 1.2 44.7 10.0
5. 120.192.97.9 86.8% 400 6.0 5.8 5.6 7.0 0.2
6. 221.183.12.205 0.0% 400 5.2 7.1 5.1 89.8 7.0
7. 221.183.10.26 12.8% 400 38.2 38.7 28.3 127.0 9.2
8. 221.183.23.170 9.8% 400 61.8 65.0 53.3 186.8 12.5
9. 221.176.20.186 11.5% 400 51.9 53.4 40.0 123.6 11.9
10. 183.203.27.218 10.5% 400 51.7 51.1 41.3 70.0 3.9
11. 183.203.21.138 11.0% 399 63.1 62.2 50.9 76.7 3.2
12. 221.180.20.170 13.0% 399 55.8 228.3 48.2 1004. 275.5
13. 00.0 399 0.0 0.0 0.0 0.0 0.0
14. <公司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经常做这种测试“忽悠人”，这时我们可以叫机房拿出测试路由对比图。因为整个 络的传输链路很多，可能是某个链路的问题，一般很难查到，必须对比，以便配合运营商更快的解决问题。
    [root@xxx ~]# 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测试结果，一般首先看最后一跳，如果最后一跳有丢包，那么这个分析才是有意义的。因此判断是否丢包，丢在哪里，看最后几跳是最明显的。

带尺寸的图片:

居中并且带尺寸的图片:

当然，我们为了让用户更加便捷，我们增加了图片拖拽功能。

如何插入一段漂亮的代码片

去博客设置页面，选择一款你喜欢的代码片高亮样式，下面展示同样高亮的 .

生成一个适合你的列表

• 项目
  • 项目
    • 项目

1. 项目1
2. 项目2
3. 项目3

• 计划任务
• 完成任务

创建一个表格

一个简单的表格是这么创建的：

设定内容居中、居左、居右

使用居中
使用居左
使用居右

SmartyPants

SmartyPants将ASCII标点字符转换为“智能”印刷标点HTML实体。例如：

创建一个自定义列表

Markdown

Text-to- HTML conversion tool

Authors

John

Luke

如何创建一个注脚

一个具有注脚的文本。¹

注释也是必不可少的

Markdown将文本转换为 HTML。

KaTeX数学公式

您可以使用渲染LaTeX数学表达式 KaTeX:

Gamma公式展示 Γ ( n ) = ( n 1 ) ! n ∈ N Gamma(n) = (n-1)!quadforall ninmathbb N Γ(n)=(n/span>1)!/span>n∈N 是通过欧拉积分

Γ ( z ) = ∫ 0 ∞ t z 1 e t d t . Gamma(z) = int_0^infty t^{z-1}e^{-t}dt,. Γ(z)=∫0∞/span>tz/span>1e/span>tdt.

你可以找到更多关于的信息 LaTeX 数学表达式here.

新的甘特图功能，丰富你的文章

• 关于 甘特图 语法，参考 这儿,

UML 图表

可以使用UML图表进行渲染。 Mermaid. 例如下面产生的一个序列图：