CN110612702A - 针对不一致的意图规范检查 - Google Patents

Abstract

用于意图规范检查的系统、方法、和计算机可读介质。在一个示例中，系统从软件定义网络中的一个或多个控制器获得该软件定义网络的逻辑模型，该逻辑模型包括分层管理信息树中的一个或多个对象的配置，该分层管理信息树定义了该软件定义网络的可管理对象和对象属性。基于分层管理信息树，系统对逻辑模型中的配置执行策略分析，并基于策略分析来确定逻辑模型中的配置是否包含一个或多个错误。

Description

针对不一致的意图规范检查

相关申请的交叉引用

本申请要求题为“INTENT SPECIFICATION CHECKS FOR INCONSISTENCIES”的在2017年5月31日提交的美国临时专利申请62/513,059号以及题为“INTENT SPECIFICATIONCHECKS FOR INCONSISTENCIES”的在2017年7月28日提交的美国非临时专利申请15/663,642号的权益和优先权。两个申请的全部内容通过引用而被明确包含在此。

技术领域

本技术涉及网络配置和故障排除，并且更具体地涉及通过检查意图规范的不一致来保证网络配置。

背景技术

计算机网络正变得越来越复杂，经常涉及在网络的各个层的低层以及高层配置。例如，计算机网络通常包括众多接入策略、转发策略、路由策略、安全策略、服务质量(QoS)策略等，它们一起定义了网络的整体行为和操作。网络运营商具有用于根据用户的需要来调整网络的多种配置选项。尽管可用的不同配置选项为网络运营商提供了很大程度的灵活性和对网络的控制，但它们也增加了网络的复杂性。在许多情况下，配置过程可能变得高度复杂。不奇怪，网络配置过程越来越容易出错。此外，对高度复杂的网络中的错误进行故障排除可能极其困难。识别网络中的不希望行为的根本原因的过程可能是艰巨的任务。

附图说明

为了描述可以获得本公开的上述和其他的优点和特征的方式，将通过参考在附图中示出的其特定实施例来对以上简要描述的原理进行更具体的描述。应理解，这些附图仅描绘了本公开的示例性实施例并且因此不应被认为是对其范围的限制，通过使用附图以附加的特征和细节来描述和解释本文中的原理，其中：

图1A和1B示出了示例网络环境；

图2A示出了网络的示例对象模型；

图2B示出了来自图2A的示例对象模型中的租户对象的示例对象模型；

图2C示出了来自图2A的示例对象模型中的各种对象的示例关联；

图2D示出了用于实现来自图2A的示例对象模型的示例模型的示意图；

图3A示出了示例网络保证设备；

图3B示出了用于网络保证的示例系统；

图3C示出了示例静态策略分析器的示意图；

图4示出了意图规范检查的示例场景；

图5A示出了用于网络保证的示例方法；

图5B示出了用于检查网络中的意图规范的示例方法；

图6示出了示例策略分析系统；

图7示出了根据各种实施例的示例计算设备；并且

图8示出了根据各种实施例的示例网络设备。

具体实施方式

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

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

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

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

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

概述

在独立权利要求中陈述了本发明的各方面，并且在从属权利要求中陈述了优选特征。一方面的特征可以单独应用于每个方面或与其他方面结合应用于每个方面。

本文公开了用于检查软件定义网络(SDN)中的意图规范的系统、方法和计算机可读介质。在一些示例中，一种系统或方法可以从SDN网络中的一个或多个控制器获得SDN网络的逻辑模型。逻辑模型可以包括分层管理信息树(MIT)中一个或多个对象的配置，该分层MIT定义了SDN网络的可管理对象和对象属性。在某些情况下，一个或多个控制器可以是以应用为中心的基础设施(ACI)中的应用策略基础设施控制器(APIC)，并且分层MIT可以是ACI管理信息模型(MIM)。因此，可管理对象可以是在ACI MIM中定义的被管理对象(MO)，并且配置是经由一个或多个APIC的用户输入的配置。

该系统或方法可以基于分层MIT对逻辑模型中的配置进行语法验证，以产生语法验证输出。该系统或方法还可以基于为分层MIT中的可管理对象和对象属性定义的一个或多个规则来对逻辑模型中的配置进行语义验证，以产生语义验证输出。基于语法验证输出和语义验证输出，该系统或方法可以确定逻辑模型中的配置是否包含一个或多个错误。

示例实施例

所公开的技术解决了本领域中对检查网络的意图规范和验证意图规范的改变的需求。本技术涉及用于检查网络的意图规范内的不一致的系统、方法和计算机可读介质。将在以下公开中如下描述本技术。讨论从如图1A和1B所示的对网络保证的介绍性讨论和对示例计算环境的描述开始。然后接下来将是对如图2A至2D所示的用于网络保证的网络模型以及如图3A-C和4所示的网络保证系统和方法的讨论。讨论继续进行如图5所示的对用于检测意图规范内的不一致的意图规范检查的描述和示例。讨论以对如图6所示的示例网络设备以及如图7所示的包括适合于托管软件应用和执行计算操作的示例硬件组件的示例计算设备的描述结束。

本公开现在转向对网络保证的介绍性讨论。

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

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

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

可以实施这样的模型以确保网络的行为与通过由网络运营商实施的特定配置(例如，策略、设置、定义等)反映的预期行为将一致(或与之一致)。与涉及发送和分析数据分组并观察网络行为的传统网络监视不同，可以通过建模来执行网络保证，而没有必要摄取分组数据或监视流量或网络行为。这可以产生先见之明、洞察力和后见之明：可以在问题发生之前预防问题，在问题发生时识别问题，并在问题发生之后立即解决问题。

