CN110741603A

CN110741603A - 拓扑探测器

Info

Publication number: CN110741603A
Application number: CN201880039227.3A
Authority: CN
Inventors: 迪吉约特·塞西; 钱德拉·那加拉甘; 拉马纳·拉奥·孔佩拉; 高拉夫·古普塔; 桑德·伊耶
Original assignee: Cisco Technology Inc
Current assignee: Cisco Technology Inc
Priority date: 2017-06-16
Filing date: 2018-06-15
Publication date: 2020-01-31
Anticipated expiration: 2038-06-15
Also published as: WO2018232223A1; EP3639478A1; US11463316B2; EP4224811A2; US20200099589A1; EP4224811A3; US10498608B2; CN110741603B; EP3639478B1; US20180367412A1

Abstract

用于发现网络的拓扑和健康情况的系统、方法和计算机可读介质。在一些示例中，系统可以从网络上的多个控制器中的至少一个控制器获得网络的逻辑模型，该逻辑模型包括针对网络定义的一个或多个对象的配置。基于逻辑模型，系统可以识别网络中的多个控制器以及网络的结构中的多个节点的相应位置。基于该多个控制器和多个节点的相应位置，系统可以针对相应的状况信息来轮询该多个控制器和多个节点，并基于逻辑模型、相应位置、以及相应的状况信息来确定网络的健康情况和拓扑。

Description

拓扑探测器

相关申请的交叉引用

本申请要求于2017年6月16日递交的题为“TOPOLOGY EXPLORER(拓扑探测器)”的美国临时专利申请第62/520,700号；以及于2017年10月23日递交的题为“TOPOLOGYEXPLORER(拓扑探测器)”的美国非临时专利申请第15/790,577号的权益和优先权。通过引用将这两个申请中的每一者的全部内容明确地合并于此。

技术领域

本技术涉及网络配置和故障排除，更具体地，涉及网络中的网络建模和拓扑发现。

背景技术

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

附图说明

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

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

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

图2B示出了图2A的示例对象模型中的租户对象(tenant object)的示例对象模型；

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

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

图3A示出了示例保证设备(assurance appliance)系统；

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

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

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

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

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

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

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

图6A示出了第一示例冲突精简的有序二元决策图(ROBDD)；

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

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

图7A示出了导致网络上的安全问题的示例网络健康情况；

图7B示出了用于从图7A中的网络健康情况和网络中发现网络拓扑和安全问题的示例系统；

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

图8B示出了用于发现网络的拓扑和健康情况的示例方法；

图9示出了示例计算设备；以及

图10示出了示例网络设备。

具体实施方式

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

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

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

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

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

概述

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

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

在许多情况下，网络中的各种节点和/或控制器可以包含网络和网络状态的相应信息或表示。例如，不同的控制器可以存储网络的不同逻辑模型，并且网络结构中的每个节点可以包含其自己的网络配置模型。本文阐述的方法可以针对网络中的各种控制器和节点执行数据收集和分析，以获得网络和设备模型，并基于网络和设备模型执行网络保证检查。这些建模方法可以提供对网络的重要的洞察力、远见和可见性。本文阐述的方法还可以提供用于在数据收集和分析期间处理故障场景的策略，包括控制器和节点故障场景。例如，本文的方法可以在数据收集和/或分析期间检测故障场景，并且提供对故障场景的可动作事件或响应。

本文公开了用于发现网络上的拓扑和健康信息的拓扑探测器的系统、方法和计算机可读介质。在一些示例中，诸如拓扑探测器之类的系统可以从网络上的一个或多个控制器获得网络(例如，软件定义网络)的逻辑模型。逻辑模型可以包括针对网络定义的对象的配置，例如，契约、租户、端点组、策略(例如，安全策略、过滤器等)、联网配置(例如，路由和/或转发配置、优先级、端口配置、接口配置等)、规则、应用简档、桥接域、网络情境(例如，虚拟路由和转发实例)、网络元件(例如，服务器、交换机、控制器等)、对象属性(例如，权限、对象名称、网络地址、组成员、对象类型等)、访问控制列表等。

基于逻辑模型，系统可以识别网络中的多个控制器和网络结构中的多个节点的相应位置。相应位置可以包括例如网络地址(例如，IP地址)、网络名称(例如，完全合格的域名、主机名、可辨别名称等)、网络情境、子网、虚拟局域网、网段、虚拟或覆盖网络等。基于多个控制器和多个节点的相应位置，系统可以轮询多个控制器和多个节点以获得相应的状况信息。相应的状况信息可以包括例如可达性状况、状态(例如，活动、不活动、发现、未知、禁用、故障、不可用等)、配置(例如，兼容性、软件版本、硬件版本、设备设置、存储的偏好、登录凭据、呈现的规则、网络设置等)、注册(例如，已注册、未注册等)、安全状况(例如，登录失败、不受保护的状况等)等。

然后，系统可以基于逻辑模型(例如，逻辑模型中的配置、对象和/或数据)、多个控制器和节点的相应位置、以及多个控制器和节点的相应状况信息来确定网络的健康情况和拓扑。例如，系统可以确定：每个控制器和节点的标识、每个控制器和节点的网络地址、与每个控制器或节点相关联的网段、一个或多个控制器或节点的相对位置、与控制器集群相关联的规定数量或多数状况、网络中的安全问题、网络分区、一个或多个控制器或节点的不可达状况、配置错误等。

示例实施例

