CN110521170B - Static network policy analysis of a network - Google Patents

Abstract

Systems, methods, and computer-readable media for static network policy analysis of a network. In one example, a system obtains a logical model based on network configuration data stored in a controller on a software defined network, the logical model including a declarative representation of respective configurations of objects in the software defined network, the objects including at least one of: one or more endpoint groups, bridged domains, contexts, or tenants. The system defines rules representing respective conditions of the objects according to specifications corresponding to the software defined network and determines whether a respective configuration of each object in the logical model violates one or more rules associated with the object. When a respective configuration of an object in the logical model violates one or more rules, the system detects an error in the respective configuration associated with the object.

Description

Static network policy analysis of a network

Cross reference to related applications

This application claims the benefit and priority of U.S. provisional patent application No.62/487,935 entitled "STATIC NETWORK POLICY FOR NETWORK" filed on 20.4.2017 and U.S. non-provisional patent application No.15/663,598 entitled "STATIC NETWORK POLICY FOR NETWORK" filed on 28.7.2017, both of which are expressly incorporated herein by reference in their entirety.

Technical Field

The present technology relates to network configuration and troubleshooting, and more particularly to static network policy analysis of a network.

Background

The network configuration of a large data center network is typically specified at a centralized controller. The controller may implement the intent in the network by programming switches and routers in the data center according to a specified network configuration. The network configuration itself is very complex and involves low-level and high-level configurations of several layers of the network (e.g., access policies, forwarding policies, routing policies, security policies, QoS policies, etc.). In view of these complexities, the network configuration process is prone to errors.

Drawings

In order to describe the manner in which the above-recited and other advantages and features of the disclosure can be obtained, a more particular description of the principles briefly described above will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings. Understanding that these drawings depict only exemplary embodiments of the disclosure and are not therefore to be considered to be limiting of its scope, the principles herein are described and explained with additional specificity and detail through the use of the accompanying drawings in which:

FIGS. 1A and 1B illustrate example network environments;

FIG. 2A illustrates an example object model of a network;

FIG. 2B illustrates an example object model of a tenant object in the example object model of FIG. 2A;

FIG. 2C illustrates an example association of objects in the example object model of FIG. 2A;

FIG. 2D illustrates a schematic diagram of an example model for implementing the example object model of FIG. 2A;

FIG. 2E shows an equivalent diagram of a different model;

FIG. 3A illustrates an example network assurance device;

FIG. 3B illustrates an example system for network guarantees;

FIG. 3C illustrates a schematic diagram of an example static policy analyzer;

FIGS. 4A and 4B illustrate an example method for network guarantees and policy analysis;

FIG. 5 illustrates example pseudo code for policy analysis;

FIG. 6 illustrates an example network device in accordance with various embodiments; and

fig. 7 illustrates an example computing device in accordance with various embodiments.

Detailed Description

Various embodiments of the present disclosure are discussed in detail below. While specific implementations are discussed, it should be understood that this is done for illustrative purposes only. A person skilled in the relevant art will recognize that other components and configurations may be used without parting from the spirit and scope of the disclosure. The following description and drawings are, accordingly, to be regarded in an illustrative sense and are not to be construed as limiting. Numerous specific details are described to provide a thorough understanding of the present disclosure. However, in certain instances, well-known or conventional details are not described in order to avoid obscuring the description. A reference to an embodiment or embodiments in the present disclosure may be a reference to the same embodiment or any embodiment; and, such reference means at least one of the embodiments.

Reference to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the disclosure. The appearances of the phrase "in one embodiment" in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. In addition, various features are described which may be exhibited by some embodiments and not by others.

The terms used in this specification generally have their ordinary meaning in the art, both in the context of this disclosure and in the particular context in which each term is used. Alternative languages and synonyms may be used for any one or more of the terms discussed herein, and it should not be particularly important whether a term is detailed or discussed herein. In some cases, synonyms for certain terms are provided. Recitation of one or more synonyms does not exclude the use of other synonyms. The use of examples anywhere in this specification, including examples of any terms discussed herein, is illustrative only and is not intended to further limit the scope and meaning of the disclosure or any example terms. As such, the present disclosure is not limited to the various embodiments presented in this specification.

Without intending to limit the scope of the disclosure, examples of tools, devices, methods, and their related results according to embodiments of the disclosure are given below. Note that titles or subtitles may be used in the examples for convenience of a reader, which in no way should limit the scope of the disclosure. Unless defined otherwise, technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. In case of conflict, the present document, including definitions, will control.

Additional features and advantages of the disclosure will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by practice of the principles disclosed herein. The features and advantages of the disclosure may be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. These and other features of the present disclosure will become more fully apparent from the following description and appended claims, or may be learned by the practice of the principles set forth herein.

SUMMARY

Aspects of the invention are set out in the independent claims, and preferred features are set out in the dependent claims. Features of one aspect may be applied to each aspect individually or in combination with other aspects.

The approach set forth herein allows for accurate, efficient, and improved network configuration error detection. The parsing of the network configuration may be performed by: the slave or manager polls the network configuration and checks the network configuration based on rules governing the correctness of the configuration.

Systems, methods, and computer-readable media for static network policy analysis of a network are disclosed herein. In some examples, a method may involve building a logic model based on network configuration data stored in a controller on a Software Defined Network (SDN). The logical model may include declarative representations of respective configurations of objects in the SDN network, such as endpoint groups, bridged domains, contexts, tenants, and so forth. The logical model may include representing objects in the configuration tree as well as object relationships. The corresponding configuration of the object may include endpoint group configuration, context configuration, bridged domain configuration, subnet configuration, security policy, and the like. The security policy may include contracts, filters, entries, and the like.

The method may further involve: the method may include defining rules representing respective conditions of the objects according to a specification corresponding to the SDN (e.g., an ACI specification), and determining whether a respective configuration of each object in the logical model violates one or more rules associated with the object. When a respective configuration of an object in the logical model violates one or more rules, the method may involve detecting an error in the respective configuration associated with the object. The method may also generate an alert or notification when an error is detected and/or take corrective action by modifying one or more network configurations.

Description of the preferred embodiment

The disclosed technology addresses the need in the art for accurate and efficient network policy analysis. The present technology relates to systems, methods, and computer-readable media for static network policy analysis of a network. The present technology will be described below in the following disclosure. The present discussion begins with an introductory discussion of static network policy analysis. Following is an introductory discussion of network guarantees and a description of an example computing environment, as shown in FIGS. 1A and 1B. Following is a discussion of additional descriptions of network assurance and policy analysis systems and concepts, as shown in fig. 2 through 5. The discussion concludes with a description of an example network device (as shown in fig. 6) and an example computing environment (as shown in fig. 7), including example hardware components suitable for hosting software applications and performing computing operations.

The present disclosure will now turn to an introductory discussion of network policy analysis and network guarantees.

In a Software Defined Network (SDN), such as an ACI (application-centric infrastructure) network, the network configuration may be stored in a controller, e.g., an APIC (application policy infrastructure controller). Such a network configuration may be stored as (or used to generate) a logical model (hereinafter referred to as "L _ model"). The L _ model may be a declarative representation of the network configuration. The logical model describes user intent in terms of tenants, endpoint groups (EPGs), bridging domains (L2), contexts (L3), and the like. The security policy may be described using a contract. Tenants refer to data center residents that need network infrastructure access and share data centers. The EPG refers to a group of terminal hosts sharing the same security policy. The bridging domain refers to the L2 boundary of the tenant. Context refers to the L3 boundary of the tenant.

A system for policy analysis may poll an L _ model of an SDN (e.g., ACI) network and perform static analysis on rules to detect errors in configuration. The L _ model may be stored or maintained at a controller on the SDN network. An SDN network may be provisioned with leaf nodes, spine nodes, controllers, and management connections to the SDN controller to perform static policy analysis.

Policy analysis can look extensively at various aspects of the L _ model, such as endpoint group (EPG) configuration; context, bridge domain/subnet configuration; security policies (e.g., contracts, filters, entries, etc.), and the like.

Policy analysis may perform multiple checks on the L _ model across the various categories or aspects described above. The input to the policy analysis may be the L _ model. The output may be a list of configuration violations grouped by, for example, a tenant.

In a controller (e.g., APIC), the L _ model represents the configuration of the EPG, the bridged domain, the context and contract and their relationships that are the objects of the configuration tree. For example, the EPG configuration is represented as a configuration tree that specifies the tenant to which the EPG belongs, the application profile, and the EPG attributes. The EPG attributes include the bridged domain of which the EPG is a part and the security policies to which the EPG complies. Each of these objects is strongly typed and has specific attributes defined for SDN.

The rules then represent specific conditions of an object or a set of objects that are valid according to the SDN specification. Rules are typically specified to ensure proper network connectivity for the end hosts. The rules also ensure that the end-hosts are secure and comply with the contract specified in the controller.

Examples of policy analysis are described further below.

Rule definition: the validity rules may be that each EPG should be part of at least one contract. This will ensure that the host that is part of the EPG can talk to other hosts according to the contract.

And (3) strategy analysis: to check if the rules are satisfied, the L _ model is parsed for all objects of EPG type. The attributes of the EPG are then checked to see if they are indeed part of at least one contract. Configuration violations are generated for all EPGs that do not match a rule or condition.

The rules are implemented as callbacks that act on objects of a given type. A given object type may have multiple rules. Trendlines are drawn and the configuration error percentage is calculated as the ratio of the total failure checks to the total checks performed for each tenant.

Flat rule: the L _ model may include, for example, contracts, bodies, filters, EPG attributes, and other entries and rules that define the behavior and relationships of objects in the network. The information in the L _ model can be used to generate a list of rules, which is referred to as flat rules. Flat rules may contain, for example, range IDs, source PC tags, destination PC tags, packet header fields, actions (e.g., allow, log, deny, etc.) that apply to packets that match the rule. Information from other models (e.g., hardware models or concrete models) may also be used to create flat rules. The flat rules from the various models may then be compared and used to determine if any conflicts exist for performing network guarantees and/or troubleshooting. Thus, policy analysis may detect network configuration errors in the intended specification in the controller, as well as stale or unused configurations in the network configuration, etc., and may be implemented to maintain the configuration up to date.

A non-limiting example of a flat rule may be as follows.

Assume that a tenant (tenant a) has two contexts: ctxl and Ctx 2. Each context has a BD (bridge domain), such as BD1 in Ctxtl and BD2 in Ctx 2. Each BD has an EPG, such as EPG1, EPG2 under BD1, BD 2. Assume that there is a contract Ctrctl between Ctxtl and Ctxt 2. Assume that a network administrator creates a contract between two application EPGs that allows traffic on TCP port 80. The security policy compliance analysis retrieves the hardware model from each switch and ensures that traffic on TCP port 80 between the two application EPGs is indeed allowed. Assume that one of the switches has a high priority stale or misconfigured entry (e.g., TCAM entry) in the hardware model that drops all traffic between the same pair of EPGs. In this case, security policy compliance analysis will raise an event. The event will contain all information about the security policy violation, such as the contract, the EPG, and the switch ID.