因此，网络保证可以涉及对网络的属性进行建模以确定性地预测网络的行为。如果(一个或多个)模型指示适当的行为(例如，没有不一致、冲突、错误等)，则可以确定网络是健康的。如果建模指示除一些不一致以外的适当行为，则可以确定该网络起作用，但不是完全健康的。如果建模指示不正确的行为和错误，则可以确定网络不起作用并且不是健康的。如果通过建模检测到不一致或错误，则对(一个或多个)对应模型的详细分析可以允许非常准确地识别一个或多个基本问题或根本问题。

建模可以消耗许多类型的智能事件，这些智能事件对网络的大量行为方面进行建模。智能事件可以影响网络的各个方面，诸如底层服务、叠加服务、租户连接性、租户安全性、租户端点(EP)移动性、租户策略、租户路由、资源等。

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

图1A示出了诸如数据中心之类的示例网络环境100的图。网络环境100可以包括结构120，其可以表示网络环境100的物理层或基础设施(例如，底层)。结构120可以包括脊102(例如，脊路由器或交换机)和叶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可以允许VM110共享服务器106上的硬件资源，并且允许服务器106上的硬件资源表现为多个单独的硬件平台。此外，服务器106上的管理程序108可以托管一个或多个VM110。

在某些情况下，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或VMWARE NSX)来配置网络环境100。下面简要描述这些示例SDN解决方案。

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

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

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

现在返回图1A，网络环境100可以经由叶104、服务器106、管理程序108、VM 110、应用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和NSXMANAGERS；裸金属物理主机；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和/或主机OS等)、关联的网络或租户、一个或多个策略、标签等)而分组在一起的端点(物理的和/或逻辑的或虚拟的)的逻辑实体。例如，逻辑组可以是表示分组在一起的端点集合的对象。为了说明，逻辑组1可以包含客户端端点，逻辑组2可以包含web服务器端点，逻辑组3可以包含应用服务器端点，逻辑组N可以包含数据库服务器端点，等等。在某些示例中，逻辑组118是ACI环境中的EPG和/或另一SDN环境中的其他逻辑组(例如，SG)。

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

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

图2A示出了用于诸如网络环境100之类的SDN网络的示例管理信息模型200的图。对管理信息模型200的以下讨论引用了在整个公开中也将使用的各种术语。因此，为清楚起见，本公开将首先在下面提供术语列表，其后将是对管理信息模型200的更详细的讨论。

如本文所使用的，“别名”可以指给定对象的可改变的名称。因此，即使对象的名称一旦被创建就无法被改变，别名也可以是可以被改变的字段。

如本文所使用的，术语“混叠”可以指与一个或多个其他规则重叠的规则(例如，合同、策略、配置等)。例如，如果合同1与合同1重叠，则可以说在网络的逻辑模型中定义的合同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或防火墙规则。在一些示例中，可以在诸如L3协议类型、L4(第4层)端口等之类的分组(例如，TCP/IP)报头字段中实现过滤器，这例如用于允许端点或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。

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

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

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

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

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

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

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

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

控制器116

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

节点204

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

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

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

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

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

节点206

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

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

节点208

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

节点210

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

节点212

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

分层策略模型可以很好地适应API，诸如REST API接口。当被调用时，API可以从MIT中的对象读取或向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耦合。为了使流量流动，例如利用物理、VMM、L2输出、L3输出、或光纤通道域中的VLAN将EPG部署在叶端口上。

接入部分206A因此包含域配置文件236，域配置文件236可以定义例如将与EPG相关联的物理、VMM、L2输出、L3输出或光纤通道域。域配置文件236包含直接与应用EPG相关联的VLAN实例配置文件238(例如，VLAN池)和可附接接入实体配置文件(AEP)240。AEP 240将关联的应用EPG部署到它所附接到的端口，并使指派VLAN的任务自动化。虽然大型数据中心可以具有在数百个VLAN上配设的数千个活动VM，但结构120可以自动从VLAN池指派VLANID。这与在传统数据中心中聚合(trunk down)VLAN相比节省了时间。

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

如图所示，模型可以包括L_Model 270A(逻辑模型)、LR_Model270B(逻辑呈现模型或逻辑运行时模型)、Li_Model 272(i的逻辑模型)、Ci_Model 274(i的具体模型)、和/或Hi_Model 276(i的硬件模型或TCAM模型)。

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

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

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

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

Li_Model 272是从L_Model 270A和/或LR_Model 270B获得的交换机级模型或特定于交换机的模型。Li_Model 272可以投射特定的交换机或设备i上的L_Model 270A和/或LR_Model 270B，并且因此可以传达L_Model 270A和/或LR_Model 270B应当如何在特定的交换机或设备i处出现或被在特定的交换机或设备i处实现。

例如，Li_Model 272可以投射与特定交换机i有关的L_Model 270A和/或LR_Model270B，以捕捉交换机i处的L_Model 270A和/或LR_Model270B的交换机级表示。为了说明，Li_Model 272L₁可以表示投射到叶1(104)或在叶1处实现的L_Model 270A和/或LR_Model270B。因此，可以根据用于结构120上的各个设备(例如，叶104、脊102等)的L_Model 270A和/或LR_Model 270B来生成Li_Model 272。

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

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

在某些情况下，Li_Model 272和Ci_Model 274可以具有相同或类似的格式。例如，Li_Model 272和Ci_Model 274可以基于JSON对象。具有相同或类似的格式可以帮助针对等效性或一致性来比较Li_Model 272和Ci_Model 274中的对象。如本文进一步描述的，这样的等效性或一致性检查可以用于网络分析和保证。

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

