CN110710160A - 生成用于网络策略分析的全网络逻辑模型 - Google Patents

Abstract

用于生成网络的全网络逻辑模型的系统、方法和计算机可读介质。在一些示例中，系统从网络中的多个控制器获得与网络相关联的各个逻辑模型段，各个逻辑模型段中的每个逻辑模型段包括在多个控制器中的相应控制器处的针对网络的配置，各个逻辑模型段是基于定义网络的可管理对象和对象属性的模式的。系统确定多个控制器是否为法定数量，并且当多个控制器为法定数量时，组合与网络相关联的各个逻辑模型段以产生网络的全网络逻辑模型，该全网络逻辑模型包括跨多个控制器的针对网络的配置。

Description

生成用于网络策略分析的全网络逻辑模型

相关申请的交叉引用

本申请要求享有2017年5月31日提交的名称为“生成用于网络策略分析的全网络逻辑模型”的美国临时专利申请No.62/513,144以及2017年10月17日提交的名称为“生成用于网络策略分析的全网络逻辑模型”的美国非临时专利申请No.15/786,425的优先权。这两个申请的内容通过引用明确地以其全文结合于此。

技术领域

本技术涉及网络配置和故障排除，并且更具体地涉及生成网络的用于网络保障和策略分析的逻辑模型。

背景技术

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

附图说明

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

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

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

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

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

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

图3A示出了示例保障设备系统；

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

图4A示出了用于构建网络的逻辑模型的第一示例方法的示图；

图4B示出了用于构造网络的逻辑模型的第二示例方法的示图；

图4C示出了用于基于网络的逻辑模型来构造设备专用逻辑模型的示例图；

图5A示出了示例策略分析器的示意图；

图5B示出了不同网络模型的等效图；

图5C示出了用于识别冲突规则的示例架构；

图6A示出了第一示例冲突减少有序二进制决策图(ROBDD)；

图6B示出了第二示例冲突ROBDD；

图6C示出了具有附加规则的图6B的示例冲突ROBDD；

图7A示出了用于网络保障的示例方法；

图7B示出了用于生成网络的全网络逻辑模型的示例方法；

图8示出了示例网络设备；和

图9示出了示例计算设备。

具体实施方式

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

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

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

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

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

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

总述

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

在许多情况下，网络中的各种节点和/或控制器可以包含网络和网络状态的相应信息或表示。例如，不同的控制器可以存储网络的不同逻辑模型，并且网络结构中的每个节点可以包含其自己的针对网络的配置模型。本文提出的方法可以从网络中的各个控制器和节点收集信息和/或模型，并基于来自各个控制器的信息和/或模型来构建网络的全网络模型。全网络逻辑模型可用于分析网络，生成其他模型以及比较网络模型以执行网络保障。本文中的建模方法可以提供对网络的重要洞察性、预见性和可见性。

本文公开了用于生成网络或网络的全架构逻辑模型的系统、方法和计算机可读介质。在一些示例中，一种系统或方法识别诸如软件定义网络(SDN)之类的网络中的控制器，并从多个控制器获取与该网络相关联的各个逻辑模型段。各个逻辑模型段中的每个可以包括存储在多个控制器中的各个控制器处的针对网络的配置。各个逻辑模型段可以基于为网络定义可管理对象和对象属性的模式，例如为网络定义的分层管理信息树。此外，各个逻辑模型段可以包括存储在多个控制器处的网络的各个逻辑模型的至少一部分。

该系统和方法组合与网络相关联的各个逻辑模型段，以产生网络的全网络逻辑模型。全网络逻辑模型可以包括跨多个控制器的对于网络的配置。配置可以是包括在各个逻辑模型段中的配置和/或数据。

在组合或集中各个逻辑模型段之前，该系统或方法可以确定多个控制器是否处于法定数量(quorum)。可以基于一个或多个法定数量规则来确定法定数量。法定数量规则例如可以指定当多个控制器具有特定状态(例如可达性状态、活动状态、兼容状态等)时，形成法定数量。在某些情况下，各个逻辑模型的组合或集中可以基于多个控制器形成法定数量的确定。例如，该系统或方法可以仅在多个控制器形成法定数量的情况下集中和/或组合各个逻辑模型段。

示例实施例

所公开的技术满足了本领域中对准确和有效的网络建模和保障的需求。本技术涉及用于生成全网络网络模型的系统、方法和计算机可读介质，其可用于网络保障和故障排除。本技术将在以下公开中描述如下。讨论从对网络保障的介绍性讨论和示例计算环境的描述开始，如图1A和图1B所示。然后讨论用于网络保障的网络模型，如图2A到2D所示，以及网络建模和保障系统，如图3A-C、4A-C、5A-C、6A-C以及7A-B所示。讨论以对示例网络和计算设备的描述结束，如图8和9所示，包括适合于托管软件应用和执行计算操作的示例硬件组件。

现在，本公开转向对网络建模和保障的讨论。

网络保障(assurance)是对网络按照网络运营商的预期进行行为并已正确配置的保障或确定(例如，网络正在执行其预期的工作)。预期可以涵盖各种网络操作，例如桥接、路由、安全、服务链、端点、合规性、QoS(服务质量)、审核等。预期可以体现在为网络和单个网络元件(例如，交换机、路由器、应用、资源等)定义的一个或多个策略、设置、配置等中。在某些情况下，网络运营商定义的配置、策略等可能无法准确反映在网络的实际行为中。例如，网络运营商为一种或多种类型的流量指定配置A，但后来发现网络实际上正在将配置B应用于该流量，或者以与配置A不一致的方式处理该流量。这可能是许多不同原因的结果，例如硬件错误、软件缺陷、优先级变化、配置冲突、一个或多个设置的误配、设备的不正确规则解析、意外的错误或事件、软件升级、配置更改、故障等。作为另一个示例，网络运营商为网络定义配置C，但是网络中的一个或多个配置导致网络以与网络运营商实施配置C所反映的预期不一致的方式进行行为。

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

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

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

因此，网络保障可以涉及对网络的属性建模以确定性地预测网络的行为。如果(一个或多个)模型表明适当的行为(例如，没有不一致、冲突、错误等)，则可以确定网络健康。如果建模表明适当的行为但存在一些不一致，则可以确定网络功能正常，但不是完全健康。如果建模表明不当行为和错误，则可以确定网络功能不正常并且不健康。如果通过建模检测到不一致或错误，则对相应模型的详细分析可以使一个或多个底层问题或根本问题得以非常准确地识别。

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

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

