CN110754065A - 网络的逻辑级和硬件级之间的网络验证 - Google Patents
网络的逻辑级和硬件级之间的网络验证 Download PDFInfo
- Publication number
- CN110754065A CN110754065A CN201880040486.8A CN201880040486A CN110754065A CN 110754065 A CN110754065 A CN 110754065A CN 201880040486 A CN201880040486 A CN 201880040486A CN 110754065 A CN110754065 A CN 110754065A
- Authority
- CN
- China
- Prior art keywords
- model
- network
- format
- fabric
- software
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0866—Checking the configuration
- H04L41/0873—Checking configuration conflicts between network elements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/02—Standardisation; Integration
- H04L41/0246—Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols
- H04L41/0266—Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols using meta-data, objects or commands for formatting management information, e.g. using eXtensible markup language [XML]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/085—Retrieval of network configuration; Tracking network configuration history
- H04L41/0853—Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0894—Policy-based network configuration management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0895—Configuration of virtualised networks or elements, e.g. virtualised network function or OpenFlow elements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/12—Discovery or management of network topologies
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/12—Discovery or management of network topologies
- H04L41/122—Discovery or management of network topologies of virtualised topologies, e.g. software-defined networks [SDN] or network function virtualisation [NFV]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/14—Network analysis or design
- H04L41/145—Network analysis or design involving simulating, designing, planning or modelling of a network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0893—Assignment of logical groups to network elements
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
公开了用于确保网络环境中的租户转发的系统、方法和计算机可读介质。可以在网络环境的第1层、第2层和第3层中确定网络保证,网络保证包括网络环境中的内部(例如,结构中)转发和内部‑外部(例如,结构外部)转发。可以使用逻辑配置、软件配置和/或硬件配置来执行网络保证。
Description
相关申请的交叉引用
本申请要求于2017年06月19日递交的题为“NETWORK VALIDATION BETWEEN THELOGICAL LEVEL AND THE HARDWARE LEVEL OF A NETWORK(网络的逻辑级和硬件级之间的网络验证)”的美国临时专利申请第62/521,763号的优先权,其还要求于于2017年07月28日递交的题为“NETWORK VALIDATION BETWEEN THE LOGICAL LEVEL AND THE HARDWARELEVEL OF A NETWORK(网络的逻辑级和硬件级之间的网络验证)”的美国专利申请第15/663,587号以及于2017年07月28日递交的题为“VALIDATION OF LAYER 3USING VIRTUALROUTING FORWARDING CONTAINERS IN A NETWORK(在网络中使用虚拟路由转发容器进行的第3层验证)”的美国专利申请第15/663,627号的优先权。通过引用将每个申请的全部内容合并至本文。
技术领域
本技术涉及网络配置和保证,更具体地,涉及网络内部和外部的路由和转发配置和保证。
背景技术
计算机网络变得越来越复杂,通常在网络的各个层都涉及低层以及高层配置。例如,计算机网络一般包括众多访问策略、转发策略、路由策略、安全性策略、服务质量(QoS)策略等等,它们共同定义了网络的整体行为和操作。网络运营商具有各种各样的配置选项,使得可根据用户的需求定制网络。尽管可用的不同配置选项为网络运营商提供了很大程度的灵活性和对网络的控制,但它们也增加了网络的复杂性。在许多情况下,配置过程可能变得高度复杂。毫不奇怪,网络配置过程越来越容易出错。另外,对高度复杂的网络中的错误进行故障排除可能极其困难。识别网络中意外行为的根本原因的过程可能是艰巨的任务。
附图说明
为了描述可以获得本公开的上述和其他优点和特征的方式,将通过参考在附图中示出的上面简要描述的原理的特定实施例来呈现对这些原理的更具体的描述。应理解,这些附图仅描绘了本公开的示例性实施例,因此不应认为是对其范围的限制,通过使用附图,利用附加特征和细节描述和解释了本文的原理,在附图中:
图1A和1B示出了示例网络环境;
图2A示出了网络的示例对象模型;
图2B示出了图2A的示例对象模型中的租户对象(tenant object)的示例对象模型;
图2C示出了图2A的示例对象模型中的各对象的示例关联;
图2D示出了用于实现图2A的示例对象模型的示例模型的示意图;
图3A示出了示例网络保证设备(network assurance appliance);
图3B示出了用于网络保证的示例系统;
图3C示出了用于网络保证的示例系统的示意图;
图3D示出了验证的策略的示例;
图4示出了用于分布式故障代码聚合的平台;
图5A和图5B示出了网络保证和故障代码聚合的示例方法实施例;
图6示出了网络保证设备的示例性检查器;
图7示出了示例网络环境;
图8示出了用于第1层接口的网络保证的示例方法实施例;
图9示出了用于第2层联网的网络保证的示例方法实施例;
图10示出了用于第3层联网的网络保证的示例方法实施例;
图11示出了用于网络保证的示例配置;
图12示出了用于跨逻辑组/VRF的网络保证的示例网络环境和配置;
图13示出了用于RIB和FIB的网络保证的示例网络环境和配置;
图14示出了用于RIB和FIB的网络保证的示例方法实施例;
图15第3层out的网络保证的示例方法实施例;
图16示出了BD-L3out关联的示例网络图;
图17示出了用于BD-L3out关联的网络保证的示例方法实施例;
图18示出了用于学习到的网络保证的示例方法实施例;
图19示出了网络重叠的示例图;
图20示出了用于重叠子网的网络保证的示例方法实施例;
图21示出了根据各种实施例的示例网络设备;以及
图22示出了根据各种实施例的示例计算设备。
具体实施方式
下面详细讨论本公开的各种实施例。虽然讨论了具体实现方式,但应该理解,仅是出于说明目的而这样做的。相关领域的技术人员将认识到,在不脱离本公开的精神和范围的情况下,可以使用其他组件和配置。因此,以下描述和附图是说明性的而不应被解释为限制性的。描述了许多具体细节以提供对本公开的透彻理解。然而,在某些情形下,没有描述众所周知的或传统的细节以避免模糊本描述。在本公开中参考一个实施例或参考实施例可以是参考相同的实施例或任意实施例;并且,这样的参考指的是实施例中的至少一个。
对“一个实施例”或“实施例”的参考意味着结合该实施例描述的特定特征、结构或特性被包括在本公开的至少一个实施例中。在说明书中各处出现的短语“在一个实施例中”不一定都指代相同的实施例,也不是与其他实施例互斥的单独或替代的实施例。此外,描述了可以由一些实施例而不由其他实施例展示的各种特征。
本说明书中使用的术语在本公开的上下文中以及在其中每个术语被使用的特定上下文中通常具有其在本领域中的普通含义。替代语言和同义词可以用于本文所讨论的任何一个或多个术语,并且本文是否详述或论述某一术语不应被看作具有特殊意义。在一些情况下,提供了某些术语的同义词。对一个或多个同义词的记载不排除对其他同义词的使用。本说明书中任何地方的对示例(包括本文所讨论的任何术语的示例)的使用仅是说明性的,并且不旨在进一步限制本公开或任何示例术语的范围和含义。同样地,本公开不限于本说明书中给出的各种实施例。
不意图限制本公开的范围,下面给出根据本公开的实施例的工具、装置、方法、及其相关结果的示例。注意,为了方便读者,可能在示例中使用标题或副标题,这绝不应限制本公开的范围。除非另有定义,否则本文使用的技术和科学术语具有本公开所属领域的普通技术人员通常理解的含义。在发生冲突的情况下,以包括定义的本文档为准。
将在下面的描述中阐述本公开的其他特征和优点,并且其部分将从描述中变得清晰可见,或者可以通过实践本文公开的原理来进行学习。借助于所附权利要求中具体指出的工具和组合,可以实现和获得本公开的特征和优点。根据以下描述和所附权利要求,本公开的这些和其他特征将变得更加完全地显现出来,或者可以通过实践本文阐述的原理来进行学习。
概述
在独立权利要求中陈述了本发明的方面,并且在从属权利要求中陈述了优选的特征。一个方面的特征可单独地应用于每个方面或者与其他方面结合来应用。
公开了用于网络的网络保证的系统、方法和非暂时性计算机可读介质(CRM)。该系统、方法和非暂时性计算机可读介质被配置为:从控制器接收第一格式的全局逻辑模型,全局逻辑模型包含关于连接到网络结构的端点如何在结构内进行通信的指令,以及从结构中的一个或多个网络设备接收软件模型,软件模型是来自全局逻辑模型的指令的至少一个子集并具有在一个或多个网络设备上可执行的第二格式,指令的子集是来自全局逻辑模型的、特定于一个或多个网络设备的可操作性的指令。该系统、方法和非暂时性计算机可读介质还被配置为:创建第一格式的局部逻辑模型,局部逻辑模型是所接收的全局逻辑模型的至少一部分,其中全局逻辑模型包含关于连接到网络结构的端点如何在结构内进行通信的指令,将所创建的局部逻辑模型的至少一部分和所接收的软件模型的至少一部分转换为公共格式,以及对公共格式的局部逻辑模型和公共格式的软件模型中的重叠字段的内容进行比较,其中,比较的肯定结果表示一个或多个网络设备从所接收的全局逻辑模型准确地创建了所接收的软件模型。在一些示例中,第一和第二格式彼此不同,公共格式是第一和第二格式中的一个或与第一和第二格式二者都不同。
在一些示例中,该系统、方法和CRM可以被配置为:从结构中的一个或多个网络设备接收从软件模型转换的硬件配置的硬件模型。该系统、方法和CRM可以被配置为:将所接收的软件模型的至少一部分和所接收的硬件模型的至少一部分转换为公共格式,以及对公共格式的软件模型和公共格式的硬件模型中的重叠字段的内容进行比较,并且比较的肯定结果表示一个或多个网络设备将软件模型准确地转换为了硬件模型。在一些示例中,该硬件模型的格式与第一格式和第二格式不同,第二格式是第二格式和第三格式中的一个,或其与第二格式和第三格式都不同。
还公开了用于网络的网络保证中的事件生成的系统、方法和CRM。该系统、方法和CRM可以被配置为:从控制器接收第一格式的全局逻辑模型,该全局逻辑模型包含关于连接到网络结构的端点如何通过结构中的一个或多个网络设备相互通信的指令,以及从结构中的一个或多个网络设备接收软件模型,该软件模型是来自全局逻辑模型的指令的至少一个子集并具有可在一个或多个网络设备上执行的第二格式,该指令子集是来自全局逻辑模型、特定于一个或多个网络设备的可操作性的指令,以及接收从软件模型转换而来的硬件配置的硬件模型。该系统、方法和CRM还可以配置为验证接收到的全局逻辑模型、所接收的软件模型和所接收的硬件模型的准确性,并给予该验证生成一个或多个事件。
在一些示例中,系统、方法和CRM可以被配置为:存储先前的配置以及该先前的配置的相应的有效性,识别所接收的全局逻辑模型、所接收的软件模型和/或所接收的硬件模型中的与所存储的具有相应的不利的有效性的先前的配置相同或类似的任何配置,以及响应于该识别的肯定结果,报告将接收的全局逻辑模型、所接收的软件模型和/或所接收的硬件模型中的潜在缺陷。
在一些示例中,该一个或多个事件包括信息事件,该信息事件响应于验证中未识别出不一致。在其他示例中,一个或多个事件包括错误事件,该错误事件响应于验证中识别出至少一个不一致。在一些示例中,错误事件可以根据至少一个不一致的严重性具有不同的严重性级别。在一些示例中,响应于错误事件,系统进一步包括指令,当该指令由至少一个处理器执行时,使得该至少一个处理器:单独地验证所接收的全局逻辑模型、所接收的软件模型和/或所接收的硬件模型中的所接收的二级内容与针对其生成至少一个不一致的原始内容相关。
还公开了用于指令结构中的配置的正确部署的第1层网络保证检查系统、方法和CRM。该系统、方法和CRM可以被配置为:从控制器接收包含关于连接到网络结构的端点如何在结构内进行通信的指令的全局逻辑模型,指令包括一个或多个网络设备的至少一个接口的访问策略,以及从结构中的一个或多个网络设备接收软件模型,软件模型是来自全局逻辑模型的指令的至少一个子集,指令子集是来自全局逻辑模型的、特定于一个或多个网络设备的可操作性的指令。在一些示例中,该系统、方法和CRM可以配置为:验证所接收的全局逻辑模型中的访问策略的至少第1层被正确配置在一个或多个网络设备上,在所接收的软件模型中识别一个或多个网络设备的一个或多个端口的物理链路和软件链路的报告状态,获得一个或多个网络设备的一个或多个端口的物理链路和软件链路的实际状态,对物理链路和软件链路的报告状态与所获得的物理链路和软件链路的实际状态进行比较,以及基于验证和/或比较生成一个或多个事件。
在一些示例中,系统、方法和CRM可以被配置为:确认所接收的全局逻辑模型中存在交换机简档和接口简档,交换机简档和接口简档已正确链接,以及接口简档被正确链接到全局简档。
在一些示例中,系统、方法和CRM可以被配置为:响应于确定一个或多个访问策略未配置在至少一个接口上,生成错误事件。
在一些示例中,系统、方法和CRM可以被配置为:响应于指示物理链路的报告状态为活动而物理链路的实际状态为关闭、或物理链路的报告状态为关闭而物理链路的实际状态为活动的比较,生成错误事件
在一些示例中,系统、方法和CRM可以被配置为:响应于指示软件链路的报告状态为活动而软件链路的实际状态为关闭、或物理交换机的报告状态为关闭而物理交换机的实际状态为活动的比较,生成错误事件。
在一些示例中,系统、方法和CRM可以被配置为:轮询一个或多个网络设备,以获得物理链路和软件链路的实际状态。
还公开了用于指令结构中的配置的正确部署的第2层网络保证检查系统、方法和CRM。该系统、方法和CRM可以被配置为:从控制器接收第一格式的全局逻辑模型,所述全局逻辑模型包含关于连接到网络结构的端点如何在所述结构内进行通信的指令,以及从所述结构中的一个或多个网络设备接收软件模型,所述软件模型是来自所述全局逻辑模型的指令的至少一个子集并具有在所述一个或多个网络设备上可执行的第二格式,所述指令的子集是来自所述全局逻辑模型的、特定于所述一个或多个网络设备的可操作性的指令。
该系统、方法和CRM可以被配置为:创建所述第一格式的局部逻辑模型,所述局部逻辑模型是所接收的全局逻辑模型的至少一部分,其特定于一个或多个网络设备的可操作性,将所创建的局部逻辑模型的第2层内容的至少一部分和所接收的软件模型的第2层内容的至少一部分转换为公共格式,以及对所述公共格式的所述局部逻辑模型和所述公共格式的所述软件模型中的至少部分第二层重叠字段的内容进行比较。
在一些示例中,比较的肯定结果表示一个或多个网络设备先前至少部分准确地从全局逻辑模型创建了软件模型。该系统、方法和CRM还可以被配置为:验证全局逻辑模型的至少部分第2层内容被正确地配置。
在一些示例中,要进行转换和比较的第2层内容的至少一部分包括VLAN信息和接口信息,从而至少部分地检查任何网桥域和/或端点组(EPG)的正确部署。在一些示例中,要进行验证的第2层内容中的至少一部分包括,在第2层,正确配置了访问策略,正确配置了EPG,多个EPG在存在于网络设备中的至少一个上时不使用相同的虚拟局域网(VLAN),不存在重叠的VLAN,同一交换机的交换机级别上不存在重复的VLAN,同一交换机的同一端口上的端口级别上也不存在重复的VLAN。该系统、方法和CRM还可以配置为:系统、方法和CRM还可以被配置为从结构中的一个或多个网络设备接收从软件模型转换而来的第三硬件配置格式的硬件模型,将所接收的软件模型的第2层内容的至少一部分和/或硬件模型的第2层内容的至少一部分转换为公共格式,并对公共格式的所接收的软件模型中的至少部分第2层重叠字段的内容与公共格式的所接收的硬件模型进行比较。
在一些示例中,比较的肯定结果表示一个或多个网络设备将软件模型的第2层部分至少准确地转换为硬件模型。
在一些示例中,第2层内容的至少一部分要经受转换,并且比较包括每个EPG的VLAN。
该系统、方法和CRM也可以配置为从结构外部的DVS接收分布式虚拟交换机(DVS)逻辑模型,将所接收的DVS逻辑模型的第2层内容的至少一部分和/或所接收的全局硬件模型的第2层内容的至少一部分转换为第三公共格式,并将第三公共格式的所接收的全局逻辑模型的至少部分第2层重叠字段的内容与第三格式的所接收的DVS逻辑模型进行比较。
在一些示例中,第三比较的一个肯定结果表示全局逻辑模型中的VLAN在整个网络中已正确分配。
还公开了用于指令结构中的配置的正确部署的第3层网络保证检查系统、方法和CRM。该系统、方法和CRM可以被配置为:从控制器接收第一格式的全局逻辑模型,全部逻辑模型包含关于连接到网络结构的端点如何在结构内进行通信的指令,并且全局逻辑模型包括至少一个虚拟路由和转发实例(VRF),以及从结构中的一个或多个网络设备接收软件模型,软件模型是来自全局逻辑模型的指令的至少一个子集并具有在一个或多个网络设备上可执行的第二格式,指令的子集是来自全局逻辑模型的、特定于一个或多个网络设备的可操作性的指令;该系统、方法和CRM还可以配置为:针对每个网络设备,将全局逻辑模型转换为第一格式的局部逻辑模型,局部逻辑模型是所接收的全局逻辑模型的至少一部分,全局逻辑模型特定于相应的每个网络设备的可操作性,针对接收到的全局逻辑模型中的至少一个VRF中的每个VRF创建一个容器,为所创建的容器中的每个填充与VRF相关联的网络设备中的每个的局部逻辑模型和软件模型,以及确认所填充的容器中的桥接域(BD)子网匹配。在一些示例中,填充包括集合并(set union),使得所填充的VRF容器不包含任何重复的BD子网。
在一些示例中,在所填充的容器中包括没有相应的局部逻辑模型的软件模型表示不正确的额外项。在一些示例中,在所填充的容器中包括没有相应的软件模型的局部逻辑模型表示在全局逻辑模型的部署中存在错误。
该系统、方法和CRM还可以配置为:从局部逻辑硬件模型中减去软件模型中的相应的一个软件模型,从软件模型中的一个软件模型中减去相应的局部逻辑模型。在一些示例中,减法之间的不匹配表示差异。在一些示例中,响应于减法之间的不匹配而生成错误事件。在一些示例中,响应于所填充的容器中的桥接域(BD)子网中的不匹配而生成错误事件。
还公开了用于指令结构中的配置的正确部署的第3层网络保证检查系统、方法和CRM。该系统、方法和CRM可被配置成接收全局逻辑模型、多个软件模型和多个硬件模型,其中全局逻辑模型中包括虚拟路由实例(VRF)的。该系统、方法和CRM还可以被配置为:从全局逻辑模型创建多个局部逻辑模型,针对所接收的VRF创建VRF容器,使用所接收的软件模型、所接收的硬件模型和/或所创建的局部逻辑模型的子集来填充所创建的VRF容器,该子集由结构中与所接收的全局逻辑模型的VRF相关联的一个或多个网络设备定义,以及识别所填充的VRF容器中所接收的软件模型、所接收的硬件模型和/或所创建的局部逻辑模型中的一个或多个,其中所识别的一个或多个模型对应于结构中不与所接收的全局逻辑模型的VRF相关联的一个或多个网络设备。在一些示例中,识别的肯定结果表示全局逻辑模型中存在差异。
在一些示例中,系统、方法和CRM可以被配置为:验证全局逻辑模型与软件模型和/或硬件模型相一致。在一些示例中,系统、方法和CRM可以被配置为对软件模型中的一个与局部逻辑模型中的一个之间的重叠字段内容进行比较。在一些示例中,系统、方法和CRM可以被配置为对软件模型中的一个与硬件模型中的一个之间的重叠字段内容进行比较。在一些示例中,系统、方法和CRM可以被配置为:响应于识别的肯定结果,生成错误事件。
在一些示例中,软件模型基于全局逻辑模型。在一些示例中,硬件模型基于相应的软件模型。
还公开了用于执行结构中的配置的正确部署的RIB-FIB网络保证检查的系统、方法和CRM。该系统、方法和CRM可以被配置为:获得网络设备的转发信息库(FIB)和路由信息库(RIB),将FIB和/或RIB转换为公共格式,从RIB和FIB中移除重复项,确定RIB中的RIB项目是否与FIB中的项目相匹配,响应于该确定的否定结果,识别何时FIB中的条目被另一RIB条目覆盖。在一些示例中,可以响应于识别的否定结果来生成错误事件。
在一些示例中,系统、方法和CRM可以被配置为确定FIB中的条目的IP地址/掩码和下一跳与RIB条目相匹配。在一些示例中,系统、方法和CRM可以被配置为识别FIB中的FIB条目,该FIB条目具有与不匹配的RIB条目匹配以及覆盖该不匹配的RIB条目的IP地址/掩码的下一跳。在一些示例中,系统、方法和CRM可以被配置为标识FIB中的FIB条目,该FIB条目具有完全覆盖不匹配RIB条目的替代性子网前缀。
在一些示例中,FIB从网络设备的线路控制器获得,RIB从网络设备的SUP控制器提取。在一些示例中,网络设备是结构中的叶节点或脊节点,系统、方法和CRM可以被配置为从叶节点或脊节点获得包含FIB和RIB的软件模型。在一些示例中,系统、方法和CRM可以被配置为确定应用于RIB中的每个条目。
还公开了用于结构中的配置的正确部署的跨端点组网络保证检查的系统、方法和CRM。该系统、方法和CRM可以被配置为接收全局逻辑模型、多个软件模型和/或多个硬件模型,其中该全局逻辑模型包括虚拟路由和转发实例(VRF),VRF在其下具有至少一个桥接域(BD)以及至少一个相关联的EPG。该系统、方法和CRM还可以被配置为从所接收的全局逻辑模型创建多个局部逻辑模型,针对所接收的全局逻辑模型的VRF创建VRF容器,使用软件模型、硬件模型和/或局部逻辑模型的子集填充所创建的VRF容器,该子集由结构中在其上部署VRF的叶节点定义,确定所接收的全局逻辑模型的VRF容器中的至少一个EPG中的任何EPG和不位于该VRF容器中的EPG之间是否存在安全性契约,以及响应于确定的肯定结果,验证一个或多个子网不冲突。
在一些示例中,至少一个BD中的每个BD包括至少一个子网。在一些示例中,至少一个EPG的每个EPG包括至少一个子网。
该系统、方法和CRM还可以被配置为确定第一BD中与第一EPG(在该处存在契约)相关联的第一子网集,确定第二BD中与第二EPG(在该处存在契约)相关联的第二子网集,以及验证第一子网集不与第二子网集相交。该系统、方法和CRM还可以被配置为针对每个子网验证下一跳。
在一些示例中,响应于一个或多个子网之间存在冲突而生成错误事件。在一些示例中,响应于第一子网集与第二子网集相交而生成错误事件。
还公开了用于执行结构中的配置的重叠子网网络保证检查的系统、方法和CRM。该系统、方法和CRM可以被配置为从控制器接收第一格式的全局逻辑模型,该全局逻辑模型关于与网络结构连接的端点如何与在结构内进行通信的指令,以及从结构中的一个或多个网络设备接收软件模型,该软件模型是来自全局逻辑模型的指令的子集并具有在一个或多个网络设备上可执行的第二格式,该指令的子集是来自全局逻辑模型的、特定于一个或多个网络设备的可操作性的指令。该系统、方法和CRM还可以被配置为确定所接收的全局逻辑模型和所接收的软件模型中是否存在一个或多个重叠桥接域(BD)子网,以及响应于一个或多个BD子网的重叠BD子网的确定,确定该一个或多个重叠BD子网中的任何BD子网满足例外。在一些示例中,确定中一者的否定结果至少部分地表示子网已被正确地部署。在一些示例中,响应于重叠且不存在可应用的异常而生成错误事件。
该系统、方法和CRM可以被配置为检查软件模型的IP地址和掩码,以及当IP地址和掩码中的两个或多个重叠时,确定存在重叠。在一些示例中,在网络设备中的每个的每个VRF中执行定位。在一些示例中,例外是当BD子网在学习到的路由内时。在一些示例中,确定中一者的肯定结果至少部分地表示子网未被正确地部署。在一些示例中,例外是当重叠的BD子网是相同的。
还公开了用于结构中的配置的正确部署的L3out网络保证检查的系统、方法和CRM。该系统、方法和CRM可以被配置为从控制器接收第一格式的全局逻辑模型,所述全局逻辑模型包含关于连接到网络结构的端点如何在所述结构内进行通信的指令,以及从所述结构中的一个或多个网络设备接收软件模型,所述软件模型是来自所述全局逻辑模型的指令的至少一个子集并具有在所述一个或多个网络设备上可执行的第二格式,所述指令的子集是来自所述全局逻辑模型的、特定于所述一个或多个网络设备的可操作性的指令。该系统、方法和CRM还可以用于创建所述第一格式的局部逻辑模型,局部逻辑模型是所接收的全局逻辑模型的特定于一个或多个网络设备的可操作性的至少一部分,将所创建的局部逻辑模型的第3层out(L3out)内容的至少一部分和/或所接收的软件模型的L3out内容的至少一部分转换为公共格式,以及将来自公共格式的所创建的局部逻辑模型的至少部分L3out重叠字段地内容与所接收的软件模型的公共格式进行比较。在一些示例中,比较的肯定结果至少部分地表示内部子网已正确地泄露到结构外部。在一些示例中,在一些示例中,要经受比较的至少一些L3out重叠字段包括叶节点、端口和网络,从而至少部分地验证L3out接口已正确部署。在一些示例中,至少部分要经受比较的L3out重叠字段包括网络设备,从而至少部分地验证L3out环回已正确部署。
在一些示例中,经受比较的至少部分L3out重叠字段包括叶节点和下一跳,从而至少部分验证L3out静态路由已正确部署。在一些示例中,要经受比较的至少部分L3out重叠字段包括字段,从而至少部分验证端点组已正确部署。
该系统、方法和CRM可以被配置为验证软件模型的最长前缀匹配(LPM)表中的每个泄漏的内部子网具有下一跳,该下一跳标识哪个边界叶节点泄露了该子网,其中,验证的肯定结果至少部分地表示内部子网已被正确地泄漏到结构外部。
该系统、方法和CRM可以被配置为验证边界叶的LPM表具有标识网络设备的泄漏的内部子网的下一跳,其中验证的肯定结果至少部分地表示内部子网已被正确泄漏到结构外部。
还公开了用于执行结构中的配置的正确部署的BD-L3out关联网络保证检查的系统、方法和CRM。该系统、方法和CRM可以被配置为从控制器接收第一格式的全局逻辑模型,该全局逻辑模型包含关于连接到网络结构的端点如何在结构内通信的指令,识别全局逻辑模型中指定为公共的桥接域(BD)子网,响应于识别的肯定结果,验证所识别的BD与L3out相关联。在一些示例中,识别的否定结果和验证的肯定结果至少部分地表示BD-第3层out(L3out)关系的正确配置。
该系统、方法和CRM可以被配置为确定所识别的BD中是否存在具有与其相应的L3out不同的端点组(EPG)的任何BD。该系统、方法和CRM还可以被配置为响应于确认的肯定结果,确认具有与其相应的L3out不同的端点组(EPG)的所识别的BD中的任何BD之间存在契约。
在一些示例中,确认的肯定结果至少部分地表示BD-L3out关系的正确配置。在一些示例中,可以响应于识别的肯定结果而生成错误事件。在一些示例中,可以响应于验证的否定结果而生成错误事件。在一些示例中,可以响应于确认的否定结果而生成错误事件。
还公开了用于执行结构中的配置的正确部署的学习到的路由网络保证检查的系统、方法和CRM。该系统、方法和CRM可以被配置为从结构中的一个或多个网络设备接收软件模型,该软件模型来自全局逻辑模型的指令的子集并具有在一个或多个网络设备上可执行的第二格式,该指令的子集是来自全局逻辑模型的、特定于一个或多个网络设备的可操作性的指令。该系统、方法和CRM还可以被配置为从多个网络设备中识别从外部设备导入外部子网的源叶节点,源叶节点具有在虚拟路由转发实例(VRF)下的L3out,从多个网络设备中识别叶节点子分组,该叶节点子分组包括源叶节点和具有源叶节点的VRF下的L3out或BD的源叶节点,确认所导入的外部子网与叶节点组的一个或多个叶节点的软件模型相一致,在源叶节点处,确定所导入的网络的下一跳是请求泄露的网络设备,以及在其他叶节点处,确定所导入的网络的下一跳是至少源叶节点。在一些示例中,确定和确认的肯定结果至少部分地代表导入的路由的正确传播。在一些示例中,确认的否定结果表示导入的路由的不正确传播。在一些示例中,确认的否定结果表示导入的路由的不正确传播。
该系统、方法和CRM还可以被配置为确认所导入的外部子网在叶节点组中的所有叶节点的软件模型中都是一致的,进一步包括指令,该指令当被至少一个处理器执行时,使得至少一个处理器确认所导入的外部子网在叶节点组的所有叶节点中的软件模型的最长前缀匹配(LPM)表中都是一致的。该系统、方法和CRM还可以被配置为从控制器接收全局逻辑模型,该全局逻辑模型包含关于连接到网络结构的端点如何通过结构中的一个或多个设备彼此通信的指令,以及确认全局逻辑模型中任何导入的路由与多个叶节点中的边界叶节点的所接收的软件模型中的任何导入的路由一致。
该系统、方法和CRM还可以被配置为确认全局逻辑模型中任何导入的路由与多个叶节点中的边界叶节点的所接收的软件模型中的任何导入的路由一致包括指令,该指令当被至少一个处理器执行时,使得至少一个处理器确认边界叶节点的软件模型的LPM表包括在全局逻辑模型的第3层out(L3out)的端点组(EPG)中找到的任何导入的路由。
该系统、方法和CRM还可以被配置为确认全局逻辑模型中的任何导入的路由与多个叶节点中的边界叶节点的所接收的软件模型中的任何导入的路由一致包括指令,该指令当被至少一个处理器执行时,使得至少一个处理器确认边界叶节点的软件模型的LPM表包括在全局逻辑模型的L3out的EPG中找到的任何导入的路由,并且不包括其他导入的路由,除非从不同的边界叶节点或不同的L3out导入。
描述
所公开的技术解决了本领域中准确高效地发现大型复杂网络或数据中心中的问题的需求。本技术涉及用于网络化环境的第1层、第2层和第3层中的网络保证的系统、方法和计算机可读介质。本技术还涉及用于网络保证的系统、方法和计算机可读介质,以进行网络化环境中的内部-内部(例如,结构内)转发和内部—外部(例如,结构外)转发。可以使用逻辑配置、软件配置和/或硬件配置来执行该网络保证。本技术将在下面的公开中如下描述。讨论开始于跨以应用为中心的维度的网络保证和故障代码聚合的介绍性讨论。接下来是网络保证的介绍性讨论和示例计算环境的描述,如图1A和图1B中所示。讨论将继续进行针对用于网络保证、网络建模以及跨逻辑或以应用程序为中心的维度的故障代码聚合的系统和方法的描述,如图2A至图2D、图3A至图3D、图4和图5A至图5B所示。讨论将继续进行针对用于路由和转发保证及检查的系统和方法的描述,如图3至图20所示。讨论以针对示例网络设备的描述(如图21所示),以及针对示例计算设备(如图22所示)的描述结束,包括适合于容宿软件应用和执行计算操作的示例硬件组件。
现在,本公开转向对跨逻辑或以应用程序为中心的维度的网络保证和分布式故障代码聚合的讨论。
网络保证是确保或确定网络按照网络运营商的意图行事并且已经被恰当配置(例如,网络正在做预期它要做的事情)。意图可以包含各种网络操作,例如,桥接、路由、安全性、服务链化(service chaining)、端点、合规性、QoS(服务质量)、审计等。意图可以体现在为网络和各个网络元件(例如,交换机、路由器、应用、资源等)定义的一个或多个策略、设置、配置等中。然而,经常地,网络运营商所定义的配置、策略等是不正确的或者未能准确地反映在网络的实际行为中。例如,网络运营商为一种或多种类型的流量指定配置A,但后来发现网络实际上正在将配置B应用于该流量或以与配置A不一致的方式处理该流量。这可能是许多不同原因导致的结果,例如硬件错误、软件缺陷、变化的优先级、配置冲突、一个或多个设置的误配置、设备不适当的规则呈现、意外错误或事件、软件升级、配置更改、失败等。作为另一示例,网络运营商实现配置C,但一个或多个其他配置导致网络以与配置C的实现方式所反映的意图不一致的方式行动。例如,当配置C与网络中的其他配置冲突时会导致这样的情形。
本文中的方法可以通过对网络的各个方面建模和/或执行一致性检查以及其他网络保证检查来提供网络保证。本文的方法还可使得能够按照以任何软件或应用为中心的维度对硬件级(例如,网络交换机级)错误进行识别和可视化。非限制性示例可视化可以包括:1)每租户错误聚合、2)每应用程序简档错误聚合、3)每端点组对聚合、以及4)每契约错误聚合。通过这种方式,数据中心运营商可以快速查看在整个网络结构中影响特定租户或其他逻辑实体的硬件错误,甚至可以按其他维度(例如端点组)进行深入挖掘,以仅查看那些相关的硬件错误。这些可视化加快了根本原因分析的速度,从而改善数据中心和应用可用性指标。给定网络结构的规模,用于创建这些可视化的聚合可以以分布式方式完成。
在此上下文中,网络保证平台可以在每个单独的网络设备(例如,交换机)运行保证操作员,并且发出与网络设备相关联的故障代码。逻辑策略丰富器可以将硬件ID(例如,范围、pcTag等)映射到软件定义网络(SDN)结构配置(例如以应用为中心的基础设施(ACI)结构配置)中定义的逻辑策略实体。该映射可以产生丰富的(enriched)故障代码。可以将该丰富的故障代码发送到聚合层,以进行聚合。例如,多个节点(例如,HADOOP)可收集该丰富的故障代码并将它们作为(密钥、标签)发送到聚合层。
在一些情况下,通过将每个密钥的聚合器运行为单独的缩减器(reducer),聚合层可以水平扩展。每个密钥可以代表不同的聚合维度。维度的非限制性的示例包括租户、契约、应用简档、端点组(EPG)对,等等。这为大型网络结构的操作员提供了针对该特定聚合维度的网络结构的健康状况的集成视图。例如,这可以提供每个租户、契约、应用简档,EPG对等的健康状况。
如前所述,故障代码聚合可实现可以表示网络各个方面的逻辑模型。模型可包括网络的数学或语义模型,包括但不限于网络的策略、配置、要求、安全性、路由、拓扑结构、应用、硬件、过滤器、契约、访问控制列表、EPG、应用简档、租户,等等。可以实现模型以提供网络保证,来确保网络被恰当地配置,并且网络的行为将与通过由网络运营商实现的具体策略、设置、定义等所反映的预期行为一致(或保持一致)。与涉及发送和分析数据分组并观察网络行为的传统网络监视不同,可以通过建模执行网络保证,而不必摄取任何分组数据或监视流量或网络行为。这可产生先见之明、洞悉、和后见之明:可以在问题发生之前加以预防,在发生问题时识别问题,并在问题发生后立即修复问题。
可以对网络的性质进行数学建模以确定性地预测网络的行为和状况。数学模型可以对控制、管理和数据平面进行抽象,并且可以使用诸如符号化、形式验证、一致性、图形、行为之类的各种技术。如果(一个或多个)模型指示适当的行为(例如,没有不一致、冲突、错误等),则可以确定网络是健康的。如果建模指示适当的行为但有点不一致,则可以确定网络是可实现功能的,但不是完全健康的。如果建模指示不适当的行为和错误,则可以确定网络是不能实现功能的并且不健康。如果通过建模检测到不一致或错误,则对相应的(一个或多个)模型的详细分析可以允许非常准确地识别出一个或多个基础或根本问题。
建模可能消耗多种类型的数据和/或事件,其对网络的大量行为方面进行建模。这样的数据和事件可能影响网络的各个方面,例如底层服务、覆盖服务、租户连通性、租户安全性、租户EP移动性、租户策略、资源等。
已经描述了跨维度的网络保证和故障代码聚合的各种方面,本公开现在转到对用于网络保证和故障代码聚合的示例网络环境的讨论。
图1A示出了示例网络环境100(例如,数据中心)的图示。网络环境100可以包括可以表示网络环境100的物理层或基础设施(例如,底层)的结构120。结构120可以包括脊节点(脊节点)102(例如,脊路由器或交换机)和叶节点(叶节点)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。分类可以基于例如网络段标识符,例如,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可以形成通过上行(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(逻辑呈现模型或逻辑运行时模型)、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处的配置或逻辑模型导致的任何依赖性、冗余、冲突等。
因此,L_模型270A是第一/最高层模型。L_模型270A由控制器116基于来自操作员的输入而创建。因此,L_模型270A中的内容是关于结构120中的各个叶节点104和脊节点102如何与端点122通信的特定指令。在一些示例中,任何特定的L_模型270A都可以是“全局”的,因为其可以在中心点处生成,以包括用于所有叶节点104和脊节点102的指令,或用于它们中的仅一部分的指令(理论上来讲,该部分可以小到一个叶节点104或脊节点120,但这是不寻常的)。格式基于GUI接口和/或Rest API允许用户输入的任何内容。可以存在多个L_模型270A配置。L_模型270A的格式是用于生成指令的用户的程序格式,并且其不能由控制器116使用。控制器116将作为第一级的L_模型270A转换为作为第二级的LR_模型270B,其中LR_模型270B是包含L_模型270A的内容的逻辑表示,其格式在控制器116上可读并且可向叶节点104和脊节点102传输。由于这是格式改变,L_模型270A和LR_模型270B的信息内容可以是相同的,但本申请不受此限制,并且可以省略或添加该内容以创建LR_模型270B。
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中的交换机解释和/或编译的特定标识符或标签(例如,用作分类符的硬件平面标识符)相关联。
控制器116将L_模型270A和/或LR_模型270B(本文中单独地和集体地称为“L_模型270A/B”)传输到结构120中的相关叶节点104和脊节点102。相关性可以由控制器116定义为所有叶节点104和脊节点102,或者其某个子集。作为非限制性示例,图IB的结构120包括叶节点1、叶节点2以及叶节点N。控制器116处的L_模型270A/B可以仅包括用于叶节点1和叶节点N的内容,而不包括用于叶节点2的内容。因此,控制器116将L_模型270A/B传输到所有叶节点1、叶节点2和叶节点N,或仅传输到相关叶节点1和叶节点N。
然后,控制器116和/或接收到L_模型270A/B的每个特定叶节点104和脊节点102从接收到的模型提取/隔离出内容,以形成特定于该特定叶节点或脊节点的内容的局部子集。此提取/隔离出的内容定义第三级Li_模型272,该Li_模型272是交换机级或交换机特定的逻辑模型;因此,Li_模型272是“局部的”,因为其是特定于该交换机的(尽管其可以包括关于该交换机与其他交换机的关系的内容)。因此,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_模型272L1可以表示投射到叶节点1(104)或在叶节点1(104)处实现的L_模型270A和/或LR_模型270B。因此,对于结构120上的个体设备(例如,叶节点104、脊节点102等),可以从L_模型270A和/或LR_模型270B生成Li_模型272。作为非限制性示例,如果L_模型270A/B包括用于叶节点1和叶节点N的指令,则叶节点1将提取/隔离出与叶节点1的操作相关的内容,以定义局部Ll_模型272,叶节点N将提取/隔离出与叶节点N的操作相关的内容,以定义局部LN_模型272。由L_模型270A/B不包括用于叶节点2的指令,那么即使叶节点2接收到L_模型270A/B,其也不会创建它自己的局部L2_模型,但本申请不限于此。从局部Li_模型272是L_模型270A/B的子集的角度来看,这表示内容的变化。从局部Li_模型272是从LR_模型270B中的内容的提取/隔离的角度来看,通常不存在格式的改变,但本申请不限于此。
在一些情况下,可以使用JSON(JavaScript对象表示法)来表示Li_模型272。例如,Li_模型272可以包括JSON对象,例如规则、过滤器、条目和范围。
每个Li_模型272的格式可以不是可以由在其上创建了该Li_模型272的特定叶节点104或脊节点102执行的格式(例如,该格式可能不可以在该叶节点或脊节点的本地操作系统上执行)。因此,每个叶节点104和脊节点102可以本地创建第四级,通过将Li_模型272的格式转换为该特定叶节点104或脊节点102的操作系统可以运行的格式。这产生Ci_模型274,其在本文中被称为软件模型或具体模型。因此,作为非限制性示例,其中叶节点N由L_模型270A/B创建了局部LN_模型272,叶节点N将进而由LN_模型272创建局部CN_模型274。因此,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的形式。
由Ci_模型274创建局部Li_模型274表示至少格式的改变。Li_模型272的内容可以与Ci_模型274相同,使得不存在内容改变,尽管引用不限于此且内容可能仅重叠。例如,并非来自Li_模型272的所有内容都被包括在相应的Ci_模型274中。类似地,特定的叶节点104或脊节点102可以将不存在于Li模型272中的内容添加到Ci_模型274。
在一些情况下,Li_模型272和Ci_模型274可以具有相同或相似的格式。例如,Li_模型272和Ci_模型274可以基于JSON对象。具有相同或相似格式可以协助Li_模型272和Ci_模型274中的对象进行比较以确定是否对等或一致。如本文进一步描述的,这种对等性或一致性检查可以用于网络分析和保证。
创建Ci_模型274作为第四级的每个叶节点104和脊节点102将进而创建第五级作为局部硬件模型Hi_模型276。Hi_模型276表示来自Ci_模型274的实际硬件配置,其被提取出并被存储在本地存储器中。从Ci_模型274到Hi_模型276的转变表示格式改变和内容改变二者。类似地,特定的叶节点104或脊节点102将不存在于Ci_模型274中的内容添加到Hi_模型276。
因此,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中的个体操作员(操作员)。这允许实现本地水平扩展架构,其能够扩展到结构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中的矛盾或冲突的策略)。
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(例如,来自边界叶节点)的路由反射服务不具有健康问题。
逻辑线头(Lint)和实时变化分析
保证设备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之间是否存在规定数量(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和其他节点以收集各种类型的数据。在一些场景中,保证设备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能够进行对等性或一致性的比较。这种对等性检查可以有助于网络分析和保证,如本文进一步解释的。
交换机逻辑策略还可以执行变化分析并生成针对在L_模型270A和/或LR_模型270B中发现的问题的线头事件(lint event)或记录。线头事件或记录可用于为用户或网络运营商生成警报。
策略操作员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可以生成与端点违反相关的事件,例如重复的IPs、APIPA等,租户路由检查器324可以生成与BD、VRF、子网、路由表前缀等的部署相关的事件。
图3C示出了用于网络(例如,网络环境100)中的静态策略分析的示例系统的示意图。静态策略分析器360可以执行保证检查,以检测配置违规、逻辑线头事件、矛盾或冲突的策略、未使用的契约、不完整的配置等。静态策略分析器360可以检查L_模型270A中用户的一个或多个意图的规范,以确定控制器116中是否有任何配置与用户的一个或多个意图的规范不一致。
静态策略分析器360可以包括在保证设备300中执行或容宿的操作员310中的一个或多个。然而,在其他配置中,静态策略分析器360可运行与操作员310和/或保证设备300分离的一个或多个操作员或引擎。例如,静态策略分析器360可以是VM、VM集群、或服务功能链中的端点的集合。
静态策略分析器360可以从逻辑模型收集过程366接收L_模型270A并且接收为L_模型270A中的每个特征(例如,对象)定义的规则368作为输入。规则368可以基于MIM 200中的对象、关系、定义、配置、以及任何其他特征。规则368可以指定条件、关系、参数、和/或用于识别配置违规或问题的任何其他信息。
此外,规则368可以包括用于识别语法违规或问题的信息。例如,规则368可包括用于执行语法检查的一个或多个规则。语法检查可以验证L_模型270A的配置是否完整,并且可以帮助识别未使用的配置或规则。语法检查还可验证分层MIM 200中的配置是否完整(已定义),并识别已定义但未使用的任何配置。为进行说明,规则368可以指定L_模型270A中的每个租户都应被配置一个情境;L_模型270A中的每个契约都应指定提供者EPG和消费者EPG;L_模型270A中的每个契约都应指定主体、过滤器和/或端口;等等。
规则368还可以包括用于执行语义检查和识别语义违规或问题的规则。语义检查可以检查冲突的规则或配置。例如,规则1和规则2可能有别名(aliasing)问题,规则1可能比规则2更具体,从而产生冲突/问题,等等。规则368可以定义可能导致别名规则、冲突规则等的条件。为进行说明,规则368可以指定如果针对两个对象之间的特定通信的允许策略的优先级高于针对两个对象之间的同一通信的拒绝策略,则该允许策略可能与该拒绝策略相冲突,或者针对对象的一种规则使得另一规则显得不必要。
静态策略分析器360可以将规则368应用于L_模型270A,以检查L_模型270A中的配置,并基于检测到的任何问题而输出配置违规事件370(例如,警报、日志、通知等)。配置违规事件370可以包括语义或语义问题,例如,不完整的配置、冲突的配置、别名规则、未使用的配置、错误、策略违反、配置错误的对象、不完整的配置、不正确的契约范围、不正确的对象关系等。
在一些情况下,静态策略分析器360可以迭代遍历基于L_模型270A和/或MIM 200生成的树中的每个节点,并在树中的每个节点上应用规则368以确定是否有任何节点发生违规(例如,不完整的配置、不恰当的配置、未使用的配置等)。当静态策略分析器360检测到任何违规时,它可以输出配置违规事件370。
图4示出了用于网络保证平台434的示例配置400。网络保证平台434可以在每个叶节点104上运行保证操作员402,以从叶节点104生成和发出故障代码。在一些情况下,保证操作员402可以是例如来自图3A所示的操作员310中的一个或多个操作员。故障代码可以表示错误,例如硬件错误。保证操作员402可以将原始故障404发送到逻辑策略丰富器406。
逻辑策略丰富器406可以将硬件标识(例如,范围、pcTag等)映射到结构配置(例如,ACI结构配置)中定义的逻辑策略实体。例如,逻辑策略丰富器406可以将硬件标识映射到特定租户、EPG、应用简档(AP)、契约,等等。逻辑策略丰富器406可以基于该映射生成索引故障(indexed故障)480,并将索引故障408发送给租户聚合器418、420、422、424。在一些情况下,可以将索引故障408作为对(例如,密钥和标签对)发送给聚合器。每个密钥可以代表一特定的维度,例如租户、契约、应用简档和EPG对等。
聚合器418、420、422、424可以表示一聚合层。在一些情况下,聚合器418、420、422、424可以被特定地设置为沿预定维度聚合,例如沿租户(例如,聚合器418)、契约(例如,聚合器420)、应用简档(例如,聚合器422)、EPG对(例如,聚合器24),等等。聚合器418、420、422、424可以沿特定维度生成故障,例如,租户410的故障、契约412的故障、应用简档414的故障、EPG对416的故障,等等。
然后,网络保证平台434可以生成和/或存储针对特定维度的可视化数据。例如,网络保证平台434可以维持租户错误可视化426、契约错误可视化428、应用简档错误可视化430、EPG对错误可视化432,等等。该可视化可以提供沿SDN(例如ACI网络)中特定维度的错误的硬件级可见性。此外,可以将租户错误可视化426、契约错误可视化428、应用简档错误可视化430、EPG对错误可视化432存储在一个或多个相应存储位置中,例如数据库或存储服务器。
图5A示出了网络保证模型的示例流程图。在步骤500,该方法涉及数据收集。数据收集可以包括针对运营商意图的数据的收集,例如,结构数据(例如,拓扑结构、交换机、接口策略、应用策略、端点组等)、网络策略(例如,BD、VRF、L2输出(L2Out)、L3输出(L3Out)、协议配置等)、安全性策略(例如,契约、过滤器等)、服务链策略等等。数据收集还可包括针对具体硬件模型的数据,例如,网络配置(例如,RIB/FIB、VLAN、MAC、ISIS、DB、BGP、OSPF、ARP、VPC、LLDP、MTU、QoS等)、安全性策略(例如,TCAM、ECMP表等)、端点动态(例如,EPM、COOP EPDB等)、统计信息(例如,TCAM规则命中、接口计数器、带宽等)。
在步骤502,该方法可以涉及形式建模和分析。形式建模和分析可以涉及确定逻辑模型与硬件模型之间的对等关系,例如,模型之间的安全性策略等。
在步骤504,该方法可以涉及智能事件生成。可以使用深度对象分层结构来生成智能事件以进行详细分析,例如:租户、叶节点、VRF、规则;过滤器、路由、前缀、端口号。
在步骤506,该方法可以涉及可视化。可以在用户友好的GUI中使用形式模型来识别问题以进行分析和调试。
图5B示出了用于故障代码聚合的示例方法。在步骤520处,保证操作员402获得对应于网络中一个或多个网络设备(例如,叶节点104)的相应的故障代码。在步骤522处,逻辑策略丰富器406将该一个或多个网络设备和/或相应的故障代码映射到在网络的逻辑策略模型中定义的相应的逻辑策略实体,以产生故障代码映射。该逻辑策略模型可以是基于SDN或ACI配置生成的结构和/或网络的模型。
在步骤524处,聚合器418、420、422、424沿网络中相应的逻辑策略维度对故障代码映射中的一个或多个进行聚合,以产生跨相应的逻辑策略维度的故障代码聚合。在步骤526处,针对相应的逻辑策略维度中的每个,网络保证平台434呈现沿该相应的逻辑策略维度的一个或多个硬件级错误。在一些情况下,网络保证平台434可以生成可视化数据或接口数据,以沿相应的逻辑策略维度呈现一个或多个硬件级错误。这样的数据可以基于跨相应的逻辑策略维度的故障代码聚合。
所公开的技术解决了本领域中保证网络环境中的租户转发的需求。本技术涉及用于网络化环境的第1层、第2层和第3层中的网络保证的系统、方法和计算机可读介。本技术还涉及用于网络保证的系统、方法和计算机可读介质,以进行网络化环境中的内部-内部(例如,结构内)转发和内部—外部(例如,结构外)转发。在一些示例中,该网络保证可以在非结构网络化环境中进行。可以使用逻辑配置、软件配置和/或硬件配置来执行网络保证。
如上所述,某些实施例涉及策略的创建,该策略将定义端点122如何能够通过结构120中的叶节点104和节点102彼此通信。本文中公开的实施例包括上文中关于图2D讨论的五级指令信息的创建和传播,该五级指令信息将配置叶节点104和脊节点102以促进该通信。每级可以包括内容和/或格式的改变,但此需求并不总是该情况。
作为非限制性示例,图7示出了网络化环境700中的示例配置。租户配置740(例如,L_模型270A配置)可以将VRF1配置为BD1。BD1可以具有一个或多个配置的子网(例如,10.1.*、100.2.*,等等)。子网可以被指定为私有的或公共的。在一些示例中,子网可以默认指定为私有的。在此示例中,已使子网100.2.*为公共的(例如,可从外部结构120和网络化环境700访问)。子网100.2.*可以与Web服务器746相关联。例如,Web服务器746可以经由子网100.2.*提供对结构120中的一个或多个web服务(到设备)的访问以及对结构120外部的访问(通过网络设备114)。
为了促进到Web服务器746和从Web服务器746的通信,必须将租户配置740从控制器116发送到结构120的叶节点104和脊节点102。公共子网100.2.*也必须从边界叶节点(例如,叶节点N)泄露到外部设备(例如,网络设备114)。为了租户与结构120外部进行通信,外部网络设备(例如,网络设备114)必须将子网(例如,175.*)泄露到边界叶节点(例如,叶节点N)。然后,可以将泄露的外部子网(例如,泄露的路由)传播到结构120的叶节点104和脊节点102的L3表。VRF可以在第3层域中操作,并且可以使得路由表的多个实例能够在同一路由器(例如,叶节点104和脊节点102,等等)上同时共存。由于路由实例是独立的,可以跨VRF使用相同或重叠的IP地址,而不会发生冲突。
BD可以作为结构中的第2层转发结构,并且可以实现第2层桥接网络和第3层路由网络之间的双向业务流。每个BD可以驻留在VRF中。每个BD还可以定义一个或多个子网。定义的子网中的IP地址可以属于指定的BD。
逻辑组(EPG)可以是一个管理对象,它是一个命名的逻辑实体并且包含端点的集合。端点可以是直接或间接连接到网络的设备(例如、服务器、虚拟机、网络附连存储,等等)。每个EPG可以分派到BD。EPG可以具有地址(例如,标识)、位置、属性(例如,版本或补丁级别),并且可以是物理的或虚拟的。EPG的端点成员可以是动态的或静态的。子网特可以在EPG处定义。
L3out可以是用于扩展第3层以进行外部通信(例如,在结构和/或网络环境之外)的结构。L3out可以绑定到VRF。L2out可以是用于扩展第2层以进行外部通信(例如,在结构和/或网络环境之外)的结构。L2out可以绑定到BD。
一旦配置了控制器116,控制器116可以将L_模型270A/B推送到结构120的叶节点104和脊节点102。在一些情况下,可以将L_模型270A/B推送到结构120的所有叶节点104和脊节点102。在其他情况下,可以将L_模型270A/B的部分推送到结构120的负责路由和转发与L_模型270A/B一致的数据的叶节点104和脊节点102。例如,当BD1定义子网10.1.1.*时,配置到该BD的叶节点104(例如,负责通过子网10.1.1*传输数据)可以接受与BD1相关的L_模型270A/B配置。
L_模型270A/B可以用于填充结构120的叶节点104和脊节点102处的转发和路由表(L3)、VLAN表(L2)、接口(LI)和端点表(L2和L3)。例如,当BD1定义子网10.1.1.*时,LPM表填充子网的条目以及到来的分组要被路由到该处的目的地(例如,叶节点3)。
在一些示例中,LPM表可以是转发表的一部分。LPM表可以对一个或多个子网指定与LPM表中多于一个条目匹配的目的地址。可以选择匹配表条目中最具体的条目,即具有最长子网掩码的条目。LPM表还可以包括与子网s、静态路由、动态(学习的)路由、L3接口和L3回路相关的信息。图7中填充的LPM表包括表742、748、1802和1806,它们是Ci_模型。
结构120中的每个叶节点104可以具有第3层(L3)表(例如,最长前缀匹配(LPM)表)。例如,L3表742可以驻留在叶节点2上,而L3表748可以驻留在叶节点N上。L3表可以包括子网和下一跳的列表。例如,当叶节点N的租户请求访问Web服务器746,叶节点N在L3表748中查找与服务器746(例如,100.2.*)相关联的子网,并确定下一跳(例如,叶节点2)。相应地,叶节点N可以将来自该租户的分组经由脊节点中的一个引导到叶节点2。
在其他示例中,结构120外部的设备可以请求访问公共Web服务器746。在这些示例中,边界叶节点(例如,叶节点N)将公共子网(例如,100.2.*)泄露到外部网络设备(例如,网络设备114)。外部网络设备可以维持路由和转发表(例如,Table 744),其中存储了泄露的子网信息。当结构120外部的设备请求访问Web服务器120时,网络设备114可以通过表744确定将该请求转发到何处。然后,该请求将被路由到边界叶节点(例如,叶节点N)。然后,可以根据叶节和脊节点的L3表将该请求路由到争取的目的地。
在其他示例中,结构120内的租户可以访问结构外部的设备(通过与外部网络连接的边界叶节点)。例如,租户(例如,端点4)可以请求访问结构120外部的设备,L3表742可以确定访问外部设备的下一跳是通过叶节点N(例如,子网175.*→叶节点N)。这条学习到的路由从网络设备114泄漏到边界叶节点N,然后根据需要传播到该结构的其他叶节点和脊柱节点。然后,边界叶节点N可以经由下一跳网络设备114(例如,来自L3表748)将该请求路由到结构外部。
网络化环境700还包括逻辑组、第3层环回和第3层接口之间的通过安全性契约(例如,750)进行的路由和转发。虽然未示出,L3表还包括第3层环回和第3层接口。
上述指令和其他指令由控制器116部署为L_模型270A/B,并由单独的叶节点104和脊节点102执行到Ci_模型274和Hi_模型276的转换。网络保证是这样的一过程,通过该过程,L、C和H模型和相关内容的各种创建和传播被正确地编程、部署和创建,等等。作为非限制性示例,通过验证模型的一致性,可以在逻辑、软件和/或硬件模型处执行单级检查。还可以通过检查模型是否被正确地转换为其他级(例如,叶节点104和脊节点102是否正确地将L_模型270A/B转变为Ci_模型274(逻辑到具体检查)以及将Ci_模型274转换为Hi_模型276(具体到硬件检查))来执行检查。
网络保证可以通过保证设备300来验证。设备300可以针对驻留L、H和C模型配置轮询网络化环境(例如,100、结构120)的设备(例如,脊节点102,叶节点104,控制器116)。例如,应用可以针对L_模型270A/B配置轮询控制器116,以及针对针对Ci_模型274和Hi_模型276配置轮询叶节点104和脊节点102。在从一个或多个设备(例如,脊节点102、叶节点104、控制器116)接收一个或多个L、C和H模型配置后,设备300可以使用图6中示出的检查器620来执行一个或多个验证,检查器620可以以关于图3B讨论的方式操作。应理解,应当理解,由设备300或检查器620之一进行的活动可以由它们中的另一设备进行。
检查器620可以是设备300的组件。检查器620可以接收一个或多个配置(例如,通过经由统一收集器314进行的轮询在设备300处接收)作为输入,以及接收可能由网络100和/或结构120提供的其他输入。在一些示例中,可以接收由控制器116提供的一个或多个L_模型622配置(例如,L_模型270A/B)作为输入。类似地,报告叶节点104和脊节点102提供一个或多个C_模型624配置(例如,Ci_模型274)和一个或多个H_模型626配置(例如,Ci_模型276),检查器620将其接收作为输入。检查器620也可以接收来自结构120和/或网络100的组件的其他数据。一个类型的检查是单级一致性检查,其中检查特定的接收到的模型622/624/626,以确认如最初编程的操作员的意图在模型中被表示和正确地配置。例如,检查器620可以对L_模型配置622执行一致性检查。例如,对L_模型配置622执行语法分析(例如,配置、设置、排版(typographical),等等)。一致性检查可以在创建配置时确定操作员的意图是否表示在L_模型配置622中。
L_模型配置622上的第1层一致性检查的一非限制性示例是部署在“管理失效(admin down)”接口上的EPG。该检查可以从L-模型中读取EPG部署信息和接口管理(Interface Admin)状态。EPG部署信息可以标识在该处物理部署EPG的叶节点和接口,并且如果部署正确,该叶节点和接口将与接口管理状态信息中的叶节点和接口匹配。如果发现状态为“管理失效”,则检查可能会失败。
第2层检查的一非限制性示例是交换机上重叠的封装VLAN(encap VALN)。该检查可以从L-模型中读取EPG部署信息和接口端口策略,以获得叶路由器、接口和封装VLAN。EPG部署可以按照叶节点,在叶节点上分组。在每个这样的(叶节点)分组中,该检查可以查找具有相同封装VLAN的两个不同的EPG。当找到这样的对时,如果该对在同一接口上,则该检查可能会失败。在其他示例中,该检查可以从L-模型中搜索接口,其中在该接口上聚集了匹配的EPG对(针对接口端口策略信息)。如果两个端口的VLAN范围被标记为全局的,那么该检查可能会失败。
第3层检查的一非限制性示例是由于跨VRF契约导致的重叠的子网。该检查可以从L-模型中读取BD(子网和VRF关联)、EPG(子网和BD关联)、以及契约信息。在一组契约中,该检查可以搜索满足以下跨VRF属性的契约:契约的提供者EPG的BD的VRF(即,提供者VRF)和契约的消费者EPG的BD的VRF(即,消费者VRF)不是相同的VRF。当找到这样的契约时,该检查确定消费者子网(EPG子网以及消费者EPG的BD子网)和提供者子网(EPG子网)。当任何消费者子网与任何提供者子网重叠时,该检查可能会失败。
类似地,可以接收一个或多个C_模型624配置(例如,报告叶节点104和脊节点102的Ci_模型274)作为输入和检查器620可以对任何和所有的C_模型624配置执行一致性检查。一致性检查的非限制性示例以及它们是如何被执行的,如下所述:
第1层检查的一非限制性示例是虚拟端口通道(VPC)一致性。该检查可以从每个叶节点读取VPC状态信息。如果一个叶节点上的某些接口处于VPC模式,但VPC对等叶节点上的接口都不处于VPC模式。
第2层检查的一非限制性示例是EPG VLAN(FD-VLAN)和BD VLAN(BD-VLAN)关系一致性。该检查可以读取叶节点的VLAN表信息。该检查还可以搜索FD-VLAN,使得其父级BD-VLAN不包括在其子级列表中(但如果发现了这种情况,检查可能会失败)。在其他示例中,如果识别出的FD-VLAN未将BD-VLAN指示为父级,则该检查可能会失败
第3层检查的一非限制性示例是学习到的路由分配和下一跳一致性。该检查可以读取所有叶节点的LPM表信息。当经由L3out在某边界叶节点上学习到一路由,但在部署L3out的VRF的所有其他叶节点上都不存在该路由时,该检查可能会失败。在其他示例中,如果非边界叶节点上的路由的下一跳不包含边界叶节点,则检查可能会失败。
不存在对H_模型一致性检查的特定需求,引起这将被包括在相应的C_模型的一致性检查中;C_模型检查中不存在任何问题引申地表示在相应的H_模型也没有问题。然而,本申请不限于此,检查器620可以执行与本文讨论的方法一致的H_模型一致性检查。
另一种类型的检查是“模型到模型”检查。这样的检查确认叶节点104和脊节点102正确地将L_模型270A/B转换为Ci_模型274,和/或正确地将Ci_模型274转换为Ci_模型276。
对于L至C模型(“L-C”)检查,特定的叶节点或脊节点提供Ci_模型作为C_模型624,控制器116提供L_模型622。检查器620可以确定是否从L_模型622正确地生成了特定的Ci_模型。检查器620首先取得L_模型622并针对该特定的叶节点或脊节点生成相应的局部Li_模型;这可以由交换机逻辑策略生成器316执行,如关于图3B所述,其中相应的生成的Li_模型在图3中被示出为Li。由于特定的Ci_模型和相应的生成的Li_模型的格式不同,检查器620将它们中的一者或两者转换为相同的格式(“公共格式”)。此格式可以是Li_模型或Ci_模型的原始格式(在这种情况下,该两个模型中仅有一个将需要经历格式转换),但该格式也可以与二者都不同。公共格式的一非限制性示例是JSON对象、扁平化列表、字符串、XML、公用表,等等。
如上所述,特定的Ci_模型274可以具有与它所基于的Li_模型272不同的内容,这使得模型间将存在内容重叠的字段。内容差异部分反映了Li_模型表示操作员意图的指令,Ci_模型表示该意图的实际实现,因此,Ci_模型可以包括关于实际实现的内容。检查器620可以从Ci_模型和相应的生成的Li_模型的公共格式版本中的重叠字段中提取内容(至少其一部分),并将它们互相比较。如果从重叠字段中提取的内容相匹配,则当相应的Ci_模型被创建时,内容被正确地并入。如果从重叠字段中提取的内容不匹配,则生成了错误,例如,阻止了相应的Ci_模型的正确创建和填充的错误。该错误可能以多种不同的方式发生,例如,在L-to-C转换中发生,或者Ci_模型已过时(可能是更新的L_模型根本没接收到或没有对其进行转换);本申请不受限于该错误的性质。
对于C至H模型(“C-H”)检查,特定的叶节点或脊节点提供其特定的Ci_模型624和Hi_模型626。检查器620可以确定是否从Ci_模型中正确地生成了Hi_模型。由于特定的Ci_模型和Hi_模型的格式不同,检查器620可以将其中一者或二者转换为公共格式。该格式可以是Hi_模型或Ci_模型的原始格式(在这种情况下,该模型中仅一个将需要经历格式转换),但该格式可以是与二者都不同的格式。C-H级别检查的公共格式可以与L-C级别检查中使用的格式相同或不同。公共格式的非限制性示例为JSON对象、扁平化列表、字符串、XML、公用表,等等。
如上所述,特定Ci_模型274可以具有与它所基于的相应的Hi_模型276不同的内容,者使得模型信息之间存在内容重叠的字段。检查器620可以从Ci_模型624和相应的生成的Hi_模型626的公共格式版本中的重叠字段中提取内容(至少其一部分),并将它们互相比较。如果从重叠字段中提取的内容相匹配,则当相应的Hi_模型被创建时,内容被正确地并入。如果从重叠字段中提取的内容不匹配,则某错误阻止了相应的Hi_模型的正确创建和填充。该错误可能以多种不同的方式发生,例如,在C-to-H转换中发生,或者Hi_模型已过时(可能叶节点104最初就未进行转换);本申请不受限于该错误的性质。
响应于一致性或模型到模型转换检查中不存在差异,检查器620可以输出信息事件628。响应于一个或多个差异,检查器620输出错误事件628(例如,取决于差异性,其严重性不同)。
图9示出了网络环境的模型到模型检查的示例网络保证的示例流程图。通过举例的方式提供图9中示出的方法,但存在多种执行该方法的方式。此外,虽然以特定序列顺序示出了示例方法,本领域普通技术人员将理解,图9以及其中示出的序列可以以实现本公开地技术优点的任何顺序来执行,并且可以包括比示出的更少或更多的序列。
图9中的每个序列表示示例方法中执行的一个或多个过程、方法或子例程。图9中示出的序列可以在诸如图1A和图1B中示出的网络环境100的网络环境由应用实现。此应用可以存在于设备300和/或检查器620上,但本申请不限于此。
在序列910处,接收要检查的各种模型(例如,L_模型、C_模型、和/或H_模型)。例如,结构120中的每个控制器116可以将一个或多个L_模型270A/B发送到应用(例如,保证设备300和/或检查器620),每个叶节点104和脊节点102发送其相应的Ci_模型274和Ci_模型276。在另一示例中,提供和/或接收L_模型、C_模型、和/或H_模型配置中的一部分而不是全部。这些接收到的模型将包括信息内容,该信息内容中的至少一部分将经受验证过程。
在序列920处,应用可以将两个接收到的模型转变为公共格式(即,一个模型转换为另一个的格式,使得它们的格式相同,或两个模型都被转换为同一新格式)。在一些示例中,公共格式可以是公共模型(例如,操作员初始输入的配置)。
在序列930处,应用可以通过比较两个模型的公共格式中相对重叠字段中的内容来验证接收到的信息。内容中的匹配表示,至少针对该内容,始发叶节点104或脊节点102正确地将一个级模型转换为下一级的模型。例如,从控制器接收到的逻辑模型(例如,L_模型)已正确转换为具体模型(例如,C_模型)。差异指示与模型的部署和创建有关的一些错误。
在序列940处,生成了事件。例如,当验证一致时,应用可以生成信息事件。在其他示例中,当验证中的一个或多个不一致时,应用可以生成错误事件。错误事件的严重性至少可以基于哪个验证不一致以及哪个设备具有不一致性(例如,生产设备、测试设备、访问点、边界叶节点,等等)来确定。
上述方法反映了模型到模型检查的总体步骤。单独类型的模型到模型检查可以包括附加步骤、修改某些步骤、或者省略某些步骤。这样的单独的检查的非限制示例在本文中其他部分中阐述。
在上述实施例中,不请求局部Li_模型272或将其提供给检查器620,因为包括L_模型270A/B的配置和/或级检查将包括对局部Li_模型272的任何特定检查。然而,本申请不限于此,并且局部Li_模型272可以作为检查器620的输入,并可以按照上述方法进行检查。
在上述实施例中,不需要单独的L到H模型(“L-H”)检查,因为这将包含在L-C和C-H检查的组合结果中;L-C和C-H检查中不存在差异引申地表示L和H之间没有差异。然而,本申请并不限于此,并且检查器620可以按照上述方法执行L-H级检查。一致性检查可以对于整个模型是通用的,因为检查了模型的全部内容。在其他示例中,可以检查模型的仅部分内容,特别是主题(topic)特定的内容。作为非限制性示例,第2层特定检查可以仅查验模型中特定于第2层操作的内容,而第3层特定检查查验模型中特定于第3层操作的内容。
在一些示例中,模型到模型检查可以对模型中的全部内容是通用的,因为可以比较全部内容(至少是要被比较的模型的重叠字段中发现的全部内容),以识别哪些特定字段具有匹配或差异。就某些特定主题检查是感兴趣的的角度看,检查可以简单地查询所得的总体比较来查验相关字段。作为一限制性示例,L和C级可以具有50个内容重叠的字段,但第一特定检查可以仅需要考虑它们中的三个(3),而第二特定检查仅要求考虑它们中的两个(2)。每个主题特定间检查可以查询比较结果,以搜索所需的特定字段。以这种方式,该比较可以在请求主题特定检查之前进行。
在其他示例中,可以比较模型的部分内容,特别是主题特定内容。例如,如下文中关于单独的检查的更详细的描述,一些检查针对关于特定主题的特定信息。在这样的情况下,比较可以不包括或考虑全部的重叠字段,而是将限定于感兴趣的重叠字段。作为非限制性示例,第2层特定检查可以仅比较特定于第2层操作的重叠字段的内容。可以在应用(例如,300)中预定义与特定检查相关的感兴趣信息的类型,但本申请不受此限制。这样,请求主题特定检查可以在比较之前,并且比较可以仅限于感兴趣的主题。
主题特定检查可以是自包含的或重叠。具体地,如上所述,不同的主题检查可以查验模型中不同的重叠字段。这些字段中的一些字段可以对于不同检查是公共的。作为非限制性示例并如下讨论的,针对BD部署和EPG部署二者的第2层检查都查验关于VLAN的信息;因此,两个不同的检查包括对相似内容的考虑。如果检查是自包含的,那么每个检查都将查验相关内容,而不管其他先前的/未来的检查;因此,在本示例中,在BD部署和EPG部署检查二者中,VLAN都将被单独地检查。在其他示例中,如果公共字段已经被先前的检查查验过,则后续的检查可以依赖于这些结果,而不进行独立的查验;因此,如果BD检查显示VLAN信息符合预期,则后续的EPG检查可以采用这些结果,而不必再次/单独地检查VLAN信息。
在上述实施例中,检查的结果要么是匹配要么是差异。然而,本申请不限于此。比较的内容是可接受的和其与预期一致之间可以存在一个预定义的可接受变化范围。对于一些内容,某种差异可能不如另一种差异重要。本申请不限于检查器620评估差异的存在、性质或差异影响的方式。
尽管上面的检查是针对特定的叶节点104和脊柱102进行讨论的,但应理解,这些检查可以在全部或部分叶节点104和脊柱102上执行。这样的检查可以响应于简单地接收到模型,例如,接收到C_模型和H_模型,从而执行C-H检查。在其他示例中,可以轮询特定的叶节点104和/或脊节点102以获取信息,而检查仅限于请求信息。本申请不受请求或接收用于检查的信息的方式或触发检查器620发起特定检查的原因的限制。
租户转发事件生成
如上所述,图6还示出了事件628的生成。可以响应于检查器620对一个或多个输入(例如,622、624、626、630)执行检查而生成事件。事件可以是信息事件和错误事件。响应于在输入的检查期间未发现不一致或差异而生成信息事件。信息事件可以包括执行的检查、设备检查、检查的时间(time)、检查的结果,等等。可以将信息(和错误)事件存储在可被设备300访问的存储器/数据库中。
历史上存储的事件可以以预测的方式使用。作为非限制性示例,可以存储和参考先前的配置和这些配置的检查的因果关系(特别是失败的结果)。在使用新提出的配置对结构120或网络化环境做出改变之前,系统可以对历史数据进行查询,以获取相同或类似配置的实例以及其产生的正面的或不利的影响。因此,系统可以基于具有相同或类似特性的先前的配置来预测新提出的配置是否将对网络产生有害的影响。类似地,历史事件也可以用来预测最近发生的可能导致问题的改变。
可以响应于在输入(例如,L_模型、C_模型、H_模型,等等)的检查器件发现的不一致和差异生成错误事件。错误事件可以具有不同的严重性级别,例如,警告、轻微、主要、严重,等等。警告严重性可能是未来的潜在问题,例如,未使用操作员感兴趣的最佳实践或事件。轻微严重性可以是较低影响的问题,例如,不影响生产设备,不影响操作,等等。主要问题是较高影响的问题,例如,操作被影响,但仍在工作(例如,生产设备丢失了一些数据包,等等)。严重错误是通常会阻止设备的正常操作并需要立即修复的严重故障,例如,边界叶节点、生产设备等的错误。
每个事件可以包括一个助记符(事件代码)、错误说明、修复步骤、受影响的对象(例如,VRF)、次要受影响的对象(例如,与受影响的VRF相关联的BD和EPG)、严重性级别、检查次数,等等。当受影响的对象发生错误时,可以检查每个次要受影响的对象是否存在错误。例如,当VRF出现问题并且错误事件被生成时,可以检查VRF的次要对象(链接的BD、EPG,等等)是否存在错误。在一些示例中,错误可能是在较高级别处(例如,VRF)生成的,但错误的原因可能是在较低级别(例如,BD,EPG等)引起的。通过检查次要对象并确定错误的实际原因,可以更高效和有效地进行修复。
在一些示例中,可以将修复步骤发送到操作员。在其他示例中,网络环境或结构中的设备中的一个或多个可以自动地执行修复步骤。在一些示例中,设备300可以执行修复步骤。在其他示例中,修复可能需要供应商,并且可以通知操作员与供应商联系。
第1层的验证
从部署的角度来看,操作员可以在L模型270A指令中定义有关第1层可操作性的特定叶节点104或脊节点102。这可以包括物理链路(例如,端口)是否设置为活动还是关闭,软件链路(例如,端口)是活动还是关闭,以及用于查看接口是否已配置(例如,配置了访问策略等)的配置检查。叶节点104和脊节点102可以接收L_模型270A,并且将相关内容转换为Ci_模型274,然后执行指令以建立配置,并按照指示的方式设置物理链路、软件链路和接口。然后,叶节点104和脊节点102更新它们相应的Ci_模型274,以反映物理、软件链路、接口及其组合的状态。
第1层物理接口的网络保证针对的是设备300和/或检查器620确认配置存在以及按照指示配置了链路。第1层检查可以是物理链路检查(例如,活动或者关闭)、软件链路检查(例如,活动或者关闭)以及配置检查(例如,已配置或未配置)。对于要主动配置的第1层,三个控制中的每个都应被正确地配置(例如,物理链路打开,软件链路打开,访问策略已配置)。在其他示例中,可以不主动配置第1层,并且该三个控制可以打开、关闭以及未配置的。
物理链路检查可以确定网络接口(例如。叶节点104和脊节点102的网络接口)是否具有物理连接(例如,附接了电缆等)。检查器620从特定的单独的叶节点104或脊节点102接收Ci_模型,并从Ci_模型中识别物理链路是活动还是关闭的报告的状态。检查器620还可以轮询监视硬件状态的特定的单独的叶节点或脊节点的软件以确定物理链路的实际状态是否如Ci_模型所反映,例如通过在设备的命令行接口上发出命令(例如,ethtool、ifconfig等)。当状态匹配时,物理链路被验证,而当状态不匹配时,则存在差异(例如,轮询的状态标识链路是活动的,而报告的状态显示其实关闭的,反之亦然)。
软件链接检查可以在软件级(例如,固件、应用,等等)上确定物理链路(例如,端口)何时是打开或关闭的。该方法跟随(track)上述物理链路检查的方式,区别是检查器620轮询监视软件状态的特定的单独叶节点或脊节点的软件,以查看软件链路的以查看软件链路的实际状态是否如Ci_模型所反映,例如通过软件(例如,设备的命令行接口(或GUI))查看设备的端口已被打开或关闭。如果状态匹配,则软件链路被验证,如果状态不匹配,则表明存在差异(例如,轮询的状态表示该链路是活动的,但报告的状态显示该链路关闭,反之亦然)。配置检查可以确定接口于何时被配置(例如,具有访问策略等)。访问策略可以管理交换机访问端口的操作,其中该端口提供与资源(例如存储、资源等)的连接、第2层和第3层(桥接和路由)连接、与虚拟机管理程序的连接、与第4层到第7层设备的连接,等等。访问策略可以实现以下配置(但不限于):端口通道、虚拟端口通道、协议(诸如LLDP、CDP或LACP)、速度,STP属性、以及监视或诊断等特征。访问策略可以包括公共对象,包括但不限于:叶节点简档、叶节点策略、接口简档、接口策略、AEP、VLAN池、物理域(physdom)、VMM域、管理程序等。现在参考图3D,特定检查是L-模型级的一致性检查,其中检查器620进行检查以确认存在交换简档382和接口简档384、386,并且它们已被填充且被正确地链接386,以及接口简档384已正确地链接386到全局简档388。全局简档和其他内容的检查可以在其他层进行。
图8示出了第1层物理接口的示例网络保证的示例流程图。通过示例的方式提供了图8中所示的方法,但存在多种方法来执行该方法。另外,尽管以特定顺序的序列示出了示例方法,但是本领域普通技术人员将理解,图8及其中所示的顺序可以以实现本公开的技术优点的任何顺序来执行,并且其中可以包括比示出的更少或更多的序列。
图8中示出的每个序列代表示例方法中执行的一个或多个过程、方法或子例程。图8中所示的序列可以在网络环境中实现,例如图1A和图1B中所示的网络环境100。该应用可以存在于设备300和/或检查器620上,但本申请并不限于此。
在序列810处,接收要检查的各种模型(例如,L_模型、C_模型、和/或H_模型)。例如,结构120中的一个或多个叶节点104、脊节点102和控制器116可以将L_模型270A/B、Ci_模型274和H_模型274发送到应用(例如,保证设备300)。这些接收到的模型将包括信息内容,该信息内容中的至少一部分将经受验证过程。例如,感兴趣的第1层内容可以包括设备接口的物理链路状态、设备上的接口的软件链路状态、以及设备上的接口的任何访问策略。
在序列820处,应用可以验证接收到的信息。例如,例如,应用程序(例如,保证设备300)可以验证接收到的信息与先前存储的信息的关系。在一些示例中,可以根据先前存储的信息来验证接收到的物理接口状态,这些先前存储的信息是确定物理接口是否打开(例如,活动)所需的。在一些示例中,可以根据先前存储的信息来验证接收到的软件接口状态,这些先前存储的信息是确定软件接口是否打开(例如,活动)所需的。在一些示例中,在一些示例中,可以根据先前存储的信息来验证接收到的访问策略信息,这些这些先前存储的信息是确定访问策略是否存在并正确配置所需的。在一些示例中,检查器620可以独立地从一个或多个叶节点104、脊节点102等获取信息,并以上述方式与模型的内容进行比较。
在序列830处,应用可以生成事件。例如,当验证全部成功(例如,与验证的预期一致)时,应用可以生成一个信息事件。在其他示例中,当验证中的一个或多个不成功(例如,与验证的预期不一致)时,应用程序可以生成错误事件。错误事件的严重性至少可以根据哪个验证不成功以及哪个设备验证不成功(例如,生产设备、测试设备、访问点、边界叶节点,等等)来确定。
第2层的验证
第2层是协议层(例如,数据链路层),它可以提供功能和程序配置,以便在网络实体之间传输数据。设备300可以对网络环境的第2层执行一系列网络保证检查。第2层检查至少可以包括针对第2层相关内容的L_模型一致性检查、L-C检查和C-H检查,尽管应用不限于此。如上文所述,可以由设备300和/或检查器620至少对特定于第2层操作性的内容重叠的字段执行这些检查。
可以针对访问策略(例如,公共对象)和租户树(例如,推送到叶节点和脊节点的公共对象)执行第2层检查。对于每个租户,租户树公共对象可以包括VRF、BD(绑定到VRF)、EPG(绑定到BD)。每个EPG可以包括部署信息(控制器应该在哪里部署配置),包括静态绑定或动态绑定和域静态绑定可以包括叶节点、卡、端口和VLAN。动态绑定不需要进一步的信息,因为它是在需要时动态配置的。域可以包括物理域、VMM或两者。域和静态绑定还可以包括部署设置,包括预配置、即时、延迟(lazy)等。一旦完成用于定义L_模型270A的配置(例如由操作员),控制器116可以将L_模型270A/B推送到适当的叶节点104和脊节点102。然后,设备300和/或检查器620可以检查该部署。
第2层L_模型一致性检查可以至少包括对L_模型配置的语法分析(例如,配置、设置、排版,等等)。针对第2层检查的特定内容通过非限制性示例包括:正确配置访问策略(例如,基于公共对象)、正确配置EPG(例如,基于公共对象)、跨EPG检查(例如,如果一个EPG使用一个VLAN,那么部署在同一个叶节点上的另一个EPG不应该使用同一个VLAN),等等。当存在不一致时,可以生成事件。
第2层L-C检查可以包括BD是否正确部署(例如,语义检查)。例如,例如,BD的一些子集已经部署在叶节点104的一个或多个上。L-C检查可以例如通过使用公共对象(例如VLAN和接口)来验证该BD子集是否已正确部署在叶节点上。在一些示例中,VLAN和接口信息(例如,C_模型)可以存储在叶节点/脊节点的VLAN表中。
L-C检查还可以包括EPG是否被正确部署,类似于上面的BD检查,其检查VLAN对(L_模型和C_模型之间)和接口对(L_模型和C_模型之间)。
第2层C-H检查可以类似于第2层L-C检查,但要检查的内容驻留在叶节点104和脊节点102中并且从叶节点104和脊节点102接收。例如,应用(例如,设备300)可以从一个或多个叶节点104和脊节点102接收Ci_模型624和Hi_模型626,将其转换成公共格式,然后验证VLAN对和接口对。当Ci_模型和Hi_模型之间存在不一致时,可以生成事件。
另一第2层检查是验证网络中的VLAN分配,这是L_模型到H_模型的相对检查。在一些示例中,可以通过L-C和C-H检查的组合来执行L_模型到H_模型检查。检查可以针对每个EPG验证在L_模型、Ci_模型和Hi_模型的同一接口分配了相同的VLAN。
另一第2层检查可以是验证整个网络环境中的VLAN分配。该特定检查是L_模型与分布式虚拟交换机(DVS)配置(以下简称“DVS_模型”)的内容的比较。DVS在结构120外部,并且类似于叶节点104和脊节点102,其也接收L_模型270A/B。如上所述,检查器620从控制器116的L_模型输入622接收L_模型270A/B,并且还从其他输入630处的DVS接收作为不同的输入的DVS配置。接收到的L_模型和/或DVS配置中的一者或二者被转换为公共格式,并且比较来自相关重叠字段(位于模型/配置中)中的内容。对于VLAN分配,相关重叠字段可以包括但不限于:为每个EPG配置的VLAN(例如,静态/物理和动态/虚拟),以及动态/虚拟EPG的特定VLAN ID。
另一第2层检查是作为L_模型一致性检查的一部分的交换机或端口上的VLAN配置。设备300可以检查从控制器116接收的L_270模型A/B不包括重叠的VLAN。在交换机级,设备300可以确定交换机上是否存在重复的VLAN。在端口级,设备300可以确定交换机的同一端口上是否存在重复的VLAN。在端口示例中,交换机的不同端口上可存在重复的VLAN。
如关于图9所讨论的那样,执行第2层中的L-DVS、L-C和C-H级检查。序列910处的各种接收的模型将包括与第2层分析相关的信息,例如VLAN和接口信息。在序列920处,针对每个模型到模型检查,应用可以将接收到的模型转换为公共格式。在序列930处,应用可以通过查验来自相关字段(例如VLAN公共对象和/或Ci_模型的接口公共对象)的内容来验证接收到的信息。第2层的其他公共对象可以在L-DVS、L-C和C-H检查之间进行验证。
在序列940处,控制器可以生成事件。例如,当验证是一致的(例如,与验证的预期一致)时,应用可以生成信息事件。在其他示例中,当验证中一个或多个不一致(例如,与验证的预期不一致)时,应用可以生成错误事件。错误事件的严重性至少可以基于哪个验证不一致和哪个设备(例如,生产设备、测试设备、访问点、边界叶节点等)具有不一致性来确定。
第3层的验证
设备300可以对网络环境(例如,网络保证)的第3层(例如,网络层)执行一系列检查。网络层负责分组转发,包括通过中间路由器进行路由。第3层检查可以至少包括L_模型的一致性检查、L-C检查和C-H检查,但应用不限于此。如上文所述,由设备300和/或检查器620至少对特定于第3层操作性的内容重叠的字段执行这些检查。
可以执行多种第3层检查,例如,BD子网被正确部署(例如,路由开/关、IP/掩码等)、重叠子网检查、L3out被正确部署、BD-L3out关联、利用子网正确编程了RIB、学习到的路由在结构中正确传播、RIB-FIB等效性、以及跨VRF路径泄漏。
在第3层中,检查的一个关注点是子网部署的完整性。每个BD可以定义一个或多个子网(例如10.0.*)。也可以在逻辑组(例如,EPG)中定义子网。每个VRF(位于第3层)可以具有唯一的IP地址。如果另一设备使用同一IP地址,只要该IP地址由不同的VRF使用,就不存在冲突。在第3层中,还可以定义一个公共对象L3out(用于外部通信)。L3out公共对象可以定义:L3接口、L3out EPG、静态路由和环回。
BD子网是否被正确部署可以作为L-C检查。每个BD(和EPG)的子网可以驻留在由控制器116部署的L_模型270A/B上。部署在网络设备上的子网可以包括驻留在报告叶节点104或脊节点102的Ci_模型上的路由信息库。应用可以收集从接收到的L_模型和Ci_模型部署的BD子网(基于VRF分配),以定义一个集合并(例如,无重复部署的BD子网列表)。应用可以确定BD子网实际上部署在该并集中的适当网络设备上(而不是部署在不应该部署的网络设备上)。由于EPG之间的契约,BD子网检查还可以包括检查网络设备上的BD子网。BD子网检查可以确定BD子网指向脊节点代理,并且BD子网具有安装了的相应的网关地址。
图10示出了网络环境的第3层配置的示例网络保证的示例流程图。通过示例的方式提供图10所示的方法,但存在多种方式来执行该方法。此外,虽然用特定的序列顺序来说明示例方法,但是本领域的普通技术人员将理解,图10和其中所示的序列可以按照实现本公开的技术优点的任何顺序来执行,并且可以包括比所示更少或更多的序列。
图10中的每个序列表示示例方法中执行的一个或多个过程、方法或子例程。图10中示出的序列可以在诸如图1A和图1B中示出的网络环境100的网络环境中实现。应用可以存在于设备300和/或检查器620上,但本申请不限于此。
方法1000可以从序列1010开始。在序列1010处,接收要检查的各种模型(例如,L_模型、C_模型和/或H_模型)。例如,结构120中的一个或多个叶节点104、脊节点102和控制器116可以将L_模型270A/B、Ci_模型274和H_模型274发送到应用(例如,保证设备300)。这些接收到的模型将包括信息内容,该信息内容中的至少一部分将经受验证过程。在一些示例中,与第3层检查相关的信息可以包括来自网络环境或结构中的每个VRF、BD、EPG(例如,逻辑组)的前缀、子网、网络或路由数据。
在序列1020处,针对接收到的L_622模型中的VRF创建并填充用于配置abc的一个或多个VRF容器(例如,单独的或多个表、文件等)。图11示出了示例VRF容器1100和1125。虽然VRF容器1100和1125说明了两种不同的容器配置,但是实现了更多的容器配置,并且示例容器1100和1125不作为限制。可以标识每个VRF下的特定叶节点104(例如,每个VRF将具有一个或多个BD子网,并且每个BD子网将具有一个或多个EPG,该EPG具有一个或多个特定叶104)。VRF容器1100至少填充了接收到的Ci_模型274和针对特定叶节点创建的Li_模型272(先前或新创建的,并且考虑安全性契约,如下所述)。因此,每个VRF容器可以包括特定于该VRF的数据(例如,前缀、子网、网络、外部路由等的LPM容器)。
在序列1030处,由检查器620和/或装置300对每个VRF容器进行验证。Li_模型表示如何配置BD子网(例如,根据操作员的意图),Ci_模型表示如何实际执行指令(例如,在叶节点、脊节点等处)。该意图应与该实现相匹配,因此检查器620针对每个VRF容器确认Li_模型与Ci_模型一致。如果内容中存在不匹配,则存在差异。
如果存在不应该存在的模型,则也可能存在差异。例如,如果在特定VRF下仅存在叶节点1和叶节点2,则该VRF的容器中将存在L1_模型、Ci_模型、L2_模型和C2_模型。VRF容器中不应存在其他叶节点的Li_模型或Ci_模型,并且该模型的存在将是差异。
图11示出了部署1150。例如,如图11所示,abc在叶节点1和叶节点2上,但不在叶节点3上,而def在叶节点3上,但不在叶节点1或叶节点2上。因此,检查器620将验证abc配置是否正确部署在叶节点1和叶节点2上,而不是叶节点3上,以及def配置是否正确部署在叶节点3上,而不是叶节点1或叶节点2上。检查器620还可以验证叶节点1和叶节点2上的abc配置与L_模型中定义的abc配置一致,以及叶3上的def配置与L_模型中定义的def配置一致。
在一些示例中,检查器620可以执行集检查。例如,检查器可以执行对集求差,在转换为公共格式之后,从Ci_模型集中减去Li_模型集,然后从L_模型集中减去Ci_模型集;当两个减法的结果相同时,集是正确的。不匹配将指示丢失信息或具有额外信息,这可导致(例如)结构中的分组丢失,并且额外信息可导致(例如)结构中的安全问题(设备可以访问其没有权限请求的其他设备)。
当示例显示L-C检查时,可以实现C-H检查。在一些示例中,在检验器验证了配置之后,可以检查脊节点代理的配置以确定正确的下一跳。
在序列1040处,可以生成一个或多个事件。例如,当验证一致时(例如,与验证的期望一致),应用可以生成信息事件。在其他示例中,当一个或多个验证不一致(例如,与验证的预期不一致)时,配置不在正确的叶节点上(根据L_模型),或者当缺少信息或存在额外信息时,应用可生成错误事件。错误事件的严重性至少可以根据哪个验证不一致以及哪个设备具有该不一致性(例如,生产设备、测试设备、访问点、边界叶节点,等等)来确定。
上述BD部署的VRF容器检查是通用VRF容器完整性检查的应用示例。创建VRF容器时,可以使用L_模型、Li_模型、Ci_模型和/或Hi_模型填充该容器,其中这些模型包含与检查相关/检查所需要的数据。检查器620可以确认这些模型的存在或不存在。作为非限制性示例,如果存在适当的Li_模型,但不存在相应的所需Ci_模型,这将指示部署中存在错误。如果存在Ci_模型,但所需的相应Li_模型不存在,则表示存在不正确的额外信息。另一VRF中存在Li_模型或Ci_模型,也表示存在不正确的额外信息。
逻辑组间的安全性契约
在某些情况下,端点组之间可存在安全性契约(如下所示)。在这些情况下,叶节点将获得泄漏的子网(和其他信息)。设备300可以执行L-C检查以确定RIB是否被正确编程。例如,如图12所示,当配置契约2时,叶节点1上RIB将包括子网100.*和200.*(例如,来自BDl)和从契约2泄漏的BD2子网(例如,300.*、400.*)。此外,叶节点3还将包括子网300.*和400.*(来自BD2)以及从契约2泄漏的用于BDl的子网(例如,100.*和200.*)。如果没有契约2,叶节点1将不包括BD2子网,而由于契约1,叶节点3将包括BDl子网。
如果两个或多个逻辑组之间发生冲突,则无法正确部署逻辑组(例如EPG)。例如,如果逻辑组正在使用相同的接口、子网、封装VLAN等。在一个示例中,如图7所示,逻辑组1(LG1)和逻辑组2(LG2)最初彼此独立且不冲突。然而,当安全性契约750被实现时,LG1和LG2子网之间可能发生冲突。在形成安全契约之后,逻辑组可以部署在承载逻辑组的叶上(例如,逻辑组内的端点可以通信)。在逻辑组之间形成安全性之后,逻辑组可以部署在承载该逻辑组的叶节点以及承载作为契约端点的逻辑组的叶节点上(例如,具有契约的逻辑组之间的端点可以通信)。这使得不同逻辑组中的端点能够相互通信。例如,LGl位于叶节点1上,LG2位于叶节点2上。在LGl和LG2之间形成安全协议后,LGl子网将部署在叶节点2上,LG2子网将部署在叶节点1上。但是,具有契约的逻辑组之间的通信也可以在叶节点之间共享前缀(例如路由),由于逻辑组之间存在公共前缀,这可导致冲突;而当LG1和LG2的配置发生冲突(例如,同一个子网)时,部署可能失败并生成事件。
在一些示例中,契约可以位于不同VRF中的逻辑组之间。在这种情况下,可以在VRF之间执行内部路由泄漏,检查可以在第3层中进行,如下所述。
图12示出了网络环境(例如,结构120)的租户配置1200的图形视图。租户配置1200可示出绑定到同一VRF(例如VRF1)的两个BD(例如BD1和BD2)。每个BD可以有一个或多个指定的子网。例如,BD1可已分配100.*和200.*子网,BD2可已分配300.*子网。一个或多个逻辑组(例如,EPG)可以绑定到一个或多个BD。例如,EPG1和EPG2可以绑定到BD1,EPG 3可以绑定到BD2。每个EPG也可以具有一个或多个指定的子网。例如,EPG3已指定子网400.*。每个EPG可以指向一个或多个叶节点。例如,EPG1可以指向叶节点1和叶节点2,EPG2可以指向叶节点2,EPG3可以指向叶节点3。
在上述租户配置(例如1200)中,EPG内的端点可以彼此通信,然而,如果没有安全性契约,一个EPG的端点不能与另一个EPG的端点通信。例如,EPG3的端点在首先不具有安全性契约(例如,契约1)的情况下不能与EPG2的端点通信。当EPG之间存在契约时,受契约约束的EPG的端点可以通信。例如,当契约1就位时,EPG3和EPG2中的端点可以通信。
当存在安全性契约时,配置(和子网)将部署在各自连接的叶节点中。例如,当契约1就位时,EPG2子网将部署在叶节点3上,EPG3子网将部署在叶节点2上。因此,BD1的子网(例如100.*和200.*)将部署在叶节点3上,BD2的子网(例如300.*)和EPG3的子网(例如400.*)将部署在叶节点2上。
当子网部署在叶节点上时,设备300可以验证子网是否正确部署,例如,通过查看由安全性契约创建的结果配置(如L-C检查)。如前所述,子网可以通过安全性契约进行验证,并且可以创建VRF容器(例如1250)。VRF容器1250可以包括Li_模型配置,包括由安全契约创建的配置。例如,叶节点1至3可以包括子网100.*、200.*和300.*。子网300.*可由叶节点1和叶节点2根据契约1访问,并且子网300.*是BD子网。叶节点2和叶节点3都可以具有可根据协定1访问的子网400.*。然后,可以通过L-C检查将Li_模型配置映射到Ci_模型配置,以确定整个结构的一致性。
下一跳检查
接下来,应用可以确定下一跳是否正确。例如,每个BD和EPG子网应该指向脊节点代理,网关IP应该指向本地(local)。在一些示例中,路由表1275可以显示IP地址和掩码的下一跳(例如,使用最长前缀匹配)。当IP地址为100.0.0.1时,下一跳将是下一跳1,因为使用了完整的IP地址(例如,IPv4中的32位掩码)。当IP地址为100.0.0.0/24时,下一跳将是下一跳2,因为掩码为28(也显示为*)。此检查可以是Ci_模型处对所记录内容的一致性检查。
RIB到FIB等效性
设备300还可以确定特定叶节点104或脊节点102的RIB和FIB是一致的。路由信息库(RIB)包含在特定叶节点104或脊节点102的Ci_模型的LPM表中。转发信息库(FIB)包含在特定叶节点104或脊节点102的Hi_模型的LPM表中。RIB到FIB检查是如上所述的针对至少对特定于RIB和FIB操作性的内容重叠的字段的C-H检查。
如图13所示,设备1300(例如,叶节点104、脊节点102等)可以包括线路卡控制器1310(FIB驻留的位置)和SUP控制器1320(RIB驻留的位置)。路由协议在SUP级软件级上工作。RIB被编译到线路卡控制器,该线路卡控制器被物理地编程到设备的硬件上。如表1330所示,设备300可以通过提取FIB和RIB并将其转换为公共格式来确定等效性。表1330可以显示IP地址(例如100.0.0.0)、掩码(例如32)和一个或多个下一跳(例如NH1、NH2等)。表1330还可以包含“全部捕获(catch all)”(如*-DROP)。例如,当接收到与IP地址/掩码不匹配的IP地址时,“全部捕捉”将丢弃分组。可以对条目进行比较以确定下一跳之间不存在不一致。
图14示出了网络环境的RIB-FIB等效性的示例网络保证的示例流程图。图14所示的方法是作为示例提供的,因为有多种方法来执行该方法。此外,虽然以特定序列顺序示出了示例方法,本领域普通技术人员将理解,图14以及其中示出的序列可以以实现本公开地技术优点的任何顺序来执行,并且可以包括比示出的更少或更多的序列。
图14所示的每个序列表示在示例方法中执行的一个或多个过程、方法或子例程。图14所示的序列可以在诸如图1A和图1B所示的网络环境100的网络环境中实现。应用可以存在于在设备300和/或检查器620上,尽管该本申请不限于此。
方法1400可以从序列1410开始。在序列1410处,应用(例如,设备300)可以从设备的SUP控制器(例如,叶节点104、脊节点102等)提取RIB。在序列1420处,应用可以从设备的线路卡控制器中提取FIB。序列1410和1420都可以引起轮询一个或多个叶节点104或脊节点102以获取内容,或者在其他示例中,从接收到的Ci_模型624和Hi_模型获取一个或多个叶节点104或脊节点102的内容。
在序列1430处,应用可以将提取的FIB和RIB转换为公共格式(例如,FIB或RIB二者中的一个被转换为另一个的格式,或者两者都被转换为相同的新格式)。在序列1440处,应用可以创建转换后的RIB和FIB的并集(例如,包括所有RIB和FIB(无重复)的列表的并集),如表1330所示。虽然显示为集合性表,但列表可能位于不同的表中。
在序列1450处,应用可以识别RIB中的第一个条目,并确定FIB中是否存在具有匹配下一跳的匹配的IP地址/掩码。如果存在这样的匹配,则控制传递到序列1470,以查看是否存在要考虑的下一个条目。如果存在要考虑的下一个条目,控制传回到序列1450以检查下一个条目(例如,RIB中的下一个条目,然后转到FIB中的条目)。
例如,关于表1330,第一条目RIB 1)具有IP地址/掩码100.0.0.0/32,其下一跳为NH1。在FIB中(在FIB 1)处)找到相同的下一跳为NH1的IP地址/掩码100.0.0.0/32。由于RIB和FIB条目匹配,方法1400可以继续到下一个条目序列1470。如果没有下一个条目,则方法1400可以结束。在此示例中,存在RIB 2)的下一个条目,因此控制传递到序列1450,以检查RIB 2)的下一个条目。
在序列1450处,如果针对所检查的RIB条,应用没有识别到匹配的FIB条目,则控制传递到序列1460。在序列1460处,应用可以确定该不匹配是否被另一个前缀覆盖,例如,通过最长前缀匹配。当不存在另一个前缀和/或下一跳不匹配时,可以在1480处生成错误。
例如,关于表1330,条目RIB 2)100.0.0.1/32没有匹配的FIB,因此控制传递到序列1460以识别另一覆盖前缀,在这种情况下,该另一覆盖前缀作为FIB 2)100.0.0.*/30存在。如果下一跳匹配(RIB 2)和FIB 2)之间),则控制将传递到序列1450,以检查下一个RIB条目。然而,RIB 2)和FIB2)的下一跳不匹配(NH1相对于NH2),并且在控制返回到序列1470考虑下一个条目之前,在序列1480处记录错误。
在一些情况下,不匹配可以是其中表中的一个的非条目(non-entry)。例如,除了“全部捕获”(例如,*-Drop)之外,FIB 3)200.0.0.0/30在RIB表中没有匹配项。任何到来的IP地址200.0.0.0都将被丢弃,即使FIB表中显示将其路由到NHL。响应于这种类型的不匹配,可以生成错误。
在一些情况下,RIB或FIB中可存在将不被使用的条目。例如,RIB 5)永远不会被使用,因为组合的RIB1)到RIB4)覆盖了RIB5)中的所有IP。
当所有RIB都已查验,过程继续检查FIB的列表,特别是最初RIB检查未考虑的那些FIB。这个过程也可以反过来进行,其中可以在检查RIB之前先对FIB的列表进行检查。或者系统可以在列表之间切换。本申请不受RIB和FIB列表的处理方式的限制。
L3out的验证(内部-外部转发)
如上面图7所示,内部子网(例如,100.2.*)可以泄漏到外部网络(例如,网络设备114),外部网络(例如175.*)可以泄漏到结构。为了在结构120中的公共子网和外部设备之间正确地进行通信,必须正确地配置第3层out(“L3out”)。设备300可以确定L3out已正确配置。
L3out接口模型至少可以包括叶节点(例如,边界叶节点)、端口和网络(例如,40.1.2.*)。边界叶节点可以将L3out配置为访问外部设备/网络(例如,网络设备114)。为了部署L3out接口,可以配置叶节点、端口和网络。例如,操作员可以将叶节点N、端口ethl/10和网络40.1.2.*编程到L_模型270A中,其中以上文中讨论的方式,叶节点N生成相应的CN_模型和HN_模型。一旦被配置,叶节点N和网络设备114之间的链路对于在结构外部传输数据是重要的。在这种情况下,网络40.1.2.*将拥有该链路。100.2.*子网(如LPM表748所示)可以泄漏到网络设备114(通过L3out接口和链路40.1.2.*)。子网通过路由协议泄漏,例如BGP、OSPF、EIGRP等。例如,在路由协议中有两个对等点:对等点l是边界叶(例如,叶N),对等点2是外部设备(例如,网络设备114)。这两个对等点将互相交换路由。例如,对等点l可以告知对等点2其具有用于泄露到结构外部的公共网络(例如,100.2.*),对等点2可以对等点1其具有要被泄露到结构内部的外部路由(例如,175.*)。
L3out环回是用于配置网络协议(例如,BGP)的接口。静态路由可由结构120编程。例如,网络设备114可以具有未泄漏到结构120的网络200.*。在这些情况下,L_模型可以直接编程200.*网络以与外部路由器(例如,网络设备114)通信。EPG(Instp)可用于控制外部路由的导入。例如,网络设备114可以具有泄漏到结构120的若干路由(例如,100.*、300.*、400.*,等等)。这些网络可以用EPG标记。例如,100.*可以用EPG1(例如,逻辑组1)标记,300.*可以用EPG2(例如,逻辑组2)标记,400.*可以用EPG3(例如,逻辑组3)标记。因此,每当来自这些网络的到来的分组进入结构120时,将使用相关的EPG标记该分组。
设备300可以通过L-C模型检查对L3out执行检查。例如,设备300可以验证在边界叶节点上编程了接口、环回和静态路由(例如,存在于LPM表中)。设备300还可以验证L3out的一个或多个EPG正确。对于每个网络,设备300可以验证下一跳正确。
图15示出了网络环境的L3out配置的示例网络保证的示例流程图。图15所示的方法是作为示例提供的,但存在多种方式来执行该方法。此外,虽然以特定序列顺序示出了示例方法,本领域普通技术人员将理解,图15以及其中示出的序列可以以实现本公开地技术优点的任何顺序来执行,并且可以包括比示出的更少或更多的序列。
图15中的每个序列表示示例方法中执行的一个或多个过程、方法或子例程。图15中示出的序列可以在诸如图7中示出的网络环境700的网络环境中实现。应用可以存在于设备300和/或检查器620上,但本申请不限于此。
方法1500可以从序列1510开始。在序列1510处,接收要检查的各种模型(例如,L_模型、C_模型和/或H_模型)。例如,结构120中的一个或多个叶节点104、脊节点102和控制器116可以将L_模型270A/B、Ci_模型274和H_模型274发送到应用(例如,保证设备300)。这些接收到的模型可以包括信息内容,该信息内容可以经受验证过程。在一些示例中,与L3out保证检查相关的信息可以包括接口(例如,叶节点、端口、网络)、环回(例如,协议)、静态路由和EPG。
在序列1520处,应用可以验证配置为通过L3out通信的网络在LPM表(例如,L3表)中。LPM表(例如,C_模型)可以包含网络中的设备(例如,叶节点104、脊节点102等)的配置。如上所述,可以将L_模型和C_模型转换为公共格式,并且可以对重叠字段的相关内容进行比较。例如,L3out接口保证考虑叶节点、端口和网络的字段。设备300可以验证来自配置的叶节点已按照配置(例如,L_模型)中所示部署了端口和网络。设备300可以对环回(考虑叶节点和网络的字段)和静态路由(考虑叶节点、网络和下一跳的字段)执行类似的验证。通过L-C检查,应用也可以验证EPG。
在序列1530处,应用可以通过C_模型一致性检查来验证下一跳。例如,验证每个叶节点处的LPM表包括与边界叶节点(例如,用于外部通信)通信的下一跳条目。如图7所示,叶节点2可以包括LPM表742。LPM表742可以包括子网和下一跳。如前所述,子网100.2.*已从叶节点N泄漏到网络设备114,并且当叶节点2意图与外部网络通信时,数据路由通过叶节点N(或连接到网络设备114的另一边界叶节点)。设备300可以验证叶节点和脊节点的LPM表中的下一跳路由正确。
在序列1540处,可以生成一个或多个事件。例如,当验证是一致的(例如,与验证的预期一致)时,应用程序可以生成一个信息事件。在其他示例中,当验证中的一个或多个不一致(例如,与验证的预期不一致),配置不在正确的叶节点上(根据L_模型)时,或者当存在丢失的或额外的信息时,应用可以生成错误事件。错误事件的严重性至少可以基于哪个验证不一致和哪个设备(例如,生产设备、测试设备、访问点、边界叶节点等)具有不一致性来确定。
BD-L3out配置的验证(内部-外部转发)
BD-L3out关联使得内部网络能够泄漏到结构外部,即外部路由器应知道内部网络以及应将数据路由到何处以访问内部网络(例如,内部结构120)。如图7所示,叶节点2具有公共网络100.2.*。对于要从结构外部访问的网络100.2.*(例如,由网络设备114访问),可以配置BD-L3out关联。如图16所示,BD L3out关联可以包括,BD子网被标记为公共的(例如,100.2.*),BD与L3out(例如,1650)相关联,并且在BD的EPG和L3out的EPG之间存在安全性契约(例如,契约1)。当BD子网标记为公共的并且BD与L3out关联时,路由可以在结构外部正常进行。
设备300可以验证这些BD-L3out配置条件。特别地,设备300可以确认模型反映内部网络实际上已经泄漏。此特定检查使用一系列L_模型一致性检查(或考虑多个信息字段的单个检查)。
图17示出了网络环境的BD-L3out关联配置的示例网络保证的示例流程图。图17所示的方法是作为示例提供的,但存在多种方式来执行该方法。此外,虽然用特定的序列顺序来说明示例方法,但是本领域的普通技术人员将理解,图17和其中所示的序列可以按照实现本公开的技术优点的任何顺序来执行,并且可以包括比所示更少或更多的序列。
图17中的每个序列表示示例方法中执行的一个或多个过程、方法或子例程。图17中示出的序列可以在诸如图7中示出的网络环境700的网络环境中实现。应用可以存在于设备300和/或检查器620上,但本申请不限于此。
在序列1710处,接收要检查的各种模型(例如,L_模型、C_模型和/或H_模型)。例如,结构120中的一个或多个叶节点104、脊节点102和控制器116可以将L_模型270A/B、Ci_模型274和H_模型274发送到应用(例如,保证设备300)。在另一示例中,提供和/或接收L_模型、C_模型、和/或H_模型配置中的部分而不是全部。这些接收到的模型可以包括信息内容,该信息内容中的至少一部分将经受验证过程。在一些示例中,信息可以包括L3out配置数据和BD配置数据。
在序列1720处,应用通过L_模型一致性检查来识别是否有任何BD子网被标记为公共的。在一些示例中,结构中的BD子网被配置为私有的、共享的等。为了使子网被标记为公共的,操作员必须在L_模型270A中将子网指定为公共的,并将该配置推送到控制器116。应用可以通过L_Model一致性检查来验证所接收的L_Model 622中是否有任何BD子网标记为公共的。如果没有,则此检查结束于序列1760。如果接收到的L_模型622中的BD子网中的一个或多个被标记为公共的,则针对被标识为公共的每个子网,过程于1730处继续;将针对这样标识的单个子网来描述该过程,但应当理解,该过程也应用于多个被标识的子网。
在序列1730处,通过L_模型一致性检查,应用可以验证公共BD与L3out相关联。BD通过BD配置与L3out相关联。可以由操作员在控制器116处将BD配置编程在L_模型270A中(例如,租户配置740),并且该配置随后可以经由上文中的序列1710到达检查器620处。图16示出了BD-L3out关联1650的示例。应用可以通过L_模型一致性检查来验证关联。
在序列1740处,通过L_模型一致性检查,应用可以验证EPG(例如,逻辑组)之间的契约。如上所示,L3out可以具有EPG(例如,EPG2),BD可以具有EPG(例如EPG1)。当在EPG之间形成契约(例如,契约1)时,那么相关联的端点可以通信。设备300可以验证L3out下的EPG和BD下的EPG之间是否存在安全性契约。
在序列1750处,可以生成一个或多个事件。例如,当验证是一致的(例如,与验证的预期一致)时,应用可以生成信息事件。在其他示例中,当验证中的一个或多个不一致(例如,与验证的预期不一致),配置不在正确的叶上(根据L_模型),或者当丢失信息或存在额外信息时,应用可能生成错误事件。错误事件的严重性至少可以基于哪个验证不一致以及哪个设备具有不一致性(例如,生产设备、测试设备、访问点、边界叶节点,等等)来确定。
正确传播的学习到的(导入的)路由
学习到的路由(例如,导入路由)是泄漏(即,导入)到结构120内部的外部网络。外部网络(例如,要被泄漏的)可以是外部设备(例如,网络设备114)意图通过边界叶节点(例如,叶节点N)与结构120共享的网络。结构120理论上可以导入由外部路由器提供的所有网络,或者仅导入特定的外部网络。决策可以基于网络设备的资源,例如LPM表。当所有外部路由被导入,例如数千个网络,在每个网络设备(例如,叶节点104、脊节点102等)处存储这些学习到的路由会利用昂贵的资源。学习的路由填充存储在每个网络设备的TCAM中的LPM表。这些资源的过度使用会影响结构的效率和整体操作。边界叶节点(例如,叶节点N)可以判定(例如,基于操作员意图)导入哪个外部网络。
由操作员将允许泄漏特定外部网络的指令的部署编程到L_模型270A中,并且该部署能够标识针对特定边界叶节点104(例如叶节点N),哪些网络可以泄漏到结构120中。特定的边界叶节点104(例如叶节点N)可以将允许的网络存储在Ci_模型中的L3out表(例如,叶节点N的表1806)中定义的EPG中。
当外部设备(例如,网络设备114)希望通过边界叶节点(例如,叶节点N)与结构102共享外部网络时,边界叶节点(例如,叶节点N)从其L3out表中初步确定该网络的导入是否是允许的。如果允许,边界叶节点(例如,叶节点N)将该外部设备设置为LPM表(例如,叶节点N的748)中的下一跳。边界叶节点(例如,叶节点N)的L3out在特定VRF下,并且边缘叶节点作为泄漏的“源”,其将学习到的路由传播(例如,泄漏)到其他叶节点104(例如,学生叶节点),该其他叶节点具有在同一特定VRF下的L3out或BD。这些“学生”叶节点104将学习到的路径存储在其LPM表(例如,叶节点1为1802,叶节点2为742)中,并将下一跳设置到源叶节点(例如,叶节点N)。根据在同一VRF下具有L3out和/或BD的源叶节点和学生叶节点,这些源叶和学生叶104定义“VRF叶节点组”。
图7的结构120中示出了学习到的路径的非限制性示例。L_模型270A/B包含其可以从外部网络175.*导入的叶节点N的指示。叶节点N将其包含在它的CN_模型272中,作为LPM表1806中的L3out。外部网络设备114意图通过边界叶节点N将网络导出到结构120,例如,如网络设备114的路由和转发表744所列的外部子网175.*、185.*、195.*。因为175.*列在表1806中,边界叶节点N可以导入网络175.*(例如,EPG(175.*)),但是不能导入网络185.*和195.*,因为它们不在表1806中。边界叶节点N更新表748,下一跳指示符为网络设备114(175.*→设备114)。然后,边界叶节点N可以将泄漏扩散到VRF叶节点组的其余部分,在此示例中,该组包括叶节点1和叶节点2。叶节点1和叶节点2可以在Ci_模型274级更新其LPM表(例如1802、742),以反映175.*的导入,并将叶节点N设置为对应的下一跳,以反映它是源叶节点(例如175.*→叶N)。
在一些示例中,多个边界叶节点从相同的外部设备导入网络。在图7中,叶节点3也是如虚线1804所示的连接到外部网络设备114的边界叶节点,因此也导入网络175.*并将导入的网络传播到叶节点1和叶节点2。LPM表(例如1802、742)反映下一跳可以是叶节点3或叶节点N(例如175.*→叶节点3、叶节点N)。在一些示例中,LPM表可能有错误。例如,设备的LPM表(例如1802、742等)可以包括与边界叶节点的LPM表(例如748)等效的学习到的路由。转到图7,叶节点2的LPM表(例如,742)示出与边界叶节点N中的等效的学习到的路径(例如175.*),而叶节点1的LPM表(例如1802)示出不在边界叶节点N中的额外的学习到的路径(例如185.*)。网络185.*未被L_模型270A授权用于导入。因此,学习路径185.*的存在是差异,并可能产生错误。
图18示出了网络环境的学习到的路由的示例网络保证的示例流程图。图18所示的方法是作为示例提供的,但存在多种方式来执行该方法。另外,尽管以特定顺序的序列示出了示例方法,但是本领域普通技术人员将理解,图18及其中所示的顺序可以以实现本公开的技术优点的任何顺序来执行,并且其中可以包括比示出的更少或更多的序列。
图18中的每个序列表示示例方法中执行的一个或多个过程、方法或子例程。图18中示出的序列可以在诸如图7中示出的网络环境700的网络环境中实现。应用可以存在于设备300和/或检查器620上,但本申请不限于此。
方法1800可以从序列1810开始。在序列1810处,应用(例如,保证设备300)可以接收要检查的各种模型(例如,L_模型、C_模型和/或H_模型)。例如,结构120中的每个控制器116可以向应用(例如,保证设备300和/或检查器620)发送一个或多个L_模型270A/B,每个叶节点104和脊节点102发送其相应的Ci_模型274和Ci_模型276。在另一示例中,提供和/或接收L_模型、C_模型、和/或H_模型配置中的部分而不是全部。这些接收到的模型将包括信息内容,该信息内容中的至少一部分将经受验证过程。例如,结构120中的每个边界叶节点(例如叶节点3、叶节点N等)可以向应用发送与软件模型(C_模型)相关联的信息。在一些示例中,信息可以是LPM表(例如,L3表)和L3out配置。
学习到的路由可以出现在边界节点(例如,边界叶节点)的Ci_模型274和L_模型270A的L3out的EPG中的LPM表中。在序列1820处,应用针对一个或多个边界叶节点查验C_模型624以及L_模型622,以确认所学习到的路径彼此一致。例如,当L3out的EPG包括导入的路由175.*时,LPM表应包括175.*作为导入的路由(并且没有其他学习到的路由,除非从不同的边界叶节点或不同的L3out导入)。响应于L3out的EPG和LPM表之间的学习到的路由的差异,可以生成错误事件(例如,在序列1860处)。响应于不存在差异,则可以生成信息事件。
序列1820可能需要Ci_模型624和L_模型622的公共格式步骤,但感兴趣的主题可以从具有公共格式的模型的重叠字段提取公共格式以及从模型中不重叠的字段提取。
在序列1830处,应用可以验证“源”是“学生”叶上存在的学习到的路由(例如,EPG/逻辑组的VRF存在)。因此,应用检查公共VRF叶节点组中所有叶节点的Ci_模型624配置,以确认学习到的路径在整个组中是一致的。这可以是每个Ci_模型和跨多个Ci_模型的C模型级一致性检查。关于图7,该检查将确认175.*的所有列表在这些叶节点中是正确的;它还将识别网络185.*被不正确地列在1802中,并触发相应的错误事件。
在序列1840处,应用可以验证导入路由的下一跳。对于源叶节点中的学习到的路由,此为Ci_模型级一致性检查,用于验证下一跳指向外部设备。作为非限制性示例,在图7中,检查叶节点N的CN_模型以确认网络175的下一跳是请求导入的外部设备(例如175.*→设备114)。在学生叶节点中的学习到的路径示例中,此为Ci_模型级一致性检查,用于验证下一跳是否指向源叶节点。通过非限制性示例,在图7中,检查叶节点1和叶节点2的Ci_模型,以确认学习到的路径(例如175.*)指向边界叶节点(例如叶节点3和叶节点N)。当存在多于一个边界叶节点和两个下一跳(例如,175.*,例如175.*→叶节点3、叶节点N)时,应用可以验证两个下一跳(对于网络冗余,这是常见的)。
当在两个下一跳之间路由时,叶节点(例如,叶节点1)可以基于流(例如,源IP、源端口、目标IP、目标端口等)计算散列。计算出的散列将对边界叶节点数量取模。在此示例中,存在两个边界叶节点,因此计算处的散列对2取模(例如,散列%2)。然后将在模块输出之间散步(spray)路由。
在序列1850处,可以生成一个或多个事件。例如,当验证是一致的(例如,与验证的预期一致)时,应用可以生成信息事件。在其他示例中,当验证中的一个或多个不一致(例如,与验证的预期不一致),配置不在正确的叶节点上(根据L_模型),或者当缺少信息或存在额外信息时,应用可生成错误事件。错误事件的严重性至少可以根据验证不一致和不一致的设备(例如,生产设备、测试设备、访问点、边界页等)来确定。
重叠子网的检测
网络中的重叠子网(例如,结构120)可导致转发期间(例如,使用LPM)的错误路由和丢失分组。在结构中,每个VRF中可以存在多个网络,例如BD子网;EPG子网(功能与BD子网相同);L3out接口;L3out环回;L3out静态路由;L3out环回;学习到的路由,等等。可以由操作员意图确定或导入(例如,学习)这些多个网络。网络(例如,子网)中的每个都可以具有IP地址和掩码(例如,IPv4、IPv6等)。掩码确定在转发数据(例如LPM)中使用了多少IP地址。例如,200.1.1.1/16的IP/掩码将用作200.1.*,因为最后16位(在IPv4地址中)被屏蔽。
图19示出了潜在子网重叠和例外的网络图1900。通常,结构中的子网可以遍布在可能的子网中。然而,操作员意图(例如,错误内容)和掩码可造成意外的重叠。例如,BDl子网和BD2子网可以重叠,因为BD1和BD2可以配置至少一个相同的子网(例如,两者都配置有100.1.1.1的子网)。在本示例中,存在重叠并生成事件。在其他示例中,此重叠可以由掩码约束。例如,BDl可以具有32的掩码(例如,100.1.1.1/32),BD2可以具有24的掩码(例如,100.1.1.1/24)。在此示例中,当转发数据时,BDl将具有子网100.1.1.1,BD2将具有子网100.1.1.*.。因此,除100.1.1.1以外的任何内容都将转发给BD2。
虽然上述重叠受掩码的约束,但如BD3子网和BD4子网所示,完全重叠仍然是可能的。例如,BD3子网可以包括200.1.1.0/16,BD4子网可以包括200.1.1.1/24。在本示例中,当子网不同时,掩码将使它们重叠,BD3子网将是200.1.*,而BD4子网将是200.1.1.*。因此,任何到200.1.1.0(或200.1.1.*)的转发将转到BD4子网,即使其意图可能是发送到BD3子网(因为LPM)。此重叠会产生事件。一个例外是如果BD3和BD4是相同的BD(例如,转发将是到相同的BD,因此没有冲突)。
在某些情况下,存在安全性契约的EPG可以位于不同的VRF中,如图12所示(例如,从BD2到VRF2的虚线)。例如,BD2可以绑定到VRF2,BD1可以绑定到VRF1。当EPG3(绑定到BD2)和EPG1(绑定到BD1)之间形成安全契约2时,BD2的子网(例如300.*和400.*)泄漏到VRF1,BD1的子网(例如100.*和200.*)泄漏到VRF2。一旦子网泄漏,VRF1不能在不发生子网冲突的情况下单独使用子网300.*和400.*,而VRF2不能在不发生子网冲突的情况下单独使用子网100.*和200.*。设备300被配置为在EPG之间形成契约时验证和检查子网之间不存在冲突。
学习到的路由和BD5子网所显示的重叠也有一些例外。在此示例中,学习到的路由的可以具有子网200.*(例如,掩码8),BD5子网可以具有子网200.1.1.*。BD5子网由结构(例如,内部)所有,学习到的路由由外部所有。在此示例中,与使用LPM时不同的是,重叠没有关系,因为具有200.1.1.XXX的任何内容都将被转发到BD5,而其他内容都将被转发到外部。因此,内部路由优先于外部路由,不会出现对数据的错误路由。然而,当情况相反时(BD5subnet为200.*,而外部为200.1.1.*时),内部网络不被提供为优选,内部数据可能会发送到结构外部,并且可能会生成错误。
图20示出了网络环境的学习到的路由的示例网络保证的示例流程图。图20所示的方法是作为示例提供的,但存在多种方式来执行该方法。另外,尽管以特定顺序的序列示出了示例方法,但是本领域普通技术人员将理解,图20及其中所示的顺序可以以实现本公开的技术优点的任何顺序来执行,并且其中可以包括比示出的更少或更多的序列。
图20中的每个序列表示示例方法中执行的一个或多个过程、方法或子例程。图20中示出的序列可以在诸如图7中示出的网络环境700和图19中所示的网络图1900的网络环境中实现。应用可以存在于设备300和/或检查器620上,但本申请不限于此。
方法2000可以从序列2010开始。在序列2010处,应用(例如,保证设备300)接收要检查的各种模型(例如,L_模型、C_模型和/或H_模型)。例如,结构120中的每个控制器116可以向应用(例如,保证设备300和/或检查器620)发送一个或多个L_模型270A/B,每个叶节点104和脊节点102发送其相应的Ci_模型274和Ci_模型276。在另一示例中,提供和/或接收L_模型、C_模型、和/或H_模型配置中的部分而不是全部。这些接收到的模型将包括信息内容,该信息内容中的至少一部分将经受验证过程。在一些示例中,信息可以包括每个VRF中的多个网络(例如,来自LPM表、租户配置等)。
在序列2020处,应用可以确定每个VRF的接收网络之间不允许的重叠(例如,在接收的L_模型中)。子网可以在L_模型270A/B中找到,学习到的路由可以在每个VRF的单个Ci_模型274配置中找到。可以查验所有这些子网(包括学习到的路由),以指示重叠。不存在例外的重叠构成差异。
在序列2030处,可以生成一个或多个事件。例如,当验证是一致的(例如,与验证的预期一致)时,应用可以生成信息事件。在其他示例中,当一个或多个验证不一致(例如,与验证的预期不一致)时,配置不在正确的叶节点上(根据L_模型),或者当丢失或存在额外信息时,应用可生成错误事件。错误事件的严重性至少可以根据验证不一致和不一致的设备(例如,生产设备、测试设备、访问点、边界页等)来确定。
参考叶节点/脊节点描述了上述实施例。然而,本申请并不限于此,并且该方法可以应用于其他拓扑。
本公开现在转向图21和图22,其示出了示例网络设备和计算设备,例如,交换机、路由器、负载平衡器、客户端设备等。
图21示出了适用于执行交换、路由、负载平衡、和其他联网操作的示例网络设备2100。网络设备2100包括中央处理单元(CPU)2104、接口2102和总线2110(例如,PCI总线)。当在适当的软件或固件的控制下动作时,CPU 2104负责执行分组管理、错误检测和/或路由功能。CPU 2104可以在包括操作系统和任何适当的应用软件的软件的控制下完成所有这些功能。CPU 2104可以包括一个或多个处理器2108,例如来自INTEL X86系列微处理器的处理器。在一些情况下,处理器2108可以是用于控制网络设备2100的操作的专门设计的硬件。在一些情况下,存储器2106(例如,非易失性RAM、ROM等)也形成CPU 2104的一部分。然而,有许多不同的方式可以将存储器耦合到系统。
接口2102通常作为模块化接口卡(有时被称为“线卡”)提供。通常,它们控制通过网络发送和接收数据分组,并且有时支持与网络设备2100一起使用的其他外围设备。可以提供的接口包括以太网接口、帧中继接口、线缆接口、DSL接口、令牌环接口等等。此外,可提供各种非常高速的接口,例如,快速令牌环接口、无线接口、以太网接口、千兆以太网接口、ATM接口、HSSI接口、POS接口、FDDI接口、WIFI接口、3G/4G/5G蜂窝接口、CAN总线、LoRA等。一般而言,这些接口可以包括适合于与适当介质通信的端口。在一些情况下,它们还可以包括独立处理器,并且在一些情况下,还包括易失性RAM。独立处理器可以控制诸如分组交换、介质控制、信号处理、加密处理、和管理之类的通信密集型任务。通过为通信密集型任务提供分离的处理器,这些接口允许主微处理器604高效地执行路由计算、网络诊断、安全性功能等。
尽管图21中所示的系统是本发明的一个特定网络设备,但它决不是可以在其上实现本公开的概念的唯一网络设备架构。例如,经常使用具有处理通信以及路由计算等的单个处理器的架构。此外,其他类型的接口和介质也可以与网络设备2100一起使用。
无论网络设备的配置如何,它都可以采用一个或多个存储器或存储器模块(包括存储器2106),其被配置为存储用于本文所描述的漫游、路由优化和路由功能的通用网络操作和机制的程序指令。例如,程序指令可以控制操作系统和/或一个或多个应用的操作。一个或多个存储器还可以被配置为存储诸如移动性绑定、注册和关联表之类的表。存储器2106还可以保存各种软件容器和虚拟化的执行环境和数据。
网络设备2100还可以包括专用集成电路(ASIC),其可以被配置为执行路由和/或交换操作。例如,ASIC可以经由总线2110与网络设备2100中的其他组件通信,以交换数据和信号并协调网络设备2100的各种类型的操作,例如路由、交换、和/或数据存储操作。
图22示出了计算系统架构2200,其中该系统的组件使用诸如总线之类的连接2205彼此电通信。系统2200包括处理单元(CPU或处理器)2210和系统连接2205,系统连接2205将包括系统存储器2215在内的各种系统组件(例如,只读存储器(ROM)2220和随机存取存储器(RAM)2225)耦合到处理器2210。系统2200可以包括高速存储器的缓存,其与处理器2210直接连接、靠近处理器2210、或者集成作为处理器2210的一部分。系统2200可以将数据从存储器2215和/或存储设备2230复制到缓存2212以供处理器2210快速访问。以这种方式,缓存可以提供性能提升,避免处理器2210在等待数据时的延迟。这些和其他模块可以控制或被配置为控制处理器2210以执行各种动作。也可以使用其他系统存储器2215。存储器2215可以包括具有不同性能特性的多个不同类型的存储器。处理器2210可以包括任何通用处理器和被配置为控制处理器2210的硬件或软件服务(例如,存储在存储设备2230中的服务1 2232、服务2 2234和服务32236)以及其中将软件指令包含在实际的处理器设计中的专用处理器。处理器2210可以是完全自包含的计算系统,包含多个核或处理器、总线、存储器控制器、缓存等。多核处理器可以是对称的或非对称的。
为了实现与计算设备2200的用户交互,输入设备2245可以表示任何数量的输入机制,诸如用于语音的麦克风、用于手势或图形输入的触敏屏幕、键盘、鼠标、运动输入、语音等等。输出设备2235也可以是本领域技术人员已知的多种输出机构中的一种或多种。在一些情况下,多模式系统可以使用户能够提供多种类型的输入以与计算设备2200通信。通信接口2240通常可以控制和管理用户输入和系统输出。对任何特定硬件布置进行的操作没有限制,因此这里的基本特征可以很容易地随着改进的硬件或固件布置被开发而被替换为这些改进的硬件或固件布置。
存储设备2230是非易失性存储器,并且可以是硬盘或其他类型的计算机可读介质,其可以存储可由计算机访问的数据,例如磁带盒、闪存卡、固态存储器设备、数字通用盘、盒式磁带、随机存取存储器(RAM)2225、只读存储器(ROM)2220及其混合。
存储设备2230可以包括用于控制处理器2210的服务2232、2234、2236。可以预期其他硬件或软件模块。存储设备2230可以连接到系统连接2205。在一个方面,执行特定功能的硬件模块可以包括存储在与必要的硬件组件(例如,处理器2210、连接2205、输出设备2235等)相连的计算机可读介质中的软件组件以执行功能。
总而言之,公开了用于保证网络环境中的租户转发的系统、方法和计算机可读介质。可以在网络环境的第1层、第2层和第3层中确定网络保证,网络保证包括网络环境中的内部(例如,结构中)转发和内部-外部(例如,结构外部)转发。可以使用逻辑配置、软件配置和/或硬件配置来执行该网络保证。
为了解释的清楚起见,在一些实例中,本技术可以被呈现为包括个体的功能序列,其包括包含以下项的功能序列:设备、设备组件、在软件中体现的方法中的步骤或例程、或者硬件和软件的组合。
在一些实施例中,计算机可读存储设备、介质和存储器可以包括包含比特流等的有线或无线信号。然而,当提及时,非暂时性计算机可读存储介质明确地排除诸如能量、载波信号、电磁波和信号本身之类的介质。
可以使用存储在计算机可读介质中或以其他方式可从计算机可读介质获得的计算机可执行指令来实现根据上述示例的方法。这样的指令可以包括例如使得或以其他方式配置通用计算机、专用计算机或专用处理设备以执行特定功能或功能组的指令和数据。可以通过网络访问所使用的计算机资源的部分。计算机可执行指令可以是例如二进制指令、诸如汇编语言之类的中间格式指令、固件、或源代码。可用于存储指令、所使用的信息和/或在根据所描述的示例的方法期间创建的信息的计算机可读介质的示例包括磁盘或光盘、闪存、具有非易失性存储器的USB设备、联网的存储设备等等。
实现根据这些公开内容的方法的设备可以包括硬件、固件和/或软件,并且可以采用各种形式因子中的任何形式因子。这种形式因子的典型示例包括膝上型计算机、智能电话、小型个人计算机、个人数字助理、机架设备、独立设备等。本文描述的功能也可以实现在外围设备或附加卡中。作为进一步的示例,这样的功能还可以在不同芯片之间的电路板上实现,或者在单个设备中执行的不同处理过程中实现。
指令、用于传达这些指令的介质、用于执行它们的计算资源以及用于支持这种计算资源的其他结构是用于提供这些公开内容中所描述的功能的手段。
尽管使用各种示例和其他信息来解释所附权利要求范围内的各个方面,但是不应基于这些示例中的特定特征或布置来暗示对权利要求的限制,因为普通技术人员将能够使用这些示例来导出各种各样的实现方式。此外,尽管可能已经用特定于结构特征和/或方法步骤的示例的语言描述了一些主题,但是应该理解,所附权利要求中定义的主题不必限于这些描述的特征或动作。例如,这种功能可以在本文标识的那些组件之外的组件中以不同的方式分布或者在本文标识的那些组件之外的组件中执行。相反,所描述的特征和步骤被公开为所附权利要求范围内的系统和方法的组分的示例。
记载“……中的至少一个”的权利要求语言指的是集合中的至少一个,并且指示该集合中的一个成员或该集合中的多个成员满足该权利要求。例如,记载“A和B中的至少一个”的权利要求语言意思是A、B或A和B。
Claims (23)
1.一种用于对结构中的配置的正确部署执行网络保证检查的系统,包括:
至少一个存储器,配置为存储数据;以及
至少一个处理器,可操作用于执行与所述数据相关联的指令,其中所述指令当被所述至少一个处理器执行时,使得所述处理器:
从控制器接收第一格式的全局逻辑模型,所述全局逻辑模型包含关于连接到网络结构的端点如何在所述结构内进行通信的指令;
从所述结构中的一个或多个网络设备接收软件模型,所述软件模型是来自所述全局逻辑模型的指令的至少一个子集并具有在所述一个或多个网络设备上可执行的第二格式,指令的所述子集是来自所述全局逻辑模型的、特定于所述一个或多个网络设备的可操作性的指令;
创建所述第一格式的局部逻辑模型,所述局部逻辑模型是所接收的全局逻辑模型的至少一部分,该部分包含关于连接到网络结构的端点如何在所述结构内进行通信的指令;
将所创建的局部逻辑模型的至少一部分和所接收的软件模型的至少一部分转换为公共格式;以及
对所述公共格式的所述局部逻辑模型和所述公共格式的所述软件模型中的重叠字段的内容进行比较;
其中,所述比较的肯定结果表示所述一个或多个网络设备从所接收的全局逻辑模型准确地创建了所接收的软件模型。
2.根据权利要求1所述的系统,其中所述第一格式和所述第二格式彼此不同。
3.根据权利要求1或2所述的系统,其中所述公共格式是所述第一格式和所述第二格式中的一个,或者所述公共格式与所述第一格式和所述第二格式二者都不同。
4.根据权利要求1至3中任一项所述的系统,还包括指令,所述指令在被所述至少一个处理器执行时使得所述至少一个处理器:
从所述结构中的所述一个或多个网络设备接收从所述软件模型转换的硬件配置的硬件模型;
将所接收的软件模型的至少一部分和所接收的硬件模型的至少一部分转换为所述公共格式;
对所述公共格式的所述软件模型和所述公共格式的所述硬件模型中的重叠字段的内容进行比较;以及
其中,所述比较的肯定结果表示所述一个或多个网络设备将所述软件模型准确地转换为了所述硬件模型。
5.根据权利要求4所述的系统,其中所述硬件模型具有与所述第一格式和所述第二格式不同的格式。
6.根据权利要求4或5所述的系统,其中所述公共格式是所述第二格式和第三格式中的一个,或者所述公共格式与所述第二格式和所述第三格式二者都不同。
7.根据权利要求4至6中任一项所述的系统,其中所述比较的肯定结果表示所述一个或多个网络设备从所述全局逻辑模型准确地创建了所述硬件模型。
8.至少一个非暂时性计算机可读介质,用于存储指令,其中所述指令当被处理器执行时,使得所述处理器:
从控制器接收第一格式的全局逻辑模型,所述全局逻辑模型包含关于连接到网络结构的端点如何在所述结构内进行通信的指令;
从所述结构中的一个或多个网络设备接收软件模型,所述软件模型是来自所述全局逻辑模型的指令的至少一个子集并具有在所述一个或多个网络设备上可执行的第二格式,指令的所述子集是来自所述全局逻辑模型的、特定于所述一个或多个网络设备的可操作性的指令;
创建所述第一格式的局部逻辑模型,所述局部逻辑模型是所接收的全局逻辑模型的至少一部分,该部分包含关于连接到网络结构的端点如何在所述结构内进行通信的指令;
将所创建的局部逻辑模型的至少一部分和所接收的软件模型的至少一部分转换为公共格式;以及
对所述公共格式的所述局部逻辑模型和所述公共格式的所述软件模型中的重叠字段的内容进行比较;
其中,所述比较的肯定结果表示所述一个或多个网络设备从所接收的全局逻辑模型准确地创建了所接收的软件模型。
9.根据权利要求8所述的计算机代码,其中所述第一格式和所述第二格式彼此不同。
10.根据权利要求8或9所述的计算机代码,其中所述公共格式是所述第一格式和所述第二格式中的一个,或者所述公共格式与所述第一格式和所述第二格式二者都不同。
11.根据权利要求8至10中任一项所述的计算机代码,还包括用于以下操作的指令:
从所述结构中的所述一个或多个网络设备接收从所述软件模型转换的硬件配置的硬件模型;
将所接收的软件模型的至少一部分和所接收的硬件模型的至少一部分转换为所述公共格式;
对所述公共格式的所述软件模型和所述公共格式的所述硬件模型中的重叠字段的内容进行比较;以及
其中,所述比较的肯定结果表示所述一个或多个网络设备将所述软件模型准确地转换为了所述硬件模型。
12.根据权利要求11所述的计算机代码,其中所述硬件模型具有与所述第一格式和所述第二格式不同的格式。
13.根据权利要求11或12所述的计算机代码,其中所述公共格式是所述第二格式和第三格式中的一个,或者所述公共格式与所述第二格式和所述第三格式二者都不同。
14.根据权利要求11至13中任一项所述的计算机代码,其中所述比较的肯定结果表示所述一个或多个网络设备从所述全局逻辑模型准确地创建了所述硬件模型。
15.一种用于对结构中的配置的正确部署执行网络保证检查的方法,包括:
从控制器接收第一格式的全局逻辑模型,所述全局逻辑模型包含关于连接到网络结构的端点如何在所述结构内进行通信的指令;
从所述结构中的一个或多个网络设备接收软件模型,所述软件模型是来自所述全局逻辑模型的指令的至少一个子集并具有在所述一个或多个网络设备上可执行的第二格式,指令的所述子集是来自所述全局逻辑模型的、特定于所述一个或多个网络设备的可操作性的指令;
创建所述第一格式的局部逻辑模型,所述局部逻辑模型是所接收的全局逻辑模型的至少一部分,该部分包含关于连接到网络结构的端点如何在所述结构内进行通信的指令;
将所创建的局部逻辑模型的至少一部分和所接收的软件模型的至少一部分转换为公共格式;以及
对所述公共格式的所述局部逻辑模型和所述公共格式的所述软件模型中的重叠字段的内容进行比较;
其中,所述比较的肯定结果表示所述一个或多个网络设备从所接收的全局逻辑模型准确地创建了所接收的软件模型。
16.根据权利要求15所述的方法,其中所述第一格式和所述第二格式彼此不同。
17.根据权利要求15或16所述的方法,其中所述公共格式是所述第一格式和所述第二格式中的一个,或者所述公共格式与所述第一格式和所述第二格式二者都不同。
18.根据权利要求15至17中任一项所述的方法,还包括:
从所述结构中的所述一个或多个网络设备接收从所述软件模型转换的硬件配置的硬件模型;
将所接收的软件模型的至少一部分和所接收的硬件模型的至少一部分转换为所述公共格式;
对所述公共格式的所述软件模型和所述公共格式的所述硬件模型中的重叠字段的内容进行比较;
其中,所述比较的肯定结果表示所述网络设备中的一个先前将所述软件模型准确地转换为了所述硬件模型。
19.根据权利要求18所述的方法,其中所述硬件模型具有与所述第一格式和所述第二格式不同的格式。
20.根据权利要求18或19所述的方法,其中所述公共格式是所述第二格式和第三格式中的一个,或者所述公共格式与所述第二格式和所述第三格式二者都不同。
21.一种用于对结构中的配置的正确部署执行网络保证检查的设备,包括:
用于从控制器接收第一格式的全局逻辑模型的装置,其中所述全局逻辑模型包含关于连接到网络结构的端点如何在所述结构内进行通信的指令;
用于从所述结构中的一个或多个网络设备接收软件模型的装置,其中所述软件模型是来自所述全局逻辑模型的指令的至少一个子集并具有在所述一个或多个网络设备上可执行的第二格式,指令的所述子集是来自所述全局逻辑模型的、特定于所述一个或多个网络设备的可操作性的指令;
用于创建所述第一格式的局部逻辑模型的装置,其中所述局部逻辑模型是所接收的全局逻辑模型的至少一部分,该部分包含关于连接到网络结构的端点如何在所述结构内进行通信的指令;
用于将所创建的局部逻辑模型的至少一部分和所接收的软件模型的至少一部分转换为公共格式的装置;以及
用于对所述公共格式的所述局部逻辑模型和所述公共格式的所述软件模型中的重叠字段的内容进行比较的装置;
其中,所述比较的肯定结果表示所述一个或多个网络设备从所接收的全局逻辑模型准确地创建了所接收的软件模型。
22.根据权利要求21所述的设备,还包括用于实现根据权利要求16至20中任一项所述的方法的装置。
23.一种计算机程序、计算机程序产品或计算机可读介质,其包括指令,所述指令当被计算机执行时,使得所述计算机执行根据权利要求15至20中任一项所述的方法的步骤。
Applications Claiming Priority (7)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201762521763P | 2017-06-19 | 2017-06-19 | |
US62/521,763 | 2017-06-19 | ||
US15/663,627 US10673702B2 (en) | 2017-06-19 | 2017-07-28 | Validation of layer 3 using virtual routing forwarding containers in a network |
US15/663,587 US10432467B2 (en) | 2017-06-19 | 2017-07-28 | Network validation between the logical level and the hardware level of a network |
US15/663,627 | 2017-07-28 | ||
US15/663,587 | 2017-07-28 | ||
PCT/US2018/038030 WO2018236726A1 (en) | 2017-06-19 | 2018-06-18 | NETWORK VALIDATION BETWEEN THE LOGIC LEVEL AND THE MATERIAL LEVEL OF A NETWORK |
Publications (2)
Publication Number | Publication Date |
---|---|
CN110754065A true CN110754065A (zh) | 2020-02-04 |
CN110754065B CN110754065B (zh) | 2022-11-01 |
Family
ID=64656706
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201880040486.8A Active CN110754065B (zh) | 2017-06-19 | 2018-06-18 | 网络的逻辑级和硬件级之间的网络验证 |
Country Status (4)
Country | Link |
---|---|
US (2) | US10432467B2 (zh) |
EP (1) | EP3643011B1 (zh) |
CN (1) | CN110754065B (zh) |
WO (1) | WO2018236726A1 (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN118509250A (zh) * | 2024-07-12 | 2024-08-16 | 武汉明合永安科技有限公司 | 基于抗毁性测试技术的网络安全漏洞检测方法及系统 |
Families Citing this family (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP6585656B2 (ja) | 2017-05-10 | 2019-10-02 | 株式会社ソニー・インタラクティブエンタテインメント | 製造ライン用コンピュータシステム及びそのネットワーク設定方法 |
US11645131B2 (en) * | 2017-06-16 | 2023-05-09 | Cisco Technology, Inc. | Distributed fault code aggregation across application centric dimensions |
US10574513B2 (en) * | 2017-06-16 | 2020-02-25 | Cisco Technology, Inc. | Handling controller and node failure scenarios during data collection |
US10341184B2 (en) | 2017-06-19 | 2019-07-02 | Cisco Technology, Inc. | Validation of layer 3 bridge domain subnets in in a network |
US10673702B2 (en) * | 2017-06-19 | 2020-06-02 | Cisco Technology, Inc. | Validation of layer 3 using virtual routing forwarding containers in a network |
US10218572B2 (en) * | 2017-06-19 | 2019-02-26 | Cisco Technology, Inc. | Multiprotocol border gateway protocol routing validation |
US10826775B1 (en) * | 2019-06-19 | 2020-11-03 | Cisco Technology, Inc. | Policy plane integration across multiple domains |
US11153420B2 (en) | 2019-10-18 | 2021-10-19 | Arista Networks, Inc. | Neighbor equivalence groups |
US11743142B1 (en) * | 2021-12-20 | 2023-08-29 | Illumio, Inc. | Segmentation using infrastructure policy feedback |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050154735A1 (en) * | 2003-12-19 | 2005-07-14 | International Business Machines Corporation | Resource management |
KR20090104382A (ko) * | 2008-03-31 | 2009-10-06 | 주식회사 케이티 | 모니터링 시스템, 모니터링 장치 및 방법 |
US20160112246A1 (en) * | 2014-10-17 | 2016-04-21 | International Business Machines Corporation | Identifying configuration inconsistency in edge-based software defined networks (sdn) |
Family Cites Families (147)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5204829A (en) | 1992-07-10 | 1993-04-20 | Lsi Logic Corporation | Interleaving operations in a floating-point numeric processor |
US20040168100A1 (en) | 2000-12-04 | 2004-08-26 | Thottan Marina K. | Fault detection and prediction for management of computer networks |
ITTO20010180A1 (it) | 2001-03-01 | 2002-09-01 | Cselt Centro Studi Lab Telecom | Procedimento e sistema per il controllo della configurazione dei nodidi una rete per telecomunicazione. |
US7003562B2 (en) | 2001-03-27 | 2006-02-21 | Redseal Systems, Inc. | Method and apparatus for network wide policy-based analysis of configurations of devices |
DE10143101A1 (de) | 2001-09-03 | 2003-04-03 | Infineon Technologies Ag | Verfahren zur Validierung von Simulationsergebnissen eines Systems sowie darauf aufbauender Äquivalenzvergleich digitaler Schaltungen |
US20030229693A1 (en) | 2002-06-06 | 2003-12-11 | International Business Machines Corporation | Self-correcting monitor |
US8073935B2 (en) | 2002-07-25 | 2011-12-06 | Oracle America, Inc. | Pluggable semantic verification and validation of configuration data |
ITTO20020742A1 (it) | 2002-08-23 | 2004-02-24 | Telecom Italia Lab Spa | Procedimento e sistema per il controllo della |
US7558847B2 (en) * | 2002-09-13 | 2009-07-07 | Intelliden, Inc. | System and method for mapping between and controlling different device abstractions |
GB0224187D0 (en) | 2002-10-17 | 2002-11-27 | Mitel Knowledge Corp | Interactive conflict resolution for personalised policy-based services |
US6856951B2 (en) * | 2002-11-15 | 2005-02-15 | Rajat Moona | Repartitioning performance estimation in a hardware-software system |
US7453886B1 (en) | 2003-03-11 | 2008-11-18 | Nortel Networks Limited | Verification of communications paths between devices |
US7089369B2 (en) | 2003-03-31 | 2006-08-08 | Sun Microsystems, Inc. | Method for optimizing utilization of a double-data-rate-SDRAM memory system |
US8645276B2 (en) * | 2003-07-11 | 2014-02-04 | Ca, Inc. | Modeling of applications and business process services through auto discovery analysis |
US9264922B2 (en) | 2003-08-05 | 2016-02-16 | Mobileum Inc. | Method and system for ensuring service continuity in case of a proxy profile gateway failure or interruption |
JP4251964B2 (ja) * | 2003-11-10 | 2009-04-08 | 富士通マイクロエレクトロニクス株式会社 | 検証装置、検証方法およびプログラム |
US20050108389A1 (en) | 2003-11-13 | 2005-05-19 | International Business Machines Corporation | Network endpoint health check |
US7360064B1 (en) | 2003-12-10 | 2008-04-15 | Cisco Technology, Inc. | Thread interleaving in a multithreaded embedded processor |
US7609647B2 (en) | 2004-05-12 | 2009-10-27 | Bce Inc. | Method and apparatus for network configuration validation |
US8010952B2 (en) | 2004-06-08 | 2011-08-30 | Cisco Technology, Inc. | Method and apparatus for configuration syntax and semantic validation |
US7505463B2 (en) | 2004-06-15 | 2009-03-17 | Sun Microsystems, Inc. | Rule set conflict resolution |
US7698561B2 (en) | 2004-08-12 | 2010-04-13 | Cisco Technology, Inc. | Method and system for detection of aliases in a network |
JP4192877B2 (ja) | 2004-09-29 | 2008-12-10 | ブラザー工業株式会社 | 設定データ伝送プログラム、設定データ伝送装置、および設定データ伝送システム |
US8024568B2 (en) | 2005-01-28 | 2011-09-20 | Citrix Systems, Inc. | Method and system for verification of an endpoint security scan |
US7619989B2 (en) | 2005-08-26 | 2009-11-17 | Alcatel Lucent | Routing configuration validation apparatus and methods |
US7765093B2 (en) | 2005-09-19 | 2010-07-27 | Itt Manufacturing Enterprises, Inc. | Network modeling system and method of simulating network operation with configurable node models |
US20070124437A1 (en) | 2005-11-30 | 2007-05-31 | Cisco Technology, Inc. | Method and system for real-time collection of log data from distributed network components |
US8046207B2 (en) * | 2005-12-27 | 2011-10-25 | The Mathworks, Inc. | Digital effects analysis in modeling environments |
JP2007241533A (ja) | 2006-03-07 | 2007-09-20 | Oki Electric Ind Co Ltd | システム構成情報比較装置およびコンピュータプログラム |
US8040895B2 (en) | 2006-03-22 | 2011-10-18 | Cisco Technology, Inc. | Method and system for removing dead access control entries (ACEs) |
US20080031147A1 (en) | 2006-08-01 | 2008-02-07 | Siemens Communications, Inc. | Network status determination |
CA2663299A1 (en) | 2006-09-12 | 2008-09-04 | Telcordia Technologies, Inc. | Ip network vulnerability and policy compliance assessment by ip device analysis |
US20080117827A1 (en) | 2006-11-17 | 2008-05-22 | Nec Corporation | Method and system for verifying connectivity of logical link |
US20130024844A1 (en) * | 2006-12-27 | 2013-01-24 | The Mathworks, Inc. | Continuous evaluation of program code and saving state information associated with program code |
US8484693B2 (en) | 2007-04-27 | 2013-07-09 | Gregory W. Cox | Efficient policy conflict detection |
US8782182B2 (en) | 2007-05-24 | 2014-07-15 | Foundry Networks, Llc | Generating device-specific configurations |
US8209738B2 (en) | 2007-05-31 | 2012-06-26 | The Board Of Trustees Of The University Of Illinois | Analysis of distributed policy rule-sets for compliance with global policy |
US8499331B1 (en) | 2007-06-27 | 2013-07-30 | Emc Corporation | Policy based network compliance |
US7992201B2 (en) | 2007-07-26 | 2011-08-02 | International Business Machines Corporation | Dynamic network tunnel endpoint selection |
US7743274B2 (en) | 2007-09-12 | 2010-06-22 | International Business Machines Corporation | Administering correlated error logs in a computer system |
US8494977B1 (en) | 2007-09-28 | 2013-07-23 | Emc Corporation | IT policy violation views |
JP4872945B2 (ja) | 2008-02-25 | 2012-02-08 | 日本電気株式会社 | 運用管理装置、運用管理システム、情報処理方法、及び運用管理プログラム |
WO2009108943A2 (en) | 2008-02-29 | 2009-09-03 | Doyenz Incorporated | Automation for virtualized it environments |
US8839387B2 (en) | 2009-01-28 | 2014-09-16 | Headwater Partners I Llc | Roaming services network and overlay networks |
US8554883B2 (en) | 2008-08-06 | 2013-10-08 | Cisco Technology, Inc. | Apparatus and method for sharing a generic configuration across a group of network devices |
US8441941B2 (en) | 2008-10-06 | 2013-05-14 | Cisco Technology, Inc. | Automating identification and isolation of loop-free protocol network problems |
US8103480B2 (en) | 2008-10-31 | 2012-01-24 | Hewlett-Packard Development Company, L.P. | Evaluating service level agreement violations |
US8627328B2 (en) | 2008-11-14 | 2014-01-07 | Oracle International Corporation | Operation control for deploying and managing software service in a virtual environment |
US9319300B2 (en) | 2008-12-09 | 2016-04-19 | Glue Networks, Inc. | Systems and methods for determining endpoint configurations for endpoints of a virtual private network (VPN) and deploying the configurations to the endpoints |
US8479267B2 (en) | 2009-06-30 | 2013-07-02 | Sophos Limited | System and method for identifying unauthorized endpoints |
JP2011087302A (ja) | 2009-10-19 | 2011-04-28 | Ip Infusion Inc | Bgp経路監視装置、bgp経路監視方法、およびプログラム |
US8416696B2 (en) | 2010-01-04 | 2013-04-09 | Cisco Technology, Inc. | CFM for conflicting MAC address notification |
US8689307B2 (en) | 2010-03-19 | 2014-04-01 | Damaka, Inc. | System and method for providing a virtual peer-to-peer environment |
US8375117B2 (en) | 2010-04-28 | 2013-02-12 | Juniper Networks, Inc. | Using endpoint host checking to classify unmanaged devices in a network and to improve network location awareness |
US8958292B2 (en) | 2010-07-06 | 2015-02-17 | Nicira, Inc. | Network control apparatus and method with port security controls |
US20120054163A1 (en) | 2010-08-27 | 2012-03-01 | Motorola, Inc. | Policy conflict classifier |
US9389993B1 (en) | 2010-09-03 | 2016-07-12 | Cisco Technology, Inc. | System and method for whitelist management |
US8910143B2 (en) | 2010-09-20 | 2014-12-09 | General Electric Company | Conversion system and method for use in upgrading a monitoring system |
EP2437470A1 (en) | 2010-09-30 | 2012-04-04 | British Telecommunications Public Limited Company | Network element and method for deriving quality of service data from a distributed hierarchical naming system |
US9542164B1 (en) * | 2011-03-02 | 2017-01-10 | The Mathworks, Inc. | Managing an application variable using variable attributes |
US8589934B2 (en) | 2011-04-01 | 2013-11-19 | Arm Limited | Controlling priority levels of pending threads awaiting processing |
US8693344B1 (en) | 2011-09-27 | 2014-04-08 | Big Switch Network, Inc. | Systems and methods for generating packet forwarding rules based on network policy |
US9043864B2 (en) | 2011-09-30 | 2015-05-26 | Oracle International Corporation | Constraint definition for conditional policy attachments |
US20130097660A1 (en) | 2011-10-17 | 2013-04-18 | Mcafee, Inc. | System and method for whitelisting applications in a mobile network environment |
US8930756B2 (en) | 2011-12-22 | 2015-01-06 | International Business Machines Corporation | Grouping related errors in a distributed computing environment |
US9106555B2 (en) | 2012-01-25 | 2015-08-11 | Cisco Technology, Inc. | Troubleshooting routing topology based on a reference topology |
US9405553B2 (en) | 2012-01-30 | 2016-08-02 | International Business Machines Corporation | Processing element management in a streaming data system |
US20150019756A1 (en) | 2012-02-10 | 2015-01-15 | Nec Corporation | Computer system and virtual network visualization method |
US9444842B2 (en) | 2012-05-22 | 2016-09-13 | Sri International | Security mediation for dynamically programmable network |
US9571523B2 (en) | 2012-05-22 | 2017-02-14 | Sri International | Security actuator for a dynamically programmable computer network |
US9898317B2 (en) | 2012-06-06 | 2018-02-20 | Juniper Networks, Inc. | Physical path determination for virtual network packet flows |
US9571502B2 (en) | 2012-09-14 | 2017-02-14 | International Business Machines Corporation | Priority resolution for access control list policies in a networking device |
US9038151B1 (en) | 2012-09-20 | 2015-05-19 | Wiretap Ventures, LLC | Authentication for software defined networks |
US9727446B2 (en) * | 2012-12-05 | 2017-08-08 | The Mathworks, Inc. | Modifiers that customize presentation of tested values to constraints |
US9055000B1 (en) | 2012-12-17 | 2015-06-09 | Juniper Networks, Inc. | Distributed network subnet |
EP2951952B1 (en) | 2013-01-30 | 2021-06-02 | Hewlett Packard Enterprise Development LP | Controlling a topology of a network |
US9860140B2 (en) | 2013-02-05 | 2018-01-02 | Cisco Technology, Inc. | Dynamically adjusting a set of monitored network properties using distributed learning machine feedback |
US8966637B2 (en) | 2013-02-08 | 2015-02-24 | PhishMe, Inc. | Performance benchmarking for simulated phishing attacks |
US9596141B2 (en) | 2013-03-15 | 2017-03-14 | Cisco Technology, Inc. | Representing software defined networks using a programmable graph model |
US10291515B2 (en) | 2013-04-10 | 2019-05-14 | Huawei Technologies Co., Ltd. | System and method for a control plane reference model framework |
US10021027B2 (en) | 2013-04-30 | 2018-07-10 | Comcast Cable Communications, Llc | Network validation with dynamic tunneling |
US9225601B2 (en) | 2013-06-17 | 2015-12-29 | The Board Of Trustees Of The University Of Illinois | Network-wide verification of invariants |
US20140379915A1 (en) | 2013-06-19 | 2014-12-25 | Cisco Technology, Inc. | Cloud based dynamic access control list management architecture |
US9246818B2 (en) | 2013-06-24 | 2016-01-26 | Cisco Technology, Inc. | Congestion notification in leaf and spine networks |
CN104348757B (zh) | 2013-07-31 | 2018-03-16 | 华为技术有限公司 | 一种流表交互方法、交换机及系统 |
US9548965B2 (en) | 2013-08-26 | 2017-01-17 | Nicira, Inc. | Proxy methods for suppressing broadcast traffic in a network |
KR101455167B1 (ko) | 2013-09-03 | 2014-10-27 | 한국전자통신연구원 | 화이트리스트 기반의 네트워크 스위치 |
US9553845B1 (en) | 2013-09-30 | 2017-01-24 | F5 Networks, Inc. | Methods for validating and testing firewalls and devices thereof |
US9590914B2 (en) | 2013-11-05 | 2017-03-07 | Cisco Technology, Inc. | Randomized per-packet port channel load balancing |
EP3066796B1 (en) | 2013-11-05 | 2020-01-01 | Cisco Technology, Inc. | Network fabric overlay |
US9374294B1 (en) | 2013-11-05 | 2016-06-21 | Cisco Technology, Inc. | On-demand learning in overlay networks |
US9876711B2 (en) | 2013-11-05 | 2018-01-23 | Cisco Technology, Inc. | Source address translation in overlay networks |
CN103701926B (zh) | 2013-12-31 | 2017-06-16 | 小米科技有限责任公司 | 一种获取故障原因信息的方法、装置和系统 |
US9660886B1 (en) | 2014-03-07 | 2017-05-23 | Google Inc. | Scalable network route analysis |
US10476698B2 (en) | 2014-03-20 | 2019-11-12 | Avago Technologies International Sales Pte. Limited | Redundent virtual link aggregation group |
US9654361B2 (en) | 2014-05-13 | 2017-05-16 | Cisco Technology, Inc. | Dynamic collection of network metrics for predictive analytics |
US9935831B1 (en) | 2014-06-03 | 2018-04-03 | Big Switch Networks, Inc. | Systems and methods for controlling network switches using a switch modeling interface at a controller |
JP6490205B2 (ja) | 2014-06-30 | 2019-03-27 | 華為技術有限公司Huawei Technologies Co.,Ltd. | フローエントリ構成の方法、装置及びシステム |
CN104104615B (zh) | 2014-07-21 | 2017-07-07 | 华为技术有限公司 | 策略冲突解决方法以及装置 |
US9813312B2 (en) | 2014-07-21 | 2017-11-07 | Big Switch Networks, Inc. | Systems and methods for performing debugging operations on networks using a controller |
US9497215B2 (en) | 2014-07-23 | 2016-11-15 | Cisco Technology, Inc. | Stealth mitigation for simulating the success of an attack |
US10050842B2 (en) | 2014-07-23 | 2018-08-14 | Cisco Technology, Inc. | Network control and management using semantic reasoners in a network environment |
AU2015296248B2 (en) | 2014-07-30 | 2018-01-18 | Forward Networks, Inc. | Systems and methods for network management |
US20160164748A1 (en) | 2014-12-04 | 2016-06-09 | Belkin International, Inc. | Identifying and resolving network device rule conflicts and recursive operations at a network device |
US9497207B2 (en) | 2014-08-15 | 2016-11-15 | International Business Machines Corporation | Securing of software defined network controllers |
WO2016039730A1 (en) | 2014-09-09 | 2016-03-17 | Hewlett Packard Enterprise Development Lp | Auto-configuration and management of storage resources |
CN105471830A (zh) | 2014-09-10 | 2016-04-06 | 中国电信股份有限公司 | 用于消解安全策略冲突的方法、装置和系统 |
US9641249B2 (en) | 2014-09-18 | 2017-05-02 | Lenovo Enterprise Solutions (Singapore) Pte, Ltd. | Support for converged fiber channel over ethernet (FCoE) traffic on software defined networks (SDNs) |
US9787572B2 (en) | 2014-10-07 | 2017-10-10 | Cisco Technology, Inc. | Conflict avoidant traffic routing in a network environment |
EP3216177B1 (en) | 2014-11-06 | 2021-04-14 | Hewlett Packard Enterprise Development LP | Network policy graphs |
US9690644B2 (en) | 2014-11-06 | 2017-06-27 | International Business Machines Corporation | Cognitive analysis for healing an IT system |
US10116493B2 (en) | 2014-11-21 | 2018-10-30 | Cisco Technology, Inc. | Recovering from virtual port channel peer failure |
US9594640B1 (en) | 2014-11-25 | 2017-03-14 | VCE IP Holding Company LLC | Backup/recovery system and method for a computing environment |
US10425282B2 (en) | 2014-11-28 | 2019-09-24 | Hewlett Packard Enterprise Development Lp | Verifying a network configuration |
CN105721193B (zh) | 2014-12-05 | 2020-04-28 | 方正国际软件(北京)有限公司 | 一种系统信息监控的方法和设备 |
US20170346676A1 (en) | 2014-12-12 | 2017-11-30 | Nokia Solutions And Networks Oy | Alarm correlation in network function virtualization environment |
US9680875B2 (en) | 2015-01-20 | 2017-06-13 | Cisco Technology, Inc. | Security policy unification across different security products |
CN105991332A (zh) | 2015-01-27 | 2016-10-05 | 中兴通讯股份有限公司 | 告警处理方法及装置 |
WO2016130108A1 (en) | 2015-02-10 | 2016-08-18 | Hewlett Packard Enterprise Development Lp | Network policy conflict detection and resolution |
US10530697B2 (en) | 2015-02-17 | 2020-01-07 | Futurewei Technologies, Inc. | Intent based network configuration |
US10504025B2 (en) | 2015-03-13 | 2019-12-10 | Cisco Technology, Inc. | Parallel processing of data by multiple semantic reasoning engines |
US10700958B2 (en) | 2015-04-01 | 2020-06-30 | Neutrona Networks International Llc | Network management system with traffic engineering for a software defined network |
US10148496B2 (en) | 2015-05-05 | 2018-12-04 | Citrix Systems, Inc. | Systems and methods for configuring a device via a software-defined networking controller |
US10601642B2 (en) | 2015-05-28 | 2020-03-24 | Cisco Technology, Inc. | Virtual network health checker |
US9929949B2 (en) | 2015-06-29 | 2018-03-27 | Google Llc | Systems and methods for inferring network topology and path metrics in wide area networks |
US20170026292A1 (en) | 2015-07-20 | 2017-01-26 | Schweitzer Engineering Laboratories, Inc. | Communication link failure detection in a software defined network |
US10263847B2 (en) | 2015-07-31 | 2019-04-16 | Vmware, Inc. | Policy validation |
US10243778B2 (en) | 2015-08-11 | 2019-03-26 | Telefonaktiebolaget L M Ericsson (Publ) | Method and system for debugging in a software-defined networking (SDN) system |
US10187321B2 (en) | 2015-08-19 | 2019-01-22 | Cisco Technology, Inc. | Dynamic VPN policy model with encryption and traffic engineering resolution |
CN106488487A (zh) | 2015-08-27 | 2017-03-08 | 中兴通讯股份有限公司 | 故障检测方法及装置 |
EP3272073A4 (en) | 2015-08-31 | 2018-11-14 | Hewlett-Packard Enterprise Development LP | Control channel usage monitoring in a software-defined network |
US10148489B2 (en) | 2015-09-01 | 2018-12-04 | At&T Intellectual Property I, L.P. | Service impact event analyzer for cloud SDN service assurance |
US9929924B2 (en) | 2015-09-25 | 2018-03-27 | Telefonaktiebolaget Lm Ericsson (Publ) | SDN controller logic-inference network troubleshooter (SDN-LINT) tool |
US11303513B2 (en) | 2015-09-28 | 2022-04-12 | Evenroute, Llc | Automatic QoS optimization in network equipment |
US9882833B2 (en) | 2015-09-28 | 2018-01-30 | Centurylink Intellectual Property Llc | Intent-based services orchestration |
US10291654B2 (en) | 2015-09-30 | 2019-05-14 | Symantec Corporation | Automated construction of network whitelists using host-based security controls |
CN106603264A (zh) | 2015-10-20 | 2017-04-26 | 阿里巴巴集团控股有限公司 | 一种定位故障根源的方法和设备 |
US10643149B2 (en) | 2015-10-22 | 2020-05-05 | Oracle International Corporation | Whitelist construction |
US10419530B2 (en) | 2015-11-02 | 2019-09-17 | Telefonaktiebolaget Lm Ericsson (Publ) | System and methods for intelligent service function placement and autoscale based on machine learning |
US20170126727A1 (en) | 2015-11-03 | 2017-05-04 | Juniper Networks, Inc. | Integrated security system having threat visualization |
US10069646B2 (en) | 2015-12-02 | 2018-09-04 | Nicira, Inc. | Distribution of tunnel endpoint mapping information |
WO2017105452A1 (en) | 2015-12-17 | 2017-06-22 | Hewlett Packard Enterprise Development Lp | Reduced orthogonal network policy set selection |
US10979311B2 (en) | 2016-01-05 | 2021-04-13 | Schneider Electric USA, Inc. | System and method for validating network configuration changes in a client environment |
US10261858B2 (en) | 2016-01-20 | 2019-04-16 | Intel Corporation | TCAM soft-error detection method and apparatus |
CN105721297B (zh) | 2016-01-28 | 2019-04-09 | 北京国电通网络技术有限公司 | 基于sdn网络中路由环路的检测方法及系统 |
CN106130766B (zh) | 2016-09-23 | 2020-04-07 | 深圳灵动智网科技有限公司 | 一种基于sdn技术实现自动化网络故障分析的系统和方法 |
US20170187577A1 (en) | 2017-03-14 | 2017-06-29 | Nuviso Networks Inc | System for configuring network devices |
-
2017
- 2017-07-28 US US15/663,587 patent/US10432467B2/en active Active
-
2018
- 2018-06-18 EP EP18740691.3A patent/EP3643011B1/en active Active
- 2018-06-18 CN CN201880040486.8A patent/CN110754065B/zh active Active
- 2018-06-18 WO PCT/US2018/038030 patent/WO2018236726A1/en unknown
-
2019
- 2019-09-19 US US16/575,723 patent/US10862752B2/en active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050154735A1 (en) * | 2003-12-19 | 2005-07-14 | International Business Machines Corporation | Resource management |
KR20090104382A (ko) * | 2008-03-31 | 2009-10-06 | 주식회사 케이티 | 모니터링 시스템, 모니터링 장치 및 방법 |
US20160112246A1 (en) * | 2014-10-17 | 2016-04-21 | International Business Machines Corporation | Identifying configuration inconsistency in edge-based software defined networks (sdn) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN118509250A (zh) * | 2024-07-12 | 2024-08-16 | 武汉明合永安科技有限公司 | 基于抗毁性测试技术的网络安全漏洞检测方法及系统 |
CN118509250B (zh) * | 2024-07-12 | 2024-10-01 | 武汉明合永安科技有限公司 | 基于抗毁性测试技术的网络安全漏洞检测方法及系统 |
Also Published As
Publication number | Publication date |
---|---|
US10432467B2 (en) | 2019-10-01 |
CN110754065B (zh) | 2022-11-01 |
US20180367401A1 (en) | 2018-12-20 |
US10862752B2 (en) | 2020-12-08 |
WO2018236726A1 (en) | 2018-12-27 |
EP3643011A1 (en) | 2020-04-29 |
US20200014597A1 (en) | 2020-01-09 |
EP3643011B1 (en) | 2023-03-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN110754064B (zh) | 网络结构中的路由信息的验证 | |
CN110521170B (zh) | 网络的静态网络策略分析 | |
CN110785964B (zh) | 网络中第3层桥接域子网的验证 | |
CN110754065B (zh) | 网络的逻辑级和硬件级之间的网络验证 | |
US10972352B2 (en) | Validation of routing information base-forwarding information base equivalence in a network | |
CN110710159B (zh) | 用于网络配置和故障排除的方法、系统、设备和介质 | |
US10673702B2 (en) | Validation of layer 3 using virtual routing forwarding containers in a network | |
US10536337B2 (en) | Validation of layer 2 interface and VLAN in a networked environment | |
CN111034123B (zh) | 用于执行网络保证检查的系统、方法及计算机可读介质 | |
CN110785963B (zh) | 从网络收集网络模型和节点信息 | |
US11303520B2 (en) | Validation of cross logical groups in a network | |
CN110741602B (zh) | 响应于网络意图形式对等性失败的事件生成 | |
US11153167B2 (en) | Validation of L3OUT configuration for communications outside a network | |
US10812336B2 (en) | Validation of bridge domain-L3out association for communication outside a network | |
US20230171157A1 (en) | Detection of overlapping subnets in a network | |
CN110800259B (zh) | 跨以应用为中心的维度的分布式故障代码聚合 | |
US10528444B2 (en) | Event generation in response to validation between logical level and hardware level | |
US11343150B2 (en) | Validation of learned routes in a network |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |