关注星融元

从运维需求的传递链条来看，云网络和园区网络也高度相似。首先，租户（用户）的业务开通/变更申请会提交至管理平台（运维部门），管理平台（运维部门）分解任务后，下发给网络控制器（网络运维人员），由他们完成具体网络配置并将结果反馈给需求方。当然，云网络中依靠网络控制器和REST API接口早已实现了自动化运维，而传统园区大多还停留在依靠网络管理员和手工配置网络设备的“人肉运维”阶段。

如今，在云化园区网络架构下，我们将有机会把云中广泛使用的，面向未来的软件编程、自动化、NetDevOps等先进技术和理念应用到园区场景，在网络运维方面大大解放生产力，提高效率！

集中控制器与分布式路由/转发

与云网络类似，云化的园区网络架构采用了“集中控制器+分布式路由+分布式转发”的整体结构，具体如下图所示：

集中控制器+分布式路由+分布式转发

在云化园区网络中：

• 网络管理员对网络的配置通过具备图形化界面的网络控制器统一进行，无需再通过命令行逐台设备地进行，网络控制器在定位和功能设计方面超越了传统的集中网管系统，除了能够完成基础的配置管理功能，还可以将网络管理员的意图转换为对网络中每一台网络设备的配置，并且实时收集、分析和呈现网络的运行状态，帮助网络管理员避免繁重的配置运维工作、降低引入人为错误的风险、快速预警风险和定位故障；
• 在基于OpenFlow的SDN模型中，所有的路由学习与计算能力是集中式的部署在网络控制器上的，网络设备只需要接受来自网络控制器下发的转发表、按照转发表完成转发动作即可。在云化园区网络中则不同，网络的路由学习计算功能分布式地部署在所有的网络设备之上，借助IP网络成熟高效的路由算法，智能学习、动态传播、快速同步整网的路由信息，充分利用了每台网络设备的计算能力，并且有效地规避了网络控制器单点故障带来的风险；
• 与分布式路由相对应的，则是所有网络流量在所有网络设备上的分布式转发，无需在某些特殊情况下将流量集中到网络控制器上做集中转发，对于无法转发的错误流量，网络设备将直接丢弃，这一点也从根本上解决了OpenFlow SDN模型性能低、可靠性低的问题。

开放的编程接口

借助于开放网络操作系统的软件编程接口能力，在云化园区网络中，各种网络业务与应用可以通过软件编程的方式自动、按需地调度网络，网络管理员甚至可以开发自有的网络应用以满足各种业务和应用的需求，让“应用定义网络”成为现实。

开放的编程接口

上图，以星融元的开放网络操作系统AsterNOS为例说明了如上的概念。AsterNOS SDK所提供的面向机器的软件编程接口使得在各种环境中对网络进行软件定义成为可能。在运行着AsterNOS的网络中，使用者除了使用传统的命令行、WebUI对网络进行基础的运维之外，还可以通过AsterNOS SDK所提供的REST API和/或System API自动化地、高效地运维网络，甚至为自己的网络开发新的应用。

分层简化配置

传统园区网络中，往往是“一个设备、一个配置”，即每一台网络设备的配置都是不同的。对于较大规模、结构复杂的网络来说，网络配置和配置的维护、变更是网络管理员所面临的巨大挑战之一，面对复杂的网络结构、众多的网络设备、多个版本的网络配置文件，稍有不慎就会因为错误配置引发网络故障。

分层简化配置

云化园区网络架构追求极简的另一个有力例证就是将网络设备的配置改进为“一层设备、一个配置”。简单来说，通过创新的设计，云化园区网络架构彻底规避了“同层设备、配置不同”的问题，在一个二级三层的Clos网络中，无论有几十台还是上百台网络设备，只需要维护三个网络配置即可，同层设备在配置方面的差异性，完全通过软件设计上的创新和初始配置的自动化屏蔽了。在云化园区网络中，网络配置的数量不再被网络设备的总数量所决定，而是只跟网络的层数相关，将配置管理工作带给网络运维的复杂度降低了2-3个数量级，帮助网络的拥有者大幅度降低运维的综合成本。

零配置部署

进一步的，云化园区网络架构引入了在服务器、云网络运维体系中广泛使用的零配置部署机制。

零配置部署

在零配置部署机制中：