To perform network guarantees based on the above contracts, flat rules may be created to identify problems. For example, the contract described in this example may generate two flat rules, one for each directional flow. Two flat rules may be:

rule 1:

scope＝0xl23sg_label＝0x34src_pc_tag＝0xll41dst_pc_tag＝0x1215action＝0xl log＝0x0dport＝0x50。

rule 2:

scope＝0xl23sg_label＝0x34src_pc_tag＝0xl215dst_pc_tag＝0xll41action＝0xl log＝0x0dport＝0x50。

the action of 0x1 corresponds to an allowance. The flat rule is the same except that the source and destination PC label values are swapped to the switch direction. Flat rules may be generated in a switch where endpoints from one or both application EPGs are deployed.

Network guarantees

As previously described, the techniques herein may provide network guarantees. Network guarantees are things that guarantee or determine that the network is doing its intent. The intent may include various network operations such as bridging, routing, security, service chaining, endpoint, compliance, QoS, auditing, etc. The intent is typically embodied in one or more policies, settings, configurations, etc., defined for the network. However, in general, configurations, policies, etc. defined by network operators cannot be accurately reflected in the actual behavior of the network. For example, a network operator specifies policy a for one or more types of traffic, but later discovers that the network is actually applying policy B to that traffic. This may be the result of many different reasons, such as a hardware error, a software error, a different priority, a configuration conflict, a misconfiguration of one or more settings, an improper rule presentation of a network device, an unexpected error or event, a software upgrade, a configuration change, a failure, and so forth.

The methods herein may provide policy analysis and network guarantees by modeling the network. The network may include a private network, such as a Local Area Network (LAN); an enterprise network; standalone or legacy networks, e.g., networks with one or more branches running directory services (e.g., active directory, open directory, LDAP, etc.) such as for policy, configuration, and authentication; a data center network; networks including physical or underlying and logical or overlying layers, such as VxLAN; software defined networks, such as Application Centric Infrastructure (ACI) or VMware NSX networks; and so on. The model may be a mathematical model of the network including, but not limited to, policies, configurations, requirements, security, routing, topology, applications, hardware, filters, contracts, access control lists, etc. of the network. The model may be implemented to provide network guarantees to ensure that the behavior of the network will be consistent (or currently consistent) with the expected behavior reflected by the particular policies, settings, definitions, etc. implemented by the network operator. Unlike traditional network monitoring, which involves sending and analyzing data packets and observing network behavior, network guarantees can be performed through modeling without the need to ingest any packet data or monitor traffic or network behavior. This can lead to precedent, insight and posteriori insights: problems can be prevented before they occur, identified when they occur, and repaired immediately after they occur.

Network guarantees may involve mathematical modeling of the properties of the network to deterministically predict the behavior of the network. If the model indicates appropriate behavior, it may be determined that the network is healthy, and a detailed analysis of the model may allow problems to be identified with great accuracy. The mathematical model may abstract the control, management, and data planes and may use various techniques such as notation, formal verification, consistency, graphics, behavior, and the like.

The model may use multiple types of objects and configuration settings that model a large number of behavioral aspects of the network. Such configuration settings may affect various aspects of the network, such as underlying services, overlay services, tenant connectivity, tenant security, tenant EP mobility, tenant policies, resources, and so forth.

The present disclosure now turns to fig. 1A, which illustrates a diagram of an example network environment 100, such as a data center. Network environment 100 may include a fabric 120 that may represent a physical layer or infrastructure (e.g., the bottom layer) of network environment 100. The fabric 120 may include spine nodes (spine)102 (e.g., spine routers or switches) and leaf nodes (leaf)104 (e.g., leaf routers or switches) that may be interconnected to route or switch traffic in the fabric 120. Spine nodes 102 may interconnect leaf nodes 104 in fabric 120, and leaf nodes 104 may connect fabric 120 to an overlay or logical portion of network environment 100, which may include application services, servers, virtual machines, containers, endpoints, and the like. Thus, network connectivity in the fabric 120 may flow from the spine node 102 to the leaf nodes 104 and vice versa. The interconnections between leaf nodes 104 and spine nodes 102 may be redundant (e.g., multiple interconnections) to avoid routing failures. In some embodiments, leaf nodes 104 and spine nodes 102 may be fully connected such that any given leaf node is connected to each spine node 102 and any given spine node is connected to each leaf node 104. Leaf nodes 104 may be, for example, top-of-rack ("ToR") switches, aggregation switches, gateways, ingress and/or egress switches, provider edge devices, and/or any other type of routing or switching device.

The leaf node 104 may be responsible for routing and/or bridging tenant or customer packets and applying network policies or rules. The network policies and rules may be driven by one or more controllers 116 and/or implemented or enforced by one or more devices, such as leaf nodes 104. Leaf node 104 may connect other elements to fabric 120. For example, the leaf nodes 104 may connect servers 106, hypervisors 108, Virtual Machines (VMs) 110, applications 112, network devices 114, and the like, with the fabric 120. These elements may reside in one or more logical or virtual layers or networks, such as an overlay network. In some cases, leaf node 104 may encapsulate and decapsulate packets to and from these elements (e.g., server 106) to enable communication throughout network environment 100 and fabric 120. Leaf node 104 may also provide access to fabric 120 to any other device, service, tenant, or workload. In some cases, a server 106 connected to a leaf node 104 may similarly encapsulate and decapsulate packets to and from the leaf node 104. For example, the server 106 may include one or more virtual switches or routers or tunnel endpoints for tunneling packets between an overlay or logical layer hosted by the server 106 or connected to the server 106 and a bottom layer represented by the fabric 120 and accessed through the leaf nodes 104.

The applications 112 may include software applications, services, containers, devices, functions, service chains, and the like. For example, the applications 112 may include firewalls, databases, CDN servers, IDS/IPSs, deep packet inspection services, message routers, virtual translators, and the like. Applications from application 112 may be distributed, linked, or hosted by multiple endpoints (e.g., server 106, VM 110, etc.), or may run or execute entirely from a single endpoint.

VM 110 may be a virtual machine hosted by hypervisor 108 or a virtual machine manager running on server 106. VM 110 may include a workload running on a guest operating system on a corresponding server. Hypervisor 108 may provide a software, firmware, and/or hardware layer to create, manage, and/or run VMs 110. The hypervisor 108 may allow the VMs 110 to share hardware resources on the server 106 and allow the hardware resources on the server 106 to appear as multiple independent hardware platforms. Further, hypervisor 108 on server 106 may host one or more VMs 110.

In some cases, the VM 110 and/or the hypervisor 108 may migrate to other servers 106. Server 106 may similarly migrate to other locations in network environment 100. For example, a server connected to a particular leaf node may change to connect to a different or additional leaf node. Such configuration or deployment changes may involve modifications to settings, configurations, and policies applied to the resources being migrated as well as other network components.

In some cases, one or more servers 106, hypervisors 108, and/or VMs 110 may represent or reside in a tenant or customer space. The tenant space may include workloads, services, applications, devices, networks, and/or resources associated with one or more clients or subscribers. Thus, traffic in network environment 100 may be routed based on particular tenant policies, spaces, protocols, configurations, and the like. Further, addressing may vary between one or more tenants. In some configurations, the tenant space may be divided into logical segments and/or networks and separated from logical segments and/or networks associated with other tenants. Addressing, policy, security, and configuration information between tenants may be managed by the controller 116, the server 106, the leaf nodes 104, and so on.

The configuration in network environment 100 may be implemented at a logical level, a hardware level (e.g., a physical level), and/or both. For example, configuration may be implemented at a logical and/or hardware level based on endpoint or resource attributes (e.g., endpoint type and/or application group or profile) through a Software Defined Network (SDN) framework (e.g., Application Centric Infrastructure (ACI) or VMWARE NSX). To illustrate, one or more administrators may define configurations at a logical level (e.g., an application or software level) through controller 116, and controller 116 may implement or propagate such configurations through network environment 100. In some examples, the controller 116 may be an Application Policy Infrastructure Controller (APIC) in an ACI framework. In other examples, controller 116 may be one or more management components associated with other SDN solutions, such as an NSX manager.

Such configurations may define rules, policies, priorities, protocols, attributes, objects, etc. for routing and/or classifying traffic in network environment 100. For example, such configurations may define attributes and objects for classifying and processing traffic based on endpoint groups (EPGs), Security Groups (SGs), VM types, Bridged Domains (BDs), virtual routing and forwarding instances (VRFs), tenants, priorities, firewall rules, and the like. Other example network objects and configurations are described further below. Traffic policies and rules may be implemented based on tags, attributes, or other characteristics of the traffic, such as a protocol associated with the traffic, an EPG associated with the traffic, an SG associated with the traffic, network address information associated with the traffic, and so forth. Such policies and rules may be enforced by one or more elements (e.g., leaf nodes 104, servers 106, hypervisors 108, controllers 116, etc.) in the network environment 100. As previously described, network environment 100 may be configured according to one or more specific Software Defined Network (SDN) solutions (e.g., CISCO ACI or vmwave NSX). These example SDN solutions are briefly described below.

ACI may provide an application-centric or policy-based solution through a scalable distributed implementation. ACI supports integrating physical and virtual environments under a declarative configuration model for networks, servers, services, security, requirements, etc. For example, the ACI framework implements an EPG, which may include a collection of endpoints or applications that share common configuration requirements (e.g., security, QoS, services, etc.). The endpoints may be virtual/logical or physical devices, such as VMs, containers, hosts, or physical servers connected to the network environment 100. An endpoint may have one or more attributes, such as a VM name, a guest OS name, a security label, an application profile, and the like. The application configuration may be applied between EPGs in the form of contracts, rather than directly between endpoints. Leaf node 104 may classify incoming traffic into different EPGs. The classification can be based on, for example, a network segment identifier, e.g., a VLAN ID, a VXLAN Network Identifier (VNID), an NVGRE Virtual Subnet Identifier (VSID), a MAC address, an IP address, and the like.

In some cases, classification in the ACI infrastructure may be implemented by an Application Virtual Switch (AVS), which may run on a host such as a server or switch. For example, the AVS may classify traffic based on specified attributes and tag packets of different attribute EPGs with different identifiers, e.g., network segment identifiers (e.g., VLAN IDs). Finally, the leaf node 104 may bind the packet with its property EPG based on its identifier and enforcement policy, which may be implemented and/or managed by one or more controllers 116. The leaf node 104 may classify to which EPG the traffic from the host belongs and enforce the policy accordingly.