图1A示出了示例网络环境100(例如，数据中心)的示图。网络环境100可以包括结构120，该结构120可以代表网络环境100的物理层或基础结构(例如，底层)。结构120可以包括可以互连以在结构120中路由或交换流量的脊102(例如，脊路由器或交换机)和叶104(例如，叶路由器或交换机)。脊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)或VMWARE NSX)基于端点或资源属性(例如端点类型和/或应用组或配置文件)在逻辑和/或硬件级别上实现配置。为了说明，一个或多个管理员可以通过控制器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)。考虑将三种类型的VM(即应用、数据库和Web VM)放入单个第2层网段的情况。可以根据VM类型在网段内提供流量保护。例如，可以在Web VM之间允许HTTP流量，而在Web VM与应用或数据库VM之间不允许HTTP流量。为了对流量进行分类并实施策略，VMWARE NSX可以实施安全组，这些安全组可用于对特定VM(例如，Web VM、应用VM、数据库VM)进行分组。可以将DFW规则配置为实施特定安全组的策略。为了说明，在前面的示例的上下文中，可以将DFW规则配置为阻止网站、应用和数据库安全组之间的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主机；虚拟机DOCKER容器；等等

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

端点122可以与相应的逻辑组118关联。逻辑组118可以是包含根据一个或多个属性(例如端点类型，例如VM类型、工作负载类型、应用类型等)、一个或多个要求(例如策略要求、安全要求、QoS要求、消费者要求、资源要求等)、资源名称(例如VM名称、应用名称等)、配置文件、平台或操作系统(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网络的示例模式(schema)的示图。该模式可以定义与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。

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

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

如本文所用，术语“专有名称”(DN)可以指描述对象(例如MO)并在管理信息模型200中定位其位置的唯一名称。在某些情况下，DN可以是(或等于)完全合格域名(FQDN)。

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

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

如本文所使用的，术语“L2输出(Out)”可以指桥接的连接。桥接的连接可以连接同一网络的两个或多个网段，以便它们可以通信。在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层地址域，该域允许路由表的多个实例存在并同时工作。通过允许在不使用多个设备的情况下对网络路径进行分段，从而增加了功能性。也称为上下文或专用网络。

已经描述了本文中使用的各种术语，本公开现在返回到图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)，其描述对象并在树中定位其位置。节点116、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的用户特权、角色和结构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耦合。为了使流量流通，EPG部署在具有物理、VMM、L2输出、L3输出或光纤通道域中的VLAN的叶端口上。

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

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

如图所示，模型可以包括L_Model 270A(逻辑模型)、LR_Model 270B(逻辑展示模型或逻辑运行时模型)、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处表示网络的逻辑配置。这是在网络实体的元素(例如应用、租户等)被连接并且由控制器116提供结构120时所需的“结束状态”表达的声明。因为L_Model 270A代表在控制器116中输入的配置，包括MIM 200中的对象和关系，所以它也可以反映管理员的“预期”：管理员希望网络和网络元素如何工作。

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

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

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

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

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

在某些情况下，可以使用JSON(JavaScript对象表示法)表示Li_Model 272。例如，Li_Model 272可以包含JSON对象，例如规则(Rule)、过滤器(Filter)、条目(Entries)和范围(Scopes)。

Ci_Model 274是各个结构成员i(例如，交换机i)的实际状态中(in-state)配置。换句话说，Ci_Model 274是基于Li_Model 272的交换机级别或特定于交换机的模型。例如，控制器116可以将Li_Model 272递送到叶1(104)。叶1(104)可以采用可以特定于叶1(104)的Li_Model 272，并将Li_Model 272中的策略展示(render)为在叶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_Model 274中的配置。叶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可以提供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中的一个或多个资源100(例如，存储、计算、VM、端口通道、物理元素等)的资源模型284等。

通常，L_Model 270A可以是LR_Model 270B中存在的内容的高级表达，该表达应在具体设备上以Ci_Model 274和Hi_Model 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中的各个操作器编写或提供。这实现了本机水平向外扩展的体系结构，该体系结构可以扩展到结构120(例如，ACI结构)中的任意数量的交换机。

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

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

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

安全策略遵守

保障设备系统300可以检查以确保来自L_Model 270A的配置或规范(这些配置或规范可以反映用户针对网络的意图，包括例如安全策略和消费者配置的合约)在Li_Model272、Ci_Model 274和Hi_Model 276中正确实施和/或展示，并因此由结构成员(例如叶104)正确实施和/或展示，并报告发现的任何错误、违反合约或违规行为。

静态策略分析

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

TCAM利用

TCAM是结构(例如，结构120)中的稀缺资源。但是，保障设备系统300可以通过网络数据(例如，最长前缀匹配(LPM)表、路由表、VLAN表、BGP更新等)、合约、逻辑组118(例如，EPG)、网络环境100中的租户、脊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可以包括操作器312、314、316、318、320、322、324和326。在一些情况下，操作器312、314、316、318、320、322、324和326可以对应于先前关于图3A讨论的操作器310。例如，操作器312、314、316、318、320、322、324和326可以各自代表保障设备系统300的操作器310中的一个或多个操作器。

在该示例中，拓扑管理器(Explore)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、节点_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_Model 270A和/或LR_Model270B)，从结构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_Model 270A、LR_Model 270B和/或Ci_Model 274，并且通过SSH利用由用于访问交换机命令行界面(CLI)或VSH_LC外壳程序来访问线卡的运行时状态的交换机软件(诸如虚拟外壳程序(VSH或VSHELL))提供的实用程序来收集硬件信息(例如，配置、表、结构卡信息、规则、路由等)。

统一收集器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_Model270A和/或LR_Model 270B)。统一收集器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_Model 272，从而为每个交换机基于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_Model 274和Hi_Model 276以及从交换机逻辑策略生成器316接收针对每个交换机的Li_Model 272，并基于Ci_Model 274、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_Model 270B解析之后，路由策略解析器320和/或路由解析器326可以将清理后的协议缓冲区(Proto Buff)发送给下游操作器(端点检查器322和租户路由检查器324)。然后，端点检查器322可以生成与端点违规有关的事件，例如重复IP、APIPA等，并且租户路由检查器324可以生成与路由表前缀、子网、VRF、BD的部署等有关的事件。

图4A图示了图示400，其描绘了用于基于从网络(例如，网络环境100)上的各种控制器(例如，控制器116-1至116-N)获得的逻辑模型270-1来构造网络的逻辑模型270的示例方法。逻辑模型270在本文中将互换地被称为逻辑模型270或全网络逻辑模型270。

逻辑模型270-1至270-N可以包括存储在各个控制器116处的L_Model 270A和/或LR_Model 270B的相应版本，如图2D所示。逻辑模型270-1至270-N中的每一个可以包括存储在各个控制器116处的网络的对象和配置。对象和配置可以包括网络运营商通过控制器116提供的数据和配置。控制器116可以存储要推送到结构120中的节点(例如叶104)的此类对象和配置。

在一些情况下，可以通过轮询控制器的各个逻辑模型和/或存储的配置来从多个控制器获得逻辑模型270-1至270-N。例如，保障设备系统300可以轮询控制器116并从控制器116提取逻辑模型和/或配置。保障设备系统300可以经由一个或多个引擎或操作器(例如，操作器310)，例如统一收集器314，从控制器116收集逻辑模型和/或配置。保障设备系统300还可以从网络中的节点(例如，叶104)收集其他数据，例如运行时状态和/或配置，并将某些或全部这种信息合并到逻辑模型270中。例如，保障设备系统300可以经由例如拓扑管理器312从节点收集运行时或状态数据，并将运行时或状态数据合并到逻辑模型270中。

