基于EVPN实现neutron的VxLan网络

1.EVPN简介

       EVPN全称是Ethernet VPN，它最开始由RFC7432定义，RFC的全称是：BGP MPLS-BasedEthernet VPN，从名字上看，这是一个基于BGP和MPLS的L2 VPN。EVPN架构是在现有的BGP VPLS（RFC4761）方案上，参考了BGP/MPLS L3 VPN（RFC4364）的架构提出的。我们知道SDN架构是控制数据分离，应用在控制层之上构建。对于EVPN来说，控制层是MP-BGP，而EVPN可以看成是构建在MP-BGP上的应用。MBGP有两个主要的工作，为路由指定特定网络层协议的下一跳和NLRI（网络层可达信息）。

所以EVPN不仅仅是一种技术和架构，它也有应用场景的定义。更具体的说，EVPN不仅定义了L2 VPN的一种改进方案，还定义了各个应用场景下的行为，像multi-homing，fast convergence，auto-discovery，MAC mobility等等，这些场景都非常有意思。随着EVPN技术的讨论，EVPN也被用来传递IP路由信息，作为VXLAN等overlay网络的控制层，用来作为数据中心互联的控制层等。

 

EVPN组网架构图

 

         OpenStack的neutron组网，一般是计算节点上部署OpenvSwitch做VTEP，通过 VxLan 跑数据平面。简单说下原理，首先我们基于OVS实现的VxLan隧道，由Neutron收集所有Agent来建立 VxLan隧道，然后 VTEP因为不知道其后的VIF的地址，所以只能依赖 Flood & learn来学习应该往哪个隧道转发。ARP广播也没有机制实现代理，所以效率和 BUM都成问题。总结一下：

l  基于Flood的VxLan效率低

l  基于软件实现的L2Gateway无法承担较大的workload

l  neutron Legacy架构的路由是中心化的

       本文所写的是基于EVPN的解决方案，其实核心思想主要是可达信息的互换，制定一个控制平面，具体可以看 RFC。基于spine-leaf的组网拓扑如下所示：

 

数据中心分布式组网图

 

         spine交换机做BGP路由反射器，leaf上移植了oslo的一些公共库，作为agent端,主要负责下发evpn配置，通过rpc与neutron-server进行通信。 控制节点上安装自己实现的Plugin，主要把ml2和L3的事件，通知到到agent上。

2. EVPN-Plugin

实现自己的Plugin：

         网络层面上，主要实现功能利用 Ml2的分层绑定机制来配置交换机和OVS ；

         路由层面上，实现VRF的分配机制，并将VRF分配情况记录在数据库中。

         Plugin要检测交换机上L2agent的report state报文，并记录在数据库中。

如果想利用交换机的EVPN特性，那首先必须知道组网拓扑。

2.1 收集组网拓扑

         利用LLDP链路发现协议收集邻居拓扑，然后记录到数据库里面。对于分布式组网，这儿有两种方式，一种是交换机侧去收集邻居拓扑并通过RPC，上报给neutron，然后再记录在数据库。另外一种是服务器直接收集邻居信息，直接记录在数据库里面。

         我们在交换机上扩展了LLDP，支持私有信息，出于其他功能的考虑，比如监控整个组网拓扑，而不是简单的获取openstack的节点的邻居拓扑，我们实际上是在leaf交换机收集邻居信息，然后把邻居拓扑信息上报给neutron。

         因为在组网里面，不管有leaf，服务器，还有spine。spine的作用是实现bgp的反射器，来控制建立vxlan的tunnel。我们在LLDP报文里面携带了设备角色的私有TLV，来区分上下行设备。然后由一台主spine的设备，依次去各个交换机上获取其邻居拓扑，然后计算出整个组网拓扑。

         服务器我们的EVPN-Plugin

2.2 实现自己的mechanism机制

         这儿为了避免修改源代码，实际上是复用的ml2分层绑定机制。

ML2分层端口绑定（ML2Hierarchical Port Binding）

         在OpenstackNeutron的liberty版本ML2机制driver已经支持分层网络拓扑，每一层级网络拓扑都有各自的网络segment id。例如一个机制driver可以绑定一个静态的网络VXLAN segment id值，因为与ToR交换机相连的计算节点需要动态的分配VLAN id，因此另一个机制driver，例如OVS，就可以绑定计算节点到需要的动态VLAN上。可参考

https://github.com/openstack/neutron-specs/blob/master/specs/kilo/ml2-hierarchical-port-binding.rst

                        +-------------+

                        |             |

                        | Core Switch |

                        |             |

                        +---+-----+---+

                VXLAN       |     |       VXLAN

                +-----------+     +------------+

                |                              |

         +------+-----+                 +------+-----+

         |            |                 |            |

         | ToR Switch |                 | ToR Switch |

         |            |                 |            |

         +---+---+----+                 +---+----+---+

     VLAN    |   |   VLAN           VLAN    |    |    VLAN

     +-------+   +----+                +----+    +------+

     |                |                |                |

