虚拟化的网络丢包

　　今天同事说有个问题弄了很长时间没有找出原因让帮忙看下，问题最后得以解决；现在来记录一下当时分析处理的过程！

问题：客户端使用http 去下载视频发现下载很慢， 但是去掉网络传输路径中的节点A， 下载速度就很快恢复正常

目前有客户端 以及 节点A的内部抓包的结果，节点A内部是设置的转发模式；

网络拓扑大约是： client-----【eth1 节点A  eth2】--------server，  节点A eth1 eth2 口是bypass的模式， 驱动从eth1口收到报文就转发到eth2 不走协议栈， 从eth2 收到包就转发到eth1

首先分析报文：

 

 

 上述抓包结果是在节点A的eth1 eth2 两口上同时抓的server到client的包，所以会看到同样的报文有两份

 

 

 上述报文时在client上抓取的报文，由于环境中存在nat，所以 ip 会有所不同，但是client 和server 段的报文特征不会变

分析上述两份报文可以得出如下结论：

client：

可以看到三次握手结果为：mss=1460  窗口/窗口滑动因子为：  64240/14600--------256 /128 开启sack功能

同时 server 到client 存在丢包重传；丢包重传需要具体看下，这个和节点a抓包对比可以分析出大概丢包实在哪里产生！！

可以看到：server 传给client报文 seq为从1--3841   17921---290481，当收到17921 序列号时， client开始出发sack，最后server 开始重传3841 到17921之间的报文，同时在重传的过程中也出现丢包，最后出现client 给server 的ack 报文中sack 出现了两份 SLE SRE报文

server：server 传给client报文 seq为从1--1281；发送1281---1281+1946段 后续也重传1281---1281+1280 段    发送12801 --12801+1946后续也发生重传 ；

现在 对比报文结果分析：

　　首先节点A抓到12801--12801+1946的报文， 然后发送出去了，但是在client段重传前没有看到这个报文， client只看到了1--3841   17921---290481这两段报文，

所以可以认为 节点A 到client 这段路径导致丢包出现重传！！

在对比12801 这个seq 报文， 节点A 出现了重传， 此时len长度为1946 但是client 没有出现，直接抓到报文，此时len为1280

　　所以更加坚定了认为 节点A到client 出现丢包导致整体重传！！

在对比节点A 重传的序列号！ 对比分析其报文特征，发现重传报文大小都为大包，超过传统的mtu1514， 所以认为是节点A 到client 大包出现丢包导致！

由于此时节点A 的两个端口eth1 eth2 是转发模式，接口发送大包的时候 ，会直接走驱动发包不会走协议栈，

那如果使用代理模式应该就不会丢包了，但是最先反馈的是 代理模式也会存在你丢包！！

所以问题存在点为：节点A对处理大包存在问题，以及 直接发送大包存在问题，因为经过协议栈发送大包，IP层会分片处理！！

这是分析报文后的结果！！

问题处理

接收问题后

• 弄清楚网络拓扑
• 找到一个有问题的ip节点分析

其网络拓扑大约如下：

client-----宿主机eth0------ovs149-----【eth2 节点A eth1】----ovs148---eth0-----server

也就是此节点A 对外是一个旁路模式处理报文

　　此时主要抓取server回复client的报文，对ovs148 的out eth2的out   ovs149 in 方向 抓包分析处理

发现报文正常 ，三个位置报文对比为一样的结果！！

抓取 eth0 in 方向  client ip dst 报文 以及 eth0 out 方向 client ip dst的报文对比

发现 eth0  能看到入口报文，其中报文和 在ovs148 ovs149接口上一样，有小包、大包巨帧报文，但是巨帧 都存在重传

在eth0 出口方向没有抓到大包报文！

所以问题出现在ovs 和宿主机上！！

但是有个问题： 由于tcp协商的时候使用mss 为1460，结果还是出现了巨帧，宿主机物理网卡mtu也为1460 这就比较奇怪了；

这个巨帧 怎么出来的呢？

由于tcp 协商mss 是1460，难道是物理网卡搞得鬼， 要证明是不是物理网卡搞得鬼，可以直接镜像物理网卡eth0 连接交换机port 抓包分析，

但是太麻烦， 从mss以及eth0 mtu 上分析， 认为交换机发出的包应该是mtu max为1514的包，所以原因可能是物理网卡搞得鬼；

使用ethtool -k 发现接口开启了gro 功能， 关闭gro 后，抓包分析都是mtu小于1514的报文，且没有出现重传，client 下载也很快；

此时问题得以解决！！

还有个疑问：此时节点A 执行代理模式 发包时mtu max 肯定是1514 但是还是丢包，目前认为结果是：代理模式下节点A tcpdump 能抓到大包， 但是实在链路层，肯能在协议栈的时候被丢弃

；导致节点A 处理报文失败， 同时分析节点A 代理应用层报文，发现也没有代理节点log 以及代理的socket。

所以主要是大包问题！

目前来看这个问题分析也比较简单，只需要对每个报文进行分析即可！！

注意每个报文的细节，理清楚为什么会出现这个报文，

然后根据现场已知条件 分析存在的可能性 然后按照可能性概率大小排除；也就是合理假设 求证

PS：处理问题时要注意细节， 细节串联起来就是一个证据链，能给人意想不到的惊喜