标签： 中立科普

关注星融元

从运维需求的传递链条来看，云网络和园区网络也高度相似。首先，租户（用户）的业务开通/变更申请会提交至管理平台（运维部门），管理平台（运维部门）分解任务后，下发给网络控制器（网络运维人员），由他们完成具体网络配置并将结果反馈给需求方。当然，云网络中依靠网络控制器和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接口，让网络随需而动。

关注星融元

从旧时代一路走来的传统园区网络架构背负了过多的历史包袱，这些包袱在当时的技术发展背景、网络客观状况以及工程师对网络的理解的环境中，都是不得不支付的代价。今天，随着开放网络架构在云网络中的概念验证、规模部署和蓬勃发展，支撑技术与产品已经完全具备了帮助园区网络甩掉这些历史包袱的条件。因此，基于开放网络架构建设云化园区网络时所坚持的唯一原则就是：极简。接下来，我们从若干个方面看看这些极简的建设思路，以及给园区网络带来的好处。

抛弃二层网络，消除园区广播风暴

以太网工作在网络参考模型的二层（Layer 2，简写为L2），其大部分交互逻辑建立在广播这种机制之上，因此是一种高效的通信协议。为这种高效所支付的代价是，当在一定范围内（例如，跨越两台以上的交换机）部署以太网时，需要将广播报文在不同的交换机之间传播，由此则带来了潜在的广播风暴风险；为了规避这种风险，又出现了类似于STP（Spanning Tree Protocol，生成树协议）及其各种相关的协议和保护机制。由此，大规模部署的二层以太网结构变得越来越复杂、健壮性变得越来越差，建设和维护成本都高居不下。究其根本原因，基本可以认为是（大范围的二层）广播导致了这一切的发生。更为严峻的是，很多网络安全漏洞，都是利用以太网的广播机制工作的。那么，在不破坏以太网基础工作原理的基础之上，如何解决这个问题？

云化园区网络架构解决这个问题的方法非常简单，也非常优雅：将L2的工作范围限制在接入终端和其所连接接入Leaf的端口之间，在确保以太网能正常工作的前提下，最大限度地压缩L2区域，彻底消除以太网广播在网络中的传播，从而将广播带来的各种复杂度、脆弱性和安全风险从根源上消除掉。

抛弃L2的L3 IP Fabric

如上图所示，一旦以太网报文进入到接入Leaf的物理端口，L2就会被彻底终结，取而代之的是一个基于IP的网络。IP工作在网络参考模型的三层（Layer 3，简写为L3），这个协议在设计之初就充分地考虑了环路规避、多路径转发、高可靠、故障自愈等因素，因此在L2广播中面临的各种挑战，在L3的世界里天然不存在。而且，L2转L3的处理只发生网络侧，对于每一个接入终端来说是完全透明的，接入终端无需为此做出任何调整。借用云网络中的概念，我们也可以用IP Fabric来指代这样的园区网络的主体。

可以看到，在云化园区网络中，管理员只需要根据不同的业务需求设置不同的L3子网以隔离不同的业务，而无需配置和维护复杂的各种STP、全局VLAN、广播抑制等L2功能。尤为重要的是，经过如此的简化，网络的可靠性和健壮性是不降反升的。

统一极简的BGP园区路由

IP协议在诞生的初期，互联网的各个部分非常复杂，各种规模、各种结构、各种速率、各种网络协议、各种运营主体不一而足。因此，早期的网络工程师不得不开发了各种路由协议来应对如上的局面。这些路由协议包括RIP、OSPF、IS-IS等IGP（Internal Gateway Protocol，内部网关协议）和BGP这种EGP（External Gateway Protocol，外部网关协议），不同的网络内部运行着不同的IGP，不同的网络之间需要互联时则采用EGP（即BGP）。长期以来，复杂的路由结构一直是令网络建设者和管理员战战兢兢的雷区，稍有不慎就会因路由的错误配置导致网络的路由震荡、路由丢失甚至整网瘫痪；而这样的路由结构也一直沿袭到传统的园区网络架构内部。

