标签： 中立科普

关注星融元

什么是SONiC?

在构建公有云平台Azure的过程中，微软逐渐意识到传统网络设备的局限性。

于是成立了SONiC（Software for Open Networking in the Cloud）/SAI（Switch Abstraction Interface）开源项目，目标是针对Azure对网络的需求，基于标准的Linux内核重新构建一个开放的网络系统软件。

并且，微软没有将这个系统做成封闭的，而是以开放、开源、社区的模式运作；

SONiC/SAI最近几年的蓬勃发展在很大程度上也是得益于此…

图1：SONiC/SAI概念

在SONiC/SAI定义的开放架构中，传统网络设备软硬件一体的封闭架构被打破，软件和硬件被彻底解耦；就好像今天的Windows/Linux操作系统能够运行在任何第三方基于标准设计的PC/Server硬件上一样，SONiC/SAI网络软件系统也能够运行在任何符合标准的网络硬件平台之上啦！

SONiC/SAI给整个网络产业带来的最根本变革是：

• 软硬件解耦的理念和标准化的软硬件接口定义，分别让网络软件系统和硬件平台飞速发展；
• 网络软件系统的演进，也可以让快速迭代、按需定制、社区共建成为可能；
• 网络软件的开发形成了全新的共建、共享、开放的网络生态系统，快速推进网络自身的发展。

SONiC/SAI全新的理念、开放的架构，很快获得了云计算时代的用户、厂商的青睐，成为云计算时代构建网络软件系统的首选。

也正因此，SONiC/SAI被OCP（Open Compute Project，开放计算项目）吸纳，成为OCP网络组的两个子项目。

SONiC系统架构

SONiC构建在Linux系统之上，并且利用键值数据库（redis）、容器技术（docker）、标准化硬件接口定义等技术，使其成为一个软硬件彻底解耦、软件模块松耦合（loose coupling）、高可靠、易于扩展、开源开放的网络软件系统。

图2：SONiC系统架构

从图2我们可以看到：

• 运行在用户空间的SONiC系统，只有为数很少的模块（pmon、swss和syncd）与Linux内核之间存在交互关系，从而保证了系统的稳定性。
• 以redis键值数据库为交互中心，redis为SONiC的所有软件模块构建了一个松耦合的通信载体，同时提供数据一致性、信息复制、多进程通信等机制。
• 采用了最新的容器架构，除SONiC CLI和SONiC Configuration这两个软件模块以外，构成SONiC系统的其他各个软件模块均被隔离在独立的Docker容器中。使用者无论需要增加新的功能，还是改变一个Docker，都不需要做太大的变化，只对一个局部做出改变即可！

星融元基于SONiC构建的网络操作系统

星融是国内最早参与SONiC社区的公司之一

经过几年的发展，SONiC已经成为云计算领域极具发展前途的开源社区之一。

星融（Asterfusion）创始团队的核心成员来自于华为、Cisco、Broadcom等知名网络企业，对于网络和云计算领域的技术和产品有着深刻的理解，创立星融之前就已经在积极跟踪、深度参与SONiC及其社区。

作为新一代云网络供应商的星融自成立之初就正式加入了SONiC社区，成为国内最早参与SONiC社区的云网络公司之一。

图3：SONiC社区成员

SONiC社区活跃的成员大致可以分为以下几类：

• 互联网巨头/云计算公司：阿里巴巴、百度、滴滴、Docker、Facebook、京东、LinkedIn、Microsoft、腾讯等
• 传统网络设备供应商：Arista、Cisco、Dell、Juniper、Ruijie等
• 白盒网络设备供应商：Celestica、Edgecore、Quanta等
• 新一代云网络供应商：Apstra、Asterfusion等
• 网络交换芯片供应商：Barefoot、Broadcom、Cavium、Centec、Innovium、Marvell、Mellanox等

可见，SONiC社区已经形成了从最低层芯片到最上层大规模用户的全面生态系统，这个生态系统从硬件芯片、系统架构、系统集成、大规模应用等各个层面促进着SONiC的发展与成熟。

AsterNOS网络操作系统