所公开的技术解决了本领域中对于高效和主动发现和理解网络的拓扑、配置和健康情况以用于网络预见和保证的需求。本技术涉及用于主动发现网络的拓扑和健康情况的拓扑探测器机制的系统、方法和计算机可读介质。本技术将在以下公开内容中描述如下。本讨论开始于对网络保证的介绍性讨论，包括网络探测，以及对示例计算环境的描述，如图1A和图1B所示。然后将是对用于网络保证的网络模型的讨论，如图2A到2D所示，以及对网络建模、保证和错误处理的讨论，如图3A-C、4A-C、5A-C、6A-C、7A-B、和图8A-B所示。本讨论以对示例计算和网络设备(如图9和图10所示)的描述结束，包括适合于托管软件应用和执行计算操作的示例硬件组件。

本公开现在转到对网络保证和拓扑探测的介绍性讨论。

网络保证是确保或确定网络按照网络运营商的意图行事并且已经被恰当配置(例如，网络正在做预期它要做的事情)。意图可以包含各种网络操作，例如，桥接、路由、安全性、服务链化(service chaining)、端点、合规性、QoS(服务质量)、审计等。意图可以体现在针对网络和各个网络元件(例如，交换机、路由器、应用、资源等)定义的一个或多个策略、设置、配置等中。然而，经常地，网络运营商所定义的配置、策略等是不正确的或者未能准确地反映在网络的实际行为中。例如，网络运营商针对一种或多种类型的流量指定配置A，但后来发现网络实际上正在将配置B应用于该流量或以与配置A不一致的方式处理该流量。作为另一示例，网络运营商将安全策略C实现为由某些网络元件针对特定类别的流量来实施，但是后来发现一个或多个网络元件在处理与安全策略C相关联的特定类别的流量时未实施该安全策略。这些问题可能有多种原因，例如，硬件错误、软件错误、优先级或配置冲突、网络或设备配置错误、连接问题、设备的不正确规则呈现、意外的错误或事件、软件升级、配置更改、故障、网络分区等。

本文中的方法可以收集网络周围的数据，构建网络模型，并基于网络模型和所收集的数据主动发现网络的拓扑和健康情况。本文的方法可以执行拓扑探测和网络保证来作为预见分析的一部分，以发现网络信息并在由错误引起的故障之前防止此类错误。拓扑探测和预见分析可以在不分析实际流量流的情况下执行，并用于在所导致的网络故障之前主动识别网络健康问题。可以在各种类型的网络中实现拓扑探测和预见分析，所述各种类型的网络包括：私有网络，例如局域网(LAN)；企业网络；独立的或传统的网络，例如传统数据中心网络；具有物理层或底层以及逻辑层或覆盖层的虚拟网络，例如VXLAN或软件定义网络(SDN)(例如，以应用为中心的基础设施(ACI)或VMware NSX网络)、网络功能虚拟化(NFV)平台；等等。

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

可以实现这种模型以确定关于网络的信息，并确保网络的行为将与通过由网络运营商实现的具体配置(例如，策略、设置、定义等)所反映的预期行为一致(或保持一致)。与涉及发送和分析数据分组并观察网络行为的传统网络监视不同，可以通过建模来执行本文的拓扑探测和网络保证，而不必摄取分组数据或监视流量和网络行为。这可产生先见之明、洞悉、和后见之明：可以在问题发生之前加以预防，在发生问题时识别问题，并在问题发生后立即修复问题。

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

建模可能消耗对应于网络的大量行为方面的多种类型的智能事件。智能事件可能影响网络的各个方面，例如底层服务、覆盖服务、租户连通性、租户安全性、租户端点(EP)移动性、租户策略、租户路由、资源等。可以收集和分析来自网络模型中的节点的数据以及网络模型中的信息以预测网络配置和状况，例如，网络的拓扑和健康情况。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

如本文所使用的，术语“别名化(aliasing)”可以指代与一个或多个其他规则重叠的规则(例如，契约、策略、配置等)。例如，如果在网络的逻辑模型中定义的契约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或防火墙规则。在一些示例中，过滤器可以在分组(例如，TCP/IP)头部字段中实现，例如，L3协议类型、L4(第4层)端口等，其例如用于允许端点或EPG之间的入站或出站通信。

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

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

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

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

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

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

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

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

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

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

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

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

控制器116

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

节点204

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

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

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

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

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

节点206

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

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

节点208

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

节点210

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

节点212

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

模型270A、270B、272、274、276可以提供网络的各个方面或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_模型270A可以是存在于LR_模型270B中的内容的高级表述，其应当在具体设备上被呈现为Ci_模型274和Hi_模型276表述。如果模型之间存在任何间隙，则可能存在不一致的配置或问题。

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

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

保证设备系统300可以包括数据框架308，其可以基于例如APACHE APEX和HADOOP。在一些情况下，保证检查可以被编写为驻留在数据框架308中的个体操作器(operator)。这允许实现本地水平扩展架构，其能够扩展到结构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_模型270A的配置或规范(包括例如安全性策略和客户配置的契约)被正确地实现和/或呈现在Li_模型272、Ci_模型274和Hi_模型276中并且因此由结构成员(例如，叶节点104)适当地实现和呈现，并且报告任何发现的错误、契约违反或不规则。

静态策略分析

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

TCAM利用率

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

端点检查

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

租户路由检查

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

基础设施路由

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

MP-BGP路由反射检查

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

逻辑线头和实时变化分析

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

图3B示出了用于网络保证的示例系统350(例如，保证设备系统300)的架构图。系统350可以包括操作器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中的一个或多个。