尽管将模型272、274、276示出为特定于设备的模型，但是可以针对结构120中的结构成员(例如，叶104和/或脊102)的集合生成或聚合类似的模型。当被组合时，特定于设备的模型(诸如模型272、模型274和/或模型276)可以提供扩展到特定设备之外的结构120的表示。例如，在一些情况下，与一些或所有单独结构成员(例如，叶104和脊102)相关联的Li_Model 272、Ci_Model 274、和/或Hi_Model 276可以被组合或聚合以生成基于单独结构成员的一个或多个聚合模型。

如本文所引用的，术语“H模型”、“T模型”和“TCAM模型”可以可互换地用来指代硬件模型，诸如Hi_Model 276。例如，Ti模型、Hi模型和TCAMi模型可以可互换地用来指代Hi_Model 276。

模型270A、270B、272、274、276可以提供网络的各个方面或MIM200的各个配置阶段的表示。例如，可以使用模型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_Model 270A可以是LR_Model 270B中存在的内容的高级表达，它应当作为Ci_Model 274和Hi_Model 276表达而存在于具体设备上。如果模型之间存在任何差距，则可能存在不一致的配置或问题。

图3A示出了用于网络保证的示例保证设备300的图。在该示例中，保证设备300可以包括以集群模式运行的k个VM 110。VM在该示例中用于说明目的。然而，应当理解的是，本文中还考虑了其他配置，诸如对容器、裸金属设备、端点122或任何其他物理或逻辑系统的使用。此外，尽管图3A示出了集群模式配置，但是本文中还考虑了其他配置，诸如单模式配置(例如，单个VM、容器或服务器)或例如服务链。

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

保证设备300可以包括数据框架308，其可以基于例如APACHE APEX和HADOOP。在某些情况下，可以将保证检查编写为驻留在数据框架308中的各个运算符。这实现了本地水平向外扩展的架构，该架构可以扩展到结构120(例如，ACI结构)中任意数目的交换机。

保证设备300可以以可配置的周期(例如，时期)对结构120进行轮询。可以将分析工作流设置为运算符310的DAG(有向无环图)，其中数据从一个运算符流向另一运算符，并且对于每个间隔(例如，每个时期)最终生成结果并将其存留到数据库302。

北层(north-tier)实现API服务器(例如，APACHE Tomcat和Spring框架)304和Web服务器306。图形用户界面(GUI)经由暴露给客户的API进行交互。客户还可以使用这些API从保证设备300收集数据，以进一步集成到其他工具中。

数据框架308(例如，APEX/Hadoop)中的运算符310可以一起支持保证操作。以下是保证设备300可以经由运算符310执行的保证操作的非限制性示例。

安全策略遵守

保证设备300可以检查以确保包括例如安全策略和客户配置的合同的来自L_Model 270A的配置或规范(其可以反映用户对网络的意图)在Li_Model 272、Ci_Model 274和Hi_Model 276中被正确地实现和/或呈现并且因此由结构成员(例如，叶104)适当地实现和呈现，并且可以报告所发现的任何错误、合同违约、或违规行为。

静态策略分析

保证设备300可以检查用户的一个或多个意图的规范中的问题(例如，识别L_Model 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协议)是否没有导致黑洞、环路、翻动和其他问题的收敛问题。

MP-BGP路由反射检查

网络结构(例如，结构120)可以与其他外部网络交界并且经由一个或多个协议(诸如边界网关协议(BGP)、开放式最短路径优先(OSPF)等)向它们提供连接。经由例如MP-BGP在网络结构内通告所学习的路由。这些检查可以确保经由例如MP-BGP(例如，来自边界叶)的路由反射服务没有健康问题。

逻辑线头和实时变化分析

保证设备300可以验证是否网络的规范(例如，L_Model 270A)中的规则是完整的并且没有不一致或其他问题。保证设备300可以通过对L_Model 270A和/或MIM 200中的MO的相关配置执行的语法和语义检查来检查MIM 200中的MO。保证设备300还可以验证不必要、陈旧、未使用或冗余的配置(诸如合同)是否被移除。

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

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

拓扑资源管理器312被配置为发现结构120中的节点，诸如控制器116、叶104、脊102等。拓扑资源管理器312可以另外检测在控制器116当中执行的多数选举，并且确定在控制器116当中是否存在法定数量(quorum)。如果不存在法定数量或多数，则拓扑资源管理器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_Model270A和/或LR_Model 270B)，来自结构120中的节点(例如，叶104和/或脊102)的交换机软件配置和模型(例如，Ci_Model 274)，来自结构120中的节点(例如，叶104和/或脊102)的硬件配置和模型(例如，Hi_Model 276)，等等。统一收集器314可以收集来自各个节点或结构成员(诸如叶104和脊102)的Ci_Model 274和Hi_Model 276，和来自网络环境100中的一个或多个控制器(例如，控制器116)的L_Model 270A和/或LR_Model 270B。

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

在某些情况下，统一收集器314经由REST API来收集L_Model270A、LR_Model 270B和/或Ci_Model 274，并使用由交换机软件提供的实用程序(诸如用于访问交换机命令行界面(CLI)的虚拟外壳(VSH或VSHELL)或用于访问线卡的运行时状态的VSH_LC外壳)经由SSH来收集硬件信息(例如，配置、表、结构卡信息、规则、路由等)。

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

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

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

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

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

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

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

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

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

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

策略运算符318可以从统一收集器314接收每个交换机的Ci_Model274和Hi_Model276，并从交换机逻辑策略生成器316接收每个交换机的Li_Model 272，并基于Ci_Model274、Hi_Model 276和Li_Model 272执行保证检查和分析(例如，安全遵守检查、TCAM利用率分析等)。策略运算符318可以通过比较这些模型中的一个或多个来逐交换机地执行保证检查。