• 网络管理员在管理服务器上部署文件传输系统的服务器端，并将网络操作系统镜像和按照规划生成的网络配置管理文件存放在指定目录下；
• 云化园区网络的每台交换机上都运行着开源软件ONIE（Open Network Install Environment，开放网络安装环境），ONIE在交换机加电开机时自动运行并连接到管理服务器，按照预先设置的规则申请特定的网络操作系统镜像和对应的配置文件；
• 管理服务器将系统镜像和配置文件传送到交换机后，交换机将自动加载新获得的网络操作系统镜像，并根据配置文件完成系统的初始配置；
• 以上申请、加载、配置的过程均不需要网络管理员介入，完全自动化地完成，试想，对于一个有着成百上千台交换机的网络来说，零配置部署机制对网络升级、变更所带来的效率提升是非常可观的。

NetDevOps

DevOps（Development and Operations，开发运营）是一种新型的产品交付与运营模型，它将与产品生命周期和业务运营过程中的各个相关环节（例如研发、测试、部署、运营等）以一种空前的方法连接了起来。DevOps对应到开放网络世界中，就是NetDevOps。

云化园区网络架构天然地支持NetDevOps。下面，基于星融元的AsterNOS及其SDK、REST API，围绕一个安全运维场景来说明云化园区网络如何支持NetDevOps。

一个NetDevOps的示例

如上图所示，出于对安全的考虑，网络运维人员往往需要对重要的应用系统进行访问情况的审计与分析；针对这些应用系统，如果发生了访问控制的缺失、访问状况的异常，管理员希望第一时间得到通知，以便采取相应的动作。这些审计与分析的内容可能包括：网络对重要应用系统的访问是否进行了控制（以便判定该应用系统是否被保护）、对这些重要应用的访问情况是否发生了突然的变化（以便判定该应用系统是否处于可能的攻击中）等。

下面，我们就来看看通过AsterNOS SDK如何便捷、高效地实现这一需求。在网络中，访问控制一般是通过ACL（Access Control List，访问控制列表）实现的。

AsterNOS支持ACL功能，并且能够提供所有ACL被命中过的统计数据；AsterNOS SDK所提供的REST API中，包含对ACL各个字段和统计数据的访问接口，通过调用这些接口，即可直接获得ACL的这些信息用以分析。具体思路如下：

1. 重要的应用系统可以用IP地址来标识（如果需要更精确地定义，还可以增加该应用所使用的TCP/UDP端口信息）；
2. 通过调用REST API，获得AsterNOS中当前配置的所有ACL的“目的IP地址”字段，以便判断所定义的重要应用系统是否被ACL进行访问控制；
3. 通过调用REST API，获得对这些重要应用系统的访问量的统计信息，以便判断是否出现异常状况；
4. 对于出现的访问控制缺失或访问异常状况，该程序自动通知管理员进行干预。

假设运行着AsterNOS的网络设备的管理接口IP地址和端口为192.168.1.200:4430，则上述思路的示意性伪代码可以如下：

这段伪代码仅用于示意，并未严格地写出循环、边界条件判断、具体日志与告警实现等。其中，“GET https://192.168.1.200:4430/rest/v3/acl/…”即AsterNOS SDK中获取ACL及其具体信息的REST API，“TABLE_y:RULEz:”dst_ip””和“TABLE_y:RULEz:“stats””即一条ACL的“目的IP地址字段”和“该ACL的命中数量统计”。需要强调的是，编程者通过AsterNOS SDK的REST API获得的已经是ACL的每一个具体字段及其值，无需再使用复杂的文本解析程序进行处理。

将这段非常简单的程序用Docker进行容器化封装，部署在AsterNOS中，并且自动化地定时运行，即可实现前文所述的运维需求，并且，通过对更多ACL字段与值的调用，即可实现更高级的运维功能。

总结：新思路、新架构、新网络

云计算掀起数据中心网络的变革热潮，而随着中大型园区网络规模的进一步扩增，传统园区网络面临着运维复杂、扩展性差、架构封闭等诸多挑战，借鉴云数据中心网络的发展经验，星融元Asterfusion创新性地提出了新一代精简高效的云化园区网络架构。

我们可以看到基于开放网络架构的新一代云化园区网络的确会在方方面面为园区网络带来改变。总结来看，这些改变主要包括：

• 全新的网络规划思路：采用领先的开放网络理念，基于最新的数据中心级网络技术、开放的网络操作系统，“一网多用”地构建出能够同时承载多种业务的超大规模园区网络；
• 全新的网络建设架构：抛弃传统园区网络架构所背负的历史包袱，通过纯三层网络、统一路由结构、天然无环、去堆叠、自主内生安全等创新的技术，建设架构极简、更可靠、更安全、更高性能新一代园区网络；
• 全新的高效运维体系：将开放网络的集中控制器、软件可编程引入到园区网络的运维系统中以有效支持NetDevOps，同时通过简化配置、自动部署等创新性设计大幅度提升网络运维的效率。