在该示例中，拓扑探测器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通过分片(sharding)和/或负载平衡来针对拓扑结构(例如，包括脊节点102、叶节点104、控制器116等的结构120)中的每个节点分布收集数据的任务，以及将收集任务和/或节点映射到统一收集器314的特定实例，其中跨越节点的数据收集由统一收集器314的各个实例并行执行。在给定节点内，可以串行地执行命令和数据收集。保证设备系统300可以控制统一收集器314的每个实例用于从结构120轮询数据的线程的数量。

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

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

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

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

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

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

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

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

保证设备系统300可以联系控制器116、脊节点102、叶节点104和其他节点以(例如，经由统一收集器314)收集各种类型的数据。在一些场景中，保证设备系统300或统一收集器314可能经历故障(例如，连通性问题、硬件或软件错误等)，这使其在一段时间内无法收集数据。此类故障可能源自保证设备系统300中的一个或多个组件(例如，统一收集器314)和/或网络环境100或结构120中的其他组件，例如，结构120中的一个或多个节点(例如，控制器116、叶节点104、脊节点102等)。保证设备系统300和/或统一收集器314可以无缝地处理此类故障，并基于此类故障生成事件或响应。

例如，如果统一收集器314不能从一个或多个节点收集信息(例如，由于网络、硬件或软件故障)，则统一收集器314可以触发事件或响应以解决检测到的故障。因此，尽管数据收集可以由统一收集器314自动执行，但统一收集器314可以在数据收集不可能或将导致不完整记录时生成警报，以避免或限制由于数据收集不完整而可能导致错误的情况，并实现更快的解决方案。这样的故障处理过程还可以提供保护层，以防止浪费的计算工作。

如上所述，统一收集器314可以在发生或检测到故障情况时生成警报或事件。然而，在一些情况下，警报或事件可以由单独的事件服务(Event Service)(未示出)、由统一收集器314、和/或两者生成。例如，统一收集器314可以与事件服务进行通信以向事件服务通知收集状况、情况、故障等，和/或向事件服务报告已经收集了什么数据。这可以允许事件服务确定何时发生故障以生成警报或事件。事件服务可以由一个或多个操作器、应用、服务器、设备、功能(例如，服务功能链)、VM、模块等实现。然而，在一些示例中，事件服务可以通过统一收集器314中的一个或多个组件来实现。因此，在一些情况下，事件服务可以是统一收集器314的一部分。

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

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

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

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

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

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

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

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

保证设备故障处理和设备遥测

如前所述，保证设备系统300具有可能经历故障的各种域，包括上层和下层(SouthTier)。可以将保证设备系统300配置为针对这些域中的每一个来检测并响应各种类型的故障。

例如，上层可以通过例如API和UI为上行消费提供消费层。上层可以包括例如Web层、App层、和DB层。

下层可以包括数据收集和数据分析层。下层可以涉及下层基础设施(SouthInfra)和下层应用(South Application)。可能在下层基础设施或各个操作器或基本OS中经历故障。

基本OS可以基于实现方式而有所不同。基本OS上值得关注的故障可以包括但不限于：CPU、存储器、磁盘卷、磁盘I/O和网络I/O的资源耗尽、进程崩溃和重新启动、OS崩溃和重新启动、网络连接故障和存储故障。下面的示例表说明了各个层处的示例故障和故障响应。

表1：故障和故障处理-上层

表2：故障和故障处理-下层

表3：针对基本OS的设备遥测

收集与分析

保证设备系统300可以实施用于收集和分析以及故障处理的规则。以下是用于收集、分析和故障处理的规则和条件的示例，以及对故障处理场景的描述。本文还考虑其他配置。

规则1：仅从占大多数并且具有相同的软件版本(该软件版本是保证设备系统300所支持的软件版本)的控制器中收集逻辑模型(例如，L_模型270)。

规则2：根据所收集的逻辑模型，创建已被注册(节点ID不为零)并且处于活动或不活动状态的所有节点的列表。处于禁用(DISABLED)、发现(DISCOVERING)、未发现(UNDISCOVERED)或未知(UNKNOWN)状态的任何节点都从该列表中排除。

规则3：分析来自规则2的节点列表中具有保证设备系统300所支持的软件的每个节点。具有不受支持的软件的节点从分析中排除。

规则4：对于具有受支持的软件、以及至少部分地由与保证设备系统300相关联的一组检查器支持的硬件的每个节点，根据逻辑模型构造相应的Ci_模型274，并根据相应的Ci_模型274构造相应的Hi_模型276。换句话说，对于具有受支持的软件和至少部分地受支持的硬件的节点，将逻辑模型转换为具体模型，并将具体模型转换为硬件模型。

规则5：对于具有受支持的软件但其硬件不被该组检查器支持的每个节点，根据逻辑模型构造相应的Ci_模型274，但不根据相应的Ci_模型274构造相应的Hi_模型276。检查器还可以为具有不受支持的硬件的那些节点生成事件或警报。

故障处理

保证设备系统300还可以实施用于故障处理的规则。故障处理可以基于网络中的各种元件的状况，包括控制器状况，从控制器角度的节点状况、从保证设备系统300角度的节点状况等。下面是对示例状况条件，以及用于故障处理的一组示例规则的描述。本文还考虑其他规则和状态。

控制器状况：

如果控制器不可达或可达控制器不是多数部分的一部分，则可以停止分析(例如，DAG分析)并生成事件或警报(例如，严重事件/警报(紧急))。

