在昨天的主题《从二层交换到三层路由》中，我们已经了解了Neutron和VMWare NSX虚拟网络模型中，VXLAN转发平面的工作方式。那么，数据包转发所依赖的MAC和FIB信息是从哪来的呢？
在早期的Neutron版本中，采用了Openflow协议，将MAC，ARP和FIB以流表的方式下发到OVS中。Openflow的出现，是网络界的一场重大变革，但Openflow也有着一些致命的缺陷。
一方面，Openflow代替泛洪学习的机制导致控制节点负担过重。Openflow VXLAN网络中，VTEP之间的BUM报文都将触发Openflow控制节点代答或下发流表，在网络较大时，对控制节点是沉重的负担。
另一方面，如果控制节点意外停机，Openflow流表将无法刷新，新的虚拟机也无法上线。这在生产环境中是难以接受的。
由于Openflow设计的这些固有缺陷，人们需要新的控制平面协议，为VXLAN网络同步各个节点的MAC和FIB信息。
一些人注意到了VXLAN和VPLS的相似之处。VPLS有两种控制平面，CISCO主导的Martini方式是使用LDP作为控制平面（RFC4762)，而Juniper主导的Kompella方式是使用MP-BGP作为控制平面（RFC4761）。VPLS的主要问题是需要对所有BUM数据包进行泛洪来实现MAC地址的学习，而浪费了宝贵的骨干网络带宽。为了解决这一问题，人们提出了EVPN(RFC 7432)，通过BGP协议来交换各个隧道端点之间的MAC/FIB信息。
我们发现了，如果使用VXLAN代替VPLS，也就是将EVPN协议作为VXLAN的控制平面，在数据中心网络中也可以实现VXLAN的二层和三层转发，如下图：
EVPN的Route Type2，可以实现在各个VTEP之间同步VM的MAC、IP、二层VNI(所在子网)、三层VNI(对称IRB方式做VXLAN路由时，使用的公用中转子网VNI)。 EVPN的另一种宣告方式，叫Route Type5：
Route Type5和Route Type2的区别，在于前者可以以子网前缀方式，向网络中其他VTEP宣告IP地址段，而后者是以主机路由的方式宣告离散的VM（主机）。因此，Route Type5非常适用于连接网络边界路由器的VTEP，向其他VTEP宣告出局路由。
那么，图中的RR是什么角色呢？让我们回忆一下《BGP设计与实现》中提到的，在AS域中，所有iBGP应当建立全连接。这样，如果网络中有n个VTEP，总共就需要维护n(n-1)/2个连接。引入RR，则可以将iBGP的连接数从O(n2)精简为n。
有了EVPN作为VXLAN的控制平面，我们发现，前面提到的两个问题都迎刃而解了。
EVPN代替了flood-and-learn的机制，VM上线或迁移时，VTEP只要通告更新即可；
EVPN在配置完毕后，各VTEP会记住相关配置，控制节点只有在添加租户/子网时，才会修改EVPN配置，避免了控制节点单点故障带来的风险。
EVPN可谓是云网融合的红娘！
