CrystalNet：超逼真地仿真大型生产网络

译者注：在第26届ACM年度操作系统和原理研讨会上，微软介绍了一种名为CrystalNet的新技术，这是一种高保真、云规模的网络仿真器。CrystalNet由微软花费两年时间构建，在公示时，其已在微软内部应用6个月时间。本论文为CrystalNet发表的学术研究成果中文翻译版，仅供学习研究之用。后续微软曾公开表示要将CrystalNet开源，并更名为Open Network Emulator（ONE），目前尚无正式开源的日程计划。

摘要

网络可靠性对于大型云计算系统和像微软这样的在线服务提供商来说至关重要。类似系统（微软）的网络是庞大的、异构的、复杂并且不断变化的。在这样的环境中，即使是由设备故障、设备软件故障、配置错误、未经验证的管理工具和不可避免的人为错误触发的小问题，也会迅速导致大面积蝴蝶效应（比如停机故障）。减少此类网络中断的一个有希望的方法是，在高保真网络仿真器中主动验证所有网络操作，然后再在生产中执行。为此，我们介绍了CrystalNet，这是一种云规模的高保真网络仿真器。它在一个由容器和虚拟机组成的网络中运行真实的网络设备固件，并加载生产配置。网络工程师可以使用与生产网络相同的管理工具和方法来与仿真网络进行交互。CrystalNet可以处理各种各样的设备固件，并且可以在几分钟内伸缩以仿真成千上万的网络设备。在保证网络变化传播正确性的同时，CrystalNet谨慎选择仿真边界以减少资源消耗。微软的网络工程师每天使用CrystalNet来测试计划中的网络操作。我们（微软）的经验表明，CrystalNet使操作员能够检测到许多可能导致严重停机的网络问题。

CCS概念 ：网络→网络可靠性；

关键字：网络，可靠性，仿真，验证

1 简介

CrystalNet是微软日常使用的一款高保真的云规模网络仿真器。我们构建CrystalNet是为了帮助我们的工程师提高网络基础设施的整体可靠性。可靠且高效的网络结构对于满足我们（微软公有云）向客户承诺的可用性SLA至关重要。

众所周知，公有云及在线服务的大型网络的可靠稳定运行一直是业内需要解决的一项挑战。我们（微软公有云）的网络包含数以万计的设备，这些设备来自众多供应商，并部署在全球各地。这些设备运行复杂的路由软件，由复杂的配置控制（因此容易出错）。此外，除了偶发的硬件故障外，升级、新的部署和其他迭代总是实时在进行中，这种操作产生的网络中断问题导致我们（微软公有云）的用户因此大量的流失。

关键问题在于，在这样一个庞大而复杂的环境中，即使是很小的变化或失败也可能产生无法预见的、近乎灾难性的后果。更糟糕的是，我们几乎没有什么工具可以用来主动评估此类网络中的故障、错误或计划更改的影响。

小型硬件测试台用于在将新的网络设备添加到网络之前对其进行单元测试或压力测试。这些虽然有用，但它们无法揭示大型拓扑中复杂的交互作用所引起的问题。

网络验证工具例如batfish，输入设备配置和网络拓扑信息，通过模拟路由协议计算转发表。分析这些转发表的行为可以回答例如可达性这类问题。然而，Batfish不能够找到设备固件中存在的bug，它也不能解决由于不同供应商对同一路由协议的实施存在细微差异而导致的互操作性问题。换句话说，Batfish与生产网络“不兼容”。在微软的网络中，将近36%的问题是由此类软件bug引起的（如表1所示）。请注意，没有办法使Batfish兼容bug或者检测bug——通常，这些错误对于设备供应商本身就是未知的，直到它们在特定条件下显现出来为止。此外，Batfish为网络运营商提供了一个截然不同的工作流程。这意味着它不适合防止人为错误，人为错误的因素也很重要，因为人为错误造成了我们（微软公有云）网络中6％的停机故障。

我们需要的是一个大规模、高保真的网络仿真器，它可以让我们准确地验证任何计划的更改，或者评估各种故障场景的影响。小型网络仿真器（例如MiniNet或GNS）很有用，但存在许多缺陷（见第10节），并且无法扩展到仿真大型公共云网络所需的级别。

为了解决这个问题，我们构建了CrystalNet，一个高度可伸缩的高保真网络仿真器。高保真度意味着仿真器可以精确地仿真生产网络的行为，特别是在控制平面上。此外，它还允许操作员使用与生产网络完全相同的工具和工作流程。

我们并不要求完全保真-这需要创建一个完整的生产网络副本，这是不可行的。因此，我们的目标不是近乎逼真地仿真网络数据平面（延迟、链路带宽、流量等）。我们的重点是控制平面。

为了准确地仿真控制平面，CrystalNet在虚拟沙箱（例如容器和虚拟机）中运行真实的网络设备固件。大多数主要路由器供应商都可以提供此类虚拟机或容器。我们将设备沙箱与虚拟链路相互连接，以模拟真实的拓扑结构。它将真实的配置加载到仿真设备中，并将真实的路由状态注入到仿真网络中。

操作员可以使用与生产网络交互所使用的相同工具和脚本与CrystalNet仿真网络进行交互（即更改、升级或监视）。也可以在仿真网络中注入数据包并监视其路径。甚至可以在仿真网络中扩展包括真实硬件的网络设备。

我们的网络工程师每天都使用CrystalNet。他们在升级计划中发现了几个错误，而如果没有类似CrystalNet的仿真器，这些错误是不可能被捕获的。我们在第7节中报告了他们的一些经验。

CrystalNet具有可伸缩性和成本效益。要仿真由5000台设备组成的网络，我们只需要几分钟和500个虚拟机（配置4核CPU、8GB RAM）。这种虚拟机的零售价为每小时0.20美元，因此用CrystalNet仿真这样一个大型网络的总成本为100美元/小时。与网络中断的成本相比，这是微不足道的。

CrystalNet的三个关键特性使其能够大规模地仿真大型异构网络，这也是本文的主要贡献。首先，CrystalNet被设计成在公共云中运行。如有必要，CrystalNet甚至可以同时使用多个公共和私有云。这使得CrystalNet可以扩展到远远超过MiniNet和GNS3的水平。由于在任何大规模部署中都可能发生虚拟机故障，CrystalNet允许保存和恢复仿真状态，并快速增量更改仿真状态。

其次，CrystalNet可以容纳我们供应商提供的各种路由器软件映像。路由器映像可以是独立的虚拟机，也可以是Docker容器的形式。为了统一地容纳和管理它们，我们使用同质的容器仿真了物理网络，并在容器的网络名称空间之上运行了异类的设备沙箱。CrystalNet还允许我们的工程师通过Telnet或SSH以标准方式访问路由器。CrystalNet还可以透明地将内部硬件设备包括在仿真网络中。这需要仔细遍历路径中的NAT和防火墙。

