OpenStack Neutron DVR L2 Agent的初步解析 （一）

声明：

本博客欢迎转载，但请保留原作者信息!

作者：林凯

团队：华为杭州OpenStack团队

OpenStack Juno版本号已正式公布，这是这个开源云平台的10个版本号，在Juno版的Neutron模块中真正引入了分布式路由（DVR）的实现，如今就让我们来初步看下分布式路由是怎么样工作的。

分布式路由怎么工作？

为了实现分布式路由。L3和L2 agent将须要工作在计算节点内。

今天。L3 agent执行在网络节点。但DVR提议，L3agent会在计算节点上执行。L2 agent将继续工作在计算节点，而将工作在所谓的“DVR模式'，当中L2 agent将另外负责管理（加入/删除）一个增强模式OVS规则以实现分布式路由。

以下来说明怎样分布式路由完毕的拓扑实例：

在上图，一个PING请求从红色网络上的VM1中发送到在绿色网络上的VM2，这两个网络之间通过一个分布式路由器r1连接。

r1在CN1和CN2节点上有同样的IP地址和MAC地址。

我们能够看到，分布式路由器r1有两个接口，一个接口在红色网络的子网上，还有一个在绿色网络的子网上。

从VM1到VM2的PING ECHO请求数据流能够从上图1到6数据流看出。

1.从vm1中发出带有vm2 ip目的IP的数据流，首先发往红色网络的默认网关mac即r1上红色子网的接口的MAC地址（r1-red-mac）,整合网桥发送这些这个数据流给r1

2.DVR路由器r1的红色子网接口接受这个数据帧，然后路由这个数据帧。

3.路由之后。r1将这个数据帧发送到绿色子网的接口，这个数据帧被br-int交换到br-tun。而且打上绿色网络的本地vlantag。

4.在CN1的br-tun用他节点上唯一的DVR mac地址取代帧的源mac地址（一个唯一的dvr mac地址被控制器分配给每一个计算节点CN1和CN2是不一样的）。更改后的数据帧通过br-tun发送到CN2，在发送前他也去除了本地绿色vlantag，并打上隧道vni vxlan id。

5.CN2上br-tun收到这个隧道数据帧。去除绿色vni标签。然后加上本地绿色网络vlan tag，然后发送这个帧到br-int。

6.CN2上的br-int识别到数据帧的源mac地址是一个独特的DVR mac地址（每一个计算节点的l2-agent知道全部dvr独有的mac地址）。之后将这个mac地址替换成绿色子网的mac地址，然后发送这个数据帧给vm2.

从vm2发送ping response给vm1，和上述的过程是一样的。

正如你可能已经注意到。在帧的源节点的DVR路由路由这些数据帧，他们仅仅是被发送到正确的目的地。对于全部的路由的帧。帧的源节点的DVR唯一的MAC地址被用在底层，作为该帧的源MAC地址（即内部帧）。

VM2的ARP表项将被预填充在CN1上的DVR路由器R1。由CN1上的L3-agent执行（通过从L3的插件提供的信息）。相同，对于VM1的ARP表项将由CN1上的L3-agent执行（通过从L3的插件提供的信息）预填充在CN2上的DVR的路由器R1。

CN1上流规则

br-int的规则：

br-tun的规则

CN2上的流规则：

br-int的规则：

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvY2FueGluZ2hlbg==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">

br-tun的规则：

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvY2FueGluZ2hlbg==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">

当执行在DVR模式下。全部这些红色表示的表和规则都是新增的，将通过二级代理进行额外的管理。

这些规则的简明说明例如以下：

a.通过租户的虚拟机生成的ARP广播请求在云广播到全部其它CN。可是，假设是ARP请求帧的目标是默认网关的IP（路由器IP子网）。那么这种帧被本地的br-tun所丢弃。由于这种ARP须要。并将仅仅被本地有效的DVR实例所服务。

Tunnel bridge

DVR PROCESS Table 1 (New table for dvr):

table=1, priority=4, dl_vlan= red1-L-vlan, dl_type=arp,ar_tpa= r1-red-ip actions: drop

table=1, priority=4, dl_vlan= grn1-L-vlan, dl_type=arp,ar_tpa= r1-grn-ip actions: drop

b.由分布式路由器接口port产生的全部请求，无论是ARP请求时，其他广播（或）单播数据包。将被发送至云中。可是，全部的这些帧被觉得是“DVR路由帧”。因此这种帧将搭载在该帧的源MAC地址的“本地唯一的DVRMACADDRESS”被转发到云中。

将本地的路由接口的mac地址转换为本地唯一的dvr mac address在 DVR PROCESStable完毕，例如以下演示样例：

Tunnel bridge

DVR PROCESS Table 1 (New table for dvr):

table=1, priority=1, dl_vlan=red2_L_vlan,dl_src=r1-red-mac, actions: mod_dl_src=dvr-cn1-mac, resubmit(,2)

table=1, priority=1, dl_vlan=grn2_L_vlan,dl_src=r1-grn-mac, actions: mod_dl_src=dvr-cn1-mac, resubmit (,2)

c.补充b点，在DVR的路由通过计算节点接收到的帧，目的节点上的br-int将去除上面加入的“唯一的DVR的MAC地址”。相同，br-int将代替本地DVR实样例网接口的MAC地址，再把该帧转发到本地目的地的虚拟机。这是通过br-int中的新的表1完毕。比如在CN2：

Integration Bridge Rules

Table 0: (Local switching table)、

table=0, priority=2, in_port=patch-tun, dl_src=dvr-cn1-macactions: goto table 1

table=0, priority=1, actions: output->NORMAL Table 1:(DVR_TO_LOCALMAC table)

table=1, priority=2, dl_vlan=grn2-L-vlan,nw_dst=grn-subnet actions: strip_vlan,mod_dl_src=r1-grn-MAC,output->port-vm2

table=1, priority=1 actions: drop

d.发往本地dvr子网的接口mac地址的数据包在原始计算节点的br-tun中丢弃。由于它们假设转发到云中。将在这个包被云中其它节点解码时。创建mac发生歧义。这是通过以下的规则：

Tunnel bridge

DVR PROCESS Table 1 (New table for dvr):

table=1, priority=2, dl_vlan=red2_L_vlan,dl_dst=r1-red-mac, actions: drop

table=1, priority=2 , dl_vlan=grn2_L_vlan,dl_dst=r1-grn-mac, actions: drop

e.为了防止多个单播的路由数据包同一时候发往云中的全部计算节点的远程虚拟机。12的预填充技术被用来在计算节点预先填充FDB表中。仅仅对正确的单目的地计算节点发送帧。

f.对于br-int上的这些规则，当中一长串的端口都可能会出现“输出口”行动规则。该文件建议使用可从2.1OpenVswitch（OVS）版本号的“组表Group Tables”措施，将源MAC地址改动为qr-net2的MAC地址，并转发到Net2的全部port，VM2就能收到请求包了。

Integration bridge

Table 1: (DVR_TO_LOCALMAC table)

table=1, priority=2, dl_vlan=grn2-L-vlan,nw_dst=grn-subnet actions: strip_vlan,mod_dl_src=r1-grn-MAC,output->port-vm2