作者：Liping Mao 发表于：2014-07-04
版权声明：能够随意转载。转载时请务必以超链接形式标明文章原始出处和作者信息及本版权声明
在Openstack中L3router会造成流量集中的问题。不论东西向还是南北向的流量都须要流过网络节点的虚拟路由器。为了解决流量集中的问题，社区正在开打分布式虚拟路由器(DVR)的feature。
本文focus在DVR中东西向流量的处理流程。
南北向的处理不在本文范围内。
首先看一下东西向流量存在的问题。 一个用户创建了一个VRoute1(在Network Node上)和两个虚拟网络Net1、Net2，然后在两个网络中分别起了一个虚机，如果这两个虚机分别在Compute Node1和Compute Node2上。能够看到当VM1想要和VM2通信时。数据须要集中到Network Node，因而产生了东西向流量集中的问题。例如以下图所看到的：
为了解决问题引入了DVR，将东西向流量分布在各个计算节点上做到了真正的Multi-Host。
为了分析packet flow做下面如果：
1. VM1 和 VM2如上图所看到的。是属于Net1和Net2的两个虚机，他们分别在Compute Node1 和Compute Node2上。
2. Net1和Net2连接到了VRouter上。
3. Compute Node1和Compute Node2的连接方式是Vlan。
4. VM1和VM2使用fixed ip通信，不涉及floating ip。
5. 使用DVR时，会在每个计算节点上建立IR（Internal Router），如果连接Net1和Net2的接口是qr-net1和qr-net2。
拓扑例如以下图：
启用DVR须要在compute node上安装neutron-l3-agent。而且要打开DVR mode。同一时候须要改动neutron-openvswitch-agent为DVR mode：
就以从VM1发一个包到VM2为例分析东西向包的数据流。
包从VM1发出时。因为默认网关是qr-net1，就会发出下面格式的包：
当包流到br-int会转发到qr-net1,这样就进入了Compute Node1的Internal Router1。
在IR1中查找路由，发现目标地址是属于Net2。而在IR1的ARP表中有全部VM的Static ARP Entry。因此目标地址为VM2就会已经存在ARP Entry，不会发出ARP Request。ARP表是在neutron-l3-agent中维护的。
当有新增/删除虚机时，都会改动此ARP表。
包就会从qr-net2接口转发出。格式例如以下：
当包流入br-int后，会将其转发到br-eth0。br-eth0会将包的Vlan改为外部Vlan，同一时候通过openflow rule会将Source MAC改为一个唯一且与ComputeNode绑定的MAC地址。
这个唯一MAC地址是由DVR生成的。
同一时候在br-eth0上也有阻止对qr-net1和qr-net2的ARP请求的rule，这样就能保证本机的VM使用本机的Internal Router。
Notes:
为什么要这个与Compute Node绑定的唯一MAC呢？主要原因是每一个Compute Node上都有IR1。同一时候qr-net1和qr-net2接口IP地址和MAC地址都是同样的。
如果不改动Source MAC。那各个计算节点上的OVS以及外部物理交换机会从不同的port收到同样源MAC地址的包。这会造成交换机MAC地址表thrashing。
尽管即使使用了唯一MAC还是会出现不同Vlan id但MAC地址同样的情况，但这样的情况影响要小的多。
当包从Compute Node1上发出后，Phy Switch将其转发到Compute Node2。在br-eth0上将外部Vlan转为内部Vlan，之后转发到br-int，在br-int上会採用OpenVSwitch2.1的新feature，利用“Group Tables”将源MAC地址改动为qr-net2的MAC地址，并转发到Net2的全部port，VM2就能收到请求包了。
Openflow Rule 应该类似例如以下：
dl_vlan = net2LocalVlanID, nw_dst = net2IPRange, actions : strip_vlan, mod_dl_src = qr-net2 MAC, output->all the port in Net2
Refer:
https://blueprints.launchpad.net/neutron/+spec/neutron-ovs-dvr
https://review.openstack.org/#/q/topic:bp/neutron-ovs-dvr,n,z
Note:
本文计算节点之间进行vlan连接的，现在实际提交patch如果只支持vxlan。未来将支持vlan。