第三，CrystalNet精确仿真外部网络，对仿真网络透明。仿真网络必须有一个边界，超过这个边界就没有仿真设备。除了资源限制（无法模拟整个互联网），事实是我们无法从不受管理控制的设备（如上游ISP）获取配置和设备固件。我们使用轻量级的被动代理，该代理模仿仿真设备从边界之外接收到的公告。由于代理对仿真网络中的动态没有响应，我们通过识别和搜索安全边界来确保结果的正确性（第5节）。计算正确的边界还可以节省资源：事实上，它可以在保持高保真度的同时将仿真成本降低94-96%（第8.4节）。

在更详细地描述CrystalNet之前，我们首先讨论了我们的网络在过去两年中的中断情况。

2 动机

表1显示了过去两年我们网络中O（100）个网络事件及其根本原因的摘要。这些类别很宽泛，定义有点松散；重要的是各个场景的细节，如下所示。

表1：我们网络中O（100）重大和影响客户的事件的根本原因（2015年至2017年）。

软件bug：这个分类主要包括设备固件中的Bug、网络管理工具中的bug。就算是同一个厂商同型号的设备，针对于不同版本的固件，配置语法以及支持的功能可能会存在细微的差别。举个例子，对防火墙设置V**秘钥时，因为防火墙的系统版本不一样，可能所支持的秘钥符号不同。只有通过仿真设备固件，才能发现此类的问题。

我们自己的自动化工具中的错误示例包括未处理的异常，该异常导致工具关闭路由器而不是单个BGP会话。

设备软件问题有多种形式。有些是彻底的Bugs：例如，来自供应商的新路由器固件错误地停止了宣布某些IP前缀。在另一种情况下，当对等配置更改时，ARP刷新失败。

另一组问题是由歧义而不是错误引起的。来自同一供应商的不同版本的网络设备通常具有稍微不同的配置定义。例如，一个供应商在新版本中更改了ACL的格式，但忽略了清楚地记录更改的内容。结果，运行新固件的交换机对旧配置文件的处理不正确。

设备在实现其他标准协议/功能时通常表现出依赖于供应商的行为，例如，如何为聚合的IP前缀选择BGP路径，或如何在FIB已满后处理路由等。此类特殊情况通常没有很好的记录。例如，图1显示了我们在生产中看到的问题的简化版本。IP前缀P1和P2属于AS编号为“1”路由器R1。当高层路由器R6和R7得到这两个前缀的通告时，它们希望将它们聚合为一个前缀（P3）。但是，R6和R7来自不同的供应商，它们具有不同的行为来选择P3的AS路径：R6从R2（AS路径{2，1}）和R3（AS路径{3，1}）学习P1和P2的不同路径，并选择其中一个路径并在将P3发布到R8之前附加自己的AS编号（本例中为{6，2，1}）；R7也面临着类似的情况，但是它不选择任何路径，而仅将其AS编号作为P3到R8的通告中的AS路径。因此，R8总是倾向于为P3到R7发送数据包，因为它认为R7的成本较低，从而导致严重的流量负载不平衡问题。

图1 由IP聚合中的供应商特定行为引起的流量负载不平衡

有时，不同的系统组件以各自的能力直接执行任务，组件之间无法很好地交互，特别是在发生更改之后。例如，一个软件负载平衡器拥有a/16 IP前缀。但是，它被要求释放前缀中的一些IP块，并将它们提供给其他负载平衡器。然后，它将/16 IP前缀分成256×/24个IP块，并宣布它所持有的块（大约100个）。然而，连接到负载平衡器的路由器缺少FIB空间，并且丢弃了许多这样的公告，从而导致流量黑洞。

请注意，这些Bugs没有经过我们的供应商进行的相当严格的单元测试以及我们自己的预认证检查。虽然更严格的单元测试总是有帮助的，但是不可能涵盖生产环境中可能出现的大量输入和条件。除非使用像CrystalNet这样的高保真仿真器，否则全面的集成测试将是不切实际的资源密集型测试，占用大量资源。我们并不是说CrystalNet可以发现所有的漏洞——只是让操作员在高保真仿真中测试路由器硬件、工具和计划的更改，可以减少此类漏洞影响生产网络的可能性。我们再次注意到，网络验证系统无法解释此类错误的影响，因为它们依赖于分析配置，并假设网络组件具有理想的无错误行为。可能有人认为可以对系统进行更新以对错误进行建模-但是许多错误在生产网络中显现之前都是“未知的”。此外，当网络中包含诸如软件负载之类的组件时，此类系统的效率甚至更低，这些组件的行为被“烘焙”到自定义软件中，而不是由配置驱动和由标准控制。人们永远无法对这些组件的行为进行完全和准确的建模。

配置Bugs：网元设备的配置不仅仅是定义一些路由协议（关于控制面的这些行为)，还包括了例如转发表容量、设备的CPU负载、IPv4短缺和重用、安全和访问控制等问题。把这些全部加起来，才是一个完整的配置。这使得我们的网络配置策略相当复杂，网络事故中有27%是因为配置Bugs所导致的，例如缺失或者错误的ACL策略、重叠的IP分配、错误的AS号等。

我们的设备最初是自动配置的，使用类似于Robotron、Propane的配置生成器。这一类中的大多数意外事件都是由于在故障缓解或计划更新期间对配置进行特殊更改而触发的。通过使用CrystalNet测试这些变化，可以减少此类错误影响生产网络的可能性。

人为错误：我们将“人为错误”定义为那些明显与他们的意图不匹配的手动操作，从而导致某种错误。例如将“deny 10.0.0.0/20”误认为是“deny 10.0.0.0/2”。令人惊讶的是，人为错误导致了不可忽略的部分（约6%）事故。有人可能会说，这是由于粗心造成的，无法补救。然而，在与有经验的操作人员交谈之后，我们发现一个更重要的系统性原因是，操作人员没有一个良好的环境来测试他们的计划，并用实际的设备命令界面来实践他们的操作。CrystalNet可以提供这样的环境。像Batfish这样的网络验证系统所呈现的工作流程与操作员实际执行的工作流程不同，因此无法减少此类错误的发生。

总结：对这些事件的分析强调了一个事实，即许多不同类型的漏洞和Bugs都会影响大型复杂网络。使用像CrystalNet这样的高保真网络仿真器进行测试和规划，可以在这些漏洞和Bugs扰乱生产网络之前捕获它们；而传统的网络验证系统提供的成功率要少得多。

