阿里云网络丢包问题查询
最近在阿里云上碰到一个奇怪的网络问题。
有一组机器在晚上凌晨0点30分开始就会不定时的大量丢包，然后到凌晨2点左右恢复。
但是在每周六周日都一切正常，没有任何问题。
由于这些都是nginx服务，而产生的现象就是那个时段会出现大量的502请求。
这个第一步考虑的是会不会是我们基于consul的脚本有bug，导致consul连接不到server的时候，把内存里upstream都给清空了。为什么会怀疑consul，只是这个时候我们看到consul日志里会有大量的connect timeout的日志，而且这个日志记录的时间点比出现502的时间要早。
而后经过详细的代码检查，排除了这种可能。
这些机器上也有lua代码会远程连接redis，于是排查可能是连接redis timeout后导致不继续后面的操作了。再次检查代码依然没有问题。
那看来就是阿里云网络的问题了。于是请求阿里云查看该服务器的所在物理机和对应的网络是否有异常，结果被告知一切正常。
让阿里云迁移该vm到其他物理机上，结果问题依旧。而且到了周末也依然没有问题。
这难道不是阿里云网络的问题，之前碰到类似的故障是某个客户半夜要对所有vm做snapshot，然后进行放到存储里备份，这期间把整个网络都给占满了。
可阿里云直接说了所有网络都正常，流量都正常。
只有最后一条路了，就是抓包了。
第一次抓了nginx上的包，发现502上有很多proxy pass的请求都没有收到回包，连续3次后导致nginx判定后端挂了，就从upstream里摘除了。
于是第二次除了nginx上抓包，后端也抓包，发现后端收到nginx proxy pass的包了，但是回去的包发现了很多的重传，有些都重传了5次。但是nginx一个包都没收到。
好了，我们能做的就只有这样了，为什么发包收不到我们也不知道了。接下来只能拉着阿里云的来一起抓包了。而且还提供了一些工具。
1 | 1.下载tcpping2脚本，链接： |
结果第一天让我们发现502了再通知他们抓包，然后就根本来不及，于是又浪费一天。
第二天就让他们在0点30分开始抓包，到我们发现502后通知他们停止就行。这次是抓到了，但是就抓了vif的，真正物理网卡居然由于命令写错了没抓到。
ecs1–vif–eth0————-eth0–vif–ecs2，vif抓包也确认是丢在了两个vif之间，最好能在eth0上抓下，就知道是丢在服务器还是中间交换机上了
抓到服务器物理网卡包，确认是丢在nginx侧的接入交换机到核心交换机这一段的物理网络上了。如昨天下午讨论，物理交换机上没办法抓包，比较难再进一步定位。我先找我们物理网络的同学再筛查一遍，筛查完后，我们再讨论下。
上面就是阿里云给的答案，我看这是要我们知难而退，这个问题他们搞不定。当中交换机上他们都抓不了包，可这个真要有心，镜像一下流量不就可以抓了。
只是以现在的网络情况，他们要抓起来会比较难，但是如果是我还是会抓下去的。不然这种隐患会一直存在的。
而且虽然这中间是7层网络，可不也是抓3~4次就可以查出来的。不过我们却不想这么搞了。
而现在所有证据都指向了阿里云的核心网络层，虽然我有问题，但是我没法处理。
我可以理解这个网络到底有多庞大，比如
因为为了冗余，所有连接必须是两条的，这里就不考虑bonding这样的情况了。光这个图我们就看到涉及到30台交换设备。但是通过2分查找应该就是4次的事情。
现在就把这个机器从slb里剔除掉了，然后坐等本周日会不会出问题。如果周一也出，那这个问题就比较搞笑了。