尴尬的VXLAN

VXLAN(Virtual eXtensible Local Area Network)技术是由VMware、思科、Arista、Broadcom、Citrix和红帽共同提出的IETF草案，用以解决数据中心多租户间通信和隔离时解决vlan不够的问题;Vxlan草案里给出的封装格式是MAC-IN-UDP，即将原始报文封装在UDP报文里，其本意是在用于不同数据中心之间的VM(Virtual Machine)之间进行通信时数据报文封装格式。但是这种技术到底是否是一种完美的解决方案哪?

先对VXLAN的技术的提出其标准里主要想解决以下几个问题进行说明：

1) STP协议缺陷和VLAN ID数目少带来的限制

对于国内互联网的公司如BAT的数据中心，STP协议多数是不开启的，明显的缺陷是vxlan标准中所提及的，会导致链路带宽的大量浪费，并且一旦拓扑变化到二三百台网络设备的时候，收敛性能会明显变慢;所以大型数据中心会通过对网络的合理规划，来避免环路。

2) 云计算中多租户环境下的通信和隔离

对于为了提高CPU的使用率以及服务器维护/迁移等操作便捷的云计算来说，不同租户的云主机需要进行私网隔离，对于同一个租户的多个云主机私网内需要二层数据隔离而可以通过三层转发进行通信，并且当云主机在多个数据中心之间的进行热迁移时为了保持其提供服务的不间断需要保证迁移前后在一个vlan内，即多个数据中心组成的二层某个VLAN网路有多大，那么着里面的VM就能迁移有多远，也就是所谓的大二层技术。然而一个数据中心的物理服务器规模十万级在国内已经出现，国外Google等已有百万级规模的数据中心，此类环境下仅有12bit的VLAN数目对于云计算的租户数目来讲是远远不够的;其实vlan数目不够很早就被意识到，并提出了 Q-IN-Q之类的技术(还有灵活Q-IN-Q等)，为什么这些技术不直接被拿来在云计算虚拟网络环境里使用哪?因为虽然我们可以在数据中心内部控制报文的TAG情况，但是一旦报文到了公网，其路径经过的网络设备是路由器还是交换机无法得知，根本无法保证让带各种不同TAG的报文安然通过公网达到对端数据中心;然后就看有了vxlan的技术被提出和应用。

3)TOR交换机的MAC地址表不充足

再讨论一下云计算环境下TOR交换机MAC地址表不足的问题，在以前TOR因为走三层转发,只会学习到与其之恋直连设备及二层相连设备的MAC;而随着大二层的出现，不仅要学习本数据中心二层的设备MAC地址，还有更多其他数据中心二层范围内的地址，包括海量的虚拟机的MAC地址都有可能要被TOR学习到，这无疑大大增加了TOR的MAC表项容量的要求。我们知道对于传统的商业交换芯片如Broadcom的ESW系列芯片，基本都有128K的MAC表项大小，这个容量相对于现代一个数据中心十万级甚至百万级设备的数据量真不算太大。

4)针对VXLAN技术的内容有以下几点讨论：

a)没有说明同一个租户下不同VNID之间如何通信;以前对于同一个vlan或不同的vlan来说两个主机通过交换机进行通信，需要添加或删除报文的vlan TAG;但是对于同一个同一个VNID或不同的VNID的主机进行通信，封装VXLAN报文还需要额外提供一个从L2以太网到L4 UDP的头部，始终让人感觉非常的怪异;

b)VLXAN技术将隔离区域数目从原来的12bit的VLAN ID扩展到现在24bit的VNI，可能犹如原先VLAN提出时看待其12bit的大小觉得已经很多了，但是现在网络规模越来越大，随着业务的需求扩展比如多个行星之间的星际通信发展后，可能很快又无法满足需求;这种扩展的方式始终是有缺陷的;

c)对原有VLAN技术的兼容

Vxlan技术如其他革命性的网络技术的出现(OSPF代替RIP或IPV6代替IPV4)，应该取代vlan，并且兼容vlan，这点VXLAN技术标准文档里也有提及，即如何让VXLAN里的设备与VLAN里的设备进行通信，也可以考虑将vlan作为VXLAN一个子域的PVLAN技术;但是兼容性其他方面依然是个值得考虑的问题，比如三层交换机现有的IP转发时基于vlan创建三层接口的，可以简单理解为DIP VLAN进行查找表项，然后更改报文的VLAN ID号转发到另一个VLAN里转出;当VXLAN代替VLAN后，如何芯片基于VXLAN的VNID进行三层转发时VXLAN标准里没有提及的内容(+微信关注网络世界)，还有如QOS中vlan shapping的映射等技术也存在这个问题;而且封装后还会有报文转发效率、对转发负载均衡性能等方面的影响;