3 CrystalNet设计概述

在本节中，我们描述了CrystalNet的设计目标、总体架构和编程接口。

3.1 设计目标

CrystalNet的最终目标是为操作员提供高保真的网络仿真。为了实现这一目标，CrystalNet有三个关键特性：

使用公共云进行扩展的能力：高逼真仿真大型网络所需的资源远远超过单个服务器的容量，甚至是一个小型服务器集群的容量。例如，一个微软数据中心可以包含数千个路由器。对每个路由器进行仿真都需要大量的CPU，RAM等。如果我们考虑中间件和数据中心间的场景，则需要更多的资源。这种规模的计算资源只能以VMs的形式从公共云提供商处获得。因此，为了确保仿真网络的规模没有上限，CrystalNet必须能够在公共云环境中以分布式方式在大量虚拟机上运行。一切都应该很容易扩展——例如，要将仿真的网络规模扩大一倍，操作员只需分配两倍的计算资源即可。

透明仿真物理网络的能力：交换机操作系统假设它运行在具有多个网络接口并连接到相邻设备的物理交换机之上。管理工具假设可以通过Telnet或SSH的IP地址访问每个网络设备。CrystalNet必须创建对交换机操作系统和管理工具透明的虚拟网络接口、虚拟链接和虚拟管理网络，以便后者可以在不做修改的情况下工作。

透明仿真外部网络的能力：仿真的网络总是有边界的——我们不能仿真整个互联网。这不仅仅是一个资源问题；关键问题是运营商无法获取其管理域之外设备的操作系统映像或配置。CrystalNet必须接受边界存在的事实，即使边界外的设备不被仿真，也要确保高保真度。

此外，我们还希望性能，如故障率和成本效益。接下来，我们将描述CrystalNet的设计是如何实现这些目标的。

3.2 架构

图2 CrystalNet架构。这显示了在三个VM上运行的八个交换机的模拟Clos拓扑

图2显示了CrystalNet的高级体系结构。Orchestrator（协调器/编排器）是CrystalNe的“大脑”。它读取生产网络的信息，在云上配置VM（例如VM A），在VMs中启动设备虚拟化沙箱（例如T1），在沙箱中创建虚拟接口，在沙箱之间构建覆盖网络，并引入一些外部设备沙箱（例如B1）来模拟外部网络。通过积极的批处理和并行性，Orchestrator（协调器/编排器）可以在单个商品服务器上运行，并轻松处理O（1000）个虚拟机。

CrystalNet易于扩展。覆盖网络确保该仿真可以在任何VM集群上运行（有足够的资源），而无需进行任何修改。

CrystalNet中的仿真网络是透明的。每个设备的网络名称空间具有与实际硬件中相同的以太网接口；这些接口通过虚拟链路连接到远程端，虚拟链路与实际物理链路一样传输以太网数据包；覆盖网络的拓扑结构与其模拟的实际网络相同（第4节）。因此，设备固件无法区分它是在沙箱内运行还是在实际设备上运行。此外，CrystalNet还创建了一个管理覆盖网络，用于连接所有设备和Jumpbox VM。管理工具可以在Jumpbox内运行，并可以像在生产中一样访问设备。

CrystalNet的仿真边界是透明的。用于模拟外部网络的外部设备提供与真实网络中相同的路由信息。此外，如第5节所述，边界是经过仔细选择的，因此即使仿真网络处于搅动状态，仿真网络的状态也与真实网络相同。

仿真网络是高度可用的，因为VM是独立设置的，VM不需要知道任何其他VM的设置。因此，编排器可以轻松地检测并重新启动失败的VM。

CrystalNet通过在每个虚拟机上放置多个设备，并选择正确的设备进行仿真而不是盲目地仿真整个网络来实现成本效益（第5.2节）。

3.3 CrystalNet API

Orchestrator（协调器/编排器）公开了一个API，操作员可以使用该API来配置、创建和删除仿真，以及运行各种测试并观察网络状态以进行验证。如表2所示，该API的灵感来自于网络运营商希望运行的验证工作流。

图3说明了网络配置更新的典型工作流。首先，调用Prepare来获取生产环境的快照，生成VM并将它们作为输入输入到Mockup中。Prepare包括获取必要拓扑信息、设备配置和边界路由公告（见第5节）的功能，以及基于拓扑的虚拟机规划。Mockup创建虚拟网络拓扑（第4节）和仿真边界（第5节），并启动仿真设备软件。

图3典型的网络更新验证工作流程。CrystalNet API涵盖了蓝色和粗体部分。工作流程的其余部分是特定于操作员的

在仿真之后，CrystalNet已经准备好测试更新步骤。在每个步骤中，操作员可以选择应用诸如启动新设备OS或更新整个配置的重新加载，或者使用现有工具通过管理席进行增量更改（第4节）。

接下来，操作员可以使用监控API和他们自己的工具来提取仿真状态（例如，在每个设备上的路由表），以检查他们所做的更改是否达到了预期的效果。为此，CrystalNet还支持包级遥测。运算符指定要注入的数据包，CrystalNet使用预定义的签名将其注入。所有仿真设备都会捕获所有看到的数据包，并根据签名筛选和转储跟踪。这些跟踪可用于分析网络行为。

通过获取路由表、数据包跟踪以及登录到仿真设备并检查设备状态的能力（见表2），使用CrystalNet的运营商可以使用其首选方法验证仿真网络，例如注入测试流量、使用反应性数据平面验证工具验证路由表等。如果结果与预期一致，操作员可以进入下一步。否则，操作员将通过重新加载还原当前更新，修复错误并重试。此过程将重复，直到验证所有更新步骤。最后，调用Destroy来释放虚拟机。

CrystalNet还提供了一些辅助API，如列出所有模拟设备、登录到设备等。我们省略了详细信息。

CrystalNet的关键部分是仿真一个高保真环境，该环境支持此统一的API集并且具有成本效益。我们将在接下来的两节中讨论它。

4建立物理网络

4.1 异构网络设备

CrystalNet支持在网络设备上运行的各种操作系统和软件。我们专注于数据中心和广域网中的交换机，其中包括三家最大的交换机供应商（称为CTNR-A、VM-B和VM-A）和一个开源交换机操作系统（CTNR-B）。CrystalNet的设计目的是透明地与这些异构软件系统一起运行，可扩展到其他设备软件，并为用户提供统一的API（第3.3节）。

CrystalNet选择容器作为隔离装置的基本格式。容器以比VM更少的开销隔离运行时库，在云上的VM中运行良好，更重要的是，隔离多个设备的虚拟接口以避免命名冲突。我们使用Docker引擎来管理容器。我们解决了运行异构软件的挑战，如下所述。

