阅读说明：本技术 网络中服务质量配置的保证 (Ensuring quality of service configuration in a network ) 是由 钱德拉·那加拉甘 卡蒂克·莫汉拉姆 拉马纳·拉奥·孔佩拉 迪吉约特·塞西 桑德·伊耶 于 2018-04-17 设计创作，主要内容包括：用于保证网络中的服务质量配置的系统、方法和计算机可读介质。在一些示例中,一种系统获得软件定义网络的逻辑模型,该逻辑模型包括为软件定义网络指定的规则,该逻辑模型基于定义软件定义网络的可管理对象和对象属性的模式。该系统还获得针对软件定义网络中的每个节点的相应硬件模型,该相应硬件模型包括基于逻辑模型的相应特定于节点的表示在节点处呈现的规则。基于逻辑模型和相应硬件模型,该系统可以执行逻辑模型中的规则与相应硬件模型中的规则之间的等效性检查,以确定逻辑模型和相应硬件模型是否包含配置不一致。(Systems, methods, and computer-readable media for ensuring quality of service configuration in a network. In some examples, a system obtains a logical model of a software defined network that includes rules specified for the software defined network, the logical model based on a schema that defines manageable objects and object attributes of the software defined network. The system also obtains a respective hardware model for each node in the software defined network, the respective hardware model including rules that are presented at the node based on a respective node-specific representation of the logical model. Based on the logic model and the corresponding hardware model, the system may perform an equivalence check between the rules in the logic model and the rules in the corresponding hardware model to determine whether the logic model and the corresponding hardware model contain configuration inconsistencies.)

网络中服务质量配置的保证

相关申请交叉引用

本申请要求于2017年4月20日提交的题为“POLICY ASSURANCE OF QUALITY-OF-SERVICE CONFIGURATIONS IN A NETWORK(网络中服务质量配置的策略保证)”的美国临时专利申请No.62/487,930和于2017年8月31日提交的题为“ASSURANCE OF QUALITY-OF-SERVICE CONFIGURATIONS IN A NETWORK(网络中服务质量配置的保证)”美国非临时专利申请No.15/693,299的权益和优先权，它们两者的全部内容通过引用明确地并入本文。

技术领域

本技术涉及网络配置和故障排除，更具体地涉及网络中服务质量配置的保证。

背景技术

网络运营商配置用于指定服务质量(QoS)的策略，以便优先化网络中的流量。例如，实时流送应用可能要求其流量在网络中被给与优先级。可以通过在网络中配置特定的QoS策略来实现这种优先级。网络运营商可以将QoS策略配置为由网络中的节点(例如，交换机)传播或实现。例如，节点可以将其存储器(例如，TCAM存储器)中的QoS策略呈现为规则。

遗憾的是，网络中的QoS策略可能需要大量的手动工作来配置，并且通常容易出错。此外，即使被正确地配置，QoS策略也可能无法由网络中的节点适当地呈现。例如，QoS策略可能不会在交换机上产生正确的TCAM规则。这可能是各种问题的结果，例如网络故障、连接问题、设备或软件错误等。如果现场发生错误，网络运营商可能会通过在端口或节点之间发送测试流量并分析流量以识别问题。此过程可能很慢，导致进一步的故障停机时间，并且通常会使网络运营商的故障排除过程变得复杂。

具体实施方式

下面详细讨论本公开的各种实施例。虽然讨论了具体实现，但应该理解，仅出于说明目的而这样做。相关领域的技术人员将认识到，在不脱离本公开的精神和范围的情况下，可以使用其他组件和配置。因此，以下描述和附图是说明性的而不应被解释为限制性的。描述了许多具体细节以提供对本公开的透彻理解。然而，在某些情况下，没有描述众所周知的或传统的细节以避免使描述模糊。对本公开中的一个实施例或实施例的参考可以是对相同实施例或任何实施例的参考；并且，这样的参考意思是实施例中的至少一个。

对“一个实施例”或“实施例”的参考意味着结合该实施例描述的特定特征、结构或特性被包括在本公开的至少一个实施例中。在说明书中各处出现的短语“在一个实施例中”不一定都指代相同的实施例，也不是与其他实施例互斥的单独或替代实施例。此外，描述了可以由一些实施例而不由其他实施例展示的各种特征。

本说明书中使用的术语在本公开的上下文中以及在其中每个术语被使用的特定上下文中通常具有其在本领域中的普通含义。替代语言和同义词可以用于本文所讨论的任何一个或多个术语，并且本文是否详述或讨论术语不应特别重要。在某些情况下，提供了某些术语的同义词。对一个或多个同义词的叙述不排除对其他同义词的使用。本说明书中任何地方的对示例(包括本文所讨论的任何术语的示例)的使用仅是说明性的，并且不旨在进一步限制本公开或任何示例术语的范围和含义。同样地，本公开不限于本说明书中给出的各种实施例。

不意图限制本公开的范围，下面给出根据本公开的实施例的工具、装置、方法及其相关结果的示例。注意，为了方便读者，可能在示例中使用标题或副标题，这绝不应限制本公开的范围。除非另外定义，否则本文使用的技术和科学术语具有本公开所属领域的普通技术人员通常理解的含义。在发生冲突的情况下，以包括定义的本文件为准。

本公开的其他特征和优点将在下面的描述中阐述，并且部分地将从描述中显而易见，或者可以通过实践本文公开的原理来学习。借助于所附权利要求中特别指出的工具和组合，可以实现和获得本公开的特征和优点。根据以下描述和所附权利要求，本公开的这些和其他特征将变得更加明显，或者可以通过实践本文阐述的原理来学习本公开的这些和其他特征。

概述

软件定义网络(SDN)(例如以应用为中心的基础设施(ACI)网络)可以根据一个或多个集中式网络元件(例如，ACI网络中的应用策略基础设施控制器(APIC)或其他SDN网络中的网络管理器)来管理和配置。网络运营商可以为SDN网络定义各种配置、对象、规则等，其可以由一个或多个集中式网络元件实现。网络运营商所提供的配置信息可以反映网络运营商对SDN网络的意图，意思是网络运营商打算如何使SDN网络及其组件运行。这样的用户意图可以以编程方式封装在存储在集中式网络元件处的逻辑模型中。逻辑模型可以表示用户意图并反映SDN网络的配置。例如，逻辑模型可以表示由用户意图和/或集中式网络元件为特定SDN网络定义的对象和策略全集(例如，端点、租户、端点组、网络或上下文、应用简档、服务、域、策略等)。

在许多情况下，网络中的各种节点和/或控制器可以包含网络和网络状态的相应信息或表示。例如，不同的控制器可以存储网络的不同逻辑模型，并且网络结构中的每个节点可以包含其自己的网络配置模型。本文阐述的方法使得能够保证已经将QoS契约或策略正确地配置为设备的存储器(例如，交换机的TCAM存储器)中的规则。由于控制器和交换机软件使用复杂的优化来创建交换机TCAM规则，因此与契约相对应的规则可能没有与配置的契约进行简单的一对一映射。本文阐述的方法可以解决该问题，并且无论设备的硬件或软件使用任何优化，都能够实现保证。例如，本文的方法可以识别由于运营商错误导致的不一致以及各种消费者场景中的网络控制器(例如，SDN控制器)对QoS策略的不正确呈现。

本文公开了用于网络中QoS配置的策略保证的系统、方法和计算机可读介质。在一些示例中，一种系统或方法可以获得软件定义网络(SDN)的逻辑模型。逻辑模型可以表示与SDN相关联的模式中的对象的配置。对象的配置可以包括为SDN网络指定的规则。模式可以为SDN定义可管理的对象和对象属性。

对于SDN中的每个节点，该系统或方法还可以获得包括在节点处呈现或存储的规则的相应硬件模型。规则可以基于逻辑模型的相应特定于节点的表示。在一些情况下，在节点处呈现或存储的规则可以基于逻辑模型中指定的契约中的规则。契约和规则可以定义例如QoS策略、安全策略、流量规则等。

基于与节点相关联的相应硬件模型和逻辑模型，该系统或方法可以执行逻辑模型中的规则与相应硬件模型中的规则之间的等效性检查，以确定逻辑模型和相应硬件模型是否包含配置不一致。在一些情况下，可以通过比较为逻辑模型和相应硬件模型中的规则生成的和/或表示与逻辑模型和相应硬件模型中的规则相关联的值的相应数据结构来执行等效性检查。相应数据结构可以包括例如位向量、简化有序二元决策图(ROBDD)、n比特表示等。

示例实施例

所公开的技术解决了本领域对准确和有效的QoS保证的需求。本技术涉及用于网络中的QoS配置的保证的系统、方法和计算机可读介质。本技术将在以下公开内容中描述如下。本讨论开始于对网络保证的介绍性讨论和对示例计算环境的描述，如图1A和1B所示。接着是对网络保证的网络模型的讨论，如图2A至2D所示，以及对网络建模和保证系统的讨论，如图3A-C、4、5A-C、6A-C和7A-B所示。本讨论以对示例网络和计算设备的描述结束，如图8和9所示，包括适合于托管软件应用和执行计算操作的示例硬件组件。

本公开现在转到对网络保证的讨论。

网络保证是网络按照网络运营商的意图行事并且已经被正确配置的保证或确定(例如，网络正在做它想要做的事情)。意图可以包含各种网络操作，例如桥接、路由、安全性、服务链化、端点、合规性、QoS(服务质量)、审计等。意图可以体现在为网络和各个网络元件(例如，交换机、路由器、应用、资源等)定义的一个或多个策略、设置、配置等中。在某些情况下，网络运营商所定义的配置、策略等可能无法准确地反映在网络的实际行为中。例如，网络运营商为一种或多种类型的流量指定配置A，但后来发现网络实际上正在将配置B应用于该流量或以与配置A不一致的方式处理该流量。这可能是许多不同原因导致的结果，例如硬件错误、软件错误、不同优先级、配置冲突、一个或多个设置的误配置、设备不适当的规则呈现、意外错误或事件、软件升级、配置更改、故障等。作为另一示例，网络运营商为网络定义配置C，但是网络中的一个或多个配置使得网络以与网络运营商的配置C的实现所反映的意图不一致的方式运行。

本文的方法可以通过对网络的各个方面建模和/或执行一致性检查以及其他网络保证检查来提供网络保证。本文的网络保证方法可以在各种类型的网络中实现，包括专用网络，例如局域网(LAN)；企业网络；独立的或传统的网络，例如数据中心网络；包括物理或底层以及逻辑或覆盖层的网络，例如VXLAN或软件定义网络(SDN)(例如，以应用为中心的基础设施(ACI)或VMware NSX网络)；等等。

可以为网络构建网络模型并且实现网络模型以用于网络保证。网络模型可以提供网络的一个或多个方面的表示，包括但不限于，网络的策略、配置、要求、安全性、路由、拓扑、应用、硬件、过滤器、契约、访问控制列表、基础设施等。例如，网络模型可以提供网络中的配置的数学表示。如下面将进一步说明的，可以为网络生成不同类型的模型。

可以实现这样的模型以保证网络的行为将与通过网络运营商所实现的特定配置(例如，策略、设置、定义等)所反映的预期行为一致(或当前就是一致)。与传统的网络监控(传统网络监控涉及发送和分析数据分组以及观察网络行为)不同，可以通过建模来执行网络保证，而无需摄取分组数据或监控流量或网络行为。这可以带来先见之明、洞察力和后见之明：可以在问题发生之前预防问题，在问题发生时识别问题以及在问题发生后立即修复问题。

因此，网络保证可以涉及对网络的属性进行建模以确定性地预测网络的行为。如果(一个或多个)模型指示适当的行为(例如，没有不一致、冲突、错误等)，则可以确定网络是健康的。如果建模表明适当的行为但有点不一致，则可以确定网络是实现功能的，但不是完全健康的。如果建模指示不适当的行为和错误，则可以确定网络是不能实现功能的并且不健康。如果建模检测到不一致或错误，则对相应(一个或多个)模型的详细分析可以允许非常准确地识别出一个或多个基础或根本问题。

建模可以利用多种类型的智能事件，其对网络的大量行为方面进行建模。智能事件可以影响网络的各个方面，例如底层服务、覆盖服务、租户连接性、租户安全性、租户端点(EP)移动性、租户策略、租户路由、资源等。

已经描述了网络保证的各个方面，本公开现在转到对用于网络保证的示例网络环境的讨论。

图1A示出了示例网络环境100的图，例如数据中心。网络环境100可以包括可以表示网络环境100的物理层或基础设施(例如，底层)的结构120。结构120可以包括脊节点(spine)102(例如，脊路由器或交换机)和叶节点(leaf)104(例如，叶路由器或交换机)，它们可以互连以便在结构120中路由或交换流量。脊节点102可以互连结构120中的叶节点104，并且叶节点104可以将结构120连接到网络环境100的覆盖或逻辑部分，其可以包括应用服务、服务器、虚拟机、容器、端点等。因此，结构120中的网络连接性可以从脊节点102流向叶节点104，反之亦然。叶节点104和脊节点102之间的互连可以是冗余的(例如，多个互连)以避免路由故障。在一些实施例中，叶节点104和脊节点102可以完全连接，使得任何给定的叶节点都连接到每个脊节点102，并且任何给定的脊节点都连接到每个叶节点104。叶节点104可以是例如架顶式(“ToR”)交换机、聚合交换机、网关、入口和/或出***换机、提供者边缘设备和/或任何其他类型的路由或交换设备。

叶节点104可以负责路由和/或桥接租户或客户分组以及应用网络策略或规则。网络策略和规则可以由一个或多个控制器116驱动，和/或由诸如叶节点104之类的一个或多个设备实现或实施。叶节点104可以将其他元件连接到结构120。例如，叶节点104可以将服务器106、管理程序108、虚拟机(VM)110、应用112、网络设备114等与结构120连接。这些元件可以驻留在一个或多个逻辑或虚拟层或网络中，例如覆盖网络。在一些情况下，叶节点104可以对去往和来自这些元件(例如，服务器106)的分组进行封装和解封装，以便使得能够进行遍及网络环境100和结构120的通信。叶节点104还可以向任何其他设备、服务、租户或工作负载提供对结构120的接入。在一些情况下，连接到叶节点104的服务器106可以类似地对去往和来自叶节点104的分组进行封装和解封装。例如，服务器106可以包括一个或多个虚拟交换机或路由器或隧道端点，用于在由服务器106托管或连接到服务器106的覆盖层或逻辑层与由结构120表示并通过叶节点104访问的底层之间用隧道传输分组。

应用112可以包括软件应用、服务、容器、设备、功能、服务链等。例如，应用112可以包括防火墙、数据库、CDN服务器、IDS/IPS、深度分组检查服务、消息路由器、虚拟变换机等。来自应用112的应用可以由多个端点(例如，服务器106、VM 110等)分发、链接或托管，或者可以完全从单个端点运行或执行。

VM 110可以是由管理程序108托管的虚拟机或在服务器106上运行的虚拟机管理器。VM 110可以包括在相应服务器上的访客操作系统上运行的工作负载。管理程序108可以提供创建、管理和/或运行VM 110的软件、固件和/或硬件层。管理程序108可以允许VM 110共享服务器106上的硬件资源，并且允许服务器106上的硬件资源显示为多个独立的硬件平台。此外，服务器106上的管理程序108可以托管一个或多个VM 110。

在一些情况下，VM 110和/或管理程序108可以迁移到其他服务器106。服务器106可以类似地迁移到网络环境100中的其他位置。例如，连接到特定叶节点的服务器可以改变为连接到不同的或额外的叶节点。此类配置或部署更改可能涉及对应用于正在迁移的资源以及其他网络组件的设置、配置和策略的修改。

在一些情况下，一个或多个服务器106、管理程序108和/或VM 110可以表示或驻留在租户或客户空间中。租户空间可以包括与一个或多个客户端或订户相关联的工作负载、服务、应用、设备、网络和/或资源。因此，可以基于特定租户策略、空间、协议、配置等来路由网络环境100中的流量。此外，寻址可以在一个或多个租户之间变化。在一些配置中，租户空间可以被划分为逻辑段和/或网络，并且与跟其他租户相关联的逻辑段和/或网络分开。租户之间的寻址、策略、安全性和配置信息可以由控制器116、服务器106、叶节点104等管理。

网络环境100中的配置可以在逻辑级、硬件级(例如，物理级)和/或两者处实现。例如，可以通过软件定义网络(SDN)框架(例如，以应用为中心的基础设施(ACI)或VMWARENSX)，基于端点或资源属性(例如，端点类型和/或应用组或简档)来在逻辑和/或硬件级实现配置。为了说明，一个或多个管理员可以通过控制器116在逻辑级(例如，应用或软件级)定义配置，控制器116可以通过网络环境100实现或传播这样的配置。在一些示例中，控制器116可以是ACI框架中的应用策略基础设施控制器(APIC)。在其他示例中，控制器116可以是与其他SDN解决方案相关联的一个或多个管理组件，例如，NSX管理器。

这样的配置可以定义用于在网络环境100中路由和/或分类流量的规则、策略、优先级、协议、属性、对象等。例如，这样的配置可以定义用于基于端点组(EPG)、安全组(SG)、VM类型、桥接域(BD)、虚拟路由和转发实例(VRF)、租户、优先级、防火墙规则等来分类和处理流量的属性和对象。下面进一步描述其他示例网络对象和配置。可以基于流量的标签、属性或其他特性来实施流量策略和规则，诸如与流量相关联的协议、与流量相关联的EPG、与流量相关联的SG、与流量相关联的网络地址信息等。这样的策略和规则可以由网络环境100中的一个或多个元件(例如，叶节点104、服务器106、管理程序108、控制器116等)实施。如前所述，可以根据一个或多个特定软件定义网络(SDN)解决方案(例如，CISCO ACI或VMWARENSX)来配置网络环境100。下面简要描述这些示例SDN解决方案。

ACI可以通过可缩放的分布式实施来提供以应用为中心或基于策略的解决方案。ACI支持在针对网络、服务器、服务、安全性、要求等的声明性配置模型下集成物理和虚拟环境。例如，ACI框架实现EPG，EPG可以包括共享通用配置要求(例如，安全性、QoS、服务等)的端点或应用的集合。端点可以是虚拟/逻辑或物理设备，例如，连接到网络环境100的VM、容器、主机或物理服务器。端点可以具有一个或多个属性，例如，VM名称、访客OS名称、安全标签、应用简档等。应用配置可以以契约的形式在EPG之间应用，而不是直接应用于端点之间。叶节点104可以将传入的流量分类为不同的EPG。分类可以基于例如网络段标识符，例如，VLAN ID、VXLAN网络标识符(VNID)、NVGRE虚拟子网标识符(VSID)、MAC地址、IP地址等。

在一些情况下，ACI基础设施中的分类可以由应用虚拟交换机(AVS)实现，其可以在诸如服务器或交换机之类的主机上运行。例如，AVS可以基于指定的属性对流量进行分类，并且对具有不同标识符(例如，网络段标识符(例如，VLAN ID))的不同属性EPG的分组进行标记。最后，叶节点104可以基于其标识符和实施策略来将分组与其属性EPG绑定，这可以由一个或多个控制器116实现和/或管理。叶节点104可以对来自主机的流量属于哪个EPG进行分类并且相应地实施策略。

另一示例SDN解决方案基于VMWARE NSX。使用VMWARE NSX，主机可以运行分布式防火墙(DFW)，其可以对流量进行分类和处理。考虑将三种类型的VM(即，应用、数据库和webVM)放入单个第2层网络段的情况。可以基于VM类型在网络段内提供流量保护。例如，可以在web VM之间允许HTTP流量，并且在web VM与应用或数据库VM之间不允许HTTP流量。为了对流量进行分类并实现策略，VMWARE NSX可以实现安全组，该安全组可用于对特定VM(例如，web VM、应用VM、数据库VM)进行分组。可以配置DFW规则以实现针对特定安全组的策略。为了说明，在前面的示例的上下文中，DFW规则可以被配置为阻止web、应用和数据库安全组之间的HTTP流量。

现在回到图1A，网络环境100可以通过叶节点104、服务器106、管理程序108、VM110、应用112和控制器116来部署不同的主机，例如VMWARE ESXi主机、WINDOWS HYPER-V主机、裸金属物理主机等。网络环境100可以与各种管理程序108、服务器106(例如，物理和/或虚拟服务器)、SDN编排平台等进行互操作。网络环境100可以实现声明性模型以允许其与应用设计和整体网络策略的集成。

控制器116可以提供对软件定义网络(SDN)基础设施的结构信息、应用配置、资源配置、应用级配置建模的集中访问，与管理系统或服务器的集成等。控制器116可以形成通过北向API与应用平面进行接口，并且通过南向API与数据平面进行接口的控制平面。

如前所述，控制器116可以定义和管理网络环境100中的针对配置的(一个或多个)应用级模型。在一些情况下，还可以由网络中的其他组件管理和/或定义应用或设备配置。例如，管理程序或虚拟设备(例如，VM或容器)可以运行服务器或管理工具来管理网络环境100中的软件和服务，包括虚拟设备的配置和设置。

如上所示，网络环境100可以包括一个或多个不同类型的SDN解决方案、主机等。为了清楚和解释的目的，将参考ACI框架描述本公开中的各种示例，并且控制器116可以可互换地被称为控制器、APIC或APIC控制器。然而，应该注意，本文的技术和概念不限于ACI解决方案，并且可以在其他架构和场景中实现，包括其他SDN解决方案以及可以不部署SDN解决方案的其他类型的网络。

此外，如本文所引用的，术语“主机”可以指代服务器106(例如，物理的或逻辑的)、管理程序108、VM 110、容器(例如，应用112)等，并且可以运行或包括任何类型的服务器或应用解决方案。“主机”的非限制性示例可以包括，虚拟交换机或路由器，例如分布式虚拟交换机(DVS)、应用虚拟交换机(AVS)、矢量分组处理(VPP)交换机；VCENTER和NSX管理器；裸金属物理主机；HYPER-V主机；VM；DOCKER容器；等等。

图1B示出了网络环境100的另一示例。在该示例中，网络环境100包括连接到结构120中的叶节点104的端点122。端点122可以是物理和/或逻辑或虚拟实体，诸如服务器、客户端、VM、管理程序、软件容器、应用、资源、网络设备、工作负载等。例如，端点122可以是表示下列项的对象：物理设备(例如，服务器、客户端、交换机等)、应用(例如，web应用、数据库应用等)、逻辑或虚拟资源(例如，虚拟交换机、虚拟服务设备、虚拟化网络功能(VNF)、VM、服务链等)、运行软件资源的容器(例如，应用、设备、VNF、服务链等)、存储设备、工作负载或工作负载引擎等。端点122可以具有地址(例如，身份)、位置(例如，主机、网络段、虚拟路由和转发(VRF)实例、域等)、一个或多个属性(例如，名称、类型、版本、补丁级别、OS名称、OS类型等)、标签(例如，安全标签)、简档等。

端点122可以与相应的逻辑组118相关联。逻辑组118可以是包含根据以下各项分组在一起的端点(物理和/或逻辑或虚拟)的逻辑实体：一个或多个属性(例如，端点类型(例如，VM类型、工作负载类型、应用类型等))，一个或多个要求(例如，策略要求、安全性要求、QoS要求、客户要求、资源要求等)，资源名称(例如，VM名称、应用名称等)，简档，平台或操作系统(OS)特性(例如，包括访客和/或主机OS的OS类型或名称等)，关联的网络或租户，一个或多个策略，标签等。例如，逻辑组可以是表示分组在一起的端点集合的对象。为了说明，逻辑组1可以包含客户端端点，逻辑组2可以包含web服务器端点，逻辑组3可以包含应用服务器端点，逻辑组N可以包含数据库服务器端点等。在一些示例中，逻辑组118是ACI环境中的EPG和/或另一SDN环境中的其他逻辑组(例如，SG)。

可以基于逻辑组118对去往端点122和/或来自端点122的流量进行分类、处理、管理等。例如，逻辑组118可以用于对去往端点122或者来自端点122的流量进行分类，将策略应用于去往端点122或者来自端点122的流量，定义端点122之间的关系，定义端点122的角色(例如，端点是消费还是提供服务等)，将规则应用于去往端点122或来自端点122的流量，对去往端点122或来自端点122的流量应用过滤器或访问控制列表(ACL)，为去往端点122或来自端点122的流量定义通信路径，实施与端点122相关联的要求，实现与端点122相关联的安全性以及其他配置等。

在ACI环境中，逻辑组118可以是用于在ACI中定义契约的EPG。契约可以包括指定EPG之间发生什么通信和如何发生通信的规则。例如，契约可以定义提供服务的是什么，消费服务的是什么以及什么策略对象与该消费关系相关。契约可以包括定义如下内容的策略：通信路径以及端点或EPG之间的通信或关系的所有相关元素。例如，Web EPG可以提供客户端EPG所消费的服务，并且该消费可以经受过滤器(ACL)和包括一个或多个服务(例如，防火墙检查服务和服务器负载平衡)的服务图。

图2A示出了诸如网络环境100之类的SDN网络的示例模式的图。该模式可以定义与SDN网络相关联的对象、属性和关系。在该示例中，模式是管理信息模型200，如下面进一步描述的。然而，在其他配置和实现中，该模式可以是与不同类型的网络相关联的不同模型或规范。

对管理信息模型200的以下讨论引用了各种术语，这些术语也将在整个公开内容中使用。因此，为了清楚起见，本公开首先将在下面提供术语列表，随后将对管理信息模型200进行更详细的讨论。

如本文所使用的，“别名”可以指代给定对象的可变名称。即使对象名称一旦创建就无法更改，别名也可以是可以更改的字段。术语“别名化”可以指代与一个或多个其他规则重叠的规则(例如，契约、策略、配置等)。例如，如果契约1与契约2完全重叠，则在网络的逻辑模型中定义的契约1可以说是别名化在网络的逻辑模型中定义的契约2。在此示例中，通过别名化契约2，契约1使得契约2冗余或不可操作。例如，如果契约1具有比契约2更高的优先级，则这种别名化可以基于合契约1的重叠和更高优先级特性而使契约2冗余。

如本文所使用的，术语“APIC”可以指代ACI框架中的一个或多个控制器(例如，控制器116)。APIC可以为ACI多租户结构提供统一的自动化和管理点、策略编程、应用部署、健康监控。APIC可以实现为单个控制器，分布式控制器，或复制的、同步的和/或集群的控制器。

如本文所使用的，术语“BDD”可以指代二元决策树。二元决策树可以是表示函数(例如，布尔函数)的数据结构。

如本文所使用的，术语“BD”可以指代桥接域。桥接域可以是一组共享相同洪泛或广播特性的逻辑端口。与虚拟LAN(VLAN)一样，桥接域可以跨越多个设备。桥接域可以是L2(第2层)构建。

如本文所使用的，“消费者”可以指代消费服务的端点、资源和/或EPG。

如本文所使用的，“上下文”可以指代L3(第3层)地址域，其允许路由表的多个实例存在并同时工作。这通过允许在不使用多个设备的情况下对网络路径进行分段来提高功能性。上下文或L3地址域的非限制性示例可以包括虚拟路由和转发(VRF)实例、私网等。

如本文所使用的，术语“契约”可以指代指定在网络中进行什么通信以及如何进行通信(例如，允许、拒绝、过滤、处理等)的规则或配置。在ACI网络中，契约可以指定端点和/或EPG之间的通信如何发生。在一些示例中，契约可以提供类似于访问控制列表(ACL)的规则和配置。

如本文所使用的，术语“可辨别名称”(DN)可以指代如下的唯一名称：其描述诸如MO之类的对象，并且在管理信息模型200中定位其位置。在一些情况下，DN可以是(或等同于)全限定域名(FQDN)。

如本文所使用的，术语“端点组”(EPG)可以指代与端点的集合或组相关联的逻辑实体或对象，如先前参考图1B所描述的。

如本文所使用的，术语“过滤器”可以指代用于允许通信的参数或配置。例如，在其中默认情况下所有通信都被阻止的白名单模型中，必须给予通信明确的许可，以防止此类通信被阻止。过滤器可以定义针对一个或多个通信或分组的(一个或多个)许可。因此，过滤器的功能可以类似于ACL或防火墙规则。在一些示例中，过滤器可以在分组(例如，TCP/IP)报头字段中实现，例如，L3协议类型、L4(第4层)端口等，其例如用于允许端点或EPG之间的入站或出站通信。

如本文所使用的，术语“L2输出”可以指代桥接连接。桥接连接可以连接同一网络的两个或更多个段，使得它们可以通信。在ACI框架中，L2输出可以是ACI结构(例如，结构120)和外部第2层网络(例如，交换机)之间的桥接(第2层)连接。

