CN110521169B

CN110521169B - 用于服务链的策略保证

Info

Publication number: CN110521169B
Application number: CN201880021049.1A
Authority: CN
Inventors: 拉马纳·拉奥·孔佩拉; 卡蒂克·莫汉拉姆; 阿德维特·迪克西特; 桑德·伊耶
Original assignee: Cisco Technology Inc
Current assignee: Cisco Technology Inc
Priority date: 2017-04-20
Filing date: 2018-04-05
Publication date: 2022-06-03
Anticipated expiration: 2038-04-05
Also published as: US20180309632A1; CN110521169A; US10623264B2; WO2018194839A1; EP3613175A1

Abstract

在一些示例中，系统获得网络逻辑模型，并且对于网络中的每个节点，获得节点级逻辑、具体和硬件模型。系统识别服务功能链，并确定服务功能链规则的相应集合。对于每个节点，系统确定在节点级逻辑模型和/或具体模型中是否正确捕获服务功能链规则的相应集合，以产生节点包含检查结果。基于具体模型、硬件模型以及节点级逻辑模型或网络逻辑模型中的至少一个中的策略动作的比较，系统确定是否在每个节点上正确呈现服务功能链规则的相应集合，以产生节点呈现检查结果。基于节点包含检查结果和节点呈现检查结果，系统确定是否正确配置了服务功能链。

Description

用于服务链的策略保证

相关申请交叉引用

本申请要求于2017年4月20日提交的题为“POLICY ASSURANCE FOR SERVICECHAINING(用于服务链的策略保证)”的美国临时专利申请No.62/487,924和于2017年8月31日提交的题为“POLICY ASSURANCE FOR SERVICE CHAINING(用于服务链的策略保证)”美国非临时专利申请No.15/693,310的权益和优先权，它们两者的全部内容通过引用明确地并入本文。

技术领域

本技术涉及网络配置和故障排除，更具体地涉及网络服务链功能的策略保证。

背景技术

部署第4层(L4)至第7层(L7)网络服务(例如，防火墙、负载平衡器等)通常需要网络运营商配置网络，以保证网络流量经过特定网络服务设备。无论服务功能设备是物理设备还是虚拟服务，都是这种情况。此配置过程繁琐且容易出错。由于网络配置的分布式特性，单个网络设备无法验证或保证流量不绕过特定网络服务设备。此外，手动验证网络配置可能非常困难。即使在使用测试分组手动验证网络配置时，此验证机制也不会随着网络规模而缩放。此外，手动验证通常仅在问题发生后反应性地进行。这可能会导致安全性和性能漏洞，以及长时间的意外网络行为。

附图说明

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

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

图1C示出了示例网络服务功能链的示意图；

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

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

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

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

图2E示出了示例服务图部署的图示；

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

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

图4A示出了用于构建网络的网络范围逻辑模型的示例图；

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

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

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

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

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

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

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

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

图7B和7C示出了用于保证网络服务链配置的示例方法；

图8示出了示例网络设备；以及

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

具体实施方式

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

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

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

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

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

概述

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

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

在许多情况下，网络中的各种节点和/或控制器可以包含网络和网络状态的相应信息或表示。例如，不同的控制器可以存储网络的不同逻辑模型，并且网络结构中的每个节点可以包含其自己的网络配置模型。本文阐述的方法为服务功能链配置和验证提供了主动(proactive)机制。本文的技术可以验证和确认服务功能链配置，并且能够检测各种可能的配置错误。

例如，在诸如以应用为中心的基础设施(ACI)网络之类的软件定义网络(SDN)的上下文中，经常发生各种类型的错误。在一个示例中，运营商可能向集中式控制器提供错误配置。这会导致错误和误配置问题。在另一示例中，控制器可能错误地将网络配置呈现到网络设备上。这可能是由各种问题引起的，例如软件和/或硬件错误、网络设备上的资源短缺、硬件故障和其他问题。本文的方法可以检测这些和其他错误，并主动验证 SDN控制器和网络设备之间的服务链配置和一致性。GUI(图形用户界面)可以显示由于运营商配置错误而识别出的不一致、网络中的设备不正确地呈现策略以及其他配置问题，并且提供可视工具来解决这样的错误和不一致。

本文公开了用于服务链的策略保证的系统、方法和计算机可读介质。在一些示例中，系统或方法获得与网络相关联的多个模型。多个模型包括表示为网络定义的规则的网络范围的逻辑模型、针对网络中每个节点的相应节点级逻辑模型、针对网络中每个节点的相应具体模型(concrete model)、以及针对网络中每个节点的相应硬件模型。

相应节点级逻辑模型可以至少包括在网络范围的逻辑模型中定义的规则的一部分。该部分规则可以包括为网络范围的逻辑模型定义的规则中对应于节点的那些规则。因此，相应节点级逻辑模型可以将网络范围的逻辑模型投射到节点上。相应具体模型可以包括在节点的软件环境上的软件呈现规则，例如操作系统。相应硬件模型可以包括节点的硬件上的硬件呈现规则，例如TCAM规则。

基于多个模型中的至少一个，系统可以识别网络中的预期服务功能链。系统还可以基于多个模型中的至少一个模型中的相应规则来确定用于预期服务功能链的预期服务功能链规则的相应集合。相应规则可以对应于与预期服务功能链中的元素相关联的端点组。

对于每个节点，系统可以确定相应节点级逻辑模型和/或相应具体模型中的规则是否正确地捕获了预期服务功能链规则的相应集合，以产生针对该节点的相应的节点级包含(containment)检查结果。基于相应具体模型、相应硬件模型以及相应节点级逻辑模型和/或网络范围逻辑模型中的相应策略动作的比较，系统可以确定与网络范围逻辑模型相关联的预期服务功能链规则的相应集合是否在每个节点上被正确地呈现，以产生节点级呈现检查结果。基于相应的节点级包含检查结果和节点级呈现检查结果，系统可以确定是否在网络上正确地配置了预期服务功能链。

示例实施例

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

本公开现在转到对网络保证概念的介绍性讨论，包括用于服务链化的策略保证。

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

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

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

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

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

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

在一些情况下，可以实现模型以验证服务功能链配置。下面描述示例服务功能链配置检查。出于解释目的，在ACI网络的上下文中描述示例检查。

在ACI网络中，网络运营商的预期服务功能链以及预期服务功能链行为可以以各种形式表示，例如逻辑网络服务图、具有顶点(EPG)和边 (网络服务)的规范、对应于服务功能链的显式规则等。该网络服务功能链意图可以被认为是用于确定服务功能链是否按预期进行配置的基本事实，因为它反映了网络运营商的真实意图。因此，可以相对于该服务功能链意图来验证网络的路由和策略配置。

