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
下面这个链接解释的更加清楚，访问时可能需要FQ
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