连接和工具的统一层。CrystalNet API必须适用于我们要仿真的所有设备。然而，供应商将异构设备软件打包到不同的黑盒映像中，为重新实现每个设备的API并确保一致的行为是艰巨的，有时是不可行的。另一个工程上的挑战是，大多数容器化的交换机OS必须使用已经存在的接口进行引导，而虚拟接口只能在Docker容器启动后才能放入容器中。

为了解决这个问题，我们设计了一个统一的物理网络层，或者PhyNet容器层（图4），其运行时二进制文件与被测设备分离。此容器层包含所有虚拟接口，并作为目标拓扑连接。我们在PhyNet容器中放置常见的工具，如Tcpdump、包注入和提取脚本。大多数CrystalNet API都是为这些PhyNet容器实现的，而不是为每个设备重新实现。之后，我们使用相应的网络名称空间引导实际的设备软件。因此，设备软件运行时没有任何代码更改——就像在现实生活中一样，它们从已经存在的物理接口开始。即使软件重新启动或崩溃，虚拟接口和链接仍然存在。运行PhyNet容器（仅用于保存网络名称空间）的开销可以忽略不计。

图4 CrystalNet中的PhyNet容器使接口的管理和设施工具与设备软件脱钩

基于虚拟机的设备。虽然有些供应商提供容器化映像，但其他供应商（如VM-B和VM-A）只提供其交换机软件的VM映像。我们不能直接在云上运行基于虚拟机的设备映像，因为公共云不能将数百个虚拟接口附加到虚拟机。此外，我们需要将这些基于VM的设备与其他容器连接起来，并维护PhyNet容器层。

我们的解决方案是将VM映像、KVM管理程序二进制文件和生成设备VM的脚本打包到一个容器映像中。换句话说，我们在云VM的容器中运行设备VM。这需要云上的嵌套虚拟机功能。此功能在Microsoft Azure以及其他一些公共云上可用。如果没有此功能，CrystalNet可以为基于虚拟机的设备提供裸机服务器。

真实的硬件。最后，CrystalNet还允许操作员将真实硬件连接到仿真拓扑中。例如，CrystalNet可以模拟一个完整的网络，用一个或多个设备被实际的硬件替换。这使我们能够在比传统的独立测试更现实的环境中测试硬件行为。每个真正的硬件开关都连接到一个“fanout”开关。“fanout”交换机将每个端口隧道到服务器上的虚拟接口。这些虚拟接口由PhyNet容器管理，并通过连接CrystalNet覆盖层的虚拟链接（见第4.2节）桥接。

通过引入PhyNet容器，CrystalNet能够从管理的角度对设备进行相同的处理，无论它们是在容器、虚拟机中运行还是作为真正的物理设备运行。

4.2 网络连接

CrystalNet中有两种虚拟链路，一种用于数据平面，另一种用于管理平面。

数据平面。设备应将虚拟数据平面链路视为以太网链路，并应彼此隔离。此外，虚拟链接必须能够通过底层网络，包括云提供商的网络和互联网。要允许仿真跨越多个公共云，并允许基于云的仿真连接到一个或多个物理设备，必须能够以无缝方式在Internet上进行传输。

我们选择VXLAN而不是其他隧道协议（例如GRE），因为它最符合我们的目标——它模拟以太网链路，并且外部报头（UDP）允许我们连接任何IP网络，包括广域网。我们甚至可以跨nat和负载均衡器，因为它们大多数都支持UDP。

如图5所示，每个设备接口是veth对的一个成员，另一侧插入网桥。每个网桥也有一个VXLAN隧道接口（如果远程设备在另一个VM上），或另一个本地veth接口。这对设备容器是透明的。我们通过给每个链路分配一个唯一的VXLAN ID来隔离每个虚拟链路。Orchestrator确保同一个虚拟机上没有ID冲突。

图5虚拟数据链接的设计。设备X的et0已连接到Y的et0。X的et1通过VXLAN ID连接到Z的et0。显示的设备是PhyNet容器

管理平面。多年来，运营商已经开发了基于通过管理平面对设备进行直接IP访问的工具，管理平面是仅用于管理的带外通道。CrystalNet自动提供此管理平面（图6）。就像在生产环境中一样，操作员可以在不做任何修改的情况下运行其管理工具，使用这些工具执行增量配置更改，并拉取设备状态。

图6管理平面的体系结构。为了简洁起见，省略了物理接口

CrystalNet部署了一个Linux jumpbox，并将所有模拟设备连接在一起。然而，不能简单地将所有的管理接口连接到一个完整的二级网格中——这将在这样的覆盖中导致臭名昭著的L2风暴。相反，我们构建了一个树结构——每个虚拟机都建立了一个网桥，并通过VXLAN隧道连接到Linux跳线盒。所有模拟设备都连接到本地虚拟机的网桥。其他jumpbox（例如基于Windows的jumpbox）通过V**连接到Linux jumpbox。最后，Linux Jumpbox运行一个DNS服务器来获取设备的管理IP。

5 模拟仿真边界

任何仿真或模拟网络都必须有一个边界。例如，当我们模拟一个或多个数据中心时，我们会停在它们连接到广域网的地方。超越这一界限是不可行的，不仅因为我们缺乏资源，还因为我们无法获得不在我们控制下的设备的配置或其他信息。然而，来自外部网络的路由消息以及外部设备对仿真网络内部动态的反应是保证仿真正确性的关键。

解决这一难题的关键在于，大多数生产网络不会盲目地泛滥或接受路由更新。在特定位置发生动态变化时，有一些策略或协议会限制影响范围。如果我们找到影响的停止边界，则可以安全地假设边界外的网络在运营商验证边界内的网络期间保持静态。在本节的其余部分中，我们将更详细地讨论这个概念。

5.1 静态仿真边界

在CrystalNet中，我们将仿真设备定义为运行实际设备固件和生产配置的设备。例如，在图7a中，T1-4和L1-4都是仿真设备。此外，我们称T1-4为内部设备，因为它们的邻居都是仿真设备；称L1-4为边界设备，因为它们的邻居在边界之外。我们称直接连接到边界设备的外部设备为speaker devices。其他外部设备被排除在仿真之外。例如，在图7a中，S1-2是speaker devices，并且连接到模拟设备，而T5-6和L5-6没有仿真。

图7a 需要在BGP数据中心网络中模拟基于设备的不安全静态边界示例