可以在若干阶段中执行对服务功能链配置的验证。首先，网络的网络范围的逻辑模型可以被转换成节点级或特定于节点的逻辑模型，针对网络中的每个节点(例如，交换机)包括一个节点级或特定于节点的逻辑模型。节点中的软件配置可以用“具体模型”表示，并且硬件配置(例如， TCAM配置)可以用“硬件模型”表示。可以从每个节点收集或轮询节点上的软件和硬件配置。可以使用逻辑模型中的规则来构造预期网络服务链规则的集合，该规则在语法上匹配预期服务功能链的元素中的EPG。

可以分别在每个节点的逻辑和具体模型中验证服务功能链的路由配置。在正确配置的服务功能链中，预期服务功能链的规则在逻辑上被包含在全局逻辑策略中。这可以在包含检查中验证，可以为每个节点执行包含检查。在一些示例中，为了执行包含检查，为预期服务功能链规则和逻辑策略规则生成一组布尔函数。每个布尔函数对应于逻辑策略中的一个动作，并且如果相应的规则集对分组执行该动作，则针对分组报头返回“真”。

布尔函数可以由特定结构表示。例如，布尔函数可以通过简化有序二元决策图(ROBDD)来表示。出于解释目的，将在以下示例中使用 ROBDD。然而，应该注意，其他表示也是可能的并且在本文中考虑。

ROBDD还可用于检查逻辑模型是否已正确地呈现到每个节点上。如果节点级的包含检查失败或呈现检查失败，则可以使用ROBDD来识别哪些EPG对契约导致该失败。ROBDD的应用将在下面进一步解释。

可以沿各种维度聚合检查结果。例如，节点级的包含检查结果可以聚合到单个网络范围的服务功能链包含结果。此外，EPG成对包含检查结果可以跨节点地聚合到网络范围的EPG对包含结果。执行的所有检查的结果以及聚合结果可以加时间戳并写入数据库或存储装置。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

图1C示出了示例网络服务功能链140的示意图。网络或服务功能 (例如路由、网络地址转换、入侵检测、防火墙功能、内容传递等)可以与硬件平台解耦并以软件实现。例如，网络功能虚拟化(NFV)可以将网络设备实现为软件中的虚拟化功能。网络或服务功能可以通过例如VM、软件容器、应用、运行时功能等来实现。给定应用的给定流程可以通过组成服务功能链的多个网络或服务功能来引导，以实现期望功能。

在该示例中，服务功能链140可以包括服务功能148A-C，它们一起实现服务功能链140的期望功能。服务功能148A-C可以在一个或多个 VM、软件容器、运行时环境、服务器等中运行。此外，服务功能148A-C 驻留在一个或多个网络上。在一些情况下，服务功能148A-C可以驻留在相同的网络和/或主机(例如，VM、软件容器、服务器等)或不同的网络和/或主机上。例如，服务功能148A-C可以驻留在不同的VM或容器上，并且经由一个或多个网络146进行通信，网络146可以包括一个或多个物理和/或逻辑网络。为了说明，网络146可以包括网络环境100中的不同数据中心。

当端点142和端点144针对给定应用进行通信时，可以通过服务功能链140中的服务功能148A-C来引导给定应用的分组，以实现该应用的期望功能。例如，假设服务功能148A是网络监控功能，服务功能148B是负载平衡功能，并且服务功能148C是防火墙功能。这里，从端点142到端点144的分组可以经过服务功能148A所提供的网络监控功能，服务功能148B的负载平衡功能和服务功能148C的防火墙。作为另一示例，假设服务功能链140提供移动基站的虚拟化功能以用于访问移动网络。在该示例中，服务功能148A-C可以提供各种功能以实现移动基站的功能。端点 142、144之间的流量可以经过服务功能链140中的服务功能148A-C以实现移动基站的期望功能。

为了向与服务功能链140相关联的给定应用提供端到端服务，应该适当地引导流量通过服务功能链140中的每个服务功能148A-C。这可能需要特定路由配置、安全性配置、优先级、应用策略等。这些配置可以由一个或多个控制器(例如，控制器116)、节点(例如，叶节点104)、服务或编排系统、应用等来定义。在一些情况下，信息模型可以描述服务功能链140中的服务功能148A-C、相关的物理或基础设施实体、节点、链路、每个服务功能的要求(例如，容量、性能、SLA等)等。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

控制器116

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

节点204

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

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

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

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

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

节点206

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

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

节点208

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

节点210

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

控制器116可以提供自动服务插入，并且还充当策略控制的中心点。策略可以管理网络结构和服务设备。控制器116可以配置网络，以便流量流过服务。控制器116还可以根据应用的要求来配置服务。

节点210可以包括第4层到第7层策略模型。该第4层到第7层策略模型可以包括针对L4-L7服务设备类型策略的管理对象，例如包和设备脚本所支持的服务。

节点210可以包括服务可管理对象(MO)、设备脚本MO和功能简档组容器MO。服务MO可以包含设备所提供的功能的元数据，例如SSL 卸载和负载平衡。服务MO可以包含连接器名称、封装类型(例如， VLAN、VxLAN等)、接口标签等。

设备脚本MO可以表示设备脚本处理器，其包含关于脚本处理器的相关属性的元信息，包括例如其名称、包名称、版本等。

功能简档组容器MO可以包括包含服务设备类型可用功能的对象。功能简档可以包含设备所支持的可配置参数，其例如可以被组织到文件夹中。

节点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。与在传统数据中心中中继(trunk down)VLAN相比，这节省了时间。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

图2E示出了示例服务图部署280的图。应用所需的服务可以被视为来自控制器116在结构120上实例化的服务图。用户可以为应用定义服务，并且服务图可以标识应用所需的网络或服务功能(例如，服务功能 148A-C)的集合。

服务图使用功能节点、终端节点、连接器和连接来表示网络。功能节点表示应用于流量的功能，例如，转换(SSL终端、VPN网关)、过滤器 (防火墙)或终端(入侵检测系统)。服务图内的功能节点可能需要一个或多个参数，这些参数可以是EPG、应用简档或租户VRF。

功能节点包括连接器。连接器使能来自节点的输入和输出，并将功能节点连接到服务图。功能节点的连接器表示服务功能的网络要求。连接器可以基于图的连接器的子集来与适当的桥接域和连接相关联。每个连接器都可以与VLAN或虚拟可扩展LAN(VXLAN)相关联。连接器的每一侧都可以被视为EPG。

终端节点使能来自服务图的输入和输出。终端节点将服务图与契约连接起来。通过将终端节点连接到契约，可以为两个应用EPG之间的流量插入服务图。一旦连接，契约的消费者EPG和提供者EPG之间的流量被重定向到服务图。

