作者简介：唐昊，现就职于华为，从事云网络研发工作。本文所有观点仅代表作者个人观点，与作者现在或者之前所在的公司无关。
管理网络一直以来是一个十分复杂的工作，网络工程师需要负责管理网络设备、提供用户权限、配置网络策略等等工作。根据Gartner的数据显示，75%的组织仍然通过手动操作来管理他们的网络，很多组织仍然使用最初的命令行界面（CLI）。CLI的缺点也很明显，因为缺少错误特定的返回代码，自动化工具还必须处理输入或输出文本中的偶尔错字。CLI通常与手动配置更改有关，这也是造成企业网络中断的主要原因。
网络业界的发展总是伴随着新技术的应用，五年前，数据中心是Ethernet Fabrics，后来是SDN，其核心理念是将转发与控制进行分离，以此提高网络的运行效率和网络的灵活性。目前是SD-WAN，随着SD-WAN的不断发展，网络领域最新的风口是基于意图的网络IBN（Intent based network）。Verification and Intent-Based Networking: Closing the Control Loop文章中，描述了基于意图网络的最基本的系统框架，如下图所示。
简单的讲就是把用户对网络的意图翻译成配置，然后通过网络自动化或网络编排的方式下发到设备上。最后对实际网络进行周期性的快照，验证是否符合用户意图，形成一个闭环。这里就不详细解释了，因为现在网上有许多文章解释IBN，大家可以搜一下。
Introduction
上一篇文章Robotron和Ansible如何实现网络可编程和自动化中，介绍了Facebook Robotron项目，有兴趣的人可以看一下论文作者Xiaozheng Tie在2017年Network@Scale会上的演讲，其中强调了FBNet对象模型的重要性，在Facebook里许多其他网络项目都是基于FBNet模型开发的。其中FCR - FBNet Command Runner是Robotron系统的一部分，负责对设备的进行下命令，目前已经开源。这里不详细介绍，有兴趣的人可以看这篇文章：Open source command runner for network devices。除此之外上一篇文章还介绍了Red Hat公司推出的Ansible网络自动化方案。本文将介绍几家巨头公司的可编程网络与验证项目，其中 Cisco Crosswork Change Automation 使用了Ansible对网络设备进行自动化部署。本文中还会介绍 Alibaba NetCraft 网络可编程项目和 Microsoft CrystalNet 网络仿真验证项目，笔者期待能通过本文起到抛砖引玉的作用，共同探讨与学习。
Cisco Crosswork Change Automation
当前网络运维处在一个拐点的位置上，从网络方面的投资来看，Capex（建网成本）和 Opex（运维成本），随着网络规模越来越大，网络建网成本会变得越来越低，但是运维成本会越来越高。这是一个很显著的一个特点。在今天的网络，部署一个新的结点，或者是开通一个新的功能，可能都是以天为单位的。比如在一个大型运营商里面，要开通一个跨省的线路，都是以月为单位。思科把IT部门的工作分为了两大类，如下图所示：
我们可以看到65%的变更都属于常规标准的变更。思科借鉴了许多工具，最终将标准化、流程化的日常网络运维工作变成一个自动化工具。思科可编程网络架构如下图所示：
- 从设备API架构来看思科提供了传统的CLI以及NETCONF、RESTCONF等协议接口。所支持的编码格式有：XML、JSON、YAML等。值得注意的是虽然现在大部分的厂商设备支持netconf协议了，但是在实际网络中，并不是所有的型号都支持netconf的全部功能。
- 从Data model数据模型来看，支持的数据有两大类Configuration（下发的配置命令）和Operation（设备的运行状态）。open model和native model分别是标准模型（例如openconfig）和厂商私有的模型。
- 思科支持使用第三方自动化工具进行部署，例如Ansible、puppet、chef。
在简单的了解思科可编程网络架构后，接下来介绍一下思科最近发布的网络自动化平台Cisco Crosswork Network Automation。这里只简单的介绍其中的一部分—Cisco Crosswork Change Automation，主要使用Ansible作为基础框架进行对网络设备管理及部署，流程图如下。
Cisco Crosswork Change Automation (CCCA) 不同与其他基于脚本的自动化工具. CCCA 是一个能够实现闭环的框架，主要由两部分组成:
- 配置变更管理：对外提供REST APIs，从仓库中获取Ansible 剧本（playbook）对其进行编排和初始化。使用设备可编程接口，可提供翻译成设备配置的能力。执行流程如下，预检查（pre-check）-> 执行（execute）-> 验证（Verify）-> 如果验证成功则进行Post-Check否则回退Rollback。
- 警告/验证引擎：监听消息通知端口，使用实时遥测（Telemetry）进行收集数据去验证配置意图，同时对设备状态进行监控报警。在传统的网络中，往往只是进行简单地监控（monitor），有许多不足的地方。网络监控广度和深度不足，所描述的信息和数据都是直接来自于底层设备的（low-level），而非用户期望的以规范化数据模型方式来表达。这对管理员的技能要求高，可用性保障困难。因为故障来源复杂（配置错误，软件故障，链路故障等），设备之间联系紧密, 并且存在故障扩散现象，整个系统缺乏有深度的全局网络数据视图。所以基于Telemetry这一网络遥测、实时监控的特性，能够全面地实时了解网络状态。Telemetry遥测的功能不仅仅能够获得数据流实时信息，而且能够获得实时的网络配置、流量统计、计数、报错、表项、环境、缓存等一些列信息。近期Google等云巨头推动 OpenConfig 的一个重要原因就是希望能够以单一标准化数据模型语言（YANG） 来定义数据和实时状态反馈（state streaming），其实就是数据定义加上 Telemetry 的特性。通过验证verification最后闭环这一步骤将low-level的设备数据与high-level的意图关联起来。网络的状态时时变化，执行时的状态与验证时的状态可能存在不一致，此时平台会主动地根据期望的状态对策略进行优化补救。
Alibaba NetCraft
作者Hongqiang Harry Liu目前就职于阿里，他所在的团队最近发表了一篇论文Automatic Life Cycle Management of Network Configurations，使我受益匪浅，所以在这简单介绍下这篇论文。该作者在网络可编程和验证领域发表过多篇论文，包括本文下一章介绍微软的网络模拟器，有兴趣的可以去他主页下载论文。
NetCraft是什么？它是基于网络数据模型对配置进行抽象，用于管理网络配置完整生命周期的一个自动化工具。它的初始版本已经商用，用于管理阿里的全球广域网。随着业务需求越来越多，现在网络的规模不断变大，网络变更也越来越频繁，尤其是在广域网。论文中对2016和2017年阿里发生的网络故障进行了分类总结，如下图所示：
配置导致的事故占65%，其中包括在变更中导致的占56%，网络配置bug占10%。很明显，配置变更占了总事故率的一大半。主要的原因有以下三点：
- 配置层面（low-level）更新是由high-level的意图所推导出来的，这一过程容易出错。
- 配置更新涉及到许多设备和协议，因此需要一个平滑的增量式的变更方案，这里涉及到编排，例如对设备进行配置变更的先后顺序，使得变更不影响到当前网络。
- 在变更中需要对发生的故障进行快速反应，发现问题后能够立马对设备进行平滑的回退。
未来最理想的管理网络方式是网络工程师只需要参与设计和更新网络意图，其余的一些底层的事情例如配置生成、增量式的配置更新、平滑的变更操作以及配置诊断及回退，能够用自动化软件去完成管理整个配置的生命周期。NetCraft就是为此设计，设计框架如下：
- 网络运维工程师创建一个目标网络模型，可以是描述整个网络的或者是只对一部分网络，把生成的模型输入到NetCraft。配置生成器（Configuration Generator）对目标模型进行解析，在这个过程中会结合对应的模板（modular template）生成目标配置。
- 与此同时，如果运维人员是对网络进行变更，那么变更计划（Transition Planner）会计算所有网络配置模块的相互依赖图（dependency graph）。每个配置模块都是简单和基础的原子化操作（接下来会具体讲）。这样可以保证增量的网络变更能够顺利平滑的进行。
- 目标配置（Target Configuration）和变更计划（Transition Planner）最终会放入到配置执行器里面（Configuration Executer），按照计划对这些配置模块一步一步的进行下发，同时会检查网络的状态，如果执行失败或者网络出现异常，那么将里面进行回退操作。
- 模型生成器（Model Generator）会当前网络配置进行抽象转译成网络模型，可用于诊断故障、配置关键属性比较等等。这一过程与开源的Batfish控制面结构有些相似，能够将各个厂商的配置进行解析最终生成统一的网络模型。
- 上图灰色所表示的四个模块大该用了10W行代码（Java）。
下图左边表示的cisco的配置模板，右边是根据模板生成的对应的网络配置。这一步骤与上篇文章中所讲到的Facebook Robotron和一些开源自动化部署工具方式类似，都是基于配置模板生成配置。因为不同设备厂商的配置命令语法不同，所以配置模板也一定不一样。可以使用Jinja或者其他语法去写模板，这取决于配置生成器的能力。
对于网络变更来说，输入一个最新的网络模型到NetCraft，系统会对当前运行的网络模型与输入的进行比较，计算每一层的不同。例如有没有节点或者链路被增加或删除了，有没有对结点或者链路的属性进行了修改等等。这时候Transition Planner需要准备好对应的配置模板。没有检查及回退的操作是极其不安全的。所以针对一些网络操作的配置模板，有以下四种shadow modules：Deactivate、Activate、Undo、Check。下图是BGP Peering配置模板的例子。
目前NetCraft使用了以下几种策略实现平滑安全的增量变更方案。
- 目前执行配置模板是串行操作，不支持并行。所以同一时间里，只能执行一个配置模板。
- 执行配置模板时，会先检查网络状态，只有当上一个模板成功执行时，才会执行下一个模板。
- 变更时当网络发生异常时，NetCraft会马上使用Undo shadow module进行回退。
完成每次更新有以下四个步骤，以下面的图为例：
- 执行所有相关的Deactivate模块。
- 执行自定义模板（在这个例子里是Prepending ASN in AS Path）。目前没有方法找到自动去通过网络模型去推算出这种模板，但是一些常见的用例，例如BGP Peering 更新，这些操作是可以自动化的。对于复杂的变更场景，需要写个状态机去指引。
- 执行所有相关的Activate模块。
- 执行第二步里自定义模板的Undo模块，删除一些旧的配置（例如把link断掉了）。
上述的每个步骤，配置模块都是从网络模型低层到高层依次执行。这是因为每一层使用下一层提供的服务，并且要向其上层提供服务。可能大家会想为什么一定要成这么复杂，可不可以在对设备进行下发配置之前，先做一个配置快照保存起来，然后把所更新的配置下发到设备上。如果失败了，直接用类似于热重启的方式回退到之前的配置。就像Napalm提供的rollback函数，例如思科用rollback running-config file的命令进行回退。这种操作在实际生产环境中，可能会造成短暂的中断甚至是热重启失败。尤其是对于有着大量配置并且扮演着十分重要的角色的设备（例如核心路由），一定要保证设备可以平滑的进行增量式的变更和回退操作。
Microsoft CrystalNet
网络可靠性对于云服务厂商十分重要。当云网络规模变大后，运维变得困难。因为历史的原因，网络中本来就可能存在许多不确定的bug在里面，例如当下次变更时触发了之前网络存在的bug，又或者设备主备切换后才会触发到的bug。由于云业务不断的扩展，要求开发的速度不断提升，但是没有一个可靠的测试和验证工具。这导致降低了软件交付和用户业务变更的速度。那么如何做到网络验证呢？微软在网络验证这个新兴的细分领域，发表了一些学术研究成果的文章，有兴趣的可以去Microsoft Network Verification网站查看。明确地说，网络验证可以细分成以下三个领域：
- 控制面验证：网络中路由表是通过路由协议生成的，例如BGP、OSPF等。在上到生成环境前，我们需要对网络控制面层进行验证。有兴趣的可以找下面几篇论文读：
- A general approach to network configuration verification. In SIGCOMM ’17
- Efficient Network Reachability Analysis using a Succinct Control Plane Representation. In OSDI (2016)
- Fast control plane analysis using an abstract representation. In SIGCOMM ’16
- Control plane compression. In SIGCOMM ‘18
- 数据面验证：因为网络中转发数据包是根据数据面的行为，所以验证工具需要在部署前和部署之后对网络进行验证，例如检查可达性、黑洞路由等等。有兴趣的可以找下面几篇论文读：
- Checking Beliefs in Dynamic Networks. In NSDI (2015)
- Real time network policy checking using header space analysis. In NSDI, 2013.
- Veriflow: Verifying Network-Wide Invariants in Real Time
- 仿真：通过仿真，网络工程师能够找到固件和模型中的bug，可以在上生产环境之前对它们进行测试和检查。前些天InfoQ写了篇文章介绍微软将开源其对抗云网络中断的秘密武器，微软设计了一款开放网络仿真器（Open Network Emulator，简称ONE），可以通过仿真整个Azure网络基础架构，来查找最终导致网络中断的错误，故障和其他恶意软件。在当时，它被称为“CrystalNet”，现在微软准备把它开源出来。有兴趣想了解细节的朋友可以读一下CrystalNet: Faithfully Emulating Large Production Networks，第一作者是Hongqiang Harry Liu。下面截取文章中一部分对比网络仿真与控制面、数据面验证这两种思路方式。
网络验证工具例如batfish，输入设备配置和网络拓扑信息，通过模拟路由协议计算转发表。分析这些转发表的行为可以回答例如可达性这类问题。然而，Batfish不能够找到设备固件中存在的bug，另外不同厂商对同一个路由协议行为可能有微妙的差别。在微软有将近36%的问题是由软件bug所导致，如下表所示，展示了近两年网络事故的根因。
从表中可以看出，网络验证工具并不能解决和发现软件bug（36%）和人为下发时导致的错误（6%），而通过仿真整个网络可以解决下面的问题。
- 软件bug：这个分类主要包括设备固件中的bug、网络管理工具中的bug。就算是同一个厂商同型号的设备，针对于不同版本的固件，配置语法以及支持的功能可能会存在细微的差别。举个例子，对防火墙设置vpn秘钥时，因为防火墙的系统版本不一样，可能所支持的秘钥符号不同。只有通过仿真设备固件，才能发现此类的问题。
- 配置bug：网元设备的配置不仅仅是定义一些路由协议（关于控制面的这些行为)，还包括了例如转发表容量、设备cpu、acl等等。把这些全部加起来，才是一个完整的配置。网络事故中有27%是因为配置错误所导致的，例如缺失或者错误的ACL策略、重复分配了同一个IP、错误的AS号等等。
- 人为导致的错误： 主要是一些手动操作失误所导致的. 例如通过CLI或者某个部署工具，把
deny 10.0.0.0/20写成了deny 10.0.0.0/2。这些人为错误占了网络事故的6%。我们通过对一些有经验的网络工程师对话中得知，造成这个问题的主要原因是操作人员没有一个与生存环境同等的测试环境去练习和操作。CrystalNet可以通过仿真提供这样的环境。
为了准确地模拟出控制面，CrystalNet运行在容器和虚拟机，底层使用的是真实的网络设备固件。如果能仿真出大规模网络，那么性能究竟如何？不同厂商设备兼容性如何？需要消耗的主机资源有多少？根据文章中的描述，仿真5000台的设备，需要500个VM（4 core, 8GB RAM）。想要通过实践回答上面的问题，可能要等到微软开源这个项目后才能知道了。
Conclusion
- 网络模型（network model）是核心竞争力。 我们可以发现无论是Robotron、NetCraft这类网络可编程的项目和Batfish这类网络验证的项目，都需要基于网络模型。构建网络模型需要一个过程去不断的完善。
- 版本控制（version control）也很重要。 网络拓扑、路由、设备的版本以及配置会随着时间的推移，会进行不断的变更。这要求做到可以对整个网络进行版本管理，例如比对配置不同版本的差异，能够回退到指定的版本等等。
目前开源的这些项目主要专注于特定的领域。例如Ansible专注于实现网络自动化部署和任务编排；Propane专注于从意图生成设备配置这个流程；Batfish专注于网络配置验证，找出网络中的bug；Napalm专注于实现对网络管理层操作的抽象，屏蔽多厂商差异提供一个统一的API接口。
公司需要思考如何利用好目前开源工具，减少一些重复的工作，构建真正有核心力的产品。想真正实现网络可编程，需要把整个流程打通实现闭环，这会涉及到多个部门的合作。当前各大云厂商都在投入网络可编程，试图打通端到端的网络自动化，进而提高了部署效率、节约了人力成本，还可以有效地避免配置错误。相反传统IT厂商无法在运维成本上和云厂商抗衡，所以未来越来越多的IT厂商会把大部分的业务放到云上。从Gartner公布的云市场整体情况，能够看到一个趋势非常明显。全球整个IT市场发生了很大的变化，传统IT几乎没有增长，但是云服务增长40%左右。云做的业务增长明显比传统IT增长要快。对于服务器厂商来说，如果全球服务器的出货量几乎不变，那么实际整个收入是下降的。未来服务器会不会只能卖给几个大的云供应商了。另外最近出了几个传闻亚马逊、微软要决定自己做服务器了，当天思科等厂商股票立马跌了不少。从历史的发展来看，巨头公司往往不是被同行干掉的，而是被新的技术所革命。
作为技术从业者，如果能够处在朝阳行业并且看到自己写的代码有一个实践和落地的舞台，可以说是一件幸运的事情。前段时间，我按照开源项目Napalm的接口规范，添加了对华为CE系列的交换机的支持。大家可以去napalm-ce网站中查看和使用，如果在使用中遇到问题可以提交issue或者Pull Requests。
Reference
- Verification and Intent-Based Networking: Closing the Control Loop
- Facebook Robotron 演讲、FBNet Command Runner FCR
- Cisco Crosswork Network Automation、Cisco Crosswork Change Automation
- Automatic Life Cycle Management of Network Configurations
- CrystalNet: Faithfully Emulating Large Production Networks
- Microsoft Network Verification
- 微软将开源其对抗云网络中断的秘密武器
- Huawei napalm-ce