在CrystalNet中，speakerdevices不会运行实际的设备固件或生产环境中的配置。相反，他们运行简单的软件并仅执行两个功能。首先，它们使链接设备和路由会话与边界设备保持活动状态，因此边界的存在对仿真设备是透明的。其次，它们是完全可编程的，用于发送任意路由消息。

静态speaker devices在CrystalNet中，我们将speaker devices设计为静态的，即speaker devices对来自边界设备的任何路由消息都没有反应。相反，在准备过程中，CrystalNet安装路由消息，由每个边界设备发送。在仿真之后，speaker devices将宣布这些消息。通过使speaker devices静止，我们避免了对外部设备行为的任何假设。

另一种方法是使用运行路由协议规范实现的网络模拟器设计动态边界。这个模拟器可以实时计算每个speaker devices的反应。但是，由于两个原因，我们没有选择此选项。首先，我们通常无权访问外部设备的策略或配置，因此无法完全模拟它们。其次，经典路由协议的实现可能会存在自身的错误，这可能会影响整个仿真的正确性。

安全静态边界使用静态speaker devices会引起一个问题：当操作员对模拟设备应用更改时，仿真是否仍然正确？换言之，在真实的网络中，以speaker devices为代表的设备是否会对变化做出反应，并与我们的静态设计不一致？

这种担心是有道理的。例如，在图7a中，在使用边界网关协议（BGP）的数据中心网络上，我们运行T1-4和L1-4作为仿真设备，运行S1-2作为speakerdevices。如果T4获得新的IP前缀（10.1.0.0/16），则在仿真中，该前缀的通告将在S1-2处停止。然而，在实际的网络中，S1-2会将这个前缀传播到L1-2！鉴于这种潜在的不一致性，我们称图7a中的边界为不安全边界。

我们将安全的静态边界定义为边界设备的集合，即使在模拟设备的拓扑和/或配置发生变化时，也可以保证仿真和真实网络之间的一致性。例如，图7b具有安全边界：S1和S2。新IP前缀的通告可以到达L1-2和T1-2，因为S1和S2这次是仿真设备。我们现在证明了S1-2作为边界在T1-4和L1-4的任意路由和/或拓扑更新下的安全性。

5.2 识别和搜索安全静态边界

在准备过程中，CrystalNet将“必备设备”（操作员需要仿真的设备）作为输入。然后，它会找到一个安全的静态边界，在该边界内仿真所有必须具备的设备。在本节中，我们给出了判断各种网络上给定边界安全性的充分条件，并给出了在运行BGP的数据中心网络中寻找安全静态边界的启发式方法。

BGP网络。BGP不仅是Internet上自治系统之间的实际路由协议，而且在数据中心网络中得到了广泛的应用。作为距离矢量协议的一种变体，BGP允许每个路由器向其邻居报告其可以到达的IP前缀。在仿真中，配置或拓扑结构的改变会触发IP前缀可从某些设备访问性的改变。这些变化在仿真设备之间传播。我们声明以下LEMMA：

LEMMA 5.1。在仿真的BGP网络中，只有当且仅当仿真设备中发起的路由更新没有多次通过边界时，边界才是安全的。

证明LEMMA 5.1很简单，因为如果仿真设备中的所有路由更新停留在仿真网络内，或者退出而不返回仿真网络，则speaker devices不需要作出反应。LEMMA5.1适用于所有距离矢量路由协议。

尽管如此，很难直接应用LEMMA 5.1，因为检查所有IP前缀的所有潜在路由更新路径可能是不可行的。因此，我们声明了更强大的版本LEMMA，可以有效地实现：

LEMMA 5.2。如果模拟的BGP网络的边界设备在一个AS内，并且所有的speaker devices在不同的AS中，则边界是安全的。

证明。如果所有的边界设备都在一个单一的AS中，则没有路由更新可以退出边界并再次返回，因为为了避免路由循环，BGP不允许将路由更新发送回同一AS。根据LEMMA 5.1，证明完成。

注意，如果由speaker（或外部）设备表示的设备任意修改或移除AS路径中的元素，则路由更新会返回，但这种情况很少见。在实际的生产网络中，对AS路径的修改大多是为了改变AS路径的长度而多次重复单个AS。在这种情况下，路由更新将不会返回，因为否则将有一个循环。

提议5.2为BGP网络中边界是否安全提供了一个充分条件，从而搜索到一个小的安全边界。例如，图7b中的边界是安全的，因为S1和S2在一个AS中。此外，我们提出了一个更有力的主张：

提议5.3。如果模拟的BGP网络的边界设备是通过外部网络彼此不可到达的as，则边界是安全的。

图7b 需要在BGP数据中心网络中模拟基于设备的不安全静态边界示例

证明。在路由更新从边界设备（β）发送到speaker devices之后，路由更新将永远不会到达任何其他边界设备，因为其他边界设备要么与β相同，要么与β没有连接。根据LEMMA 5.1，证明完成。

例如，假设操作员只想仿真L1-4而不是T1-4，图7c给出了一个安全边界。这是因为边界设备S1-2、L1-2、L3-4处于三个不同的AS中，如果不通过仿真网络区域，则它们彼此之间将无法到达。例如，当链路S1-L1发生故障时，例如，当链路S1-L1发生故障时，L1将针对从S1到T1和T2的路由发送撤消消息，但是T1或T2不会将撤消消息发送给L2，因为L1和L2都在AS200中。S1-2或L3-4也不受影响，因为它们不能从T1或T2到达。类似的情况发生在T3-4和L5-6。

图7c 需要在BGP数据中心网络中模拟基于设备的不安全静态边界示例

在运行BGP的数据中心中搜索安全静态边界。给定一组输入设备，在一般网络中寻找满足命题5.2或5.3的最优边界仍然是困难的。然而，对于类似Clos的数据中心网络，如[4，5]，我们根据其特殊性质导出了一个有用的启发式算法：（i）整个网络拓扑是分层的；（ii）现在允许谷路由[9]；（iii）连接到广域网（WAN）的边界交换机位于最高层，通常共享一个AS号。

我们的想法是把拓扑看作一个多根树，边界开关是根。从每个输入设备开始，添加其所有父级、祖级等，直到边界切换到仿真设备集中。这本质上是一个有向图上的BFS，它是通过将拓扑中的链接替换为有向子对父边来构造的。算法1显示了BFS过程。很容易验证输出仿真设备是否具有安全边界。由于篇幅所限，我们省略了形式证明。

OSPF网络。OSPF是一种链路状态路由协议，作为内部网关协议（IGP）在大规模网络中得到了广泛的应用。与BGP不同，OSPF中的路由器向位于指定路由器（DR）和备份指定路由器（BDR）中的数据库报告其相邻链路的状态（例如，活性、权重等）。链路上的状态更改会触发连接到该链路的路由器，以向DR和BDR报告新的链路状态。为了确保在仿真设备上验证更改不需要speakerdevices的响应，我们声明如下：