连接确定如何通过网络转发流量。

在控制器116中配置了图之后，控制器116可以根据服务图中的服务功能要求来配置服务。控制器116还可以根据服务图中指定的服务功能的需要来配置网络，其不需要服务设备中的任何改变。

服务图可以被表示为应用的两个或更多个层，其中在这些层之间插入有适当的服务功能。服务装置(设备)可以执行图内的服务功能。可能需要一个或多个服务装置来呈现图所需的服务。一个或多个服务功能可以由单服务设备执行。

服务图和服务功能可以具有以下特性：

可以基于策略来过滤由EPG发送或接收的流量，并且可以将流量的子集重定向到图中的不同边。

服务图的边是有方向性的。

抽头(tap)(基于硬件的分组复制服务)可以附接到服务图中的不同点。

可以基于策略来在适当的(物理或虚拟)设备上呈现逻辑功能。

服务图支持边的分割和连接，并且它不将管理员限制为线性服务链。

在服务装置发出流量之后，可以在网络中再次对流量进行重新分类。

逻辑服务功能可以按比例放大或缩小或部署(例如，以集群模式或 1:1活动–待机高可用性模式)，这取决于要求。

服务图可以允许网络运营商安装诸如防火墙之类的服务一次并且在不同的逻辑拓扑中多次部署它。每次部署图时，网络控制器(例如，控制器 116)可以改变防火墙上的配置以使能新逻辑拓扑中的转发。服务图部署可以涉及各种配置，例如BD和VRF。

在图2E中，服务图部署280示出了与标记为“web应用”的web应用相关联的服务图282。服务图部署280包括功能节点284A-C、终端节点 286、连接器288和连接290。

功能节点284A表示防火墙功能。功能节点284B表示SSL卸载功能。功能节点286C表示负载平衡器功能。

功能节点284A-C可以包括L4-L7参数292，其可以包括参数294A- C。参数294A、294B和294C分别对应于功能节点284A、284B和284C。

连接器288表示功能节点284A-C的网络要求。诸如VLAN和VNID 标签之类的网络连接性被分配给连接器288。连接290确定如何通过服务图部署280转发流量。

终端节点286表示服务图282中的功能节点284A-C的消费者和提供者EPG。

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

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

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

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

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

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

安全策略遵守

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

静态策略分析

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

TCAM利用率

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

端点检查

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

租户路由检查

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

基础设施路由

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

MP-BGP路由反射检查

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

逻辑线头和实时变化分析

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

图4A示出了用于基于从网络上的各种控制器(例如，控制器116-1 至116-N)获得的逻辑模型270-1来构建网络(例如，网络环境100)的网络范围逻辑模型270的示例图400。逻辑模型270-1到270-N可以包括相应版本的L_模型270A和/或LR_模型270B，如图2D所示，其存储在相应控制器116处。逻辑模型270-1到270-N中的每一个可以包括存储在相应控制器116处的网络的对象和配置。对象和配置可以包括由网络运营商经由控制器116提供的数据和配置。控制器116可以存储这样的对象和配置以被推送到结构120中的节点，例如叶节点104。

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

网络范围逻辑模型270可以基于来自控制器116的逻辑模型270-1到 270-N提供网络的网络范围表示。因此，网络范围逻辑模型270可以反映网络的意图规范。换句话说，网络范围逻辑模型270可以通过网络运营商经由控制器116指定的配置和数据来反映网络运营商所期望的网络的配置。

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

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

图4B示出了用于基于网络(例如，网络环境100)的逻辑模型270构建特定于节点的逻辑模型(例如，Li_模型272)的示例图420。逻辑模型 270可以参考如图4A所示的网络范围逻辑模型270。因此，如先前所解释的，逻辑模型270可以是基于网络中的各种控制器(例如，控制器116) 处的逻辑模型L_模型270A和/或LR_模型270B的L_模型270A和/或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)，以在节点的硬件上生成所呈现的配置。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在一些示例中，被比较的ROBDD将与相同的动作相关联。例如，等效性检查器528可以通过计算L_允许_BDD和H_允许_BDD之间的排他性析取 (disjuction)来检查L_允许_BDD与H_允许_BDD的形式等效性。更具体地，计算

(即，L_允许_BDD XOR H_允许_BDD)，但是应理解，以下描述也适用于其他网络模型(例如，逻辑模型270、L_模型 270A、LR_模型270B、Li_模型272、Ci_模型274、Hi_模型276等)和相关联的动作(允许、允许_日志、拒绝、拒绝_日志等)。

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

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

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

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

L2：端口＝4允许

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

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

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

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

H2：端口＝5允许

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

H4：端口＝10拒绝_日志

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

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

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

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

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

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

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

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

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

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

如前面的情形，通过将冲突ROBDD 600c构造为

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

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

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

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

在接收到一个或多个特定于动作的冲突ROBDD的情况下，冲突规则识别器534还可以接收在每个冲突ROBDD 532中表示的经优先级排序的规则的扁平列表作为输入。例如，如果冲突规则识别器534接收对应于

的允许冲突ROBDD，则用于生成L_允许_BDD和H_ 允许_BDD的经优先级排序的规则Li、Hi的基础扁平列表也被接收作为输入。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

图7A-7 C中所示的每个块表示方法中的一个或多个步骤、过程、方法或例程。为了清楚和解释的目的，图7A-7 C中的块参考如图1A-1 C、2D、 3A、5A和5C所示的网络环境100，服务功能链140，保证设备系统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和7C示出了用于保证服务功能链配置的示例方法。在某些情况下，图7B和7C中的方法可以与图7A中的方法分开执行，或者附加于图 7A中的方法执行。然而，在其他情况下，图7B或7C中的方法可以是图 7A中的保证方法的一部分。例如，图7B中的方法可以表示图7A中的方法内的一个或多个步骤，或图7A中的方法的具体应用。为了说明，图7A 中的方法可以表示可以分析网络的不同类型的配置或方面的一般保证方法的示例，而图7B中的方法可以表示专门实现用于保证服务功能链配置的方法的示例。

在步骤720，保证设备系统300获得与网络(例如，网络环境100) 相关联的多个模型(例如，模型270-276)。多个模型可以包括表示为网络定义的规则的网络范围的逻辑模型(例如，逻辑模型270)、针对网络中的每个节点(例如，脊节点102和/或叶节点104)的相应的节点级逻辑模型(例如，Li_模型272)、针对网络中的每个节点的相应的具体模型 (例如，Ci_模型274)，以及针对网络中的每个节点的相应的硬件模型 (例如，Hi_模型276)。

