OVS故障处理一例

OVS下无法访问内部网站

遇到朋友求助的一个客户问题，环境是这样的，客户在自己的iaas平台（不是openstack）上使用ovs，物理交换机上配置vlan和dhcp service，计算节点的ovs上配置了虚拟vlan，当ovs port设置为trunk port模式后，vm就可以自动获取物理交换机dhcp分配的ip地址了，之后测试vm可以ping通公网目标地址，使用过程中发现个别公网地址的80/443服务无法访问，比如无法访问百度，(如图所示，https点击继续浏览按钮长时间没反应，http服务也是打开超时) 。朋友尝试在ovs上取消vlan，并把与计算节点相连的物理交换机对应的端口设置为access模式后，现象消失。

无法访问的现象如图所示：



点击继续浏览此网站，网站没有响应

朋友认为是防火墙或者OVS的问题，求助我协助分析。下面是整个处理的过程的记录。

抓包分析

如上图所示，应用wireshark数据包分析工具，根据朋友的描述设置过滤条件，核实数据包存在丢失的情况，因丢包直接导致了reset的发生。

去掉过滤条件，查看完整的信息发现一些正常的访问出现了比较多的PDU重置的情况，如下图所示：

于是让朋友在ping的时候加上-l 参数，ping -l 2048 -f www.baidu.com, 结果发现无法ping通，而调整到

ping -l 1499 -f www.baidu.com 后才可以ping通。

至此，问题已经开始明朗。

问题排查

检查虚拟网卡接口信息，核实mtu的配置为默认值1500，看似没有问题。

不管怎么说，问题应该和MTU的协商和配置有关，于是朋友在vm上执行下列命令：

sudo ifconfig eth0 mtu 1492

再次测试访问百度成功，至此问题就这样解决了。

看似是一个简单问题，里面一定藏有玄机，一般情况都不需要我们去改动MTU默认值的。通过查阅资料，我就这个问题做下总结。首先，这是既GRE存在MTU相关问题之后，迄今为止发现的又一个OVS在MTU方面的问题。这一次发生在是ovs vlan trunk port设置上。

如果你对GRE相关问题不了解，可以参考：http://blog.csdn.net/lynn_kong/article/details/9140659

下面这个链接解释的更加清楚，访问时可能需要翻墙

http://techbackground.blogspot.co.uk/2013/06/path-mtu-discovery-and-gre.html

在OVS1.9版本提到并已经改进了这个问题，但经证实发现仍然要配置MTU的值，具体可以参考：

http://openvswitch.org/releases/NEWS-1.9.0

• Tunnel Path MTU Discovery.
  
  对于Quantum插件OVS这意味着，超过MTU的物理接口上的数据包，现在将得到碎片，ICMP将不予退还给发件人。您可能仍然要配置的MTU值（在实例或节点），以防止该IP碎片，因为它降低了整体的性能，它造成了很多小的额外的数据包的开销。

总结：

遇到此类问题，可以通过traceroute --mtu （具体命令可以参考文档结尾的附件）检查中间设备，通过wireshark抓包分析，也就是验证和探索吧。

具体机制肯定是ovs和tracepath中的某设备在自动协商方面都做了限定有关，双方都坚持让对方重传，没有任何一方让步的结果。谁对谁错暂且不说，不过胳膊拧不过大腿，Ovs在这方面还需要做出改进。该问题已经影响到基本使用，由此也带来的性能上的问题。

最后的解决方案

以下是Openstack中的解决方法：

https://github.com/claenjoy/OpenStack-Grizzly-Install-Guide/commit/9ed25290ecd8466407c985aaad61eb0e098df8cd
+* Create new file /etc/quantum/dnsmasq.conf::
+
+   # reduce the MTU on the new instances to 1454
+   dhcp-option-force=26,1454
+   log-facility = /var/log/quantum/dnsmasq.log
+   log-dhcp
+
+   # Change file's owner
+   chown root:quantum /etc/quantum/dnsmasq.conf
+
+   #Add line to /etc/quantum/dhcp_agent.ini
+   dnsmasq_config_file = /etc/quantum/dnsmasq.conf
+
 * Make sure that your rabbitMQ IP in /etc/quantum/quantum.conf is set to the controller node::

    rabbit_host = 10.10.10.51

不同的IaaS平台都可以参照这个方法设置，至此问题解决分析完毕！后续将继续关注由此带来的性能方面的问题。

补充材料

通过traceroute可以检查每跳设备的mtu设置：

traceroute -n www.baidu.com -p 80 --mtu
traceroute to www.baidu.com (220.181.112.244), 30 hops max, 65000 byte packets
 1  192.168.1.1  3.740 ms F=1500  2.000 ms  23.781 ms
 2  218.241.252.157  32.011 ms F=1492  12.053 ms  5.484 ms
 3  218.241.252.149  7.705 ms  12.232 ms  10.914 ms
 4  202.99.1.153  8.830 ms 202.99.1.121  6.432 ms  7.449 ms
 5  172.16.98.133  13.663 ms  15.295 ms  10.729 ms
 6  106.38.215.13  12.791 ms  20.058 ms  8.631 ms
 7  * * *
 8  * * *
 9  220.181.17.94  6.918 ms 220.181.182.34  9.949 ms 220.181.17.94  8.589 ms
10  * * *
11  * * *
12  * * *
13  * * *

END