提议5.4。如果边界设备和speaker devices之间的链路在模拟网络中保持不变，并且DR（s）和BDR（s）是仿真设备，则OSPF网络的边界是安全的。

这是因为如果speaker devices的链接保持不变，则它们不会有新的报告；DR（s）和BDR（s）将始终对更改作出反应，因为它们始终是仿真的。根据提议5.4，为了OSPF网络的边界是安全的，可能遭受变化的链路的两端必须是仿真设备。同样的结论也适用于IS-IS协议。

软件定义网络（SDN）。SDN通常运行分布式路由协议，如BGP或OSPF，以实现集中式控制器和网络设备之间的连接，提议5.2、5.3和5.4可用于验证控制网络。对于数据网络，如果边界包含其状态可能影响控制器决策的所有设备，则边界是安全的。分析控制器的代码可能会产生更严格的条件。我们把它留作将来的工作。

6 实施

CrystalNet由超过1万行Python代码组成，并包括一些与我们的内部服务和公共云交互的库。我们不会以任何方式自定义从供应商处收到的交换机固件映像。 在本节中，我们将详细说明一些重要的实现细节。

6.1 准备阶段

Prepare API会为模型生成输入。它包括生成拓扑和配置，以及生成VM。Prepare的唯一输入是操作员要仿真的设备主机名列表。然后，Orchestrator与内部网络管理服务和云交互，执行以下步骤。

生成拓扑和配置。对于输入列表中的所有设备，CrystalNet标识物理拓扑中的位置并计算安全边界。然后CrystalNet会提取所有相关的拓扑结构、设备配置和路由状态快照。然后以Mockup可以理解的格式对所有信息进行预处理和重新排列。预处理主要包括在配置中添加统一的SSH凭据、解析和重新格式化路由状态等。

虚拟机生成。CrystalNet估计所需的虚拟机数量，并使用云API按需生成它们。这是可伸缩性和降低成本的关键。VMs运行一个预构建的Linux映像，其中包括所有必要的软件和受支持的设备容器。可以在运行时使用Docker引擎提取其他映像。

仿真所需的VM的数量和类型取决于各种因素。我们不想产生太多的小虚拟机-这增加了协调器的负担，也会增加成本。同时，我们不想让每个虚拟机太大（并在同一个虚拟机上打包许多设备），因为当虚拟接口太高时，内核在包转发方面的效率会降低。我们还发现基于容器的设备通常需要更多的CPU，而基于VM的设备需要更多的内存。最后，CrystalNet需要嵌套VM（第4.1节）来模拟设备vm，而不是容器。Azure仅对某些VM SKU支持此选项。基于这些考虑，我们通常使用4核8或16GB虚拟机构建仿真，尽管在某些情况下我们也使用其他SKU。

6.2 Mockup阶段

Mockup是CrystalNet的核心部分。Mockup所需的时间决定了运行CrystalNet的时间和成本开销。按照第4.1节的设计，Mockup有两个步骤。首先，它设置PhyNet层和拓扑连接。其次，它运行设备软件。我们在Mockup阶段积极地批处理和并行化各种操作。有关性能编号见第8节。以下是我们吸取的实施经验教训和作出的决定。

Linux网桥或OVS（Open vSwitch）？Linux网桥和OVS都可以转发数据包并集成VXLAN隧道。虽然CrystalNet支持两者，但我们更喜欢前者，因为我们只需要在虚拟链路上进行“哑”包转发。Linux网桥的安装速度要快得多，特别是当CrystalNet为每个虚拟机配置O（1000）个隧道时。为了提高效率，我们还禁用了网桥上的iptables过滤和生成树协议。

在不同的虚拟机组上运行不同的设备。同一主机上的容器共享同一内核，这可能会导致问题。例如，我们发现一个交换机供应商调整了与数据包校验和相关的某些内核设置，这可能导致来自其他供应商的并置设备出现故障。为了避免此类问题，CrystalNet通常不会在同一虚拟机上实例化来自不同供应商的设备。简而言之，我们创建一组VM，每个VM组专用于运行来自特定供应商的设备。

健康检查和自动恢复。VMs可能会失败或在没有警告的情况下重新启动。CrystalNet包括一个运行状况监视器和修复守护程序，用于从此类故障中恢复。守护进程定期检查设备的正常运行时间，并通过从两端注入和捕获数据包来验证链路状态。如果发现问题，它会警告用户，并使用前面描述的api清除和重新启动失败的VM。由于vm彼此独立，因此不需要重新启动或重新配置其他vm。

边界处的BGP speakerdevices。我们的生产网络依赖于BGP路由。因此，我们使用基于ExaBGP 3.4.17的BGP speakerdevices（第5节）环绕仿真边界。它可以插入任意公告，转储接收到的公告以进行潜在分析，并且不会将公告反映给其他对等方。

集成P4 ASIC仿真器。虽然来自三大厂商的映像都带有ASIC仿真器，但开源交换机OS CTNR-B却没有。因此，我们将其集成到开源P4行为模型BMv2中，BMv2充当ASIC模拟器并转发数据包。

7 使用经验

CrystalNet已经在我们的生产网络中部署了大约6个月。运营商和工程师使用它来验证和降低新网络设计、重大网络架构更改、网络固件/硬件升级和网络配置更新的风险。他们还将其用作开发网络自动化工具和开发我们内部交换机操作系统的实际测试环境。在这一节中，我们描述了两个在实践中证明CrystalNet有效性的案例。

案例1：向新的区域骨干迁移。我们的云平台允许用户在具有粗略地理区域概念的区域（例如，美国东部，欧洲西部）分配所需的资源。我们在每个单个区域内都有多个数据中心（DC），并且DC间/广域间的流量通常由DC间广域网（WAN）承载。但是，随着对同一区域内不同DC之间对高容量和低延迟的需求的增长，该设计已升级为包括新的区域骨干网，这些区域骨干网连接同一区域中的DC并绕过WAN以提高性能。

对一个运营网络做出如此重大的改变充满了危险。在迁移期间或迁移后，运营商必须保证在该地区没有明显的流量中断/干扰。由于硬件容量限制、IPv4地址短缺、交换机负载考虑和安全性等考虑，将数据中心连接到主干网的路由器中的路由配置已经相当复杂，甚至迁移计划中的小错误都可能导致大规模中断。

通过允许操作员在高保真仿真器中集中验证和完善其操作计划和软件工具，CrystalNet降低了此复杂操作的风险。