星融致力于为云计算时代的用户提供新一代云网络解决方案。

为了提供全开放、高性能、业务可视的云网络解决方案，星融以SONiC为内核，构建了新一代的网络操作系统——AsterNOS。

图4：AsterNOS整体架构

AsterNOS构建在标准的Linux内核与SONiC/SAI之上，基于SONiC的标准功能，星融为AsterNOS开发了一些增强特性??：

• 增加了VLAG、BGP EVPN、PICFA™、REST API等功能来提升系统整体可用性；
• 通过REST API将网络的所有能力开放出去，使系统能够被第三方云管平台集中管理、自动调用；
• 基于REST API提供了Web UI，让用户能够通过图形化的界面来操作和管理云网络；
• 应用编排、业务调度、资源管理、策略管理等运维和运营的增强特性，使系统能够支持云管理平台的业务统一规划、自动部署；
• 集成了Python、Ansible、NETCONF等DevOps工具，使得系统能够与DevOps平台自动对接；
• 开放标准的Docker容器环境，支持第三方应用直接在网络系统中运行。

另外值得一提的是，星融还为AsterNOS提供了可编程

• 基于可编程交换芯片的高性能硬件平台
• 统一控制器：Asteria SDN云网控制器（AFC）

AsterNOS、AFC和高性能的可编程硬件平台一起为云计算提供新一代的SDN云网络方案：

图5：星融云网络方案整体架构

星融积极回馈SONiC社区

秉承开源、开放的精神，星融积极回馈SONiC开源社区。
截至2020年4月，星融已经向社区贡献了多个Bug Fix，其中有21个通过社区评审，并被合并进入主线版本。

这21个Bug Fix具体如下：

 20个针对SONiC系统，分布在路由协议（FRR、docker-fpm-frr、vrfmgrd）、应用模块（dhcp-relay、libteam、lldp）、VXLAN隧道（vxlanorch）、ACL模块（portsorch）、安全保护（copporch、ebtables）、服务质量保障（qosorch）、系统与配置管理（sonic-sfp、config、hostcfgd）、系统仿真（vstests）等模块。

除了上述Bug Fix以外，星融目前正在计划将自行开发的增强功能也贡献给SONiC社区，帮助社区进一步提升SONiC的可用性、易用性。

星融可以帮助企业用户使用SONiC

针对企业用户，在部署SONiC和基于SONiC进行的二次开发过程中遇到的一些难题，星融从以下几个方面，可以帮助企业用户顺利使用SONiC。

搭建本地Git仓库

很多企业用户通过github.com下载、编译SONiC源代码的过程并不顺利，往往会碰到无法连接、下载速度慢继而导致编译失败等问题。

针对这样的问题，星融在云端为企业用户搭建了位于本地的Git代码仓库，定时、自动地克隆源服务器上的相关内容以提供本地镜像，需要使用时只要连接到这个本地的Git代码仓库即可。

提供技术咨询服务

针对企业的生产环境，星融编制了全面的测试用例，在基于各种交换芯片的硬件平台上对SONiC系统中的各个软件模块进行了详尽的功能、集成、性能及压力测试，并且将测试过程中发现的问题修正后反馈给社区。

在这个过程中，星融积累了对SONiC系统的深刻理解，能够提供全方位的SONiC技术咨询服务，帮助企业用户清楚明白地使用SONiC。

提供一站式SONiC解决方案

对于希望使用原生SONiC的企业用户，星融能够帮助用户在选定的硬件平台上快速地完成开源、开放云网络系统的构建与部署；对于希望使用一站式解决方案的用户，星融可以基于AsterNOS、可编程交换硬件平台及AFC的支持，提供Turn-key方式的交付与部署，帮助用户轻松享受新一代的云网络技术为IT系统带来的“速度与便捷”。

功能与特性的定制开发

经过三年的发展，星融目前已经拥有了将近80名具备SONiC经验的开发/测试工程师，其中不乏具备架构能力的技术专家。因此，对于客户提出的针对网络的特殊功能需求，星融能够提供定制开发服务，将客户对需求的等待时间从18-24个月缩短到2-4周。

关注星融元