在步骤722，基于多个模型中的至少一个，保证设备系统300识别网络中的预期服务功能链(例如，服务功能链140)。例如，保证设备系统 300可以基于网络范围的逻辑模型(例如，逻辑模型270)识别预期服务功能链。预期服务功能链中的服务功能可以驻留在一个或多个网络和/或主机中，例如VM、软件容器、服务器、运行时环境等。可以通过网络逻辑模型中的规则、契约、对象等来配置预期服务功能链。在一些情况下，可以基于逻辑模型中的EPG之间的契约和/或规则来配置预期服务功能链。因此，逻辑模型可以指定为预期服务功能链定义的EPG、策略、规则、对象、契约等。

在一些情况下，保证设备系统300可以基于逻辑网络服务图(例如，表示280)、顶点(例如，EPG)和边(例如，网络服务)的规范、和/或与服务功能链相对应的显式规则来识别预期服务功能链。当识别预期服务功能链时，保证设备系统300可以识别与服务功能链相关联的各个方面，例如，每个服务功能、每个主机(例如，VM、软件容器、网络等)、每个服务要求、每个配置、每个EPG、每个策略、每个契约、每个动作、每个终端主机等。

在步骤724，保证设备系统300可以基于多个模型中的一个或多个模型中的相应规则来确定用于预期服务功能链的预期服务功能链规则的一个或多个相应集合。例如，保证设备系统300可以在网络范围的逻辑模型 (例如，逻辑模型270、L_模型270A或LR_模型270B)中确定预期服务功能链规则的相应集合。然后，保证设备系统300可以针对每个节点确定来自与网络范围的逻辑模型相关联的预期服务功能链规则的相应集合的哪些规则应该被包括在该节点的相应节点级逻辑模型(例如，Li_模型272) 中。基于应当被包括在节点的相应节点级逻辑模型中的预期服务功能链规则的相应集合中的规则，保证设备系统300可以为该节点构建预期服务功能链规则的相应集合。

预期服务功能链规则的相应集合可以对应于与预期服务功能链中的一个或多个元素相关联的一个或多个EPG。例如，预期服务功能链规则的相应集合可以包括在语法上与预期服务功能链的元素(例如，端点、节点、契约、策略、应用、规则、对象、配置等)中的EPG相匹配的规则。

在一些情况下，保证设备系统300可以识别从网络逻辑模型(例如，来自一个或多个控制器的逻辑模型，例如逻辑模型270、L_模型270A或者LR_模型270B)得到的网络级预期服务功能链规则的相应集合和从一个或多个节点的相应节点级逻辑模型得到的节点级预期服务功能链规则的相应集合。因此，保证设备系统300可以构造或获得预期服务功能链规则的多个相应的集合，包括从网络的逻辑模型得到的集合和分别从一个或多个节点的逻辑模型得到的一个或多个集合。例如，保证设备系统300可以识别从网络逻辑模型(例如，逻辑模型270、L_模型270A或LR_模型 270B)得到的预期服务功能链规则的相应集合。保证设备系统300还可以识别从网络逻辑模型得到的预期服务功能链规则的相应集合中的规则(例如，与预期服务功能链相关联的EPG之间的契约)，以基于从网络逻辑模型得到的预期服务功能链规则的相应集合，确定用于每个节点的预期服务功能链规则的相应集合。用于节点的预期服务功能链规则的相应集合可以包括与网络逻辑模型相关联的预期功能链规则的相应集合中的应被投射或传播到该节点的相应节点级逻辑模型的那些规则。

预期服务功能链规则的集合可以包括定义如下内容的规则：例如，与预期服务功能链有关的EPG、与预期服务功能链和EPG有关的流量参数 (例如，分组报头、标记等)、用于关联流量的转发规则、链中的有序功能、与链中功能相对应的功能参数、通过网络和/或链的流量流、L4-L7参数、契约、策略动作、VRF信息、BD信息、网络连接性信息(例如， VLAN、VNID标签等)、管理网络结构和服务设备的规则等。

在步骤726，对于每个节点，保证设备系统300可以确定与相应节点级逻辑模型相关联的预期服务功能链规则的相应集合是否被相应节点级逻辑模型中的规则正确捕获(例如，包含)，以为节点产生相应的节点级包含检查结果。例如，保证设备系统300可以基于节点的相应节点级逻辑模型，将为每个节点构建或得到的预期服务功能链规则的相应集合与该节点的相应节点级逻辑模型中的规则相比较，如下进一步解释的那样。

在步骤728，基于相应具体模型、相应硬件模型以及相应节点级逻辑模型或网络范围逻辑模型中的至少一个中的相应策略动作的比较，保证设备系统300可以确定是否在每个节点上正确地呈现了与网络范围的逻辑模型(例如，逻辑模型270、L_模型270A或LR_模型270B)相关联的预期服务功能链规则的相应集合，以产生节点级呈现检查结果。在步骤730，基于相应的节点级包含检查结果和节点级呈现检查结果，保证设备系统 300可以确定是否在网络上正确地配置了预期服务功能链。

例如，如果相应的节点级包含检查结果和节点级呈现检查结果针对每个节点通过了，则保证设备系统300可以确定在网络中正确地配置了预期服务功能链。相反，如果相应的节点级包含检查结果和节点级呈现检查结果未针对每个节点通过，则保证设备系统300可以确定在网络中未正确地配置预期服务功能链。

在一些情况下，保证设备系统300可以聚合每个节点的相应节点级包含检查结果，以产生用于预期服务功能链的网络范围的包含检查结果，并聚合每个节点的节点级呈现检查结果，以产生用于预期服务功能链的网络范围的呈现检查结果。因此，保证设备系统300可以基于网络范围的包含检查结果和网络范围的呈现检查结果来确定是否在网络上正确地配置了预期服务功能链。

保证设备系统300还可以分析每个节点的相应路由信息库(RIB)，并且基于每个节点的RIB，确定与对应于预期服务功能链的分组相关联的路由配置是否保证分组将被路由到预期服务功能链，而不绕过预期服务功能链中的一个或多个服务功能。换句话说，保证设备系统300可以检查每个节点的RIB并验证预期服务功能链未被绕过。

在一些情况下，当网络范围的包含检查结果指示对于每个节点，预期服务功能链规则的相应集合被相应的节点级逻辑模型和/或相应的具体模型中的所有相应规则正确地捕获，网络范围的呈现检查结果指示在每个节点上正确地呈现了与网络范围的逻辑模型相关联的预期服务功能链规则的相应集合，并且与对应于预期服务功能链的分组相关联的路由配置被正确地配置以保证与服务功能链相关联的分组被路由到服务功能链而不绕过一个或多个服务功能或服务功能链时，保证设备系统300可以确定在网络上正确地配置了预期服务功能链。