+----+----+      +----+----+      +----+----+      +----+----+

|         |      |         |      |         |      |         |

| Compute |      | Compute |      | Compute |      | Compute |

| Node    |      | Node    |      | Node    |      | Node    |

|         |      |         |      |         |      |         |

+---------+      +---------+      +---------+      +---------+

 

         当ovs-agentbind_port时，kilo版本会查找driver依次绑定，M版本之后就不再支持。这儿可以先调用自己的mechaism机制，将vxlan ID下发到交换机上，然后设置continue_binding变量，继续将vlan ID绑定到ovs上。

3.Agent

         交换机上移植了agent的代码，同RPC与neutron-server进行通信。实现了vxlan集中式，vxan分布式和vlan组网结构，其中vxlan分布式组网应用最广。以vxlan分布式组网为例。

3.1 L2 agent

交换机leaf上实现l2 agent：

   1.当create-network时，下发vsi配置（vsi 虚拟交换实例），负责vtep,leaf之间建立tunnel

   2.当 network关联router时，会将vsi实例绑定到VRF（VPN Routing & Forwarding Instance）上。

分布式EVPN网关示意图

 

3.2 L3 agent

         利用VRF实现租户路由的隔离，L3agent的主要功能是：分配VRF，生成RD和配置RT，VRF可以解决不同租户里面地址重复的问题。

 

VRF：在一台PE上虚拟出来的一个路由器，包括一些特定的接口，一张路由表，一个路由协议，一个RD和一组RT规则。

RT：表明了一个VRF的路由喜好，通过他可以实现不同VRF之间的路由互通。他的本质就是BGP的community属性。

RD：为了防止一台PE接收到远端PE发来的不同VRF的相同路由时不知所措，而加在路由前面的特殊信息。在PE发布路由时加上，在远端PE接收到路由后放在本地路由表中，用来与后来接收到的路由进行比较。

4. underlay网络

4.1 获取配置文件

         交换机启动后，管理接口会自动获取DHCP报文。我们先来看下dhcp报文格式

这里我们通过DHCP-server上指定引导文件名, 然后交换机从DHCP报文中解析出文件名。通过tftp去tftp-server上获取对应的文件，比如spine获取spine的模板文件，leaf获取leaf对应的模板文件。

         模板文件上记录着基本的信息，比如使能lldp、配置telnet、netconf等等。用户也可以自行添加。

4.2 收集全局拓扑

         我们在交换机上扩展了LLDP，支持私有信息。我们在LLDP报文里面携带了设备角色的私有TLV，来区分上下行设备，即区分对端是spine、leaf或者其他角色。每台设备都维护着自己的邻居拓扑，然后由一台主spine的设备，依次去各个交换机上获取其邻居拓扑，最后计算出整个组网拓扑，称为全局拓扑。

4.3 主spine分配LoopBack地址

         当全局拓扑有新设备加入时，通过netconf为其分配LoopBack 0地址。当有邻居离开时，要回收其LoopBack 0地址。

         交换机相互连接的接口借用LoopBack0的地址，通过OSPF协议，实现三层网络的互通，作为neutron的Underlay网络。

4.4 其他自动化功能

         

         自动化功能的配置，都来源于配置文件。通过Python自带的模块ConfigParser 是解析配置文件，读取里面的配置信息。

      4.4.1支持自动更换交换机版本

         如果需要更换新版本，放置在ftp服务器。设备启动时，首先检测当前版本和服务器侧版本号是否一致，如果不一致，则会根据ftp协议去下载新版本。

         首先，会获取ftp服务器上设备版本的大小，比计算交换机的存储空间大小，如果发现空间不足，则会删除一些无用的文件，以达到预留的空间。但是有些ftp服务器不支持查找文件的大小，那就根据设备运行的版本大小来预估新版本的大小。

         然后，利用ftp协议去获取新版本，下载完毕，解压，安装，重启。

      4.4.2支持设备的自动堆叠和BFDMAD检测

         实际组网中，需要设备的堆叠来实现高可用和扩展接口的数量。我们定义相同的角色的设备直连时（此处靠LLDP的私有信息传递角色来判断），会下发触发交换机的堆叠。

         当设备堆叠完成以后，会配置BFD-MAD检测堆叠分裂。

      4.4.3支持上下行设备自动下发接口配置和聚合

         当设备发现对端设备是自己的上行或者下行设备时（此处靠LLDP的私有信息传递角色来判断），会自动下发接口的配置。当接口的数量大于2个时，会下发聚合的配置，支持动态聚合和静态聚合，当聚合链路离开是，删除聚合组。