今天，用于流量采集和预处理的前端设备的功能越来越强大。随着实现技术的不断进化、可视化系统整体方案的复杂度越来越高、网络运维和信息安全中可视化系统应用部署越来越广泛，行业对前端设备的功能、集成度和成本要求也越来越高。

那么，在过去、现在和将来，可视化系统前端设备都经历了何种发展历史、形成了什么样的现状、又即将面对何种发展趋势？

前端设备的现状

今天主流的前端设备都是由传统网络设备逐步演化而来，其主要组成部分包括：

➤ 线路卡。主要功能包括接入和输出，即从分光器（或者生产网交换机的镜像端口）接入需要预处理的业务流量、将经过预处理后的业务流量输出到可视化分析、安全分析等后端系统。

➤ 业务卡。主要功能是对所接入的原始业务流量按照后端系统的需求进行各种预先的深度分析处理，降低后端系统的流量处理负载、提升整体系统的性能。

➤ 交换卡。主要功能是在多块线路卡和业务卡之间构建一个高速交换通道，形成一个具备高接口密度和高业务处理性能的整体系统；通常，交换卡会采用正交连接器或高速背板来和线路卡、业务卡进行互联。

业务卡所提供的流量预处理是整个前端设备最核心的能力，也是对后端系统来说最核心的价值所在。因此，接下来的讨论从业务卡开始。

业务卡的发展历史与技术路线

在过去十多年的发展历程中，随着产业基础支撑技术的发展，今天的业务卡所采用的架构也对应地形成了四种技术路线。

➤ FPGA（Field Programmable Gate Array）

具备和交换芯片类似的L2、L3和L4功能，但是针对报文的L7特征提取和分析等能力则非常有限。在这种架构中，灵活的L2、L3和L4-L7的报文处理都需要用Verilog这样的高级电路开发语言消耗FPGA的逻辑单元形成计算能力来实现。

➤ NPU（Network Process Unit）

能提供较丰富L4能力，也有较高性能的L7特征匹配分析能力。历经数代发展后，最后一代号称能够提供100G的L7协议分析处理能力的NPS在2016年被Mellanox收购后正式宣告停止后续的发展路标，大量采用NPS进行前端设备研发的厂商失去了技术支持，后续供货陷入高成本、备货周期不可预测、随时可能会停产的尴尬境地。

从另一个侧面看，所有NPU核心芯片厂家一致认为，用NPU实现L2-L4的功能，灵活有余而复杂度太高，且成本太高，用NPU实现L4-L7的功能以满足DPI的需求，则处理能力不足，在应对复杂场景时，心有余而力不足。

因此，对于今天需要对流量进行深度处理的市场（包括本文所述的可视化系统前端设备和防火墙、多业务路由器等）来说，NPU基本是一个已经被证明的在市场和技术上双重失败的典型案例。

➤ 以MIPS多核处理器为核心的SoC

SoC（System on Chip，片上处理系统）能够提供超高的系统集成度、丰富的I/O资源和灵活与性能兼备的加速子系统，而MIPS本身也能基于其强大的通用计算能力提供高性能的L4-L7的深度分析处理能力，自然而然的，两者相结合的架构可以为DPI分析需求提供高性能和灵活性兼具的解决方案。因此，从2010年开始的近十年间，以MIPS多核处理器为核心的SoC架构一直承担着L4-L7深度分析处理的主要任务。今天，MIPS处理器的指令集架构正在逐步被通用计算指令集（如X86和ARM）取代。

➤ 通用计算处理器（CPU）

今天的X86和ARMv64通用处理器，通过充分发挥SIMD指令集的效率，能够提供比肩MIPS/SoC片上加速单元的L4-L7特征分析处理能力，其通用计算能力也为报文分析提供了非常强大的软件生态支持。

（注：SIMD，Single Instruction Multiple Data，意指“单指令流多数据流”，是一种采用一个控制器来控制多个处理器同时对一组数据（又称“数据向量”）中的每一个分别执行相同的操作从而实现空间上的并行性的技术。在微处理器中，单指令流多数据流技术则是指一个控制器控制多个平行的处理微元对数据向量进行并行。）