返回到统一收集器314，统一收集器314还可以将L_Model 270A和/或LR_Model270B发送到路由策略解析器320，并将Ci_Model 274和Hi_Model 276发送到路由解析器326。

路由策略解析器320可以接收L_Model 270A和/或LR_Model 270B，并解析(一个或多个)模型以获得可能与下游运算符(诸如端点检查器322和租户路由检查器324)有关的信息。类似地，路由解析器326可以接收Ci_Model 274和Hi_Model 276，并解析每个模型以获得针对下游运算符(端点检查器322和租户路由检查器324)的信息。

在Ci_Model 274、Hi_Model 276、L_Model 270A和/或LR_Model270B被解析之后，路由策略解析器320和/或路由解析器326可以将清理后的协议缓冲区(原始缓冲区(ProtoBuff))发送到下游运算符(端点检查器322和租户路由检查器324)。端点检查器322然后可以生成与端点违规(诸如重复IP、APIPA等)有关的事件，并且租户路由检查器324可以生成与BD、VRF、子网、路由表前缀等有关的事件。

图3C示出了用于网络(例如，网络环境100)中的静态策略分析的示例系统的示意图。静态策略分析器360可以执行保证检查，以检测配置违规、逻辑线头事件、矛盾或冲突的策略、未使用的合同、不完整的配置等。静态策略分析器360可以检查L_Model 270A中的一个或多个用户意图的规范以确定控制器116中是否有任何配置与一个或多个用户意图的规范不一致。

静态策略分析器360可以包括在保证设备300中执行或托管的运算符310中的一个或多个。然而，在其他配置中，静态策略分析器360可以运行与运算符310和/或保证设备300分开的一个或多个运算符或引擎。例如，静态策略分析器360可以是VM，VM集群，或服务功能链中的端点集合。

静态策略分析器360可以接收来自逻辑模型收集过程366的L_Model270A和针对L_Model 270A中的每个特征(例如，对象)定义的规则368作为输入。规则368可以基于MIM 200中的对象、关系、定义、配置和任何其他特征。规则368可以规定用于识别配置违规或问题的条件、关系、参数和/或任何其他信息。

此外，规则368可以包括用于识别语法违规或问题的信息。例如，规则368可以包括用于执行语法检查的一个或多个规则。语法检查可以验证L_Model 270A的配置是否是完整的，并且可以帮助识别未正在使用的配置或规则。语法检查还可以验证分层MIM 200中的配置是否是完整的(已被定义)，并识别已被定义但未被使用的任何配置。为了说明，规则368可以规定L_Model 270A中的每个租户都应配置上下文；L_Model 270A中的每个合同都应指定提供者EPG和消费者EPG；L_Model 270A中的每个合同都应指定主体、过滤器和/或端口；等等。

规则368还可以包括用于执行语义检查和识别语义违规或问题的规则。语义检查可以检查冲突的规则或配置。例如，Rule1和Rule2可以具有混叠问题，Rule1可以比Rule2更具体，从而产生冲突/问题等。规则368可以定义可能导致混叠的规则、冲突的规则等的条件。为了说明，规则368可以规定：如果允许策略具有比拒绝策略更高的优先级，或者对象的一个规则使另一个规则变得不必要，则两个对象之间的特定通信的允许策略可以与两个对象之间的同一通信的拒绝策略冲突。

静态策略分析器360可以将规则368应用于L_Model 270A以检查L_Model 270A中的配置并基于检测到的任何问题来输出配置违规事件370(例如，警报、日志、通知等)。配置违规事件370可以包括语义或语义问题，诸如不完整的配置、冲突的配置、混叠的规则、未使用的配置、错误、策略违规、配置错误的对象、不完整的配置、不正确的合同范围、不适当的对象关系等。

在某些情况下，静态策略分析器360可以迭代地遍历基于L_Model270A和/或MIM200生成的树中的每个节点，并在该树中的每个节点处应用规则368，以确定是否有任何节点产生违规(例如，不完整的配置、不适当的配置、未使用的配置等)。静态策略分析器360在检测到任何违规时可以输出配置违规事件370。

图4示出了用于检查意图规范内的不一致的示例保证场景400的示意图。可以检查意图规范402以确定是否已经为网络正确指定了意图。大量的网络错误涉及在配置网络或定义网络的意图时出现的人为错误。在SDN中，该人为错误随着意图变得集中化并变为基础设施范围而可以被放大。单个不良规范可以影响整个网络。此外，对于DevOps，意图的变化频率显著增加，这意味着随时可能发生单个错误指定的破坏性变化。SDN网络中的意图规范问题可以降低敏捷性，降低质量，增加安全性和合规性风险，并提高运营成本。

因此，保证设备300可以分析在控制器116中为网络定义的意图402，以检查意图规范402内的任何不一致。意图规范402可以包括在控制器116或编排器上指定并在L_Model270A中反映的意图。保证设备300可以(在意图规范402被应用之前和/或之后)检查意图规范402内的语法和/或语义问题以获得保证确定404。保证确定404可以识别意图规范402是否包含任何语法和/或语义问题。

为了说明的目的，在该示例中，意图规范402被图示为用于结构或数据中心的单个意图规范。然而，应当注意的是，在其他示例中，保证设备300可以检查不同的结构或数据中心中的意图规范之间的不一致。