如果控制器可达但被划分为没有多数部分，则可以停止分析(例如，DAG分析)并生成事件或警报(例如，严重事件/警报(紧急))。

如果控制器版本不受支持但节点的软件受支持，则可以停止分析(例如，DAG分析)并生成事件或警报(例如，严重事件/警报(紧急))。

如果一组控制器可达并且占多数，但一些控制器具有不受支持的软件版本且其他控制器具有受支持的软件版本，则控制器可以以参与多数部分的控制器的最低软件版本运行。系统可能无法运行分析(例如，DAG分析)，并且可能要等到所有控制器具有相同的软件版本并且该版本受支持。

如果可达控制器占多数并且具有系统所支持的混合软件版本，则系统可能无法运行分析(例如，DAG分析)。系统可以针对不支持的每种情况引发事件或警报，并且操作器(例如，操作器310)可以继续以分析间隔运行。

从控制器角度的节点状况：

保证设备系统300可能无法从状况为禁用、未发现/发现、不支持、或未知的节点收集数据。在这些情况下，保证设备系统300可以根据间隔(例如，纪元)生成INFO事件，其指示处于禁用、未发现/发现、不支持、或未知状态并且将不被包括在数据收集中的已注册节点的列表。

保证设备系统300可以从以其他方式具有不活动或活动状况的节点收集数据。

从保证设备角度的节点状况：

保证设备系统300可能无法到达一个或多个节点(例如，脊节点102和叶节点104)。如果一个或多个节点不可达，则检查器可以抑制误报，并且事件或警报可以针对不可达的节点被引发，该事件或警报指示由于这些节点不可达而无法针对这些节点完成分析。基础设施路由可以生成部分信息，因为它仍然准确。

在一些情况下，一个或多个节点可以由保证设备系统300到达，但不能由占多数的控制器到达(例如，这样的网络分区，其中某些节点只能到达不是控制器多数部分的一部分的控制器，但这些节点可以由保证设备系统300到达)。可以从分析中排除具有此状况的节点，但在其他情况下，可以根据一个或多个因素(例如，连接历史)来包括这些节点。可以针对处于这种状况的节点生成事件或警报，以指示这些节点不能由占多数的控制器到达，但可以以其他方式由保证设备系统300和/或其他(一个或多个)控制器到达。

一个或多个节点可能具有不受保证设备系统300支持的软件或硬件。如先前指示并在下表5中进一步指出的，可以针对具有该状况的节点定义用于收集的规则。

一个或多个节点可能具有不能由保证设备系统300中的一个或多个检查器或操作器解析的数据。在其中从一个或多个检查器的角度来看在解析方面存在部分故障的情况下，可以解析数据的检查器可以执行检查。在其中从一个或多个检查器的角度来看在解析方面存在完全故障的情况下，检查器可以引发指示解析失败的事件或警报。在一些情况下，检查器可以针对每个结构生成单个微事件或警报，或单个策展(curated)事件。

节点(例如，脊节点和叶节点)之间可能存在单个或多个链路故障。这可以被反映为IS-IS RIB条目删除。

下表5示出了关于收集和分析以及故障处理事件的示例规则。

表5：用于收集和分析的示例规则

保证设备系统300和/或其操作器(例如，统一收集器314)可以解决各种类型的故障并处理各种警报或响应。收集和分析规则、故障场景和响应的非限制性示例在下表6中说明。

表6：示例故障和响应

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

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

在一些情况下，可以通过针对各个逻辑模型和/或存储的配置轮询控制器来从多个控制器获得逻辑模型270-1至270-N。例如，保证设备系统300可以轮询控制器116并从控制器116提取逻辑模型和/或配置。保证设备系统300可以经由诸如统一收集器314之类的一个或多个引擎或操作器(例如，操作器310)来从控制器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-1至270-N来生成逻辑模型270。例如，可以通过比较逻辑模型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的另一示例方法。在该示例中，根据从网络(例如，网络环境100)上的控制器116-1至116-N获得的逻辑模型分段412、414、416来生成逻辑模型270。例如，保证设备系统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。因此，保证设备系统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至116-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针对逻辑模型分段412、414、416和/或其他信息(例如运行时数据、健康情况数据、状况数据(例如，连通性、状态等)、所存储的数据、更新等)来轮询控制器116-1至116-N。

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

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

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

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

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

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

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

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

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

策略分析器504可以接收逻辑模型集合502作为输入，该逻辑模型集合502可以包括如图4所示的逻辑模型270；和/或如图2D所示的L_模型270A、LR_模型270B、和/或Li_模型272。策略分析器504也可以接收规则508作为输入。可以为例如来自逻辑模型集合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_模型276进行比较。该比较可以提供对等性检查，以便确定(一个或多个)控制器116处的网络环境100的逻辑配置与在一个或多个叶节点104上呈现的规则(例如，存储装置(例如TCAM)中的规则和/或配置)一致还是冲突。为了说明的目的，逻辑模型270和Hi_模型276被示为在图5B中的对等性检查示例中被比较的模型。然而，应注意，在其他示例中，可以检查其他模型以针对那些模型执行对等性检查。例如，对等性检查可以比较逻辑模型270与Ci_模型274和/或Hi_模型276、Li_模型272与Ci_模型274和/或Hi_模型276、Ci_模型274与Hi_模型276等。

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

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

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

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

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

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

因此，可以对逻辑模型270和Hi_模型276中的数据进行标准化、规范化、绘制、建模、重新格式化、扁平化等操作，以在逻辑模型270和Hi_模型276之间执行对等性。例如，可以使用位向量、布尔函数、ROBDD等对数据进行转换，以对逻辑模型270和Hi_模型276之间的对等性进行数学检查。

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

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

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

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

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

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

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

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

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

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

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

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

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