如本文所使用的，术语“L3输出”可以指代路由连接。路由第3层连接使用一组协议，该组协议确定数据所遵循的路径以便跨网络地从其源行进到其目的地。路由连接可以根据所选择的协议(例如，BGP(边界网关协议)、OSPF(开放式最短路径优先)、EIGRP(增强型内部网关路由协议)等)来执行转发(例如，IP转发)。

如本文所使用的，术语“管理对象”(MO)可以指代在网络(例如，网络环境100)中管理的对象的抽象表示。对象可以是具体对象(例如，交换机、服务器、适配器等)或逻辑对象(例如，应用简档、EPG、故障等)。MO可以是在网络中管理的网络资源或元素。例如，在ACI环境中，MO可以包括ACI结构(例如，结构120)资源的抽象。

如本文所使用的，术语“管理信息树”(MIT)可以指代包含系统的MO的分层管理信息树。例如，在ACI中，MIT包含ACI结构(例如，结构120)的MO。MIT也可以被称为管理信息模型(MIM)，例如管理信息模型200。

如本文所使用的，术语“策略”可以指代用于控制系统或网络行为的某些方面的一个或多个规范。例如，策略可以包括命名实体，该实体包含用于控制系统行为的某些方面的规范。为了说明，第3层外部网络策略可以包含BGP协议，以在将结构120连接到外部第3层网络时使能BGP路由功能。

如本文所使用的，术语“简档”可以指代与策略相关联的配置细节。例如，简档可以包括命名实体，该实体包含用于实现策略的一个或多个实例的配置细节。为了说明，针对路由策略的交换机节点简档可以包含特定于交换机的配置细节以实现BGP路由协议。

如本文所使用的，术语“提供者”指代提供服务的对象或实体。例如，提供者可以是提供服务的EPG。

如本文所使用的，术语“主体”指代用于定义通信的契约中的一个或多个参数。例如，在ACI中，契约中的主体可以指定什么信息可以被传送以及如何被传送。主体的功能类似于ACL。

如本文所使用的，术语“租户”指代网络中的隔离单元。例如，租户可以是安全且排他的虚拟计算环境。在ACI中，租户可以是从策略角度看的隔离单元，但不一定代表私网。实际上，ACI租户可以包含多个私网(例如，VRF)。租户可以代表服务提供者设置中的消费者、企业设置中的组织或域、或仅代表策略组。

如本文所使用的，术语“VRF”指代虚拟路由和转发实例。VRF可以定义第3层地址域，其允许路由表的多个实例存在并同时工作。这通过允许在不使用多个设备的情况下对网络路径进行分段来提高功能性。其也被称为上下文或私网。

已经描述了本文使用的各种术语，本公开现在返回到图2A中对管理信息模型(MIM)200的讨论。如前所述，MIM 200可以是分层管理信息树或MIT。此外，MIM 200可以由控制器116(例如，ACI中的APIC)管理和处理。控制器116可以通过将其可管理特性呈现为可以根据对象在模型的分层结构内的位置而继承的对象属性来实现对被管理资源的控制。

MIM 200的分层结构从位于顶部(根)的策略全集202开始并且包含双亲(parent)节点和子节点116、204、206、208、210、212。树中的节点116、202、204、206、208、210、212表示管理对象(MO)或对象组。结构(例如，结构120)中的每个对象具有唯一的可辨别名称(DN)，其描述对象并定位其在树中的位置。节点116、202、204、206、208、210、212可以包括各种MO，如下所述，其包含管理系统操作的策略。

控制器116

控制器116(例如，APIC控制器)可以为结构120提供管理、策略编程、应用部署和健康监控。

节点204

节点204包括用于使管理员能够执行基于域的访问控制的策略的租户容器。租户的非限制性示例可以包括：

管理员根据用户的需求定义的用户租户。它们包含管理资源(例如，应用、数据库、web服务器、网络附接存储、虚拟机等)的操作的策略。

共同租户由系统提供，但是可以由管理员配置。它包含管理所有租户可访问资源(例如，防火墙、负载平衡器、第4层到第7层服务、入侵检测设备等)的操作的策略。

基础设施租户由系统提供，但是可以由管理员配置。它包含管理基础设施资源(例如，结构覆盖(例如，VXLAN))的操作的策略。它还使结构提供者能够选择性地将资源部署到一个或多个用户租户。基础设施租户策略可由管理员配置。

管理租户由系统提供，但是可以由管理员配置。它包含管理结构管理功能的操作的策略，这些功能用于对结构节点的带内和带外配置。管理租户包含用于控制器/结构内部通信的私有带外地址空间，其位于通过交换机的管理端口提供访问的结构数据路径之外。管理租户使能与虚拟机控制器的通信的发现和自动化。

节点206

节点206可以包含管理交换机访问端口的操作的访问策略，交换机访问端口提供到诸如存储、计算、第2层和第3层(桥接和路由)连接性、虚拟机管理程序、第4层到第7层设备等之类的资源的连接。如果租户需要除默认链路、思科发现协议(CDP)、链路层发现协议(LLDP)、链路聚合控制协议(LACP)或生成树协议(STP)中提供的接口配置以外的接口配置，管理员可以配置访问策略以在叶节点104的访问端口上使能此类配置。

节点206可以包含管理交换机结构端口的操作的结构策略，包括诸如网络时间协议(NTP)服务器同步、中间系统到中间系统协议(IS-IS)、边界网关协议(BGP)路由反射器、域名系统(DNS)等之类的功能。结构MO包含诸如电源、风扇、底座等之类的对象。

节点208

节点208可以包含VM域，其将具有类似的联网策略要求的VM控制器分组。VM控制器可以共享虚拟空间(例如，VLAN或VXLAN空间)和应用EPG。控制器116与VM控制器通信以发布网络配置，例如随后应用于虚拟工作负载的端口组。

节点210

节点210可以包含第4层到第7层服务集成生命周期自动化框架，其使得系统能够在服务在线或离线时动态响应。策略可以提供服务设备包和库存管理功能。

节点212

节点212可以包含管理结构120的用户权限、角色和安全域的访问、认证和计费(AAA)策略。

分层策略模型可以很好地适合API，例如REST API接口。调用时，API可以读取或写入MIT中的对象。URL可以直接映射到标识MIT中对象的可辨别名称。例如，MIT中的数据可以被描述为以XML或JSON编码的自包含结构化树文本文档。

图2B示出了用于MIM 200的租户部分的示例对象模型220。如前所述，租户是用于使管理员能够执行基于域的访问控制的应用策略的逻辑容器。因此，租户代表了从策略角度看的隔离单元，但它不一定代表私网。租户可以代表服务提供者设置中的消费者、企业设置中的组织或域、或者仅代表方便的策略分组。此外，租户可以彼此隔离或可以共享资源。

MIM 200的租户部分204A可以包括各种实体，并且租户部分204A中的实体可以从双亲实体继承策略。租户部分204A中的实体的非限制性示例可以包括过滤器240、契约236、外部网络222、桥接域230、VRF实例234和应用简档224。

桥接域230可以包括子网232。契约236可以包括主体238。应用简档224可以包含一个或多个EPG 226。一些应用可以包含多个组件。例如，电子商务应用可能需要web服务器、数据库服务器、位于存储区域网络中的数据、以及对实现金融交易的外部资源的访问。应用简档224包含与提供应用的能力在逻辑上相关的尽可能多(或少)的EPG。

EPG 226可以以各种方式来组织，例如基于它们提供的应用、它们提供的功能(例如基础设施)、它们在数据中心(例如DMZ)的结构中的位置、或者结构或租户管理员选择使用的任何组织原则。

结构中的EPG可以包含各种类型的EPG，例如，应用EPG、第2层外部网络外实例EPG、第3层外部网络外实例EPG、用于带外或带内访问的管理EPG等。EPG 226还可以包含属性228，例如基于封装的EPG、基于IP的EPG、或基于MAC的EPG。