在其他示例中，保证设备300还可以检查意图实现，这可以包括确定意图是否已被正确实现。例如，中心意图被传播到分布式系统中的节点。由于各种问题，诸如规模、异质性、频繁改变、故障等，意图的实现可能是难以实现的并且可能容易出错。在SDN网络中，用户检查分布式状态以确定意图是否被实现的能力可以是极其困难的并且受到极大限制。在许多情况下，节点动态地按需配置其数据路径，以根据需要满足意图。工作负载移动性经常需要意图实现的频繁变化，这可以使确定中心意图是否已被实现的问题大大恶化。

鉴于与意图实现相关联的问题和困难，在某些情形下，保证设备300可以检查意图规范402及其实现之间的不一致。例如，保证设备300可以检查意图规范402与其在控制/管理平面中的实现之间的不一致，控制平面处的实现与数据平面处的实现之间的不一致，编排规范与控制器116中的已实现规范之间的不一致，等等。

图5A示出了网络保证模型的示例流程图。在步骤500，该方法包括数据收集。数据收集可以包括收集用于运营商意图的数据，诸如结构数据(例如，拓扑、交换机、接口策略、应用策略、端点组等)、网络策略(例如，BD、VRF、L2输出、L3输出、协议配置等)、安全策略(例如，合同、过滤器等)、服务链策略等。数据收集还可包括用于具体硬件模型的数据，诸如网络配置(例如，RIB/FIB、VLAN、MAC、ISIS、DB、BGP、OSPF、ARP、VPC、LLDP、MTU、QoS等)、安全策略(例如，TCAM、ECMP表等)、端点动力学(例如，EPM、COOP EP DB等)、统计信息(例如，TCAM规则命中、接口计数器、带宽等)。

在步骤502，该方法可以包括形式化建模和分析。形式化建模和分析可以包括确定逻辑和硬件模型之间的等效性，诸如模型之间的安全策略等。

在步骤504，该方法可以包括智能事件生成。可以使用用于详细分析的深度对象层次结构来生成智能事件，诸如：租户，叶，VRF，规则；过滤器，路由，前缀，端口号。

在步骤506，该方法可以包括可视化。在用户友好的GUI中，形式化模型可以用于识别问题以进行分析和调试。

图5B示出了用于检查意图规范的示例方法。在步骤520，保证设备300可以从网络环境100中的控制器116获得网络环境100的逻辑模型。该逻辑模型可以例如是如图2D所示的L_Model 270A。该逻辑模型可以包括诸如MIM 200之类的分层管理信息树(MIT)中的一个或多个对象的配置，分层MIT定义了网络环境100的可管理对象和对象属性。在某些情况下，控制器116可以是ACI环境中的APIC。因此，可管理对象可以是在MIM 200中定义的被管理对象(MO)，并且配置可以包括经由一个或多个APIC(例如，控制器116)的用户输入的配置。可管理对象的非限制性示例可以包括租户、上下文、EPG、合同、过滤器、应用配置文件、BD、和网络结构接入对象。

在步骤522，保证设备300可以对逻辑模型中的配置执行策略分析。策略分析可以基于分层MIT和/或与逻辑模型相关联的一个或多个规则。此外，策略分析可以包括对逻辑模型中的配置的语法验证和/或对逻辑模型中的配置的语义验证。语法和/或语义验证可以基于为分层MIT中的可管理对象和/或对象属性定义的一个或多个规则。

基于策略分析，在步骤504，保证设备300可以确定逻辑模型中的配置是否包含一个或多个错误。这一个或多个错误可以包括线头事件、语法错误和/或语义错误，诸如不完整的配置、未使用的配置、冗余配置、混叠的规则、冲突的配置、不正确的配置、规则违反、逻辑线头事件等。

逻辑模型中的配置可以包括EPG配置、上下文配置、BD配置、子网配置、安全策略等。EPG配置可以包括EPG部署信息、EPG VLAN分配、EPG属性等。安全策略可以包括合同、过滤器、条目等。

策略分析可以包括EPG分析、BD或上下文策略分析、安全策略分析、用于检测混叠的语义分析等。EPG分析可以检查EPG配置的完整性或配置不匹配。例如，EPG分析可以检查已配置的EPG部署信息、EPG VLAN分配、和/或EPG属性的完整性。

BD或上下文策略分析可以检查上下文和BD配置的正确性。例如，BD或上下文策略分析可以检查每个BD是否是唯一上下文的一部分，并且每个唯一上下文是否具有至少一个有效BD。如果上下文具有策略实施，则上下文策略分析可以检查是否在EPG对之间定义了适当的合同以进行数据路径通信。

安全策略分析可以检查在合同中定义的消费者EPG和提供者EPG关系。例如，可以解析逻辑模型以确定每个有效的EPG提供者是否具有至少一个有效的匹配EPG消费者。

用于检测混叠的语义分析可以确定是否有任何合同已被混叠。例如，可以执行检查以验证诸如较高优先级规则之类的规则是否不会遮掩诸如较低优先级规则之类的另一个规则。因此，可以执行检查以确定是否有任何规则被较高优先级的规则变得冗余。可以从逻辑模型中删除识别出的任何混叠规则，以节省存储空间并限制不必要的规则。

保证设备300可以为其检测到的任何错误生成一个或多个通知。例如，保证设备300可以针对合同违约、混叠的规则、缺少的配置、冲突的规则等生成警报。保证设备300还可以为图形用户界面(GUI)提供对检测到的错误以及其他信息(诸如网络配置、网络拓扑、网络状况、推荐的配置改变、建议的修复、故障等)的警报、通知、和/或可视化图示。