L2：端口＝4允许

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

L4：端口＝9拒绝

其中，“端口”表示接收分组的端口号，则示出L_允许_BDD的圆圈包含其中端口＝[1-3]、4、[6-8]的被允许的该组所有分组。该完整圆圈之外的所有内容表示与由包含在Li_模型272中的允许规则所指定的那些不同的分组条件和/或动作的空间。例如，规则L4对“端口＝9拒绝”进行编码，并且将落在L_允许_BDD所划出的区域之外。

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

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

H2：端口＝5允许

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

H4：端口＝10拒绝_日志

在L_允许_BDD和H_允许_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_模型272将根据其触发允许的分组条件与硬件呈现Hi_模型276将根据其触发允许的分组条件之间的冲突进行编码。因此，这两个唯一部分602和606组成允许冲突ROBDD 600a。其余的规则L4、H3和H4不是允许规则，因此未在L_允许_BDD、H_允许_BDD或允许冲突ROBDD 600a中表示。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(L_允许_BDD⊕H_允许_BDD)*L_j

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

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

(L_允许_BDD⊕H_允许_BDD)*L1＝0

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

(L_允许_BDD⊕H_允许_BDD)*L2≠0

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

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

(L_允许_BDD⊕H_允许_BDD)*H1＝0

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

(L_允许_BDD⊕H_允许_BDD)*H2＝0

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

(L_允许_BDD⊕H_允许_BDD)*H3≠0

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

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

(L_允许_BDD⊕H_允许_BDD)*H_j

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

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

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

(L_允许_BDD⊕H_允许_BDD)*(H1+...+H_j-1)’H_j

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

(L_允许_BDD⊕H_允许_BDD)*H_j，

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

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

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

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

图7A示出了导致安全问题的网络中的示例健康情况。在该示例中，控制器116A-C形成集群702。控制器116A由控制器116B可达，反之亦然。控制器116C具有不可达状况，其阻止控制器116A和116B与控制器116C进行通信。由于至少一个控制器(即，控制器116C)不可达，因此集群702部分地适用。此外，给定控制器116C的不可达状况，集群702可能不具有足够的可达控制器来形成规定数量，取决于与网络相关联的规定数量规则。

策略704是由集群702在结构120上部署的策略。如图所示，策略704包括防止服务器4(106C)与服务器1(106A)进行通信的限制。为部署策略704，集群702与脊节点102进行通信以将策略704传播到叶节点104。然后，叶节点104可以接收并应用策略704。然后，叶节点104可以对叶节点104所处理的流量实施策略704，以防止服务器4(106C)和服务器1(106A)之间的通信。

然而，在此示例中，叶节点3(104C)不能由脊节点102到达，因此无法接收和部署策略704。在这种情况下，叶节点3(104C)是不活动的，并且将不包含由集群702部署的策略704。当叶节点3(104C)变为活动的且可达时，它将能够通过结构120传送流量。由于在叶节点3(104C)不可达时叶节点3(104C)不包含所部署的策略704，因此叶节点3(104C)将不会对其处理的流量实施策略704。这可能产生安全问题。

例如，流量706描绘了从服务器4(106C)到服务器1(106A)的通信。由集群702部署的策略704限制了从服务器4(106C)到服务器1(106A)的通信。因此，不应在服务器4(106C)到服务器1(106A)之间允许流量706。然而，由于叶节点3(104C)不包含策略704，因此当它从服务器4(106C)接收到流量706时，将不实施策略704中的限制。替代地，叶节点3(104C)从服务器4(106C)接收去往服务器1(106A)的流量706，并将其转发到服务器1(106A)。结果，尽管集群702部署策略704以防止流量706从服务器4(106C)到服务器1(106A)，但服务器4(106C)仍能够将流量706传送到服务器1(106A)。这可能导致安全风险。通常，网络操作器将在检测到服务器4(106C)和服务器1(106A)之间的流量706(这受策略704限制)之后检测到此安全风险。例如，网络操作器将分析结构120中的流量，并基于策略704确定不应该允许流量706。

本文中的方法将能够在流量706被生成之前主动识别此安全风险，而无需分析结构120中的流量。例如，参考图7B，保证设备系统300可以从集群702中的一个或多个控制器获得逻辑模型270。保证设备系统300可以分析逻辑模型270并识别契约、策略、拓扑信息(例如，节点名称、节点地址、节点接口、节点位置、网段等)。例如，保证设备系统300可以分析逻辑模型270并识别由集群702部署在结构120、脊节点102、叶节点104上的策略704，以及相关联的信息。保证设备系统300可以使用从逻辑模型270获得的地址信息来与脊节点102和叶节点104进行通信，并针对节点数据720轮询每个节点。节点数据720可以包括节点信息，例如，状况信息(例如，活动、不活动、可达、不可达、错误等)、节点状态(例如，已注册、未注册、已知、未知等)、节点配置(例如，存储的设置、网络设置、节点软件版本、节点硬件版本等)等。