Another example SDN solution is based on VMWARE NSX. Using vmwansx, the host may run a Distributed Firewall (DFW), which may classify and process traffic. Consider the case where three types of VMs (i.e., application, database, and web VM) are placed into a single layer 2 network segment. Traffic protection may be provided within a network segment based on VM type. For example, HTTP traffic may be allowed between the web VMs and not allowed between the web VMs and the application or database VM. To classify traffic and implement policies, vmforensx may implement a security group that may be used to group particular VMs (e.g., web VMs, application VMs, database VMs). DFW rules can be configured to implement policies for particular security groups. To illustrate, in the context of the foregoing example, DFW rules may be configured to prevent HTTP traffic between the web, applications, and database security groups.

Returning now to FIG. 1A, network environment 100 may deploy different hosts, such as VMWARE ESXi hosts, WINDOWS HYPER-V hosts, bare metal physical hosts, etc., through leaf node 104, server 106, hypervisor 108, VM 110, application 112, and controller 116. Network environment 100 may interoperate with various hypervisors 108, servers 106 (e.g., physical and/or virtual servers), SDN orchestration platforms, and the like. Network environment 100 may implement a declarative model to allow its integration with application design and overall network policies.

The controller 116 may provide centralized access to structural information of a Software Defined Network (SDN) infrastructure, application configuration, resource configuration, application level configuration modeling, integration with a management system or server, and the like. Controller 116 may form a control plane that interfaces with the application plane through the northbound API and interfaces with the data plane through the southbound API.

As previously described, the controller 116 may define and manage application-level model(s) for the configuration in the network environment 100. In some cases, the application or device configuration may also be managed and/or defined by other components in the network. For example, a hypervisor or virtual device (e.g., a VM or a container) may run a server or management tool to manage software and services in the network environment 100, including configuration and settings of the virtual device.

As indicated above, network environment 100 may include one or more different types of SDN solutions, hosts, and the like. For purposes of clarity and explanation, various examples in this disclosure will be described with reference to the ACI framework, and the controller 116 may be interchangeably referred to as a controller, an APIC, or an APIC controller. It should be noted, however, that the techniques and concepts herein are not limited to ACI solutions and may be implemented in other architectures and scenarios, including other SDN solutions and other types of networks that may not deploy SDN solutions.

Further, as referenced herein, the term "host" may refer to a server 106 (e.g., physical or logical), a hypervisor 108, a VM 110, a container (e.g., an application 112), etc., and may run or include any type of server or application solution. Non-limiting examples of "hosts" may include virtual switches or routers, such as Distributed Virtual Switches (DVS), Application Virtual Switches (AVS), Vector Packet Processing (VPP) switches; VCENTER and NSX managers; a bare metal physical host; a HYPER-V host; VM; a DOCKER container; and so on.

FIG. 1B illustrates another example of a network environment 100. In this example, the network environment 100 includes endpoints 122 connected to leaf nodes 104 in a fabric 120. Endpoints 122 may be physical and/or logical or virtual entities such as servers, clients, VMs, hypervisors, software containers, applications, resources, network devices, workloads, etc. For example, endpoint 122 may be an object that represents: a physical device (e.g., a server, a client, a switch, etc.), an application (e.g., a web application, a database application, etc.), a logical or virtual resource (e.g., a virtual switch, a virtual service device, a Virtualized Network Function (VNF), a VM, a service chain, etc.), a container running a software resource (e.g., an application, a device, a VNF, a service chain, etc.), a storage device, a workload or workload engine, etc. An endpoint 122 may have an address (e.g., identity), a location (e.g., host, network segment, Virtual Routing and Forwarding (VRF) instance, domain, etc.), one or more attributes (e.g., name, type, version, patch level, OS name, OS type, etc.), a label (e.g., security label), a profile, and so forth.

Endpoints 122 may be associated with respective logical groups 118. Logical group 118 may be a logical entity containing endpoints (physical and/or logical or virtual) grouped together according to: one or more attributes (e.g., endpoint type (e.g., VM type, workload type, application type, etc.)), one or more requirements (e.g., policy requirements, security requirements, QoS requirements, customer requirements, resource requirements, etc.), resource names (e.g., VM name, application name, etc.), profiles, platform or Operating System (OS) characteristics (e.g., OS type or name including guest and/or host OS, etc.), associated network or tenant, one or more policies, tags, and the like. For example, a logical group may be an object that represents a set of endpoints that are grouped together. To illustrate, logical group 1 may comprise a client endpoint, logical group 2 may comprise a web server endpoint, logical group 3 may comprise an application server endpoint, logical group N may comprise a database server endpoint, and so on. In some examples, logical group 118 is an EPG in an ACI environment and/or other logical groups (e.g., SGs) in another SDN environment.

Traffic to endpoint 122 and/or from endpoint 122 may be classified, processed, managed, etc. based on logical groups 118. For example, logical groups 118 may be used to classify traffic to or from endpoints 122, apply policies to traffic to or from endpoints 122, define relationships between endpoints 122, define roles of endpoints 122 (e.g., whether an endpoint consumes or provides a service, etc.), apply rules to traffic to or from endpoints 122, apply filters or Access Control Lists (ACLs) to traffic to or from endpoints 122, define communication paths for traffic to or from endpoints 122, enforce requirements associated with endpoints 122, implement security and other configurations associated with endpoints 122, and so forth.

In an ACI environment, logical grouping 118 can be an EPG for defining contracts in ACI. The contract may include rules that specify what and how communications occur between EPGs. For example, the contract may define what the service is provided, what the service is consumed and what policy objects are related to the consumption relationship. The contract may include a policy defining: all relevant elements of the communication path and the communication or relationship between the endpoints or EPGs. For example, a Web EPG may provide services consumed by a client EPG, and the consumption may be subject to filters (ACLs) and service graphs including one or more services (e.g., firewall check services and server load balancing).

Figure 2A illustrates a diagram of an example management information model 200 for an SDN network (e.g., network environment 100). The following discussion of the management information model 200 refers to various terms that will also be used throughout this disclosure. Thus, for clarity, this disclosure will first provide a list of terms below, followed by a more detailed discussion of the management information model 200.

As used herein, "alias" may refer to a variable name for a given object. Thus, even if the object name cannot be changed once created, the alias may be a field that can be changed.

As used herein, the term "aliased" may refer to a rule (e.g., contract, policy, configuration, etc.) that overlaps with one or more other rules. For example, if contract 1 overlaps with contract 2, contract 1 defined in the logical model of the network can be said to alias contract 2 defined in the logical model of the network. In this example, by aliasing contract 2, contract 1 may make contract 2 redundant or inoperable. For example, if contract 1 has a higher priority than contract 2, such aliasing may make contract 2 redundant based on the overlapping and higher priority nature of contract 1.

As used herein, the term "APIC" may refer to one or more controllers (e.g., controller 116) in an ACI framework. The APIC may provide a unified automation and management point, policy programming, application deployment, health monitoring for ACI multi-tenant structures. The APIC may be implemented as a single controller, a distributed controller, or replicated, synchronized, and/or clustered controllers.

As used herein, the term "BDD" may refer to a binary decision tree. A binary decision tree may be a data structure that represents a function (e.g., a boolean function).

As used herein, the term "BD" may refer to a bridged domain. A bridging domain may be a set of logical ports that share the same flooding or broadcasting characteristics. Like virtual lans (vlans), bridged domains may span multiple devices. The bridging domain may be of L2 (layer 2) construction.

As used herein, "consumer" may refer to an endpoint, resource, and/or EPG that consumes a service.

As used herein, "context" may refer to an L3 (layer 3) address field that allows multiple instances of a routing table to exist and work simultaneously. This improves functionality by allowing network paths to be segmented without using multiple devices. Non-limiting examples of context or L3 address realms may include Virtual Routing and Forwarding (VRF) instances, private networks, and the like.

As used herein, the term "contract" may refer to a rule or configuration that specifies what communications are made in a network and how the communications are made (e.g., allowed, denied, filtered, processed, etc.). In ACI networks, a contract may specify how communication between endpoints and/or EPGs occurs. In some examples, the contract may provide rules and configurations similar to Access Control Lists (ACLs).

As used herein, the term "discernible name" (DN) may refer to a unique name as follows: which describes an object, such as a MO, and locates its position in the management information model 200. In some cases, the DN may be (or be identical to) a Fully Qualified Domain Name (FQDN).

As used herein, the term "endpoint group" (EPG) may refer to a logical entity or object associated with a set or group of endpoints, as previously described with reference to fig. 1B.

As used herein, the term "filter" may refer to a parameter or configuration for allowing communication. For example, in a white list model where all communications are blocked by default, explicit permission must be given to communications to prevent such communications from being blocked. The filter may define permission(s) for one or more communications or packets. Thus, the function of the filter may be similar to an ACL or firewall rules. In some examples, the filter may be implemented in a packet (e.g., TCP/IP) header field, e.g., L3 protocol type, L4 (layer 4) port, etc., which is used, for example, to allow inbound or outbound communications between endpoints or EPGs.

As used herein, the term "L2 output" may refer to a bridge connection. A bridging connection may connect two or more segments of the same network so that they may communicate. In an ACI framework, the L2 output may be a bridged (layer 2) connection between an ACI fabric (e.g., fabric 120) and an external layer 2 network (e.g., switch).

As used herein, the term "L3 output" may refer to a routing connection. Routing layer 3 connections use a set of protocols that determine the path followed by data to travel from its source to its destination across the network. The routing connection may perform forwarding (e.g., IP forwarding) according to a selected protocol (e.g., BGP (border gateway protocol), OSPF (open shortest path first), EIGRP (enhanced interior gateway routing protocol), etc.).

As used herein, the term "management object" (MO) may refer to an abstract representation of an object managed in a network (e.g., network environment 100). The object may be a specific object (e.g., switch, server, adapter, etc.) or a logical object (e.g., application profile, EPG, failure, etc.). A MO may be a network resource or element managed in a network. For example, in an ACI environment, an MO may include an abstraction of ACI structure (e.g., structure 120) resources.

As used herein, the term "management information tree" (MIT) may refer to a hierarchical management information tree that contains a MO of a system. For example, in ACI, MIT contains a MO of an ACI structure (e.g., structure 120). MIT may also be referred to as a Management Information Model (MIM), such as management information model 200.

As used herein, the term "policy" may refer to one or more specifications for controlling certain aspects of system or network behavior. For example, a policy may include a named entity that contains specifications for controlling certain aspects of system behavior. To illustrate, the layer 3 external network policy may contain a BGP protocol to enable BGP routing functions when connecting fabric 120 to an external layer 3 network.

As used herein, the term "profile" may refer to configuration details associated with a policy. For example, a profile may include a named entity that contains configuration details for implementing one or more instances of a policy. To illustrate, a switch node profile for a routing policy may contain switch-specific configuration details to implement the BGP routing protocol.

As used herein, the term "provider" refers to an object or entity that provides a service. For example, the provider may be an EPG that provides the service.