图6示出了示例线头和策略分析系统的示意图。线头和策略分析系统可以检查网络的意图规范。策略分析系统可以分析逻辑模型(L_Model270A)并检测网络运营商所犯的配置错误。为了执行策略分析，策略分析生成器316可以将L_Model 270A作为输入600并生成输出602，其可以包括诸如与L_Model 270A中的对象相关联的配置或运行时错误之类的事件。策略分析可以包括对L_Model 270A的语法和/或语义分析。

在一些示例中，策略分析可以分析L_Model 270A的各个方面，诸如端点组(EPG)配置、上下文、网桥域/子网配置、安全策略(例如，合同、过滤器、条目等)。策略分析可以跨各种类别对L_Model 270A执行大量检查，以生成输出602并报告事件。可以通过事件所发现于的主要被管理对象和可能告诉最终用户该线头的爆炸半径的次要被管理对象列表来标记这些事件。以下是关于L_Model 270A的不同方面的策略分析的示例。

EPG策略分析：网络运营商可以在(一个或多个)控制器116中指定EPG部署信息、EPG VLAN分配、和EPG属性。策略分析可以针对完整性和对所有类型的EPG的任何配置不匹配的报告来检查这些中的每一个。

网桥域和上下文策略分析：网桥域和上下文对网络(例如，网络环境100)中的L2和L3边界进行建模。可以检查网桥域和上下文的属性的正确性。例如，每个网桥域都需要是唯一上下文的一部分，并且每个上下文都需要具有至少一个有效的网桥域。如果上下文具有策略实施，则需要在EPG对之间定义适当的合同以进行数据路径通信。

安全策略分析：可以解析L_Model 270A中的合同以检测是否指定了提供者和消费者关系。对于每个有效的提供者，应当至少存在一个有效的关联消费者。未能使提供者与至少一个消费者匹配将使提供者EPG悬空。

用于检测混叠的语义分析：策略分析还可以对L_Model 270A进行语义分析，以检测已被混叠的合同。例如，应用于给定EPG对(A，vzAny)的较高优先级规则可以潜在地遮掩EPG对(A，B)的规则。以下是可以执行的各种类型的混叠检查。

ALLOW_OVERSPECIFICATION：在这里，较高优先级的ALLOW(允许)规则与较低优先级的ALLOW规则完全重叠，从而使较低优先级的规则变得冗余。

ALLOW_CONTRADICTION：在这里，较高优先级的DENY(拒绝)规则与较低优先级的ALLOW规则完全重叠，从而使较低优先级的规则变得冗余。

DENY_OVERSPECIFICATION：在这里，较高优先级的DENY规则与较低优先级的DENY规则完全重叠，从而使得较低优先级的规则变得冗余。

DENY_CONTRADICTION：在这里，较高优先级的ALLOW规则与较低优先级的DENY规则完全重叠，从而使较低优先级的规则变得冗余。

可以潜在地从L_Model 270A中删除混叠的规则，以节省叶104中的硬件(例如，TCAM)空间。

在某些情况下，策略分析系统可以接受多个模型作为输入600。例如，策略分析生成器316可以接受L_Model 270A、LR_Model 270B、Li_Model 272、Ci_Model 274、和/或Hi_Model 276的实例作为输入600。每个模型也可以被解释为n输入m输出布尔函数，其中n代表模式中的输入字段的总位数并且m代表输出模式中的输出字段的总位数。输入字段的非限制性示例可以包括sg_label、sport、和dport，并且输出字段的非限制性示例可以包括DENY、QOS和PBR。布尔解释可以将(输出字段中的)动作指派给2^n个输入组合上的每个唯一的输入组合。

策略分析生成器316可以验证：对于n维输入空间(对于ACI/APIC，n＝147)中的每个输入组合，即对于2^147个唯一组合中的每个组合，模型在输出处的感兴趣的所有动作字段中产生相同的输出。策略分析生成器316可以支持各种动作(诸如允许、拒绝、允许日志、拒绝日志等)以及与QoS和PBR字段相关联的向量(多位)动作。根据哪些模型被用作输入600，检查可以用于确定意图等效性、实现等效性等。

为了执行这样的检查，可以将输入规范转换为特定的表示和/或格式。规范化可以允许有效地检查根据例如合同、过滤器等到其他表示(诸如值的位流和硬件中的掩码)在SDN构造中描述的意图。策略分析生成器316可以在内部使模型规范化以针对输出中的每个动作位在n维布尔空间上执行语义等效检查。

用于内部表示和规范化的数据结构的选择可以例如是简化有序二元决策图(ROBDD)。ROBDD是高效的数据结构，其可以递增地(即，逐规则或逐合同地)为两个输入模型建立整体表示。ROBDD是根据简化和排序的规范数据结构，因此，如果两个模型在功能/语义上等效，则它们的ROBDD表示将在内部收敛到相同的数据结构以证明模型的等效性。

基于输入600，策略分析生成器316可以执行如先前提到的线头和/或策略检查，并生成输出602，其可以包括任何线头或策略事件，诸如语义问题、语法问题等。

在某些情况下，可以将输出602提供作为按照输出字段中的每个动作的单个布尔值输出(等效/不等效)，即，策略分析生成器316跨动作(诸如ALLOW、DENY、ALLOW-LOG、DENY-LOG、QoS和PBR)生成指示模型之间的等效/不等效的事件。可以将输出602生成为用于外部消费的“事件”。以下是事件的非限制性示例。

ALLOW_TRAFFIC_MAYBE_BLOCKED——由于硬件(例如，TCAM)中的冲突的潜在过时的规则或者如果规则未被适当推送，带有具有动作ALLOW的主体/过滤器/filter_entry的合同未被正确地完全执行。

