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


声明：

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

作者：林凯

团队：华为杭州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的规则：

 

br-tun的规则：

 


当运行在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.由分布式路由器接口端口产生的所有请求，不管是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

 

 

 

 

 

 

 


相关内容