Netvirt之流表分析（一）：Netvirt介绍

1. 架构

最近在看ODL的netvirt项目，netvirt是一个完整的网络虚拟机化解决方案，几乎可以实现neutron的所有功能，包括FWaaS，V**aaS，LBaaS，控制面有ODL实现，转发面由OVS实现。

netvirt由netvirtneutronnorthbound plugin，OVSDBSouthbound Plugin，OpenFlowSouthbound Plugin与HWVTEP Southbound Plugin（需要OVS2.6支持）组成。netvirt可以通过ovsdb管理协议控制虚拟设备与硬件设备，HEVTEP通过ovs的hardwarevtepschema配置硬件TEP。

图1 netvirt实现框架

今天我们分析netvirt是怎么通过ovs 来实现L2/L3 Forwarding, Floatingip, Security Group, LBaaS。

2. Pipeline

图 2 pipeline

1.Table 0: Classifier

包首先会进入这个table做classifier，将包区分为3种类型：本地发出的包，其他节点发来的包和上送controller的包

1）匹配本地发出的包

根据包的in_port与虚拟机mac或是dhcp mac来识别包是否来自于本地，并添加tunnel id，注意这里只匹配mac地址与入端口，没有ip地址。如果发送不期望source_mac那么将被丢弃，实现类似ARP Snooping的功能。

对于来自于本地的包，除了添加tunnel外，还需要配置reg0，这是一个metadata一直存直到离开bridge，对于来自于本地的包reg0=1，来自于其他host的包reg0=2。

注意：当前netvirt仅支持tunnel，不支持vlan type。

2）匹配来自其他node的包

根据包中携带的tunnel id与in_port（tunnel port）识别来自于其他node的包，配置reg0=2。

3）packetin：

当前仅将lldp报文上送到controller，由topology manager plugin处理，对于arp与dhcp不做特殊处理。

2.Table 20: DistributedARPResponde

这张表处理ARP request，利用ovs的arp responser回复arp replay。下图为实现原理：

图 3 arpresponser

这里会对以下几种类型的包回复ARP Reply

● 本节点的VM和DHCP 发送的arp 请求

● 远端节点VM和DHCP 发送的arp请求

● router interface

● floatingip

对于floatingip因为请求来自于外网，所以没有tunnel id，只能根据patch-ext来代替tunnel id来匹配外部流量。

3. Table 30 : inbound NAT

外部网络通过floatingip访问内部VM，当报文到达此table后，rewrite报文的floatingip为VM的internalip，同时将segmentation id写入reg3，在table60中，根据reg3与dst进行路由，并rewrite srcmac。

4. Table 40: Egress ACL

Egress Security Group Implementation

5. Table 50: LBaaS

利用ovs的mutipath action功能实现LBaaS。

6. Table 60: Distributed Virtual Routing

首先根据segmentation_id与destinationL3network来决定报文是否需要进行L3处理，路由时，根据目的子网，修改tunnel id和srcmac（mac of router inteface）, decrease TTL。

这张表里保存本地VM到达租户内所有网络的路由表项，组成一个full mesh架构，租户每创建一个子网，那么需要在租户vm所在的所有host上添加n*(n-1)条rule。不像neutron用户可以创建多个router，netvirt中一个租户只有一个vrouter。

此实现的优点是，对于东西向流量，只需查询一次即可到达目的，二是不需要经过controller性能也可以保证，但是对于复杂拓扑会带来流表的暴涨，管理，维护比较困难，如下图分别有2个子网，3个子网时，ovs流表配置如下：

2 Subnets: A, B

- A->B MATCH: from tun_id of subnet A, packet with dest network B

- B->A MATCH: from tun_id of subnet B, packet with dest network A

3 Subnets: A, B, C

- A->B MATCH: from tun_id of subnet A, packet with dest network B

- A->C MATCH: from tun_id of subnet A, packet with dest network C

- B->A MATCH: from tun_id of subnet B, packet with dest network A

- B->C MATCH: from tun_id of subnet B, packet with dest network C

- C->A MATCH: from tun_id of subnet C, packet with dest network A

- C->B MATCH: from tun_id of subnet C, packet with dest network B

7. Table 70: L3_Fwd

路由完成之后，下一步进行报文的封装，根据tunnel与dest ip配置destmac。

8. Table 80: Layer2 rewrite service

Layer2 rewrite service

9. Table 90: Ingress ACL

Ingress Security Group Implementation

10. Table 100 : outbound NAT

在这张表中需要处理两种类型的报文，一种是同子网的报文，一种是发送到external network的报文。

1）同子网报文

通过匹配dest network与segmention id，判断报文是发向同一个子网的报文，这时不做任何处理，直接转发到110号表

2）对于到external network的报文

需要根据segmention id，destination mac与source ip address识别出时发送外网的报文，然后将报文的src mac重写为floatingip的端口mac，destmac重写为external routergateway的端口mac，src ip重写为floatingip，然后从patch端口发送到br-ex。

这里我们用到了external routergateway的mac，但是这个mac，controller是不知道的，为了解决这问题，引入了Gateway ARP Resolver，controller会周期性的向external router gateway发送一个arp request，gateway会回复arg replay，controller根据arp replay解析出gateway 的mac，如果mac发生了变化，那么重新刷新相关流表。

在这里需要注意的是发送外网的flow的优先级为512，其比内网转发的flow优先级低，所以匹配时先match内网报文，如果不能match才进行nat处理。

11. Table 110: L2_fwd

L2_fwd为pipeline的最后一个table，负责处理L2报文，包括BUM与目的可知的单播报文。

1）BUM报文

根据{tunnel_id, reg0} 来识别报文方向，根据dl_dst识别是BUM报文，如果是reg0=1表明报文是从本地发送出去的，那么向所有端口（包括发送报文的本地端口）发送一份复制的报文，这样本地端口也会收到一份报文，这里有些疑惑。

2）目的可知的单播报文

根据{tunnel_id, reg0}查询vxlan table转发。

3 小结

我们看到所有报文（除了lldp）都直接通过ovs静态流表来处理的，并没有上送的controller。dhcp也是沿用了neutron的dhcp agent来实现的。