Neutron作为VXLAN控制平面的那些事

1、引言

大家都说OpenStack中最难学的是Neutron，其实单论Neutron一般用户不需要学习太深入，只要了解Neutron的架构API/Plugin/Agent架构就差不多了，Neutron中最复杂的其实是Neutron自身实现的一套SDN方案中涉及到的知识体系，比如：基于flow 工作模式OpenvSwitch，OpenvSwitch实现VXLAN，以及Neutron如何配合硬件交换机实现VXLAN等等；每一个知识点其实都有不少内容可说，今天本文主题想深入分析下Neutron 使用VXLAN的一些知识点。

2、背景知识

在开始讲解Neutron和VXLAN前我们先了解下VXLAN的基本知识，我们只介绍和本文主题相关的一些VXLAN知识，关于VXLAN的详细介绍网上的资料比如多，在此就不再介绍了，本文今天想说内容就如下（当然以下是讨论没有使用EVPN作为控制平台的情况下，当然Neutron在host overlay模式下没有用到EVPN（社区有提使用ExaBGP实现Neutron下的EVPN，但没有成为主流），当然在network overlay模式下是会使用的EPVN的）：

1. IETF当初在设计VXLAN是没有设计控制平面；那么就导致VTEP之间建立隧道就得手工配置；

2. 各VTEP之间的MAC、IP的学习只能通过传统Flood and Learn的方式学习；

3. VXLAN 当初设计时规定处理overlay网络中的BUM（广播、未知单播、组播）是需要使用underlay网络中的组播；

4. IETF当初规定使用VXLAN是underlay网络必须支持组播，导致有些网络中不支持、没有开启组播或虚拟交换就不支持组播的情况下使用VXLAN有问题，所有就出现了一种不依赖于播的并能使用VXLAN的技术出现了，它就是“头端复制”，头段复制就是比较好理解，就是发送端直接复制多份数据包分别发送到同一个VNI相相关的VTEP目标，这样就不需要under network必须支持组播了。

3、Neutron如何解决这些问题？

无论使用什么方式配置，其实总结起来是要解决三个问题的，如果下图所示：

以普通二层交换为例子，上面为普通的4台二层交换机，每台下连接了两个虚拟机，想要各虚拟机之间互通，其实要解决三个问题：

1. 各交换机之间该如何连接网线；

2. 网络连接好以后各交换机需要学习其它交换机的Port,MAC信息；

3. 虚拟机要和未知目标虚拟机通信先要发ARP请求

其实对应到VXLAN就也是同理，需要解决这三个问题，下面来逐步分析下Neutron 怎么解决这些问题。

3.1 手工配置VTEP的问题

如何我们一个一个问题的去探究Neutron是如何解决以上问题的,如果想使用VXLAN第一步就是各VTEP之间建立VXLAN 隧道。

上一章节有简单提到VXLAN没有控制平面的话，各VTEP之间的隧道就得手工配置，如果只有两个节点还好，可以手工配置。

三个还行将就的能手工配置。

那么十个、十一个呢或者更多呢，明显不能使用手工配置了。

3.2 Neutron 中VTEP隧道的建立

通过上文中知道如果想使用VXLAN第一步就是解决多个VTEP之间如何建立VXLAN隧道的问题。

多个VTEP之间其实是通过ovs agent建立VXLAN 隧道的，那么它是如何建立的呢？在我们配置VXLAN是会在openvswitch_agent.ini中配置local_ip和tunnel_types类型，当ovs agent启动时，会上报Neutron,Neutron会回复其它ovs agent向Neutron上报的local_ip和tunnel_type信息，如果两者tunnel类型一致就通过调用ovs-vsctl命令建立VXLAN tunnel,如果有两多的ovs agent配置了，Neutron也会给其它ovs agent发tunnel更新消息，内容为已知的其它ovs agent的 local_ip和tunnel_type类型，如果有匹配的就再建立VXLAN tunnel。

3.3 Neutron中VTEP MAC地址学习问题

如果想使用VXLAN第二步就是各VTEP之间如何学习到所有的MAC地址。

除了上面提到的l2pop的一个建立VTEP的功能外，l2pop还有一个重要的功能，就是填充各VTEP上的MAC地址，省去了通过VXLAN自身的学习机制Flood and Learn学习MAC地址的过程，这也是社区描述l2pop是提升VXLAN的Scalability的本质。

我们先看一个传统的VXLAN是如何学习MAC地址的(以同一个VNI大二层域为例子),以下为逻辑示意图。

VM_A、VM_B和VM_C同属于10.1.1.0/24网段，且同属于VNI 5000。此时，VM_A想与VM_C进行通信。

由于是首次进行通信，VM_A上没有VM_C的MAC地址，所以会发送ARP广播报文请求VM_C的MAC地址。

下面就让我们根据ARP请求报文及ARP应答报文的转发流程，来看下MAC地址是如何进行学习的。

ARP请求报文转发流程：

1. VM_A发送源MAC为MAC_A、目的MAC为全F、源IP为IP_A、目的IP为IP_C的ARP广播报文，请求VM_C的MAC地址。