As used herein, the term "body" refers to one or more parameters used in defining a contract for a communication. For example, in ACI, a body in a contract may specify what information may be transferred and how. The body functions like an ACL.

As used herein, the term "tenant" refers to an isolated unit in a network. For example, a tenant may be a secure and exclusive virtual computing environment. In ACI, a tenant may be an isolated unit from a policy perspective, but does not necessarily represent a private network. In practice, ACI tenants may contain multiple private networks (e.g., VRFs). Tenants may represent consumers in a service provider setting, organizations or domains in an enterprise setting, or just policy groups.

As used herein, the term "VRF" refers to virtual routing and forwarding instances. The VRF may define a layer 3 address realm that allows multiple instances of the routing table to exist and work simultaneously. This improves functionality by allowing segmentation of the network path without using multiple devices. Which is also called context or private network.

Having described various terms used herein, the present disclosure now returns to a discussion of a Management Information Model (MIM)200 in fig. 2A. As previously described, the MIM200 may be a hierarchical management information tree or MIT. Further, the MIM200 may be managed and processed by the controller 116 (e.g., APIC in ACI). The controller 116 may effect control of the managed resource by presenting its manageability features as object properties that may be inherited according to the location of the object within the model's hierarchy.

The hierarchy of the MIM200 begins with a policy corpus 202 at the top (root) and contains parent and child nodes 116, 204, 206, 208, 210, 212. Nodes 116, 202, 204, 206, 208, 210, 212 in the tree represent Management Objects (MOs) or groups of objects. Each object in a structure (e.g., structure 120) has a unique, Discernable Name (DN) that describes the object and locates it in the tree. Nodes 116, 202, 204, 206, 208, 210, 212 may include various MOs, which, as described below, contain policies governing system operation.

Controller 116

The controller 116 (e.g., an APIC controller) may provide management, policy programming, application deployment, and health monitoring for the fabric 120.

Node 204

Node 204 includes a tenant container for enabling an administrator to execute policies for domain-based access control. Non-limiting examples of tenants may include:

and the administrator defines the user tenants according to the requirements of the users. They contain policies that govern the operation of resources (e.g., applications, databases, web servers, network attached storage, virtual machines, etc.).

The common tenant is provided by the system, but may be configured by an administrator. It contains policies that govern the operation of all tenants accessible resources (e.g., firewalls, load balancers, layer 4 to layer 7 services, intrusion detection devices, etc.).

Infrastructure tenants are provided by the system, but can be configured by an administrator. It contains policies that govern the operation of infrastructure resources, such as fabric overlays (e.g., VXLAN). It also enables a fabric provider to selectively deploy resources to one or more user tenants. The infrastructure tenant policy may be configured by an administrator.

The management tenant is provided by the system, but may be configured by an administrator. It contains policies that govern the operation of fabric management functions for in-band and out-of-band configuration of fabric nodes. The management tenant contains a private out-of-band address space for controller/fabric internal communications that is located outside of the fabric data path providing access through the management port of the switch. The management tenant enables discovery and automation of communications with the virtual machine controller.

Node 206

The node 206 may contain access policies that manage the operation of switch access ports that provide connectivity to resources such as storage, computing, layer 2 and layer 3 (bridging and routing) connectivity, virtual machine hypervisors, layer 4 to layer 7 devices, and the like. If a tenant requires an interface configuration other than that provided in the default link, Cisco Discovery Protocol (CDP), Link Layer Discovery Protocol (LLDP), Link Aggregation Control Protocol (LACP), or Spanning Tree Protocol (STP), an administrator may configure an access policy to enable such configuration on an access port of leaf node 104.

Node 206 may contain fabric policies that manage the operation of switch fabric ports, including functions such as Network Time Protocol (NTP) server synchronization, intermediate system-to-intermediate system protocol (IS-IS), Border Gateway Protocol (BGP) route reflectors, Domain Name System (DNS), and the like. The structure MO contains objects such as power supplies, fans, pedestals, etc.

Node 208

Node 208 may contain VM domains that group VM controllers with similar networking policy requirements. The VM controllers may share a virtual space (e.g., a VLAN or VXLAN space) and an application EPG. The controller 116 communicates with the VM controllers to publish network configurations, such as port groups, which are then applied to the virtual workload.

Node 210

Node 210 may contain a layer 4 to layer 7 service integration lifecycle automation framework that enables the system to respond dynamically when a service is online or offline. Policies may provide service equipment packages and inventory management functions.

Node 212

Node 212 may contain access, authentication and accounting (AAA) policies that manage user privileges, roles, and security domains of fabric 120.

The hierarchical policy model may be well suited to APIs, such as REST API interfaces. When called, the API may read or write objects in the MIT. The URL may map directly to a discernible name that identifies an object in the MIT. For example, the data in the MIT may be described as a self-contained structured tree text document encoded in XML or JSON.

Fig. 2B illustrates an example object model 220 for the tenant portion of the MIM 200. As previously described, a tenant is a logical container for enabling an administrator to perform application policies for domain-based access control. Thus, a tenant represents an isolated unit from a policy perspective, but it does not necessarily represent a private network. Tenants may represent consumers in a service provider setting, organizations or domains in an enterprise setting, or just convenient policy groupings. Furthermore, tenants may be isolated from each other or may share resources.

The tenant portion 204A of the MIM200 can include various entities, and the entities in the tenant portion 204A can inherit policies from parent entities. Non-limiting examples of entities in tenant portion 204A may include filters 240, contracts 236, external networks 222, bridging domains 230, VRF instances 234, and application profiles 224.

The bridging domain 230 may include a subnet 232. The contract 236 may include a body 238. The application profile 224 may contain one or more EPGs 226. Some applications may contain multiple components. For example, an e-commerce application may require web servers, database servers, data located in a storage area network, and access to external resources to effect financial transactions. The application profile 224 contains as many (or as few) EPGs as logically related to the ability to provide the application.

The EPGs 226 may be organized in various ways, such as based on the applications they provide, the functions they provide (e.g., infrastructure), their location in the structure of the data center (e.g., DMZ), or any organizational principle the structure or tenant administrator chooses to use.

The EPGs in the structure may include various types of EPGs, such as an application EPG, a layer 2 external network external instance EPG, a layer 3 external network external instance EPG, a management EPG for out-of-band or in-band access, and the like. The EPG 226 may also contain attributes 228, such as an encapsulated-based EPG, an IP-based EPG, or a MAC-based EPG.

