首发于SDNLAB网站，链接：https://www.sdnlab.com/22321.html
作者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的命令进行回退。这种操作在实际生产环境中，可能会造成短暂的中断甚至是热重启失败。尤其是对于有着大量配置并且扮演着十分重要的角色的设备（例如核心路由），一定要保证设备可以平滑的进行增量式的变更和回退操作。