2. VTEP_1收到ARP请求后，根据二层子接口上的配置判断报文需要进入VXLAN隧道。确定了报文所属BD后，也就确定了报文所属的VNI。同时，VTEP_1学习MAC_A、VNI和报文入接口（Port_1，即二层子接口对应的物理接口）的对应关系，并记录在本地MAC表中。之后，VTEP_1会根据头端复制列表对报文进行复制，并分别进行封装。

3. 可以看到，这里封装的外层源IP地址为本地VTEP（VTEP_1）的IP地址，外层目的IP地址为对端VTEP（VTEP_2和VTEP_3）的IP地址；外层源MAC地址为本地VTEP的MAC地址，而外层目的MAC地址为去往目的IP的网络中下一跳设备的MAC地址。封装后的报文，根据外层MAC和IP信息，在IP网络中进行传输，直至到达对端VTEP。

4. 报文到达VTEP_2和VTEP_3后，VTEP对报文进行解封装，得到VM_A发送的原始报文。同时，VTEP_2和VTEP_3学习VM_A的MAC地址、VNI和远端VTEP的IP地址（IP_1）的对应关系，并记录在本地MAC表中。之后，VTEP_2和VTEP_3根据二层子接口上的配置对报文进行相应的处理并在对应的二层域内广播。

5. VM_B和VM_C接收到ARP请求后，比较报文中的目的IP地址是否为本机的IP地址。VM_B发现目的IP不是本机IP，故将报文丢弃；VM_C发现目的IP是本机IP，则对ARP请求做出应答。下面，让我们看下ARP应答报文是如何进行转发的。

ARP应答报文转发流程：

1. 由于此时VM_C上已经学习到了VM_A的MAC地址，所以ARP应答报文为单播报文。报文源MAC为MAC_C，目的MAC为MAC_A，源IP为IP_C、目的IP为IP_A。

2. VTEP_3接收到VM_C发送的ARP应答报文后，识别报文所属的VNI（识别过程与步骤2类似）。同时，VTEP_3学习MAC_C、VNI和报文入接口（Port_3）的对应关系，并记录在本地MAC表中。之后，VTEP_3对报文进行封装。

3. 可以看到，这里封装的外层源IP地址为本地VTEP（VTEP_3）的IP地址，外层目的IP地址为对端VTEP（VTEP_1）的IP地址；外层源MAC地址为本地VTEP的MAC地址，而外层目的MAC地址为去往目的IP的网络中下一跳设备的MAC地址。

4. 封装后的报文，根据外层MAC和IP信息，在IP网络中进行传输，直至到达对端VTEP。

5. 报文到达VTEP_1后，VTEP_1对报文进行解封装，得到VM_C发送的原始报文。同时，VTEP_1学习VM_C的MAC地址、VNI和远端VTEP的IP地址（IP_3）的对应关系，并记录在本地MAC表中。之后，VTEP_1将解封装后的报文发送给VM_A。

6. 至此，VM_A和VM_C均已学习到了对方的MAC地址。之后，VM_A和VM_C将采用单播方式进行通信。

我们总结一下上文中提到的关键知识点：

1. 一个VTEP下的虚拟机想要另一个VTEP下的虚拟机通信需要先要得到目标虚拟机的MAC地址（当然这个就是传统二层交换机的工作方式）；

2. VTEP收到VM_A的ARP请求后会在VTEP_1学习MAC_A、VNI和报文入接口（Port_1，即二层子接口对应的物理接口）的对应关系，并记录在本地MAC表中；

这是传统的VXLAN工作原理，我们使用l2pop就可以省去这第二步学习MAC的过程。

那么为什么使用l2pop能省去了VXLAN学习MAC地址的过程呢，答案是Neutron管理整个OpenStack中MAC、IP关系，那么它很清楚和个节点上的MAC和VNI以及Port的对应关系，那么通过一种方式把这个关系直接写入的VTEP中，那就省去了自学习的过程，l2pop就是干这个事的，l2pop在这里实现的有点类似EVPN的功能。

（EVPN）

（l2pop）

3.4 Neutron中ARP请求的问题

通过上方中知道Neutron服务器填充了所有VTEP中关于MAC、VNI、Port的信息，然而，这本身是不够的。当虚拟机不知道目的 MAC 地址时，它会发送一个广播 ARP 请求，但其实在在启用了l2pop后，这个ARP请求是可以避免的，因为每个VTEP是知道所有相关的VTEP下虚拟机MAC地址的，只要VTEP做个ARP代理，代替目标主机回复ARP就解决这问题了（当然，如果使用network ovelry之类的情况下，对端的VTEP是不受Neutorn控制的，那么就不能用到该功能，因为Neutron不知道该VTEP下虚拟机的信息，那么也只能乖乖的还是发送ARP请求了，ARP请求也是通过头端复制分发同一个VNI下所有的VTEP，而非使用的是传统VXLAN中规定的组播。）

下图中的br-tun就是代表VTEP。

Neutron是通过ovs flow实现的ARP responder，这个又涉及到了ovs flow机制，又是另外一个话题了，本文就不展开讨论了。

当然如果使用了network overlay并使用了EVPN后，也有类似的机制处理ARP请求问题。

3.5 如何配置l2pop和arp responder

在控制节点上配置

在所有计算节点上启用

总结

作为启用 l2 pop和 ARP 响应特性的结果，我们能够减少overlay网络中的 BUM 流量，并减少 了overlay网络中的ARP 请求泛滥。