统一的BGP路由

本着极简的原则，云化园区网络架构抛弃了“IGP+EGP”的复杂路由结构，而是采用BGP这种高效简捷、控制能力超强的路由协议统一了整网的路由机制。在云化园区网络架构中：

• 无论是在子网内部，还是在子网之间，全部采用一种路由协议，即BGP（更确切地说，是eBGP），管理员无需再为多种IGP和BGP的混合部署而头痛；
• 网络的Spine层和Leaf层分别运行着配置逻辑完全一致的BGP路由协议实体，分处于不同的两个AS（Autonomous System，自治系统）中，彼此之间通过eBGP连接交互路由信息，最终将路由同步到全网；
• 在整网范围内，则运行着简化的EVPN（Ethernet VPN，以太网VPN）或扩展的MP-BGP（Multi-Protocol BGP，多协议BGP），负责完成不同逻辑网络的路由信息同步和分布式网关信息的传递；
• 极简的配置逻辑让网络管理员只需要使能BGP、做最基础的连接建立即可完成整网的路由连通，对于经验丰富的网络管理员，通过操作BGP丰富的属性参数和策略机制，能够实现各种灵活的路由传播策略和控制；
• 这种统一路由架构对网络管理员的技能要求也尽量集中到了一种协议上，非常有利于管理效率的提升和综合成本的降低。

支持园区无缝漫游的高性能分布式网关

网关是一个子网中所有终端的出口设备，即，当一个终端（A）要与处于另一个子网的终端（B）进行通信时，A只需要将通信信息交给自己的网关即可，由网关完成信息的进一步向外传递（到B）、从B返回信息的接收、再将返回信息发送到的终端（A）上。从这个逻辑可以看出，对于一个子网来说，网关一定是一个集中的点；事实上，在传统园区网络架构中，也的确如此。

支持无缝漫游的高性能分布式网关

在云化园区网络架构中则不同：

• 一个子网的网关以分布式的形式存在于每一个接入Leaf上（这也是分布式网关这个名字的由来），充分利用每一个接入Leaf的能力，所有的跨子网转发动作在最近的分布式网关上完成，让网关功能不再成为压垮网络中某一台设备的潜在风险，同时大幅度提升整网的转发效率；
• 当移动终端发生漫游时，分布式网关的作用尤为重要，因为漫游后的接入Leaf上已经配置了网关信息，并且自动学习和同步了漫游终端的IP/MAC信息（详细解释如下一节），因此漫游后的终端可以平滑地重新接入网络（所发信息无需再到一个“集中的网关”上去兜圈子），并且漫游过程中业务不断连（即确保不丢包，因为漫游后的接入Leaf上已经有了该漫游终端的所有信息）；
• 对于网络管理员来说，只需要在网络初始化时一次性配置好所有分布式网关的信息即可，无需在运行过程中动态调整，从而进一步降低运维的复杂度。

抛弃生成树协议，天然无环路的网络结构

在有环路的L2网络中，如前文所述，为了规避广播风暴风险，往往会部署STP协议（以及由STP进化而来的RSTP、MSTP等协议），而部署STP的另外一个代价就是：必须人为地阻塞掉一半的物理线路使其处于不工作状态（即浪费一半的物理带宽），从而确保没有环路出现、L2网络能够正常工作；并且，STP的算法决定了这样的L2网络的规模无法做大，当交换机数量增长到100台左右时，网络则仅仅只在理论上具备可行性了。

天然无环的网络结构

云化园区网络架构很好地解决了上述问题：

• 利用Clos结构，云化园区网络是一个天然无环的网络，因此，相较于同样规模的传统架构园区网络，无需浪费掉一半的线路资源，即，在同等线路带宽的投入下，云化园区网络可接入终端的数量是传统园区网络的一倍（或者，在同等接入终端数量的前提下，云化园区网络所需要投入的带宽资源是传统园区网络的一半）；
•  如前所述，借助IP协议的各种L3能力，无环的云化园区网络能够做到超大规模，网络中交换机的数量不再受STP的理论限制，几百台、上千台的交换机组成的云化园区网络能够接入几十万的终端，组建超大规模的园区网络；
•  最后，当将网络中各种额外的复杂因素去除掉以后，整个网络的建设与运维难度都会大幅度降低，节省网络建设者的综合成本。