线路卡的来龙去脉与前世今生

正因为早期的业务卡多从FPGA/NPU做起，而FPGA/NPU可以在提供业务处理能力的同时提供必要的L2-L4处理能力和端口I/O能力，所以早期的业务卡往往会混合着端口I/O、L2-L4处理及L4-L7处理三种能力，而且，每端口I/O的成本和FPGA/NPU的计算能力成正比。但是，从各种真实应用场景的实际情况来看，高密度I/O端口之间的L2-L4路由需求和需要强大计算能力的L4-L7深度处理需求之间并不能简单地按照线性比例部署，因此，为成本及灵活性计，L2-L4和L4-L7必须解耦，而这种解耦的要求直接导致了从业务卡中分化出线路卡的结果（就像从路由器中分化出了交换机⼀样）。

一般的，线路卡通过计算力不强、但I/O密度高、L2-L4功能相对完善的ASIC芯片来提供流量的接入、汇聚、过滤等标准的L2-L4处理。典型的线路卡实现采用了Switch芯片（交换芯片）：

➤ 传统交换芯片中，Broadcom和Marvell是具备绝对市场统治地位的供应商，其芯片按照交换机的逻辑实现了经典的L2查表、L3查表等处理流程。在用作可视系统的前端设备时，前端设备的控制面软件通过特别的控制管理，可以利用交换芯片实现相当一部分前端设备的处理逻辑。但是，由于前端设备处理逻辑的查表键值与匹配流程和Switch芯片的经典流程并不完全相同，随着可视化系统对前端设备灵活性的要求越来越高，随着新网络协议和业务层出不穷，经典查表流程已经不能满足前端设备的L2-L4处理要求。

➤ 而事实上，类似的问题也出现在标准网络交换设备在日常的组网中，例如，根据多重隧道内层报文进行特征匹配，或者根据报文各层字段组合进行组合特征匹配，或者在一个处理流程中实现L2、L3和L4的并行处理、甚至对报文的负载部分进行修改等功能。虽然这些功能并不需要特别强大的计算能力，但是当标准Switch芯片不支持这些功能时，人们不得不将需要如此处理的流量提交到业务卡上去处理。

➤ 通常，对于每1个单位成本实现的1Tbps容量的L2-L4的Switch ASIC方案，需要2单位成本实现100Gbps的业务处理能力，这意味着，为了实现标准Switch芯片不能支持的L2-L4功能，我们可能需要多达20倍成本的业务卡才能实现这些功能。

➤ 事实上，今天的路由器、防火墙、NFV（Network Functionality Virtualization，网络功能虚拟化）在很多场景下，也在为了解决交换芯片并不容易实现的L2-L4灵活处理流程而不得不采用昂贵的计算资源来实现这些流程，也就是说，“支付20倍的实现成本”在一些特定的L2-L4需求和深度的L4-L7需求面前，是一个普遍的现象。

线路卡的未来

当交换机标准处理流程已经固化到ASIC之后，我们是否能够为新出现的L2-L4处理流程找到昂贵计算资源之外的低成本实现方案？能！答案就是可编程交换芯片。可编程交换芯片其实就是为了解决这样一种尴尬的场景而出现的新技术。可编程交换芯片通过使用高级语言灵活定义查表键值和处理流程，用和传统交换芯片同样的成本实现了（几乎）任意L2-L4的流程要求。

幸运的是，前端设备所有的L2-L4非标流程都可以得益于可编程交换芯片的灵活性，而不必支付比标准交换芯片更高的成本。当然，我们也可以看到，多业务路由器、防火墙和NFV里面相当一部分利用计算资源实现的L2-L4层非（Switch芯片处理流程的）标准能力，也完全可以由可编程交换芯片实现！更有甚者，L4-L7的部分内容特征识别和过滤也可以在可编程交换芯片中实现。

DPI是最具代表性的后端系统之一。为了便于说明问题，以下我们以DPI为例来讨论未来的架构。

DPI对芯⽚计算能⼒的要求

今天的DPI系统是一个对网络处理能力和计算能力都有很高要求的综合系统。一个典型的DPI系统需要具备如下技术能力：