使用CrystalNet，我们模拟了一个网络，该网络由两个大型数据中心中的所有脊椎路由器（由供应商a提供，容器提供）、新区域主干中的所有路由器和传统广域网中的几个核心路由器（由供应商B提供，虚拟机提供）组成。边界被证明是安全的。在这个模拟环境中，对配置、操作计划和软件工具进行了彻底的测试。仿真网络只需要150个虚拟机（与第6.1节中的规范相同）。

在测试过程中，运营商在他们的工具和脚本中发现了50多个错误，其中一些可能会触发影响客户的停机。这种中断可能导致违反SLA的巨大经济惩罚，更重要的是，会导致客户信心的丧失。在CrystalNet上完善的最终迁移计划在生产过程中没有引发任何事件。甚至没有任何偶然的人为错误（例如错别字等），操作员将其归因于仿真器上的密集练习。

案例2：切换OS开发。CrystalNet还帮助我们的工程师建立验证管道，以开发专用版本的交换机OS CTNR-B。 我们模拟生产环境，用CTNR-B替换某些设备，并验证网络行为没有改变。我们甚至可以将运行CTNR-B的硬件设备插入仿真网络中，以进行集成测试。在两个月内，CrystalNet成功地发现了可能导致灾难性故障的O（10）错误。例如，从BGP获知路由时无法更新默认路由，由于陷阱实现不正确而导致无法将ARP数据包转发到CPU，在几个BGP会话震荡后崩溃，等等。在遗留开发管道中的单元测试或测试台测试均未发现这些错误，但在模拟生产环境中，从CrystalNet很容易检测到它们。

8 评价

在本节中，我们评估了CrystalNet在模拟生产数据中心网络时的性能和成本。

8.1 实验设置

网络。我们展示了三个真正的数据中心网络的CrystalNet，如表3所示。L-DC是我们最大的数据中心网络之一，M-DC和S-DC是典型的中小型数据中心网络。它们都有Clos拓扑结构。BGP是唯一的路由协议。Borders、Spine、Leaves和Tor是不同层上的交换机，从数据中心的边界到连接的服务器。TOR运行CTNR-B，而Border，Spine和Leaf交换机运行CTNR-A。CTNR-A和CTNR-B都被打包到容器图像中。

配置和路由。所有交换机都运行由我们的生产网络管理服务生成的生产配置。所有IP前缀和路由都取自相应生产网络的快照，并注入到仿真网络中。

计算资源。对于此评估，CrystalNet生成具有4核和8GB内存的虚拟机，如第6.1节所述。对于不同的规模，我们使用不同数量的VM。

性能指标。时间就是金钱，尤其是在云端。我们测量在虚拟机上花费的以下时间：（i）网络就绪延迟：从创建仿真开始到所有虚拟链路启动的时间；（ii）路由就绪延迟：从网络就绪到所有交换机中安装并稳定所有路由的时间。在此之后，仿真网络已准备就绪，可供操作员在其上运行测试。（iii）Mockup延迟：网络就绪和路由就绪延迟的总和。（iv）清除延迟：将虚拟机重置为干净状态所需的时间。

8.2 Mockup和清除操作的速度

即使是最大的数据中心，CrystalNet模拟的延迟和金钱成本也很低。图8显示了模拟整个S-DC、M-DC和L-DC的网络就绪、路由就绪和清除延迟。每个设置重复10次。在所有情况下，中型样机等待时间均小于32分钟，在第90个百分位数时，小于50分钟。清除延迟小于2分钟。对于每天执行的验证（例如每天推出或每天构建软件），这是可以接受的。

通过比较不同的虚拟机集群大小，我们看到更多的计算资源可以实现较小的Mockup延迟并具有较小的方差。但是，对于大型网络，例如L-DC / 500与L-DC / 1000的主要瓶颈是路由算法的收敛速度。

最大的数据中心L-DC需要500个虚拟机，每小时成本约100美元。对于S-DC这样的小型网络，每小时的成本仅为1美元左右。

供应商提供的软件的启动速度和路由收敛是Mockup延迟的主要组成部分，而CrystalNet的开销却很小。图8显示，在所有数据中心规模和虚拟机集群大小中，网络就绪延迟小于2分钟。它包括了第4节中描述的所有内容，并且只占Mockup总时间的<5%。

图8在不同数据中心规模上使用CrystalNet启动/停止仿真的第10、50和90％延迟

路由就绪延迟是Mockup延迟的主要组成部分。在这个阶段，所有设备都会建立与对等设备的BGP会话，并交换路由信息，直到整个网络上的路由汇聚。请注意，路由就绪延迟取决于网络规模、路由数量、路由协议和供应商提供的软件堆栈的实现，这些不受CrystalNet控制。图9显示了Mockup的瞬时CPU使用率。一开始，CPU使用率很高，用于创建大量虚拟接口和链接，以及初始化供应商提供的软件。大约10分钟后，CPU的使用率很低，但路由仍然需要5-20分钟才能收敛。

图9：CrystalNet VM CPU使用率

8.3本地更改的恢复速度

双层设计允许CrystalNet快速重新加载单个设备。我们将单个设备的重新加载时间与CrystalNet的PhyNet软件单独设计和strawman everything together设计进行了比较。在Crystal-Net中，即使设备软件重新启动，PhyNet层仍然存在，因此它不需要重新创建接口或链接。因此，CrystalNet需要3秒来重新加载一个设备，而strawman则需要至少15秒来重新配置接口和链接。一些设备软件甚至不支持热插拔接口（第4.1节），因此此类设备需要两层设计。

CrystalNet可以快速从虚拟机故障中恢复。我们还测试从失败（和重新启动）的虚拟机恢复所花费的时间，即重置该虚拟机上的设备和链接所需的时间。对于我们测试的所有网络，恢复时间从10秒到50秒不等，具体取决于部署密度。这不包括虚拟机重新启动所需的时间。我们正在研究一种设计，在这种设计中，CrystalNet保留少量备用虚拟机，以便快速交换出故障虚拟机，而不是等待故障虚拟机重新启动。

8.4安全静态边界的重要性

对于常见的验证案例，CrystalNet可以找到一个小的安全边界，并可以显着降低成本。在上述实验中，我们始终模拟整个数据中心网络。但是，实际上，网络运营商通常每次仅更新一小部分网络。因此，他们只需要验证该零件上的操作即可。下面我们使用L-DC拓扑来演示两种最常见的操作情况。

案例1：操作员通常希望对单个Pod进行更改，其中包括一组相邻的tor和leaf。如表4所示，算法1找到的最终仿真网络有4个叶子和16个TOR，它们位于目标吊舱内，外加64个脊椎和4个边界。仿真设备总数为88台，不到整个网络的2%。