保证设备系统300可以使用逻辑模型270和节点数据720来发现网络的拓扑和健康情况，如拓扑和健康情况分析710所示。拓扑和健康情况分析710可以包括网络拓扑和节点信息，例如，节点位置和地址、节点状况和状态等。例如，拓扑信息712可以标识结构120中的每个节点、节点的位置和/或地址、节点的状况(例如，活动、可达、不活动、不可达等)等。拓扑和健康情况分析710还可以包括基于拓扑信息712和逻辑模型270确定的错误714。在此示例中，错误714包括关于逻辑模型270中的策略704的策略错误，其指示策略704可能未被叶节点3实施，因为叶节点3具有不可达状况并且不具有所部署的策略704，并且叶节点3被耦合到服务器4(106C)。如错误714所示，叶节点3将不会对来自服务器4(106C)的流量实施策略704。因此，尽管策略704被集群702部署，但服务器4(106C)仍能够与服务器1(106A)进行通信。

然而，保证设备系统300可以基于拓扑和健康情况分析710来主动检测错误714。例如，保证设备系统300可以基于拓扑和健康情况分析710来检测错误714，即使是在流量706被生成或错误714被经历之前，而不必被动地分析实际的流量流或错误事件。替代地，保证设备系统300可以基于逻辑模型270和节点数据720来主动生成拓扑和健康情况分析710。保证设备系统300可以将逻辑模型270中的数据和配置(例如，在逻辑模型270中定义的契约和路由配置)与通过轮询结构120中的从逻辑模型270标识的节点而获得的节点数据720进行比较，并基于所得到的拓扑和健康情况分析710来确定任何其他错误或状况。

在一些情况下，保证设备系统300分析逻辑模型270并发现结构120中的节点(例如，脊节点102和叶节点104)的网络地址(例如，IP地址)，并识别网络中的控制器116。然后，保证设备系统300可以查询和/或轮询网络中的设备，并检测各种网络问题。例如，保证设备系统300可以确定控制器116是否为规定数量或多数、检测一个或多个节点或控制器处的登录失败、检测网络分区、检测节点或控制器的不可达状况等。保证设备系统300可以轮询结构120中的节点(例如，脊节点102和叶节点104)以从节点获得信息(例如，节点数据720)，并确定特定节点是否是不活动的或不可达的等。保证设备系统300可以向一个或多个设备或用户(例如，网络操作器)报告在拓扑和健康情况分析710中识别出的任何问题，并建议响应于这些问题而采取的任何动作。

本公开现在转到图8A和图8B，其示出了示例方法。图8A示出了用于网络保证的示例方法，并且图8B示出了用于拓扑探测和网络健康情况发现的示例方法。这些方法以示例的方式提供，因为存在多种执行这些方法的方式。另外，尽管以特定顺序的框或步骤示出了示例方法，但是本领域普通技术人员将理解，图8A-8B以及其中所示的框可以以任何顺序执行，并且可以包括比所示的更少或更多的框。

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

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

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

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

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

图8B示出了用于发现网络的拓扑和健康情况的示例方法。在步骤820处，保证设备系统300从网络中的一个或多个控制器(例如，控制器116)获得网络(例如，网络环境100)的逻辑模型(例如，逻辑模型270)。如前所述，逻辑模型可以包括针对网络定义的对象属性以及对象的数据和配置。例如，逻辑模型可以识别网络中的各种控制器和节点(例如，脊节点102、叶节点104、控制器116)，以及针对所识别的控制器和节点定义的相应的信息或设置，例如，网络名称、网络地址(例如，IP地址)、网络情境(例如，VRF)、网段(例如，VLAN、子网、桥接域等)、网络角色或功能(例如，控制器、交换机等)等。保证设备系统300可以从逻辑网络中提取任何控制器和节点信息，以及针对网络定义的特定配置或设置，例如，租户、契约等。

基于逻辑模型，在步骤822处，保证设备系统300可以识别网络中的控制器(例如，控制器116)和网络的结构(例如，结构102)中的多个节点(例如，脊节点102和叶节点104)的相应位置。相应位置可以包括控制器和节点的相应的网络名称和/或地址。例如，保证设备系统300可以识别网络中的控制器和节点的名称(例如，可辨别名称(DN)、全限定域名(FQDN)、主机名、设备标识符、别名等)和/或IP地址。如先前所解释的，保证设备系统300可以从逻辑模型中识别或提取该信息。

基于所识别的控制器和节点的相应位置，在步骤824处，保证设备系统300可以针对相应的状况信息轮询控制器和节点。例如，保证设备系统300可以获得控制器和节点的IP地址，并使用该IP地址来针对相应的状况信息轮询任何控制器和/或节点。相应的状况信息可以包括例如可达性状况(例如，网络连接性、响应性、无响应性、登录能力等)、活动状况或状态(例如，不活动、活动、禁用、已注册、未注册、不可用、处于故障状态等)、配置信息(例如，软件版本、硬件版本、设备兼容性、安全性配置、联网设置等)等。

在一些情况下，保证设备系统300可以多次轮询或查询网络元件，例如，控制器或节点，以更新或验证接收到的信息，或尝试获得保证设备系统300先前无法获得的信息。例如，保证设备系统300可以在特定事件或时间段之后查询节点或控制器，以更新或验证从节点或控制器获得的数据。作为另一示例，保证设备系统300可以在失败查询之后多次查询节点或控制器。失败查询可能由例如不可达状况、登录失败、不活动或禁用状态、网络或设备故障、安全状况、无响应状态、不正确的信息或设置等引起。保证设备系统300可以继续发送查询并进行进一步尝试，直到节点或控制器在一段时间过去之后响应多个失败的查询或尝试等。