保证设备系统300因此可以检测允许分组在端点之间直接流动并绕过服务功能链的网络策略和路由配置错误，检测阻止服务功能链的元素之间的分组转发的网络策略和路由配置错误，检测将逻辑模型中指定的服务功能链转换为节点上的硬件配置中的错误等。

在一些示例中，保证设备系统300基于使用表示规则和/或模型的数据结构执行的等效性检查，确定与相应节点级逻辑模型和/或相应具体模型中的至少一个相关联的预期服务功能链规则的相应集合是否被相应节点级逻辑模型和/或相应具体模型中的所有相应规则正确地捕获。

例如，保证设备系统300可以构建相应的数据结构(例如， ROBDD，该数据结构表示以下各项中的一个或多个：与网络范围的逻辑模型相关联的预期服务功能链规则的相应集合、与节点级逻辑模型相关联的预期服务功能链规则的相应集合、相应节点级逻辑模型和/或相应具体模型中的相应规则)，并比较相应数据结构(例如，ROBDD)以确定相应数据结构之间的等效性结果。为了说明，假设相应的数据结构是 ROBDD。当等效性结果指示相应ROBDD匹配时，保证设备系统300可以确定正确地捕获了与网络范围的逻辑模型相关联的预期服务功能链规则的相应集合和/或与节点级逻辑模型相关联的预期服务功能链规则的相应集合。另一方面，当等效性结果指示相应的ROBDD不匹配时，保证设备系统300可以确定未正确捕获预期服务功能链规则的相应集合。

可以基于从预期服务功能链规则的相应集合中的每一个以及相应节点级逻辑模型和/或相应具体模型中的每个相应规则生成的相应布尔函数来构造ROBDD。例如，来自相应布尔函数的每个布尔函数可以表示预期服务功能链规则的相应集合以及相应节点级逻辑模型和/或相应具体模型中的相应规则。

作为比较各种模型中的相应策略动作和/或规则的一部分，ROBDD还可以用于执行等效性检查。例如，保证设备系统300可以执行对相应具体模型、相应硬件模型以及相应节点级逻辑模型和/或网络范围的逻辑模型中的相应策略动作的比较。比较可以是在为相应策略动作构建的相应 ROBDD之间的等效性检查。

ROBDD还可以用于基于针对节点的模型(例如，节点级逻辑模型、具体模型、硬件模型)之间的等效性检查来确定是否在每个节点上正确地呈现了规则。例如，保证设备系统300可以为每个节点生成ROBDD，并且可以基于相应的节点级逻辑模型、相应的具体模型和相应的硬件模型中的所有规则，针对每个策略动作构建每个节点的ROBDD。然后，当等效性检查指示为相应策略动作构造的相应ROBDD之间的匹配时，保证设备系统300可以确定在每个节点上正确地呈现了预期服务功能链规则的相应集合。因此，等效性检查可以确认节点的模型中的策略动作是一致的并且不冲突。这表明规则和/或策略动作已由节点的软件和硬件适当地呈现。

当在步骤720-730确定了在网络上是否正确地配置了预期服务功能链时，保证设备系统300可以执行如前所述的包含检查、呈现检查和/或路由检查。可以针对网络中的每个节点执行包含检查、呈现和路由配置检查，以确定是否正确地配置了预期服务功能链。在正确地配置的服务功能链中，预期服务功能链的规则应在逻辑上被包含在与预期服务功能链的规则相关联的相应逻辑模型(例如，Li_模型272)中。这可以通过包含检查来检查，包含检查可以包括将预期服务功能链规则的集合与(一个或多个) 逻辑模型(例如，相应的节点级逻辑模型和/或网络范围的逻辑模型)进行比较。这种包含检查可以验证在节点上配置的预期服务功能链规则的集合是否按预期被包含在节点和/或网络的逻辑模型中。

此外，可以针对网络中的每个节点验证节点级逻辑模型、相应具体模型和相应硬件模型中的配置。可以为每个节点单独执行这些检查。可以比较每个节点的相应逻辑模型、具体模型和硬件模型(该比较作为呈现检查的一部分)，以验证与预期服务功能链相关联的规则是否被包括在节点的逻辑模型中并且被节点的软件和硬件正确地呈现。

包含和路由检查可以包括比较节点级逻辑模型中的预期服务功能链规则的相应集合和相应节点级逻辑模型和/或具体模型中的规则，比较节点级逻辑模型与相应的具体和/或硬件模型，和/或比较网络的逻辑模型(例如，逻辑模型270)和/或与网络的逻辑模型相关联的服务功能链规则的相应集合与关联于节点级逻辑模型的服务功能链规则的相应集合。如前所述，可以通过等效性检查来执行比较，其可以使用布尔函数和/或诸如 ROBDD之类的其他数据结构来执行。这样的数据结构可以表示被比较的模型、规则和/或值。

例如，可以为与相应节点级逻辑模型相关联的预期服务功能链规则的集合和相应节点级逻辑模型中的所有规则构建布尔函数集合。每个布尔函数可以对应于逻辑模型中的动作，并且如果相应的规则集针对分组执行该动作，则针对该分组报头返回“真”。如前所述，布尔函数可以由特定结构表示。为了清楚和解释的目的，在下面的示例中，布尔函数被表示为 ROBDD。然而，其他表示也是可能的并且在本文中考虑。

通过将逻辑模型(例如，逻辑模型270和/或Li_模型272)中的规则与具体模型(例如，Ci_模型274)和/或硬件模型(例如，Hi_模型276) 中的规则进行比较，可以针对每个节点执行呈现检查。呈现检查可以包括所比较的模型中的规则之间的等效性检查。如前所述，规则可以被表示为布尔函数和/或ROBBDD(或任何其他结构)，用于执行这种等效性检查。等效性检查可以检查逻辑模型是否已被正确地呈现到每个节点上。

如果节点级包含或呈现检查失败，则可以使用诸如ROBDD之类的数据结构来识别导致失败的EPG对契约。结果可以沿各个维度聚合。例如，节点级包含检查结果可以被聚合到单个网络范围的服务功能链包含结果。如果针对每个节点的节点级包含检查结果是肯定的(例如，通过)，则聚合的节点级结果将产生肯定的网络范围的服务功能包含结果。另一方面，如果针对一个或多个节点的节点级包含检查结果是否定的(例如，失败)，则聚合的节点级结果将产生否定的网络范围的服务功能包含结果 (例如，失败)。