所有这些改变，都将带给园区网络的拥有者和运营者最直接的价值：降低网络建设的成本，提升网络运营的效率，支撑无限创新的可能！

• 基于Spine/Leaf的精简架构，天然无环路，无需堆叠。
• 全三层组网，消除二层广播风暴的同时，还有效地隔绝了内网病毒的广播。
• 一套配置模板，全网自动化部署，设备上线即插即用。
• 支持云原生操作系统环境和开放的RESTful API接口，让网络随需而动。

关注星融元

从传统的园区网络架构说起

顾名思义，园区网络指的是部署在一个园区范围内的网络，这个网络被用来连接其所在园区内的所有固定终端（台式机、服务器、打印机等）、移动终端（笔记本电脑、平板电脑、智能手机、服务机器人等）和IoT终端（门禁、考勤机、摄像头、烟雾传感器等）；园区网络需要支持所有这些终端之间的互联互通，还需要按需将其中的一部分终端接入到互联网。

一个典型的园区网络往往由有线网络和无线网络两部分构成，无线网络负责通过WiFi接入各种移动终端和具备无线接入能力的IoT终端，有线网络负责接入各种固定终端和只具备有线接入能力的IoT终端；当然，无线网络最终也需要接入到有线网络中去，从而完成所有终端之间的互联互通。

在现实世界中，园区的规模或大或小，小到可能是一个容纳三五人的办公室，大到可以是同时容纳上万人、覆盖若干个大楼、甚至分布在多个城市的集团型的办公园区；相应的，园区网络的规模也可大可小，小到只需要接入个位数的各种终端，大到需要同时接入几十万数量的各种终端。

我们的讨论从一个典型的基于传统架构的园区网络模型开始。

图1：一个典型的基于传统架构的园区网络模型

在图1所示的模型中：

• 一个三层网络连接着若干二层网络，不同的区域往往划归到不同的二层网络，所有终端连接到不同的二层网络；
• 同一区域终端间的通信在本地二层网络内部完成，跨区域的终端间的通信由连接各个二层网络的三层网络完成；
• 所采用的网络设备（自下而上）一般包括：盒式的二层接入交换机、中等规模的框式汇聚层交换机和中/大规模的框式核心层交换机；
• 网络的扩展能力主要基于框式设备的纵向扩展能力；
• 网络的运维主要依赖于人工运维。

什么是开放网络架构的云网络？

在云计算发展的起步期，云的网络架构是参考传统园区网络搭建起来的。但云计算工程师很快便发现，这样的架构并不能满足云计算的业务所需，于是广大云计算工程师开始对云网络进行持续的改进和优化。

在市场需求与科技进步的双驱动之下，云网络经历了二十年的蜕变和升华。时至今日，尽管云网络架构诞生于园区网架构，但其发展早已远超后者——无论是整体的网络架构还是在硬件设备、扩展能力、运维能力等维度，云网络相比起传统园区网络都有了长足进步。

图2：一个主流的基于开放网络架构的云网络模型

在图2所示的模型中：

• 根据所连接服务器所处物理位置的不同，网络被分成了若干个POD，所有POD则通过一个更大的网络连接起来；
• 与传统园区网络架构不同的是，任何一个POD内的网络、连接所有POD的网络都是三层网络，网络的总体规模从连接几十台到几十万台服务器不等，这个网络往往被称为Underlay Network；
• 在同一个Underlay Network之上，管理员创建出不同的虚拟网络为云上的不同租户和不同业务提供连接服务，租户和业务并不感知Underlay Network的存在，只感知有一个（虚拟）网络为自己在服务，这个虚拟网络往往被称为Overlay Network；
• 云网络的搭建一般不再采用或大或小的框式网络设备，而是根据需求选择不同规格、性能的盒式设备，从而避免单设备的复杂度给整体网络运营和运维带来更高的成本和难度；
• 基于Clos架构，这些盒式网络设备可以组成从连接几十台服务器到几十万台服务器的不同规模的网络，并且网络规模可以按需横向扩展；
• 云网络的运维往往通过云管平台、网络控制器等实现自动化运维。

经过这些年的发展，为了区别于传统的网络架构，业界往往采用“开放网络架构”这样的术语来指代云网络架构。

随之而来的问题就是：如果将开放网络的架构及其技术推广到更广泛的网络世界，譬如园区网络，将给这些“更广泛的网络世界”带来什么样的改变？这些改变将会带来什么样的好处？