保障设备系统300可以收集逻辑模型270-1至270-N，并基于逻辑模型270-1至270-N生成逻辑模型270。逻辑模型270可以基于来自控制器116的逻辑模型270-1至270-N来提供网络的全网络表示。因此，逻辑模型270可以反映网络的意图规范。换句话说，逻辑模型270可以通过网络运营商经由控制器116指定的配置和数据来反映网络运营商想要的网络的配置。

逻辑模型270可以通过组合逻辑模型270-1至270-N来生成。例如，可以通过比较逻辑模型270-1至270-N并将来自各种逻辑模型的配置和数据合并成单个逻辑模型来构造逻辑模型270。为了说明，保障设备系统300可以收集逻辑模型270-1至270-N，比较逻辑模型270-1至270-N中的数据，并基于比较后的数据，例如通过合并、组合、匹配逻辑模型270-1至270-N中的数据的各部分来构建逻辑模型270。

逻辑模型270可以包括一致(例如，匹配)的数据和/或配置，该数据和/或配置至少包括阈值数量的逻辑模型270-1至270-N。例如，阈值数目可以基于具有匹配数据和/或配置的逻辑模型是否源自足以建立法定数量的多个控制器，如前所述。在某些情况下，可以从逻辑模型270中排除仅在源自少于法定数量的那些数量的控制器的逻辑模型中发现的数据和/或配置。在其他情况下，即使不满足法定数量，也可以包括此类数据和/或配置。例如，可以包括这些数据和/或配置，但是可以通过随后对控制器的轮询和逻辑模型的比较来进行验证。如果在对控制器进行轮询并比较所获得的逻辑模型的多次迭代之后，这些数据和/或配置仍未包括在来自法定数量的控制器的逻辑模型中，则这些数据和/或配置可以被丢弃、标记、测试等。

在某些情况下，可以通过轮询控制器并分析从控制器获得的逻辑模型来定期更新或验证逻辑模型270。例如，可以按特定的时间间隔或计划的周期对控制器进行轮询。在某些情况下，逻辑模型270的更新和/或验证可以由事件触发，例如软件更新、配置修改、网络更改等。例如，当在一个或多个控制器处修改、添加或删除配置时，可以触发逻辑模型270的更新和/或验证。此类事件可以触发向控制器轮询逻辑模型。在一些情况下，可以在推送的基础上获得逻辑模型，使得控制器可以周期性地和/或基于触发事件(例如，配置更新)推送其逻辑模型和/或配置。

图4B示出了图示410，其描绘了用于构建逻辑模型270的另一示例方法。在该示例中，逻辑模型270是从获得自网络(例如，网络环境100)上的控制器116-1至116-N的逻辑模型段412、414、416生成的。例如，保障设备系统300可以从控制器116-1至116-N收集逻辑段412、414、416，并基于所收集的逻辑模型段(即，逻辑模型段412、414、416)来构造逻辑模型270。逻辑模型段412、414、416可以表示存储在控制器116-1至116-N中的每一个处的相应逻辑模型的一部分。例如，控制器116-1至116-N可各自存储网络的逻辑模型，其可包括由网络运营商在相应控制器处输入的配置和/或从网络上的其他控制器传播到相应控制器的一个或多个配置。

逻辑模型段412、414、416表示的各个逻辑模型的部分可以基于一个或多个偏好而不同，并且表示整个网络和/或全网络逻辑模型或规范的不同方面。在一些情况下，逻辑模型段412、414、416可各自表示在网络上配置的一个或多个相应的元素、配置、对象等(例如，在控制器116-1至116-N上的逻辑模型中指定)，例如一个或多个相应的租户、VRF、域、EPG、服务、VLAN、网络、合约、应用配置文件、桥接域等。

例如，逻辑模型段412可以表示在控制器116-1处针对租户A的数据和配置，逻辑模型段414可以表示在控制器116-2处针对租户B的数据和配置，逻辑模型段416可以表示在控制器116-N处针对租户C和D的数据和配置。作为另一个示例，逻辑模型段412可以表示控制器116-1处针对EPG A的数据和配置，逻辑模型段414可以表示控制器116-2处针对EPG B的数据和配置，逻辑模型段416可以表示控制器116-N处针对EPG C的数据和配置。逻辑模型段412、414、416可以一起为网络提供全网数据和配置，这可以用于生成逻辑模型270，该逻辑模型270表示网络的全网络逻辑模型。因此，保障设备系统300可以将逻辑模型段412、414、416缝合在一起(例如，组合，合并等)以构建逻辑模型270。

在某些情况下，与在控制器116-1至116-N处的逻辑模型的整个副本相反，使用逻辑模型段412、414、416来构建逻辑模型270可以提高性能，减少网络拥塞或带宽使用，防止或限制逻辑模型不一致，减少错误等。例如，在大型网络中，在控制器116-1至116-N处收集整个逻辑模型可能会占用大量带宽并造成拥塞。此外，控制器116-1至116-N处的逻辑模型可能包含大量的冗余，这可能不必要地在网络上增加了额外的负载和负担。因此，保障设备系统300可以将从控制器116-1至116-N收集的数据以及逻辑模型的(一个或多个)部分划分为段，并且代替地从控制器116-1至116-N收集逻辑模型数据的各段(在此示例中由逻辑模型段412、414、416表示)。

在某些情况下，保障设备系统300可以确定从哪些控制器收集数据(例如逻辑模型段)，从哪些控制器收集哪些数据(例如逻辑模型段)，和/或可以将哪些收集器验证为可靠，等等。例如，保障设备系统300可以从控制器的集群418收集逻辑模型段412、414、416。集群418可以包括具有特定状态或特性(例如，活动状态、可达状态、特定软件版本、，特定硬件版本等)的那些控制器。例如，集群418可以包括活动的、具有特定硬件或软件版本的和/或网络中的其他节点(例如控制器)可达的控制器，并且可以排除任何不活动的、不具有特定的硬件或软件版本的和/或其他节点不可达的任何控制器。

保障设备系统300还可以确定集群418中的控制器(例如，控制器116-1至1 16-N)是否形成法定数量。可以如先前基于一个或多个法定数量规则(例如，集群418中的控制器的数量或比率)进行法定数量确定。如果集群418形成法定数量，则保障设备系统300可以继续进行逻辑模型段412、414、416的收集。另一方面，如果集群418没有形成法定数量，保障设备系统300可以延迟收集，发出错误或通知警报和/或尝试确定其他控制器是否可用并且可以包含在集群418中以满足法定数量。

