其他分享
首页 > 其他分享> > Netvirt之流表分析(一):Netvirt介绍

Netvirt之流表分析(一):Netvirt介绍

作者:互联网

1. 架构

最近在看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