➤ 报文的L2-L3过滤、缓存和重组

➤ 报文的L4-L7特征匹配处理

➤ 邮件、下载、网页内容的还原与搜索

➤ 运营商移动系统信令解码

➤ 视频和音频数据流的解码

➤ 用户身份分析和行为关联

由于前端设备和DPI往往被传统可视化系统的实现混为一谈，我们将DPI的技术能力实现方式用前端设备业务卡的四条技术路线进行一下适应性梳理：

从上述对比可以看出，基于FPGA和NPU的前端设备在DPI系统中已经失去了任何竞争优势，我们基本可以提前得出结论：在FPGA和NPU实现的前端设备上提供DPI，将给最终用户带来极大的投资损失；MIPS多核也许还会在一段时间内保持技术竞争力，但最终通用计算将成为DPI实现的重要选择。

DPI的未来趋势

➤ 随着HTTPS等加密流量的持续增加，特征匹配在大部分场景下将失去效果，机器学习将在DPI实现中扮演日趋重要的角色；

➤ 随着DPI系统部署规模的持续增加，应对流量潮汐现象的虚机调度也日趋重要；

➤ 随着DPI系统中对视频音频处理需求的增加，计算功耗的消耗更大幅增加，同时，报文对内存缓存和外存缓存的要求也日趋增加。

结合这些趋势，我们可以看到，采用MIPS多核处理器来解决DPI的问题，从短期来看，可以在L4-L7特征匹配和信令解码方面做到同等性能比X86更低的功耗，但是从长期来看，缺乏机器学习生态系统支持、缺乏虚拟机调度支持，缺乏大容量内外存储器，会让MIPS多核处理器在未来大规模部署DPI系统时，限制DPI的未来扩展能力。

机架式设备的限制

从上面逐步梳理分析来看，X86/ARMv64这样的通用计算CPU才是大规模DPI系统实现和部署的未来之路，那么，是否意味着将X86放到前端设备的机架中，就能为用户提供高集成度的DPI方案呢？答案依然是否定的。原因在于，机架有限的插槽空间会限制X86 CPU的选择，插槽空间小意味着对功耗要求的苛刻，意味着当前高端通用CPU很难在插槽中获得真正落地，意味着当系统需要GPU加速、需要内存和外存等大量缓存的时候，作为插槽单板的X86很难提供和独立服务器可以比肩的扩展能力。

当前我们知道，在正交或者ATCA中放置的X86 CPU，比主流服务器上的CPU落后两代，主频和核心数量也是主流服务器的70%以下，这样的X86 CPU，根本不足以提供DPI需要的计算性能。

成本是第另一个重要的问题。前端设备的机架插卡空间，每个槽位不仅仅意味着物理空间的成本，更意味着对机架交换板和电源成本的分担，这两者给本来就比通用服务器性能要低一半的X86插槽带来了一倍以上的成本增加。因此，用X86集成到前端设备中，放弃通用服务器低成本的横向扩展能力，这样的技术路线无法支持DPI的部署规模和功能特性持续演进。

未来DPI整体架构的判断

未来，试图整合DPI、存储和可视分析的一体化前端设备会随着网络可视分析系统规模的扩大而越来越无法适应业务可视分析对软件复杂度和系统规模的要求。相反，就像今天互联网服务商的业务全部云化、5G业务正在云化⼀样，随着通用计算CPU算力的持续提升，随着可编程交换芯片标准化和灵活度的持续提升，我们相信，业务可视分析也正在向“云”进行演化：

➤ 各种L2-L4的预处理和部分L4-L7的深度处理会被软件可定义、芯片可编程的智能可视交换机取代；

➤ 高密度I/O端口和灵活L2-L4层处理流程，并含有少量L4-L7内容特征识别过滤能力的“智能”线路卡将成为盒式智能可视交换机；

➤ 盒式智能可视交换机实现了80%前端流量的处理，还有20%前端流量处理，例如用户身份和数据面的关联、 报文会话重组、去重、（合法）解密等，会迁移到通用计算CPU中，以流量预处理NFV的方式实现；