在该示例中，示图410示出了单个集群，即集群418。在此，为了清楚和说明的目的而提供了集群418。但是，应注意，其他配置和示例可以包括多个集群。例如，控制器116可以被分组为不同的集群。保障设备系统300可以从不同的集群中收集不同的信息(例如，逻辑段)，或者可以从两个或多个集群中收集相同的信息。为了说明，在一些示例中，保障设备系统300可以收集来自第一集群的逻辑段A-D，来自第二集群的逻辑段E-G，来自第三集群的逻辑段H-F，等等。

在其他示例中，保障设备系统300可以从第一集群和第二集群收集逻辑段A-D，从第三集群和第四集群收集逻辑段E-G，从第五集群和第六集群收集逻辑段H-F，等等。在此，保障设备系统300可以从两个或更多个不同的集群中收集(一个或多个)相同的逻辑段，或者在两个或更多个的集群中分布多个逻辑段的收集。为了说明，在先前的示例中，当从第一集群和第二集群收集逻辑段A-D时，保障设备系统300可以从第一集群以及第二集群收集逻辑段A-D，因此具有逻辑段A-D的多个副本(例如，来自第一集群的副本和来自第二集群的第二副本)，或者以其他方式从第一集群收集逻辑段A-B并从第二集群收集逻辑段C-D，从而将逻辑段A-D的收集分布在第一集群和第二集群。当从不同集群收集一个或多个逻辑段的副本(例如，从第一集群收集逻辑段A-D的副本，并从第二集群收集逻辑段A-D的第二副本)时，保障设备系统300可以维护副本以实现冗余和/或使用一个或多个其他副本以进行验证(例如，准确性验证)、完整性检查等。

在一些情况下，可以从逻辑模型270中排除从具有少于法定数量的那些数量的控制器的集群中收集的数据和/或配置(例如，逻辑模型段)。在其他情况下，即使不满足法定数量，也可以包括此类数据和/或配置。例如，可以包括这些数据和/或配置，但是可以通过随后在集群中轮询或监视控制器并确定控制器的健康状况、集群的法定数量状态、控制器的状态(例如，可达性、软件或硬件版本等)、控制器和/或相应数据的可靠性等来验证。如果集群和/或控制器的数量不是法定数量和/或被确定为具有特定条件(例如，不可达性、错误、不兼容的软件和/或硬件版本等)，则来自此类集群或数量的控制器的数据可以从逻辑模型270中排除、丢弃、标记等，并且生成指示与此集群和/或数量的控制器相关联的条件或状态的错误或消息通知。

在某些情况下，可以通过轮询控制器116-1至116-N并分析从集群418中的控制器116-1至116-N收集的逻辑模型段412、414、416来定期更新或验证逻辑模型270。例如，可以以特定的时间间隔或计划的周期来轮询控制器116-1至116-N。在某些情况下，逻辑模型270的更新和/或验证可以由事件触发，例如软件更新、配置修改、网络更改等。例如，当在一个或多个控制器处修改、添加或删除配置时，可以触发逻辑模型270的更新和/或验证。这样的事件可以触发保障设备系统300向控制器116-1至116-N轮询逻辑模型段412、414、416和/或其他信息，例如运行时数据、健康数据、状态数据(例如，连通性、状态，等)、存储的数据、更新等。

逻辑模型段412、414、416可以基于推送和/或拉取来收集。例如，逻辑模型段412、414、416可以由保障设备系统300拉取和/或由控制器116-1至116-N周期性地和/或基于触发事件(例如，更新、错误、网络更改等)来推送。

图4A和图4B所示的逻辑模型270可以包括来自网络和/或节点的运行时状态或数据，如关于LR_Model 270B所描述的。因此，逻辑模型270可以是诸如L_Model 270A的逻辑模型，或者是具有运行时状态或数据的诸如LR-Model 270B的逻辑模型。在某些情况下，保障设备系统300可以获取逻辑模型270，并合并运行时状态或数据以生成运行时全网络逻辑模型，例如LR-Model 270B。此外，保障设备系统300可以维护具有运行时状态或数据的以及没有运行时状态或数据的逻辑模型270的副本。例如，保障设备系统300可以维护L_Model270A的副本和LR_Model 270B的副本。

图4C示出了用于基于网络(例如，网络环境100)的逻辑模型270来构造特定于节点的逻辑模型(例如，Li_Model 272)的示例示图420。如前所述，逻辑模型270可以是网络的全网络逻辑模型，并且可以包括如关于LR_Model 270B所描述的运行时数据或状态。在该示例中，假设逻辑模型270包括运行时状态或数据。

逻辑模型270可以包括要通过例如控制器116推送到结构120中的节点(例如叶104)的网络的对象和配置。因此，逻辑模型270可以用于为结构120中的每个节点(例如，叶104)构造特定于节点的逻辑模型(例如，Li_Model 272)。为此，逻辑模型270可以适用于每个节点(例如，叶104)，以便为每个节点生成各自的逻辑模型，该逻辑模型表示和/或对应于来自逻辑模型270的与节点有关的(一个或多个)部分和/或信息和/或来自逻辑模型270的应在节点处被推送、存储和/或展示的(一个或多个)部分和/或信息。

每个特定于节点的逻辑模型Li_Model 272可以包含来自逻辑模型270的与特定节点有关的对象、属性、配置、数据等，包括当由逻辑模型270指定的全网意图被传播或投射到单个节点时来自逻辑模型270的在该特定节点上投射或展示的任何(一个或多个)部分。换句话说，为了执行在逻辑模型270中指定的意图，各个节点(例如，叶104)可以实现逻辑模型270的各个部分，使得各个节点可以一起执行在逻辑模型270中指定的意图。

因此，特定于节点的逻辑模型Li_Model 272将包含将由各个节点处的软件展示的数据和/或配置，包括规则和属性。换句话说，特定于节点的逻辑模型Li_Model 272包括用于配置特定节点的数据。然后节点处展示的配置和数据可以随后推送到节点硬件(例如，TCAM)，以在节点的硬件上生成展示的配置。

如本文所用，术语节点特定的逻辑模型、特定于设备的逻辑模型、特定于交换机的逻辑模型、节点级别逻辑模型、设备级别逻辑模型和交换机级别逻辑模型可以互换使用，以指代如图2D和4B所示的特定于节点的逻辑模型和Li_Model 272。

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

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

策略分析器504可以接收逻辑模型集合502作为输入，逻辑模型集合502可以包括如图4所示的逻辑模型270；如图2D所示的L_Model 270A、LR_Model 270B和/或Li_Model272。策略分析器504也可以接收规则508作为输入。可以针对例如在来自逻辑模型集合502的一个或多个逻辑模型中的每个特征(例如，每个对象、每个对象属性、每个合约、每个规则等)定义规则508。规则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和/或MIM 200生成的树中的每个节点，并在树中的每个节点上应用规则508，以确定是否有任何节点违规(例如，不完整配置、不正确配置、未使用的配置等)。当策略分析器504检测到任何违规时，它可以输出配置违规事件506。