EPG成对包含检查结果还可以跨节点地聚合到网络范围的EPG对包含结果。网络范围的EPG对包含结果将指示，基于聚合的EPG成对包含检查结果，是每个节点是否已通过EPG对包含检查还是有任何节点未通过 EPG对包含检查。执行的所有检查的结果以及聚合结果可以加时间戳并写入数据库或存储设备，或以其他方式报告。

下面进一步描述示例验证检查。

策略包含检查

可以执行策略包含检查以验证节点的逻辑模型(例如，Li_模型272) 中的规则不覆盖预期服务功能链规则，和/或为节点级逻辑模型构造的服务功能链规则的相应集合被包含在节点级逻辑模型中。这可以使用如前所述的ROBDD来完成。例如，可以针对策略动作(例如，接受)构造 ROBDD对。一个ROBDD使用服务功能链规则的集合构建，而第二个使用相应逻辑模型中的规则构建。两个ROBDD可以是逻辑“与”的。如果相应逻辑模型的结果ROBDD与预期服务链规则的ROBDD相同，则预期服务链规则不与相应逻辑模型中的规则冲突，并且包含检查将通过。这表明网络运营商根据预期服务功能链配置了逻辑模型，而不会在它们之间产生冲突。

为了说明，考虑具有下面的表中按优先级顺序示出的五个规则的节点级逻辑模型。

优先级	范围ID	源EPG	目的地EPG	动作
					1	100	11	14	容许
2	100	10	11	容许
					3	100	*	12	拒绝
4	100	13	12	容许
					5	*	*	*	拒绝

假设预期服务功能链具有EPG 10和11。用于预期服务功能链规则的容许(ALLOW)ROBDD将仅使用规则2来构造。节点级逻辑模型中的容许ROBDD将被构造为具有全部五个规则。当该ROBDD与第一个ROBDD逻辑“与”时，结果将是与第一个ROBDD匹配的ROBDD。因此，包含检查通过。这是预期的，因为规则2被包含在节点级逻辑模型中，并且节点级逻辑模型中的规则不与作为预期服务功能链的一部分的规则2冲突或覆盖规则2。

相反，如果预期服务功能链包含具有针对EPG 12和EPG 13的容许动作并且优先级为4或更低的服务链规则(例如，规则4)，则包含检查将失败，因为与服务链规则相关联的ROBDD与使用节点级逻辑模型中的全部五个规则构造的节点级逻辑模型中的ROBDD不同。这是预期的，因为节点级逻辑模型中包含的规则3将覆盖针对EPG 12和13的服务链规则。作为另一示例，如果预期服务功能链包含具有针对EPG 14和EPG的容许动作的服务链规则，则包含检查将失败，因为与针对EPG 14和15的服务链规则相关联的ROBDD将不与节点级逻辑模型的ROBDD匹配。这将是预期的，因为针对EPG 14和15的服务功能链规则未被包含在节点级逻辑模型中。

策略呈现检查

ROBDD还可以用于验证网络控制器(例如，控制器116)中的预期服务功能链规则已被正确地呈现到每个节点上。为此，可以分别使用节点的逻辑模型、具体模型和硬件模型中的规则来为每个节点(例如，交换机)和每个策略动作构建三个ROBDD。如果节点的三个ROBDD对于所有策略动作都相同，则服务功能链已被正确呈现到节点上。

路由配置检查

可以验证路由配置的各个方面。首先，每个节点(例如，交换机)上的RIB不应该导致服务(例如，与服务功能链相关联的服务)任一侧的终端主机之间的直接路径。其次，如果在服务的每一侧的主机之间需要L2 转发行为，则应该将它们的BD配置为允许该行为。在ACI网络的情况下，他们的BD应该泛洪未知的单播MAC地址，使得服务任一侧的主机可以知晓彼此的MAC地址。

对于SDN(包括ACI)，可以确定终端主机的位置以允许更高效的分组转发。可以与实际端点位置交叉验证所识别的接口，以验证分组在前往它们的最终目的地的途中被转发到服务设备。

如上所示，该保证机制可用于验证各个网络设备或节点上的配置与预期服务链配置一致。在前面的示例中，实现了ROBDD以验证在RIB上执行的策略和检查验证服务设备未被绕过。因此，验证机制可以检测允许分组直接在端点之间流动并绕过服务功能链的网络策略和路由配置错误，检测阻止服务功能链的元素之间的分组转发的网络策略和路由配置错误，以及检测将逻辑模型(例如，逻辑模型270和/或Li_模型272)中指定的服务功能链转换为节点上的软件和硬件配置中的错误。

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

图7C示出了用于保证服务功能链配置的另一示例方法。在该示例中，在步骤740，保证设备系统300可以获得网络(例如，网络环境 100)的一个或多个逻辑模型(例如，逻辑模型270、L_模型270A、L_模型270B等)。在某些情况下，保证设备系统300可以获得单个逻辑模型或逻辑模型的集合(例如图5A中所示的逻辑模型集合502)。保证设备系统300可以从一个或多个系统或节点(例如，一个或多个控制器116或叶节点104)获得一个或多个逻辑模型。在一些情况下，保证设备系统 300可以生成逻辑模型或修改收集的逻辑模型。逻辑模型可以包括一个或多个网络范围的逻辑模型，例如逻辑模型270。

在步骤742，保证设备系统300可以基于一个或多个逻辑模型来识别预期服务功能链(例如，服务功能链140)。预期服务功能链可以包括多个服务功能，它们一起执行用于与服务功能链相关联的给定应用的功能。

在步骤744，基于一个或多个逻辑模型，保证设备系统300可以为网络中的每个节点(例如，脊节点102和/或叶节点104)生成相应的特定于节点的逻辑模型(例如，Li_模型272)。相应的特定于节点的逻辑模型可以是网络的逻辑模型(例如，逻辑模型270)的节点级(例如，交换机级)版本。相应的特定于节点的逻辑模型可以将逻辑模型投射到节点上。例如，相应的特定于节点的逻辑模型可以包括逻辑模型270中与该特定节点有关的数据和/或配置，例如逻辑模型270中应该传播到或者呈现在特定节点处的数据和/或配置。为了说明，网络环境100中的叶节点1的相应的特定于节点的逻辑模型可以包括来自逻辑节点270的应被存储或呈现在节点处的数据和/或配置(例如，策略、规则、对象、对象属性、路由配置、要求、逻辑设置等)。

在步骤746，保证设备系统300可以为网络中的每个节点获得相应的具体模型(例如，Ci_模型274)和相应的硬件模型(例如，Hi_模型 276)。相应的具体模型可以包括在节点的软件或环境(例如，节点的网络操作系统)上呈现的规则。规则可以基于相应的特定于节点的逻辑模型中的数据。相应的硬件模型可以包括在节点的硬件(例如，TCAM存储器)上呈现或存储的规则。