As previously described, an EPG may contain endpoints (e.g., EP 122) that have common characteristics or attributes (e.g., common policy requirements (e.g., security, Virtual Machine Mobility (VMM), QoS, or layer 4 to layer 7 services).

Policies apply to EPGs, including the endpoints they contain. The EPG may be statically configured by an administrator in the controller 116 or dynamically configured by an automated system such as VCENTER or OPENSTACK.

To activate a tenant policy in tenant portion 204A, a fabric access policy should be configured and associated with the tenant policy. The access policy enables the administrator to configure other network configurations, for example, port channels and virtual port channels, protocols such as LLDP, CDP or LACP, and features such as monitoring or diagnostics.

Figure 2C illustrates an example association 260 of tenant entities and access entities in the MIM 200. The policy corpus 202 contains a tenant portion 204A and an access portion 206A. Thus, tenant portion 204A and access portion 206A are associated through policy corpus 202.

The access portion 206A may contain structure and infrastructure access policies. Typically, in the policy model, the EPG is coupled to the VLAN. For example, for traffic to flow through, the EPG is deployed on leaf ports with VLANs in the physical, VMM, L2 egress, L3 egress, or fibre channel domains.

Thus, access portion 206A contains domain profiles 236, which may define, for example, the physical, VMM, L2 output, L3 output, or fibre channel domain to be associated with the EPG. The domain profile 236 includes a VLAN instance profile 238 (e.g., a VLAN pool) and an attachable Access Entity Profile (AEP)240, which are directly associated with the application EPG. AEP 240 deploys the associated application EPG to the port to which it is attached and automatically performs the task of assigning VLANs. Although large data centers may be provisioned with thousands of active VMs on hundreds of VLANs, fabric 120 may automatically assign VLAN IDs from a pool of VLANs. This saves time compared to relaying (trunk down) VLANs in traditional data centers.

Fig. 2D illustrates a schematic diagram of an example model of a network (e.g., network environment 100). The model can be generated based on specific configuration and/or network state parameters associated with the various objects, policies, attributes, and elements defined in the MIM 200. The model may be implemented for network analysis and assurance, and may provide a description of the network at various stages of implementation and at various levels of the network.

As shown, the models can include L _ model 270A (logical model), LR _ model 270B (logical rendering model or logical runtime model), Li _ model 272 (logical model for i), Ci _ model 274 (concrete model for i), and/or Hi _ model 276 (hardware model or TCAM model for i).

The L _ model 270A is a logical representation of various elements in the MIM200 configured in a network (e.g., the network environment 100), such as objects, object attributes, object relationships, and other elements in the MIM200 configured in the network. The controller 116 may generate the L _ model 270A based on the configuration input in the controller 116 for the network, and thus the L _ model 270A represents the logical configuration of the network at the controller 116. This is a statement of the "end state" expression that is expected when elements of a network entity (e.g., application, tenant, etc.) are connected and the fabric 120 is provisioned by the controller 116. Because the L _ model 270A represents the configuration (including objects and relationships in the MIM 200) input in the controller 116, it can also reflect the administrator's "intent": administrators want networks and network elements to function.

The L _ model 270A may be a structure or network wide logical model. For example, the L _ model 270A may describe the configuration and objects from each controller 116. As previously described, the network environment 100 may include a plurality of controllers 116. In some cases, two or more controllers 116 may include different configurations or logical models for the network. In this case, the L _ model 270A may obtain either the configuration or logical model from the controllers 116 and generate a structure or network wide logical model based on the configuration and logical models from all the controllers 116. Thus, the L _ model 270A may incorporate configuration or logical models between the controllers 116 to provide a comprehensive logical model. The L _ model 270A may also resolve or account for any dependencies, redundancies, conflicts, etc. that may result from configuration or logic models at different controllers 116.

LR _ model 270B is an abstract model representation that controller 116 (e.g., APIC in ACI) parses from L _ model 270A. LR _ model 270B can provide a configuration component to be delivered to a physical infrastructure (e.g., fabric 120) to execute one or more policies. For example, LR _ model 270B may be delivered to leaf node 104 in fabric 120 to configure leaf node 104 for communication with attached endpoints 122. LR _ model 270B can also incorporate state information to capture the runtime state of the network (e.g., fabric 120).

In some cases, LR _ model 270B may provide a representation of L _ model 270A that is standardized according to a particular format or expression that may be propagated to the physical infrastructure of structure 120 (e.g., leaf nodes 104, spine nodes 102, etc.) and/or understood by the physical infrastructure of structure 120. For example, LR _ model 270B can associate elements in L _ model 270A with specific identifiers or tags (e.g., hardware plane identifiers used as classifiers) that can be interpreted and/or compiled by switches in fabric 120.

Li _ model 272 is a switch-level or switch-specific model obtained from L _ model 270A and/or LR _ model 270B. Li _ model 272 may cast L _ model 270A and/or LR _ model 270B on a particular switch or device i, and thus may convey how L _ model 270A and/or LR _ model 270B should appear or be implemented at a particular switch or device i.

For example, Li _ model 272 may project L _ model 270A and/or LR _ model 270B related to a particular switch i to capture a switch-level representation of L _ model 270A and/or LR _ model 270B at switch i. For purposes of illustration, Li _ model 272L ₁ May represent a projection to leaf node 1(104) or an L _ model 270A and/or LR _ model 270B implemented at leaf node 1 (104). Thus, for individual devices on the structure 120 (e.g., leaf node 104, spine node 102, etc.), the Li _ model 272 may be generated from the L _ model 270A and/or the LR _ model 270B.

In some cases, Li _ model 272 may be represented using JSON (JavaScript object notation). For example, the Li _ model 272 may include JSON objects such as rules, filters, entries, and ranges.

Ci _ model 274 is the actual in-state (in-state) configuration at an individual fabric member i (e.g., switch i). In other words, Ci _ model 274 is a switch-level or switch-specific model based on Li _ model 272. For example, the controller 116 may deliver the Li _ model 272 to leaf node 1 (104). Leaf node 1(104) may employ Li _ model 272 (which may be specific to leaf node 1(104)), and leaf node 1(104) may present policies in Li _ model 272 as a specific model Ci _ model 274 running on leaf node 1 (104). For example, leaf node 1(104) may render the Li _ model 272 by the OS on leaf node 1 (104). Thus, Ci _ model 274 may be similar to compiled software in that it is in the form of Li _ model 272 that switch OS at leaf node 1(104) may execute.

In some cases, the Li _ model 272 and the Ci _ model 274 may have the same or similar format. For example, the Li _ model 272 and the Ci _ model 274 may be based on JSON objects. Having the same or similar format may assist the objects in the Li _ model 272 and the Ci _ model 274 in comparing to determine whether they are equivalent or consistent. Such equivalence or agreement checks may be used for network analysis and assurance, as further described herein.

Hi _ model 276 is also a switch-level or switch-specific model for switch i, but is based on Ci _ model 274 for switch i. Hi _ model 276 is the actual configuration (e.g., rules) stored or presented on hardware or memory (e.g., TCAM memory) at individual fabric member i (e.g., switch i). For example, Hi _ model 276 may represent a configuration (e.g., a rule) stored or presented on hardware (e.g., TCAM memory) of leaf node 1(104) based on Ci _ model 274 at leaf node 1 (104). Switch OS at leaf node 1(104) can render or execute Ci _ model 274, and leaf node 1(104) can store or render the configuration of Ci _ model 274 from a storage device (e.g., memory or TCAM at leaf node 1 (104)). The configuration from Hi _ model 276 stored or presented by leaf node 1(104) represents the configuration that would be implemented by leaf node 1(104) when processing traffic.

Although the models 272, 274, 276 are shown as device-specific models, similar models may be generated or aggregated for a set of structure members (e.g., leaf nodes 104 and/or spine nodes 102) in the structure 120. When combined, the device-specific models (e.g., model 272, model 274, and/or model 276) may provide a representation of structure 120 beyond the specific device. For example, in some cases, Li _ models 272, Ci _ models 274, and/or Hi _ models 276 associated with some or all of the individual structure members (e.g., leaf nodes 104 and spine nodes 102) may be combined or aggregated to generate one or more aggregate models based on the individual structure members.

As referenced herein, the terms H model, T model, and TCAM model may be used interchangeably to refer to a hardware model, such as Hi _ model 276. For example, Ti model, Hi model, and TCAMi model may be used interchangeably to refer to Hi _ model 276.

The models 270A, 270B, 272, 274, 276 can provide representations of various aspects of the network or representations of various configuration stages of the MIM 200. The models 270A, 270B, 272, 274, 276 may also represent configurations of: a bottom level 278 (e.g., a bottom level topology, routes, etc.) of fabric 120, an overlay 280 of network environment 100 (e.g., COOP, MPBGP, tenant, VRF, VLAN, VXLAN, virtual application, VM, hypervisor, virtual switch, etc.), a tenant 282 in network environment 100 that includes configuration data (e.g., security, forwarding, service chain, QoS, VRF, BD, contract, filter, EPG, subnet, etc.) associated with tenant portion 204A in MIM200, resources 284 in network environment 100 (e.g., storage, computation, VM, port channel, physical element, etc.), and so forth.

In general, the L _ model 270A can be a high-level representation of the content present in the LR _ model 270B, which should be presented on a particular device as Ci _ model 274 and Hi _ model 276 representations. If there are any gaps between the models, there may be inconsistent configurations or problems.

Fig. 2E shows an equivalent diagram 290 of the different models. In this example, the L _ model 270A obtained from the controller(s) 116 in the network environment 100 may be compared to the Hi _ models 276 obtained from one or more leaf nodes 104 in the fabric 120. This comparison may provide an equivalence check to determine whether the logical configuration of network environment 100 at controller(s) 116 is consistent or conflicting with rules (e.g., rules and/or configurations in a storage device (e.g., TCAM)) presented on one or more leaf nodes 104.

For example, a network operator may define objects and configurations for network environment 100 from controller(s) 116. The controller(s) 116 may then store the definitions and configurations from the network operator and build a logical model (e.g., L _ model 270A) of the network environment 100. The controller(s) 116 may push the definitions and configurations provided by the network operator and reflected in the logical model to each node (e.g., leaf node 104) in the fabric 120. The nodes in the structure 120 may receive such information and present or compile rules on the software (e.g., operating system) of the nodes. Rules that are presented or compiled on the node software can be structured to construct a model (e.g., Ci _ model 274). The rules from the build model may then be pushed from the software of the node to the hardware of the node (e.g., a TCAM) and stored or presented as rules on the hardware of the node. The rules stored or presented on the hardware of the node may be structured as a hardware model for the node (e.g., Hi _ model 276).

As the definitions and configurations entered by the network operator are pushed through each phase, the various models (e.g., L _ model 270A and Hi _ model 276) may thus represent the rules and configurations of each phase (e.g., the intent specification at controller(s) 116, presented or compiled in software at the node, presented or stored in hardware at the node, etc.). Thus, equivalence checking of various models, such as L _ model 270A and Hi _ model 276, may be used to determine whether definitions and configurations have been pushed, rendered, and/or stored appropriately at each respective stage associated with the various models. If the model passes the equivalence check, the definition and configuration of each phase (e.g., controller(s) 116, software on the node, hardware on the node, etc.) may be verified as accurate and consistent. Conversely, if there is an error in the equivalence check, a misconfiguration may be detected at one or more particular stages. Equivalence checking between the various models may also be used to determine where (e.g., at what stage) a problem or misconfiguration occurred. For example, the stage at which a problem or misconfiguration occurs may be determined based on which model(s) fail the equivalence check.

L _ model 270A and Hi _ model 276 may store or present rules, configurations, attributes, definitions, etc. in the respective structures 292A, 292B. For example, L _ model 270A may store or present rules, configurations, objects, attributes, etc. in a data structure 292A (e.g., a file or object (e.g., JSON, XML, etc.)), and Hi _ model 276 may store or present rules, configurations, etc. in a storage device 292B (e.g., TCAM storage). The structures 292A, 292B associated with L _ model 270A and Hi _ model 276 may affect the format, organization, type, etc. of the data (e.g., rules, configurations, attributes, definitions, etc.) stored or presented.

For example, L _ model 270A can store data as objects and object attributes 2914A, e.g., EPG, contract, filter, tenant, context, BD, network-wide parameters, and the like. Hi _ model 276 may store data as values and tables 294B, e.g., value/mask pairs, range expressions, auxiliary tables, and the like.

Thus, the data in L _ model 270A and Hi _ model 276 may be normalized, regularized, graphed, modeled, reformatted, flattened, etc. to perform equivalence between L _ model 270A and Hi _ model 276. For example, the data may be transformed using a bit vector, a Boolean function, a ROBDD, or the like to perform a mathematical check of equivalence between L _ model 270A and Hi _ model 276.

FIG. 3A shows a diagram of an example assurance device 300 for network assurance. In this example, the securing apparatus 300 may include k VMs 110 operating in a cluster mode. For purposes of explanation, a VM is used in this example. However, it should be understood that other configurations are also contemplated herein, such as the use of containers, bare metal devices, endpoints 122, or any other physical or logical system. Further, while fig. 3A illustrates a cluster mode configuration, other configurations are also contemplated herein, such as a single mode configuration (e.g., a single VM, container, or server) or a service chain.

The assurance device 300 may run on one or more servers 106, VMs 110, hypervisors 108, EPs 122, leaf nodes 104, controllers 116, or any other system or resource. For example, the securing device 300 may be a logical service or application running on one or more VMs 110 in the network environment 100.

Guarantee device 300 may include a data framework 308, which may be based on, for example, APACHEAPEX and HADOOP. In some cases, the assurance checks may be written as individual operators residing in the data framework 308. This enables a local horizontal extension architecture that can extend to any number of switches in the fabric 120 (e.g., an ACI fabric).

The assurance device 300 may poll the structure 120 at a configurable period (e.g., time period). The analysis workflow may be set as a DAG (directed acyclic graph) for operators 310, where data flows from one operator to another, and ultimately results are generated and saved permanently to database 302 for each interval (e.g., each epoch).

The north layer implements API servers (e.g., APACHE Tomcat and Spring frameworks) 304 and Web servers 306. A Graphical User Interface (GUI) interacts via APIs exposed to consumers. Consumers may also use these APIs to collect data from assurance device 300 for further integration into other tools.

Operators 310 in the data framework 308 (e.g., APEX/Hadoop) may together support guaranteed operations. The operators 310 may be independent units of logical operations that may contribute to the business logic of executing use cases. The following are non-limiting examples of the assurance operations that the assurance device 300 may perform through the operators 310.

Security policy compliance

The assurance device 300 may check to confirm that the configuration or specification from the L _ model 270A, which may reflect the user's intent on the network (including, for example, contracts for security policies and customer configurations), is properly implemented and/or presented in the Li _ model 272, Ci _ model 274, and Hi _ model 276, and thus by the fabric members (e.g., leaf nodes 104), and report any errors, contract violations, or irregularities discovered.

Static policy analysis

The assurance device 300 may check for problems in the specification of one or more user intents (e.g., identifying conflicting or conflicting policies in the L _ model 270A).

TCAM utilization

TCAMs are scarce resources in structures (e.g., structure 120). However, the assurance device 300 may analyze TCAM utilization through network data (e.g., Longest Prefix Match (LPM) tables, routing tables, VLAN tables, BGP updates, etc.), contracts, logical groups 118 (e.g., EPG), tenants, spine nodes 102, leaf nodes 104, and other dimensions in the network environment 100 and/or objects in the MIM200 to provide visibility to network operators or users of utilization of the scarce resource. This is a great help for planning and other optimization purposes.

Endpoint checking

Guarantee device 300 may verify that the structure (e.g., structure 120) does not disagree in the registered endpoint information (e.g., two leaf nodes declare the same endpoint, duplicate subnets, etc.), and other such checks.

Tenant routing inspection

The assurance device 300 can verify that BD, VRF, subnet (both internal and external), VLAN, contract, filter, application, EPG, etc. are programmed correctly.

Infrastructure routing

Ensuring that device 300 can verify that infrastructure routes (e.g., IS-IS protocols) do not cause black holes, loops, oscillation (flap) convergence problems, and other problems.

MP-BGP route reflection checking

Network fabrics (e.g., fabric 120) may interface with other external networks and provide connectivity to them via one or more protocols (e.g., Border Gateway Protocol (BGP), Open Shortest Path First (OSPF), etc.). Known routes are advertised within the network fabric by, for example, MP-BGP. These checks may ensure that the service of route reflection through, for example, MP-BGP (e.g., from border leaf nodes) has no health issues.

Logical stub and real-time change analysis

The assurance device 300 may verify that the rules in the specification of the network (e.g., L _ model 270A) are complete and free of inconsistencies or other problems. MOs in MIM200 may be checked by assurance device 300 through syntax and semantic checks performed on the L _ model 270A and/or the associated configuration of MOs in MIM 200. The assurance device 300 may also verify that unnecessary, stale, unused or redundant configurations (e.g., contracts) are deleted.

Fig. 3B illustrates an architecture diagram of an example system 350 (e.g., the assurance device 300) for network assurance. In some cases, system 350 can correspond to the DAG for operator 310 discussed previously with respect to FIG. 3A.

In this example, the topology detector 312 communicates with the controller 116 (e.g., APIC controller) to discover or otherwise build a comprehensive topology view of the fabric 120 (e.g., spine node 102, leaf nodes 104, controller 116, endpoints 122, and any other components and interconnections thereof). While the various architectural components are represented in a single box, it should be understood that a given architectural component (e.g., topology detector 312) can correspond to one or more individual operators 310 and can include one or more nodes or endpoints, such as one or more servers, VMs, containers, applications, service functions (e.g., functions in a service chain or virtualized network functions), and the like.

The topology detector 312 is configured to discover nodes in the fabric 120, e.g., the controller 116, the leaf nodes 104, the spine nodes 102, and so on. The topology detector 312 can also detect majority elections performed between the controllers 116 and determine if there is a quorum between the controllers 116. If there is no quorum or majority, the topology detector 312 can trigger an event and alert the user controllers 116 of a configuration or other error that prevents the quorum or majority from being reached. Topology probe 312 may detect leaf nodes 104 and spine nodes 102 as part of fabric 120 and publish their respective out-of-band management network addresses (e.g., IP addresses) to downstream services. This may be part of a topology view published to downstream services at the end of a topology probe 312 discovery period (e.g., 5 minutes or some other specified interval).

In some examples, the topology detector 312 may receive as input a list of controllers 116 (e.g., APIC controllers) associated with a network/fabric (e.g., fabric 120). Topology detector 312 can also receive corresponding credentials to log into each controller. Topology detector 312 can retrieve information from each controller using, for example, REST calls. The topology detector 312 may obtain from each controller the list of nodes (e.g., leaf nodes 104 and spine nodes 102) and their associated attributes that the controller knows. The topology probe 312 may obtain node information from the controller 116 including, but not limited to, IP addresses, node identifiers, node names, node domains, node URIs, node dm, node roles, node versions, and the like.

The topology detector 312 can also determine whether the controllers 116 are in quorum or are sufficiently communicatively coupled therebetween. For example, if there are n controllers, then a quorum condition can be satisfied when (n/2+1) controllers know to be communicatively coupled to each other and/or to communicate. Topology detector 312 can determine quorum (or identify any failed nodes or controllers) by parsing data returned from the controllers and identifying the communication coupling between its constituent nodes. The topology detector 312 can identify the type of each node in the network, e.g., spine node, leaf node, APIC, etc., and include this information in the generated topology information (e.g., a topology map or model).

If there is no quorum, the topology detector 312 can trigger an event and alert the user that reconfiguration or appropriate attention is required. If there is a quorum, the topology probe 312 can compile the network topology information into a JSON object and pass it downstream to other operators or services, such as the unified collector 314.

The unified collector 314 may receive the topology view or model from the topology probes 312 and use the topology information to collect information for network guarantees from the fabric 120. The unified collector 314 may poll nodes (e.g., the controllers 116, the leaf nodes 104, the spine nodes 102, etc.) in the fabric 120 to collect information from the nodes.

The unified collector 314 may include one or more collectors (e.g., collector devices, operators, applications, VMs, etc.) configured to collect information from the topology detector 312 and/or nodes in the fabric 120. For example, unified collector 314 may comprise a cluster of collectors, and each collector may be assigned to a subset of nodes within topology model and/or fabric 120 in order to collect information from its assigned subset of nodes. To improve performance, unified collector 314 may operate in a parallel, multi-threaded manner.

The unified collector 314 may perform load balancing across the various collectors to improve the efficiency of the overall collection process. Load balancing may be optimized by managing the distribution of subsets of nodes to collectors, such as by randomly hashing nodes to collectors.

In some cases, the ensuring device 300 may run multiple instances of the unified collector 314. This may also allow for the guaranteed appliance 300 to distribute the tasks of collecting data for each node in the topology (e.g., the fabric 120 including the spine nodes 102, leaf nodes 104, controllers 116, etc.) through fragmentation and/or load balancing, as well as mapping the collection tasks and/or nodes to specific instances of the unified collector 314, where data collection across nodes is performed in parallel by the various instances of the unified collector 314. Within a given node, command and data collection may be performed serially. The guarantee appliance 300 may control the number of threads that each instance of the unified collector 314 uses to poll data from the fabric 120.

The unified collector 314 may collect models (e.g., L _ model 270A and/or LR _ model 270B) from the controller 116, switch software configurations and models (e.g., Ci _ model 274) from nodes in the fabric 120 (e.g., leaf nodes 104 and/or spine nodes 102), hardware configurations and models (e.g., Hi _ model 276) from nodes in the fabric 120 (e.g., leaf nodes 104 and/or spine nodes 102), and so on. The unified collector 314 may collect Ci _ models 274 and Hi _ models 276 from various nodes or fabric members (e.g., leaf nodes 104 and spine nodes 102), as well as L _ models 270A and/or LR _ models 270B from one or more controllers (e.g., controllers 116) in the network environment 100.

The unified collector 314 may poll devices discovered by the topology probes 312 to collect data from the fabric 120 (e.g., from constituent members of the fabric). The unified collector 314 can collect data using interfaces exposed by the controller 116 and/or switch software (e.g., switch OS), including, for example, a representational state transfer (REST) interface and a Secure Shell (SSH) interface.

In some cases, the unified collector 314 collects the L _ model 270A, LR _ model 270B and/or the Ci _ model 274 via REST APIs and collects hardware information (e.g., configuration, tables, fabric card information, rules, routing, etc.) via SSH using utilities provided by the switch software (e.g., a virtual shell (VSH or VSHELL) for accessing the switch Command Line Interface (CLI) or a VSH _ LC shell for accessing the runtime state of the line card).

The unified collector 314 may poll for other information from the controller 116 including, but not limited to: topology information, tenant forwarding/routing information, tenant security policies, contracts, interface policies, physical domain or VMM domain information, OOB (out-of-band) management IP of nodes in the fabric, etc.

The unified collector 314 may also poll information from nodes (e.g., leaf nodes 104 and spine nodes 102) in the fabric 120, including but not limited to: ci _ model 274 for VLAN, BD, and Security policy; link Layer Discovery Protocol (LLDP) connectivity information for nodes (e.g., leaf node 104 and/or spine node 102); endpoint information from EPM/COOP; fabric card information from spine node 102; routing Information Base (RIB) tables from nodes in fabric 120; forwarding Information Base (FIB) tables from nodes in fabric 120; security group hardware tables (e.g., TCAM tables) from nodes in fabric 120; and so on.

In some cases, the unified collector 314 may obtain runtime state from the network and incorporate runtime state information into the L _ model 270A and/or the LR _ model 270B. Unified collector 314 can also obtain multiple logical models from controller 116 and generate a comprehensive or network-wide logical model (e.g., L _ model 270A and/or LR _ model 270B) based on the logical models. The unified collector 314 may compare logical models from the controller 116, resolve dependencies, remove redundancy, etc., and generate a single L _ model 270A and/or LR _ model 270B for the entire network or fabric.

The unified collector 314 may collect the entire network state across the controller 116 and fabric nodes or members (e.g., leaf nodes 104 and/or spine nodes 102). For example, the unified collector 314 may use the REST interface and the SSH interface to collect network state. This information collected by the unified collector 314 may include data related to link layer, VLAN, BD, VRF, security policies, etc. The state information may be represented in LR _ model 270B, as previously described. The unifying collector 314 may then publish the collected information and models to any downstream operators interested in or needing such information. The unifying collector 314 may publish information as it is received, so that data is streamed to downstream operators.

The data collected by the unified collector 314 may be compressed and sent to a downstream service. In some examples, the unified collector 314 may collect data in an online manner or in real-time and send the data downstream for further analysis as the data is collected. In some examples, the unified collector 314 may collect the data in an offline manner and compile the data for later analysis or transmission.

Assurance device 300 may contact controller 116, spine node 102, leaf nodes 104, and other nodes to collect various types of data. In some scenarios, the guaranteed device 300 may experience a failure (e.g., a connection problem, a hardware or software error, etc.) that renders it unable to collect data over a period of time. Ensuring that device 300 can seamlessly handle such failures and generate events based on such failures.

The switch logic policy generator 316 may receive the L _ model 270A and/or the LR _ model 270B from the unified collector 314 and compute the Li _ model 272 for each network device i (e.g., switch i) in the fabric 120. For example, the switch logic policy generator 316 may receive the L _ model 270A and/or the LR _ model 270B and generate the Li _ model 272 by projecting a logic model for each individual node i (e.g., spine node 102 and/or leaf node 104) in the fabric 120. The switch logic policy generator 316 may generate a Li _ model 272 for each switch in the fabric 120, creating a switch logic model based on the L _ model 270A and/or the LR _ model 270B for each switch.

Each Li _ model 272 may represent an L _ model 270A and/or an LR _ model 270B projected or applied at a respective network device i (e.g., switch i) in the fabric 120. In some cases, the Li _ model 272 may be standardized or formatted in a manner that is compatible with the respective network device. For example, the Li _ model 272 may be formatted in a manner that is readable or executable by a respective network device. To illustrate, the Li _ model 272 may include a particular identifier (e.g., a hardware plane identifier used by the controller 116 as a classifier, etc.) or label (e.g., a policy group label) that may be interpreted by the corresponding network device. In some cases, the Li _ model 272 may include JSON objects. For example, the Li _ model 272 may include JSON objects to represent rules, filters, entries, ranges, and the like.

The format for the Li _ model 272 may be the same as or consistent with the format of the Ci _ model 274. For example, both Li _ model 272 and Ci _ model 274 may be based on JSON objects. A similar or matching format may enable a comparison of equivalence or consistency between the Li _ model 272 and the Ci _ model 274. Such equivalence checking can facilitate network analysis and assurance, as further explained herein.

The switch logic configuration generator 316 may also perform variation analysis and generate head of line events or records for problems found in the L _ model 270A and/or the LR _ model 270B. The end of line event or record may be used to generate an alert for the user or the network operator.

Policy operator 318 may receive Ci _ model 274 and Hi _ model 276 from unified collector 314 for each switch and Li _ model 272 from switch logic policy generator 316 for each switch and perform assurance checks and analyses (e.g., security compliance checks, TCAM utilization analyses, etc.) based on Ci _ model 274, Hi _ model 276, and Li _ model 272. Policy operator 318 may perform warranty checks on a switch-by-switch basis by comparing one or more of the models.

Returning to unification collector 314, unification collector 314 can also send L _ model 270A and/or LR _ model 270B to route policy resolver 320, and Ci _ model 274 and Hi _ model 276 to route resolver 326.

The routing policy parser 320 may receive the L _ model 270A and/or LR _ model 270B and parse the model(s) to obtain information that may be relevant to downstream operators (e.g., endpoint checker 322 and tenant routing checker 324). Similarly, route resolver 326 may receive Ci _ model 274 and Hi _ model 276 and resolve each model to obtain information for downstream operators (endpoint checker 322 and tenant route checker 324).

After parsing Ci _ model 274, Hi _ model 276, L _ model 270A, and/or LR _ model 270B, routing policy parser 320 and/or routing parser 326 may send the cleaned protocol buffers (Proto buffs) to the downstream operators (endpoint inspector 322 and tenant routing inspector 324). Endpoint checker 322 can then generate events related to endpoint violations, such as duplicate IP, APIPA, etc., and tenant route checker 324 can generate events related to deployment of BDs, VRFs, subnets, routing table prefixes, etc.

Fig. 3C illustrates a schematic diagram of an example system for static policy analysis in a network (e.g., network environment 100). Static policy analyzer 360 may perform warranty checks to detect configuration violations, logical head-of-line events, contradictory or conflicting policies, unused contracts, incomplete configurations, and the like. The static policy analyzer 360 can check the specification of the user's intent(s) in the L _ model 270A to determine if any configuration in the controller 116 is inconsistent with the specification of the user's intent(s).

The static policy analyzer 360 may include one or more operators 310 that are executed or hosted in the securing facility 300. However, in other configurations, static policy analyzer 360 may run one or more operators or engines separate from operator 310 and/or assurance device 300. For example, the static policy analyzer 360 may be a VM, a cluster of VMs, a collection of endpoints in a service function chain.

The static policy analyzer 360 may receive as input the L _ model 270A from the logical model collection process 366 and rules 368 defined for each feature (e.g., object) in the L _ model 270A. The rules 368 can be based on objects, relationships, definitions, configurations, and any other characteristics in the MIM 200. The rules 368 may specify conditions, relationships, parameters, and/or any other information for identifying configuration violations or issues.

Further, rules 368 may include information for identifying grammatical violations or issues. For example, rules 368 may include one or more rules for performing syntax checking. The syntax check may verify that the configuration of the L _ model 270A is complete and may help identify unused configurations or rules. The syntax checking may also verify that the configuration in the layered MIM200 is complete (defined) and identify any configuration that is defined but not used. To illustrate, the rules 368 may specify: each tenant in the L _ model 270A should have configured a context; each contract in the L _ model 270A should specify a provider EPG and a consumer EPG; each contract in L _ model 270A should specify a body, filter, and/or port; and so on.

The rules 368 may also include rules for performing semantic checks and identifying semantic violations or issues. Semantic checks may check for conflicting rules or configurations. For example, rule 1 and rule 2 may have alias problems, rule 1 may be more specific than rule 2 and thus create a conflict/problem, etc. The rules 368 may define conditions that may lead to alias rules, conflict rules, and the like. To illustrate, the rules 368 may specify: an admission policy for a particular communication between two objects may conflict with a denial policy for the same communication between two objects in the following cases: the allow policy has a higher priority than the deny policy, or a rule for an object makes another rule unnecessary.

The static policy analyzer 360 may apply rules 368 to the L _ model 270A to check the configuration in the L _ model 270A and output configuration violation events 370 (e.g., alarms, logs, notifications, etc.) based on any detected issues. Configuration violation events 370 may include semantic issues such as incomplete configurations, conflicting configurations, alias rules, unused configurations, errors, policy violations, misconfigured objects, incomplete configurations, incorrect contract ranges, inappropriate object relationships, and the like.

In some cases, the static policy analyzer 360 may iteratively traverse each node in a tree generated based on the L _ model 270A and/or the MIM200 and apply rules 368 at each node in the tree to determine whether any node produces a violation (e.g., an incomplete configuration, an improper configuration, an unused configuration, etc.). Static policy analyzer 360 may output a configuration violation event 370 when it detects any violations.

FIG. 4A illustrates an example flow diagram of a network assurance model. At step 400, the method involves data collection. Data collection may include collection of data for operator intent, such as structure data (e.g., topology, switches, interface policies, application policies, endpoint groups, etc.), network policies (e.g., BD, VRF, L2 output, L3 output, protocol configuration, etc.), security policies (e.g., contracts, filters, etc.), service chaining policies, etc. Data collection may also include data for specific, hardware models, such as network configuration (e.g., RIB/FIB, VLAN, MAC, ISIS, DB, BGP, OSPF, ARP, VPC, LLDP, MTU, QoS, etc.), security policies (e.g., TCAM, ECMP tables, etc.), endpoint dynamics (e.g., EPM, COOP EP DB, etc.), statistics (e.g., TCAM rule hits, interface counters, bandwidth, etc.).

At step 402, the method may involve formal modeling and analysis. Formal modeling and analysis may involve determining equivalence between logical and hardware models, such as security policies between models, and the like.

At step 404, the method may involve smart event generation. Smart events can be generated using deep object hierarchies for detailed analysis, such as: tenant, leaf node, VRF, rule; filters, routes, prefixes, port numbers.

At step 406, the method may involve visualization. In a user-friendly GUI, formal models may be used to identify problems for analysis and debugging.

FIG. 4B illustrates another method for static policy or configuration analysis. At step 420, the method may involve building a logic model based on network configuration data stored in a controller (e.g., controller 116) on a Software Defined Network (SDN) (e.g., network 100). The logical model may include declarative representations of respective configurations of objects in the SDN network, such as endpoint groups, bridged domains, contexts, tenants, and so forth. The logical model may include objects and object relationships in the representation configuration tree.

The corresponding configuration of the object may include endpoint group configuration, context configuration, bridged domain configuration, subnet configuration, security policy, and the like. The security policy may include contracts, filters, entries, and the like.

At step 422, the method may involve defining rules representing respective conditions of the object according to a specification corresponding to the SDN (e.g., an ACI specification). At step 424, the method may then involve determining whether the respective configuration of each object in the logical model violates one or more rules associated with the object. When the respective configuration of the object in the logical model violates one or more rules, the method may involve, at step 426, detecting an error in the respective configuration associated with the object.

FIG. 5 illustrates an example diagram of pseudo code for policy analysis. In this example, the pseudo code includes a step 502 for reading the configuration of the L _ model constructed as previously described. For each object in the L _ model, the pseudocode obtains a class name at step 504, a rule at step 506, and a tenant name at step 508.

At step 510, the configuration error for each rule and each object is checked and the results are obtained to determine if there is an error or violation. If the result is valid (e.g., there is a configuration between the object and the rule), then at step 512, a configuration violation for the object is created.

The present disclosure now turns to fig. 6 and 7, which illustrate example network devices and computing devices, e.g., switches, routers, load balancers, client devices, and the like.

Fig. 6 illustrates an example network device 600 suitable for performing switching, routing, load balancing, and other networking operations. Network device 600 includes a Central Processing Unit (CPU)604, an interface 602, and a bus 610 (e.g., a PCI bus). When acting under the control of appropriate software or firmware, the CPU 604 is responsible for performing packet management, error detection, and/or routing functions. CPU 604 preferably accomplishes all these functions under the control of software including an operating system and any appropriate applications software. The CPU 604 may include one or more processors 608, such as a processor from the INTEL X86 family of microprocessors. In some cases, processor 608 may be specially designed hardware for controlling the operations of network device 600. In some cases, a memory 606 (e.g., non-volatile RAM, ROM, etc.) also forms part of the CPU 604. However, there are many different ways in which memory could be coupled to the system.

The interfaces 602 are typically provided as modular interface cards (sometimes referred to as "line cards"). Generally, they control the sending and receiving of data packets over the network and sometimes support other peripherals used with the network device 600. Interfaces that may be provided include ethernet interfaces, frame relay interfaces, cable interfaces, DSL interfaces, token ring interfaces, and the like. In addition, various very high-speed interfaces may be provided, such as fast token ring interfaces, wireless interfaces, ethernet interfaces, gigabit ethernet interfaces, ATM interfaces, HSSI interfaces, POS interfaces, FDDI interfaces, WIFI interfaces, 3G/4G/5G cellular interfaces, CAN buses, LoRA, and the like. Generally, these interfaces may include ports appropriate for communication with the appropriate media. In some cases they may also include a separate processor and, in some cases, volatile RAM. The independent processors may control such communications intensive tasks as packet switching, media control, signal processing, encryption processing and management. By providing separate processors for the communications intensive tasks, these interfaces allow the master microprocessor 604 to efficiently perform routing computations, network diagnostics, security functions, etc.

Although the system shown in fig. 6 is one specific network device of the present invention, it is by no means the only network device architecture on which the present invention can be implemented. For example, an architecture having a single processor that handles communications as well as routing computations, etc. is often used. In addition, other types of interfaces and media could be used with network device 600.

Regardless of the network device's configuration, it may employ one or more memories or memory modules (including memory 606) configured to store program instructions for the general-purpose network operations and mechanisms for roaming, route optimization and routing functions described herein. The program instructions may control the operation of an operating system and/or one or more applications, for example. The one or more memories may also be configured to store tables such as mobility binding, registration and association tables, and the like. The memory 606 may also hold various software containers and virtualized execution environments and data.

Network device 600 may also include an Application Specific Integrated Circuit (ASIC) that may be configured to perform routing and/or switching operations. For example, an ASIC may communicate with other components in the network device 600 via the bus 610 to exchange data and signals and coordinate various types of operations of the network device 600, such as routing, switching, and/or data storage operations.

Fig. 7 shows a computing system architecture 700 in which components of the system are in electrical communication with each other using a connection 705, such as a bus. The exemplary system 700 includes a processing unit (CPU or processor) 710 and a system connection 705 that couples various system components including a system memory 715, such as a Read Only Memory (ROM)720 and a Random Access Memory (RAM)725 to the processor 710. System 700 may include a cache of high-speed memory directly connected to processor 710, in proximity to processor 710, or integrated as part of processor 710. The system 700 may copy data from the memory 715 and/or the storage 730 to the cache 712 for quick access by the processor 710. In this manner, caching may provide performance enhancements that avoid delays while processor 710 waits for data. These and other modules may control or be configured to control the processor 710 to perform various actions. Other system memory 715 may also be used. The memory 715 may include a plurality of different types of memory having different performance characteristics. Processor 710 may include any general purpose processor and hardware or software services configured to control processor 710 (e.g., services 1732, services 2734, and services 3736 stored in storage device 730) as well as special purpose processors where software instructions are embodied in the actual processor design. Processor 710 may be a fully self-contained computing system including multiple cores or processors, buses, memory controllers, caches, and so on. The multi-core processor may be symmetric or asymmetric.

To enable user interaction with computing device 700, input device 745 may represent any number of input mechanisms, such as a microphone for voice, a touch-sensitive screen for gesture or graphical input, a keyboard, a mouse, motion input, speech, and so forth. The output device 735 may also be one or more of a variety of output mechanisms known to those skilled in the art. In some cases, a multimodal system may enable a user to provide multiple types of input to communicate with the computing device 700. Communication interface 740 may generally control and manage user inputs and system outputs. There is no limitation to the operation performed by any particular hardware arrangement, and thus the essential features herein can be readily substituted for improved hardware or firmware arrangements as they are developed.

The storage device 730 is a non-volatile memory and may be a hard disk or other type of computer-readable medium that can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, solid state memory devices, digital versatile disks, magnetic cassettes, Random Access Memory (RAM)725, Read Only Memory (ROM)720, and hybrids thereof.

Storage 730 may include services 732, 734, 736 for controlling processor 710. Other hardware or software modules are contemplated. A storage device 730 may be connected to the system connection 705. In one aspect, a hardware module that performs a particular function may include software components stored in a computer-readable medium that is coupled to necessary hardware components (e.g., processor 710, connection 705, output device 735, etc.) to perform the function.

In summary, systems, methods, and computer-readable media for static network policy analysis of a network are described. In one example, a system obtains a logical model based on configuration data stored in a controller on a software defined network, the logical model including a declarative representation of respective configurations of objects in the software defined network, the objects including one or more endpoint groups, bridged domains, contexts, or tenants. The system defines rules representing respective conditions of the objects according to specifications corresponding to the software defined network and determines whether a respective configuration of each object in the logical model violates one or more rules associated with the object. When a respective configuration of an object in the logical model violates one or more rules, the system detects an error in the respective configuration associated with the object.

For clarity of explanation, in some instances the present technology may be presented as including individual functional blocks, including functional blocks that comprise: a device, a component of a device, a step or routine in a method implemented in software, or a combination of hardware and software.

In some embodiments, the computer-readable storage devices, media, and memories may comprise wired or wireless signals including bit streams and the like. However, when mentioned, non-transitory computer-readable storage media expressly exclude media such as energy, carrier wave signals, electromagnetic waves, and signals per se.

Methods according to the examples described above may be implemented using computer-executable instructions stored or otherwise available from computer-readable media. Such instructions may include, for example, instructions and data which cause or otherwise configure a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. Portions of the computer resources used may be accessible over a network. The computer-executable instructions may be, for example, binary instructions, intermediate format instructions such as assembly language, firmware, or source code. Examples of computer readable media that may be used to store instructions, information used, and/or information created during a method according to the described examples include magnetic or optical disks, flash memory, USB devices with non-volatile memory, networked storage devices, and so forth.

Devices implementing methods according to these disclosures may include hardware, firmware, and/or software, and may take any of a variety of form factors. Typical examples of such form factors include laptop computers, smart phones, small personal computers, personal digital assistants, rack devices, stand-alone devices, and the like. The functionality described herein may also be implemented in a peripheral device or add-on card. As a further example, such functions may also be implemented on a circuit board between different chips, or in different processes performed in a single device.

The instructions, the media used to convey these instructions, the computing resources used to execute them, and other structures used to support such computing resources are means for providing the functionality described in these disclosures.

Although various examples and other information may be used to interpret aspects within the scope of the appended claims, no limitation to the claims should be implied based on the particular features or arrangements in the examples, as one of ordinary skill would be able to derive a wide variety of implementations using the examples. Furthermore, although some subject matter may have been described in language specific to examples of structural features and/or methodological steps, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the described features or acts. For example, such functionality may be distributed differently among or performed in components other than those identified herein. Rather, the described features and steps are disclosed as examples of components of systems and methods within the scope of the appended claims.

Claim language referring to "at least one" refers to at least one of a collection and indicates that one member of the collection or a plurality of members of the collection satisfies the claim. For example, claim language referring to "at least one of a and B" means A, B or a and B.

Claims (20)

1. A method for static network policy analysis of a network, comprising:

obtaining a logical model based on network configuration data stored in a controller on a software defined network, the logical model comprising a declarative representation of a configuration of an object associated with the software defined network, the object comprising at least one of: one or more endpoint groups, one or more bridged domains, one or more contexts, or one or more tenants;

defining rules corresponding to conditions of the object according to specifications of the software defined network;

reading the logical model and, for each of the objects in the logical model, determining a respective class name associated with a respective one of the objects, one or more respective rules associated with the respective one of the objects, and a respective tenant name associated with the respective one of the objects;

determining whether the configuration violates one or more of the rules; and

detecting an error in the configuration when the configuration violates the one or more of the rules.

2. The method of claim 1, wherein the configuration comprises at least one of: contract, filter, body, or entry.

3. A method as claimed in claim 1 or 2, wherein the declarative representation defines one or more relationships between the objects.

4. The method of claim 1 or 2, wherein the software defined network comprises an application-centric infrastructure network and the controller comprises an application policy infrastructure controller.

5. The method of claim 1 or 2, wherein determining whether the configuration violates the one or more of the rules comprises:

analyzing the one or more rules to determine whether a configuration error exists.

6. The method of claim 1 or 2, wherein determining whether the configuration violates the one or more of the rules comprises:

generating a list of flat rules based on the configuration, each of the flat rules including a mathematical representation of an associated configuration from the configuration; and

the flat rule is analyzed.

7. A system for static network policy analysis of a network, comprising:

one or more processors; and

at least one computer-readable storage medium having instructions stored therein, which when executed by the one or more processors, cause the one or more processors to:

obtaining a logical model based on network configuration data stored in a controller on a software defined network, the logical model comprising a declarative representation of a configuration of an object associated with the software defined network, the object comprising at least one of: one or more endpoint groups, one or more bridged domains, one or more contexts, or one or more tenants;

defining a rule representing a condition of the object according to a specification corresponding to the software defined network;

reading the logical model and for each of the objects in the logical model, determining a respective class name associated with a respective one of the objects, one or more respective rules associated with the respective one of the objects, and a respective tenant name associated with the respective one of the objects;

determining whether the configuration violates one or more of the rules; and

detecting an error in the configuration when the configuration violates the one or more of the rules.

8. The system of claim 7, wherein the configuration comprises at least one of: endpoint group configuration, context configuration, bridged domain configuration, subnet configuration, or security policy.

9. The system of claim 8, wherein the security policy comprises at least one of: contract, filter, body, or entry.

10. The system of any of claims 7 to 9, wherein the declarative representation defines one or more relationships between the objects.

11. The system of any of claims 7 to 9, wherein the software defined network comprises an application centric infrastructure network and the controller comprises an application policy infrastructure controller.

12. The system of any of claims 7 to 9, wherein determining whether the configuration violates the one or more of the rules comprises:

the rule is analyzed to determine if there is a configuration error.

13. A non-transitory computer-readable storage medium, comprising:

instructions stored in the non-transitory computer-readable storage medium that, when executed by one or more processors, cause the one or more processors to:

obtaining a logical model based on network configuration data stored in a controller on a software defined network, the logical model comprising a declarative representation of a configuration of an object associated with the software defined network, the object including at least one of: one or more endpoint groups, one or more bridged domains, one or more contexts, or one or more tenants;

defining a rule representing a condition of the object according to a specification corresponding to the software defined network;

reading the logical model and for each of the objects in the logical model, determining a respective class name associated with a respective one of the objects, one or more respective rules associated with the respective one of the objects, and a respective tenant name associated with the respective one of the objects;

determining whether the configuration violates one or more of the rules; and

detecting an error in the configuration when the configuration violates the one or more of the rules.

14. The non-transitory computer-readable storage medium of claim 13, wherein the one or more contexts include one or more virtual routing and forwarding instances, and wherein the configuration includes at least one of: an attribute associated with the object, a contract associated with the object, or a relationship between the objects.

15. The non-transitory computer readable storage medium of claim 13 or 14, wherein the software defined network comprises an application-centric infrastructure network and the controller comprises an application policy infrastructure controller.

16. The non-transitory computer-readable storage medium of claim 13 or 14, wherein determining whether the configuration violates the one or more of the rules comprises:

the rules are analyzed to determine if there is a configuration error.

17. The non-transitory computer-readable storage medium of claim 13 or 14, wherein obtaining the logical model comprises: the logical model is built based on configuration and runtime state data collected in the software defined network.

18. The non-transitory computer-readable storage medium of claim 13 or 14, wherein the configuration comprises at least one of: endpoint group configuration, context configuration, bridge domain configuration, subnet configuration, or security policy.

19. An apparatus for static network policy analysis of a network, comprising:

means for obtaining a logical model based on network configuration data stored in a controller on a software defined network, the logical model comprising declarative representations of respective configurations of objects associated with the software defined network, the objects including at least one of: one or more endpoint groups, one or more bridged domains, one or more contexts, or one or more tenants;

means for defining rules corresponding to respective conditions of the objects according to specifications of the software defined network;

means for reading the logical model and determining, for each of the objects in the logical model, a respective class name associated with a respective one of the objects, one or more respective rules associated with the respective one of the objects, and a respective tenant name associated with the respective one of the objects;

means for determining whether the configuration violates one or more of the rules; and

means for detecting an error in the configuration when the configuration violates the one or more of the rules.

20. The apparatus of claim 19, further comprising means for implementing the method of any one of claims 2 to 6.

Images