在步骤826处，保证设备系统300可以基于逻辑模型(例如，在逻辑模型中定义的数据和配置)、节点和控制器的相应位置、和/或节点和控制器的相应的状况信息来确定网络的健康情况和拓扑。例如，保证设备系统300可以基于从逻辑模型识别出的控制器和节点的相应位置来确定网络的拓扑，并且可以基于控制器和节点的相应状况以及逻辑模型中的配置信息(例如，逻辑模型中的契约或策略)来确定网络的健康情况。保证设备系统300可以分析来自节点和控制器的相应的状况信息，以及逻辑模型中的配置、对象、属性、和/或数据，并发现网络的拓扑和健康情况(例如，拓扑和健康情况分析710)，如前所述。

例如，保证设备系统300可以将在网络的逻辑模型中定义的配置(例如，契约、策略、路由配置等)与节点和/或控制器的相应的状况信息(例如，可达性、兼容性、活动、状态等)进行比较，以识别任何健康问题，例如，安全或通信问题。为了说明，保证设备系统300可以确定尚未在节点处部署逻辑模型中的策略，并基于该节点的角色(例如，该节点连接到策略所覆盖的设备或应用，并且被预期针对去往/来自该设备或应用的流量实施该策略)或该节点未应用或实施该策略的影响来识别潜在的安全风险。

在一些示例中，保证设备系统300可以基于设备的状况以及逻辑模型中的配置或策略，或者产生自逻辑模型中所定义的配置的潜在网络情况(例如，循环)以及结构中的节点的状况(例如，逻辑模型中所定义的泛洪域(flood domain)以及节点的活动或转发状态)，来识别设备处的陈旧配置或策略。保证设备系统300所发现的健康情况的其他非限制性示例可以包括网络分区、解析错误、集群的规定数量或多数状况(例如，集群中的控制器不是规定数量或多数)、部分适用的集群(例如，集群中的一个或多个控制器不可达、不可用、无响应、禁用、不兼容等)、网络或设备故障、网络或设备不一致性、网络或设备连接性或可达性问题、安全风险、路由配置问题、设备登录问题等。

本公开现在转到图9和图10，其示出了计算设备和网络设备的示例架构，例如，客户端计算机、交换机、路由器、控制器、服务器等。

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

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

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

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

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

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

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

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

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

总之，描述了用于发现网络的拓扑和健康情况的系统、方法和计算机可读介质。在一些示例中，系统可以从网络上的多个控制器中的至少一个控制器获得网络的逻辑模型，该逻辑模型包括针对网络定义的一个或多个对象的配置。基于逻辑模型，系统可以识别网络中的多个控制器以及网络的结构中的多个节点的相应位置。基于该多个控制器和多个节点的相应位置，系统可以针对相应的状况信息来轮询该多个控制器和多个节点，并基于逻辑模型、相应位置、以及相应状况信息来确定网络的健康情况和拓扑。

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

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

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

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

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

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

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

Claims

1.一种方法，包括：

从网络上的至少一个控制器获得所述网络的逻辑模型，所述逻辑模型包括针对所述网络定义的一个或多个对象的配置；

基于所述逻辑模型，识别所述网络中的多个控制器以及所述网络的结构中的多个节点的相应的位置；

基于所述相应的位置，针对相应的状况信息来轮询所述多个控制器和所述多个节点；以及

基于所述逻辑模型以及所述网络中的所述多个控制器和所述结构中的所述多个节点的所述相应的状况信息，确定所述网络的健康情况和拓扑。

2.根据权利要求1所述的方法，其中，所述相应的状况信息包括相应的可达性状况、相应的状态、相应的响应性、和相应的配置中的至少一项，并且其中，确定所述网络的所述健康情况和拓扑是基于所述相应的位置以及所述逻辑模型中一个或多个对象的所述配置的，所述一个或多个对象的所述配置包括契约、联网配置、规则、和策略中的至少一项，并且所述一个或多个对象包括租户、端点组、应用简档、网络情境、桥接域、和网络元件中的至少一项。

3.根据权利要求2所述的方法，其中，所述相应的状态包括活动状态、不活动状态、禁用状态、发现状态、和未知状态中的至少一项，并且其中，所述相应的配置包括兼容性状况、软件版本、硬件版本、和安全参数中的至少一项。

4.根据权利要求2或3所述的方法，其中，确定所述网络的所述健康情况和拓扑包括：基于所述多个控制器和所述多个节点中的至少一个的相应的状况来识别网络分区。

5.根据权利要求1至4中任一项所述的方法，还包括：

基于所述相应的状况信息，确定所述网络中的所述多个控制器的相应的状况，所述相应的状况包括相应的可达性状况、相应的状态、相应的注册、和相应的配置中的至少一项；

基于所述相应的状况，确定所述多个控制器中具有预定状况的控制器的数量；以及

基于具有所述预定状况的控制器的所述数量，确定所述多个控制器是否为规定数量。

6.根据权利要求5所述的方法，其中，所述预定状况包括预定可达性状况、预定状态、预定注册、和预定配置中的至少一项，并且其中，确定所述多个控制器是否为规定数量是基于规定数量规则的，该规定数量规则指定形成规定数量所需的控制器的阈值数量。

7.根据权利要求6所述的方法，还包括：

识别所述结构中具有不可达状况的节点；以及

基于所述结构中的所述节点的所述不可达状况，确定所述节点尚未获得在所述网络上部署的一个或多个策略。

8.根据权利要求7所述的方法，还包括：

基于所述网络的所述拓扑，识别经由所述结构中的所述节点连接到所述结构的一个或多个设备，其中，所述一个或多个设备包括物理设备和逻辑设备中的至少一项，所述逻辑设备包括虚拟机、虚拟服务、和软件容器中的至少一项；