在步骤748，保证设备系统300可以基于一个或多个逻辑模型和/或相应的特定于节点的逻辑模型来识别用于预期服务功能链的预期服务功能链规则的集合。例如，保证设备系统300可以识别用于预期服务功能链的被包含在每个节点的相应特定于节点的逻辑模型中的预期服务功能链规则的集合。

如前所述，预期服务功能链规则的集合可以包括与预期服务功能链中的特定EPG有关的逻辑模型(例如，相应的特定于节点的逻辑模型)中的规则集合。例如，预期服务功能链规则的集合可以包括逻辑模型中匹配与预期服务功能链相关联的一个或多个EPG的规则。因此，预期服务功能链规则的集合可以包括在语法上与预期服务功能链的元素中的EPG相匹配的规则。

在步骤750，保证设备系统300可以基于网络范围的逻辑模型(例如，逻辑模型270)，相应的特定于节点的逻辑模型、相应的具体模型和/ 或相应的硬件模型中的预期服务功能链规则的集合的比较，来确定是否在网络上正确地配置了预期服务功能链。如前所述，该比较可以涉及一个或多个策略包含检查、策略呈现检查和/或路由检查。

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

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

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

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

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

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

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

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

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

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

总之，在一些示例中，系统获得网络逻辑模型，并且对于网络中的每个节点，获得节点级逻辑、具体和硬件模型。系统识别服务功能链，并确定服务功能链规则的相应集合。对于每个节点，系统确定在节点级逻辑模型和/或具体模型中是否正确地捕获了服务功能链规则的相应集合以产生节点包含检查结果。基于具体模型、硬件模型以及节点级逻辑模型或网络逻辑模型中的至少一个中的策略动作的比较，系统确定是否在每个节点上正确地呈现了服务功能链规则的相应集合以产生节点呈现检查结果。基于节点包含检查结果和节点呈现检查结果，系统确定是否正确地配置了服务功能链。

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

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

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

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

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

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

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

Claims

1.一种方法，包括：

获得与网络相关联的多个模型，所述多个模型包括：

表示针对所述网络定义的规则的网络范围的逻辑模型；

针对所述网络中每个节点的相应节点级逻辑模型，所述相应节点级逻辑模型至少包括针对所述网络范围的逻辑模型定义的规则的一部分，所述规则的所述一部分包括针对所述网络范围的逻辑模型定义的所述规则中对应于所述节点的那些规则；

针对所述网络中每个节点的相应具体模型，其中所述相应具体模型包括在所述节点的软件环境方面的软件呈现的规则；以及

针对所述网络中每个节点的相应硬件模型，其中所述相应硬件模型包括在所述节点的硬件方面的硬件呈现的规则；

基于所述多个模型，识别所述网络中的预期服务功能链；

基于所述多个模型中的至少一个模型中的相应规则，针对所述预期服务功能链确定预期服务功能链规则的相应集合，这些相应规则对应于与所述预期服务功能链中的一个或多个元素相关联的一个或多个端点组；

对于每个节点，确定与相应节点级逻辑模型和相应具体模型中的至少一个模型相关联的预期服务功能链规则的相应集合是否被所述相应节点级逻辑模型和所述相应具体模型中的所述至少一个模型中的所有相应规则正确地捕获，以产生针对所述节点的相应节点级包含检查结果；

基于对相应节点级逻辑模型和所述网络范围的逻辑模型中的至少一个模型、相应具体模型、和相应硬件模型中的相应策略动作的比较，确定与所述网络范围的逻辑模型相关联的预期服务功能链规则的相应集合是否在每个节点上被正确地呈现，以产生节点级呈现检查结果；以及

基于相应节点级包含检查结果和节点级呈现检查结果，确定所述预期服务功能链是否在所述网络上被正确地配置。

2.如权利要求1所述的方法，还包括：

聚合针对每个节点的相应节点级包含检查结果，以产生针对所述预期服务功能链的网络范围的包含检查结果；

聚合针对每个节点的节点级呈现检查结果，以产生针对所述预期服务功能链的网络范围的呈现检查结果；并且

其中，确定所述预期服务功能链是否在所述网络上被正确地配置是基于所述网络范围的包含检查结果和所述网络范围的呈现检查结果进行的。

3.如权利要求2所述的方法，还包括：

分析每个节点的相应路由信息库(RIB)；以及

基于每个节点的RIB，确定与对应于所述预期服务功能链的分组相关联的路由配置是否保证所述分组被路由到所述预期服务功能链而不绕过所述预期服务功能链中的一个或多个服务功能。

4.如权利要求3所述的方法，还包括：

在以下情况下确定所述预期服务功能链在所述网络上被正确地配置：

所述网络范围的包含检查结果表明，对于每个节点，预期服务功能链规则的相应集合被相应节点级逻辑模型和相应具体模型中的至少一个模型中的所有相应规则正确地捕获；

所述网络范围的呈现检查结果表明，与所述网络范围的逻辑模型相关联的预期服务功能链规则的相应集合在每个节点上被正确地呈现；以及

与对应于所述预期服务功能链的分组相关联的所述路由配置被确定为保证所述分组被路由到所述预期服务功能链，而不绕过所述预期服务功能链中的一个或多个服务功能。

5.如权利要求1至4中任一项所述的方法，其中，确定与相应节点级逻辑模型和相应具体模型中的至少一个模型相关联的预期服务功能链规则的相应集合是否被所述相应节点级逻辑模型和所述相应具体模型中的所述至少一个模型中的所有相应规则正确地捕获包括：

生成表示以下各项的相应数据结构：所述预期服务功能链规则的相应集合、以及所述相应节点级逻辑模型和所述相应具体模型中的所述至少一个模型中的所有相应规则；以及

比较所述相应数据结构以确定所述相应数据结构之间的等效性结果。

6.如权利要求5所述的方法，其中，所述相应数据结构包括相应简化有序二元决策图，并且其中确定与相应节点级逻辑模型和相应具体模型中的至少一个模型相关联的预期服务功能链规则的相应集合是否被所述相应节点级逻辑模型和所述相应具体模型中的所述至少一个模型中的所有相应规则正确地捕获包括：

当所述等效性结果表明所述相应简化有序二元决策图匹配时，确定所述预期服务功能链规则的相应集合被正确地捕获；以及

当所述等效性结果表明所述相应简化有序二元决策图不匹配时，确定所述预期服务功能链规则的相应集合未被正确地捕获。

7.如权利要求6所述的方法，其中，所述相应简化有序二元决策图是基于相应布尔函数来构造的，该相应布尔函数是根据以下各项生成的：所述预期服务功能链规则的相应集合中的每个预期服务功能链规则、以及所述相应节点级逻辑模型和所述相应具体模型中的所述至少一个模型中的每个相应规则。

