neutron vlan+ovs组网模式下的云主机网络数据流分析

本篇是上次的neutron配置项分析的一个延续，也是近几年的一个长期未了的心愿，之前看过OpenStack官方的networking guide，学习了一下理论上的数据流，但毕竟纸上得来终觉浅，必须要亲自调试、观察、验证一下才能真正有深入的理解，这篇文章就是为了这个目的来写的。

这是第一次分析neutron云主机网络数据流，因此挑选比较简单的vlan+ovs+物理网络设备方案，省的把自己搞晕，然后后面如有时间，再继续分析vxlan+ovs+overlay网络+物理网络方案。

环境

OpenStack mitaka（nova+neutron+glance+keystone）

neutron：server、openvswitch-agent、dhcp-agent（未使用l3-agent、metadata-agent），l2 mechanism_drivers配置的是openvswitch，2.6.1版本（未使用Linux bridge），安全组也基于openvswitch原生功能（已经在云主机上配置上下行全通安全组策略），type_drivers = vlan、tenant_network_types = vlan，物理网络都是VLAN模式，各个VLAN之间在物理交换机上配置了3层路由策略实现互通。

物理网络环境：办公区使用的是电信家庭宽带，无固定公网IP，无法做NAT，通过光猫拨号上网，服务器连接的物理交换机上联到光猫。物理服务器上的网卡em1、p5p2分别对应管理网和业务网，网桥br-int、br-p5p2通过patch port连接。

使用工具

tcpdump、ping

分析场景

同租户下同一台宿主机上的两台云主机（同网段、同VLAN、同物理机）

两台云主机ip分别为10.0.70.215、10.0.70.216。

这种场景非常简单，数据包直接在ovs bridge br-int内部交换即可，不需要经过物理网卡向外发包，两台云主机之间的带宽延时都非常低，网络性能主要依赖于物理机cpu能力和物理机负载情况。

在两台云主机的tap设备和物理网卡上抓包，发现只有tap设备有icmp数据包：

在云主机里ping网关10.0.70.1是可以在物理网卡上抓到包的：

 

同租户下不同宿主机上的两台云主机（同网段、同VLAN、不同物理机）

从物理机vs-compute-82上的云主机10.0.70.215 ping 物理机vs-compute-83上的云主机10.0.70.230。

两台云主机的tap设备就不抓包了，肯定有icmp数据包，这里只关注物理网卡p5p2：

可以看到两个物理机上的物理网卡都有icmp包经过（tap设备到br-int再到patch port再到br-p5p2最后从物理机82上出去，到物理机83上接收，转到br-p5p2，之后通过patch port转到br-int，最后到云主机tap设备）。其实一旦跨了物理机，就要经过物理交换机了，交换机那边我不熟悉，就不查看数据包流量了，同VLAN只需要进行二层交换即可。这种场景下两台云主机的网络带宽等性能更大程度上是受限于物理交换机的性能和负载。

不同租户下同一宿主机上的两台云主机（不同网段、不同VLAN、同物理机）

物理机为vs-controller，云主机在两个租户下，ip分别为10.0.80.38、10.0.70.32，使用不同的VLAN（ID分别为580和570），从10.0.80.38 ping 10.0.70.32。

两台云主机的tap设备都有icmp数据包，物理网卡p5p2也有，这种场景比上面的跨节点同网段多了一次三层路由过程，这个过程也是在物理交换机（路由器）上做的，因此整个过程类似从tap设备到br-int再到patch port再到br-p5p2再到物理网卡p5p2，之后到物理交换机（路由器）进行3层路由数据包（从VLAN 580到570），再从同一个物理网口返回物理机vs-controller的p5p2网卡，之后与发包过程反向进入另一台70段的云主机。

不同租户下同一宿主机上的两台云主机（不同网段、不同VLAN、不同物理机）

这个过程与上面的场景类似，不再分析，差异是到物理交换机（路由器）后是从另外一个网口出去到另外一台物理机的网卡。

租户私有网到公网

这个场景依赖物理交换机（路由器）配置好到私有网使用的VLAN的公网的出口网关和路由表，默认情况下，VLAN是无法连接到公网的。

整体过程与跨物理机的两台云主机之间通信类似，只不过云主机的数据包到物理交换机（路由器）之后，经过一次地址转换（SNAT）之后发送到公网网关（光猫），最终发到公网。

因为公司办公区机房没有公网IP，公网到云主机的网络流量就不分析了。