开放网络架构与技术将从哪些方面改变园区网络？

接下来，从网络的规划、建设、运维三个维度，我们分别探讨开放网络架构与技术有可能带给园区网络的改变，以及这些改变能够带来的好处。为了便于论述，我们将“基于开放网络架构和技术的园区网络”简称为“云化园区网络”，一来便于与“传统园区网络”方案进行区别，二来便于描述其本质（即“沿袭自云网络架构的新一代园区网络架构”）。

1. 多级CLOS结构的网络

如下图所示，在采用了开放网络架构的云化园区网络中，全部采用CLOS结构的组网模型。

多级CLOS结构的网络

以一个园区为例：

• 从楼层到整个园区，是个三级/四层的CLOS网络（Leaf-Spine结构的网络）：
  • 在楼层范围内，接入层交换机作为Leaf（也可称为接入Leaf），楼层汇聚交换机作为Spine（也可称为楼层Spine），构成第一级的CLOS网络；
  • 在楼栋范围内，楼层汇聚交换机作为Leaf，楼栋汇聚交换机作为Spine（也可称为楼栋Spine），构成第二级的CLOS网络；
  • 在园区范围内，楼栋汇聚交换机作为Leaf，园区汇聚交换机作为Spine（也可称为园区Spine），构成第三级的CLOS网络；
• 随着园区规模的从小到大，这个多级的CLOS网络能够从一级横向扩展至多级，使得网络能够接入的终端数量从几十个到几十万个不等，并且，扩展的过程中，原有的网络架构完全保持不变，新扩展的模块与原有模块架构完全一致，从而最大限度地降低了维护的复杂度；
• 基于其横向扩展能力，这个多级CLOS网络完全采用盒式的单芯片交换机来搭建，彻底抛弃了传统网络架构中各种规模的框式设备，从而在最大限度上避免了框式网络硬件带来的高昂成本；
• 在图中所示的三级CLOS网络中，任意两个终端之间的通信可保证在1跳（最优情况）到7跳（最坏情况）之内完成，并且因为路由结构的设计，所有的网络通信会充分利用所有的物理线路，因此网络通信质量是高性能、高可靠且可以预测的，从而在最大限度上确保了网络提供服务的质量。

2. 数据中心级的交换机设计

基于开放网络架构的云网络在过往十几年的发展过程中，在交换机设计方面逐渐形成了其独有的特点，我们将这些特点称之为数据中心级的交换机设计。

数据中心级的交换机设计

将这些特点运用于云化园区网络会极大地提升园区网络的架构先进性、整体性能和可持续发展性：

• 开放的硬件架构：由控制系统、数据中心级交换芯片、监控系统、电源、风扇等标准化模块构成，设计理念不再追求传统厂商主导的大规模、复杂的框式结构，而是追求标准化、单芯片、简单的结构，并且通过Clos架构来提升网络的横向扩展能力和整体接入能力；
• 数据中心级交换芯片：交换容量从2Tbps开始，依次向上增长到3.2Tbps、6.4Tbps、12.8Tbps、25.6Tbps，甚至51.2Tbps，基于这样容量芯片的单芯片、盒式交换机部署在园区网络的核心位置上足以承载大规模网络的流量；
• 超高端口密度：无论是接入Leaf还是各级Spine交换机，均可以提供超高密度的端口，譬如，在1U的空间内，接入Leaf可以提供48个千兆PoE接入端口和6个25GE上行端口，楼层Spine可以提供48个25GE接入端口和8个100GE上行端口，楼栋Spine则可以采用具备32个或者64个100GE端口的交换机，对于超大规模的园区，则可以采用具备128个甚至256个100GE端口的交换机作为园区Spine；
• 超高转发性能：所有数据中心级交换机均支持多流水线、全线速转发，从而保障云化园区网络支持零阻塞、无收敛的性能，这一点在今天大规模的园区网络中非常有价值，能够确保大量的访问数据中心的流量（业务系统访问等）和终端之间的P2P流量（音视频交流、文件传送等）无损的传送，提升园区网络用户的使用体验；
• 丰富的端口类型：25GE、100GE接口已经数据中心普遍使用，400GE接口也正在规模部署阶段，这些高速接口能够将网络传送每比特的成本降低至传统方案的20%~50%，并且能够有效地在未来五到八年之内保护用户的投资，因此，在云化园区网络中广泛部署此类高速接口将大幅度降低园区网络的TCO，更值得一提的是，在接入Leaf上支持Multi-Giga接口（2.5Gbps/5Gbps）可以为即将规模部署的Wi-Fi 6提前做好物理接入带宽的准备。