➤ DPI流量分析则会进一步向后端系统迁移，形成混合了L7元数据生成、大数据分析与机器学习的DPI分析私有云。

最后，总结一下。

在Asterfusion的整体解决方案中，通过“智能可视交换机+流量预处理NFV”提供的VaaS（Visibility-as-a-Service，可视即服务）将会成为重要的IT基础设施之⼀；以VaaS为前端的可视化系统私有云，会按照标准私有云的建设方式，用通过SDN交换机互联的、可以大规模横向扩展的服务器集群来进行硬件基础设施的建设。此时，我们更欣喜地看到，无论是VaaS前端，还是可视化系统私有云后端，所有的基础设施都会被简化成智能可视交换机和标准服务器两种硬件。Asterfusion星融正是这样的简洁、归一、标准和优雅的软硬件开放系统的重要方案提供商。Asterfusion的开放软硬件平台将为可视化系统提供极具性能、成本和扩展能力优势的基础设施。

关注星融元

云中的网络自从诞生以来，一直就是热门话题。

2005年前后出现的、基于隧道技术的二层虚拟网络逐步部署和在生产环境中的验证，

云网络（更确切地说是虚拟化网络）才走上了相对正确的发展道路。

二层虚拟网络（Layer 2 Overlay Virtual Network），指采用隧道技术在底层网络上构建出来的供每个租户使用的虚拟网络。根据需求，每个租户可以拥有一个或者多个二层虚拟网络；对于租户的虚拟计算节点来说，运行在二层虚拟网络上并不需要满足任何特殊要求，与运行在标准的Ethernet/IP网络上并无二致。也就是说，原先的业务、工具、协议完全可以无差别地运行在这样的二层虚拟网络之上而不用做任何改动。

但是，云计算的本质（虚拟化、虚拟节点迁移、虚拟节点二层可达）却使得二层虚拟网络对底层网络提出了特殊的需求，而这些需求在传统的园区物理网络中是根本不需要考虑的。简单总结下来，这些特殊的需求包括：同一张物理网络承载多个租户的虚拟网络、租户的虚拟网络所用的IP地址空间可以重叠、属于同一租户的虚拟计算节点能够在物理服务器之间（即不同的物理交换机之间）迁移、虚拟计算节点迁移时不允许更改其IP地址等。

为了满足上述需求，云中的二层虚拟网络大致经历了如下几个发展阶段：

三层方案：三层架构的底层网络承载运行在服务器中的二层虚拟网络

这种方案中的底层网络完全沿用了园区网络的架构，从上到下分别是核心、汇聚和接入三层，因此称为三层方案。而二层虚拟网络的所有功能，包括VXLAN（Virtual eXtensible Local Area Network）和VTEP（VXLAN Tunnel End Point）及其相关功能，则完全运行在物理服务器内部的vSwitch上，底层网络只是被用作最简单的转发通道，以隧道的方式来转发物理服务器发送的二层虚拟网络流量，根本不用关心二层虚拟网络的任何细节信息。

二层方案-框式Spine：底层网络由三层架构进化为以框式Spine为核心的二层架构

当性能瓶颈和可扩展性限制在三层方案中愈演愈烈时，二层架构的CLOS交换网络被引入到新一代数据中心网络的设计中来，底层网络由三层架构演进为二层架构。CLOS交换网络一般由两层交换机搭建而成，位于网络核心层的被称为Spine交换机，位于接入层、用来接入服务器的则被称为Leaf交换机（或ToR交换机，Top of Rack），Spine和Leaf之间则采用full-mesh全连接。这个时期的二层架构CLOS交换网络的Spine一般由两台（或多台，取决于Leaf交换机的上行接口数量）大容量的框式交换机（称为Spine交换机）承担，Leaf则是由具备48个10G接口和2-6个高速上行接口（40G或100G，向上连接到Spine）的1RU高盒式交换机承担。显而易见，这样的架构通过减少报文转发的跳数和在Spine/Leaf之间构建负载分担的多链路很好地解决了三层方案的性能瓶颈问题，也通过框式Spine的纵向扩展能力（Sale-up）在一定程度上解决了可扩展性的限制。在这种架构的网络中，二层虚拟网络仍然运行在物理服务器中的vSwitch上，底层网络依然只是被用作最简单的转发通道来转发物理服务器发送的二层虚拟网络流量。