图5B示出了网络模型的示例性等效图510。在该示例中，可以将逻辑模型270与从结构120中的一个或多个叶104获得的Hi_Model 276进行比较。该比较可以提供等效性检查，以确定在控制器116处的网络环境100的逻辑配置是否与在一个或多个叶104上展示的规则(例如，诸如TCAM的存储装置中的规则和/或配置)一致或冲突。为了说明的目的，逻辑模型270和Hi_Model 276被示为在图5B中的等效性检查示例中被比较的模型。但是，应注意，在其他示例中，可以检查其他模型以对那些模型执行等效性检查。例如，等效性检查可以将逻辑模型270与Ci_Model 274和/或Hi_Model 276、将Li_Model 272与Ci_Model 274和/或Hi_Model 276，将Ci_Model 274与Hi_Model 276等进行比较，等等。

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

结构120中的节点可以接收这样的信息并且在节点的软件(例如，操作系统)上展示或编译规则。在节点的软件上展示或编译的规则/配置可以被构造成构造模型(例如，Ci_Model 274)。然后来自构造模型的规则可以从节点的软件被推送到节点的硬件(例如，TCAM)，并在节点的硬件上作为规则存储或展示。存储在或展示在节点的硬件上的规则可被构造成该节点的硬件模型(例如，Hi_Model 276)。

各种模型(例如，逻辑模型270和Hi_Model 276)因此可以表示每个阶段的规则和配置(例如，在(一个或多个)控制器116处的意图规范，在节点的软件上进行展示或编译，在节点的硬件上进行展示或存储，等等)，因为网络运营商输入的定义和配置会贯穿每个阶段而推送。因此，可以使用各种模型的等效性检查，例如逻辑模型270和Hi_Model 276，Li_Model 272和Ci_Model 274或Hi_Model 276，Ci_Model 274和Hi_Model 276等，来确定定义和配置是否在与各种模型相关联的任何阶段已正确推送、展示和/或存储。

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

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

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

结果，可以对逻辑模型270和Hi_Model 276中的数据进行形式化、规范化、绘图、建模、重新格式化、平坦化等操作，以在逻辑模型270和Hi_Model 276之间进行等效性处理。例如，可以使用位向量、布尔函数、ROBDD等对数据进行转换，以对逻辑模型270和Hi_Model276之间的等效性进行数学检查。

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

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

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

作为简化示例，考虑Li_Model 272中优先级排序的规则L1、L2、L3和L4的单调列表，其中L1是最高优先级规则，而L4是最低优先级规则。首先根据规则LI检查给定的分组。如果触发了L1，则根据规则L1中包含的动作来处理分组。否则，然后根据规则L2检查分组。如果触发了L2，则根据规则L2中包含的动作来处理分组。否则，然后根据规则L3检查分组，依此类推，直到分组触发规则或到达规则列表的末尾。

ROBDD生成器526可以针对一个或多个模型的组成规则L1-L4计算一个或多个ROBDD。可以为由规则L1-L4编码的每个动作或可能由规则L1-L4编码的每个动作生成ROBDD，以使这些数量的动作和这些数量的所生成的ROBDD之间存在一一对应的关系。例如，规则L1-L4可用于生成L_Permit_BDD、L-_Permit_Log_BDD、L_Deny_BDD和L_Deny_Log_BDD。

通常，ROBDD生成器526从接收到的规则列表中输入524的最高优先级规则开始计算。继续Li_Model 272中的规则L1-L4的示例，ROBDD生成器526以规则L1开始。根据规则L1指定的动作(例如，Permit、Permit_Log、Deny、Deny_Log)，将规则L1添加到该动作的相应ROBDD中。接下来，规则L2将添加到其指定的动作相应的ROBDD中。在一些示例中，可以使用L2的简化形式，由L1'L2给出，其中LI'表示L1的倒数。然后，对规则L3和L4重复此过程，它们分别具有(L1+L2)'L3和(LI+L2+L3)'L4给出的简化形式。

显然，L_Permit_BDD和每个其他特定于动作的ROBDD对每个组成规则L1、L2、L3、L4尚未被较高优先级规则捕获的部分进行编码。也就是说，L1'L2表述规则L2中与规则L1不重叠的部分，(LI+L2)'L3表述规则L3中与规则L1或L2不重叠的部分，以及(LI+L2+L3)'L4表示规则L4中与规则L1或L2或L3都不重叠的部分。这种简化形式可以独立于重叠或较高优先级规则指定的动作，并且可以基于将导致触发较高优先级规则的条件来计算。

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

在一些示例中，被比较的ROBDD将与同一动作相关联。例如，等效性检查器528可以通过计算L_Permit_BDD和H_Permit_BDD之间的互斥性来检查L_Permit_BDD相对于H_Permit_BDD的形式等效性。更具体地，

(即L_Permit_BDD异或H_Permit_BDD)被计算，尽管应当理解以下描述也适用于其他网络模型(例如，逻辑模型270、L_Model 270A、LR_Model 270B、Li_Model 272、Ci_Model 274、Hi_Model 276等)及其相关联动作(Permit、Permit_Log、Deny、Deny_Log等)。

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

允许冲突ROBDD 600a包括唯一部分602和唯一部分606，唯一部分602表示包括在L_Permit_BDD而不是H_Permit_BDD中的分组配置和网络动作的集合(即，计算为L_Permit_BDD*H_Permit_BDD')，唯一部分606表示包括在H_Permit_BDD而不是L_Permit_BDD中的分组配置和网络动作的集合(即，计算为L_Permit_BDD'*H_Permit_BDD)。注意，无阴影的重叠604不是允许冲突ROBDD 600a的部分。

从概念上讲，图示L_Permit_BDD的完整圆圈(例如，唯一部分602和重叠604)表示完全枚举的一组分组配置，这些分组配置包含在由输入模型Li_Model 272编码的Permit规则中或触发由输入模型Li_Model 272编码的Permit规则。例如，假设Li_Model 272包含以下规则：

L₁：端口＝[l-3]允许

L₂：端口＝4允许

L₃：端口＝[6-8]允许

L₄：端口＝9拒绝，

其中“端口”表述接收到分组的端口编号，然后图示L_Permit_BDD的圆圈包含端口＝[1-3]，4，[6-8]的所有分组的集合。此完整圆圈之外的所有内容表示与Li_Model 272中包含的“允许”规则指定的分组条件和/或动作不同的分组条件和/或动作的空间。例如，规则L4编码端口＝9拒绝，则它将落在L_Permit_BDD划出的区域之外。

类似地，示出H_Permit_BDD的完整圆圈(例如，唯一部分606和重叠604)表示完全枚举的一组分组配置，这些分组配置包含在由输入模型Li_Model 276编码的Permit规则中或触发由输入模型Li_Model 276编码的Permit规则。假设Li_Model 276包含以下规则：

H₁：端口＝[l-3]允许

H₂：端口＝5允许

H₃：端口＝[6-8]拒绝

H₄：端口＝10拒绝_记录