确定安全策略与经由所述结构中的所述节点连接到所述结构的所述一个或多个设备中的至少一个设备相关联；以及

基于所述节点的所述不可达状况，确定所述策略尚未被部署在所述节点处，并且将不会被应用于所述结构与经由所述节点连接到所述结构的所述一个或多个设备中的所述至少一个设备之间的流量。

9.根据权利要求8所述的方法，其中，确定所述策略将不会被应用于所述结构与连接到所述结构的所述一个或多个设备中的所述至少一个设备之间的流量是在流量在所述结构与所述一个或多个设备中的所述至少一个设备之间流动之前被执行的，所述方法还包括：生成安全警报，所述安全警报指示所述策略将不会被应用于所述结构与所述一个或多个设备中的所述至少一个设备之间的流量。

10.根据权利要求1至9中任一项所述的方法，其中，所述多个控制器包括控制器的集群，所述方法还包括：

基于所述相应的状况信息，确定所述集群中的每个控制器的相应的可达性状况；

基于所述集群中的每个控制器的所述相应的可达性状况，确定所述集群具有部分适用状况，所述部分适用状况指示所述集群中的至少一个控制器不可被所述网络中的一个或多个网段到达；以及

生成对所述集群的所述部分适用状况的通知。

11.一种系统，包括：

一个或多个处理器；以及

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

从网络上的多个控制器中的至少一个控制器获得所述网络的逻辑模型，所述逻辑模型包括针对所述网络定义的一个或多个对象的配置；

基于所述逻辑模型，识别所述网络中的所述多个控制器以及所述网络的结构中的多个节点的相应的位置；

基于所述相应的位置，向所述多个控制器和所述多个节点请求相应的状况信息；以及

12.根据权利要求11所述的系统，其中，所述相应的状况信息包括相应的可达性状况、相应的状态、相应的注册、和相应的配置中的至少一项，并且其中，确定所述健康情况和拓扑是基于所述相应的位置以及所述逻辑模型中的所述一个或多个对象的所述配置的，所述配置和一个或多个对象包括契约、联网配置、策略、租户、规则、端点组、应用简档、网络情境、和网络元件中的至少一项，并且其中，所述相应的位置包括所述网络中相应的名称、和相应的网络地址中的至少一项。

13.根据权利要求12所述的系统，其中，确定所述网络的所述健康情况和拓扑包括：基于所述多个控制器和所述多个节点中的至少一个的相应的状况来识别网络分区。

14.根据权利要求11至13中任一项所述的系统，所述至少一个计算机可读存储介质存储当被所述一个或多个处理器执行时，使所述系统执行以下操作的指令：

15.根据权利要求14所述的系统，其中，所述预定状况包括预定可达性状况、预定状态、预定注册、和预定配置中的至少一项，并且其中，确定所述多个控制器是否为规定数量是基于规定数量规则的，所述规定数量规则指定形成规定数量所需的控制器的阈值数量。

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

识别所述结构中具有不可达状况的节点；

基于所述结构中的所述节点的所述不可达状况，确定所述节点尚未获得在所述网络上部署的策略；

基于所述网络的所述拓扑，识别经由所述结构中的所述节点连接到所述结构的一个或多个网络元件；

确定所述策略与经由所述结构中的所述节点连接到所述结构的所述一个或多个网络元件中的至少一个网络元件相关联；以及

确定作为所述节点尚未获得所述策略的结果，所述策略将不会被应用于所述结构与经由所述节点连接到所述结构的所述一个或多个网络元件中的所述至少一个网络元件之间的流量。

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

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

基于所述逻辑模型、所述相应的位置、以及所述相应的状况信息，确定所述网络的健康情况和拓扑。

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

识别所述结构中具有不可达状况的节点；

19.根据权利要求17或18所述的非暂态计算机可读存储介质，其中，所述相应的状况信息包括相应的可达性状况、相应的兼容性、和相应的状态中的至少一项，其中，所述配置和一个或多个对象包括契约、联网配置、策略、租户、规则、端点组、应用简档、网络情境、和对象属性中的至少一项，并且其中，确定所述网络的所述健康情况和拓扑包括：基于来自所述多个控制器的控制器和来自所述多个节点的节点中的至少一个的相应的可达性状况来识别网络分区。

20.根据权利要求17至19中任一项所述的非暂态计算机可读存储介质，其中，所述多个控制器包括控制器的集群，所述非暂态计算机可读存储介质存储附加指令，所述附加指令当被所述一个或多个处理器执行时，使所述一个或多个处理器执行以下操作：

基于所述集群中的每个控制器的所述相应的可达性状况，确定所述集群具有部分适用状况，所述部分适用状况指示所述集群中的至少一个控制器不可从所述网络中的一个或多个位置到达；以及

生成对所述集群的所述部分适用状况的通知。

21.一种设备，包括：

用于从网络上的至少一个控制器获得所述网络的逻辑模型的装置，所述逻辑模型包括针对所述网络定义的一个或多个对象的配置；

用于基于所述逻辑模型识别所述网络中的多个控制器以及所述网络的结构中的多个节点的相应的位置的装置；

用于基于所述相应的位置针对相应的状况信息来轮询所述多个控制器和所述多个节点的装置；以及

用于基于所述逻辑模型以及所述网络中的所述多个控制器和所述结构中的所述多个节点的所述相应的状况信息确定所述网络的健康情况和拓扑的装置。

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

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