标签： 中立科普

关注星融元

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