“技术手法” 搞掂768k日，才能一劳永逸

IT人都知道：768k日快要来了。

据专家估计，就在5月，还有可数的20来天吧。

所以，网络上充斥着对768k日紧张又期待、忐忑又兴奋、谨慎又乐观的各种猜测和预测。

这种酸爽复杂的心绪，就像是迎接初恋......

无论从哪个角度看，768k日都不算是初恋啦。前有大名鼎鼎的互联网故障之母：512k日（512k Day），这场发生在2014年8月12日的意外事故，令当时全球各地的数百家互联网服务提供商（ISP）瘫痪，造成了因连接中断或数据包丢失而导致的损失高达数十亿美元。

512k Day & 768k Day 的背景

512k日之所以会发生，是由于路由器用来存储全局BGP路由表的内存不足，BGP路由表是一个文件，包含所有连接至互联网的已知网络的IPv4地址。当时，互联网的大部分系统通过分配TCAM（三元内容可寻址内存）的设备进行路由；TCAM足够大，存储最多512000条互联网路由。

但在2014年8月12日那天，韦里逊增加了15000条新的BGP路由，这导致全局BGP路由表在没有警告的情况下突然超过512000条。在旧路由器上，这表现为全局路由表文件从分配的内存中溢出，每次尝试读取或处理该文件都会使设备崩溃。微软、eBay、LastPass、BT、LiquidWeb、康卡斯特、AT&T、斯普林特和韦里逊等公司统统受到了影响。

许多老式路由器都收到了紧急固件补丁，让网络管理员得以为分配用于处理全局BGP路由表的内存大小设置更高的阈值。大多数网络管理员都遵循当时提供的文档，将新的上限设置为768000，即768k。

近期，多方数据显示：全局BGP路由表在旧路由器上即将达到768000的限制——CIDR Report是跟踪全局BGP路由表的网站，它估计该文件的大小是773480个条目，但其中含有一些重复条目；一个名为BGP4-Table的Twitter机器人程序也一直在跟踪全局BGP路由表的大小，它估计文件的实际大小为767392，离溢出仅一步之遥。

好消息是：不少专家认为768k日不会像2014年那样引起整个互联网的中断。由于很多网络管理员早就知道了768k日，许多人已作好了准备，要么把旧的路由器换成新的；要么调整固件，允许设备处理超过768000条路由的全局BGP路由表。

但，我们不禁要问：随着路由表的不断累积增大，难道这阈值就这样一直调整下去吗？ 512k日之后有768k日，接下来呢，会不会还有1024k日、2048k日呢？

表项空间不足的问题不仅给我们带来了512k日、768k日这些网络运维的麻烦，也给云数据中心的规模扩展和性能提升造成了束缚和困扰。

下图描述了在传统底层网络中，将二层虚拟网络卸载到底层网络的Leaf交换机上、并且采用EVPN在所有的Leaf交换机之间传递所有虚拟网络的所有虚拟计算节点的网络可达信息时的情景：

所有二层虚拟网络的VTEP功能被从物理服务器上迁移到Leaf交换机上部署，因此，每一个Leaf交换机的FIB（ForwardingInformation base，转发信息表）需要装载的信息包括两类：

* 它自己连接的所有物理服务器中运行的所有虚拟计算节点的转发信息，简称为本地虚拟计算节点信息

* 与所有本地虚拟计算节点处于同一个二层虚拟网络中的、运行于其他Leaf交换机下的物理服务器中的所有虚拟计算节点的转发信息，简称为远端虚拟计算节点

再考虑到二层虚拟网络之间的互通、三层虚拟网络网关的分布式部署等因素，我们可以近似地认为，在上面的方案中，每一台Leaf交换机都需要在其FIB中装载全网（或全云）所有租户的所有虚拟网络的所有虚拟计算节点的转发信息。而且，更为严峻的是，这样的信息在所有Leaf交换机上完全是高度地重叠，即每一台Leaf交换机都无差别地复制、承载了所有信息。换句话说：一台Leaf交换机的FIB表项空间的大小，直接决定了云中的虚拟计算节点的数量。而Spine交换机的FIB空空如也，除了底层网络很少的那一点点转发信息以外，没有装载任何跟虚拟网络和虚拟计算节点相关的信息……

