在互联网中，不同地区的IDC机房间网络时常会出现丢包的情况。特别是多链路负载的某一条链路出问题更是家常便饭。由于这种情况下丢包率不是很高，对于一般用户来说基本无感，但对于直播用的CDN来说，将是非常致命的。
以下是之前工作中常用的一些排查方法
命令1：ping 用于探测两端设备间的丢包率
ping -c400 -f -i0.01 -s 1024 idc1.too2.net
参数：
-c 发送的icmp数据包数量
-f 快速ping
-i 发包间隔，单位为秒
-s 发送的数据包大小，单位字节
注：ping 要通的话，必须是双向都通。所以一般情况下在服务器A上ping服务器B丢包，那么在B服务器上ping服务器A也会丢包。
命令2：traceroute用于探测到达目的ip所经过的每一跳设备ip及延迟
traceroute -n idc1.too2.net
参数：
-n 不将每跳ip反解析成域名
命令3：mtr用于探测到达目的ip所经过的每一跳的丢包率及延迟。
mtr -c 400 -n -i0.1 idc1.too2.net
参数：
-c 发送的icmp数据包数量
-i 发包间隔，单位为秒
-n 不将每跳ip反解析成域名
注：一般情况下，服务器可以完全响应大包，并且间隔0.01秒也没问题，但很多路由器/交换机 则不会完全响应。所以，ping服务器时可以用0.01秒的间隔,并且是1024字节的大包来测，而mtr是测试每一跳的路由器的，所以间隔用0.1秒，包大小也不加参数用默认的（64字节）。
命令4：tcpdump用于抓包，能帮忙我们确定丢包的方向
tcpdump -ni any icmp
参数：
-n 不将每跳ip反解析成域名
-i 指定抓包端口
例子：idc1 ping idc2丢包，那么执行以下步骤:
1.在idc2上执行命令 tcpdump -ni any icmp | grep "length 1008"
2.在idc1上执行命令 ping -c200 -f -i0.01 -s 1000 idc2.too2.net 如果有丢包，则执行第三步，如果没有，则需要重试。
3.在idc2上执行ctrl+c 结束抓包。
4.在idc2上查看抓到的数据包数量是否正确，如果抓到了400条记录，那表示从idc1->idc2方向没丢包，而丢包是在反方向。（注：上面-c200参数表示发送200个包，但由于t02001的服务器要回icmp relpy，所以会抓到两倍的数据包，数据包的统计可以自己想办法，比如复制到excel中，看行数；或者重定向到文件再wc -l计算行数等）
注：上面之所以用-s 1000而不是1024，是因为我们的监控系统本身也是用1024去做监控的，所以这里改成1000来避免干扰。而抓包用1008是因为抓到的数据包加上了8字节的icmp报文头部。
定位步骤：
从邮件或监控图上看，得出故障是个别服务器间还是区域间，甚至是整个机房到所有其它地方都有问题，来判断故障点的大概位置。
1.到所有其它地方都丢包。机房问题，一般比较容易定位。
2.到某些区域丢包，一般是骨干网有问题。
3.个别服务器间丢包，也没有明显规律。这种一般比较难排，往往需要通过抓包分析丢包方向。再让机房细查。
有的路由器/交换机不一定会完全影响icmp探测，所以即使有丢包也不能断定就一定有问题。但如果到某一跳丢包率一直为0，那我们可以判断至少到这一跳所经过的设备都是正常的。
比如下面例子：
mtr -n -c400 -i0.1 -r idc2.too2.net
HOST: idc1 Loss% Snt Last Avg Best Wrst StDev
1. ??? 100.0 400 0.0 0.0 0.0 0.0 0.0
2. 192.168.1.105 14.0% 400 932.7 682.8 1.3 1489. 527.4
3. 220.186.222.17 0.0% 400 20.9 4.3 0.2 64.2 12.0
4. 220.186.223.29 28.2% 400 13.6 10.3 6.6 100.5 9.4
5. 61.164.22.158 60.2% 400 20.3 10.5 7.2 20.3 2.2
6. 61.164.19.90 0.0% 400 12.9 12.6 10.4 35.1 1.6
7. 218.75.67.122 49.0% 400 14.1 17.0 12.4 105.3 10.1
8. ??? 100.0 400 0.0 0.0 0.0 0.0 0.0
9. 123.131.5.180 2.0% 400 12.1 11.5 10.8 12.4 0.5
虽然在前5跳有的设备有丢包，但第6跳没丢包，所以我们可以判断从idc1到第6跳（61.164.19.90）之间所经过的链路是没丢包的。
而最后到服务器的丢包率是2.0%，这种情况下如果我们把这个mtr的图发给idc1机房处理，他们有时会说是“到第6跳都没问题，所以是对端机房的问题”。实际上以我们以往的经验看，很多情况下也并非如此。因为有可能是正向不丢包，而反向丢包。为了判断是哪个方向丢包，可以用上面说的方法进行抓包分析。然后只要分析丢包方向的mtr即可。
此前出现过几次单向的traceroute到了倒数第二跳（即我们的交换机）都没问题，但到我们的服务器则完全丢包的情况。这种情况报给机房时机房往往就会说是我们交换机的原因了。实际上这种情况下基本都是由于反方向的丢包（比如反方向的包在互联网中环路）导致的。
有时会出现ping丢包，而mtr不丢包的情况（这种情况主要是因为我们ping时用大包1024，间隔0.01s，而mtr则用默认的小包，并且间隔是0.1s，这种情况下如果无法定位的话可以适当提高包大小或间隔，比如将包大小改为512之类的）
多线机房解析问题、路由问题
正常情况下，服务器A ping 服务器B 丢包，那么同时服务器B ping 服务器A 也会丢包。但有时多线机房会出现不一样的情况。此时可以通过查看两向走的线路是否一致来解决。
原文出自:
http://blog.too2.net/?p=283
转载请注明转自:辛碌力成【http://blog.too2.net】
发表评论