在昨天的主题《从二层交换到三层路由》中,我们已经了解了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可谓是云网融合的红娘!