二层方案-盒式Spine：二层方案的核心由框式Spine进化为盒式Spine

云数据中心的规模越来越大，框式Spine和Scale-up终于也面临可扩展性有限和性价比太低的挑战，于是性价比更高的较大容量盒式Spine和横向扩展能力（Scale-out）被引入到CLOS网络的设计中。

在以盒式Spine作为核心的架构中，多个盒式Spine被部署在核心层，取代了原先的两个框式Spine，并且利用CLOS架构天然的横向可扩展性，为云计算带来了在交换性能、可扩展性、性价比几方面综合最优的底层网络。在这个方案中，二层虚拟网络依然运行在物理服务器中的vSwitch上，底层网络依然只是最简单的传送通道。

显而易见，在这三种方案中，二层虚拟网络都是运行在物理服务器内部，由vSwitch软件占用物理服务器CPU的计算力来模拟的，因此我们将这三种架构统称为“vSwitch方案”。而后，第四种方案出现了——硬件/EVPN方案，它最大的不同是：二层虚拟网络的功能开始从物理服务器向底层网络迁移。

• 基于“硬件/EVPN方案”的云网络，采用高性能硬件平台构建底层Underlay网络；
• 属于所有租户的二层Overlay虚拟网络从物理服务器的计算空间卸载到高性能的底层Underlay网络上，将被二层Overlay虚拟网络耗费的大量CPU计算力释放出来；
• 使用MP-BGP EVPN为二层Overlay虚拟网络构建独立的控制平面，降低维护复杂度、提升系统整体效率。

“硬件/EVPN方案”的优点显而易见，它将二层虚拟网络中非常耗费计算力的功能从物理服务器迁移到底层网络的物理交换机上，让二层Overlay虚拟网络回归到底层Underlay网络的高性能硬件平台之上，不再大量耗费物理服务器CPU的计算力，因此其性能和效率显然优于“vSwitch方案”。

同时，“硬件/EVPN方案”采用高性能网络硬件平台实现封装、去封装等功能，进一步提升二层Overlay虚拟网络的整体性能。并且，独立的MP-BGP EVPN控制平面为二层Overlay虚拟网络提供多租户的路由空间隔离，隧道的自动发现和部署，数据平面广播的有效抑制。

从2005年至今，云网络一路发展演进到“硬件/EVPN方案”，云中的二层虚拟网络需求似乎已经得到了完美的解决。

只是，遗憾的是，二层虚拟网络对计算节点容量的巨大需求与Leaf交换机转发信息表项空间的局限性之间存在着不可调和的矛盾！

这对矛盾使得“硬件/EVPN方案”无法真正在生产环境中部署。先进的架构的确解决了云的性能问题，却也成为限制云的整体规模增长的瓶颈。

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

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

基于创新的整网FIB融合架构、协议无限的可编程能力、深度报文检测能力、开放透明的网络操作系统和统一开放的硬件平台设计， Asterfusion（星融）云网络将为云计算构建下一代高性能网络，将网络真正融合到云中，为我们在云网络之路上的探索翻开新的篇章，完美地解决大规模云数据中心的关键需求：

• 底层网络容量Scale-wide扩展：每张底层网络可支持从768到4,096台物理服务器
• 超大规模虚拟网络容量：每张底层网络最大可支持64,000租户和16,384,000虚拟计算节点
• 丰富的接口类型：从10G光/电到400GQSFP56-DD
• 线速交换性能：VXLAN隧道的封装与去封装和NSF的处理完全不影响交换性能
• 丰富的NSF：包括L4LB、NAT、DDoS等最常用的NSF功能
• 端到端的QoS能力：0丢包率、超低延时确保SLA
• 应用可视化：基于深度报文头检测的网络遥测功能帮助云中关键业务优化运行
• 与CloudOS的深度融合：可被CloudOS自动、集中管理，将DevOps扩展到网络