EVPN是近几年最热门的网络技术之一。如果你还没听过EVPN，你的网络技能可能已经落伍了，赶紧看看之前的《EVPN简介》吧!EVPN全称是Ethernet VPN，从名字上看是一个L2 VPN的实现。实际上在最开始提出时，也是用作L2 VPN，号称是next generation L2 VPN，对原有的VPLS(Virtual Private LAN Service)进行改进。所以最开始的EVPN，是一套跨WAN(Wide Area Network)的L2 VPN的控制层和数据层技术，数据层特指的就是MPLS。所有的这些在EVPN简介中都有介绍，今天我们来看一个EVPN应用的变化，将EVPN的控制层与VXLAN结合。
EVPN作为控制层，通常可以对接三种数据层，MPLS，PBB和NVO。NVO(Network Virtualization Overlay)，这一分类包含了VXLAN(Virtual eXtensible LAN)。
传统的VXLAN工作方式
VXLAN是一种Overlay网络技术，我相信大家对Overlay和VXLAN已经有一定的了解了，所以，我不在这对Overlay和VXLAN做解释。我们直接看一下VXLAN网络是如何工作的。
VTEP
首先看看VXLAN网络中的重要组成部分，VTEP(VXLAN Tunnel Endpoint)。VTEP是一个网络设备VXLAN数据是在VTEP之间传递。从逻辑上看，VTEP包含了两个接口：uplink和downlink。Uplink连接Underlay网络，原始数据封装成VXLAN格式通过uplink在Underlay网络上传输;downlink连接Overlay网络，原始数据从downlink传入传出。所以，VTEP可以看成是一个连接Overlay和Underlay网络的edge设备。
举个例子，当Overlay中VLAN100数据包通过downlink发送至VTEP，首先会映射到VXLAN ID 1001。在这之后，VTEP根据原始数据包的目的MAC地址和刚刚转换获得的VXLAN ID，在VTEP L2 Table中查找对应的Remote VTEP，如果能找到，就原始的Ethernet Frame封装成VXLAN数据包，再通过uplink发送出去。
对端VTEP的uplink收到了VXLAN数据包，解封装获得原始的Ethernet Frame，再将VXLAN ID与VLAN ID做映射，加入VLAN100的信息，最后数据包再通过downlink发送出去。这样，两个VTEP下的VLAN 100网络相当于是连通的。(注：虽然这里都是VLAN 100，但是实际上两个VTEP下对同一个VXLAN ID对应的VLAN ID可以不一样)
原始的Ethernet Frame被封装成了一个IP/UDP packet，数据的传输变成了VTEP之间的IP/UDP packet传输，VTEP之间可以是二层网络，三层网络，甚至更复杂，但是这对VLAN100是透明的。
flood-learn
前面的例子中，如果VTEP L2 Table中没有找到对应的Remote VTEP，那就要通过flood-learn来获得对端的VTEP。
为了更好的描述flood-learn，我们假设最左侧虚机已经知道目的MAC了(VTEP中的L2 Table已经老化，虚机中的ARP cache还没老化)。当最左侧虚机想ping最右侧虚机，ping包送到VTEP，因为在VTEP中找不到对应的Remote VTEP，VTEP会做如下操作：
原始的Ethernet Frame被封装成VXLAN格式，VXLAN包的外层目的IP地址为组播地址。
VXLAN数据包被发送给组播内所有其他VTEP。
其实这就是flood过程。因为组播内所有VTEP都是接收方，最右侧虚机可以受到组播的ping包。最右侧的VTEP首先从ping包中学习到了最左侧虚机的MAC地址，VXLAN ID和对应的VTEP。因为有了这些信息，当最右侧虚机返回时，会直接发送到最左侧VTEP。这样最左侧VTEP也能从返回包中学习到最右侧虚机的MAC地址，VXLAN ID和对应的VTEP，并记录在自己的L2 Table中，这就是learn过程。与交换机中的flood-learn不一样的是，交换机中记录的是对应的交换机端口和MAC的关系，这里记录的是Remote VTEP(IP Address)和MAC的关系。
下次最左侧虚机想访问最右侧虚机，不需要再flood，直接查VTEP L2 Table就能找到对应的remote VTEP。
所以从这里看出，VXLAN的转发信息，也是通过数据层的flood-learn获取，VXLAN不需要一个控制层也能工作，这与VPLS的情况很像啊!
EVPN control plane
VXLAN由RFC7348定义，在RFC中，只定义了数据层的行为，并没有指定VXLAN控制层。在VXLAN技术早期，通过数据层的来获取转发信息，在实现上较为简单，相应的技术门槛较低，有利于厂商实现VXLAN。但是随着网络规模的发展，完全依赖数据层做控制会造成网络中广播组播风暴，因此VXLAN也需要有一个控制层。
SDN controller也可以作为VXLAN的控制层，OpenStack中普遍用SDN controller控制OpenVSwitch，VTEP直接通过OVSDB和OpenFlow流表进行管理。这些内容很有意思，功能也很强大，不过跟本文是两件事情，本文只讨论EVPN作为控制层的情况。
EVPN作为NVO的控制层由IETF草案：draft-ietf-bess-evpn-overlay定义。上一篇讲了EVPN的实现是参考了BGP/MPLS L3 VPN，那么EVPN作为VXLAN的控制层时，仍然采用相同的架构，只是架构的组成元素发生了改变。
具体的变换包括了：
- PE设备变成了VTEP，有的时候也称为NVE(Network Virtualization Endpoint)。相应的MP-BGP连接也建立在VTEP之间。
- 数据层变成了VXLAN，VXLAN是在Underlay网络传输。
- CE设备变成了Server，这里可以是Virtual Server也可以是Physical Server。
控制层数据传输
与传统的EVPN基本一致，Server到VTEP还是通过local learning，VTEP通过读取Ethernet Frame获得本地连接设备的MAC地址和对应的端口。VTEP之间通过MP-BGP传输Route Type 2的MAC/IP route。这里有点不一样，以MPLS为数据层时，MAC/IP route传输的是MPLS Label，而以VXLAN为数据层时，MAC/IP route传输的是VXLAN ID。正好VXLAN ID也是3个字节，能够匹配原来MPLS Label的空间。相应的NLRI信息如下：
MAC/IP route通过MP-BGP传输到对端VTEP。现实中要求BGP连接是full mesh(任意两两互连)，而为了减轻配置压力，通常会引入BGP RR(Router Reflector)。BGP RR的作用是将一个BGP Speaker的数据反射给所有其他连接的BGP peer。使用BGP RR可以使得所有的BGP Speaker只需与BGP RR建立连接，否则按照full mesh，任意一个BGP Speaker必须与其他所有的BGP peer建立BGP连接。
所以，在有BGP RR的环境中，网络拓扑如下图所示，是不是跟Spine-Leaf的网络结构很像?
所有的VTEP学习到本地的MAC地址之后，通过MP-BGP发送给BGP RR。BGP RR再将收到的MAC转发信息，发送给所有其他的VTEP。经过BGP RR的反射之后，各个VTEP已经有了所有其他VTEP的MAC转发信息，如下图所示：
看一看图中各个VTEP的L2 Table，第一列是MAC地址，第二列是对应的Remote VTEP(远端MAC)或者当前VTEP连接的端口(本地MAC)，第三列是VXLAN ID，这三列在介绍VTEP时说过。第四列是用来做MAC Mobility，也就是MAC迁移用的，这个稍后单独介绍。
就这样，控制层数据分发到了各个VTEP。
数据层数据传输
有了控制层数据，数据层就简单多了。Server A想访问Server B，通过查找本地VTEP L2 Table找到VTEP2，再封装成VXLAN数据发送到VTEP2，VTEP2将VXLAN解封装，转发给本地的Server B。所以可以看出，从数据层面角度来看，有没有EVPN效果都是一样的。EVPN只负责VXLAN的控制层面，也就是MAC转发信息的传输，对VXLAN数据层面没有影响。
EVPN作为VXLAN的控制层面就是这样了，是不是也不太复杂?接下来看一看MAC Mobility。
MAC Mobility
MAC Mobility在RFC7432中已经定义，也就是说这不是为VXLAN专门定义的。先来看看MAC Mobility解决了什么问题?
现实中，经常会面临Server迁移的场景，例如虚机迁移，物理机房的改造造成的迁移。以上图为例，当Server A从VTEP1迁移到了VTEP3，VTEP3通过本地数据层面的学习(读取ARP或者DHCP的Ethernet Header)，发现了Server A。本来VTEP3上的MP-BGP进程应该将这个新学习的MAC通过Route type 2发送给其他VTEP。但是现在有几个问题。首先，VTEP3本身已经有了Server A的MAC转发信息，表明了Server A在VTEP1上，那么VTEP3本地数据已经有了冲突了。其次，VTEP1和VTEP2中也有Server A的MAC转发信息，它们将如何处理VTEP3发出来的Server A的转发信息。你可以说，后来的覆盖先来的，但是EVPN，或者MP-BGP，这是一个L7的协议，后来的不一定是更新的数据。比如，Server A迁移到VTEP3，VTEP3本地学习到了Server A的MAC，并发送出去，VTEP2收到了这个信息，但是由于网络阻塞，VTEP1关于Server A的信息过了一会也发送到了VTEP2。如果后来的覆盖前面的，那这时就是旧的信息覆盖了新的信息。
在说解决方案之前，先回顾一下EVPN新增的MP-BGP Route type和BGP Extended community。
MAC Mobility就是基于图中标注的Extended community实现。BGP Extended community是跟随在BGP NLRI信息之后的辅助信息，像RT(Route Target)就是最常用的一种BGP Extended community。MAC Mobility Extended Community的格式定义如下：
所以，具体工作过程是这样，当VTEP通过本地的数据层学习获得了一个MAC地址，如果本地的L2 Table中没有这条MAC地址的记录，那么VTEP接下来发布的MAC/IP route会带上一份MAC Mobility Extended Community，其中的Sequence Number是0。(也可以不带，这样默认就是0)这也就是上面示意图中第四列中的0的意义。
当VTEP通过本地的数据层学习获得了一个MAC地址，如果本地的L2 Table中已经有这条MAC地址的记录，那么VTEP首先会更新自己的L2 Table，将之前的MAC转发信息覆盖。之后VTEP发布的MAC/IP route必然会带上一份MAC Mobility Extended Community，其中的Sequence Number是原有记录的数值加1。这样，当其他的VTEP收到了这条MAC/IP route，对比本地记录，就会发现，这是一条更新的MAC转发信息，原有记录会被覆盖。如果VTEP收到的MAC/IP route中的Sequence Number小于当前记录的信息，那么这条MAC/IP route会被丢弃。
MAC Mobility中的Sequence Number可以看成是MAC转发信息的版本号，高版本可以覆盖低版本。
从另一个角度看，如果没有控制层的MAC Mobility机制，那么Server迁移之后，只能等L2 Table中的表项老化以后，重新flood-learn才能获得更新之后的MAC转发信息，这样的时间相对要长很多。这就是EVPN作为控制层带来的好处之一。
最后
EVPN的提出是作为下一代L2 VPN。L2 VPN实际上是在WAN上的一个逻辑二层网络。如果将L2 VPN与Overlay技术，例如VXLAN做对比，其实有很多相似的地方。比如都是有Overlay和Underlay，Overlay都是L2网络，都有相应的edge设备等等。正是这些相似之处，才会有将原本是L2 VPN的控制层的EVPN，用作Overlay网络，例如VXLAN网络的控制层。VXLAN网络配合EVPN作为控制层，不仅能减少网络中的广播与组播数量，而且能带来EVPN作为控制层的一些优点，例如本文介绍的MAC Mobility。在一个VXLAN Fabric架构中，采用EVPN做控制层，借助功能完善的BGP(确切说是MP-BGP)协议，能够高效的连接不同的POD，甚至连接不同的site。所以从这个角度来说，EVPN作为VXLAN的控制层的应用，并不逊色与其作为L2 VPN的应用。
作者简介：肖宏辉，毕业于中科院研究生院，8年的工作经验，其中6年云计算开发经验，OpenStack社区积极活跃，有超过300个commit和超过30000行代码的贡献。目前关注SDN/NFV等虚拟网络技术。本文所有观点仅代表作者个人观点，与作者现在或者之前所在的公司无关。