在L_Permit_BDD和H_Permit_BDD之间的比较中，只有规则L1和H1是等效的，因为它们在分组条件和操作上都匹配。L2和H2不等效，因为即使它们指定了相同的动作(允许)，该动作在不同的端口编号上触发(4相对5)。L3和H3不等效，因为即使它们在相同的端口编号(6-8)上触发，它们触发不同的动作(“允许”相对“拒绝”)。L4和H4不等效，因为它们在不同的端口编号上触发(9对10)，并且还触发不同的动作(拒绝对拒绝_记录)。这样，重叠604仅包含由允许规则L1和H1捕获的分组集，即，被允许的端口＝[1-3]的分组。唯一部分602仅包含由允许规则L2和L3捕获的分组集，而唯一部分606仅包含由允许规则H2捕获的分组集。这两个唯一部分编码了Li_Model 272将触发允许的分组条件与Hi_Model 276所展示的硬件将触发的分组条件之间的冲突。因此，正是这两个唯一部分602和606构成了允许冲突ROBDD600a。其余规则L4、H3和H4不是允许规则，因此未在L_Permit_BDD、H_Permit_BDD或允许冲突ROBDD 600a中表示。

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

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

此外，为了在上面的讨论中的清楚起见，允许冲突ROBDD 600a将L_Permit_BDD和H_Permit_BDD描绘为单个实体，而不是说明每个单独规则的效果。因此，图6B和6C展示了描述各个规则的允许冲突ROBDD。图6B示出了在所图示的规则L1、L2、H1和H2的列表之间采取的允许冲突ROBDD 600b。图6C示出了允许冲突ROBDD 600c，其将规则H3添加到允许冲突ROBDD600b。两个图都保持与图6A中介绍的相同的阴影约定，其中给定的冲突ROBDD仅包括所示的阴影区域。

首先转向图6B，图6B示出了在由规则L₁和L₂组成的第二L_Permit_BDD以及由规则H₁和H₂组成的第二H_Permit_BDD上计算的允许冲突ROBDD 600b。如图所示，规则L₁和H₁是相同的，并且彼此完全重叠-这两个规则都由重叠612和重叠613组成。重叠612在规则L₁和H₁之间是共同的，而重叠613在规则L₁、H₁和L₂之间是共同的。为了随后的解释，假设规则L₁和H₁均由“端口＝[l-13]允许”定义。

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

无论原因如何，通过将允许冲突ROBDD 600b构造为

可以检测到此错误，其中此计算的结果由带阴影的唯一部分614指示。该唯一部分614表示包含在L_Permit_BDD中但不包含在H_Permit_BDD中的分组配置和网络动作的集合。具体地，唯一部分614被包含在规则L₂所包含的区域内，但是不包含在规则H₁和H₂所包含的任何区域内，并且具体包括由“端口＝[14，18-20]允许”定义的集合。

要了解如何确定，请记住规则L₂由“端口＝[10-20]允许”表示。规则H₁剔除L₂中由“端口＝[10-13]允许”定义的部分，该部分表示为重叠613。规则H₂剔除由L₂中由“端口＝[15-17]允许”定义的部分，该部分表示为重叠616。这仅将“端口＝[14，18-20]允许”保留为L₂包围的区域的非重叠部分，换句话说，唯一部分614包含允许冲突ROBDD 600b。

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

与之前的情况一样，此错误通过冲突ROBDD 600c的构造检测为

其中此计算的结果由阴影唯一部分624和唯一阴影部分626指示，阴影唯一部分624表示包含在L_Permit_BDD中但不包含在H_Permit_BDD中的分组配置和网络动作的集合，唯一阴影部分626表示包含在H_Permit_BDD中但不包含在L_Permit_BDD中的分组配置和网络动作的集合。具体而言，唯一部分624仅包含在规则L₂中，并且包括由“端口＝[14，18]允许”定义的集合，而唯一部分626仅包含在规则H₃中，并且包括由“端口＝[21-25]允许”定义的集合。因此，允许冲突ROBDD600c包含由“端口＝[14，18，21-25]允许”定义的集合。

上面仅参考了允许冲突ROBDD，但是可以理解，冲突ROBDD是为与给定模型相关联的每个动作生成的。例如，对上述Li_Model 272和Hi_Model 276的完整分析可能需要使用ROBDD生成器526生成八个ROBDD，即L_Permit_BDD、L__Permit_Log_BDD、L_Deny_BDD和L_Deny_Log_BDD、H_Permit_BDD、H_Permit_Log_BDD、H__Deny_BDD，H__Deny_Log_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来代替。根据这些特定于动作的冲突ROBDD，等效性检查器528可以确定输入之间不存在冲突--即，给定的特定于动作的冲突ROBDD为空。在图6A-6C的示例的上下文中，空冲突ROBDD将对应于不存在阴影部分。在针对给定的特定于动作的冲突ROBDD做出此确定的情况下，等效性检查器528可以生成相应的特定于动作的“通过”指示530，该指示可以从形式分析引擎522外部传送。

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

在接收到一个或多个特定于动作的冲突ROBDD的情况下，冲突规则标识符534也可以接收在每个冲突ROBDD 532中表示的优先级顺序规则的单调列表作为输入。例如，如果冲突规则标识符534接收到与

相对应的允许冲突ROBDD，则也将用于生成L_Permi_tBDD和H_Permit_BDD的优先级排序的规则Li、Hi的基础单调列表接收作为输入。

然后，冲突规则标识符534从优先排序的规则的每个列表中识别特定的冲突规则，并建立冲突规则的列表536。为了做到这一点，冲突规则标识符534遍历给定列表中包含的规则，并计算每个给定规则所包含的分组配置和网络动作集合与特定于动作的冲突ROBDD所包含的集合之间的交集。例如，假设使用j个规则的列表来生成L_Permit_BDD。对于每个规则j，冲突规则标识符534计算：

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

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

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

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

同样的计算形式也可以应用于用于生成H_Permit_BDD的规则H₁、H₂、H₃的列表。可以计算出：

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

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

这意味着规则H₂在重叠部分626与允许冲突ROBDD 600c确实重叠，因此是冲突规则，可以将其添加到冲突规则列表552中。在本示例的上下文中，从允许冲突ROBDD 600c派生的冲突规则536的完整列表为{L₂，H₃}，因为这些规则中的一个或两个已被错误地配置或展示。

在一些示例中，与输入524相关联的模型之一可以被视为参考或标准，这意味着该模型内包含的规则被假定为正确的。这样，冲突规则标识符536仅需要从非参考模型计算给定的特定于动作的冲突ROBDD与相关联的特定于动作的规则的集合的交集。例如，Li_Model272可以被视为参考或标准，因为它直接来自用于定义L_Model 270A,270B的用户输入。另一方面，Hi_Model 276在展示到节点的硬件之前会经过几次转换，因此很可能会出错。因此，冲突规则标识符534将仅计算

对于Hi_Model 276中的每个规则(或每个允许规则)j，可以显着减少所需的计算时间。

