網卡驅動引發openstack的mtu問題

一套Pike版本的openstack測試環境，使用vlan模式的網絡，數據網網卡使用的是綠聯的usb百兆網卡，遇到了虛擬機網絡異常的問題。同一個vlan下，不一樣宿主機上的兩臺虛擬機，相互之間能夠ping通，可是不能ssh。

ICMP能通，說明鏈路沒有問題，ssh走的是ssh協議，不通的話，最多見時兩種狀況，一種是防火牆安全組禁用了ssh的端口，通過排查，發現不是這個問題。

另外一種狀況多是MTU設置錯誤的問題。
按照以太網早期的設計，鏈路層最大傳輸的數據的長度（MTU）最小46個字節，最大1500個字節（緣由能夠知乎搜索），若是傳輸的數據大小超過了1500個字節，要切分紅多分小於1500的數據再交給鏈路層。對應的，鏈路層設備接受到的幀大小的範圍時64-1518^注1 ，若是以太網上的設備，如網卡，交換機網卡接收到的幀大小超過了1518^注2，默認會直接丟棄這樣的數據幀^注3 。

有的時候網絡通訊，就是由於上層協議沒有很好的根據mtu調整本身單次傳輸的數據大小，致使部分數據在傳輸過程當中丟失，網絡通訊故障。可是對於ssh，ssh使用的是tcp協議，這個按理不會出現，tcp通訊時，tcp連接的兩端會根據雙方以及整條線路上設備的最小mtu，協商出一個MSS，即tcp層每次傳輸的最大的數據，有的時候MTU設置的太大，會致使數據幀的長度超出限制，鏈接到某些網絡失敗。按理說，不管哪個設備的mtu設置錯誤，都不該該影響ssh。

可是仍是要試一試，如今虛擬機默認的mtu大小是1500，ssh不通，嘗試將mtu調整成1499，依舊不通，1498通了。這就很奇怪了，爲何鏈路層支持傳輸的最大數據少了2字節？當時還不知道這個數據網出口時綠聯的usb網卡，開始懷疑時不是vxlan相關的配置引發的bug，決定經過抓包來定位問題設備。

vlan 模式下不一樣宿主機上的虛擬機通訊邏輯比較簡單，以下圖所示：

灰色設備是ovs port，相似網線的做用，藍色是物理的或者虛擬的二層交換設備，橙色是物理的或者虛擬的網卡
嘗試從vm1執行ping -s 1471 192.168.11.106，而後再物理機02上抓包，發現再eth1上抓包，沒有問題，能夠抓獲得，在qvo上抓包，抓不到。這裏要確認，是eth1把收到的包丟掉了，仍是eth1把包交給qvo的過程當中，包丟失了。

在物理機2上執行下面的命令：

(openvswitch-vswitchd)[root@compute01 /]# ovs-dpctl show
system@ovs-system:
    lookups: hit:7589478 missed:410086 lost:0
    flows: 54
    masks: hit:62147619 total:10 hit/pkt:7.77
    port 0: ovs-system (internal)
    port 1: br-int (internal)
    port 2: br-tun (internal)
    port 3: eth1
    port 4: br-data (internal)
    port 5: qvo34b16ff1-bb
    port 6: qvoe6366126-d8


(openvswitch-vswitchd)[root@compute01 /]# ovs-dpctl dump-flows | grep -r "6e:f2" 
recirc_id(0),in_port(3),eth(src=fa:16:3e:a9:6e:f2,dst=fa:16:3e:07:ee:2c),
eth_type(0x8100),vlan(vid=131,pcp=0),encap(eth_type(0x0800),ipv4(frag=no)),
packets:2122, bytes:3223318, used:0.726s,
actions:pop_vlan,6
recirc_id(0),in_port(6),eth(src=fa:16:3e:07:ee:2c,dst=fa:16:3e:a9:6e:f2),
eth_type(0x0800),ipv4(frag=no), packets:1046, bytes:1582598, used:0.726s,
actions:push_vlan(vid=131,pcp=0),3

能夠看到，從port3(eth1)進入的icmp包，被ovs刪掉vlan id後交給port 6(qvoe6366126-d8)了, 可是咱們在qvo上抓包卻抓不到，說明qvo把eth1交給他的包丟掉了。
使用tcpdump -i eth1 icmp -w packages.cap 把eth4上的包保存到packages.cap中，在wireshark中打開，能夠看到下面的內容：

仔細觀察圖中，咱們發現，抓到的數據包的大小是1519字節，超過了1518字節的限制，這就是qvo丟棄他的緣由吧。可是咱們ping使用的是1471個字節的數據，加速8字節的icmp首部，20字節ip頭部，6字節鏈路層源地址，6字節目的地址，2字節幀類型，4字節vlan信息，應該只有1517字節，不超過限制纔對。多出來的2字節哪裏來的？仔細觀察，發現多出來的兩字節在幀的末尾，被wireshark解析爲：vssmonitoring Ethernet trailer。在qvo上抓包，發現抓到的包裏面的內容不包括這部分數據，說明是包數據從qvo到eth1的途徑中被加了這兩個額外字節。可是爲何會有這兩個字節額外字節？使用vssmonitoring + openstack在google上搜索，發現了一篇叫openstack network mystery的文章，做者遇到了同樣的問題，做者的解釋是：

Finally, we’ve found the 2 additional bytes! But, where do they come from? Google tells us that this can be caused by the padding of packets at the network-driver level. I reconsidered my setup and identified the USB network adapter as the weakest link. To be honest, I suspected this might be the issue from the beginning, but I never imagined it would catch up with me in this way

.
I downloaded and built the latest version of the driver and replaced the kernel module. Lo and behold, all my networking problems were gone! Pings of arbitrary payload sizes, SSH sessions, and file transfers all suddenly worked. In the end, my networking issues were caused by an issue with the driver that ships by default with the Linux kernel.

做者說是由於他的usb 網卡驅動的問題，咱們使用的也是一個usb網卡，那問題看來是同樣的了，去綠聯官網下載最新的驅動，更新到咱們的環境中，確實解決了咱們的問題。