WO2016072996A1 - Network policy graphs - Google Patents
Network policy graphs Download PDFInfo
- Publication number
- WO2016072996A1 WO2016072996A1 PCT/US2014/064394 US2014064394W WO2016072996A1 WO 2016072996 A1 WO2016072996 A1 WO 2016072996A1 US 2014064394 W US2014064394 W US 2014064394W WO 2016072996 A1 WO2016072996 A1 WO 2016072996A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- network
- policy
- graph
- composite
- graphs
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0803—Configuration setting
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0895—Configuration of virtualised networks or elements, e.g. virtualised network function or OpenFlow elements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/64—Hybrid switching systems
- H04L12/6418—Hybrid transport
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/085—Retrieval of network configuration; Tracking network configuration history
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0893—Assignment of logical groups to network elements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0894—Policy-based network configuration management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/12—Discovery or management of network topologies
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities
Definitions
- SDN Software-defined networking
- the hardware e.g., routers, switches, server, etc.
- virtual network and compute resources e.g., virtual L2/L3 networks, virtual machines
- users such as operators, service providers, application developers, tenants, and other users.
- FIG. 1 is a schematic system diagram according to various examples of the present disclosure.
- FIG. 2 illustrates example network policy graphs.
- FIG. 3 illustrates example policy graph sources and corresponding network policy graphs.
- FIG. 4 illustrates a data flow of network policy graphs into a policy graph composer to generate a composite policy graph, according to various examples of the present disclosure.
- FIG. 5 depicts an example policy graph composer.
- FIG. 6 is a flowchart of a method for generating composite network policy graphs, according to examples of the present disclosure.
- FIG. 7 depicts two example network policy graphs associated with specific SDN entities.
- FIG. 8 depicts an example composite network policy graph.
- SDN Software defined networking
- a network controller that implements various policies by programing the network hardware with specific rules.
- the policies or the rules can be expressed in one or more high-level or low-level network programming languages.
- Examples of the present disclosure include a policy graph abstraction (PGA) that provides an intuitive visual methodology for defining network policies and improves the design and implementation processes of network programs.
- the PGA described herein includes a graph model and declarative language to specify complex policies and that can be used to generate corresponding network programs to support the goals of multiple SDN users without requiring information about or changes to the physical topology, the subnet, the VLAN, or any of the endpoint IP/MAC addresses in the network.
- Various examples of the PGA also enable semi-automatic composition of modular sub-graphs written by different types of SDN users, such as operators, tenants, SDN developers, and the like.
- Examples of the PGA in the present disclosure include a high-level API that can support simplified specification of user goals, expressed as network policies and network invariants, which can be used as intuitive expressions in a corresponding networking programming language. Other examples can also detect and resolve conflicts within a policy and between policies. The policies can be combined to create more complex composite policies so that the various users of the network need only be concerned with their own goals and policies.
- the API can include a policy graph composer to support various types of SDN users, such as SDN solution providers, enterprise ITs, cloud operators, tenants, application owners, SDN server/application developers, and the like, with various levels of flexibility and simplicity for programming a network.
- SDN solutions providers such as SDN solution providers, enterprise ITs, cloud operators, tenants, application owners, SDN server/application developers, and the like.
- FIG. 1 illustrates a system 100 for programming and controlling a network 160, in accordance with various examples.
- the system 100 can include permanent or temporary connections to multiple policy graph sources 120.
- policy graph source can be used
- Each of the policy graph sources 120 can be connected to, or otherwise access, the policy graph composer 1 10.
- each of the policy graph sources 120 can design network policy graphs specific to its own corresponding goals.
- the functionality provided by the policy graph composer 1 10 can include a graphical user interface with drag-and-drop features for selecting and designing visual representations of the graphs depicted in some of the accompanying drawings.
- the functionality of the policy graph composer 1 10 can include a library, and/or an API for accessing a library, of previously designed network policy graphs. The API can also be used to create a new graph, or new graph components (nodes and path polices).
- the policy graph composer 1 10 can analyze the network policy graphs input by the various policy graph sources 120 to compose a composite network policy graph. The policy graph composer 1 10 can then convert the composite network policy graph to generate commands, or other control signals, that can be sent to the network controller 130.
- the network controller 130 in response to the commands received from the policy graph composer 1 10, can program the various components of the network 160.
- network 160 can include multiple switches 140 and computing resources 150 connected to and in electronic communication with one another using various electronic communication media and protocols.
- switch refers to any networking hardware that can be used to route data from one endpoint to another.
- Each computing resource 150 can include any type of function specific or general purpose computing hardware. Accordingly, as used herein, the term
- computing resource can refer to any computing device, such as a server computer, capable of instantiating applications, virtual machines (VMs), and other executable code.
- VMs virtual machines
- the policy graph sources 120 and/or their corresponding input, the policy graph composer 1 10, and/or the network controller 130 can be implemented in any one or more of the computing resources 150 or other computing resource not shown.
- the policy graph sources 120, the policy graph composer 1 10, and/or the network controller 130 can be implemented as any combination of software, firmware, and hardware in a single or in multiple physical or virtual computer systems.
- the software or firmware can be implemented as computer executable instructions stored on a non-transitory computer readable medium.
- Various examples of the present disclosure can be implemented or instantiated in one or more computer systems by executing the computer executable instructions in one or more computer processors.
- the policy graph sources 120, the policy graph composer 1 10, and/or the network controller 130 can be instantiated in any of the computing resources 150 or in another computer system (not shown) coupled to the network 160.
- FIG. 2 illustrates several example network policy graphs 220 depicted using example implementations of the PGA model described herein.
- each one of the policy network graphs 220 can include at least one endpoint group (EPG) 230 connected to another EPG 230 by a path 240.
- the EPGs 230 are sometimes referred to as EPG nodes, and the paths 240 are sometimes referred to as edges. Such terminology is consistent with conventional description of graphs.
- the EPGs 230 are connected to one or more other EPGs through paths 240 and/or a policy box 250.
- each network policy graph 220 can be placed in or associated with a ranking or hierarchy expressed by the boundaries 205. A specific example organization of the hierarchy is described herein in reference to other example implementations.
- Network policy graphs 220 can be defined using the PGA as an intuitive graph model to specify policies, requirements and service logic. Each network policy graph 220 can describe a logical topology between EPGs 230 and policy boxes 250.
- endpoint group or "EPG” refers to a group of arbitrary addressable (e.g., IP, MAC, subnet, VLAN, etc.) endpoints or a group of EPGs 230 that can perform a common logical role or share a common property.
- policy box refers to the functionality, or the visual representation of the functionality, used to implement network services such as firewall, monitoring, Network Address Translation, routing, load- balancing, etc.
- a policy box 250 can include a composition of multiple modular policy boxes. As shown, zero or more policy boxes 250 can be placed on directional paths 240 between EPGs 230.
- Various examples of the present disclosure can include a network programming language that describes the behaviors and properties of policy boxes 250.
- the network programming language representations of the functionality and properties of the policy boxes 250 can be useful for detecting potential dependencies and conflicts among the network policy graphs 220 and for generating composite network policy graphs.
- the policy graph composer 1 10 can analyze component network policy graphs 220 that may be combined into the resulting composite network policy graph.
- the policy graph composer 1 10 can detect policy conflicts and dependencies between the graphs 220 and automatically compose the graphs 220 into one complex network policy graph that satisfies the invariants specified in each individual network policy graph.
- the analysis of the conflicts and the composition of the composite network policy graphs can include analysis of the relationships (e.g., conflicts, dependencies, impacts, etc.) between policy boxes 250 of the network policy graphs 220 to be combined together on the same path in the composite network policy graph.
- the relationships can be used to automatically determine the right placement and order of the policy boxes 250 in the composite network policy graph and some of the relationships (e.g., conflicts) can be reported to users for attention or correction.
- the policy graph composer can use the set relationships between EPGs and the domain relationships between EPGs and policy boxes to derive the order of the policy boxes requested by different policy graph sources.
- the PGA can consider a hierarchy of policy graph domains, as the domain separations are depicted as boundaries 205.
- Each network policy graph 220 can be associated with or originate from a corresponding policy graph source 120, as shown in FIG. 3.
- the network policy graph 220-1 is associated with the policy graph source 1 120-1 (e.g., an operator)
- network policy graph 220-2 is associated with the policy graph source 2 120-2 (e.g. a tenant)
- network policy graph 220-3 is associated with the policy graph source 3 120-3 (e.g. an application developer)
- network policy graph 220-4 is associated with the policy graph source 4 120-4 (e.g. a solution provider).
- the network policy graphs 220 may be processed or analyzed differently for composition into a composite network policy graph.
- a tenant of the network 160 can create network policy graphs in the tenant domain.
- the tenant may be an enterprise with various departments and each department can create graphs in
- the PGA can include directed network policy graphs 220 that can include EPG 230 nodes and/or policy box 250 nodes. Such directed network policy graphs 220 include indications of data flow directions between the nodes.
- circular/oval-shaped vertices represents EPGs 230 and can include any group of arbitrary addressable endpoints or a group of endpoints that perform a common logical role or share a common property.
- a user can create an EPG to represent a logical role without real endpoint identifiers. Endpoint identifiers such as IP, MAC, subnet, VLAN addresses can be given later through 'late-binding'.
- an EPG 230 can represent a user-defined application component (e.g., web or database server, Lync server) or dynamic membership (e.g., current guest devices, Lync VoIP session, security-quarantined clients).
- An EPG 230 can have mandatory and optional parameters. For example, service port numbers, Virtual Machine (VM) type, auto-scaling option, fault-tolerance level, IP ranges, etc.
- EPGs 230 in a graph do not have overlap by default, i.e., the intersection of any EPG pair is empty (no common endpoint). If EPGs 230 do overlap, their set relationship must be specified. For instance, an EPG A is a subset of an EPG B, or a tenant EPG is the union of web and database EPGs. The set relationships, including 'no overlap', can allow the system to analyze a graph and to compose multiple graphs, without requiring real endpoint identifiers to be given.
- VM Virtual Machine
- Various example implementations can include a 'shadow' EPG that can be defined in suitable scenarios, such as in a security service that defines two EPGs 230 as "normal hosts” and “quarantined hosts” and that maintains separate policies for each.
- a security service graph is combined with any other graph, the user can define a 'shadow' EPG 230 that can include both normal host EPGs and quarantined host EPGs and the shadow EPG may be composed with EPGs in the other graph, thus triggering composition of the composite graph.
- the rectangular-shaped policy box 250 vertices can represent implementations of network services such as, but not limited to, load- balancing, firewalls, traffic engineering, billing, etc.
- a policy box 250 can be a minimal unit of service chaining and graph composition. Multiple policy boxes 250 can be chained together for service chainning. But during the composition of multiple network policy graphs 220, a chain of policy boxes 250 from one network policy graph 220 can be disconnected. The disconnected boxes can form a new chain in the composite network policy graph 220 together with other policy boxes 250 from other network policy graphs 220.
- a policy box 250 can represent an abstract 'function' that takes a packet as input and returns a set of zero or more packets.
- a network programming language can be used to describe the function, behaviors, and properties, which can be used for conflict detection, resolution, graph composition and rule compilation.
- the Pyretic network programming language can be used. Pyretic is switch-centric and can use real IP/MAC addresses to implement network programs. Pyretic can be extended to write
- Extended Pyretic can include extensions to the language that can be useful for PGA. Extended Pyretic can support "gray boxing", that can capture high-order behavior of a proprietary black box or a network policy box 250 running dynamic policies.
- Dynamic policies have behavior that changes over time, according to the programmer's specification of an arbitrary internal state machine, which is difficult to analyze offline before deploying the program to the operational network.
- a server load-balancing policy box 250 may select the destination server IP for a new client request in a round-robin manner or based on any per-server state information.
- An exact mapping between a client request to a specific server and the server becomes known only in run-time.
- Gray-boxing lets the user (load-balancing policy box 250 writer or an operator using the policy box 250) to specify the mapping behavior at a high-level without considering the actual mappings. For example:
- web.virtualjp is the virtual IP address used by clients to send requests to and web.realjp is the set of real IP addresses of web server endpoints registered to the web EPG 230 at any given time.
- set of real IPs it is possible to capture the useful information that the destination IP of a client request message will be rewritten to one of the web server IPs. Examples of the present disclosure can use this high-order information for conflict detection and automatic graph composition, as described herein.
- gray boxing can be useful to capture the high-level behavior of proprietary middle box applications, which can be black boxed (e.g., the exact internal behaviors are unknown).
- a DPI-based Intrusion Prevention System (IPS) policy box can drop certain packets based on packet payloads or any proprietary algorithm for detecting DDOS attack.
- IPS Intrusion Prevention System
- a user can provide a gray-box version of the IPS box as the statement:
- identity is the Pyretic action for 'allow'
- select(A1 , A2%) indicates that one of the specified actions (A1 , A2 7) is selected, with its selection logic unknown, and applied to its input packet.
- the select()in extended Pyretic can support gray-boxing. If it is known that the IPS box will block some endpoints from the 'client' EPG, its gray-box can be represented by:
- client.ip indicates the set of IP addresses of client EPG.
- Examples of the present disclosure can be implemented as a policy graph composer 1 10 in an SDN system 100, as depicted in FIG. 1 .
- FIG. 5 illustrates one example implementation of the policy graph composer 1 10.
- FIG. 5 illustrates the various components of the policy graph composer 1 10 and the relative dataflow to give context to the other implementations described herein.
- the policy graph composer can include a user interface/network policy graph editor, or a user graph editor 510, that includes functionality for providing a user interface and/or an API 505 to the various users of the newtork 160.
- the user graph editor 510 can provide a graphical user interface that can be used to drag- and-drop component EPGs 230, paths 240, and policy boxes 250 to create network policy graphs and/or express the goals of the particular user.
- user graph editor 510 can also include functionality for receiving or retrieving previously defined network policy graphs from the graph and policy library 525.
- the previously defined network policy graphs can be used as components of network policy graphs defined by a user using the user interface/API 505.
- the policy graph composer 1 10 can also include a policy graph converter 520.
- the policy graph converter 520 can receive network policy graphs from the user graph editor 510 and/or individual policy graphs 515 from other sources (e.g., an external graph library or database).
- the process of generating a composite network policy graph can begin with the policy graph converter 520 converting multiple component network policy graphs into appropriate network programming language statements. The details of the conversion of the network policy graphs to a network programming language are discussed in more detail below.
- the policy graph composer 1 10 can also include an EPG generator 530.
- the EPG generator 530 can include functionality for analyzing the relationships between the various EPGs 230 in the component network policy graphs. For instance, the EPG generator 530 can analyze the overlap of the EPGs 230 by determining the intersection and unions on a pairwise basis for up to all of the EPGs 230 in component network policy graphs. The EPG generator 530, based on the analysis of the relationships between the EPGs 230, can generate, or otherwise determine, the resulting composite network policy graph.
- the path generator 540 of the policy graph composer 1 can include functionality for determining the paths in the resulting composite network policy graph. By analyzing the relationships between the EPGs 230 and the original paths 240 and policy boxes 250 in the component network policy graphs represented in the network programming language provided by the policy graph converter 520, and the analysis performed by the EPG generator 530, the path generator 540 can determine the configuration of the paths and policy boxes in the resulting composite network policy graph.
- the policy graph composer 1 10 can include a conflict checker 550 to verify and determine the dependencies and conflicts between the policy boxes in the resulting composite network policy graph.
- a conflict checker 550 to verify and determine the dependencies and conflicts between the policy boxes in the resulting composite network policy graph.
- an error message/confirmation message can be sent to the user graph editor 510 and/or user interface/API 505 to alert a user to take corrective action.
- the path generator 540, or some other component of the policy graph composer 1 10 can compose the composite network policy graph 515 and provide it to another component of the system 100, such as the network controller 130 to program the network 160.
- FIG. 6 depicts a flowchart of a method 600 for generating composite network policy graphs, according to examples of the present disclosure.
- the method 600 can begin when the policy graph composer 1 10 receives one or more network policy graphs, at box 610.
- the policy graph composer 1 10 receives one or more network policy graphs, at box 610.
- receiving the network policy graphs can include converting the network policy graphs into a network programming language syntax.
- the conversion of network policy graphs into a network programming syntax is described in more detail below.
- the policy graph composer 1 10 can generate EPGs for the composite network policy graphs.
- the policy graph composer 1 10 can analyze the relationships between the EPGs 230 to determine the specific EPGs to include in the resulting composite network policy graph. The details of the EPG generation are described in more detail below.
- the policy graph composer 1 10 can generate paths for the resulting composite network policy graph.
- the composite paths can include a combination of the paths and/or the policy boxes defined in the component network policy graphs . Additional details of path generation are described in more detail below.
- the policy graph composer 1 10 can generate a composite policy graph based on the composite EPGs and paths. Additional details are described in more detail below.
- the policy graph composer 1 10 can analyze the composite policy graph to detect or determine dependencies and conflicts among the EPGs, paths, and policy boxes of the composite policy graph.
- the policy graph composer 1 10 can generate an error message to correct the policy graphs, at box 675.
- the error message can prompt a user to correct one or more of the input network policy graphs or to supply a new network policy graph.
- the policy graph composer 1 10 can output the composite policy graph to the network controller 130.
- Outputting the composite network policy graph can include converting the composite network policy graph into a network programming language.
- the network controller 130 can then use the composite network policy graph to program the network 160.
- An EPG 230 in a network policy graph 220 can be classified as a source or sink of network traffic while a policy box 250 neither creates nor consumes traffic by itself, such as, for example, the source EPG 730 and sink EPG 735 in FIG. 7.
- a directed 'path' is defined between a source EPG and a sink EPG.
- a path starts from the source EPG 230, traverses zero or more policy boxes 250 and ends at the sink EPG 230.
- a cycle is allowed, for example, when a web EPG sends to a database EPG through a policy box A while the reverse traffic from DB to web EPG is traversing policy boxes B and C.
- An EPG 230 may have a self-loop path representing traffic among endpoints of that EPG, e.g., synchronization between database server (DB) VMs.
- DB database server
- no communication is allowed between vertices, by default (e.g., default 'deny' rule).
- a solid directed edge 240 can enable communication as specified by filter attributes on the edge classifier, e.g., label 'UDP, dstport 53' allows only UDP traffic with destination port number 53 on that edge, thus implementing security whitelisting.
- Another default security measure can include a rule that an outgoing edge from a source EPG 230 constrains the source IP addresses allowed on that edge 240 only to the IPs of the source EPG 230 endpoints.
- An incoming edge 240 to a sink EPG 230 can also limit the dst IP to the sink EPG 230 endpoints' IPs.
- Such default srclP/dstIP constraints may not be applied to an EPG 230 with L3 forwarding, such as virtual router.
- L3 forwarding such as virtual router.
- a security attribute can be stateful, such that responses to allowed TCP traffic in the direction of the edge can be allowed in the reverse direction as well.
- a chain of solid edges 240 connecting a source EPG 230, through a set of policy boxes 250, to a sink EPG 230 is called a 'solid path'.
- a solid path has two implications. Firstly, the solid path can include security whitelisting as described above. Secondly, the solid path can include a path requirement meaning that the allowed communication from the source to the sink must traverse the policy boxes on that path. [0057] Some users, such as network operators, may want to impose only the path requirement without explicitly allowing any communication.
- a 'dotted path' in a network policy graph 220 connecting a source EPG to a sink EPG represents such a path requirement without whitelisting.
- Such path requirements e.g., dotted paths in an operator graph
- multiple network policy graphs 220 can be input into the policy graph composer 1 10, as depicted in FIG. 4 and described in reference to FIGS. 5 and 6.
- the policy graph composer 1 10 can analyze the various aspects and properties of each of the input network policy graphs 220 to compose and generate a composite network policy graph 320.
- the policy graph composer 1 10 can first convert the component network policy graphs 220 into a high-level network programming language, such as Pyretic or extended Pyretic, described herein.
- the behavior of the sequential composition ('»') operator in Pyretic is to pass all the packets output from one Pyretic policy to the next Pyretic policy in sequence.
- all of the output packets of one policy box 250 can be input to the next policy box 250 in the path 240.
- the sequential composition operator can be used to express a solid edge from the graph.
- a new policy box 250 can be created to capture the whitelisting parameters provided as edge classifiers on the solid edge and added to the path 240.
- a source EPG, the policy boxes 250 and a sink EPG can be mapped into policy objects.
- the sequential composition operator can be added between each successive pair of policy objects.
- the '>' in extended Pyretic can be used.
- the conversion procedure is similar.
- the source EPG, the policy boxes 250, and the sink EPG can be mapped into policy objects with the path requirement operator connecting them.
- the solid line graph 700 in FIG. 7 can be expressed in extended Pyretic as:
- the path requirement graph 705 from FIG. 7 can be expressed as:
- Automatic analysis and composition can be improved based on knowledge of user goals for a policy box 750. Accordingly, users can explicitly specify 'match' filters or 'identity' in conjunction with any kind of action being performed.
- the policy graph composer 1 10 can initiate composite network policy composition under various circumstances. For example, composite network policy graph composition can be triggered whenever a new network policy graph 220 is created or an existing graph is updated at any level of a graph hierarchy. For example, the method 600 of FIG. 6 can be initiated whenever a trigger is detected.
- the network policy graph created or updated can be automatically combined with the graphs below and above in the hierarchy by determining the EPG relationships, as described herein.
- Graph composition can also be triggered by a simple drag-and-drop GUI action that triggers merging of a service/status EPG (e.g., security-contaminated vs. security-clean) and a tenant/network EPG.
- a service/status EPG e.g., security-contaminated vs. security-clean
- tenant/network EPG e.g., security-contaminated vs. security-clean
- One example can include the combination of two network policy graph Gi and G 2 , such as 700 and 705.
- the combination composition of three or more network policy graphs can be achieved by repeating the two-graph composition, described herein.
- the combination of two network policy graphs, Gi and G 2 can begin by identifying set relationships between EPGs from the two graphs.
- the EPGs from the same graph may not overlap, as described herein.
- the relationships between EPGs across network policy graphs G1 and G2 can be derived by the graph/EPG hierarchy, accessed or determined by the policy graph composer 1 10 or by one of the policy graphs sources 120.
- the policy graph composer 1 10 may require the policy graphs sources 120 to provide the EPG set relationships at the time of composition.
- the composite network policy graph G3 can be composed by analyzing the relationships, intersections, and unions between the EPGs.
- all paths in both network policy graphs can be assumed to be solid, thus implying both security whitelisting and path requirement.
- the existing EPGs in the network policy graph can be split.
- E1 u E2 can be into one, two or three resulting EPGs based on the Venn diagram between E1 and E2.
- the resulting EPGs can be assigned to G3.
- the EPGs appearing only in either G1 or G2, thus having no overlapping EPG in the other graph, can be copied directly to G3.
- the paths for the composite network policy graph can be created as described herein.
- a directed path from EPG X to EPG Y (X->Y) is added to G3 in one of the following scenarios.
- both X and Y are 'pure' EPGs, in that case, X (Y) appears only in G1 or G2, but not in both.
- X->Y is added to G3 if X and Y appeared in the same graph (either G1 or G2) and the communication specified by the path X->Y is allowed in the original graph (Gi or G 2 ).
- X->Y has the same intermediate policy boxes specified in the original path allowing the communication.
- X is pure and Y is mixed. X appears in only G1 or G2 and Y appeared in both G1 and G2.
- X->Y has the same intermediate policy boxes specified in the original path allowing the communication.
- both X and Y are mixed.
- X and Y appeared in both G1 and G2.
- X->Y is added only if the communication specified by the path is allowed in both Gi and G 2 .
- X ⁇ Y is added only if S1 -»D1 exists in G1 and S2 ⁇ D2 exists in G2.
- the path X->Y will have the union of B1 and B2 as a result of the 'path merging' logic, described herein. Note that it is not required to differentiate between AND vs. OR operators when both X and Y are 'pure' EPGs or when both X and Y are mixed.
- the path between the overlapping parts of source EPGs and the overlapping parts of sink EPGs can include all the network policy boxes from the constituent graphs.
- automatically merging policy boxes from different graphs onto a single one can be challenging because an improper ordering of policy boxes can lead to the violation of invariants of any of the individual network policy graphs.
- Path merging can be achieved using two simple graphs as shown in FIG. 7.
- the goal of the policy graph source that authored network policy graph 705 is to count the number of bytes coming from the Internet to each machine of every tenant. This is specified in network policy graph 705 by creating a Byte Counter policy box 750-3.
- Internet EPG 730-2 and All Tenants EPG 735-2 are the source and sink EPGs respectively in the network policy graph 705.
- the tenant network policy graph 700 includes the Internet EPG and Web tier EPGs and policy boxes ACL 750-1 and LB 750-2.
- the ACL policy box 750-1 only allows packets with destination IP address of the sink EPG's virtual IP address and destination port equal to 80 to pass through. A separate policy box may also have been created for the same.
- the LB policy box 750-2 modifies the packets' destination IP address from the sink EPG's virtual IP address to the real IP addresses of machines belonging to the sink EPG.
- the example EPGs 730 from the network policy graphs 700 and 705 have the following relationships.
- Source EPGs 730-1 and 730-2: Internet Internet.
- the overlap in both source EPGs 730 and sink EPGs 735 can mean that both paths can be merged (e.g., policy boxes 750 from both graphs 700 and 705 can be placed in a single path).
- the ordering of policy boxes 750 is important. An improper order of policy boxes 750 may fail to comply with the goals of the policy graph sources 120.
- the policy graph composer can systematically analyze the policy boxes. [0084] To determine the overall ordering of policy boxes 750 from two network policy graphs, the policy graph composer 120 can perform a pairwise analysis of each pair of policy boxes - one from either graph. The outcome of the pairwise analysis of two policy boxes can provide a suggestion for an initial ordering between them. It also reveals any policy conflicts and the implications of the suggested order.
- users can declare some EPGs or EPG-to-EPG paths as 'exclusive' to prevent policies written for such EPGs or EPG pairs from being altered by other policies during the
- a designation of an exclusive EPG can indicate that no more edges be added or connected to a particular EPG node.
- a designation of an exclusive path can indicate that the path may not be merged with any other path.
- each policy box written in a high-level programming language such as Pyretic can be converted into a prioritized set of match-actions rules.
- a rule can include a match filter that defines the protocol fields and values used to distill the packets that can be evaluated by this rule and a set of actions that are to be performed on those packets.
- Input Packet Space (IPS) can be defined at a rule as the finite set of all packets that are available at the rule to be evaluated by its match filter. IPS can be governed by the various higher priority rules belonging to the same policy and the match filters used by them.
- the match filters themselves create a Match Space (MS) which is the set of all packets that match on the filter parameters.
- MS Match Space
- EMS Effective Match Space
- OPS Output Packet Space
- the conversion procedure from a policy to one or more rules can be illustrated using the ACL policy box 750-1 as an example.
- the policy specified in the ACL policy box 750-1 may be to execute two rules in sequence.
- the first rule, Rule 1 may drop every packet that does not have a destination IP address equal to the Web tier EPG's virtual IP address.
- Rule 2 may drop every packet that does not have the destination port field set to 80.
- the two filters directly map to the two rules:
- the action part of the filter rules indicates that the only action to be performed by this rule is to simply allow the packets to pass-through. Since the rules have the same action and the match filters are anchored on different fields, the two are combined into a single rule as:
- the ACL policy may further imply that any packet not matching the two filters should be dropped, as expressed by the lower priority rule:
- the match filter is set to "identity" which indicates all packets. Since higher priority rule already matches the packets with destination IP address of Web tier EPG's virtual IP address and destination port of 80, the identity here effectively matches the packets that were not matched by the higher priority rule.
- R ACL i and R ACL 2 for the ACL policy box 750-1 :
- the policy boxes 750-2 and 750-3 of the network policy graphs 700 and 705 of FIG. 7 are represented as example match-action rules.
- Byte Counter policy box 750-3 can be represented by rules rule R BC i and rule R BC 2 , where rule R BC i can be defined as:
- R BC 2 can be defined as:
- rule R LB i can be defined as:
- R LB 2 can be defined as:
- the policy graph composer can analyze the rules to characterize how they might behave under operating conditions. To illustrate the analysis, example policy boxes, P a and P b , are considered. Analysis of the constituent rules of can determine how the policy boxes P a and P b handle any given packet. Each rule in P a can be compared with each rule in P b to identify the existence of dependency,conflict, and redundant type relationships. [00110] A dependency exists from one rule to another if the former rule's actions creates a packet space that is fully or partially matched by the latter rule.
- rule R a from P a conflicts with rule Rb from P b , if the pre-condition EMS(R a ) overlaps with EMS(R b ) is true, and the actions of R a and R b are conflicting.
- dependencies can be checked first. Conflicts may be checked only if a dependency relationship is not found between the two rules.
- the output from the rule analysis stage can be analyzed to provide the final suggestions for policy boxes order and/or user alerts for any implications (e.g., conflicts, dependencies, etc.) of the suggested order.
- Such analysis can include analysis of the individual relationships identified among the rules of the policy boxes to generate the suggested orders and the corresponding implications.
- the policy graph composer 120 or the conflict checker component 550, can assign scores to the different relationships based on how the precondition of the relationship was satisfied. If the pre-condition was satisfied with an exact match of the participating packet spaces, the corresponding relationship is assigned a high score. On the other hand, if the pre-condition was satisfied due to the presence of a low priority identity rule, the
- Intermediate scores can be assigned based on the number of protocol fields that have the same value across the two participating packet spaces with the score being higher for higher number of matching fields.
- policy graph composer 120 or the conflict checker component 550, can check for any 'dependency' relationship among the list of relationships provided as input.
- the policy box with the rule that is dependent on the other rule is placed after the policy box containing the other rule. If there are multiple dependency relations with the highest weight and all of them mutually agree upon the placement of the policy box with respect to the other policy boxes, the corresponding order is used. Mutual agreement is reached when the placement of the policy box does not violate its dependency relation with any other policy box in the graph. If there are multiple dependency relations with the highest weight and there is a dispute about the ordering between them, then no suggestion can be made by the analyzer. The analyzer thus proceeds to compute all possible orders and indicate the implications of each order.
- the policy graph composer 120 or the conflict checker component 550, computes the different possible orderings and provides the implications for each order. To gather implications, the analyzer simply places the policy boxes in the determined order and checks the relations if they still hold at the new order.
- the suggested order between two policy boxes, from one or more dependency relations, tells only the relative order between the two and may not tell the absolute placements of them in the final merged path having all policy boxes from the two original paths.
- a dependency graph can be constructed in which the two policy boxes with a 'dependency' relationship are connected via a directed edge: the box creating packet space is a parent node and the other box consuming (matching) the packet space is a child node.
- the directed edges in the two original paths also exist in the dependency graph.
- Topological sorting of the policy boxes can be performed to determine the final sequence of policy boxes for the merged path.
- a dependency graph may have many valid topological sorts. The sort with the higher-weight dependency boxes more closely placed can be chosen. Topological sorting can find a valid sequence only for a directed acyclic graph (DAG).
- DAG directed acyclic graph
- operator graph 705 can have a security firewall (FW) policy box (not shown) instead of Byte Counter policy box 750-3 and the FW box blocks DDoS attack traffic from the Internet to All Tenants 735-2.
- FW security firewall
- ACL policy box 750- 1 and LB policy box 750-2 all belong to a sub-domain (Tenant 1 ) of the All Tenants domain of the Operator graph705
- the ACL policy box 750-1 and LB policy box 750-2 can be placed after the resulting FW box in the composite graph so that the FW box can operate on the traffic flowing towards the Tenant 1 domain including the ACL and LB boxes.
- the analysis on the policy box chain can also detect possible human or systems errors without composing the composite policy graph.
- each the policy box chain and/or each individual policy graph can be analyzed to detect errors before or after the composite policy graph is composed. Analysis of any detected errors can inform the policy graph composer 1 10 or a user as to how the errors can be corrected, either manually or automatically. For example, if ACL policy box 750-1 is
- the output to the user can be a composite network policy graph along with its implications.
- Operator graph 700 and tenant graph 705 herein there is a single suggested composite network graph 800 provided.
- more than one suggestion may be provided accompanied by corresponding implications.
- the users can then select one of the provided suggestions by considering the implications of the conflicts that may arise. If none of the suggestions reflects the appropriate goal, the user can then take actions such as tightening the EPG set definitions, revising the graphs or concretizing/fixing policy box internal behaviors and resubmitting the graphs for composition. The procedure repeats until the user is satisfied and validates a provided suggestion.
- the policies from the composite graphs can be compiled into switch rules and applied to the physical topology.
- the rules are compiled for any existing endpoints that are already members of the EPGs. New rules are added when new endpoints join EPGs. Endpoints may also change their membership by leaving one EPG and joining another or obtaining
- examples disclosed herein enable network operators to implement or program a network using multiple controller modules that may have disparate policies and objectives regarding the configuration of the topology of the network.
- Conflicts between the policies and objectives, as represented by the differences in the resource allocation proposals, can be resolved using various election based decision
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
Example implementations disclosed herein can be used to generate composite network policy graphs based on multiple network policy graphs input by network users that may have different goals for the network. The resulting composite network policy graph can be used to program a network so that it meets the requirements necessary to achieve the goals of at least some of the network users. In one example implementation, a method can include receiving multiple network policy graphs, generating composite endpoint groups based on relationships between endpoint groups and policy graph sources, generating composite paths based on the relationships between the endpoints and the network policy graphs, generating a composite network policy graph based on the composite endpoint groups and the composite paths, and analyzing the composite network policy graph to determine conflicts or errors.
Description
NETWORK POLICY GRAPHS
BACKGROUND
[0001] Software-defined networking (SDN) is a technique for implementing computer networking environments using software to control the configuration and allocation of networking hardware resources in the network. In such networks, the hardware (e.g., routers, switches, server, etc.) or virtual network and compute resources (e.g., virtual L2/L3 networks, virtual machines) can be programmed to allocate networking and computing resources according to the goals or policies of users such as operators, service providers, application developers, tenants, and other users.
BRIEF DESCRIPTION OF THE DRAWINGS
[0002] FIG. 1 is a schematic system diagram according to various examples of the present disclosure.
[0003] FIG. 2 illustrates example network policy graphs.
[0004] FIG. 3 illustrates example policy graph sources and corresponding network policy graphs.
[0005] FIG. 4 illustrates a data flow of network policy graphs into a policy graph composer to generate a composite policy graph, according to various examples of the present disclosure.
[0006] FIG. 5 depicts an example policy graph composer.
[0007] FIG. 6 is a flowchart of a method for generating composite network policy graphs, according to examples of the present disclosure.
[0008] FIG. 7 depicts two example network policy graphs associated with specific SDN entities.
[0009] FIG. 8 depicts an example composite network policy graph.
DETAILED DESCRIPTION
[0010] Software defined networking (SDN) provides network operators and other users with the ability to configure networking and computing resources flexibly and dynamically. In some implementations, the specific configuration
of a network topology can be controlled by a network controller that implements various policies by programing the network hardware with specific rules. The policies or the rules can be expressed in one or more high-level or low-level network programming languages.
[0011] Examples of the present disclosure include a policy graph abstraction (PGA) that provides an intuitive visual methodology for defining network policies and improves the design and implementation processes of network programs. The PGA described herein includes a graph model and declarative language to specify complex policies and that can be used to generate corresponding network programs to support the goals of multiple SDN users without requiring information about or changes to the physical topology, the subnet, the VLAN, or any of the endpoint IP/MAC addresses in the network. Various examples of the PGA also enable semi-automatic composition of modular sub-graphs written by different types of SDN users, such as operators, tenants, SDN developers, and the like.
[0012] While conventional SDN enables the various SDN users to program the network, such systems require knowledge of and proficiency in various control application programming interface (APIs) and programming languages. Existing control APIs, such as OpenFlow, are designed to program low-level rule tables of individual network devices. Accordingly, such APIs are not well suited for programming the whole network as a single system.
[0013] Examples of the PGA in the present disclosure include a high-level API that can support simplified specification of user goals, expressed as network policies and network invariants, which can be used as intuitive expressions in a corresponding networking programming language. Other examples can also detect and resolve conflicts within a policy and between policies. The policies can be combined to create more complex composite policies so that the various users of the network need only be concerned with their own goals and policies.
[0014] In yet other examples, as described above, the API can include a policy graph composer to support various types of SDN users, such as SDN
solution providers, enterprise ITs, cloud operators, tenants, application owners, SDN server/application developers, and the like, with various levels of flexibility and simplicity for programming a network.
[0015] In the following detailed description of the present disclosure, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration how examples of the disclosure can be practiced. These examples are described in sufficient detail to enable those of ordinary skill in the art to practice the examples of this disclosure, and it is to be understood that other examples can be utilized and that process, electrical, physical network, virtual network, and/or organizational changes can be made without departing from the scope of the present disclosure.
[0016] FIG. 1 illustrates a system 100 for programming and controlling a network 160, in accordance with various examples. The system 100 can include permanent or temporary connections to multiple policy graph sources 120. As used herein, the term "policy graph source" can be used
interchangeably with the term "user" to refer to any SDN entity described herein (e.g., operators, service providers, etc.).
[0017] Each of the policy graph sources 120 can be connected to, or otherwise access, the policy graph composer 1 10. Using functionality provided by the policy graph composer 1 10, each of the policy graph sources 120 can design network policy graphs specific to its own corresponding goals. In some examples, the functionality provided by the policy graph composer 1 10 can include a graphical user interface with drag-and-drop features for selecting and designing visual representations of the graphs depicted in some of the accompanying drawings. In other examples, the functionality of the policy graph composer 1 10 can include a library, and/or an API for accessing a library, of previously designed network policy graphs. The API can also be used to create a new graph, or new graph components (nodes and path polices). In various examples of the present disclosure, the policy graph composer 1 10 can analyze the network policy graphs input by the various policy graph sources 120 to compose a composite network policy graph. The policy graph composer 1 10 can then convert the composite network policy
graph to generate commands, or other control signals, that can be sent to the network controller 130.
[0018] The network controller 130, in response to the commands received from the policy graph composer 1 10, can program the various components of the network 160. As shown, network 160 can include multiple switches 140 and computing resources 150 connected to and in electronic communication with one another using various electronic communication media and protocols. As used herein, the term "switch" refers to any networking hardware that can be used to route data from one endpoint to another. Each computing resource 150 can include any type of function specific or general purpose computing hardware. Accordingly, as used herein, the term
"computing resource" can refer to any computing device, such as a server computer, capable of instantiating applications, virtual machines (VMs), and other executable code. Similarly, the policy graph sources 120 and/or their corresponding input, the policy graph composer 1 10, and/or the network controller 130 can be implemented in any one or more of the computing resources 150 or other computing resource not shown.
[0019] In various example implementations, the policy graph sources 120, the policy graph composer 1 10, and/or the network controller 130 can be implemented as any combination of software, firmware, and hardware in a single or in multiple physical or virtual computer systems. In some examples, the software or firmware can be implemented as computer executable instructions stored on a non-transitory computer readable medium. Various examples of the present disclosure can be implemented or instantiated in one or more computer systems by executing the computer executable instructions in one or more computer processors. For example, the policy graph sources 120, the policy graph composer 1 10, and/or the network controller 130 can be instantiated in any of the computing resources 150 or in another computer system (not shown) coupled to the network 160.
[0020] FIG. 2 illustrates several example network policy graphs 220 depicted using example implementations of the PGA model described herein. As shown, each one of the policy network graphs 220 can include at least one endpoint group (EPG) 230 connected to another EPG 230 by a path 240. The
EPGs 230 are sometimes referred to as EPG nodes, and the paths 240 are sometimes referred to as edges. Such terminology is consistent with conventional description of graphs. In some examples, the EPGs 230 are connected to one or more other EPGs through paths 240 and/or a policy box 250. As depicted, each network policy graph 220 can be placed in or associated with a ranking or hierarchy expressed by the boundaries 205. A specific example organization of the hierarchy is described herein in reference to other example implementations.
[0021] Network policy graphs 220 can be defined using the PGA as an intuitive graph model to specify policies, requirements and service logic. Each network policy graph 220 can describe a logical topology between EPGs 230 and policy boxes 250. The term "endpoint group" or "EPG" refers to a group of arbitrary addressable (e.g., IP, MAC, subnet, VLAN, etc.) endpoints or a group of EPGs 230 that can perform a common logical role or share a common property. The term "policy box" refers to the functionality, or the visual representation of the functionality, used to implement network services such as firewall, monitoring, Network Address Translation, routing, load- balancing, etc. A policy box 250 can include a composition of multiple modular policy boxes. As shown, zero or more policy boxes 250 can be placed on directional paths 240 between EPGs 230.
[0022] Various examples of the present disclosure can include a network programming language that describes the behaviors and properties of policy boxes 250. The network programming language representations of the functionality and properties of the policy boxes 250 can be useful for detecting potential dependencies and conflicts among the network policy graphs 220 and for generating composite network policy graphs. In such implementations, the policy graph composer 1 10 can analyze component network policy graphs 220 that may be combined into the resulting composite network policy graph.
[0023] The policy graph composer 1 10 can detect policy conflicts and dependencies between the graphs 220 and automatically compose the graphs 220 into one complex network policy graph that satisfies the invariants specified in each individual network policy graph. The analysis of the conflicts and the composition of the composite network policy graphs can include
analysis of the relationships (e.g., conflicts, dependencies, impacts, etc.) between policy boxes 250 of the network policy graphs 220 to be combined together on the same path in the composite network policy graph. The relationships can be used to automatically determine the right placement and order of the policy boxes 250 in the composite network policy graph and some of the relationships (e.g., conflicts) can be reported to users for attention or correction. In some examples, the policy graph composer can use the set relationships between EPGs and the domain relationships between EPGs and policy boxes to derive the order of the policy boxes requested by different policy graph sources.
[0024] In some example implementations, the PGA can consider a hierarchy of policy graph domains, as the domain separations are depicted as boundaries 205. Each network policy graph 220 can be associated with or originate from a corresponding policy graph source 120, as shown in FIG. 3. As depicted in FIG. 3, the network policy graph 220-1 is associated with the policy graph source 1 120-1 (e.g., an operator), while network policy graph 220-2 is associated with the policy graph source 2 120-2 (e.g. a tenant), network policy graph 220-3 is associated with the policy graph source 3 120-3 (e.g. an application developer), and network policy graph 220-4 is associated with the policy graph source 4 120-4 (e.g. a solution provider). Based on the associations between the network policy graph 220 and the corresponding policy graph source 120, the network policy graphs 220 may be processed or analyzed differently for composition into a composite network policy graph.
[0025] For example, a tenant of the network 160 can create network policy graphs in the tenant domain. The tenant may be an enterprise with various departments and each department can create graphs in
corresponding departmental domains. The departments may in turn have multiple sub-departments and each of the sub-departments can create graphs in corresponding domains. Accordingly, in the hierarchy relationships among the domains in the graph domains, the tenant domain can be considered the parent of the departmental domains, which can in turn be considered the parents of sub-departmental domains, and so on.
[0026] In various example implementations of the present disclosure, the PGA can include directed network policy graphs 220 that can include EPG 230 nodes and/or policy box 250 nodes. Such directed network policy graphs 220 include indications of data flow directions between the nodes.
[0027] As described herein, circular/oval-shaped vertices represents EPGs 230 and can include any group of arbitrary addressable endpoints or a group of endpoints that perform a common logical role or share a common property. A user can create an EPG to represent a logical role without real endpoint identifiers. Endpoint identifiers such as IP, MAC, subnet, VLAN addresses can be given later through 'late-binding'. For example, an EPG 230 can represent a user-defined application component (e.g., web or database server, Lync server) or dynamic membership (e.g., current guest devices, Lync VoIP session, security-quarantined clients).
[0028] An EPG 230 can have mandatory and optional parameters. For example, service port numbers, Virtual Machine (VM) type, auto-scaling option, fault-tolerance level, IP ranges, etc. In some implementations, EPGs 230 in a graph do not have overlap by default, i.e., the intersection of any EPG pair is empty (no common endpoint). If EPGs 230 do overlap, their set relationship must be specified. For instance, an EPG A is a subset of an EPG B, or a tenant EPG is the union of web and database EPGs. The set relationships, including 'no overlap', can allow the system to analyze a graph and to compose multiple graphs, without requiring real endpoint identifiers to be given.
[0029] Various example implementations can include a 'shadow' EPG that can be defined in suitable scenarios, such as in a security service that defines two EPGs 230 as "normal hosts" and "quarantined hosts" and that maintains separate policies for each. When such a security service graph is combined with any other graph, the user can define a 'shadow' EPG 230 that can include both normal host EPGs and quarantined host EPGs and the shadow EPG may be composed with EPGs in the other graph, thus triggering composition of the composite graph.
[0030] The rectangular-shaped policy box 250 vertices can represent implementations of network services such as, but not limited to, load- balancing, firewalls, traffic engineering, billing, etc. In some implementations, a policy box 250 can be a minimal unit of service chaining and graph composition. Multiple policy boxes 250 can be chained together for service chainning. But during the composition of multiple network policy graphs 220, a chain of policy boxes 250 from one network policy graph 220 can be disconnected. The disconnected boxes can form a new chain in the composite network policy graph 220 together with other policy boxes 250 from other network policy graphs 220.
[0031 ] Extension of Network Programming Languages
[0032] In some example implementations, a policy box 250 can represent an abstract 'function' that takes a packet as input and returns a set of zero or more packets. In such implementations, a network programming language can be used to describe the function, behaviors, and properties, which can be used for conflict detection, resolution, graph composition and rule compilation. In various implementations, the Pyretic network programming language can be used. Pyretic is switch-centric and can use real IP/MAC addresses to implement network programs. Pyretic can be extended to write
programs/policies regarding logical EPG parameters (e.g., 'web.ip' to indicate IP addresses of web EPG), before the actual IP addresses of web endpoints can be available.
[0033] Extended Pyretic can include extensions to the language that can be useful for PGA. Extended Pyretic can support "gray boxing", that can capture high-order behavior of a proprietary black box or a network policy box 250 running dynamic policies.
[0034] Dynamic policies have behavior that changes over time, according to the programmer's specification of an arbitrary internal state machine, which is difficult to analyze offline before deploying the program to the operational network. For example, a server load-balancing policy box 250 may select the destination server IP for a new client request in a round-robin manner or based on any per-server state information. An exact mapping between a client
request to a specific server and the server becomes known only in run-time. Gray-boxing lets the user (load-balancing policy box 250 writer or an operator using the policy box 250) to specify the mapping behavior at a high-level without considering the actual mappings. For example:
match('dstip', web.virtualjp) » modify('dstip', web.realjp}
[0035] In the above statement, web.virtualjp is the virtual IP address used by clients to send requests to and web.realjp is the set of real IP addresses of web server endpoints registered to the web EPG 230 at any given time. By using the set of real IPs, it is possible to capture the useful information that the destination IP of a client request message will be rewritten to one of the web server IPs. Examples of the present disclosure can use this high-order information for conflict detection and automatic graph composition, as described herein.
[0036] Like gray boxing a dynamic policy, gray boxing can be useful to capture the high-level behavior of proprietary middle box applications, which can be black boxed (e.g., the exact internal behaviors are unknown). For example, a DPI-based Intrusion Prevention System (IPS) policy box can drop certain packets based on packet payloads or any proprietary algorithm for detecting DDOS attack. According to various implementations, a user can provide a gray-box version of the IPS box as the statement:
select(drop, identity)
[0037] In such statements, identity is the Pyretic action for 'allow', and select(A1 , A2...) indicates that one of the specified actions (A1 , A2 ...) is selected, with its selection logic unknown, and applied to its input packet. The select()in extended Pyretic can support gray-boxing. If it is known that the IPS box will block some endpoints from the 'client' EPG, its gray-box can be represented by:
match('srcip', client.ip) » select(drop, identity)
[0038] In this statement, client.ip indicates the set of IP addresses of client EPG.
[0039] Examples of the present disclosure can be implemented as a policy graph composer 1 10 in an SDN system 100, as depicted in FIG. 1 . FIG. 5 illustrates one example implementation of the policy graph composer 1 10. In particular, FIG. 5 illustrates the various components of the policy graph composer 1 10 and the relative dataflow to give context to the other implementations described herein. In one exmaple, the policy graph composer can include a user interface/network policy graph editor, or a user graph editor 510, that includes functionality for providing a user interface and/or an API 505 to the various users of the newtork 160. The user graph editor 510 can provide a graphical user interface that can be used to drag- and-drop component EPGs 230, paths 240, and policy boxes 250 to create network policy graphs and/or express the goals of the particular user.
[0040] In related implementations, user graph editor 510 can also include functionality for receiving or retrieving previously defined network policy graphs from the graph and policy library 525. In such implementations, the previously defined network policy graphs can be used as components of network policy graphs defined by a user using the user interface/API 505.
[0041] The policy graph composer 1 10 can also include a policy graph converter 520. The policy graph converter 520 can receive network policy graphs from the user graph editor 510 and/or individual policy graphs 515 from other sources (e.g., an external graph library or database). In various examples of the present disclosure, the process of generating a composite network policy graph can begin with the policy graph converter 520 converting multiple component network policy graphs into appropriate network programming language statements. The details of the conversion of the network policy graphs to a network programming language are discussed in more detail below.
[0042] The policy graph composer 1 10 can also include an EPG generator 530. The EPG generator 530 can include functionality for analyzing the relationships between the various EPGs 230 in the component network policy graphs. For instance, the EPG generator 530 can analyze the overlap of the EPGs 230 by determining the intersection and unions on a pairwise basis for up to all of the EPGs 230 in component network policy graphs. The EPG
generator 530, based on the analysis of the relationships between the EPGs 230, can generate, or otherwise determine, the resulting composite network policy graph.
[0043] The path generator 540 of the policy graph composer 1 10, can include functionality for determining the paths in the resulting composite network policy graph. By analyzing the relationships between the EPGs 230 and the original paths 240 and policy boxes 250 in the component network policy graphs represented in the network programming language provided by the policy graph converter 520, and the analysis performed by the EPG generator 530, the path generator 540 can determine the configuration of the paths and policy boxes in the resulting composite network policy graph.
[0044] In related implementations, the policy graph composer 1 10 can include a conflict checker 550 to verify and determine the dependencies and conflicts between the policy boxes in the resulting composite network policy graph. In the event that the conflict checker 550 detects a conflict, an error message/confirmation message can be sent to the user graph editor 510 and/or user interface/API 505 to alert a user to take corrective action. If the conflict checker 550 does not detect any conflicts, then the path generator 540, or some other component of the policy graph composer 1 10, can compose the composite network policy graph 515 and provide it to another component of the system 100, such as the network controller 130 to program the network 160.
[0045] FIG. 6 depicts a flowchart of a method 600 for generating composite network policy graphs, according to examples of the present disclosure. The method 600 can begin when the policy graph composer 1 10 receives one or more network policy graphs, at box 610. In some
implementations, receiving the network policy graphs can include converting the network policy graphs into a network programming language syntax. The conversion of network policy graphs into a network programming syntax is described in more detail below.
[0046] At box 620, the policy graph composer 1 10 can generate EPGs for the composite network policy graphs. In such implementations, the policy
graph composer 1 10 can analyze the relationships between the EPGs 230 to determine the specific EPGs to include in the resulting composite network policy graph. The details of the EPG generation are described in more detail below.
[0047] At box 630, the policy graph composer 1 10 can generate paths for the resulting composite network policy graph. The composite paths can include a combination of the paths and/or the policy boxes defined in the component network policy graphs . Additional details of path generation are described in more detail below.
[0048] At box 640, the policy graph composer 1 10 can generate a composite policy graph based on the composite EPGs and paths. Additional details are described in more detail below.
[0049] At box 650, the policy graph composer 1 10 can analyze the composite policy graph to detect or determine dependencies and conflicts among the EPGs, paths, and policy boxes of the composite policy graph. At the termination 660, if errors are complex, then the policy graph composer 1 10 can generate an error message to correct the policy graphs, at box 675. In some implementations, the error message can prompt a user to correct one or more of the input network policy graphs or to supply a new network policy graph. Once the updated or corrected network policy graph is received by the policy graph composer 1 10, boxes 610 through 660 can be repeated.
[0050] If, however, at determination 660, no conflicts or errors are detected, then the policy graph composer 1 10 can output the composite policy graph to the network controller 130. Outputting the composite network policy graph can include converting the composite network policy graph into a network programming language. The network controller 130 can then use the composite network policy graph to program the network 160.
[0051] Additional illustrative examples and details of EPGs 230, network policy graphs, and the functions and actions represented by the boxes in FIG. 6 are discussed below.
[0052] Endpoint Groups and Network Policy Graphs
[0053] An EPG 230 in a network policy graph 220 can be classified as a source or sink of network traffic while a policy box 250 neither creates nor consumes traffic by itself, such as, for example, the source EPG 730 and sink EPG 735 in FIG. 7.
[0054] The EPGs and policy boxes nodes in a graph can be connected through directed edges, forming directed paths. A directed 'path' is defined between a source EPG and a sink EPG. A path starts from the source EPG 230, traverses zero or more policy boxes 250 and ends at the sink EPG 230. A cycle is allowed, for example, when a web EPG sends to a database EPG through a policy box A while the reverse traffic from DB to web EPG is traversing policy boxes B and C. An EPG 230 may have a self-loop path representing traffic among endpoints of that EPG, e.g., synchronization between database server (DB) VMs.
[0055] In some implementations, no communication is allowed between vertices, by default (e.g., default 'deny' rule). A solid directed edge 240 can enable communication as specified by filter attributes on the edge classifier, e.g., label 'UDP, dstport 53' allows only UDP traffic with destination port number 53 on that edge, thus implementing security whitelisting. Another default security measure can include a rule that an outgoing edge from a source EPG 230 constrains the source IP addresses allowed on that edge 240 only to the IPs of the source EPG 230 endpoints. An incoming edge 240 to a sink EPG 230 can also limit the dst IP to the sink EPG 230 endpoints' IPs. Such default srclP/dstIP constraints may not be applied to an EPG 230 with L3 forwarding, such as virtual router. By default, a security attribute can be stateful, such that responses to allowed TCP traffic in the direction of the edge can be allowed in the reverse direction as well.
[0056] A chain of solid edges 240 connecting a source EPG 230, through a set of policy boxes 250, to a sink EPG 230 is called a 'solid path'. A solid path has two implications. Firstly, the solid path can include security whitelisting as described above. Secondly, the solid path can include a path requirement meaning that the allowed communication from the source to the sink must traverse the policy boxes on that path.
[0057] Some users, such as network operators, may want to impose only the path requirement without explicitly allowing any communication. A 'dotted path' in a network policy graph 220 connecting a source EPG to a sink EPG, represents such a path requirement without whitelisting. Such path requirements (e.g., dotted paths in an operator graph) can be activated when combined with solid paths of other network policy graphs 220 (e.g., tenant graphs).
[0058] Conversion of Network Policy Graphs
[0059] As described herein, multiple network policy graphs 220 can be input into the policy graph composer 1 10, as depicted in FIG. 4 and described in reference to FIGS. 5 and 6. The policy graph composer 1 10 can analyze the various aspects and properties of each of the input network policy graphs 220 to compose and generate a composite network policy graph 320. In some example implementations, to generate a composite network policy graph, the policy graph composer 1 10 can first convert the component network policy graphs 220 into a high-level network programming language, such as Pyretic or extended Pyretic, described herein.
[0060] The behavior of the sequential composition ('»') operator in Pyretic is to pass all the packets output from one Pyretic policy to the next Pyretic policy in sequence. In various implementations, all of the output packets of one policy box 250 can be input to the next policy box 250 in the path 240. The sequential composition operator can be used to express a solid edge from the graph. A new policy box 250 can be created to capture the whitelisting parameters provided as edge classifiers on the solid edge and added to the path 240. A source EPG, the policy boxes 250 and a sink EPG can be mapped into policy objects. The sequential composition operator can be added between each successive pair of policy objects.
[0061] For path requirement graphs, the '>' in extended Pyretic can be used. The conversion procedure is similar. The source EPG, the policy boxes 250, and the sink EPG can be mapped into policy objects with the path requirement operator connecting them.
[0062] In one example, the solid line graph 700 in FIG. 7 can be expressed in extended Pyretic as:
Internet » ACL » LB » Web tier
[0063] The path requirement graph 705 from FIG. 7 can be expressed as:
Internet > Byte Counter > All tenants
[0064] Automatic analysis and composition can be improved based on knowledge of user goals for a policy box 750. Accordingly, users can explicitly specify 'match' filters or 'identity' in conjunction with any kind of action being performed.
[0065] Example Composition of Composite Network Policy Graphs
[0066] The policy graph composer 1 10 can initiate composite network policy composition under various circumstances. For example, composite network policy graph composition can be triggered whenever a new network policy graph 220 is created or an existing graph is updated at any level of a graph hierarchy. For example, the method 600 of FIG. 6 can be initiated whenever a trigger is detected.
[0067] The network policy graph created or updated can be automatically combined with the graphs below and above in the hierarchy by determining the EPG relationships, as described herein. Graph composition can also be triggered by a simple drag-and-drop GUI action that triggers merging of a service/status EPG (e.g., security-contaminated vs. security-clean) and a tenant/network EPG. In such scenarios, the security service graph and the graph containing the tenant/network EPG can be combined.
[0068] One example can include the combination of two network policy graph Gi and G2, such as 700 and 705. In similar examples, the combination composition of three or more network policy graphs can be achieved by repeating the two-graph composition, described herein.
[0069] The combination of two network policy graphs, Gi and G2, can begin by identifying set relationships between EPGs from the two graphs. The EPGs from the same graph may not overlap, as described herein. The relationships between EPGs across network policy graphs G1 and G2 can be
derived by the graph/EPG hierarchy, accessed or determined by the policy graph composer 1 10 or by one of the policy graphs sources 120. The policy graph composer 1 10 may require the policy graphs sources 120 to provide the EPG set relationships at the time of composition.
[0070] In scenarios in which there is no overlap between any pair of EPGs, one from network policy Gi and the other from network policy G2, the two network policy graphs can co-exist without any conflict or interaction on the logical topology. In such implementations, all vertices and edges from network policy G1 and network policy G2 can be copied directly to the final composition network policy graph G3 as they are. This is a special case of examples described below.
[0071 ] Generating EPGs for Composite Network Policy Graphs
[0072] In scenarios in which there are overlapping EPGs between the two network policy graphs, the composite network policy graph G3 can be composed by analyzing the relationships, intersections, and unions between the EPGs. In one example, all paths in both network policy graphs can be assumed to be solid, thus implying both security whitelisting and path requirement.
[0073] To create the composite network policy graph G3 the existing EPGs in the network policy graph can be split. When two EPGs, E1 from Gi and E2 from G2 overlap (E1 nE2 != 0), The union, E1 u E2 can be into one, two or three resulting EPGs based on the Venn diagram between E1 and E2. The resulting EPGs can be assigned to G3.
[0074] There are four possible Venn diagram relationships between E1 and E2. (1 ) E1 == E2: G3 will have only one EPG E1 (=E2), from E1 and E2; (2) E1 c E2: G3 will have two resulting EPGs, E1 and E2 - E1 ; (3) E1 _D E2: G3 will have two resulting EPGs, E1 - E2 and E2, and (4) E1 and E2 partially overlap: G3 will have three EPGs: E1 - E2, E1 n E2 and E2 - E1 .
[0075] The EPGs appearing only in either G1 or G2, thus having no overlapping EPG in the other graph, can be copied directly to G3. In some examples, once the new EPGs are created from the splitting process, the
paths for the composite network policy graph can be created as described herein.
[0076] Path Generation
[0077] Generating the paths between the EPGs created in G3 can define an EPG X in G3 as either 'mixed' (X = E1 n E2) or 'pure' (X = E1 - E2, E2 - E1 , or a direct copy of non-overlapping EPG). A directed path from EPG X to EPG Y (X->Y) is added to G3 in one of the following scenarios.
[0078] In one scenario, both X and Y are 'pure' EPGs, in that case, X (Y) appears only in G1 or G2, but not in both. X->Y is added to G3 if X and Y appeared in the same graph (either G1 or G2) and the communication specified by the path X->Y is allowed in the original graph (Gi or G2). X->Y has the same intermediate policy boxes specified in the original path allowing the communication.
[0079] In another scenario, X is pure and Y is mixed. X appears in only G1 or G2 and Y appeared in both G1 and G2. In this scenario, if G3 is composed by the AND operator, X->Y is not added at all. X->Y is added only if G3 is composed by OR operator (i.e., G3 = Gi | G2) and the communication specified by the path is allowed in either Gi or G2. X->Y has the same intermediate policy boxes specified in the original path allowing the communication.
[0080] In yet another scenario, both X and Y are mixed. X and Y appeared in both G1 and G2. In this case, X->Y is added only if the communication specified by the path is allowed in both Gi and G2. In other words, by denoting X = S1 nS2 and Y = D1 nD2 (S1/D1 in G1 and S2/D2 in G2), X^Y is added only if S1 -»D1 exists in G1 and S2^D2 exists in G2. By denoting B1 as the sequence of policy boxes on S1 ->D1 and B2 as the sequence of policy boxes on S2->D2, the path X->Y will have the union of B1 and B2 as a result of the 'path merging' logic, described herein. Note that it is not required to differentiate between AND vs. OR operators when both X and Y are 'pure' EPGs or when both X and Y are mixed.
[0081] When composing multiple graphs into one, the path between the overlapping parts of source EPGs and the overlapping parts of sink EPGs can
include all the network policy boxes from the constituent graphs. However, automatically merging policy boxes from different graphs onto a single one can be challenging because an improper ordering of policy boxes can lead to the violation of invariants of any of the individual network policy graphs.
[0082] Path merging can be achieved using two simple graphs as shown in FIG. 7. For example, the goal of the policy graph source that authored network policy graph 705 is to count the number of bytes coming from the Internet to each machine of every tenant. This is specified in network policy graph 705 by creating a Byte Counter policy box 750-3. Internet EPG 730-2 and All Tenants EPG 735-2 are the source and sink EPGs respectively in the network policy graph 705. The tenant network policy graph 700 includes the Internet EPG and Web tier EPGs and policy boxes ACL 750-1 and LB 750-2. The ACL policy box 750-1 only allows packets with destination IP address of the sink EPG's virtual IP address and destination port equal to 80 to pass through. A separate policy box may also have been created for the same. The LB policy box 750-2 modifies the packets' destination IP address from the sink EPG's virtual IP address to the real IP addresses of machines belonging to the sink EPG.
[0083] The example EPGs 730 from the network policy graphs 700 and 705 have the following relationships. Source EPGs 730-1 and 730-2: Internet = Internet. Sink EPGs 735-1 and 735-2: All tenants _D Web tier. The overlap in both source EPGs 730 and sink EPGs 735 can mean that both paths can be merged (e.g., policy boxes 750 from both graphs 700 and 705 can be placed in a single path). The ordering of policy boxes 750 is important. An improper order of policy boxes 750 may fail to comply with the goals of the policy graph sources 120. For example, if the Byte Counter policy box 750-3 is placed before LB policy box 750-2 after path merging, it would count bytes by the virtual IP Address of the Web Tier EPG 735-1 . Such a result would not comply with the goals of the policy source 120's goals (e.g., to count bytes by the tenant's machines' real IP Addresses). To determine the correct order of the policy boxes 750, the policy graph composer can systematically analyze the policy boxes.
[0084] To determine the overall ordering of policy boxes 750 from two network policy graphs, the policy graph composer 120 can perform a pairwise analysis of each pair of policy boxes - one from either graph. The outcome of the pairwise analysis of two policy boxes can provide a suggestion for an initial ordering between them. It also reveals any policy conflicts and the implications of the suggested order.
[0085] In some example implementations, users can declare some EPGs or EPG-to-EPG paths as 'exclusive' to prevent policies written for such EPGs or EPG pairs from being altered by other policies during the
composition/merging process. For example, a designation of an exclusive EPG can indicate that no more edges be added or connected to a particular EPG node. A designation of an exclusive path can indicate that the path may not be merged with any other path.
[0086] Expressing Policy Boxes as Match-Actions Rules
[0087] For the pairwise analysis, each policy box written in a high-level programming language such as Pyretic can be converted into a prioritized set of match-actions rules. A rule can include a match filter that defines the protocol fields and values used to distill the packets that can be evaluated by this rule and a set of actions that are to be performed on those packets. Input Packet Space (IPS) can be defined at a rule as the finite set of all packets that are available at the rule to be evaluated by its match filter. IPS can be governed by the various higher priority rules belonging to the same policy and the match filters used by them. The match filters themselves create a Match Space (MS) which is the set of all packets that match on the filter parameters. The intersection of the IPS at a rule and its MS gives the Effective Match Space (EMS) which is the set of all packets that the actions of the rule are performed upon. Finally, the Output Packet Space (OPS) is the set of all packets output from the rule after performing all the actions.
[0088] The logic for conversion of policies to match-actions rules is borrowed from Pyretic with some modifications. The modifications being a more precise representation of some of the actions like count_bytes, count_packets which are all generically represented by the FwdBucket action
in Pyretic. Note that the Byte Counter's match filter contains the value web.realjp rather than all_tenants.real_ip. This is because, the purpose of the analysis is to determine the composite path for the overlapping parts of the EPGs of the two graphs. In this case the overlap is only on the sink EPG and the overlapping part is the entire Web tier EPG itself. Thus, references to All tenants EPG in the operator graph rules can be replaced with Web tier EPG.
[0089] Expressing the policies in terms of simple [match->action] rules abstracts away the complexities of the programming language syntax and provides insight on how different packets can be handled by a policy. This renders it ideal for comparing the behaviors of two different policies and determining their relationship.
[0090] The conversion procedure from a policy to one or more rules can be illustrated using the ACL policy box 750-1 as an example. The policy specified in the ACL policy box 750-1 may be to execute two rules in sequence. For example, the first rule, Rule 1 , may drop every packet that does not have a destination IP address equal to the Web tier EPG's virtual IP address. The second rule, Rule 2, may drop every packet that does not have the destination port field set to 80. The two filters directly map to the two rules:
[0091] Rule 1 as match: ('dstip', web.virtualjp) -> set([identity]) and
[0092] Rule 2 as match: ('dstport', 80) -» set([identity])
[0093] The action part of the filter rules, (i.e., set([identity])), indicates that the only action to be performed by this rule is to simply allow the packets to pass-through. Since the rules have the same action and the match filters are anchored on different fields, the two are combined into a single rule as:
[0094] match: ('dstip', web.virtualjp) & ('dstport', 80) -» set([identity])
[0095] The ACL policy may further imply that any packet not matching the two filters should be dropped, as expressed by the lower priority rule:
[0096] identity set(Q)
[0097] In this rule, the match filter is set to "identity" which indicates all packets. Since higher priority rule already matches the packets with
destination IP address of Web tier EPG's virtual IP address and destination port of 80, the identity here effectively matches the packets that were not matched by the higher priority rule. Thus, we have the following prioritized rules RACLi and RACL 2 for the ACL policy box 750-1 :
[0098] RACLi - match: ('dstip', web.virtual_ip) & ('dstport', 80)
set([identity])
[0099] RACL2 - identity set([])
[00100] To further illustrate the abstraction of the policies as rules, the policy boxes 750-2 and 750-3 of the network policy graphs 700 and 705 of FIG. 7 are represented as example match-action rules. For example, Byte Counter policy box 750-3 can be represented by rules rule RBCi and rule RBC 2, where rule RBCi can be defined as:
[00101] match:('dstip', web.realjp) -> action:set([count_bytes: {'group_by': ['dstip']}]), and
[00102] RBC2 can be defined as:
[00103] identity -» set(Q).
[00104] For LB policy box 750-2 represented by rules RLBi and RLB 2, rule RLBi can be defined as:
[00105] match: ('dstip', web.virtualj'p) -> set([modify: ('dstip', web.realjp)]), and
[00106] RLB2 can be defined as:
[00107] identity -» set(Q).
[00108] Analyzing the Rules for Dependencies and Conflicts
[00109] Once the rules corresponding to the policy boxes are define, the policy graph composer can analyze the rules to characterize how they might behave under operating conditions. To illustrate the analysis, example policy boxes, Pa and Pb, are considered. Analysis of the constituent rules of can determine how the policy boxes Pa and Pb handle any given packet. Each rule in Pa can be compared with each rule in Pb to identify the existence of dependency,conflict, and redundant type relationships.
[00110] A dependency exists from one rule to another if the former rule's actions creates a packet space that is fully or partially matched by the latter rule. As such, there is a dependency from rule Ra (of Pa) to rule Rb (of Pb), if the pre-condition that OPS(Ra) overlaps with EMS(Rb) is true (i.e., OPS(Ra) n EMS(Rb) != 0), and Ra contains a modify action that creates a region overlapping with EMS(Rb).
[00111] A conflict exists if, for the same packet space, the two rules perform actions that conflict with each other. All combinations of actions are considered conflicting except the following for drop-drop, identity-identity, identity-count and count-count. Thus, rule Ra from Pa conflicts with rule Rb from Pb, if the pre-condition EMS(Ra) overlaps with EMS(Rb) is true, and the actions of Ra and Rb are conflicting. When analyzing two rules, dependencies can be checked first. Conflicts may be checked only if a dependency relationship is not found between the two rules.
[00112] A redundancy exists if, for the same packet space, the two rules perform the same action. If two boxes have redundant rules, this may mean one box is performing a subset of the other box, including the case when two boxes perform the identical set of rules. Only one of the two boxes may be chosen to be used in the merged path, for example, by choosing the box that includes a larger set of rules.
[00113] Analysis of Composite Network Policy Graphs
[00114] The output from the rule analysis stage can be analyzed to provide the final suggestions for policy boxes order and/or user alerts for any implications (e.g., conflicts, dependencies, etc.) of the suggested order. Such analysis can include analysis of the individual relationships identified among the rules of the policy boxes to generate the suggested orders and the corresponding implications.
[00115] The policy graph composer 120, or the conflict checker component 550, can assign scores to the different relationships based on how the precondition of the relationship was satisfied. If the pre-condition was satisfied with an exact match of the participating packet spaces, the corresponding relationship is assigned a high score. On the other hand, if the pre-condition
was satisfied due to the presence of a low priority identity rule, the
corresponding relationship is assigned a low score. Intermediate scores can be assigned based on the number of protocol fields that have the same value across the two participating packet spaces with the score being higher for higher number of matching fields.
[00116] The reasoning behind the score assignment logic is that more numbers of directly matching protocol fields reflect the user intention directly. Whereas a low priority identity rule, for example, is typically a by-product of other policies expressed by the user and thus they also tend to yield a larger number of conflicts.
[00117] Once the weights have been assigned to the various relationships, policy graph composer 120, or the conflict checker component 550, can check for any 'dependency' relationship among the list of relationships provided as input.
[00118] If there is a single dependency relationship with the highest weight, the policy box with the rule that is dependent on the other rule is placed after the policy box containing the other rule. If there are multiple dependency relations with the highest weight and all of them mutually agree upon the placement of the policy box with respect to the other policy boxes, the corresponding order is used. Mutual agreement is reached when the placement of the policy box does not violate its dependency relation with any other policy box in the graph. If there are multiple dependency relations with the highest weight and there is a dispute about the ordering between them, then no suggestion can be made by the analyzer. The analyzer thus proceeds to compute all possible orders and indicate the implications of each order. If there are no dependency relations in the list of relations, then the policy graph composer 120, or the conflict checker component 550, computes the different possible orderings and provides the implications for each order. To gather implications, the analyzer simply places the policy boxes in the determined order and checks the relations if they still hold at the new order.
[00119] The suggested order between two policy boxes, from one or more dependency relations, tells only the relative order between the two and may
not tell the absolute placements of them in the final merged path having all policy boxes from the two original paths.
[00120] To determine the absolute placements of all the policy boxes, a dependency graph can be constructed in which the two policy boxes with a 'dependency' relationship are connected via a directed edge: the box creating packet space is a parent node and the other box consuming (matching) the packet space is a child node. The directed edges in the two original paths also exist in the dependency graph. Topological sorting of the policy boxes can be performed to determine the final sequence of policy boxes for the merged path. A dependency graph may have many valid topological sorts. The sort with the higher-weight dependency boxes more closely placed can be chosen. Topological sorting can find a valid sequence only for a directed acyclic graph (DAG). If there is a cycle (e.g., A->B->C->A in the dependency graph), then it can be determined if the order of two boxes from an original graph (e.g., ACL and LB from the Tenant graph) can be altered by checking if the altered order generates the same behavior/invariant with the original order.
[00121] The final ordering suggestion and the corresponding implications are provided to the user. For the example of operator graph 705 and tenant graph 700, a single dependency relationship exists which also happens to be of the highest weight since the pre-condition is satisfied by an exact match of the OPS of RLBi and the EMS of RBCi . Thus the policy graph composer 120 can suggest that the Byte Counter policy box 750-3 be placed after the LB policy box 750-2. Thus, the final composite network policy graph 800 output by the policy graph composer 120 is depicted in FIG. 8 along with the implications of the suggested order for user attention. In the particular example illustrated in FIG. 8,
[00122] In addition, the hierarchical domain relationship among the policy boxes, the EPGs and the graph sources can be used to determine the order of policy boxes in the merged path. For example, operator graph 705 can have a security firewall (FW) policy box (not shown) instead of Byte Counter policy box 750-3 and the FW box blocks DDoS attack traffic from the Internet to All Tenants 735-2. Because the Web Tier EPG 735-1 , ACL policy box 750- 1 and LB policy box 750-2 all belong to a sub-domain (Tenant 1 ) of the All
Tenants domain of the Operator graph705, the ACL policy box 750-1 and LB policy box 750-2 can be placed after the resulting FW box in the composite graph so that the FW box can operate on the traffic flowing towards the Tenant 1 domain including the ACL and LB boxes.
[00123] The analysis on the policy box chain can also detect possible human or systems errors without composing the composite policy graph. In some examples, each the policy box chain and/or each individual policy graph can be analyzed to detect errors before or after the composite policy graph is composed. Analysis of any detected errors can inform the policy graph composer 1 10 or a user as to how the errors can be corrected, either manually or automatically. For example, if ACL policy box 750-1 is
misconfigured to only allow packets with destination IP address of the sink EPG's real IP address, packets directed toward the sink EPG's virtual IP address would be incorrectly dropped. An ACL rule (Ra) that drops the packets with the virtual IP address would conflict with a LB rule (Rb) that modifies the packets' destination IP address from the virtual IP address to the real IP addresses of machines belonging to the sink EPG because the two rules' EMSs overlap and their actions are conflicting. Other errors that the policy graph composer 1 10 might detect can include, but are not limited to, inadvertent loops or black holes introduced into the underlying logic of the rules or policies that correspond to the network policy graphs and/or policy boxes.
[00124] System Output to Policy Graph Sources
[00125] As illustrated in FIG. 8, the output to the user can be a composite network policy graph along with its implications. In the example of Operator graph 700 and tenant graph 705 herein, there is a single suggested composite network graph 800 provided. However, in other cases more than one suggestion may be provided accompanied by corresponding implications. The users can then select one of the provided suggestions by considering the implications of the conflicts that may arise. If none of the suggestions reflects the appropriate goal, the user can then take actions such as tightening the EPG set definitions, revising the graphs or concretizing/fixing policy box internal behaviors and resubmitting the graphs for composition. The
procedure repeats until the user is satisfied and validates a provided suggestion.
[00126] Update and Deployment to the Network
[00127] Once the user accepts a suggested composite network policy graph, the policies from the composite graphs can be compiled into switch rules and applied to the physical topology. The rules are compiled for any existing endpoints that are already members of the EPGs. New rules are added when new endpoints join EPGs. Endpoints may also change their membership by leaving one EPG and joining another or obtaining
membership in more number of EPGs dynamically. In such scenarios, the rules corresponding to the endpoint can recompiled onto the switches.
[00128] According to the foregoing, examples disclosed herein enable network operators to implement or program a network using multiple controller modules that may have disparate policies and objectives regarding the configuration of the topology of the network. Conflicts between the policies and objectives, as represented by the differences in the resource allocation proposals, can be resolved using various election based decision
mechanisms, thus allowing the network operator to realize the benefits of the policies and objectives of multiple independent controller modules.
[00129] These and other variations, modifications, additions, and
improvements may fall within the scope of the appended claims(s). As used in the description herein and throughout the claims that follow, "a", "an", and "the" includes plural references unless the context clearly dictates otherwise. Also, as used in the description herein and throughout the claims that follow, the meaning of "in" includes "in" and "on" unless the context clearly dictates otherwise.
Claims
1 . A method for configuring a network comprising:
receiving, by a processor, a plurality of network policy graphs, wherein each of the network policy graphs comprises two or more endpoint group nodes, the endpoint group nodes corresponding to one or more addressable endpoints in the network, connected by directed edges, the directed edges corresponding to directed paths in the network;
generating, by the processor, composite endpoint groups based on relationships between the endpoint groups;
generating, by the processor, composite paths based on the relationships between the endpoints and the network policy graphs;
generating, by the processor, a composite network policy graph based on the composite endpoint groups and the composite paths; and analyzing, by the processor, the composite network policy graph or the network policy graphs to determine conflicts or errors.
2. The method of claim 1 , further comprising generating a command to a controller coupled to the network to program the network according to the composite network policy graph.
3. The method of claim 1 , wherein analyzing the composite network graph to determine conflicts comprises generating an error message when a conflict is determined, the error message comprising a request to correct one or more of the plurality of network graphs.
4. The method of claim 1 , further comprising accessing a hierarchy of graph domains, and wherein generating the composite network policy graph is further based on the hierarchy of graphs.
5. The method of claim 1 , wherein generating the composite endpoint groups comprises splitting a union of two or more of the endpoint group nodes
based on set relations between the two or more of the endpoint group nodes.
6. The method of claim 1 , wherein the directed paths define flows of packets among the one or more addressable endpoints and through one or more policy boxes in the network, wherein the policy boxes correspond to network service functionality.
7. The method of claim 6, wherein the one or more policy boxes are modular and arranged in a chain to define a composite network service.
8. A non-transitory computer readable storage medium comprising
instructions, that when executed by a processor, cause the processor to: retrieve a plurality of network policy graphs from a graph library, wherein each of the network policy graphs is associated and comprises two or more endpoint group nodes, the endpoint group nodes corresponding to one or more addressable endpoints in a network, connected by directed edges, the directed edges corresponding to directed paths in the network; generate composite endpoint groups based on relationships between the endpoint groups;
generate composite paths among the composite endpoint groups based on relationships between the endpoint group nodes and the directed edges; and
generate a composite network policy graph comprising the composite endpoint groups and the composite paths.
9. The non-transitory computer readable storage medium of claim 8, wherein retrieving the plurality of network graphs comprises receiving one or more commands to configure the network from one or more policy graph sources according to the plurality of network graphs.
10. The non-transitory computer readable storage medium of claim 9, wherein the instructions further cause the processor to:
access a hierarchy comprising relationships among the policy graph sources; and
determine associations between each of the plurality of network graphs and at least one of the policy graph sources; and
wherein the composite network graph is further generated based on the relationships among the policy graph sources and the associations.
1 1 . The non-transitory computer readable storage medium of claim 8, wherein the instructions further cause the processor to:
perform a conflict check on the composite network policy graph to determine conflicts between the network policy graphs,
when the conflict check detects a conflict between two or more of the network policy graphs, generating an error message to prompt a correction of the one or more of network policy graphs; and
when the conflict check detects no conflicts among the network policy graphs, generating a command to program the network according to the composite network policy graph.
12. The non-transitory computer readable storage medium of claim 8, wherein some of the plurality of network policy graphs comprise policy boxes corresponding to implementations of network services, and wherein the instructions that cause the processor to generate the composite paths further cause the processor to generate composite policy box chains comprising some of the policy boxes based on hierarchical domain relationships among the endpoint groups and the policy boxes.
13. The non-transitory computer readable storage medium of claim 1 1 , wherein the instructions further cause the processor to convert the composite network policy graph into a high-level network programming language, and wherein the command comprises the high-level network programming language.
14. The non-transitory computer readable storage medium of claim 8, wherein the directed paths define flows of packets among the one or more
addressable endpoints and through one or more policy boxes in the network, wherein the policy boxes correspond to network service functionality.
15. The non-transitory computer readable storage medium of claim 14, wherein the one or more policy boxes are modular and arranged in chain to define a composite network service.
16. A network policy graph composer system comprising:
a processor; and
a non-transitory computer readable medium comprising instructions that when executed by the processor cause the processor to:
provide a network policy graph editor to generate a plurality of network policy graphs in response to corresponding input from a plurality of users, wherein each of the network policy graphs comprises two or more endpoint group nodes, the endpoint group nodes corresponding to one or more addressable endpoints in a network, connected by directed edges, the directed edges corresponding to directed paths in the network;
convert the plurality of network policy graphs into corresponding statements in a network programming language;
generate composite endpoint groups based on relationships between the endpoint groups described in the statements;
generate composite paths among the composite endpoint groups based on the relationships between the endpoint group nodes and the directed edges described in the statements; and
generate a composite network policy graph comprising the composite endpoint groups and the composite paths.
17. The network policy graph composer system of claim 16, wherein the instructions further cause the processor to generate a command to program the network according to the composite network policy graph.
18. The network policy graph composer system of claim 16, wherein the network policy graph editor comprises a graphical user interface receiving input from the users for defining the plurality of network policy graphs.
19. The network policy graph composer system of claim 16, wherein the instructions further cause the processor to perform a conflict check to detect conflicts between among the plurality of network policy graphs.
20. The network policy graph composer system of claim 16, wherein the network policy graph editor comprises a library of previously defined network policy graphs, and wherein to generate at least some of the plurality of network policy graphs, the network policy graph retrieves the at least some of the previously defined network policy graphs.
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
EP14905469.4A EP3216177B1 (en) | 2014-11-06 | 2014-11-06 | Network policy graphs |
US15/500,628 US10992520B2 (en) | 2014-11-06 | 2014-11-06 | Network policy graphs |
PCT/US2014/064394 WO2016072996A1 (en) | 2014-11-06 | 2014-11-06 | Network policy graphs |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/US2014/064394 WO2016072996A1 (en) | 2014-11-06 | 2014-11-06 | Network policy graphs |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2016072996A1 true WO2016072996A1 (en) | 2016-05-12 |
Family
ID=55909556
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US2014/064394 WO2016072996A1 (en) | 2014-11-06 | 2014-11-06 | Network policy graphs |
Country Status (3)
Country | Link |
---|---|
US (1) | US10992520B2 (en) |
EP (1) | EP3216177B1 (en) |
WO (1) | WO2016072996A1 (en) |
Cited By (73)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107040416A (en) * | 2017-04-12 | 2017-08-11 | 大连理工大学 | A kind of virtual data center visual management method based on Cairngorm frameworks |
EP3295608A4 (en) * | 2015-05-15 | 2018-04-25 | Hewlett-Packard Enterprise Development LP | Composition constraints for network policies |
WO2018222485A1 (en) * | 2017-05-31 | 2018-12-06 | Cisco Technology, Inc. | Intent specification checks for inconsistencies |
US10218572B2 (en) | 2017-06-19 | 2019-02-26 | Cisco Technology, Inc. | Multiprotocol border gateway protocol routing validation |
US10333787B2 (en) | 2017-06-19 | 2019-06-25 | Cisco Technology, Inc. | Validation of L3OUT configuration for communications outside a network |
US10333833B2 (en) | 2017-09-25 | 2019-06-25 | Cisco Technology, Inc. | Endpoint path assurance |
US10341184B2 (en) | 2017-06-19 | 2019-07-02 | Cisco Technology, Inc. | Validation of layer 3 bridge domain subnets in in a network |
US10348564B2 (en) | 2017-06-19 | 2019-07-09 | Cisco Technology, Inc. | Validation of routing information base-forwarding information base equivalence in a network |
US10411996B2 (en) | 2017-06-19 | 2019-09-10 | Cisco Technology, Inc. | Validation of routing information in a network fabric |
US10432467B2 (en) | 2017-06-19 | 2019-10-01 | Cisco Technology, Inc. | Network validation between the logical level and the hardware level of a network |
US10437641B2 (en) | 2017-06-19 | 2019-10-08 | Cisco Technology, Inc. | On-demand processing pipeline interleaved with temporal processing pipeline |
US10439875B2 (en) | 2017-05-31 | 2019-10-08 | Cisco Technology, Inc. | Identification of conflict rules in a network intent formal equivalence failure |
US10498608B2 (en) | 2017-06-16 | 2019-12-03 | Cisco Technology, Inc. | Topology explorer |
US10505816B2 (en) | 2017-05-31 | 2019-12-10 | Cisco Technology, Inc. | Semantic analysis to detect shadowing of rules in a model of network intents |
US10528444B2 (en) | 2017-06-19 | 2020-01-07 | Cisco Technology, Inc. | Event generation in response to validation between logical level and hardware level |
US10536337B2 (en) | 2017-06-19 | 2020-01-14 | Cisco Technology, Inc. | Validation of layer 2 interface and VLAN in a networked environment |
US10536348B2 (en) | 2017-04-28 | 2020-01-14 | At&T Intellectual Property I, L.P. | Operational micro-services design, development, deployment |
US10541873B2 (en) | 2015-11-20 | 2020-01-21 | Hewlett Packard Enterprise Development Lp | Determining violation of a network invariant |
US10547509B2 (en) | 2017-06-19 | 2020-01-28 | Cisco Technology, Inc. | Validation of a virtual port channel (VPC) endpoint in the network fabric |
US10547715B2 (en) | 2017-06-16 | 2020-01-28 | Cisco Technology, Inc. | Event generation in response to network intent formal equivalence failures |
US10554483B2 (en) | 2017-05-31 | 2020-02-04 | Cisco Technology, Inc. | Network policy analysis for networks |
US10554477B2 (en) | 2017-09-13 | 2020-02-04 | Cisco Technology, Inc. | Network assurance event aggregator |
US10554493B2 (en) | 2017-06-19 | 2020-02-04 | Cisco Technology, Inc. | Identifying mismatches between a logical model and node implementation |
US10560328B2 (en) | 2017-04-20 | 2020-02-11 | Cisco Technology, Inc. | Static network policy analysis for networks |
US10560355B2 (en) | 2017-06-19 | 2020-02-11 | Cisco Technology, Inc. | Static endpoint validation |
US10567384B2 (en) | 2017-08-25 | 2020-02-18 | Hewlett Packard Enterprise Development Lp | Verifying whether connectivity in a composed policy graph reflects a corresponding policy in input policy graphs |
US10567228B2 (en) | 2017-06-19 | 2020-02-18 | Cisco Technology, Inc. | Validation of cross logical groups in a network |
US10567229B2 (en) | 2017-06-19 | 2020-02-18 | Cisco Technology, Inc. | Validating endpoint configurations between nodes |
US10574513B2 (en) | 2017-06-16 | 2020-02-25 | Cisco Technology, Inc. | Handling controller and node failure scenarios during data collection |
US10572495B2 (en) | 2018-02-06 | 2020-02-25 | Cisco Technology Inc. | Network assurance database version compatibility |
US10581694B2 (en) | 2017-05-31 | 2020-03-03 | Cisco Technology, Inc. | Generation of counter examples for network intent formal equivalence failures |
US10587484B2 (en) | 2017-09-12 | 2020-03-10 | Cisco Technology, Inc. | Anomaly detection and reporting in a network assurance appliance |
US10587456B2 (en) | 2017-09-12 | 2020-03-10 | Cisco Technology, Inc. | Event clustering for a network assurance platform |
US10587621B2 (en) | 2017-06-16 | 2020-03-10 | Cisco Technology, Inc. | System and method for migrating to and maintaining a white-list network security model |
US10616072B1 (en) | 2018-07-27 | 2020-04-07 | Cisco Technology, Inc. | Epoch data interface |
US10623271B2 (en) | 2017-05-31 | 2020-04-14 | Cisco Technology, Inc. | Intra-priority class ordering of rules corresponding to a model of network intents |
US10623259B2 (en) | 2017-06-19 | 2020-04-14 | Cisco Technology, Inc. | Validation of layer 1 interface in a network |
US10623264B2 (en) | 2017-04-20 | 2020-04-14 | Cisco Technology, Inc. | Policy assurance for service chaining |
US10644946B2 (en) | 2017-06-19 | 2020-05-05 | Cisco Technology, Inc. | Detection of overlapping subnets in a network |
US10644951B2 (en) | 2015-07-22 | 2020-05-05 | Hewlett Packard Enterprise Development Lp | Adding metadata associated with a composite network policy |
US10652102B2 (en) | 2017-06-19 | 2020-05-12 | Cisco Technology, Inc. | Network node memory utilization analysis |
US10659298B1 (en) | 2018-06-27 | 2020-05-19 | Cisco Technology, Inc. | Epoch comparison for network events |
US10673702B2 (en) | 2017-06-19 | 2020-06-02 | Cisco Technology, Inc. | Validation of layer 3 using virtual routing forwarding containers in a network |
US10686669B2 (en) | 2017-06-16 | 2020-06-16 | Cisco Technology, Inc. | Collecting network models and node information from a network |
US10693738B2 (en) | 2017-05-31 | 2020-06-23 | Cisco Technology, Inc. | Generating device-level logical models for a network |
US10700933B2 (en) | 2017-06-19 | 2020-06-30 | Cisco Technology, Inc. | Validating tunnel endpoint addresses in a network fabric |
US10797951B2 (en) | 2014-10-16 | 2020-10-06 | Cisco Technology, Inc. | Discovering and grouping application endpoints in a network environment |
US10805160B2 (en) | 2017-06-19 | 2020-10-13 | Cisco Technology, Inc. | Endpoint bridge domain subnet validation |
US10812315B2 (en) | 2018-06-07 | 2020-10-20 | Cisco Technology, Inc. | Cross-domain network assurance |
US10812336B2 (en) | 2017-06-19 | 2020-10-20 | Cisco Technology, Inc. | Validation of bridge domain-L3out association for communication outside a network |
US10812318B2 (en) | 2017-05-31 | 2020-10-20 | Cisco Technology, Inc. | Associating network policy objects with specific faults corresponding to fault localizations in large-scale network deployment |
US10826770B2 (en) | 2018-07-26 | 2020-11-03 | Cisco Technology, Inc. | Synthesis of models for networks using automated boolean learning |
US10826788B2 (en) | 2017-04-20 | 2020-11-03 | Cisco Technology, Inc. | Assurance of quality-of-service configurations in a network |
US10873509B2 (en) | 2018-01-17 | 2020-12-22 | Cisco Technology, Inc. | Check-pointing ACI network state and re-execution from a check-pointed state |
US10904070B2 (en) | 2018-07-11 | 2021-01-26 | Cisco Technology, Inc. | Techniques and interfaces for troubleshooting datacenter networks |
US10904101B2 (en) | 2017-06-16 | 2021-01-26 | Cisco Technology, Inc. | Shim layer for extracting and prioritizing underlying rules for modeling network intents |
US10911495B2 (en) | 2018-06-27 | 2021-02-02 | Cisco Technology, Inc. | Assurance of security rules in a network |
CN112565193A (en) * | 2020-11-06 | 2021-03-26 | 西安电子科技大学 | Network security policy conflict resolution method, system, storage medium and equipment |
US10992520B2 (en) | 2014-11-06 | 2021-04-27 | Hewlett Packard Enterprise Development Lp | Network policy graphs |
US11019027B2 (en) | 2018-06-27 | 2021-05-25 | Cisco Technology, Inc. | Address translation for external network appliance |
US11044273B2 (en) | 2018-06-27 | 2021-06-22 | Cisco Technology, Inc. | Assurance of security rules in a network |
US11102053B2 (en) | 2017-12-05 | 2021-08-24 | Cisco Technology, Inc. | Cross-domain assurance |
US11121927B2 (en) | 2017-06-19 | 2021-09-14 | Cisco Technology, Inc. | Automatically determining an optimal amount of time for analyzing a distributed network environment |
US11150973B2 (en) | 2017-06-16 | 2021-10-19 | Cisco Technology, Inc. | Self diagnosing distributed appliance |
US11218508B2 (en) | 2018-06-27 | 2022-01-04 | Cisco Technology, Inc. | Assurance of security rules in a network |
US11258657B2 (en) | 2017-05-31 | 2022-02-22 | Cisco Technology, Inc. | Fault localization in large-scale network policy deployment |
US11283680B2 (en) | 2017-06-19 | 2022-03-22 | Cisco Technology, Inc. | Identifying components for removal in a network configuration |
US11343150B2 (en) | 2017-06-19 | 2022-05-24 | Cisco Technology, Inc. | Validation of learned routes in a network |
US11374980B1 (en) | 2020-01-17 | 2022-06-28 | Cisco Technology, Inc. | Resolution of policy enforcement point by cross correlating other policies |
US11469986B2 (en) | 2017-06-16 | 2022-10-11 | Cisco Technology, Inc. | Controlled micro fault injection on a distributed appliance |
US11516088B1 (en) * | 2021-10-28 | 2022-11-29 | Microsoft Technology Licensing, Llc | Network configuration verification in computing systems |
US11606301B2 (en) | 2019-04-23 | 2023-03-14 | Hewlett Packard Enterprise Development Lp | Verifying intents in stateful networks using atomic address objects |
US11645131B2 (en) | 2017-06-16 | 2023-05-09 | Cisco Technology, Inc. | Distributed fault code aggregation across application centric dimensions |
Families Citing this family (22)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10530697B2 (en) * | 2015-02-17 | 2020-01-07 | Futurewei Technologies, Inc. | Intent based network configuration |
US10243848B2 (en) | 2015-06-27 | 2019-03-26 | Nicira, Inc. | Provisioning logical entities in a multi-datacenter environment |
DE102015115898A1 (en) * | 2015-09-21 | 2017-03-23 | Deutsche Telekom Ag | Network entity for monitoring a plurality of processes of a communication system |
US10454789B2 (en) * | 2015-10-19 | 2019-10-22 | Draios, Inc. | Automated service-oriented performance management |
US10382529B2 (en) | 2016-01-29 | 2019-08-13 | Nicira, Inc. | Directed graph based span computation and configuration dispatching |
US10122589B2 (en) * | 2016-04-08 | 2018-11-06 | Cisco Technology, Inc. | Configuring the design of an industrial automation network |
US10284428B2 (en) * | 2016-06-09 | 2019-05-07 | Fujitsu Limited | Graphical policy interface for network control systems |
US10594560B2 (en) * | 2017-03-27 | 2020-03-17 | Cisco Technology, Inc. | Intent driven network policy platform |
US10243846B2 (en) | 2017-05-15 | 2019-03-26 | Nicira, Inc. | Defining routing domain for distributed packet processing |
US10756983B2 (en) | 2017-12-08 | 2020-08-25 | Apstra, Inc. | Intent-based analytics |
US10917436B2 (en) * | 2018-03-20 | 2021-02-09 | Cisco Technology, Inc. | On-demand security policy provisioning |
US11165803B2 (en) * | 2018-06-12 | 2021-11-02 | Netskope, Inc. | Systems and methods to show detailed structure in a security events graph |
US11539749B2 (en) | 2018-06-12 | 2022-12-27 | Netskope, Inc. | Systems and methods for alert prioritization using security events graph |
US11258827B2 (en) * | 2018-10-19 | 2022-02-22 | Oracle International Corporation | Autonomous monitoring of applications in a cloud environment |
CN113316925B (en) * | 2019-01-21 | 2023-07-04 | 威睿公司 | Determining spans of network configuration dependencies |
US11048670B2 (en) * | 2019-08-27 | 2021-06-29 | Advanced New Technologies Co., Ltd. | Node layout determining method and apparatus, computing device, and computer readable medium |
US11088902B1 (en) | 2020-04-06 | 2021-08-10 | Vmware, Inc. | Synchronization of logical network state between global and local managers |
US11088919B1 (en) | 2020-04-06 | 2021-08-10 | Vmware, Inc. | Data structure for defining multi-site logical network |
US11374817B2 (en) | 2020-04-06 | 2022-06-28 | Vmware, Inc. | Determining span of logical network element |
US11343283B2 (en) | 2020-09-28 | 2022-05-24 | Vmware, Inc. | Multi-tenant network virtualization infrastructure |
US11283691B1 (en) | 2020-10-21 | 2022-03-22 | Juniper Networks, Inc. | Model driven intent policy conflict detection and resolution through graph analysis |
CN113660677B (en) * | 2021-07-29 | 2022-08-19 | 西安电子科技大学 | Maximum error independent path calculation method of weighted time-varying network under consumption limit |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20090059814A1 (en) | 2007-08-31 | 2009-03-05 | Fisher-Rosemount Sytems, Inc. | Configuring and Optimizing a Wireless Mesh Network |
US20120023546A1 (en) | 2010-07-22 | 2012-01-26 | Juniper Networks, Inc. | Domain-based security policies |
US20120166604A1 (en) * | 2010-12-28 | 2012-06-28 | Microsoft Corporation | Flexible policy based network decisionmaking |
US20130064255A1 (en) * | 2008-11-12 | 2013-03-14 | Patricia Humberto Saavedra | System, apparatus and method for providing aggregated network connections |
US8499331B1 (en) * | 2007-06-27 | 2013-07-30 | Emc Corporation | Policy based network compliance |
US20140096188A1 (en) * | 2011-06-16 | 2014-04-03 | Marco Casassa Mont | System and method for policy generation |
Family Cites Families (77)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6463470B1 (en) | 1998-10-26 | 2002-10-08 | Cisco Technology, Inc. | Method and apparatus of storing policies for policy-based management of quality of service treatments of network data traffic flows |
US6393473B1 (en) | 1998-12-18 | 2002-05-21 | Cisco Technology, Inc. | Representing and verifying network management policies using collective constraints |
US6675353B1 (en) | 1999-07-26 | 2004-01-06 | Microsoft Corporation | Methods and systems for generating XML documents |
WO2001067309A2 (en) | 2000-03-03 | 2001-09-13 | Radiant Logic, Inc. | System and method for providing access to databases via directories and other hierarchical structures and interfaces |
US6880005B1 (en) | 2000-03-31 | 2005-04-12 | Intel Corporation | Managing policy rules in a network |
US6584476B1 (en) | 2000-04-22 | 2003-06-24 | Oracle Corp. | System and method for enforcing referential constraints between versioned database tables |
WO2002059773A1 (en) | 2000-12-04 | 2002-08-01 | Thinkshare Corp. | Modular distributed mobile data applications |
US6920461B2 (en) | 2001-07-10 | 2005-07-19 | Microsoft Corp. | Application program interface for network software platform |
US8316051B1 (en) | 2001-11-30 | 2012-11-20 | Oralce International Corporation | Techniques for adding multiple security policies to a database system |
US7096216B2 (en) | 2002-07-20 | 2006-08-22 | Microsoft Corporation | Performing operations on a set of objects in a database system |
US8122106B2 (en) | 2003-03-06 | 2012-02-21 | Microsoft Corporation | Integrating design, deployment, and management phases for systems |
US7340649B2 (en) | 2003-03-20 | 2008-03-04 | Dell Products L.P. | System and method for determining fault isolation in an enterprise computing system |
US7308711B2 (en) | 2003-06-06 | 2007-12-11 | Microsoft Corporation | Method and framework for integrating a plurality of network policies |
US7665119B2 (en) | 2004-09-03 | 2010-02-16 | Secure Elements, Inc. | Policy-based selection of remediation |
US7707619B2 (en) | 2005-01-28 | 2010-04-27 | Microsoft Corporation | Method and system for troubleshooting when a program is adversely impacted by a security policy |
US7941309B2 (en) | 2005-11-02 | 2011-05-10 | Microsoft Corporation | Modeling IT operations/policies |
US8141125B2 (en) | 2005-11-30 | 2012-03-20 | Oracle International Corporation | Orchestration of policy engines and format technologies |
US20070156736A1 (en) | 2006-01-05 | 2007-07-05 | International Business Machines Corporation | Method and apparatus for automatically detecting a latent referential integrity relationship between different tables of a database |
US8001528B2 (en) | 2006-03-30 | 2011-08-16 | Microsoft Corporation | Organization of application state and configuration settings |
US20070255769A1 (en) | 2006-04-14 | 2007-11-01 | International Business Machines Corporation | System of hierarchical policy definition, dissemination, and evaluation |
CN100559771C (en) | 2006-06-23 | 2009-11-11 | 国际商业机器公司 | The web service strategy is transformed into the method and apparatus of physical model from logical model |
US7844908B2 (en) | 2006-08-04 | 2010-11-30 | National Instruments Corporation | Diagram that visually indicates targeted execution |
US8369224B1 (en) | 2006-09-08 | 2013-02-05 | Juniper Networks, Inc. | Combining network endpoint policy results |
US8938783B2 (en) | 2006-09-11 | 2015-01-20 | Microsoft Corporation | Security language expressions for logic resolution |
US20080162109A1 (en) * | 2006-12-28 | 2008-07-03 | Motorola, Inc. | Creating and managing a policy continuum |
US20080161941A1 (en) | 2006-12-29 | 2008-07-03 | Motorola, Inc. | Graph-theoretic technique of analyzing and optimizing policy deployment |
US9661112B2 (en) | 2007-02-22 | 2017-05-23 | International Business Machines Corporation | System and methods for providing server virtualization assistance |
US8484693B2 (en) | 2007-04-27 | 2013-07-09 | Gregory W. Cox | Efficient policy conflict detection |
US8327414B2 (en) | 2007-06-21 | 2012-12-04 | Motorola Solutions, Inc. | Performing policy conflict detection and resolution using semantic analysis |
US8443433B2 (en) | 2007-06-28 | 2013-05-14 | Microsoft Corporation | Determining a merged security policy for a computer system |
US8468521B2 (en) | 2007-10-26 | 2013-06-18 | Netapp, Inc. | System and method for utilizing a virtualized compute cluster as an execution engine for a virtual machine of a storage system cluster |
US8656451B2 (en) | 2008-03-07 | 2014-02-18 | At&T Mobility Ii Llc | Policy application server for mobile data networks |
US8166516B2 (en) | 2008-03-27 | 2012-04-24 | Microsoft Corporation | Determining effective policy |
TWI476610B (en) | 2008-04-29 | 2015-03-11 | Maxiscale Inc | Peer-to-peer redundant file server system and methods |
US20090300069A1 (en) | 2008-05-29 | 2009-12-03 | O'sullivan Michael Patrick | Method and system for the logical deletion of relational database records |
US8479257B1 (en) | 2008-08-08 | 2013-07-02 | Redseal Networks, Inc. | Method and apparatus for assessing policy compliance of as-built data networks |
US9135629B2 (en) | 2009-06-23 | 2015-09-15 | Simeon S. Simeonov | User targeting management, monitoring and enforcement |
CN101833497B (en) | 2010-03-30 | 2015-01-21 | 浪潮电子信息产业股份有限公司 | Computer fault management system based on expert system method |
EP2583211B1 (en) | 2010-06-15 | 2020-04-15 | Oracle International Corporation | Virtual computing infrastructure |
US8868506B1 (en) | 2010-06-17 | 2014-10-21 | Evolphin Software, Inc. | Method and apparatus for digital asset management |
US8717895B2 (en) | 2010-07-06 | 2014-05-06 | Nicira, Inc. | Network virtualization apparatus and method with a table mapping engine |
US8560646B1 (en) | 2010-09-28 | 2013-10-15 | Amazon Technologies, Inc. | Managing communications using alternative packet addressing |
US8719253B2 (en) | 2010-12-01 | 2014-05-06 | Cisco Technology, Inc. | Method and apparatus for efficiently organizing hierarchical QoS policies |
US9208071B2 (en) | 2010-12-13 | 2015-12-08 | SanDisk Technologies, Inc. | Apparatus, system, and method for accessing memory |
US8577842B1 (en) | 2011-09-19 | 2013-11-05 | Amazon Technologies, Inc. | Distributed computer system snapshots and instantiation thereof |
JP5500309B2 (en) | 2011-09-07 | 2014-05-21 | 日本電気株式会社 | Storage device |
US20130124567A1 (en) | 2011-11-14 | 2013-05-16 | Helen Balinsky | Automatic prioritization of policies |
US8718064B2 (en) | 2011-12-22 | 2014-05-06 | Telefonaktiebolaget L M Ericsson (Publ) | Forwarding element for flexible and extensible flow processing software-defined networks |
GB2504487A (en) | 2012-07-30 | 2014-02-05 | Ibm | Automated network deployment of cloud services into a network by matching security requirements |
US20140122670A1 (en) | 2012-11-01 | 2014-05-01 | Intigua Inc. | System and method for automated system management |
US10181979B2 (en) | 2012-11-09 | 2019-01-15 | California Institute Of Technology | Inter-network policy |
US9363289B2 (en) | 2013-02-12 | 2016-06-07 | International Business Machines Corporation | Instrumentation and monitoring of service level agreement (SLA) and service policy enforcement |
US9130901B2 (en) | 2013-02-26 | 2015-09-08 | Zentera Systems, Inc. | Peripheral firewall system for application protection in cloud computing environments |
US9578061B2 (en) | 2013-03-13 | 2017-02-21 | FireMon, LLC | System and method for modeling a networking device policy |
US9270704B2 (en) | 2013-03-13 | 2016-02-23 | FireMon, LLC | Modeling network devices for behavior analysis |
US9047143B2 (en) | 2013-03-15 | 2015-06-02 | Cisco Technology, Inc. | Automation and programmability for software defined networking systems |
US9596141B2 (en) * | 2013-03-15 | 2017-03-14 | Cisco Technology, Inc. | Representing software defined networks using a programmable graph model |
US10263848B2 (en) | 2013-03-20 | 2019-04-16 | Wolting Holding B.V. | Compiler for and method for software defined networks |
US9483361B2 (en) | 2013-05-08 | 2016-11-01 | Commvault Systems, Inc. | Information management cell with failover management capability |
CA2820492A1 (en) | 2013-06-18 | 2014-12-18 | El Fresko Technologies Limited | Namespace transformations |
US9203765B2 (en) | 2013-08-30 | 2015-12-01 | Cisco Technology, Inc. | Flow based network service insertion using a service chain identifier |
US9367434B2 (en) | 2013-10-02 | 2016-06-14 | Accenture Global Services Limited | Testing framework for policy-based workflows |
US20150135265A1 (en) | 2013-11-11 | 2015-05-14 | MyDigitalShield, Inc. | Automatic network firewall policy determination |
US9680872B1 (en) | 2014-03-25 | 2017-06-13 | Amazon Technologies, Inc. | Trusted-code generated requests |
US9491054B2 (en) * | 2014-06-06 | 2016-11-08 | Microsoft Technology Licensing, Llc | Network-state management service |
US10382537B2 (en) | 2014-09-25 | 2019-08-13 | Oracle International Corporation | System and method for use of a global runtime in a multitenant application server environment |
EP3216177B1 (en) | 2014-11-06 | 2021-04-14 | Hewlett Packard Enterprise Development LP | Network policy graphs |
WO2016094825A1 (en) | 2014-12-11 | 2016-06-16 | Brocade Communications Systems, Inc. | Multilayered distributed router architecture |
US9785777B2 (en) | 2014-12-19 | 2017-10-10 | International Business Machines Corporation | Static analysis based on abstract program representations |
US9892143B2 (en) | 2015-02-04 | 2018-02-13 | Microsoft Technology Licensing, Llc | Association index linking child and parent tables |
US9848041B2 (en) | 2015-05-01 | 2017-12-19 | Amazon Technologies, Inc. | Automatic scaling of resource instance groups within compute clusters |
WO2016186605A1 (en) | 2015-05-15 | 2016-11-24 | Hewlett Packard Enterprise Development Lp | Composition constraints for network policies |
US10009438B2 (en) | 2015-05-20 | 2018-06-26 | Sandisk Technologies Llc | Transaction log acceleration |
WO2017014769A1 (en) | 2015-07-22 | 2017-01-26 | Hewlett Packard Enterprise Development Lp | Providing a composite network policy |
WO2017095391A1 (en) | 2015-12-01 | 2017-06-08 | Hewlett Packard Enterprise Development Lp | Label management |
US11157560B2 (en) | 2016-04-25 | 2021-10-26 | Tigergraph, Inc. | System and method for managing graph data |
US11281706B2 (en) | 2016-09-26 | 2022-03-22 | Splunk Inc. | Multi-layer partition allocation for query execution |
-
2014
- 2014-11-06 EP EP14905469.4A patent/EP3216177B1/en active Active
- 2014-11-06 WO PCT/US2014/064394 patent/WO2016072996A1/en active Application Filing
- 2014-11-06 US US15/500,628 patent/US10992520B2/en active Active
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8499331B1 (en) * | 2007-06-27 | 2013-07-30 | Emc Corporation | Policy based network compliance |
US20090059814A1 (en) | 2007-08-31 | 2009-03-05 | Fisher-Rosemount Sytems, Inc. | Configuring and Optimizing a Wireless Mesh Network |
US20130064255A1 (en) * | 2008-11-12 | 2013-03-14 | Patricia Humberto Saavedra | System, apparatus and method for providing aggregated network connections |
US20120023546A1 (en) | 2010-07-22 | 2012-01-26 | Juniper Networks, Inc. | Domain-based security policies |
US20120166604A1 (en) * | 2010-12-28 | 2012-06-28 | Microsoft Corporation | Flexible policy based network decisionmaking |
US20140096188A1 (en) * | 2011-06-16 | 2014-04-03 | Marco Casassa Mont | System and method for policy generation |
Non-Patent Citations (3)
Title |
---|
MOHAMMAD BANKIKAZEMI ET AL.: "IEEE COMMUNICATIONS MAGAZINE, IEEE SERVICE CENTER, PISCATAWAY, US", vol. 51, 1 February 2013, article "Meridian: an SDN platform for cloud network services", pages: 120 - 127 |
S. K. FAYAZBAKHSH ET AL.: "Enforcing network-wide policies in the presence of dynamic middlebox actions using flowtags.", PROCEEDINGS OF THE 11TH USEN IX CONFERENCE ON NETWORKED SYSTEMS DESIGN AND IMPLEMENTATION, 2 April 2014 (2014-04-02) - 4 April 2014 (2014-04-04), pages 533 - 546, XP055374720 * |
See also references of EP3216177A4 |
Cited By (113)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11539588B2 (en) | 2014-10-16 | 2022-12-27 | Cisco Technology, Inc. | Discovering and grouping application endpoints in a network environment |
US11811603B2 (en) | 2014-10-16 | 2023-11-07 | Cisco Technology, Inc. | Discovering and grouping application endpoints in a network environment |
US10797951B2 (en) | 2014-10-16 | 2020-10-06 | Cisco Technology, Inc. | Discovering and grouping application endpoints in a network environment |
US10992520B2 (en) | 2014-11-06 | 2021-04-27 | Hewlett Packard Enterprise Development Lp | Network policy graphs |
EP3295608A4 (en) * | 2015-05-15 | 2018-04-25 | Hewlett-Packard Enterprise Development LP | Composition constraints for network policies |
US10644951B2 (en) | 2015-07-22 | 2020-05-05 | Hewlett Packard Enterprise Development Lp | Adding metadata associated with a composite network policy |
US11095518B2 (en) | 2015-11-20 | 2021-08-17 | Hewlett Packard Enterprise Development Lp | Determining violation of a network invariant |
US10541873B2 (en) | 2015-11-20 | 2020-01-21 | Hewlett Packard Enterprise Development Lp | Determining violation of a network invariant |
CN107040416A (en) * | 2017-04-12 | 2017-08-11 | 大连理工大学 | A kind of virtual data center visual management method based on Cairngorm frameworks |
US10623264B2 (en) | 2017-04-20 | 2020-04-14 | Cisco Technology, Inc. | Policy assurance for service chaining |
US10826788B2 (en) | 2017-04-20 | 2020-11-03 | Cisco Technology, Inc. | Assurance of quality-of-service configurations in a network |
US10560328B2 (en) | 2017-04-20 | 2020-02-11 | Cisco Technology, Inc. | Static network policy analysis for networks |
US11178009B2 (en) | 2017-04-20 | 2021-11-16 | Cisco Technology, Inc. | Static network policy analysis for networks |
US10536348B2 (en) | 2017-04-28 | 2020-01-14 | At&T Intellectual Property I, L.P. | Operational micro-services design, development, deployment |
CN110612702B (en) * | 2017-05-31 | 2022-08-02 | 思科技术公司 | Intent specification checking for inconsistencies |
US10951477B2 (en) | 2017-05-31 | 2021-03-16 | Cisco Technology, Inc. | Identification of conflict rules in a network intent formal equivalence failure |
US11258657B2 (en) | 2017-05-31 | 2022-02-22 | Cisco Technology, Inc. | Fault localization in large-scale network policy deployment |
CN110612702A (en) * | 2017-05-31 | 2019-12-24 | 思科技术公司 | Intent specification checking for inconsistencies |
US10505816B2 (en) | 2017-05-31 | 2019-12-10 | Cisco Technology, Inc. | Semantic analysis to detect shadowing of rules in a model of network intents |
WO2018222485A1 (en) * | 2017-05-31 | 2018-12-06 | Cisco Technology, Inc. | Intent specification checks for inconsistencies |
US10693738B2 (en) | 2017-05-31 | 2020-06-23 | Cisco Technology, Inc. | Generating device-level logical models for a network |
US10554483B2 (en) | 2017-05-31 | 2020-02-04 | Cisco Technology, Inc. | Network policy analysis for networks |
US10623271B2 (en) | 2017-05-31 | 2020-04-14 | Cisco Technology, Inc. | Intra-priority class ordering of rules corresponding to a model of network intents |
US10812318B2 (en) | 2017-05-31 | 2020-10-20 | Cisco Technology, Inc. | Associating network policy objects with specific faults corresponding to fault localizations in large-scale network deployment |
US10439875B2 (en) | 2017-05-31 | 2019-10-08 | Cisco Technology, Inc. | Identification of conflict rules in a network intent formal equivalence failure |
US11411803B2 (en) | 2017-05-31 | 2022-08-09 | Cisco Technology, Inc. | Associating network policy objects with specific faults corresponding to fault localizations in large-scale network deployment |
US10581694B2 (en) | 2017-05-31 | 2020-03-03 | Cisco Technology, Inc. | Generation of counter examples for network intent formal equivalence failures |
US11303531B2 (en) | 2017-05-31 | 2022-04-12 | Cisco Technologies, Inc. | Generation of counter examples for network intent formal equivalence failures |
US10904101B2 (en) | 2017-06-16 | 2021-01-26 | Cisco Technology, Inc. | Shim layer for extracting and prioritizing underlying rules for modeling network intents |
US10574513B2 (en) | 2017-06-16 | 2020-02-25 | Cisco Technology, Inc. | Handling controller and node failure scenarios during data collection |
US11469986B2 (en) | 2017-06-16 | 2022-10-11 | Cisco Technology, Inc. | Controlled micro fault injection on a distributed appliance |
US11463316B2 (en) | 2017-06-16 | 2022-10-04 | Cisco Technology, Inc. | Topology explorer |
US11563645B2 (en) | 2017-06-16 | 2023-01-24 | Cisco Technology, Inc. | Shim layer for extracting and prioritizing underlying rules for modeling network intents |
US11102337B2 (en) | 2017-06-16 | 2021-08-24 | Cisco Technology, Inc. | Event generation in response to network intent formal equivalence failures |
US10587621B2 (en) | 2017-06-16 | 2020-03-10 | Cisco Technology, Inc. | System and method for migrating to and maintaining a white-list network security model |
US11645131B2 (en) | 2017-06-16 | 2023-05-09 | Cisco Technology, Inc. | Distributed fault code aggregation across application centric dimensions |
US11150973B2 (en) | 2017-06-16 | 2021-10-19 | Cisco Technology, Inc. | Self diagnosing distributed appliance |
US10547715B2 (en) | 2017-06-16 | 2020-01-28 | Cisco Technology, Inc. | Event generation in response to network intent formal equivalence failures |
US10498608B2 (en) | 2017-06-16 | 2019-12-03 | Cisco Technology, Inc. | Topology explorer |
US10686669B2 (en) | 2017-06-16 | 2020-06-16 | Cisco Technology, Inc. | Collecting network models and node information from a network |
US10873506B2 (en) | 2017-06-19 | 2020-12-22 | Cisco Technology, Inc. | Validation of a virtual port channel (VPC) endpoint in the network fabric |
US10547509B2 (en) | 2017-06-19 | 2020-01-28 | Cisco Technology, Inc. | Validation of a virtual port channel (VPC) endpoint in the network fabric |
US10218572B2 (en) | 2017-06-19 | 2019-02-26 | Cisco Technology, Inc. | Multiprotocol border gateway protocol routing validation |
US10673702B2 (en) | 2017-06-19 | 2020-06-02 | Cisco Technology, Inc. | Validation of layer 3 using virtual routing forwarding containers in a network |
US10644946B2 (en) | 2017-06-19 | 2020-05-05 | Cisco Technology, Inc. | Detection of overlapping subnets in a network |
US10623259B2 (en) | 2017-06-19 | 2020-04-14 | Cisco Technology, Inc. | Validation of layer 1 interface in a network |
US10700933B2 (en) | 2017-06-19 | 2020-06-30 | Cisco Technology, Inc. | Validating tunnel endpoint addresses in a network fabric |
US11750463B2 (en) | 2017-06-19 | 2023-09-05 | Cisco Technology, Inc. | Automatically determining an optimal amount of time for analyzing a distributed network environment |
US10805160B2 (en) | 2017-06-19 | 2020-10-13 | Cisco Technology, Inc. | Endpoint bridge domain subnet validation |
US11736351B2 (en) | 2017-06-19 | 2023-08-22 | Cisco Technology Inc. | Identifying components for removal in a network configuration |
US10812336B2 (en) | 2017-06-19 | 2020-10-20 | Cisco Technology, Inc. | Validation of bridge domain-L3out association for communication outside a network |
US10333787B2 (en) | 2017-06-19 | 2019-06-25 | Cisco Technology, Inc. | Validation of L3OUT configuration for communications outside a network |
US11595257B2 (en) | 2017-06-19 | 2023-02-28 | Cisco Technology, Inc. | Validation of cross logical groups in a network |
US11570047B2 (en) | 2017-06-19 | 2023-01-31 | Cisco Technology, Inc. | Detection of overlapping subnets in a network |
US10862752B2 (en) | 2017-06-19 | 2020-12-08 | Cisco Technology, Inc. | Network validation between the logical level and the hardware level of a network |
US10873505B2 (en) | 2017-06-19 | 2020-12-22 | Cisco Technology, Inc. | Validation of layer 2 interface and VLAN in a networked environment |
US11558260B2 (en) | 2017-06-19 | 2023-01-17 | Cisco Technology, Inc. | Network node memory utilization analysis |
US10341184B2 (en) | 2017-06-19 | 2019-07-02 | Cisco Technology, Inc. | Validation of layer 3 bridge domain subnets in in a network |
US10880169B2 (en) | 2017-06-19 | 2020-12-29 | Cisco Technology, Inc. | Multiprotocol border gateway protocol routing validation |
US10348564B2 (en) | 2017-06-19 | 2019-07-09 | Cisco Technology, Inc. | Validation of routing information base-forwarding information base equivalence in a network |
US10567229B2 (en) | 2017-06-19 | 2020-02-18 | Cisco Technology, Inc. | Validating endpoint configurations between nodes |
US11469952B2 (en) | 2017-06-19 | 2022-10-11 | Cisco Technology, Inc. | Identifying mismatches between a logical model and node implementation |
US10567228B2 (en) | 2017-06-19 | 2020-02-18 | Cisco Technology, Inc. | Validation of cross logical groups in a network |
US10411996B2 (en) | 2017-06-19 | 2019-09-10 | Cisco Technology, Inc. | Validation of routing information in a network fabric |
US10972352B2 (en) | 2017-06-19 | 2021-04-06 | Cisco Technology, Inc. | Validation of routing information base-forwarding information base equivalence in a network |
US11438234B2 (en) | 2017-06-19 | 2022-09-06 | Cisco Technology, Inc. | Validation of a virtual port channel (VPC) endpoint in the network fabric |
US10432467B2 (en) | 2017-06-19 | 2019-10-01 | Cisco Technology, Inc. | Network validation between the logical level and the hardware level of a network |
US11405278B2 (en) | 2017-06-19 | 2022-08-02 | Cisco Technology, Inc. | Validating tunnel endpoint addresses in a network fabric |
US10437641B2 (en) | 2017-06-19 | 2019-10-08 | Cisco Technology, Inc. | On-demand processing pipeline interleaved with temporal processing pipeline |
US11063827B2 (en) | 2017-06-19 | 2021-07-13 | Cisco Technology, Inc. | Validation of layer 3 bridge domain subnets in a network |
US10560355B2 (en) | 2017-06-19 | 2020-02-11 | Cisco Technology, Inc. | Static endpoint validation |
US11343150B2 (en) | 2017-06-19 | 2022-05-24 | Cisco Technology, Inc. | Validation of learned routes in a network |
US11102111B2 (en) | 2017-06-19 | 2021-08-24 | Cisco Technology, Inc. | Validation of routing information in a network fabric |
US10554493B2 (en) | 2017-06-19 | 2020-02-04 | Cisco Technology, Inc. | Identifying mismatches between a logical model and node implementation |
US11303520B2 (en) | 2017-06-19 | 2022-04-12 | Cisco Technology, Inc. | Validation of cross logical groups in a network |
US11121927B2 (en) | 2017-06-19 | 2021-09-14 | Cisco Technology, Inc. | Automatically determining an optimal amount of time for analyzing a distributed network environment |
US10528444B2 (en) | 2017-06-19 | 2020-01-07 | Cisco Technology, Inc. | Event generation in response to validation between logical level and hardware level |
US11153167B2 (en) | 2017-06-19 | 2021-10-19 | Cisco Technology, Inc. | Validation of L3OUT configuration for communications outside a network |
US10652102B2 (en) | 2017-06-19 | 2020-05-12 | Cisco Technology, Inc. | Network node memory utilization analysis |
US11283680B2 (en) | 2017-06-19 | 2022-03-22 | Cisco Technology, Inc. | Identifying components for removal in a network configuration |
US10536337B2 (en) | 2017-06-19 | 2020-01-14 | Cisco Technology, Inc. | Validation of layer 2 interface and VLAN in a networked environment |
US11283682B2 (en) | 2017-06-19 | 2022-03-22 | Cisco Technology, Inc. | Validation of bridge domain-L3out association for communication outside a network |
US10567384B2 (en) | 2017-08-25 | 2020-02-18 | Hewlett Packard Enterprise Development Lp | Verifying whether connectivity in a composed policy graph reflects a corresponding policy in input policy graphs |
US10587456B2 (en) | 2017-09-12 | 2020-03-10 | Cisco Technology, Inc. | Event clustering for a network assurance platform |
US11038743B2 (en) | 2017-09-12 | 2021-06-15 | Cisco Technology, Inc. | Event clustering for a network assurance platform |
US10587484B2 (en) | 2017-09-12 | 2020-03-10 | Cisco Technology, Inc. | Anomaly detection and reporting in a network assurance appliance |
US11115300B2 (en) | 2017-09-12 | 2021-09-07 | Cisco Technology, Inc | Anomaly detection and reporting in a network assurance appliance |
US10554477B2 (en) | 2017-09-13 | 2020-02-04 | Cisco Technology, Inc. | Network assurance event aggregator |
US10333833B2 (en) | 2017-09-25 | 2019-06-25 | Cisco Technology, Inc. | Endpoint path assurance |
US11102053B2 (en) | 2017-12-05 | 2021-08-24 | Cisco Technology, Inc. | Cross-domain assurance |
US10873509B2 (en) | 2018-01-17 | 2020-12-22 | Cisco Technology, Inc. | Check-pointing ACI network state and re-execution from a check-pointed state |
US11824728B2 (en) | 2018-01-17 | 2023-11-21 | Cisco Technology, Inc. | Check-pointing ACI network state and re-execution from a check-pointed state |
US10572495B2 (en) | 2018-02-06 | 2020-02-25 | Cisco Technology Inc. | Network assurance database version compatibility |
US10812315B2 (en) | 2018-06-07 | 2020-10-20 | Cisco Technology, Inc. | Cross-domain network assurance |
US11374806B2 (en) | 2018-06-07 | 2022-06-28 | Cisco Technology, Inc. | Cross-domain network assurance |
US11902082B2 (en) | 2018-06-07 | 2024-02-13 | Cisco Technology, Inc. | Cross-domain network assurance |
US10659298B1 (en) | 2018-06-27 | 2020-05-19 | Cisco Technology, Inc. | Epoch comparison for network events |
US11909713B2 (en) | 2018-06-27 | 2024-02-20 | Cisco Technology, Inc. | Address translation for external network appliance |
US11888603B2 (en) | 2018-06-27 | 2024-01-30 | Cisco Technology, Inc. | Assurance of security rules in a network |
US10911495B2 (en) | 2018-06-27 | 2021-02-02 | Cisco Technology, Inc. | Assurance of security rules in a network |
US11218508B2 (en) | 2018-06-27 | 2022-01-04 | Cisco Technology, Inc. | Assurance of security rules in a network |
US11044273B2 (en) | 2018-06-27 | 2021-06-22 | Cisco Technology, Inc. | Assurance of security rules in a network |
US11019027B2 (en) | 2018-06-27 | 2021-05-25 | Cisco Technology, Inc. | Address translation for external network appliance |
US10904070B2 (en) | 2018-07-11 | 2021-01-26 | Cisco Technology, Inc. | Techniques and interfaces for troubleshooting datacenter networks |
US11805004B2 (en) | 2018-07-11 | 2023-10-31 | Cisco Technology, Inc. | Techniques and interfaces for troubleshooting datacenter networks |
US10826770B2 (en) | 2018-07-26 | 2020-11-03 | Cisco Technology, Inc. | Synthesis of models for networks using automated boolean learning |
US10616072B1 (en) | 2018-07-27 | 2020-04-07 | Cisco Technology, Inc. | Epoch data interface |
US11606301B2 (en) | 2019-04-23 | 2023-03-14 | Hewlett Packard Enterprise Development Lp | Verifying intents in stateful networks using atomic address objects |
US11374980B1 (en) | 2020-01-17 | 2022-06-28 | Cisco Technology, Inc. | Resolution of policy enforcement point by cross correlating other policies |
CN112565193A (en) * | 2020-11-06 | 2021-03-26 | 西安电子科技大学 | Network security policy conflict resolution method, system, storage medium and equipment |
US20230134981A1 (en) * | 2021-10-28 | 2023-05-04 | Microsoft Technology Licensing, Llc | Network configuration verification in computing systems |
US11824727B2 (en) * | 2021-10-28 | 2023-11-21 | Microsoft Technology Licensing, Llc | Network configuration verification in computing systems |
US11516088B1 (en) * | 2021-10-28 | 2022-11-29 | Microsoft Technology Licensing, Llc | Network configuration verification in computing systems |
Also Published As
Publication number | Publication date |
---|---|
EP3216177B1 (en) | 2021-04-14 |
US10992520B2 (en) | 2021-04-27 |
EP3216177A1 (en) | 2017-09-13 |
US20170222873A1 (en) | 2017-08-03 |
EP3216177A4 (en) | 2017-11-22 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10992520B2 (en) | Network policy graphs | |
US11716265B2 (en) | Anomaly detection and reporting in a network assurance appliance | |
Prakash et al. | Pga: Using graphs to express and automatically reconcile network policies | |
US11019027B2 (en) | Address translation for external network appliance | |
CN110785965B (en) | System and method for performing network assurance checks on correct deployment of configurations in a fabric | |
CN112219382B (en) | Ensuring of security rules in a network | |
US10826770B2 (en) | Synthesis of models for networks using automated boolean learning | |
US11902082B2 (en) | Cross-domain network assurance | |
US11038743B2 (en) | Event clustering for a network assurance platform | |
CN110710159B (en) | Methods, systems, devices, and media for network configuration and troubleshooting | |
CN110785964B (en) | Authentication of layer 3 bridged domain subnets in a network | |
US20180139096A1 (en) | Composition constraints for network policies | |
CN111034123B (en) | System, method, and computer readable medium for performing network assurance checks | |
US10572495B2 (en) | Network assurance database version compatibility | |
US10644951B2 (en) | Adding metadata associated with a composite network policy | |
CN110785963A (en) | Collecting network model and node information from a network | |
CN110754063B (en) | Verifying endpoint configuration between nodes | |
US10333833B2 (en) | Endpoint path assurance | |
Asif et al. | ROCA: Auto‐resolving overlapping and conflicts in Access Control List policies for Software Defined Networking |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 14905469 Country of ref document: EP Kind code of ref document: A1 |
|
WWE | Wipo information: entry into national phase |
Ref document number: 15500628 Country of ref document: US |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
REEP | Request for entry into the european phase |
Ref document number: 2014905469 Country of ref document: EP |