另外，冲突规则标识符534不需要计算特定于动作的冲突ROBDD和每个规则的整体的交集，而是可以使用每个规则的优先级降低的形式。换句话说，这是规则在ROBDD中被表示的形式。例如，规则H₂的优先级降低形式是H₁'H₂，或者规则H₂的贡献减去规则H₁已经捕获的部分。规则H3的优先级降低形式为(H₁+H₂)'H₃，或规则H₃的贡献减去规则H₁或H2已捕获的部分。规则H4的优先级降低形式为(H₁+H₂+H₃)'H₄，或规则H4的贡献减去规则H₁和H₂和H₃已捕获的部分。

因此，对于Hi_Model 276中包含的每个规则(或每个允许规则)j，计算进而减少为：

尽管与简单计算相比，上面的公式中引入了其他项，降低优先级形式实际上在计算上更高效。对于每个规则j，优先级降低形式(H1+...+H_j-1)'H_j与非降低形式H_j相比，包含了更小的分组配置和网络动作集合，或者包含了大小相等的集合。用于针对冲突ROBDD进行交集计算的集合越小，计算效率越高。

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

在一些示例中，可以在冲突规则标识符534与外部输出之间布置返回注释器538。返回注释器538可以将冲突规则列表536中的每个给定规则与导致生成给定规则的特定父合约或其他高级意图相关联。以这种方式，不仅根据冲突的特定规则向用户解释了形式上的等效性失败，而且还根据被输入到网络并最终创建了冲突规则的高级用户动作、配置或意图向用户解释了等效性失败。以这种方式，用户可以通过将冲突规则在源或父源处进行调节或作为目标来更有效地解决冲突规则。

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

现在，本公开转向图7A和图7B，图7A和图7B示出了示例方法。图7A示出了用于网络保障的示例方法。图7B示出了用于在网络中生成全网络逻辑模型的示例方法。该方法以示例的方式提供，因为存在多种执行该方法的方式。另外，尽管以框或步骤的特定顺序示出了示例性方法，但是本领域普通技术人员将理解图7A-B及其中的各框可以以任何顺序执行，并且可以包括比所示的更少或更多的框。

图7A-图7B中所示的每个框表示方法中的一个或多个步骤、处理、方法或例程。为了清楚和说明的目的，图7A-图7B中的框参考如图1A-图1B、图2D、图3A、图4A-图4C、图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示出了用于生成网络的全网络逻辑模型的示例方法。在某些情况下，图7B中的方法可以与图7A中的方法分开地或附加地执行。然而，在其他情况下，图7B中的方法可以是图7A中的保障方法的一部分。例如，图7B中的方法可以表示图7A的方法中的一个或多个步骤或图7A中的方法特定应用。为了说明，图7A中的方法可以表示可以分析网络的不同类型的配置或方面的一般保障方法的示例，而图7B中的方法可以表示用于构造在图7A的方法中使用的特定全网络逻辑模型的方法的示例。

在步骤720，保障设备系统300可以从软件定义的网络(例如，网络环境100)中的多个控制器(例如，控制器116)获得与软件定义网络(SDN)相关联的各个逻辑模型段(例如，图4B所示的逻辑模型段412、414、416)。各个逻辑模型段中的每个可以包括SDN网络的多个控制器中的相应控制器处的配置。此外，各个逻辑模型段可以基于为SDN网络定义可管理对象和对象属性的模式，例如MIM 200。在某些情况下，各个逻辑模型段可以包括多个控制器处的全部各个逻辑模型。在其他情况下，各个逻辑模型段可以包括在多个控制器处的各个逻辑模型的相应部分。

各个逻辑模型段可以捕获为SDN网络指定的配置的不同段，其可以被包括在多个控制器处的各个逻辑模型中。由各个逻辑模型段中的每个捕获的配置的特定段可以对应于SDN网络的与特定段相关联的一个或多个对象、配置或方面。例如，各个逻辑模型段可以捕获SDN网络中不同租户的配置和数据、SDN网络中的上下文(例如VRF)、SDN网络中的EPG、SDN网络中的应用配置文件、SDN网络中的桥接域、域、等等。例如，可以通过用租户、EPG、VRF等对存储在多个控制器上的SDN网络的逻辑模型进行分段来生成各个逻辑模型段。可以为每个控制器分配SDN网络的特定方面，以为该控制器生成相应的逻辑模型段。例如，可以为每个控制器分配一个特定的租户。然后，每个控制器都可以根据分配的租户细分各自的逻辑模型。例如，每个控制器可以从其各自的逻辑模型配置、数据等中提取对应于其分配的租户的信息。提取的信息可以表示该控制器的相应逻辑模型段。

在步骤722，保障设备系统300可以确定多个控制器是否处于法定数量。例如，保障设备系统300可以确定多个控制器是否满足满足法定数量规则所需的阈值数量或比率。保障设备系统300还可以验证每个控制器的状态是否满足在法定数量中对控制器进行计数所必需的控制器状态。例如，在某些情况下，只有控制器是活动的、可达的、与保障设备系统300相兼容和/或是与SDN网络关联的软件、正在运行特定软件和/或硬件版本等，才仅出于确定法定数量的目的才对控制器进行计数。在某些情况下，没有特定状态或特征(例如，可达性、兼容性、版本等)的控制器可能不包含在法定数量中或不计入法定数量中。可能不会向此类控制器轮询逻辑模型段，或者可能不会在构造SDN网络的逻辑模型时使用其数据。

当多个控制器处于法定数量时，在步骤724，保障设备系统300可以组合各个逻辑模型段以产生SDN网络的全网络逻辑模型(例如，逻辑模型270)。全网络逻辑模型可包括跨多个SDN网络控制器的配置。例如，全网络逻辑模型可以包括至少阈值数量的各个逻辑模型段和/或包括在法定数量所必需的至少阈值数量的控制器中的数据的组合。

在某些情况下，全网络逻辑模型可以合并运行时状态或数据。例如，保障设备系统300可以从SDN网络的结构中的多个控制器和/或节点收集运行时状态或数据，并将运行时状态或数据合并到全网络逻辑模型中以产生网络的运行时逻辑模型，例如LR_Model 270B。在某些情况下，多个控制器可以将在多个控制器处收集或存储的数据或运行时状态连同相应的逻辑模型段一起发送到保障设备系统300，或者将运行时状态或数据包括在相应的逻辑模型段中。因此，由保障设备系统300构造的全网络逻辑模型可以包括这种运行时间状态或数据。

现在，本公开转向图8和9，图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 BUS、LoRA等。通常，这些接口可以包括适合与适当的媒介进行通信的端口。在某些情况下，它们还可以包括独立的处理器，在某些情况下还包括易失性RAM。独立处理器可以控制诸如分组交换、媒体控制、信号处理、密码处理和管理之类的通信密集型任务。通过为通信密集型任务提供单独的处理器，这些接口允许主微处理器804有效地执行路由计算、网络诊断、安全功能等。

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

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

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

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