如前所述，EPG可以包含具有共同特性或属性(例如，共同策略要求(例如，安全性、虚拟机移动性(VMM)、QoS、或第4层到第7层服务)的端点(例如，EP 122)。不是单独配置和管理端点，而是它们可以放在EPG中并作为组进行管理。

策略应用于EPG，包括它们所包含的端点。EPG可以由管理员在控制器116中静态配置，或者由诸如VCENTER或OPENSTACK之类的自动系统动态配置。

为了在租户部分204A中激活租户策略，应配置结构访问策略并将其与租户策略相关联。访问策略使管理员能够配置其他网络配置，例如，端口信道和虚拟端口信道，诸如LLDP、CDP或LACP之类的协议，以及诸如监控或诊断之类的特征。

图2C示出了MIM 200中的租户实体和访问实体的示例关联260。策略全集202包含租户部分204A和访问部分206A。因此，租户部分204A和访问部分206A通过策略全集202相关联。

访问部分206A可以包含结构和基础设施访问策略。通常，在策略模型中，EPG与VLAN耦合。例如，对于要流过的流量，EPG部署在叶端口上，其具有在物理、VMM、L2输出、L3输出或光纤信道域中的VLAN。

因此，访问部分206A包含域简档236，其可以定义例如要与EPG相关联的物理、VMM、L2输出、L3输出或光纤信道域。域简档236包含VLAN实例简档238(例如，VLAN池)和可附接访问实体简档(AEP)240，它们直接与应用EPG相关联。AEP 240将关联的应用EPG部署到它所附接的端口，并自动执行分配VLAN的任务。虽然大型数据中心可以在数百个VLAN上配有数千个活动的VM，但结构120可以自动从VLAN池分配VLAN ID。与在传统数据中心中中继(trunkdown)VLAN相比，这节省了时间。

图2D示出了网络(例如，网络环境100)的示例模型的示意图。可以基于与MIM 200中定义的各种对象、策略、属性和元素相关联的特定配置和/或网络状态参数来生成模型。模型可以被实现用于网络分析和保证，并且可以在实现的各个阶段和网络的各个级别提供对网络的描述。

如图所示，模型可以包括L_模型270A(逻辑模型)、LR_模型270B(逻辑呈现模型或逻辑运行时模型)、Li_模型272(针对i的逻辑模型)、Ci_模型274(针对i的具体模型)和/或Hi_模型276(针对i的硬件模型或TCAM模型)。

L_模型270A是在网络(例如，网络环境100)中配置的MIM 200中的各种元素(例如，如网络中配置的MIM 200中的对象、对象属性、对象关系和其他元素)的逻辑表示。控制器116可以基于针对网络而输入在控制器116中的配置来生成L_模型270A，并且因此L_模型270A表示控制器116处的网络的逻辑配置。这是对在网络实体(例如，应用、租户等)的元素被连接并且结构120被控制器116配设时所期望的“结束状态”表达的声明。因为L_模型270A表示输入在控制器116中的配置(包括MIM 200中的对象和关系)，它还可以反映管理员的“意图”：管理员希望网络和网络元件如何运作。

L_模型270A可以是结构或网络范围的逻辑模型。例如，L_模型270A可以描述来自每个控制器116的配置和对象。如前所述，网络环境100可以包括多个控制器116。在一些情况下，两个或更多个控制器116可以包括用于网络的不同配置或逻辑模型。在这种情况下，L_模型270A可以获得来自控制器116的配置或逻辑模型中的任一者，并基于来自所有控制器116的配置和逻辑模型来生成结构或网络范围的逻辑模型。因此，L_模型270A可以在控制器116之间合并配置或逻辑模型，以提供综合的逻辑模型。L_模型270A还可以解决或解释可能由不同控制器116处的配置或逻辑模型导致的任何依赖性、冗余、冲突等。

LR_模型270B是控制器116(例如，ACI中的APIC)从L_模型270A中解析的抽象模型表达。LR_模型270B可以提供将被递送到物理基础设施(例如，结构120)以执行一个或多个策略的配置组件。例如，LR_模型270B可以被递送到结构120中的叶节点104，以将叶节点104配置用于与附接的端点122通信。LR_模型270B还可以合并状态信息以捕获网络(例如，结构120)的运行时状态。

在一些情况下，LR_模型270B可以提供L_模型270A的表示，其根据可以传播到结构120的物理基础设施(例如，叶节点104、脊节点102等)和/或被结构120的物理基础设施所理解的特定格式或表达来标准化。例如，LR_模型270B可以将L_模型270A中的元素与可以由结构120中的交换机解释和/或编译的特定标识符或标签(例如，用作分类符的硬件平面标识符)相关联。

Li_模型272是从L_模型270A和/或LR_模型270B获得的交换机级或特定于交换机的模型。Li_模型272可以将L_模型270A和/或LR_模型270B投射在特定交换机或设备i上，因此可以传达L_模型270A和/或LR_模型270B应该如何出现在特定交换机或设备i处或如何在特定交换机或设备i处实现。

例如，Li_模型272可以投射与特定交换机i有关的L_模型270A和/或LR_模型270B，以捕获L_模型270A和/或LR_模型270B在交换机i处的交换机级表示。为了说明，Li_模型272L₁可以表示投射到叶节点1(104)或在叶节点1(104)处实现的L_模型270A和/或LR_模型270B。因此，对于结构120上的单独设备(例如，叶节点104、脊节点102等)，可以从L_模型270A和/或LR_模型270B生成Li_模型272。

在一些情况下，可以使用JSON(JavaScript对象表示法)来表示Li_模型272。例如，Li_模型272可以包括JSON对象，例如规则、过滤器、条目和范围。

Ci_模型274是单独的结构成员i(例如，交换机i)处的实际入状态(in-state)配置。换句话说，Ci_模型274是基于Li_模型272的交换机级或特定于交换机的模型。例如，控制器116可以将Li_模型272递送到叶节点1(104)。叶节点1(104)可以采用Li_模型272(其可以特定于叶节点1(104))，并且叶节点1(104)可以将Li_模型272中的策略呈现为在叶节点1(104)上运行的具体模型Ci_模型274。例如，叶节点1(104)可以通过叶节点1(104)上的OS来呈现Li_模型272。因此，Ci_模型274可以类似于经编译的软件，因为它是叶节点1(104)处的交换机OS可以执行的Li_模型272的形式。

在一些情况下，Li_模型272和Ci_模型274可以具有相同或相似的格式。例如，Li_模型272和Ci_模型274可以基于JSON对象。具有相同或相似格式可以协助Li_模型272和Ci_模型274中的对象进行比较以确定是否等效或一致。如本文进一步描述的，这种等效或一致检查可以用于网络分析和保证。

Hi_模型276也是针对交换机i的交换机级或特定于交换机的模型，但是基于针对交换机i的Ci_模型274。Hi_模型276是在单独的结构成员i(例如，交换机i)处的硬件或存储器(例如，TCAM存储器)上存储或呈现的实际配置(例如，规则)。例如，Hi_模型276可以表示叶节点1(104)基于叶节点1(104)处的Ci_模型274在叶节点1(104)的硬件(例如，TCAM存储器)上存储或呈现的配置(例如，规则)。叶节点1(104)处的交换机OS可以呈现或执行Ci_模型274，并且叶节点1(104)可以存储或呈现来自存储设备(例如，叶节点1(104)处的存储器或TCAM)中的Ci_模型274的配置。由叶节点1(104)存储或呈现的来自Hi_模型276的配置表示在处理流量时将由叶节点1(104)实现的配置。

虽然模型272、274、276被示出为特定于设备的模型，但是类似的模型可以为结构120中的结构成员(例如，叶节点104和/或脊节点102)的集合生成或聚合。当被组合时，特定于设备的模型(例如模型272、模型274和/或模型276)可以提供超出特定设备的结构120的表示。例如，在一些情况下，可以组合或聚合与一些或所有单独的结构成员(例如，叶节点104和脊节点102)相关联的Li_模型272、Ci_模型274和/或Hi_模型276，以基于单独的结构成员生成一个或多个聚合模型。

如本文所引用的，术语H模型、T模型和TCAM模型可以互换使用以指代硬件模型，例如Hi_模型276。例如，Ti模型、Hi模型和TCAMi模型可以互换使用，以指代Hi_模型276。

模型270A、270B、272、274、276可以提供网络的各个方面的表示或MIM 200的各个配置阶段的表示。例如，模型270A、270B、272、274、276中的一个或多个可以用于生成表示结构120的一个或多个方面(例如，底层拓扑、路由等)的底层模型278，表示网络环境100的覆盖或(一个或多个)逻辑段的一个或多个方面(例如，COOP、MPBGP、租户、VRF、VLAN、VXLAN、虚拟应用、VM、管理程序、虚拟交换等)的覆盖模型280，表示MIM 200中的租户部分204A的一个或多个方面(例如，安全性、转发、服务链、QoS、VRF、BD、契约、过滤器、EPG、子网等)的租户模型282，表示网络环境100中的一个或多个资源(例如，存储、计算、VM、端口信道、物理元素等)的资源模型284，等等。

通常，L_模型270A可以是LR_模型270B中存在的内容的高级表达，其应当在具体设备上被呈现为Ci_模型274和Hi_模型276表达。如果模型之间存在任何间隙，则可能存在不一致的配置或问题。

图3A示出了用于网络保证的示例保证设备系统300的图。在该示例中，保证设备系统300可以包括以集群模式操作的k个资源110(例如，VM)。资源110可以指VM、软件容器、裸金属设备、端点122或任何其他物理或逻辑系统或组件。应该注意，虽然图3A示出了集群模式配置，但是本文还预期其他配置，例如单模式配置(例如，单个VM、容器或服务器)或服务链。

保证设备系统300可以在一个或多个服务器106、资源110、管理程序108、EP 122、叶节点104、控制器116或任何其他系统或资源上运行。例如，保证设备系统300可以是在网络环境100中的一个或多个资源110上运行的逻辑服务或应用。

保证设备系统300可以包括数据框架308(例如，APACHE APEX、HADOOP、HDFS、ZOOKEEPER等)。在某些情况下，保证检查可以被编写为驻留在数据框架308中的各个操作符或者由驻留在数据框架308中的各个操作符提供。这实现本地水平扩展架构，其能够扩展到结构120(例如，ACI结构)中的任意数量的交换机。

保证设备系统300可以以可配置的周期(例如，时期)轮询结构120。在一些示例中，分析工作流可以被设置为操作符310的DAG(有向无环图)，其中数据从一个操作符流向另一个操作符，并且最终生成结果并且针对每个间隔(例如，每个时期)将结果永久保存到数据库302。

北层实现API服务器(例如，APACHE TOMCAT、SPRING框架等)304和Web服务器306。图形用户界面(GUI)经由暴露给消费者的API进行交互。消费者还可以使用这些API来从保证设备系统300收集数据，以便进一步集成到其他工具中。

数据框架308中的操作符310可以一起支持保证操作。以下是保证设备系统300可以通过操作符310执行的保证操作的非限制性示例。

安全策略遵守

保证设备系统300可以检查以确认来自可以反映用户对网络的意图的L_模型270A的配置或规范(包括例如安全策略和客户配置的契约)被正确地实现和/或呈现在Li_模型272、Ci_模型274和Hi_模型276中，并且因此由结构成员(例如，叶节点104)适当地实现和呈现，并且报告发现的任何错误、契约违反或不规则。

静态策略分析

保证设备系统300可以检查一个或多个用户意图的规范中的问题(例如，识别L_模型270A中的矛盾或冲突的策略)。保证设备系统300可以基于网络的意图规范来识别线头(lint)事件。线头和策略分析可以包括对网络的(一个或多个)意图规范的语义和/或语法检查。

TCAM利用率

TCAM是结构(例如，结构120)中的稀缺资源。然而，保证设备系统300可以通过网络数据(例如，最长前缀匹配(LPM)表、路由表、VLAN表、BGP更新等)、契约、逻辑组118(例如，EPG)、租户、脊节点102、叶节点104和网络环境100中的其他维度和/或MIM 200中的对象来分析TCAM利用率，以向网络运营商或用户提供对该稀缺资源的利用率的可见性。这对规划和其他优化目的有很大帮助。

端点检查

保证设备系统300可以验证结构(例如，结构120)在所注册的端点信息中没有不一致(例如，两个叶节点宣告相同的端点、重复的子网等)，以及其他这样的检查。

租户路由检查

保证设备系统300可以验证BD、VRF、子网(内部和外部两者)、VLAN、契约、过滤器、应用、EPG等被正确地编程。

基础设施路由

保证设备系统300可以验证基础设施路由(例如，IS-IS协议)没有导致黑洞、环路、振荡(flap)的收敛问题和其他问题。

MP-BGP路由反射检查

网络结构(例如，结构120)可以与其他外部网络接口，并通过一个或多个协议(例如，边界网关协议(BGP)、开放式最短路径优先(OSPF)等)提供到它们的连接。通过例如MP-BGP在网络结构内通告已知的路由。这些检查可以保证通过例如MP-BGP(例如，来自边界叶节点)的路由反射服务不具有健康问题。

逻辑线头和实时变化分析

保证设备系统300可以验证网络的规范(例如，L_模型270A)中的规则是完整的并且没有不一致或其他问题。可以由保证设备系统300通过在L_模型270A和/或MIM 200中的MO的相关联的配置上执行的语法和语义检查来检查MIM 200中的MO。保证设备系统300还可以验证不必要的、陈旧的、未使用的或冗余的配置(例如契约)被删除。

图3B示出了用于网络保证的示例系统350(例如保证设备系统300)的架构图。在一些情况下，系统350可以对应于先前关于图3A所讨论的操作符310的DAG。

在该示例中，拓扑探测器312与控制器116(例如，APIC控制器)通信，以便发现或以其他方式构建结构120的综合拓扑视图(例如，脊节点102、叶节点104、控制器116、端点122，和任何其他组件及其互连)。虽然各种架构组件以单个盒装方式表示，但是应理解，给定的架构组件(例如，拓扑探测器312)可以对应于一个或多个单独的操作符310，并且可以包括一个或多个节点或端点，例如一个或多个服务器、VM、容器、应用、服务功能(例如，服务链中的功能或虚拟化网络功能)等。

拓扑探测器312被配置为发现结构120中的节点，例如，控制器116、叶节点104、脊节点102等。拓扑探测器312还可以检测在控制器116之间执行的多数选举，并确定控制器116之间是否存在法定数量。如果不存在法定数量或多数，则拓扑探测器312可以触发事件并警告用户控制器116之间存在配置或其他错误，其阻止达到法定人数或多数。拓扑探测器312可以检测作为结构120的一部分的叶节点104和脊节点102，并将其相应的带外管理网络地址(例如，IP地址)发布到下游服务。这可以是在拓扑探测器312发现时期(例如，5分钟或某个其他指定间隔)结束时发布到下游服务的拓扑视图的一部分。

在一些示例中，拓扑探测器312可以接收与网络/结构(例如，结构120)相关联的控制器116(例如，APIC控制器)的列表作为输入。拓扑探测器312还可以接收相应的证书以登录到每个控制器。拓扑探测器312可以使用例如REST调用从每个控制器取回信息。拓扑探测器312可以从每个控制器获得控制器知道的节点列表(例如，叶节点104和脊节点102)及其相关联的属性。拓扑探测器312可以从控制器116获得节点信息，包括但不限于，IP地址、节点标识符、节点名称、节点域、节点URI、node_dm、节点角色、节点版本等。

拓扑探测器312还可以确定控制器116是否处于法定数量，或者它们之间是否充分地以通信方式耦合。例如，如果存在n个控制器，则当(n/2+1)个控制器知道彼此和/或以通信方式耦合时，可以满足法定数量条件。拓扑探测器312可以通过解析从控制器返回的数据并识别其组成节点之间的通信耦合来确定法定数量(或识别任何故障节点或控制器)。拓扑探测器312可以识别网络中每个节点的类型，例如，脊节点、叶节点、APIC等，并将该信息包括在所生成的拓扑信息中(例如，拓扑图或模型)。

如果不存在法定数量，则拓扑探测器312可以触发事件并警告用户需要重新配置或适当注意。如果存在法定数量，则拓扑探测器312可以将网络拓扑信息编译为JSON对象，并将其向下游传递给其他操作器或服务，例如统一收集器314。

统一收集器314可以从拓扑探测器312接收拓扑视图或模型，并使用拓扑信息以从结构120收集用于网络保证的信息。统一收集器314可以轮询结构120中的节点(例如，控制器116、叶节点104、脊节点102等)以从节点收集信息。

统一收集器314可以包括一个或多个收集器(例如，收集器设备、操作器、应用、VM等)，其被配置为从拓扑探测器312和/或结构120中的节点收集信息。例如，统一收集器314可以包括收集器集群，并且可以将每个收集器分配给拓扑模型和/或结构120内的节点子集，以便从其分配的节点子集收集信息。为了提高性能，统一收集器314可以以并行、多线程方式运行。

统一收集器314可以跨各个收集器执行负载平衡，以提高整个收集过程的效率。可以通过管理节点子集到收集器的分布来优化负载平衡，例如通过随机散列节点到收集器。

在一些情况下，保证设备系统300可以运行统一收集器314的多个实例。这还可以允许保证设备系统300通过分片和/或负载平衡来分配针对拓扑(例如，包括脊节点102、叶节点104、控制器116等的结构120)中的每个节点收集数据的任务，以及将收集任务和/或节点映射到统一收集器314的特定实例，其中跨越节点的数据收集由统一收集器314的各个实例并行执行。在给定节点内，可以串行执行命令和数据收集。保证设备系统300可以控制统一收集器314的每个实例用于从结构120轮询数据的线程的数量。

统一收集器314可以收集来自控制器116的模型(例如，L_模型270A和/或LR_模型270B)，来自结构120中的节点(例如，叶节点104和/或脊节点102)的交换机软件配置和模型(例如，Ci_模型274)，来自结构120中的节点(例如，叶节点104和/或脊节点102)的硬件配置和模型(例如，Hi_模型276)等。统一收集器314可以收集来自各个节点或结构成员(例如，叶节点104和脊节点102)的Ci_模型274和Hi_模型276，以及来自网络环境100中的一个或多个控制器(例如，控制器116)的L_模型270A和/或LR_模型270B。

统一收集器314可以轮询拓扑探测器312发现的设备，以便从结构120(例如，从结构的组成成员)收集数据。统一收集器314可以使用由控制器116和/或交换机软件(例如，交换机OS)暴露的接口(包括例如表示状态转移(REST)接口和安全外壳(SSH)接口)来收集数据。

在一些情况下，统一收集器314经由REST API收集L_模型270A、LR_模型270B和/或Ci_模型274，并且经由SSH，使用交换机软件所提供的实用程序(例如，用于访问交换机命令行接口(CLI)的虚拟壳(VSH或VSHELL)或用于访问线卡的运行时状态的VSH_LC壳)收集硬件信息(例如，配置、表、结构卡信息、规则、路由等)。

统一收集器314可以轮询来自控制器116的其他信息，包括但不限于：拓扑信息、租户转发/路由信息、租户安全策略、契约、接口策略、物理域或VMM域信息、结构中节点的OOB(带外)管理IP等。

统一收集器314还可以轮询来自结构120中的节点(例如，叶节点104和脊节点102)的信息，包括但不限于：用于VLAN、BD和安全策略的Ci_模型274；节点(例如，叶节点104和/或脊节点102)的链路层发现协议(LLDP)连接性信息；来自EPM/COOP的端点信息；来自脊节点102的结构卡信息；来自结构120中的节点的路由信息库(RIB)表；来自结构120中的节点的转发信息库(FIB)表；来自结构120中的节点的安全组硬件表(例如，TCAM表)；等等。

在一些情况下，统一收集器314可以从网络获得运行时状态并且将运行时状态信息合并到L_模型270A和/或LR_模型270B中。统一收集器314还可以从控制器116获得多个逻辑模型，并基于逻辑模型生成综合或网络范围的逻辑模型(例如，L_模型270A和/或LR_模型270B)。统一收集器314可以比较来自控制器116的逻辑模型，解决依赖性，移除冗余等，并为整个网络或结构生成单个L_模型270A和/或LR_模型270B。

统一收集器314可以跨控制器116和结构节点或成员(例如，叶节点104和/或脊节点102)收集整个网络状态。例如，统一收集器314可以使用REST接口和SSH接口来收集网络状态。统一收集器314收集的该信息可以包括与链路层、VLAN、BD、VRF、安全策略等有关的数据。状态信息可以在LR_模型270B中表示，如前所述。然后，统一收集器314可以将收集的信息和模型发布给对此类信息感兴趣或需要此类信息的任何下游操作器。统一收集器314可以在接收到信息时发布信息，使得数据被流送到下游操作器。

统一收集器314所收集的数据可以被压缩并发送到下游服务。在一些示例中，统一收集器314可以以在线方式或实时方式收集数据，并在收集数据时向下游发送数据以供进一步分析。在一些示例中，统一收集器314可以以离线方式收集数据，并且编译数据以供稍后分析或传输。

保证设备系统300可以联系控制器116、脊节点102、叶节点104和其他节点以收集各种类型的数据。在一些场景中，保证设备系统300可能经历故障(例如，连接问题、硬件或软件错误等)，这使其无法在一段时间内收集数据。保证设备系统300可以无缝地处理这种故障，并基于这样的故障生成事件。

交换机逻辑策略生成器316可以从统一收集器314接收L_模型270A和/或LR_模型270B，并且为结构120中的每个网络设备i(例如，交换机i)计算Li_模型272。例如，交换机逻辑策略生成器316可以接收L_模型270A和/或LR_模型270B并通过为结构120中的每个单独节点i(例如，脊节点102和/或叶节点104)投射逻辑模型来生成Li_模型272。交换机逻辑策略生成器316可以为结构120中的每个交换机生成Li_模型272，从而为每个交换机创建基于L_模型270A和/或LR_模型270B的交换机逻辑模型。

每个Li_模型272可以表示在结构120中的相应网络设备i(例如，交换机i)处投射或应用的L_模型270A和/或LR_模型270B。在一些情况下，Li_模型272可以以与相应网络设备兼容的方式标准化或格式化。例如，Li_模型272可以以可由相应网络设备读取或执行的方式格式化。为了说明，Li_模型272可以包括可由相应网络设备解释的特定标识符(例如，控制器116用作分类符的硬件平面标识符等)或标签(例如，策略组标签)。在某些情况下，Li_模型272可以包括JSON对象。例如，Li_模型272可以包括JSON对象来表示规则、过滤器、条目、范围等。

用于Li_模型272的格式可以与Ci_模型274的格式相同或一致。例如，Li_模型272和Ci_模型274两者都可以基于JSON对象。类似或匹配的格式可以使Li_模型272和Ci_模型274能够进行等效性或一致性的比较。这种等效性检查可以有助于网络分析和保证，如本文进一步解释的。

交换机逻辑配置生成器316还可以执行变化分析并生成针对在L_模型270A和/或LR_模型270B中发现的问题的线头事件或记录。线头事件或记录可用于为用户或网络运营商生成警报。

策略操作器318可以针对每个交换机从统一收集器314接收Ci_模型274和Hi_模型276，并且针对每个交换机从交换机逻辑策略生成器316接收Li_模型272，并且基于Ci_模型274、Hi_模型276和Li_模型272执行保证检查和分析(例如，安全性遵守检查、TCAM利用率分析等)。策略操作器318可以通过比较模型中的一个或多个来逐个交换机地执行保证检查。

返回到统一收集器314，统一收集器314还可以将L_模型270A和/或LR_模型270B发送到路由策略解析器320，并且将Ci_模型274和Hi_模型276发送到路由解析器326。

路由策略解析器320可以接收L_模型270A和/或LR_模型270B并且解析(一个或多个)模型以获得可能与下游操作器(例如，端点检查器322和租户路由检查器324)相关的信息。类似地，路由解析器326可以接收Ci_模型274和Hi_模型276并解析每个模型以获得下游操作器(端点检查器322和租户路由检查器324)的信息。

在解析Ci_模型274、Hi_模型276、L_模型270A和/或LR_模型270B之后，路由策略解析器320和/或路由解析器326可以将清理的协议缓冲区(Proto Buff)发送到下游操作器(端点检查器322和租户路由检查器324)。然后，端点检查器322可以生成与端点违规相关的事件，例如重复的IP、APIPA等，并且租户路由检查器324可以生成与BD、VRF、子网、路由表前缀等的部署相关的事件。

图4示出了用于基于网络(例如，网络环境100)的逻辑模型270来构建特定于节点的逻辑网络(例如，Li_模型272)的示例图400。逻辑模型270可以包括L_模型270A和/或LR_模型270B，如图2D所示。逻辑模型270可以包括要被推送到结构120中的设备(例如，叶节点104)的网络的对象和配置。逻辑模型270可以提供网络的网络范围表示。因此，逻辑模型270可用于为结构120中的节点(例如，叶节点104)构建特定于节点的逻辑模型(例如，Li_模型272)。

逻辑模型270可以适用于每个节点(例如，叶节点104)，以便为每个节点生成相应的逻辑模型，其表示和/或对应于来自逻辑模型270的与节点相关的(一个或多个)部分和/或信息，和/或来自逻辑模型270的应被和/或被推送、存储和/或呈现在节点处的(一个或多个)部分和/或信息。每个特定于节点的逻辑模型，Li_模型272，可以包含来自逻辑模型270的那些与特定节点有关的对象、属性、配置、数据等，包括当逻辑模型270所指定的网络范围的意图被传播或投射到单独的节点时，在特定节点上投射或呈现的来自逻辑模型270的任何(一个或多个)部分。换句话说，为了执行逻辑模型270中所指定的意图，各个节点(例如，叶节点104)可以实现逻辑模型270的各个部分，使得各个节点一起可以执行逻辑模型270中所指定的意图。

图5A示出了用于网络(例如，网络环境100)中的策略分析的示例系统的示意图。策略分析器504可以执行保证检查以检测配置违规、逻辑线头事件、矛盾或冲突的策略、未使用的契约、不完整的配置、路由检查、呈现错误、不正确的规则等。策略分析器504可以检查L_模型270A(或如图4中所示的逻辑模型270)中的用户的(一个或多个)意图的规范，以确定控制器116中的任何配置是否与用户的(一个或多个)意图的规范不一致。

策略分析器504可以包括在保证设备系统300中执行或托管的一个或多个操作符310。然而，在其他配置中，策略分析器504可以运行与操作符310和/或保证设备系统300分开的一个或多个操作符或引擎。例如，策略分析器504可以通过VM、软件容器、VM或软件容器的集群、端点、端点集合、服务功能链等来实现，其中任何一个都可以与保证设备系统300分开。

策略分析器504可以接收逻辑模型集合502作为输入，逻辑模型集合502可以包括如图4所示的逻辑模型270；和/或如图2D所示的L_模型270A、LR_模型270B和/或Li_模型272。策略分析器504还可以接收规则508作为输入。规则508可以被定义，例如，按照来自逻辑模型集合502的一个或多个逻辑模型中的每个特征(例如，每个对象、每个对象属性、每个契约、每个规则等)。规则508可以基于MIM 200中的对象、关系、定义、配置和任何其他特征。规则508可以指定条件、关系、参数和/或用于识别配置违规或问题的任何其他信息。

规则508可以包括用于识别语法违规或问题的信息。例如，规则508可以包括用于执行语法检查的一个或多个语句和/或条件。语法检查可以验证逻辑模型和/或逻辑模型集合502的配置是完整的，并且可以帮助从逻辑模型和/或逻辑模型集合502中识别未被使用的配置或规则。语法检查还可以验证分层MIM 200中的配置已在逻辑模型集合502中正确或完整地定义，并识别已定义但未使用的任何配置。为了说明，规则508可以指定逻辑模型集合502中定义的每个租户应该配置上下文；逻辑模型集合502中的每个契约应指定提供者EPG和消费者EPG；逻辑模型集合502中的每个契约应指定主体、过滤器和/或端口；等等。

规则508还可以包括用于执行语义检查和识别语义违规的信息。语义检查可以检查冲突的规则或配置。例如，规则1和规则2可能重叠并产生别名问题，规则1可能比规则2更具体并导致冲突，规则1可能基于相应的优先级屏蔽规则2或者无意中否决规则2等等。因此，规则508可以定义可能导致别名规则、冲突规则等的条件。为了说明，规则508可以指示如果用于两个对象之间的特定通信的允许策略具有比用于两个对象之间的同一通信的拒绝策略更高的优先级，则允许策略可能与拒绝策略相冲突。规则508可以指示用于对象的规则由于别名和/或优先级而使得另一个规则变得不必要。作为另一示例，规则508可以指示契约中的QoS策略与存储在节点上的QoS规则相冲突。

策略分析器504可以将规则508应用于逻辑模型集合502以检查逻辑模型集合502中的配置并基于检测到的任何问题来输出配置违规事件506(例如，警报、日志、通知等)。配置违规事件506可以包括语义或语义问题，例如，不完整的配置、冲突的配置、别名规则、未使用的配置、错误、策略违规、误配置的对象、不完整的配置、不正确的契约范围、不适当的对象关系等。

在一些情况下，策略分析器504可以迭代地遍历基于逻辑模型集合502和/或MIM200生成的树中的每个节点，并且在树中的每个节点处应用规则508以确定是否有任何节点产生违规(例如，不完整的配置、不适当的配置、未使用的配置等)。策略分析器504可在其检测到任何违规时输出配置违规事件506。

图5B示出了网络模型的示例等效图510。在该示例中，可以将逻辑模型270与从结构120中的一个或多个叶节点104获得的Hi_模型276进行比较。该比较可以提供等效性检查，以便确定(一个或多个)控制器116处的网络环境100的逻辑配置与在一个或多个叶节点104上呈现的规则(例如，存储设备(例如，TCAM)中的规则和/或配置)一致还是冲突。出于解释的目的，逻辑模型270和Hi_模型276被示出为在图5B中的等效性检查示例中比较的模型。然而，应该注意，在其他示例中，可以检查其他模型以对那些模型执行等效性检查。例如，等效性检查可以将逻辑模型270与Ci_模型274和/或Hi_模型276，将Li_模型272与Ci_模型274和/或Hi_模型276，将Ci_模型274与Hi_模型276等进行比较。

等效性检查可以识别网络运营商的配置意图是否与网络的实际行为一致，以及在网络中的模型和/或设备之间传播的信息是一致、冲突还是包含错误等。例如，网络运营商可以从(一个或多个)控制器116定义用于网络环境100的对象和配置。(一个或多个)控制器116可以存储来自网络运营商的定义和配置，并构建网络环境100的逻辑模型(例如，L_模型270A)。(一个或多个)控制器116可以将网络运营商所提供的并且在逻辑模型中反映的定义和配置推送到结构120中的每个节点(例如，叶节点104)。在一些情况下，(一个或多个)控制器116可以推送逻辑模型的特定于节点的版本(例如，Li_模型272)，其反映网络的逻辑模型(例如，L_模型270A)中与该节点有关的信息。

结构120中的节点可以接收这样的信息并在节点的软件(例如，操作系统)上呈现或编译规则。在节点软件上呈现或编译的规则/配置可以被构建成构建模型(例如，Ci_模型274)。然后可以将来自构建模型的规则从节点的软件推送到节点的硬件(例如，TCAM)，并在节点的硬件上存储或呈现为规则。在节点的硬件上存储或呈现的规则可以被构建成用于节点的硬件模型(例如，Hi_模型276)。

随着网络运营商所输入的定义和配置被推送通过每个阶段，各种模型(例如，逻辑模型270和Hi_模型276)因此可以表示每个阶段(例如，(一个或多个)控制器116处的意图规范，在节点的软件上呈现或编译，在节点的硬件上呈现或存储等)的规则和配置。因此，可以使用对诸如逻辑模型270与Hi_模型276，Li_模型272与Ci_模型274或Hi_模型276，Ci_模型274与Hi_模型276等之类的各种模型的等效性检查来确定定义和配置是否在与各种模型相关联的任何阶段已被适当地推送、呈现和/或存储。

如果模型通过等效性检查，则所检查阶段(例如，(一个或多个)控制器116、节点上的软件、节点上的硬件等)的定义和配置可以被验证为准确和一致的。相反，如果等效性检查中存在错误，则可以在一个或多个特定阶段检测到误配置。各种模型之间的等效性检查也可以用于确定问题或误配置发生在哪(例如，在哪个阶段)。例如，可以基于哪个(或哪些)模型未通过等效性检查来确定发生问题或误配置的阶段。

逻辑模型270和Hi_模型276可以在相应的结构512A、512B中存储或呈现规则、配置、属性、定义等。例如，逻辑模型270可以在数据结构512A(例如，文件或对象(例如，JSON、XML等))中存储或呈现规则、配置、对象、属性等，并且Hi_模型276可以在存储设备512B(例如TCAM存储器)中存储或者呈现规则、配置等。与逻辑模型270和Hi_模型276相关联的结构512A、512B可以影响所存储或所呈现的数据(例如，规则、配置、属性、定义等)的格式、组织、类型等。

例如，逻辑模型270可以将数据存储为对象和对象属性514A，例如，EPG、契约、过滤器、租户、上下文、BD、网络范围参数等。Hi_模型276可以将数据存储为值和表514B，例如，值/掩码对、范围表达式、辅助表等。

因此，逻辑模型270和Hi_模型276中的数据可以被标准化、正则化(canonize)、图示化、建模化、重新格式化、扁平化等，以执行逻辑模型270和Hi_模型276之间的等效性。例如，可以使用位向量、布尔函数、ROBDD等来转换数据，以执行逻辑模型270和Hi_模型276之间的等效性的数学检查。

图5C示出了用于执行输入模型的等效性检查的示例架构520。不是使用蛮力来确定输入模型的等效性，而是可以将网络模型表示为特定数据结构，例如，简化有序二元决策图(ROBDD)和/或位向量。在此示例中，输入模型被表示为ROBDD，其中每个ROBDD对输入规则及其优先级排序是正则的(唯一的)。

首先将每个网络模型转换为经优先级排序的规则的扁平列表。在一些示例中，契约可以特定于EPG并且因此定义EPG之间的通信，并且规则可以是这种契约的特定节点到节点的实现。架构520包括形式分析引擎522。在一些情况下，形式分析引擎522可以是策略分析器504和/或保证设备系统300的一部分。例如，形式分析引擎522可以在策略分析器504和/或保证设备系统300内托管或由其执行。为了说明，形式分析引擎522可以通过策略分析器504和/或保证设备系统300上的一个或多个操作符、VM、容器、服务器、应用、服务功能等来实现。在其他情况下，形式分析引擎522可以与策略分析器504和/或保证设备系统300分开。例如，形式分析引擎522可以是独立引擎、托管在多个系统或网络上的引擎集群、托管在一个或多个系统或网络上的服务功能链、VM、软件容器、VM或软件容器的集群、基于云的服务等。

形式分析引擎522包括ROBDD生成器526。ROBDD生成器526接收输入524，其包括用于如图2D所示的模型272、274、276的经优先级排序的规则的扁平列表。这些规则可以表示为布尔函数，其中每个规则包括动作(例如，允许(Permit)、允许_日志(Permit_Log)、拒绝(Deny)、拒绝_日志(Deny_Log))和将触发该动作的条件集合(例如，一个或多个流量配置，例如分组源、目的地、端口、报头、QoS策略、优先级标记等)。例如，规则可以设计为允许端口80上的所有流量。在一些示例中，每个规则可以是具有m个键值对字段的n位字符串。例如，每个规则可能是147位字符串，其中包含13个键值对字段。

作为简化示例，考虑Li_模型272中的经优先级排序的规则L1、L2、L3和L4的扁平列表，其中L1是最高优先级规则，并且L4是最低优先级规则。首先根据规则L1检查给定分组。如果L1被触发，则根据规则L1中包含的动作处理该分组。否则，然后根据规则L2检查分组。如果L2被触发，则根据规则L2中包含的动作处理分组。否则，然后根据规则L3检查分组，依此类推，直到分组触发规则或到达规则列表的末尾。

ROBDD生成器526可以计算一个或多个模型的组成规则L1-L4的一个或多个ROBDD。可以为由规则L1-L4编码的每个动作，或者可以由规则L1-L4编码的每个动作生成ROBDD，使得动作的数量与所生成的ROBDD的数量之间存在一对一的对应关系。例如，规则L1-L4可用于生成L_允许_BDD、L_允许_日志_BDD、L_拒绝_BDD和L_拒绝_日志_BDD。

通常，ROBDD生成器526以所接收的规则列表中的输入524的最高优先级规则开始其计算。继续Li_模型272中的规则L1-L4的示例，ROBDD生成器526以规则L1开始。基于规则L1所指定的动作(例如，允许、允许_日志、拒绝、拒绝_日志)，将规则L1添加到该动作的相应ROBDD。接下来，规则L2将被添加到它指定的动作的相应ROBDD。在一些示例中，可以使用由L1'L2给出的简化形式的L2，其中L1'表示L1的逆。然后对规则L3和L4重复该过程，规则L3和L4分别具有由(L1+L2)'L3和(L1+L2+L3)'L4给出的简化形式。

值得注意的是，L_允许_BDD和每个其他特定于动作的ROBDD对每个组成规则L1、L2、L3、L4尚未被更高优先级规则捕获的部分进行编码。也就是说，L1'L2表示规则L2的不与规则L1重叠的部分，(L1+L2)'L3表示规则L3的不与规则L1或L2重叠的部分，以及(L1+L2+L3)'L4表示规则L4的不与规则L1或L2或L3重叠的部分。该简化形式可以独立于重叠或更高优先级规则所指定的动作，并且可以基于将导致更高优先级规则触发的条件来计算。

ROBDD生成器526同样可以为与输入524相关联的剩余模型(例如在该示例中的Ci_模型274和Hi_模型276)或者由ROBDD生成器526接收的任何其他模型的每个相关联的动作生成ROBDD。根据生成的ROBDD，可以通过等效性检查器528检查任何两个或更多个模型的ROBDD的形式等效性，其建立对输入ROBDD之间的冲突区域进行编码的冲突ROBDD。

在一些示例中，被比较的ROBDD将与相同的动作相关联。例如，等效性检查器528可以通过计算L_允许_BDD和H_允许_BDD之间的排他性析取(disjuction)来检查L_允许_BDD与H_允许_BDD的形式等效性。更具体地，计算(即，L_允许_BDD XOR H_允许_BDD)，但是应理解，以下描述也适用于其他网络模型(例如，逻辑模型270、L_模型270A、LR_模型270B、Li_模型272、Ci_模型274、Hi_模型276等)和相关联的动作(允许、允许_日志、拒绝、拒绝_日志等)。

图6A中示出了示例计算，其描绘了针对L_允许_BDD和H_允许_BDD计算的允许冲突ROBDD 600a的简化表示。如图所示，L_允许_BDD包括唯一部分602(阴影)和重叠604(无阴影)。类似地，H_允许_BDD包括唯一部分606(阴影)和相同的重叠604。

允许冲突ROBDD 600a包括唯一部分602，其表示包含在L_允许_BDD内但不包含在H_允许_BDD内(即，计算为L_允许_BDD*H_允许_BDD')的分组配置和网络动作的集合，以及唯一部分606，其表示包含在H_允许_BDD内但不包含在L_允许_BDD内(即，计算为L_允许_BDD'*H_允许_BDD)的分组配置和网络动作的集合。注意，无阴影的重叠604不是允许冲突ROBDD 600a的一部分。

概念上，示出L_允许_BDD的整圆(例如，唯一部分602和重叠604)表示包含在由输入模型Li_模型272编码的允许规则内或触发允许规则的分组配置的完全枚举集合。例如，假设Li_模型272包含以下规则：

L1：端口＝[l-3]允许

L2：端口＝4允许

L3：端口＝[6-8]允许

L4：端口＝9拒绝

其中'端口'表示接收分组的端口号，然后示出L_允许_BDD的圆包含具有所允许的端口＝[l-3]、4、[6-8]的所有分组的集合。此整圆之外的一切都表示与由包含在Li_模型272中的允许规则所指定的那些不同的分组条件和/或动作的空间。例如，规则L4编码端口＝9拒绝，并且将落在由L_允许_BDD划分出的区域之外。

类似地，示出H_允许_BDD的整圆(例如，唯一部分606和重叠604)表示包含在由输入模型Hi_模型276编码的允许规则内或触发允许规则的分组配置和网络动作的完全枚举的集合，其包含在硬件中呈现的规则和/或配置。假设Hi_模型276包含以下规则：

H1：端口＝[l-3]允许

H2：端口＝5允许

H3：端口＝[6-8]拒绝

H4：端口＝10拒绝_日志

在L_允许_BDD和H_允许_BDD之间的比较中，只有规则L1和H1是等效的，因为它们在分组条件和动作两者上都匹配。L2和H2不等效，因为即使它们指定相同的动作(允许)，但在不同的端口号(4vs.5)上触发此动作。L3和H3不等效，因为即使它们在相同的端口号(6-8)上触发，但它们触发不同的动作(允许vs.拒绝)。L4和H4不等效，因为它们在不同的端口号(9vs.10)上触发，并且还触发不同的动作(拒绝vs.拒绝_日志)。这样，重叠604仅包含由允许规则L1和H1捕获的分组集合，即，具有被允许的端口＝[1-3]的分组。唯一部分602仅包含由允许规则L2和L3捕获的分组集合，而唯一部分606仅包含由允许规则H2捕获的分组集合。这两个唯一部分对如下冲突进行编码：Li_模型272将触发允许的分组条件以及硬件呈现Hi_模型276将触发允许的分组条件之间的冲突。因此，构成允许冲突ROBDD 600a的是这两个唯一部分602和606。其余规则L4、H3和H4不是允许规则，因此不在L_允许_BDD、H_允许_BDD或允许冲突ROBDD 600a中表示。

通常，任何两个模型之间的特定于动作的重叠包含将触发相同动作的分组集合，无论应用的是第一模型的规则还是第二模型的规则，而这相同两个模型之间的特定于动作的冲突ROBDD包含通过在不同条件下触发、触发不同动作或两者而导致冲突的分组集合。

应该注意，在上面关于图6A描述的示例中，Li_模型272和Hi_模型276用作示例输入模型以用于说明目的，但是可以类似地使用其他模型。例如，在某些情况下，可以基于如图4所示的逻辑模型270和/或如图2D所示的模型270A、270B、272、274、276中的任何模型来计算冲突ROBDD。

此外，为了在上面的讨论中清楚的目的，允许冲突ROBDD 600a将L_允许_BDD和H_允许_BDD描绘为单个实体，而不是说明每个单独规则的效果。因此，图6B和6C通过所描绘的单独规则来呈现允许冲突ROBDD。图6B呈现了在所示的规则列表L1、L2、H1和H2之间取得的允许冲突ROBDD 600b。图6C呈现了将规则H3添加到允许冲突ROBDD 600b的允许冲突ROBDD600c。两个图都保持图6A中引入的相同阴影约定，其中给定冲突ROBDD仅包括所示的阴影区域。

首先转到图6B，示出的是允许冲突ROBDD 600b，其跨越由规则L1和L2组成的第二L_允许_BDD、以及由规则H1和H2组成的第二H_允许_BDD进行计算。如图所示，规则L1和H1是相同的，并且彼此完全重叠-两个规则由重叠612和重叠613组成。重叠612在规则L1和H1之间是共同的，而重叠613在规则L1、H1和L2之间是共同的。出于后续解释的目的，假设规则L1和H1两者都由“端口＝[l-13]允许”定义。

规则L2和H2不相同。规则L2由重叠613、唯一部分614和重叠616组成。规则H2仅由重叠616组成，因为它完全包含在规则L2所包含的区域内。例如，规则L2可能是“端口＝[10-20]允许”，而规则H2可能是“端口＝[15-17]允许”。从概念上讲，这是网络保证检查可能遇到的错误的示例，其中由用户意图指定的Li_模型272规则(例如，L2)被错误地呈现到节点的存储器(例如，交换机TCAM)作为Hi_模型276规则(例如，H2)。特别地，所呈现的Hi_模型276规则H2的范围小于L2中所包含的用户意图所指定的预期范围。例如，如果交换机TCAM用完空间，并且没有足够的空闲条目来容纳Li_模型272规则的完整表示，则可能出现这种情况。

无论原因如何，通过将允许冲突ROBDD 600b构建为 来检测该错误，其中该计算的结果由阴影唯一部分614指示。该唯一部分614表示包含在L_允许_BDD内但不包含在H_允许_BDD内的分组配置和网络动作的集合。特别地，唯一部分614包含在规则L2所包含的区域内但不包含在规则H1和H2所包含的任一区域内，并且具体地包括由“端口＝[14,18-20]允许”定义的集合。

为了理解这是如何确定的，回想一下规则L2由“端口＝[10-20]允许”表示。规则H1划分出由“端口＝[10-13]允许”定义的L2的部分，其表示为重叠613。规则H2划分出由“端口＝[15-17]允许”定义的L2的部分，其表示为重叠616。这仅留下“端口＝[14,18-20]允许”作为L2所包含的区域的非重叠部分，或者换句话说，唯一部分614包括允许冲突ROBDD600b。

图6C示出了允许冲突ROBDD 600c，其与允许冲突ROBDD 600b相同，除了新添加的第三规则H3：端口＝[19-25]允许。规则H3包括重叠部分628，其表示包含在规则H3和L2二者中的条件和动作的集合，并且还包括唯一部分626，其表示仅包含在规则H3中的条件和动作的集合。从概念上讲，这可以表示这样的错误：其中由用户意图指定的Li_模型272规则(例如，L2)被错误地呈现到节点存储器中作为两个Hi_模型276规则(例如，H2和H3)。单个Li_模型272规则被表示为多个Hi_模型276规则没有固有的错误。这里的错误而是在于以下事实：两个相应的Hi_模型276规则不能充分捕获允许规则L2所包含的分组配置集合的全部范围。规则H2与规则L2相比太窄，如上面关于图6B所讨论的，并且规则H3不仅太窄而且不正确地延伸超出规则L2所包含的区域的边界。

如前面的情形，通过将冲突ROBDD 600c构建为 来检测该错误，其中该计算的结果由阴影唯一部分624(其表示包含在L_允许_BDD内但不包含在H_允许_BDD内的分组配置和网络动作的集合)以及阴影唯一部分626(其表示包含在H_允许_BDD内但不包含在L_允许_BDD内的分组配置和网络动作的集合)指示。具体地，唯一部分624仅包含在规则L2内，并且包括由“端口＝[14,18]允许”定义的集合，而唯一部分626仅包含在规则H3内，并且包括由“端口＝[21-25]允许”定义的集合。因此，允许冲突ROBDD 600c包括由“端口＝[14,18,21-25]允许”定义的集合。

上面仅参考允许冲突ROBDD，但是应当理解，冲突ROBDD是针对与给定模型相关联的每个动作生成的。例如，对上述Li_模型272和Hi_模型276的完整分析可能导致如下操作：使用ROBDD生成器526来生成8个ROBDD L_允许_BDD、L_允许_日志_BDD、L_拒绝_BDD和L_拒绝_日志_BDD、H_允许_BDD、H_允许_日志_BDD、H_拒绝_BDD和H_拒绝_日志_BDD，然后使用等效性检查器528来生成允许冲突ROBDD、允许_日志冲突ROBDD、拒绝冲突ROBDD和拒绝_日志冲突ROBDD。

通常，等效性检查器528基于输入网络模型或来自ROBDD生成器526的输入ROBDD生成特定于动作的冲突ROBDD。如图5C所示，等效性检查器528接收输入对(L_BDD，H_BDD)、(L_BDD，C_BDD)、(C_BDD，H_BDD)，但是应理解这些表示是为了清楚的目的，并且可以用任何上面讨论的特定于动作的ROBDD来替换。从这些特定于动作的冲突ROBDD，等效性检查器528可以确定输入之间没有冲突-即，给定的特定于动作的冲突ROBDD是空的。在图6A-6C的示例的上下文中，空的冲突ROBDD将对应于不存在阴影部分。在针对给定的特定于动作的冲突ROBDD进行该确定的情况下，等效性检查器528可以生成对应的特定于动作的“通过(PASS)”指示530，其可以从形式分析引擎522外部传送。

然而，如果等效性检查器528确定输入之间存在冲突，并且给定的特定于动作的冲突ROBDD不为空，则等效性检查器528将不生成通过指示530，并且可以改为发送给定的特定于动作的冲突ROBDD 532到冲突规则识别器534，其识别存在的特定冲突规则。在一些示例中，可以针对被确定为空的每个特定于动作的冲突ROBDD生成特定于动作的“通过”指示530。在一些示例中，可以仅在每个特定于动作的冲突ROBDD被确定为空时生成和/或发送“通过”指示530。

在接收到一个或多个特定于动作的冲突ROBDD的情况下，冲突规则识别器534还可以接收在每个冲突ROBDD 532中表示的经优先级排序的规则的扁平列表作为输入。例如，如果冲突规则识别器534接收对应于 的允许冲突ROBDD，则用于生成L_允许_BDD和H_允许_BDD的经优先级排序的规则Li、Hi的基础扁平列表也被接收作为输入。

冲突规则识别器534然后从每个经优先级排序的规则列表中识别特定冲突规则，并构建冲突规则列表536。为此，冲突规则识别器534遍历给定列表中包含的规则并计算每个给定规则所包含的分组配置和网络动作的集合以及特定于动作的冲突ROBDD所包含的集合之间的交集。例如，假设使用j个规则的列表生成L_允许_BDD。对于每个规则j，冲突规则识别器534计算：

如果此计算等于零，则给定规则L_j不是冲突ROBDD的一部分，因此不是冲突规则。然而，如果该计算不等于零，则给定规则L_j是允许冲突ROBDD的一部分，因此是添加到冲突规则列表536的冲突规则。

例如，在图6C中，允许冲突ROBDD 600c包括阴影部分624和626。从用于生成L_允许_BDD的两个规则L1、L2开始，可以计算：

因此，规则L1不与允许冲突ROBDD 600c重叠，并且因此不是冲突规则。但是，可以计算：

这意味着规则L2确实与允许冲突ROBDD 600c在重叠部分624处重叠，并且因此是冲突规则并且被添加到冲突规则列表536中。

相同形式的计算也可以应用于用于生成H_允许_BDD的规则H1、H2、H3的列表。可以计算：

因此，规则H1不与允许冲突ROBDD 600c重叠，并且因此不是冲突规则。还可以计算：

因此，规则H2不与允许冲突ROBDD 600c重叠，并且因此不是冲突规则。最后，可以计算：

这意味着规则H2与允许冲突ROBDD 600c在重叠部分626处重叠并因此是冲突规则并且可以被添加到冲突规则列表552中。在本示例的上下文中，从允许冲突ROBDD 600c得到的完整的冲突规则列表536是{L2，H3}，因为这些规则中的一个或两个已经被错误地配置或呈现。

在一些示例中，与输入524相关联的模型之一可以被视为参考或标准，这意味着假定包含在该模型内的规则是正确的。这样，冲突规则识别器536仅需要计算给定的特定于动作的冲突ROBDD与来自非参考模型的相关联的特定于动作的规则的集合的交集。例如，Li_模型272可以被视为参考或标准，因为它直接从用于定义L_模型270A、270B的用户输入得到。另一方面，Hi_模型276在被呈现到节点的硬件之前经过若干变换，并因此更可能受到错误的影响。因此，冲突规则识别器534将仅针对Hi_模型276中的每个规则(或每个允许规则)j计算：

这可以显著地减少所需的计算时间。

另外，冲突规则识别器534不需要计算特定于动作的冲突ROBDD与每个规则的整体的交集，而是可以使用每个规则的优先级简化的形式。换句话说，这是其中规则被表示在ROBDD内的形式。例如，规则H2的优先级简化形式是H1'H2，或规则H2的贡献减去规则H1已经捕获的部分。规则H3的优先级简化形式是(H1+H2)'H3，或规则H3的贡献减去规则H1或H2已经捕获的部分。规则H4的优先级简化形式是(H1+H2+H3)'H4，或规则H4的贡献减去规则H1和H2和H3已经捕获的部分。

因此，对于包含在Hi_模型276中的每个规则(或每个允许规则)j，计算替代地被简化为：

虽然与下面的简单计算相比，在上面的等式中引入了额外的项：

但是优先级简化的形式实际上在计算上更高效。对于每个规则j，与非简化形式H_j相比，优先级简化形式(H1+...+H_j-1)'H_j包括更小的分组配置和网络动作的集合，或包括相同大小的集合。针对冲突ROBDD执行交集计算的集合越小，计算越高效。

在一些情况下，冲突规则识别器534可以输出冲突规则列表536(无论是从两个输入模型生成，还是仅从单个非参考输入模型生成)到形式分析引擎522外部的目的地。例如，冲突规则536可以输出给用户或网络运营商，以便更好地理解模型之间发生冲突的具体原因。

在一些示例中，后部注释器538可以设置在冲突规则识别器534和外部输出之间。后部注释器538可以将来自冲突规则列表536的每个给定规则与导致给定规则被生成的特定双亲契约或其他高级意图相关联。通过这种方式，不仅在冲突的特定规则方面向用户解释了形式等效性失败，还在被输入到网络中并最终创建了冲突规则的高级用户动作、配置或意图方面向用户解释了等效性失败。以这种方式，用户可以通过在其源或双亲处调整或以其他方式瞄准冲突规则来更有效地解决冲突规则。

在一些示例中，冲突规则列表536可以在内部维护和/或发送到形式分析引擎522，以便实现进一步的网络保证分析和操作，例如但不限于事件生成、反例生成、QoS保证等。

本公开现在转到图7A和7B，其示出了示例方法。图7A示出了用于一般网络保证的示例方法，并且图7B示出了用于网络中的QoS配置的策略保证的示例方法。通过示例的方式提供了这些方法，因为存在多种方式来执行这些方法。另外，虽然示例方法以特定顺序的块或步骤示出，但是本领域普通技术人员将理解，图7A-B和其中所示的块可以以任何顺序执行，并且可以包括比图示的更少或更多的块。

图7A-B中所示的每个块表示方法中的一个或多个步骤、过程、方法或例程。为了清楚和解释的目的，图7A-B中的块参考如图1A-B、2D、3A、5A和5C所示的网络环境100，保证设备系统300和网络模型270、270A-B、272、274、276，策略分析器504和形式等效性引擎522来描述。

参考图7A，在步骤700，保证设备系统300可以收集数据并获得与网络环境100相关联的模型。模型可以包括如图4所示的逻辑模型270，和/或如图2D所示的模型270A-B、272、274、276中的任何模型。数据可以包括结构数据(例如，拓扑、交换机、接口策略、应用策略等)，网络配置(例如，BD、VRF、L2输出、L3输出、协议配置等)，QoS策略(例如，DSCP、优先级、带宽、排队、传输速率、SLA规则、性能设置等)，安全配置(例如，契约、过滤器等)，应用策略(例如，EPG契约、应用简档设置、应用优先级等)，服务链化配置，路由配置等。收集或获得的信息的其他非限制性示例包括网络数据(例如，RIB/FIB、VLAN、MAC、ISIS、DB、BGP、OSPF、ARP、VPC、LLDP、MTU、网络或流状态、日志、节点信息、路由等)，规则和表(例如，TCAM规则、ECMP表、路由表等)，端点动态(例如，EPM、COOP EP DB等)，统计(例如，TCAM规则命中、接口计数器、带宽、分组、应用使用、资源使用模式、错误率、等待时间、丢包等)。

在步骤702，保证设备系统300可以分析和建模所接收的数据和模型。例如，保证设备系统300可以执行形式建模和分析，其可以涉及确定模型(包括配置、策略等)之间的等效性。保证设备系统300可以分析和/或建模所接收的数据和模型的一些或所有部分。例如，在某些情况下，保证设备系统300可以分析和建模契约、策略、规则和状态数据，但排除所收集或可用的信息的其他部分。

在步骤704，保证设备系统300可以生成一个或多个智能事件。保证设备系统300可以使用深层对象分层来生成智能事件以进行详细分析，例如租户、交换机、VRF、规则、过滤器、路由、前缀、端口、契约、主体等。

在步骤706，保证设备系统300可以可视化智能事件、分析和/或模型。保证设备系统300可以在用户友好的GUI中显示用于分析和调试的问题和警报。

图7B示出了用于网络中的QoS配置的策略保证的示例方法。在一些情况下，图7B中的方法可以与图7A中的方法分开执行，或者附加于图7A中的方法执行。然而，在其他情况下，图7B中的方法可以是图7A中的保证方法的一部分。例如，图7B中的方法可以表示图7A中的方法内的一个或多个步骤，或图7A中的方法的具体应用。为了说明，图7A中的方法可以表示可以分析网络的不同类型的配置或方面的一般保证方法的示例，而图7B中的方法可以表示专门实现用于QoS配置的策略保证的方法的示例。

在步骤720，保证设备系统300可以获得网络(例如，网络环境100)的一个或多个逻辑模型。例如，保证设备系统300可以获得逻辑模型270、L_模型270A、LR_模型270B和/或Li_模型272。在某些情况下，保证设备系统300可以获得单个逻辑模型或逻辑模型的集合(例如图5A中所示的逻辑模型集合502)。保证设备系统300可以从一个或多个系统或节点(例如，一个或多个控制器116)获得一个或多个逻辑模型。在一些情况下，保证设备系统300可以生成逻辑模型或修改收集的逻辑模型。

在步骤722，保证设备系统300可以针对网络中的一个或多个节点(例如，叶节点104)获得相应的硬件模型，例如Hi_模型276。例如，保证设备系统300可以从结构120中的每个节点收集Hi_模型276。保证设备系统300可以从结构120中的每个节点接收、提取或请求Hi_模型276。相应的硬件模型可以包括在相应节点处存储或呈现的配置，如前所述。这样的配置可以基于相应的特定于节点的表示或网络的逻辑模型的呈现，诸如Li_模型272或Ci_模型274。

在步骤724，基于逻辑模型和相应的硬件模型，保证设备系统300可以执行逻辑模型中的规则与相应硬件模型中的规则之间的等效性检查，以确定逻辑模型和相应的硬件模型是否包含配置不一致。例如，保证设备系统300可以通过形式分析引擎522执行逻辑模型和相应硬件模型的形式等效，如先前参考图5C和6A-C所述。

为了说明，可以将逻辑模型和相应的硬件模型转换为按优先级排序的规则的扁平列表。这些规则可以表示为布尔函数，其中每个规则包括动作(例如，Permit(允许)、Permit_Log(允许_日志)、Deny(拒绝)、Deny_Log(拒绝_日志))和将触发该动作的条件的集合(例如，分组源、目的地、端口或端口范围、报头、DSCP值、标记级别等的各种配置)。例如，每个规则可以由位串或向量表示。

规则可以包括逻辑模型和相应的硬件模型中的QoS策略。QoS策略可以在由网络运营商在控制器处指定的契约中定义，并反映在网络的逻辑模型中。QoS策略可用于通知底层网络(例如，结构120)以在具有特定QoS值的指定流量源和目的地之间标记流量。QoS值可以包括标记级别(例如，级别-1、级别-2、级别-3)和目标DSCP(区分服务代码点)值，它们一起可以定义网络中相关联的流量的优先级。一旦在(一个或多个)控制器处被配置，定义QoS策略的契约(以及其他契约)可以被呈现为节点硬件(例如，交换机TCAM硬件)中的规则。

为了执行QoS策略的等效性检查，可以将逻辑模型和相应硬件模型中相关联的规则转换为一个或多个数据结构。在一些情况下，规则可以被转换为布尔函数，该布尔函数表示对应于分组空间(例如，源、目的地、端口值或端口范围等)和动作(例如，允许、拒绝等)的QoS策略(例如，DSCP值、标记级别等)。然后，布尔函数可用于在数学上确定逻辑模型与相应硬件模型中的QoS策略之间的等效性。

在一些情况下，可以提供规则和/或布尔函数作为ROBDD生成器(例如，ROBDD生成器526)的输入。ROBDD生成器可以生成表示规则和/或布尔函数的ROBDD，并执行等效性检查，如先前参考图5C和6A-C所述。ROBDD和等效性检查可用于确定逻辑模型和相应硬件模型中的QoS策略是否匹配或是否包含任何错误或不一致。如果检测到任何不一致，则还可以使用等效性检查来识别可能已创建错误或不一致的位置。例如，等效性检查可用于确定错误或不一致的根本原因是由逻辑模型中的规则还是由特定节点的相应硬件模型中的规则产生的。

在一些示例中，该方法可以在来自逻辑模型的契约中定义的QoS策略与作为节点的硬件上的规则呈现并且被包含在该节点的相应硬件模型中的QoS策略之间执行等效性检查。例如，该方法可以检查逻辑模型中与用于特定分组空间或元组(例如，源、目的地、和端口或端口范围)的动作(例如，允许、拒绝等)有关的(一个或多个)QoS规则，与相应硬件模型中与用于相同分组空间或元组的相同动作有关的(一个或多个)QoS规则之间的等效性。作为等效性检查的一部分，该方法可以检查与分组集合相关联的QoS和标记字段的值(其在节点的硬件(例如，交换机TCAM)中用这样的值标记)，等效于针对该分组集合的逻辑模型中指定(例如，通过控制器116)的QoS和标记字段的值。此等效性检查可以识别逻辑模型中定义的QoS规则与节点硬件上呈现的QoS规则一致还是不一致。

为了说明，假设逻辑模型包含以下规则：

L1：源＝[A]；目的地＝[B]；端口＝[80]；动作＝允许；DSCP＝[11]

L2：源＝[A]；目的地＝[B]；端口＝[10]；动作＝允许；CoS＝[7]

L3：源＝[A]；目的地＝[B]；端口＝[15]；动作＝允许；802.1p优先级＝[7]

另外，假设相应的硬件模型包含以下规则：

H1：源＝[A]；目的地＝[B]；端口＝[80]；动作＝允许；DSCP＝[11]

H2：源＝[A]；目的地＝[B]；端口＝[10]；动作＝允许；CoS＝[7]

H3：源＝[A]；目的地＝[B]；端口＝[15]；动作＝允许；802.1p优先级＝[1]

该方法可以分别在逻辑模型与相应的硬件模型中的L1-L3和H1-H3之间执行等效性检查，以确定任何相关联的QoS策略是否是不等效的。例如，该方法可以创建相应的数据结构，例如用于逻辑模型(例如，策略L1-L3)和硬件模型(例如，H1-H3)的ROBDD，并且使用相应的数据结构来确定模型之间的等效性。可以比较为逻辑模型和硬件模型构建的ROBDD以确定模型之间的整体等效性。

例如，可以为逻辑模型(在该示例中，逻辑模型包含规则L1-L3)以及硬件模型(在该示例中，硬件模型包含规则H1-H3)构建ROBBD。可以基于相应的ROBDD在逻辑模型和硬件模型之间执行等效性检查。因此，逻辑模型和硬件模型之间的等效性检查可以验证逻辑模型和硬件模型中的QoS策略(包括逻辑和硬件模型中的L1-L3和H1-H3中的DSCP、CoS和802.1p优先级值)。

在上面的示例中，逻辑模型和硬件模型之间的等效性检查可以识别由逻辑模型的L3中定义的802.1p优先级值与硬件模型的H3中定义的802.1p优先级之间的不匹配导致的逻辑模型和硬件模型之间的不等效。如上所示，逻辑模型经由L3为具有允许动作并且对应于源A、目的地B和端口15的分组定义了为7的802.1p优先级，而硬件模型经由H3为相同分组(即，具有允许动作并且对应于源A、目的地B和端口15的分组)定义了为1的802.1p优先级。在逻辑和硬件模型下为相同分组定义的802.1p优先级之间的冲突或不匹配可导致逻辑模型和硬件模型之间的不等效发现。如果802.1p优先级值相同，则逻辑模型和硬件模型之间的等效性检查将产生通过，其指示模型之间的整体等效性。

作为另一示例，考虑网络运营商配置这样的契约：其允许端口10-20之间的所有流量并且要求流量以级别1标记和被设置为7的QoS DSCP值启用QoS。该契约在下表中示出。

逻辑模型中的QoS契约

在将该QoS契约部署在网络中的控制器(例如，控制器116)上之后，在节点的硬件(例如，交换机TCAM)中呈现与QoS契约相关联的规则。出于说明目的，此示例将假设节点的硬件是交换机TCAM存储器。

由于TCAM是具有二进制值和有限资源的电路，因此在一些情况下，交换机TCAM可以为契约呈现多个规则。这可能是由于各种问题造成的，例如范围扩展、呈现TCAM规则的软件优化、硬件问题等。例如，在上述示例中，可以在TCAM中为QoS契约呈现以下规则：

在TCAM中呈现的QoS规则

该方法可以检查对于交换机中的所有流量，TCAM中的DSCP和标记值与契约中指定的意图一致。在上面的示例中，该方法可以检查在TCAM中呈现的QoS规则是否等效于来自逻辑模型的经配置的契约中的QoS规则。该QoS保证方法可以独立于任何优化技术或任何其他可能扭曲规则或等效性的因素来实现。如下所示，QoS保证方法将产生等效性失败，因为经配置的契约中的QoS规则不等效于TCAM中呈现的QoS规则，因为它们不产生针对所有相应分组元组的相同DSCP值。

为了执行QoS等效性检查，该方法可以生成数据结构，例如，位向量和/或ROBDD，以表示DSCP和标记字段。例如，该方法可以为DSCP和标记字段生成16位表示并计算针对分组空间的一个或多个数据结构。在计算分组空间时，每个位的值应为1或0。该方法针对TCAM(即相应的硬件模型)中的QoS规则和策略规范(即逻辑模型)中的规则两者计算此分组空间。然后，该方法检查针对逻辑和硬件模型计算出的分组空间是等效的。

因此，继续上面的示例，假设DSCP、标记元组由位向量表示。为了便于解释，以下示例仅讨论DSCP表示，并将假设DSCP由4位向量0xblb2b3b4表示。基于4位向量，DSCP值7被表示为0x0111，并且DSCP值15被表示为0x1111。

关于逻辑模型中的QoS契约，针对4位向量中的每个比特b_i计算分组集合LP0_i和LP1_i，使得对于该分组集合，针对比特b_i的契约指定值分别是0和1。在此示例中，分组对应于元组源、目的地和端口值(src、dst、port value)，并且分组集合对应于元组源、目的地和端口范围(src、dst、port range)。因此，对于此示例中的QoS契约，其DSCP值为被表示为0x0111的7，LP0_i是针对位bl的集合(A，B，10-20)，并且LPl_i是针对比特b2、b3和b4的集合(A，B，10-20)。

关于相应硬件模型中的QoS规则，针对每个比特b_i计算分组集合HP0_i和HP1_i，使得b_i的TCAM值分别为0和1。如前所述，该示例中的TCAM已经根据逻辑模型中的QoS规则呈现了多个规则。这可能导致多个分组集合，以及针对同一分组的多个QoS值。因此，为了计算这些分组集合，考虑TCAM中的规则及它们的优先级顺序。

在上面的示例中，端口值16的DSCP值为15和7，并且端口15的DSCP值为7和15。由于针对端口16具有DSCP值15的规则的优先级高于针对端口16具有DSCP值7的规则，因此端口16将被具有DSCP值15的优先级较高的规则掩蔽。此外，由于针对端口15具有DSCP值7的规则的优先级高于针对端口15具有DSCP值15的规则，因此端口15被具有DSCP值7的优先级较高的规则掩蔽。

因此，对于端口16，比特b0将是1，因为相应硬件模型中的端口16的DSCP值是15，在该示例中被表示为0x1111。相比之下，逻辑模型中端口16的比特b0将为0，因为逻辑模型中端口16的DSCP值为7，其被表示为0x0111。因此，端口16的比特b0在逻辑模型和相应的硬件模型中将具有不同的DSCP值(即，逻辑模型中为0，相应硬件模型中为1)。这导致针对比特b0的等效性失败。因此，等效性检查将识别出逻辑模型中的QoS契约与在TCAM中呈现并被包含在相应硬件模型中的QoS规则之间的不一致。作为响应，该方法可以报告针对比特b0的不等效。该方法还可以将这种不等效报告给网络运营商，作为呈现QoS保证检查失败。

对于端口15，逻辑模型和硬件模型中的DSCP值将匹配，因为TCAM规则中的端口15将被具有DSCP值7(其被表示为0x0111)的优先级较高的规则掩蔽，并且来自逻辑模型的QoS规则中针对端口15的DSCP值也是7并因此也被表示为0x0111。

在一些情况下，分组的数量可能非常大。因此，可以在保证检查中实现诸如ROBDD之类的专用数据结构，以提高性能、处理能力和可伸缩性。例如，ROBDD可用于紧凑地表示分组集合以减少计算负担并提高计算性能。ROBDD还可以保证等效性检查独立于TCAM软件优化。因此，如果交换机的软件呈现规则发生变化，保证方法仍然有效。

为了说明，在上面的示例中为QoS契约和TCAM规则构建的4位向量中的比特可以用于生成ROBDD，以用于等效性检查。例如，ROBDD可以基于为示例QoS契约和TCAM规则构建的每个4位向量中的每个比特来生成。然后可以比较ROBDD以确定等效性，如先前关于图5C和6A到6C所述。

QoS检查失败意味着契约未在交换机上被正确地呈现。这可能由于各种原因而发生。例如，该呈现问题可能是瞬态条件的结果，因为在模型被获得(例如，从控制器116和叶节点104轮询)时契约可能正在被呈现的过程中。为了消除此问题，可以执行滞后服务以检查失败的呈现检查在后续轮询中是否会继续失败。

由于可能存在由控制器116控制的多个交换机，为了分析跨所有交换机的契约的呈现，可以使用聚合逻辑来聚合针对不同交换机的结果。聚合结果可以被发布到数据库并使用GUI显示给网络运营商，或以其他方式报告给网络运营商。

现在，本公开转向图8和图9，其示出了示例网络和计算设备，例如，交换机、路由器、负载平衡器、服务器、客户端计算机等。

图8示出了适用于执行交换、路由、保证和其他联网操作的示例网络设备800。网络设备800包括中央处理单元(CPU)804、接口802和连接810(例如，PCI总线)。当在适当的软件或固件的控制下动作时，CPU 804负责执行分组管理、错误检测和/或路由功能。CPU 804优选地在包括操作系统和任何适当的应用软件的软件的控制下完成所有这些功能。CPU 804可以包括一个或多个处理器808，例如来自INTEL X86系列微处理器的处理器。在一些情况下，处理器808可以是用于控制网络设备800的操作的专门设计的硬件。在一些情况下，存储器806(例如，非易失性RAM、ROM、TCAM等)也形成CPU 804的一部分。然而，有许多不同的方式可以将存储器耦合到系统。在一些情况下，网络设备800可以包括与CPU 804分开的存储器和/或存储硬件，例如TCAM。这样的存储器和/或存储硬件可以通过例如连接810与网络设备800及其组件耦合。

接口802通常作为模块化接口卡(有时被称为“线卡”)提供。通常，它们控制通过网络发送和接收数据分组，并且有时支持与网络设备800一起使用的其他***设备。可以提供的接口包括以太网接口、帧中继接口、电缆接口、DSL接口、令牌环接口等等。此外，可提供各种非常高速的接口，例如，快速令牌环接口、无线接口、以太网接口、千兆以太网接口、ATM接口、HSSI接口、POS接口、FDDI接口、WIFI接口、3G/4G/5G蜂窝接口、CAN总线、LoRA等。通常，这些接口可以包括适合与适当介质通信的端口。在某些情况下，它们还可以包括独立处理器，并且在某些情况下，还包括易失性RAM。独立处理器可以控制诸如分组交换、媒体控制、信号处理、加密处理和管理之类的通信密集型任务。通过为通信密集型任务提供分离的处理器，这些接口允许主微处理器804高效地执行路由计算、网络诊断、安全功能等。

尽管图8中所示的系统是本公开的一个特定网络设备，但它决不是可以在其上实现本文的概念的唯一网络设备架构。例如，可以使用具有处理通信以及路由计算等的单个处理器的架构。此外，其他类型的接口和介质也可以与网络设备800一起使用。

无论网络设备的配置如何，它都可以采用一个或多个存储器或存储器模块(包括存储器806)，其被配置为存储用于本文所描述的漫游、路由优化和路由功能的通用网络操作和机制的程序指令。例如，程序指令可以控制操作系统和/或一个或多个应用的操作。一个或多个存储器还可以被配置为存储诸如移动性绑定、注册和关联表等之类的表。存储器806还可以保存各种软件容器和虚拟化的执行环境和数据。

网络设备800还可以包括专用集成电路(ASIC)，其可以被配置为执行路由、交换和/或其他操作。例如，ASIC可以经由连接810与网络设备800中的其他组件通信，以交换数据和信号并协调网络设备800的各种类型的操作，例如路由、交换和/或数据存储操作。

图9示出了计算系统架构900，其包括使用诸如总线之类的连接905彼此电通信的组件。系统900包括处理单元(CPU或处理器)910和系统连接905，系统连接905将包括系统存储器915在内的各种系统组件(例如，只读存储器(ROM)920和随机存取存储器(RAM)925)耦合到处理器910。系统900可以包括高速存储器的缓存，其与处理器910直接连接、靠近处理器910或者集成作为处理器910的一部分。系统900可以将数据从存储器915和/或存储设备930复制到缓存912用于由处理器910快速访问。以这种方式，缓存可以提供性能提升，避免处理器910在等待数据时的延迟。这些和其他模块可以控制或被配置为控制处理器910以执行各种动作。其他系统存储器915也可以使用。存储器915可以包括具有不同性能特性的多个不同类型的存储器。处理器910可以包括任何通用处理器和被配置为控制处理器910的硬件或软件服务(例如存储在存储设备930中的服务1 932、服务2 934和服务3 936)以及其中软件指令被包含在实际的处理器设计中的专用处理器。处理器910可以是完全自包含的计算系统，包含多个核或处理器、总线、存储器控制器、缓存等。多核处理器可以是对称的或非对称的。

为了实现与计算设备900的用户交互，输入设备945可以表示任何数量的输入机制，诸如用于语音的麦克风、用于手势或图形输入的触敏屏幕、键盘、鼠标、运动输入、讲话等等。输出设备935也可以是本领域技术人员已知的多种输出机制中的一种或多种。在一些情况下，多模式系统可以使用户能够提供多种类型的输入以与计算设备900通信。通信接口940通常可以控制和管理用户输入和系统输出。对任何特定硬件布置进行的操作没有限制，因此这里的基本特征可以很容易地随着改进的硬件或固件布置被开发而被代替为这些改进的硬件或固件布置。

存储设备930是非易失性存储器，并且可以是硬盘或其他类型的计算机可读介质，其可以存储可由计算机访问的数据，例如磁带盒、闪存卡、固态存储器设备、数字通用盘、盒式磁带、随机存取存储器(RAM)925、只读存储器(ROM)920及其混合。

存储设备930可以包括用于控制处理器910的服务932、934、936。可以预期其他硬件或软件模块。存储设备930可以连接到系统连接905。在一个方面，执行特定功能的硬件模块可以包括存储在与必要的硬件组件(例如处理器910、连接905、输出设备935等)相连的计算机可读介质中的软件组件以执行功能。

总之，描述了用于网络中服务质量配置的保证的系统、方法和计算机可读介质。在一些示例中，一种系统获得软件定义网络的逻辑模型，该逻辑模型包括为软件定义网络指定的规则，该逻辑模型基于定义软件定义网络的可管理对象和对象属性的模式。该系统还获得针对软件定义网络中的每个节点的相应硬件模型，该相应硬件模型包括基于逻辑模型的相应特定于节点的表示而在该节点处呈现的规则。基于逻辑模型和相应硬件模型，该系统可以在逻辑模型中的规则与相应硬件模型中的规则之间执行等效性检查，以确定逻辑模型和相应硬件模型是否包括配置不一致。

为了解释的清楚性，在一些实例中，本技术可以被呈现为包括单独的功能块，其包括包含以下项的功能块：设备、设备组件、在软件中实现的方法中的步骤或例程，或者硬件和软件的组合。

在一些实施例中，计算机可读存储设备、介质和存储器可以包括包含比特流等的有线或无线信号。然而，当提到时，非暂时性计算机可读存储介质明确地排除诸如能量、载波信号、电磁波和信号本身之类的介质。

可以使用存储在计算机可读介质中或以其他方式可从计算机可读介质获得的计算机可执行指令来实现根据上述示例的方法。这样的指令可以包括例如引起或以其他方式配置通用计算机、专用计算机或专用处理设备以执行特定功能或功能组的指令和数据。所使用的计算机资源的部分可以通过网络访问。计算机可执行指令可以是例如二进制指令、诸如汇编语言之类的中间格式指令、固件或源代码。可用于存储指令、所使用的信息和/或在根据所描述的示例的方法期间创建的信息的计算机可读介质的示例包括磁盘或光盘、闪存、具有非易失性存储器的USB设备、联网的存储设备等等。

实现根据这些公开内容的方法的设备可以包括硬件、固件和/或软件，并且可以采用各种形状因子中的任何形状因子。这种形状因子的典型示例包括膝上型计算机、智能电话、小型个人计算机、个人数字助理、机架设备、独立设备等。本文描述的功能也可以实现在***设备或附加卡中。作为进一步的示例，这样的功能还可以在不同芯片之间的电路板上实现，或者在单个设备中执行的不同处理中实现。

指令、用于传达这些指令的介质、用于执行它们的计算资源以及用于支持这种计算资源的其他结构是用于提供这些公开内容中描述的功能的手段。

尽管使用各种示例和其他信息来解释所附权利要求范围内的方面，但是不应基于这些示例中的特定特征或布置来暗示对权利要求的限制，因为普通技术人员将能够使用这些示例来推导各种各样的实现。此外，尽管可能已经用特定于结构特征和/或方法步骤的示例的语言描述了一些主题，但是应该理解，所附权利要求中定义的主题不必限于这些描述的特征或动作。例如，这种功能可以在本文标识的那些组件之外的组件中不同地分布或者在本文标识的那些组件之外的组件中执行。而是，所描述的特征和步骤被公开为所附权利要求范围内的系统和方法的组件的示例。

引用“至少一个”的权利要求语言是指集合中的至少一个，并且指示该集合中的一个成员或该集合中的多个成员满足该权利要求。例如，引用“A和B中的至少一个”的权利要求语言意思是A、B或A和B。