去堆叠，并且更可靠

传统园区网络架构中，为了向一些终端提供高可靠的接入服务，往往会采用堆叠技术。堆叠技术将两台（甚至有可能是多台）同规格的接入交换机在逻辑上虚拟成一台交换机，让终端通过不同的线路分别连接到不同的接入交换机上；当堆叠组中的一台交换机故障后，由另一台交换机将自动接管网络流量，从而达到高可靠接入网络的目的。在某一些方案中，这样的堆叠甚至会出现在更高层级的交换机、或者不同层级的交换机之间。

通过上面的描述，已经能够感觉到堆叠是一种非常复杂的组网模型，其流量处理逻辑、故障恢复逻辑都及其复杂。从软件设计、开发的角度来说，要将两个完全独立运行的系统，从初始配置、到运行状态、到流量转发、再到出现故障时的行为完全同步、协调起来，是一件非常困难的事情。很多网络出现全网级的故障甚至瘫痪，都是因为交换机内部的堆叠软件故障所引发的。

去堆叠，并且更可靠的网络

在云化园区网络架构中，则彻底的抛弃了堆叠方案，而是采用基于L3能力实现的一种可靠度更高、复杂度约等于零的方案：

• 接入终端并不需要为此方案做出任何调整，依然是通过两条（或多条）的线路、采用通用的Bond技术，上连到不同的接入Leaf上去；
• 接入Leaf通过使用ARP学习、32位主机路由、BGP同步等功能，利用L3网络天然的高可靠、多路径能力，达到跟传统堆叠一样的效果；
• 因为不涉及复杂的堆叠软件的开发，因此系统的稳定性非常高，不会因为复杂的堆叠逻辑引入潜在的Bug，因此是一个可靠性更高的方案；
• 利用L3网络的ECMP负载分担能力，可以充分利用交换机之间的所有带宽传递报文，使得网络性能更高；
• 对于网络管理员来说，不需再陷入到堆叠复杂的组网逻辑、纷繁的设备配置、脆弱的状态同步等问题中无法自拔。

基于网络安全策略自学习的“内生安全”

DHCP（Dynamic Host Configuration Protocol，动态主机配置协议）的重要功能之一是为接入网络的终端分配规划好的IP地址，同时为终端动态配置网关地址、DNS地址等信息。

基于自学习的主动安全、内生安全

云化园区网络将主动跟踪任何接入终端与DHCP服务器之间的交互过程，对于所有通过DHCP服务获取自己IP地址的终端，其IP/MAC地址信息都会被网络所记录，所有来自这些终端的网络通信都将被允许通过、正常转发。而对于那些没有通过DHCP服务器获得合法地址的终端来说，网络会拒绝此类终端的接入，来自这些终端的网络流量将在与其直接相连的接入Leaf的端口上直接被丢弃。同样的学习过程也会发生在ARP的交互过程中、数据报文的转发过程中。

从上述描述不难发现，云化园区网络通过自学习手段，具备了主动安全和内生安全的机制，不再依赖于网络管理员复杂的策略配置。

安全控制表项（ACL）的手工配置

并非所有接入网络的终端都需要通过DHCP来获取自己的配置信息。例如，网络中的打印机，往往是被配置了静态的IP地址，平时是处于静默状态，一旦有打印请求到来时，就会直接开始传递需要被打印的信息。这种情况如何处理？

安全控制表项的手工配置

在云化园区网络架构中，处理这种情况的机制是安全控制表项的手工配置。手工配置与自动学习相结合，将网络中所有类型的终端全部纳入到统一安全防护的范畴之内。

下一篇，我们将从园区网络的运维层面（软件可编程、自动化、NetDevOps…）来继续探讨。

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

• 基于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接口，让网络随需而动。