以一个可容纳5,000台物理服务器的中小规模的云数据中心为例，将其最低虚拟计算节点容量设计为5,000,000是一个最正常的需求。但是，在今天的商业以太网交换芯片市场上，为1RU高的Leaf交换机设计的交换芯片的FIB表项空间的容量最常见的只有128K，做的最大的也就仅512K而已。

由此，5,000,000和512K的矛盾就尖锐地凸显出来了。

在这种矛盾面前，不得不做出的妥协就是：为了追求将VXLAN的功能卸载到物理交换机上，不得不将整张云能够支持的虚拟计算节点的数量进行数量级的降低；甚至，干脆弃用明显具备性能优势的“硬件/EVPN方案”，退回到“vSwitch方案”的世界里，用耗费大量计算力模拟网络功能和大幅降低整体性能的成本来换取非常有限的容量提升。

那么，表项空间的难题，有没有更好的解决方案呢？

重点来了——当然有！它就是PICFATM，Protocol Infinity Cloud Fabric Architecture，协议无限云网架构。它是Asterfusion（星融）为下一代云网络全面创新的分布式架构。

PICFA采用独创的分布式路由算法和与之相配合的转发逻辑，完全重构了云网络的控制平面与数据平面，彻底抛弃了传统网络中低效的集中式存储结构与转发逻辑，将云网络对云中虚拟计算节点的容量支持一举提升100倍至千万量级，同时大幅提升转发性能，使网络不再成为云计算容量的限制因素，从而为云网络从计算空间向底层物理网络的迁移打下坚实的基础。

PICFA将Asterfusion（星融）云网络所有交换机的能力整合为一个超级的“分布式虚拟路由表”。在部署了PICFA的云网络中，所有租户的所有虚拟网络信息被动态、智能、均衡地分布在全网的所有Spine和Leaf交换机上，充分利用所有交换机的所有表项空间，由此，单台网络设备的FIB容量不再成为云的容量限制，虚拟机数量获得量级的提升，服务器计算力被充分利用。

此外，所有Spine交换机可被动态地划分为三组，其中第三组可以被指定用来承载VIP租户和/或关键业务，这组Spine交换机将会被PICFATM从物理上与其他Spine交换机隔离开来，运行在HULL架构（High-bandwidth Ultra-Low Latency Architecture）所描述的资源使用率较低的状态下，从而真正做到了物理隔离，让低优先级租户的流量和尽力传送型业务流量对VIP租户和业务的影响降至0，完全达到SLA（Service Level Agreement）所规定的服务质量保证，即极低的网络延迟和近似于0的丢包率。

最后，做个总结吧！

▼

由于采用了专利算法，PICFA不仅一劳永逸的解决了表项空间的问题，而且将网络对云的支撑能力提升了100倍，将单数据中心可制成的虚拟计算节点数量一举提升到千万量级，为大规模公有云向更多的租户提供业务支撑打下坚实的基础。所以，采用PICFA构建的Asterfusion（星融）云网络，可以成功突破服务器内部10G带宽的物理限制，紧密跟随基础网络的发展速度，进入到100G/400G时代，成为名副其实的超高性能网络。

也正是因为有了PICFA，Asterfusion（星融）才一直走在“让云网络回归网络”的征途上。区别于传统云网络中被定义为“粗但是傻”的底层线路，Asterfusion将底层网络重新定义为“粗并且灵”的智能网络，为云中租户与业务服务的虚拟网络直接承载在其上，在提供虚拟化、多租户的同时，支持NFV等增值功能，让云的ROI“里外里”地增长。