Claims (23)

1.一种方法，包括：

识别网络中的多个控制器；

从所述多个控制器的至少部分中获得与所述网络相关联的各个逻辑模型段，所述各个逻辑模型段中的每个逻辑模型段包括所述多个控制器中的相应控制器处的针对所述网络的配置，所述各个逻辑模型段基于模式，所述模式定义所述网络的可管理对象和对象属性；以及

组合与所述网络相关联的所述各个逻辑模型段，以产生所述网络的全网络逻辑模型，所述全网络逻辑模型包括跨所述多个控制器的针对所述网络的配置。

2.根据权利要求1所述的方法，还包括：确定所述多个控制器的所述部分是否形成法定数量，其中，组合所述各个逻辑模型段是基于对所述多个控制器的所述部分形成所述法定数量进行的确定。

3.根据权利要求1或2所述的方法，还包括：

收集所述网络的运行时状态数据；以及

将所述运行时状态数据合并到所述全网络逻辑模型中。

4.根据权利要求1至3中任一项所述的方法，其中，所述各个逻辑模型段包括所述多个控制器中的各个控制器处的相应逻辑模型的段。

5.根据权利要求4所述的方法，其中，所述各个逻辑模型段对应于在相应逻辑模型中针对所述网络配置的一个或多个相应对象或属性。

6.根据权利要求5所述的方法，其中，所述网络包括软件定义的网络，其中，针对所述软件定义的网络配置的所述一个或多个相应对象或属性包括以下至少一者：相应租户、相应端点组、和相应网络上下文。

7.根据权利要求1至6中任一项所述的方法，还包括：当所述多个控制器中阈值数目个控制器具有预定状态时，确定所述多个控制器的所述部分包括法定数量，所述预定状态包括可达性状态、激活/非激活状态、软件兼容性状态、和硬件兼容性状态中的至少一者，并且其中，组合所述各个逻辑模型段是基于确定所述多个控制器的所述部分包括所述法定数量的。

8.根据权利要求7所述的方法，其中，从所述多个控制器的至少部分获得所述各个逻辑模型段包括：向所述多个控制器轮询所述各个逻辑模型段以及与所述多个控制器相关联的相应当前状态，并且其中，确定所述多个控制器的所述部分是否包括所述法定数量包括：将相应当前状态与所述预定状态进行比较。

9.根据权利要求1至8中任一项所述的方法，其中，所述可管理对象包括合约、租户、端点组、上下文、主题和过滤器中的至少一者，并且其中，所述模式包括分层管理信息树。

10.一种系统，包括：

一个或多个处理器；以及

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

从所述多个控制器的至少部分中获得与所述网络相关联的各个逻辑模型段，所述各个逻辑模型段中的每个逻辑模型段包括所述多个控制器中的相应控制器处的针对所述网络的配置，所述各个逻辑模型段基于模式，所述模式定义所述网络的可管理对象和对象属性；以及

组合与所述网络相关联的所述各个逻辑模型段，以产生所述网络的全网络逻辑模型，所述全网络逻辑模型包括所述多个控制器处针对所述网络而定义的配置。

11.根据权利要求10所述的系统，其中，所述多个控制器中的各控制器处的所述配置是通过合约来定义的。

12.根据权利要求10或11所述的系统，所述至少一个计算机可读存储介质存储有附加指令，所述附加指令在由所述一个或多个处理器执行时使所述系统执行以下操作：

收集所述网络的运行时状态数据；以及

将所述运行时状态数据合并到所述全网络逻辑模型中。

13.根据权利要求10至12中任一项所述的系统，其中，所述各个逻辑模型段包括所述多个控制器中的各个控制器处的相应逻辑模型的段。

14.根据权利要求13所述的系统，其中，所述各个逻辑模型段对应于针对所述网络配置的一个或多个相应对象或属性。

15.根据权利要求14所述的系统，其中，所述网络包括软件定义的网络，其中，针对所述软件定义的网络配置的所述一个或多个相应对象或属性包括以下至少一者：相应租户、相应端点组、和相应网络上下文。

16.根据权利要求10至15中任一项所述的系统，所述至少一个计算机可读存储介质存储有附加指令，所述附加指令在由所述一个或多个处理器执行时使所述系统执行以下操作：

当所述多个控制器中阈值数量个控制器具有预定状态时，确定所述多个控制器的所述部分包括法定数量，所述预定状态包括可达性状态、激活/非激活状态、软件兼容性状态、和硬件兼容性状态中的至少一者，并且其中，组合所述各个逻辑模型段是基于确定所述多个控制器的所述部分包括所述法定数量的。

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

存储在所述非暂态计算机可读存储介质中的指令，所述指令在由一个或多个处理器执行时使所述一个或多个处理器执行以下操作：

从网络中的多个控制器获得与所述网络相关联的各个逻辑模型段，所述各个逻辑模型段中的每个逻辑模型段包括所述多个控制器中的相应控制器处的针对所述网络的配置，所述各个逻辑模型段基于模式，所述模式定义所述网络的可管理对象和对象属性；

确定所述多个控制器是否包括法定数量；以及

当所述多个控制器包括所述法定数量时，组合与所述网络相关联的所述各个逻辑模型段，以产生所述网络的全网络逻辑模型，所述全网络逻辑模型包括跨所述多个控制器的针对所述网络的配置。

18.根据权利要求17所述的非暂态计算机可读存储介质，其中，所述网络包括软件定义的网络，所述多个控制器中的各个控制器处的所述配置是通过合约定义的，其中，所述可管理对象包括合约、租户、端点组、上下文、主题和过滤器中的至少一者，并且其中，所述模式包括分层管理信息树。

19.根据权利要求17或18所述的非暂态计算机可读存储介质，其中，所述非暂态计算机可读存储介质存储有附加指令，所述附加指令在由所述一个或多个处理器执行时使所述系统执行以下操作：

收集所述网络的运行时状态数据；以及

将所述运行时状态数据合并到所述全网络逻辑模型中。

20.根据权利要求17至19中任一项所述的非暂态计算机可读存储介质，其中，所述各个逻辑模型段包括所述多个控制器处的相应逻辑模型的段，其中，所述各个逻辑模型段对应于针对所述网络配置的一个或多个相应对象或属性，所述一个或多个对象或属性包括以下至少一者：相应租户、相应端点组、和相应网络上下文。

21.一种设备，包括：

用于识别网络中的多个控制器的装置；

用于从所述多个控制器的至少部分中获得与所述网络相关联的各个逻辑模型段的装置，所述各个逻辑模型段中的每个逻辑模型段包括所述多个控制器中的相应控制器处的针对所述网络的配置，所述各个逻辑模型段基于模式，所述模式定义所述网络的可管理对象和对象属性；以及

用于组合与所述网络相关联的所述各个逻辑模型段以产生所述网络的全网络逻辑模型的装置，所述全网络逻辑模型包括跨所述多个控制器的针对所述网络的配置。

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

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

Images