8.如权利要求7所述的方法，其中，来自所述相应布尔函数的每个布尔函数表示如下项中的相应规则：所述预期服务功能链规则的相应集合、以及所述相应节点级逻辑模型和所述相应具体模型中的所述至少一个模型。

9.如权利要求1至4中任一项所述的方法，其中，对相应节点级逻辑模型和所述网络范围的逻辑模型中的至少一个模型、相应具体模型、以及相应硬件模型中的相应策略动作的比较包括：在针对所述相应策略动作构造的相应数据结构之间进行等效性检查。

10.如权利要求9所述的方法，其中，确定与所述网络范围的逻辑模型相关联的预期服务功能链规则的相应集合是否在每个节点上被正确地呈现包括：

当所述等效性检查表明针对所述相应策略动作所构造的相应数据结构之间匹配时，确定所述预期服务功能链规则的相应集合在每个节点上被正确地呈现。

11.一种系统，包括：

一个或多个处理器；以及

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

获得与网络相关联的多个模型，所述多个模型包括：

表示针对所述网络定义的规则的网络范围的逻辑模型；

基于所述多个模型，识别所述网络中的预期服务功能链；

基于对相应节点级逻辑模型和所述网络范围的逻辑模型中的至少一个模型、相应具体模型、以及相应硬件模型中的相应策略动作的比较，确定与所述网络范围的逻辑模型相关联的预期服务功能链规则的相应集合是否在每个节点上被正确地呈现，以产生节点级呈现检查结果；以及

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

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

分析每个节点的相应路由信息库(RIB)；以及

14.如权利要求13所述的系统，所述至少一个计算机可读存储介质存储有附加指令，当所述附加指令由所述一个或多个处理器执行时，使得所述系统进行以下操作：

与对应于所述预期服务功能链的分组相关联的路由配置被确定为保证所述分组被路由到所述预期服务功能链，而不绕过所述预期服务功能链中的一个或多个服务功能。

15.如权利要求11至14中任一项所述的系统，其中，确定与相应节点级逻辑模型和相应具体模型中的至少一个模型相关联的预期服务功能链规则的相应集合是否被所述相应节点级逻辑模型和所述相应具体模型中的所述至少一个模型中的所有相应规则正确地捕获包括：

16.如权利要求15所述的系统，其中，所述相应数据结构包括相应简化有序二元决策图，并且其中确定与相应节点级逻辑模型和相应具体模型中的至少一个模型相关联的预期服务功能链规则的相应集合是否被所述相应节点级逻辑模型和所述相应具体模型中的所述至少一个模型中的所有相应规则正确地捕获包括：

17.如权利要求16所述的系统，其中，所述相应简化有序二元决策图是基于相应布尔函数来构造的，所述相应布尔函数是根据所述预期服务功能链规则的相应集合中的每个预期服务功能链规则以及所述相应节点级逻辑模型和所述相应具体模型中的所述至少一个模型中的每个相应规则生成的，其中每个布尔函数表示如下项中的相应规则：所述预期服务功能链规则的相应集合、以及所述相应节点级逻辑模型和所述相应具体模型中的所述至少一个模型。

18.如权利要求11至14中任一项所述的系统，其中，对相应节点级逻辑模型和所述网络范围的逻辑模型中的至少一个模型、相应具体模型、以及相应硬件模型中的相应策略动作的比较包括：在针对所述相应策略动作构造的相应数据结构之间进行等效性检查，

并且其中确定预期服务功能链规则的相应集合是否在每个节点上被正确地呈现包括：

当所述等效性检查表明针对所述相应策略动作构造的相应数据结构之间匹配时，确定所述预期服务功能链规则的相应集合在每个节点上被正确地呈现。

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

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

获得与网络相关联的多个模型，所述多个模型包括：

表示针对所述网络定义的规则的网络范围的逻辑模型；

基于所述多个模型，识别所述网络中的预期服务功能链；

20.如权利要求19所述的非暂时性计算机可读存储介质，其中，对相应节点级逻辑模型和所述网络范围的逻辑模型中的至少一个模型、相应具体模型、以及相应硬件模型中的相应策略动作的比较包括：在针对所述相应策略动作构造的相应数据结构之间进行等效性检查，

21.如权利要求20所述的非暂时性计算机可读存储介质，其中，确定与相应节点级逻辑模型和相应具体模型中的至少一个模型相关联的预期服务功能链规则的相应集合是否被所述相应节点级逻辑模型和所述相应具体模型中的所述至少一个模型中的所有相应规则正确地捕获包括：

生成表示所述预期服务功能链规则的相应集合以及所述相应节点级逻辑模型和所述相应具体模型中的所述至少一个模型中的所有相应规则的相应简化有序二元决策图，其中所述相应简化有序二元决策图是基于相应布尔函数来生成的，每个相应布尔函数表示来自以下各项中的至少一者的规则：所述预期服务功能链规则的相应集合、所述相应节点级逻辑模型、和所述相应具体模型；以及

比较所述相应简化有序二元决策图以确定所述相应简化有序二元决策图是否匹配。

22.一种装置，包括：

用于获得与网络相关联的多个模型的构件，所述多个模型包括：

表示针对所述网络定义的规则的网络范围的逻辑模型；

用于基于所述多个模型来识别所述网络中的预期服务功能链的构件；

用于基于所述多个模型中的至少一个模型中的相应规则来针对所述预期服务功能链确定预期服务功能链规则的相应集合的构件，这些相应规则对应于与所述预期服务功能链中的一个或多个元素相关联的一个或多个端点组；

用于对于每个节点进行以下操作的构件：确定与相应节点级逻辑模型和相应具体模型中的至少一个模型相关联的预期服务功能链规则的相应集合是否被所述相应节点级逻辑模型和所述相应具体模型中的所述至少一个模型中的所有相应规则正确地捕获，以产生针对所述节点的相应节点级包含检查结果；

用于进行以下操作的构件：基于对相应节点级逻辑模型和所述网络范围的逻辑模型中的至少一个模型、相应具体模型、以及相应硬件模型中的相应策略动作的比较，确定与所述网络范围的逻辑模型相关联的预期服务功能链规则的相应集合是否在每个节点上被正确地呈现，以产生节点级呈现检查结果；以及

用于基于相应节点级包含检查结果和节点级呈现检查结果来确定所述预期服务功能链是否在所述网络上被正确地配置的构件。

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

24.一种计算机可读介质，包括指令，当所述指令由计算机执行时，使得所述计算机执行如权利要求1至10中任一项所述的方法的步骤。