Netvirt之流表分析（一）：Netvirt介绍
作者：互联网
最近在看ODL的netvirt项目，netvirt是一个完整的网络虚拟机化解决方案，几乎可以实现neutron的所有功能，包括FWaaS，***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来实现的。
标签：之流,network,tunnel,报文,Netvirt,介绍,mac,Table,id 来源： https://blog.51cto.com/u_15127681/2823210