DENY_TRAFFIC_MAYBE_ALLOWED——由于硬件中的冲突的潜在过时的规则或者如果规则未被适当推送，带有具有动作DENY的主体/过滤器/filter_entry的合同未被正确地完全执行。

ALLOW_LOG_ACTION_VIOLATION——由于TCAM中的冲突的潜在过时的规则或者如果规则未被适当推送，带有具有动作“ALLOW，LOG(日志)”的主体/过滤器/filter_entry的合同未被正确地完全执行。

DENY_LOG_ACTION_VIOLATION——由于TCAM中的冲突的潜在过时的规则或者如果规则未被适当推送，带有具有动作“DENY，LOG”的主体/过滤器/filter_entry的合同未被正确地完全执行。

ENFORCED_VRF_POLICY_VIOLATION——如果给定的VRF处于ENFORCED(执行)状态，但是应被正确编程的默认规则具有违规(例如，(一个或多个)规则未被适当推送或与某个其他过时规则冲突)，则可以生成该事件。

UNENFORCED_VRF_POLICY_VIOLATION——如果给定的VRF处于UNENFORCED(未执行)状态，但是应被正确编程的默认规则具有违规(例如，(一个或多个规则)未被适当推送或与某个其他过时规则冲突)，则可以生成该事件。

*_ENFORCED——对于所有上述事件，肯定事件可以表明在硬件(例如，TCAM)中正确执行了合同。例如，ALLOW_TRAFFIC_POLICY_ENFORCED表明在TCAM硬件中正确表示了具有ALLOW动作规则的合同。

事件可以被以最细的粒度(<提供者EPG，消费者EPG，合同，主体，过滤器，过滤器条目>)生成和/或被聚合(<提供者EPG，消费者EPG>)，以减少事件泛滥。

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

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

为了实现与计算设备700的用户交互，输入设备745可以表示任何数目的输入机制，诸如用于语音的麦克风、用于手势或图形输入的触敏屏幕、键盘、鼠标、动作输入、语音等。输出设备735也可以是本领域技术人员已知的多种输出机制中的一种或多种。在一些情况下，多模式系统可以使用户能够提供多种类型的输入以与计算设备700通信。通信接口740通常可以支配和管理用户输入和系统输出。对任何特定硬件布置上的操作没有限制，因此这里的基本特征当它们发展时可以被容易地替换成改进的硬件或固件布置。

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

存储设备730可以包括用于控制处理器710的服务732、734、736。预期到其他硬件或软件模块。存储设备730可以连接到系统连接705。在一方面，执行特定功能的硬件模块可以包括与必要的硬件组件(诸如处理器710、连接705、输出设备735等)有关的在计算机可读介质中存储的软件组件，以执行该功能。

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

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

尽管图8所示的系统是本发明的一个特定网络设备，但它绝不是可以在其上实现本发明的唯一网络设备架构。例如，经常使用具有处理通信以及路由计算等的单个处理器的架构。另外，其他类型的接口和媒体也可以与网络设备800一起使用。

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

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

为了解释的清楚，在一些情况下，本技术可被呈现为包括各个功能块，其包括包含设备、设备组件、以软件体现的方法中的步骤或例程、或硬件和软件的组合的功能块。

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

总之，描述了用于意图规范检查的系统、方法和计算机可读介质。在一个示例中，系统从软件定义网络中的一个或多个控制器获得该软件定义网络的逻辑模型，该逻辑模型包括分层管理信息树中的一个或多个对象的配置，该分层管理信息树定义了该软件定义网络的可管理对象和对象属性。基于分层管理信息树，系统对逻辑模型中的配置执行策略分析，并基于该策略分析确定逻辑模型中的配置是否包含一个或多个错误。

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

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

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

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

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

Claims (23)

1.一种方法，包括：

从软件定义网络中的一个或多个控制器获得所述软件定义网络的逻辑模型，所述逻辑模型包括分层管理信息树中的一个或多个对象的配置，所述分层管理信息树定义了所述软件定义网络的可管理对象和对象属性；

基于所述分层管理信息树对所述逻辑模型中的配置执行策略分析；和

基于所述策略分析，确定所述逻辑模型中的所述配置是否包含一个或多个错误。

2.如权利要求1所述的方法，其中，所述一个或多个错误包括以下各项中的至少一者：冲突的配置，混叠的规则，未使用的配置，一个或多个对象或对象属性的不完整配置，以及一个或多个冗余配置。

3.如权利要求1或2所述的方法，其中，所述一个或多个对象包括：与在所述软件定义网络的逻辑模型中配置的第一租户相关联的第一对象集合，以及与在所述软件定义网络的逻辑模型中配置的一个或多个第二租户相关联的一个或多个第二对象集合。

4.如权利要求3所述的方法，其中，所述配置包括：针对与所述第一租户相关联的所述第一对象集合的第一配置集合，以及针对与所述一个或多个第二租户相关联的所述一个或多个第二对象集合的一个或多个第二配置集合。

5.如权利要求1至4中的任一项所述的方法，其中，所述逻辑模型中的所述配置包括：端点组配置、上下文配置、网桥域配置、子网配置、和安全策略中的至少一者，并且其中执行所述策略分析包括：执行对所述配置的语法验证和执行对所述配置的语义验证中的至少一者。

6.如权利要求5所述的方法，其中，所述策略分析包括语法验证和语义验证中的至少一者，其中所述安全策略包括合同、过滤器、和条目中的至少一者，并且其中所述端点组配置包括端点组部署信息、端点组虚拟局域网分配、和端点组属性中的至少一者。