3. 开放的网络操作系统

开放的网络操作系统是开放网络架构的灵魂，它使得网络管理员能够以SDN（Software Defined Network，软件定义网络）、IBN（Intention-Based Network，基于意图的网络）和NetDevOps的方式运维开放的网络。

开放的网络操作系统

上图以星融元的开放网络操作系统AsterNOS为例，描述了一个基于SONiC的网络操作系统在整个云网络中的位置、功能以及与周边系统、角色的关系。可以类比的是，当我们将同样的操作系统引入到云化园区网络后，网络管理员将能够：

• 通过图形化界面将网络部署、变更的意图提交给网络控制器，即可自动化完成对所有网络设备的配置，即避免了繁琐的逐设备的命令行配置，又能够有效避免人工操作引入的人为错误，从而提升网络的整体健壮性；
• 网络管理员无需再在每台网络设备上维护纷繁复杂的配置文件，而是好像维护代码一样在服务器上完成对网络配置文件的变更管理、版本管理、模拟上线运行等工作，并且网络启动时配置文件自动完成加载，无需管理员手工干预；
• 将日常运维网络的各种软件工具，以容器化的形式运行到开放网络操作系统中去，既提升了网络运维效率，又节省了网络运维的成本（不再需要部署软件工具的物理服务器）；
• 将开源世界中的各种软件集成到现有的网络运维体系中去，并且将它们与网络操作系统紧密的融合在一起，创造出前所未有的网络运维方法；
• 甚至，网络管理员能够通过调用开放网络操作系统提供的各类API，在各种基础网络功能之上编制出符合自身业务需求的“新”网络功能/设备来，从而真正让“应用定义网络”；
• 更为重要的是，当园区网络与数据中心网络使用同一个网络操作系统时，将对网络运维带来运维效率提升、运维人员减少、设备备件统一等诸多便利之处。

4. 一网多用

在同一张云网络的物理网络（Underlay）之上可以为不同的租户创建不同的虚拟网络（Overlay），从而实现“一张网络为多个租户服务、并且彼此隔离”的目的。在云化园区网络上，亦是如此，可以为不同的业务、不同的用户群创建彼此隔离的“逻辑网络”。

一网多用

在上图中，三种不同的业务（办公系统、业务系统和物联网）承载在同一张云化园区网络之上，云化园区网络提供了三张彼此隔离的逻辑网络为不同的业务服务，每种业务都认为自己被承载在一张专用的网络之上，无需感知其他逻辑网络的存在。

在云化园区网络之上创建这些彼此隔离的逻辑网络时，可以采用以下不同的方法：

• 完全复制云网络基于VXLAN（Virtual eXtensible Local Area Network，虚拟扩展局域网）的隔离方案，适用于超大规模、网络空间复杂且重叠的园区网络，是一种比较重的方案；
• 如果园区网络是扁平的地址空间，但是对路由隔离的要求比较严格，则可以利用VRF（Virtual Routing and Forwarding，虚拟路由与转发）的隔离性，将不同的逻辑网络隔离到多个不同的VRF中；相较于VXLAN方案，多VRF方案复杂度较低、开销较小；
• 如果园区网络是扁平的地址空间，并且规模较小、对隔离的要求仅限于对不同业务之间互通的访问控制，则可采用IP子网规划和ACL（Accessing Control List，访问控制列表）的组合，即可达成目标；相较于前两种方案，该方案基本不会带来额外的复杂度、开销约等于零，是最轻量的隔离方案。
• 因此，云化园区网络对多业务的支持采用的是“从大到小、越来越轻”的设计思路，可以支持接入从几十万终端到几十个终端不同规模的网络，并且采用越来越简单的逻辑隔离方案，降低部署与维护的复杂度。

下一篇我们将从园区网络的建设层面（路由、网关、广播风暴、园区网络安全、高可靠部署、园区漫游……）来继续探讨。

借鉴云数据中心网络的发展经验，星融元Asterfusion创新性地提出了新一代精简高效的云化园区网络架构。其中，型号丰富的CX-M系列主要作为接入或汇聚交换机，而高速率、高密度的CX-N系列作为汇聚和核心交换机。

• 基于Spine/Leaf的精简架构，天然无环路，无需堆叠。
• 全三层组网，消除二层广播风暴的同时，还有效地隔绝了内网病毒的广播。
• 一套配置模板，全网自动化部署，设备上线即插即用。
• 支持云原生操作系统环境和开放的RESTful API接口，让网络随需而动。