案例2：运营商通常希望更改数据中心网络的Spine层，因为这些设备具有复杂的配置，如ACL或路由图。在L-DC中，为了模拟整个Spine层，安全边界包括整个Spine层和Border层。如表4所示，我们需要模拟不到3%的设备。

在这两种情况下，还有数百个speakerdevices（未在表4中显示）。但是，它们非常轻量级，一个VM至少可以支持其中的50个。总的来说，CrystalNet第一次只需要20个虚拟机，第二次只需要30个。操作员能够在模拟网络上执行所有必需的任务和验证。由于对整个网络进行仿真需要超过500个虚拟机，因此我们得出结论：CrystalNet的安全边界识别功能将运行仿真的成本降低了90%以上。

9 讨论

处理不确定性。 CrystalNet不会控制来自扬声器设备的路由通告的顺序。在大多数情况下，BGP，OSPF之类的路由协议与路由消息的时间和顺序无关[17，24]。但是，在对来自CrystalNet和生产环境的转发表进行交叉验证时，我们发现了一些不确定的BGP行为实例。当ECMP路径选择与IP前缀聚合一起使用时，会出现此现象。如图1所示，如果R6随机选择P3的路径或基于定时选择路径，则R6和R8上P3的路径将是不确定的。我们目前正在进一步研究此问题，因为几乎不可能精确模拟前缀公告的确切时间和顺序。同时，我们设计了一个FIB比较器来说明这种不确定性。

寻找所有路由协议的最小安全边界。在第5.2节中，我们提供了充分的条件来判断给定的边界设计对于特定的路由协议（如BGP、OSPF/is-is）是否安全。这些简单的指导原则适用于我们的数据中心网络和数据中心间广域网。然而，设计一个通用的算法来寻找任意路由协议的最小安全边界是一个挑战，因为答案不仅取决于路由协议和网络拓扑结构，而且还取决于仿真网络中要进行的更改的细节。我们把这个留作将来的工作。

CrystalNet的局限性。尽管CrystalNet允许我们将单个硬件设备插入仿真网络，但我们并不打算让真正的硬件构成大多数仿真设备。CrystalNet不适合捕捉ASIC问题。它不适合对数据平面性能（如带宽或延迟）进行详细测试——尽管可以发送探测数据包来验证路由。CrystalNet不打算查找由缓慢累积状态（如内存泄漏）或计时敏感错误（如多线程竞赛）引起的错误。必须使用标准的软件验证技术来找到它们。

此外，CrystalNet无法有效地回答诸如“是否存在一个或多个链路可能失败的场景，导致交换机X过多的流量？”. 暴力搜索这样的场景将需要大量的仿真。使用逻辑验证工具（如Minesweeper ）回答此类问题可能会更便宜，尽管使用此类工具必须愿意接受保真度降低。

测试方法。 CrystalNet提供了高保真网络仿真，以及通过仿真网络提取状态和跟踪数据包的基本基础结构。 我们让操作员使用这些基本的钩子来设计测试策略，以验证他们希望验证的内容。我们正在积极使用CrystalNet设计高效的测试方法，包括设计特定领域的语言以指定感兴趣的属性，并自动生成测试用例以验证这些属性。

可编程数据平面：CrystalNet还可用于调试和验证可编程和有状态数据平面（例如P4 [10]）中的逻辑。 我们正在使用CrystalNet构建灵活的调试和测试环境，以用于具有可编程数据平面的未来网络。

10 相关研究

网络仿真。 EmuLab 和CloudLab 在其自己的基础架构中提供网络仿真服务。它们允许用户定义网络拓扑和容量，并在仿真网络上运行实际的应用程序。但是，由于它们受基础结构规模的限制，目前它们不支持定制的交换机固件或具有按需扩展性。 Flexplane 是一种数据平面仿真器，用于测试ASIC中使用的资源管理算法。它不针对控制平面软件或配置，也不能轻易在多台机器上进行横向扩展。 Kang和Tao提出了一个框架，该框架利用容器对SDN上下文中的控制平面进行压力测试。他们的重点是SDN控制器的性能，而CrystalNet可以在SDN和传统的分布式网络中使用，以确保正确性。 MiniNet （多主机版本）和MaxNet 都是基于容器的网络仿真器，可以在分布式集群上运行。但是，它们不适合模拟大型的异构生产网络，因为它们缺少CrystalNet的三个关键功能：首先，它们不与多个公共云，私有集群和物理设备集成。第二，它们不支持异构黑盒设备固件，也不提供对用于管理生产网络的管理软件和工具的透明访问；第三，它们不自动识别安全的仿真边界，这对于以低成本保持高保真度是必需的。

配置验证。有多种努力使用形式验证技术来检查网络中的配置是否满足某些属性。这些系统采用理想的设备行为模型来根据配置文件计算转发表。实际上，设备行为远非理想（§2）。 CrystalNet是一种更实用的FIB计算方法。可以使用相同的验证技术来验证FIB。有些系统对于建模理想的系统行为和跟踪来源仍然很有用。这些工具比CrystalNet所需的资源更少，因此网络工程师可以在调用CrystalNet之前将它们用作他们的第一个低保真度检查。

数据平面验证。验证网络设备转发表中的规则对于系统地检测路由问题（例如，可达性冲突，黑洞和访问控制故障）非常重要。如前所述，CrystalNet通过提供来自仿真而不是真实网络的转发表来促进数据平面验证，从而可以主动发现问题。

11 结论

我们开发了CrystalNet，它提供了生产环境的高保真仿真来验证网络操作。 CrystalNet提供了高逼真的网络控制平面，按需可伸缩性，对异构设备软件的统一管理以及安全的仿真边界。这些功能对于构建有效的测试至关重要。并将CrystalNet与测试平台实验，配置验证和小型网络仿真器等替代方案区分开来。 CrystalNet具有高度可扩展性，成本效益比，并且在Microsoft的日常使用中避免了许多潜在的事故。

12 致谢

我们要感谢为该项目的成功做出贡献的许多Microsoft工程师。其中包括John Abeln，Dave Carlton，George Chen，Andrew Eaton，Shane Foster，Ivan Lee，Dave Maltz，Haseeb Niaz，Iona Yuan，Changqing Zhu等。我们要感谢我们的审稿人和ArvindKrishnamurthy的有益评论。

原文：CrystalNet: Faithfully Emulating Large Production Networks

点击 阅读原文 打开英文版原文。

https://www.microsoft.com/en-us/research/wp-content/uploads/2017/10/p599-liu.pdf