7.如权利要求6所述的方法，其中，所述语法验证和所述语义验证包括端点组分析、网桥域或上下文策略分析、安全策略分析、和用于检测混叠的语义分析中的至少一者，其中所述端点组分析包括检查所述端点组配置的完整性或配置不匹配，其中所述网桥域或上下文策略分析包括检查上下文配置和网桥域配置的正确性，其中所述安全策略分析包括检查在合同中定义的消费者端点组和提供者端点组关系，并且其中所述用于检测混叠的语义分析包括确定第一规则是否被具有比该第一规则更高的优先级的第二规则变得冗余。

8.如权利要求7所述的方法，其中，所述可管理对象包括以下各项中的至少一者：租户对象、上下文对象、端点组、合同、过滤器、应用配置文件、网桥域、和网络结构接入对象。

9.一种系统，包括：

一个或多个处理器；和

至少一个存储有指令的计算机可读存储介质，所述指令在由所述一个或多个处理器执行时使所述系统进行以下操作：

从软件定义网络中的一个或多个控制器获得所述软件定义网络的逻辑模型，所述逻辑模型包括分层管理信息树中的一个或多个对象的配置，所述分层管理信息树定义了所述软件定义网络的可管理对象和对象属性；

基于所述分层管理信息树，对所述逻辑模型中的配置执行策略分析；和

基于所述策略分析，确定所述逻辑模型中的所述配置是否包含一个或多个错误。

10.如权利要求9所述的系统，其中，所述一个或多个错误包括以下各项中的至少一者：冲突的配置，混叠的规则，未使用的配置，一个或多个对象或对象属性的不完整配置，以及一个或多个冗余配置。

11.如权利要求9或10所述的系统，其中，所述逻辑模型中的所述配置包括端点组配置、上下文配置、网桥域配置、子网配置、和安全策略中的至少一者，并且其中所述策略分析包括对所述配置的语法验证和对所述配置的语义验证中的至少一者。

12.如权利要求11所述的系统，其中，所述安全策略包括合同、过滤器、和条目中的至少一者，并且其中所述端点组配置包括端点组部署信息、端点组虚拟局域网分配、和端点组属性中的至少一者。

13.如权利要求12所述的系统，其中，所述语法验证和所述语义验证包括以下各项中的至少一者：端点组分析、网桥域或上下文策略分析、安全策略分析、和用于检测混叠的语义分析。

14.如权利要求13所述的系统，其中，所述端点组分析包括检查所述端点组配置的完整性或配置不匹配，其中所述网桥域或上下文策略分析包括检查上下文配置和网桥域配置的正确性，其中所述安全策略分析包括检查在合同中定义的消费者端点组和提供者端点组关系，并且其中所述用于检测混叠的语义分析包括确定第一规则是否被具有比该第一规则更高的优先级的第二规则变得冗余。

15.如权利要求14所述的系统，其中，检查上下文配置和网桥域配置的正确性包括：检查每个网桥域是否与唯一上下文相关联并且每个唯一上下文是否具有至少一个有效的网桥域。

16.如权利要求14或15所述的系统，其中，所述可管理对象包括以下各项中的至少一者：租户、上下文、端点组、合同、过滤器、应用配置文件、网桥域、和网络结构接入对象。

17.一种非暂时性计算机可读存储介质，包括：

存储在其中的指令，所述指令在由一个或多个处理器执行时使所述一个或多个处理器进行以下操作：

从软件定义网络中的一个或多个控制器获得所述软件定义网络的逻辑模型，所述逻辑模型包括分层管理信息树中的一个或多个对象的配置，所述分层管理信息树定义了所述软件定义网络的可管理对象和对象属性；

基于所述分层管理信息树，对所述逻辑模型中的配置执行验证，所述验证包括语法验证或语义验证中的至少一者；和

基于所述验证，确定所述逻辑模型中的所述配置是否包含一个或多个错误。

18.如权利要求17所述的非暂时性计算机可读存储介质，其中，所述一个或多个错误包括冲突的配置、混叠的规则、未使用的配置、一个或多个对象的不完整配置、和一个或多个冗余配置中的至少一者，其中所述逻辑模型中的配置包括端点组配置、上下文配置、网桥域配置、子网配置、和安全策略中的至少一者。

19.如权利要求18所述的非暂时性计算机可读存储介质，其中，所述可管理对象包括以下各项中的至少一者：租户、上下文、端点组、合同、过滤器、应用配置文件、网桥域、和网络结构接入对象。

20.如权利要求19所述的非暂时性计算机可读存储介质，其中，所述验证包括端点组分析、网桥域或上下文策略分析、安全策略分析、和混叠分析中的至少一者，其中所述端点组分析包括检查所述端点组配置的完整性，其中所述网桥域或上下文策略分析包括检查上下文配置和网桥域配置的正确性，其中所述安全策略分析包括检查在合同中定义的消费者端点组和提供者端点组关系，并且其中所述混叠分析包括确定第一规则是否被具有比该第一规则更高的优先级的第二规则变得冗余。

21.一种装置，包括：

用于从软件定义网络中的一个或多个控制器获得所述软件定义网络的逻辑模型的构件，所述逻辑模型包括分层管理信息树中的一个或多个对象的配置，所述分层管理信息树定义了所述软件定义网络的可管理对象和对象属性；

用于基于所述分层管理信息树对所述逻辑模型中的配置执行策略分析的构件；和

用于基于所述策略分析来确定所述逻辑模型中的所述配置是否包含一个或多个错误的构件。

22.根据权利要求21所述的装置，还包括用于实现根据权利要求2至8中任一项所述的方法的构件。

23.一种计算机程序、计算机程序产品或计算机可读介质，包括指令，所述指令在由计算机执行时使该计算机执行权利要求1至8中任一项所述的方法的步骤。