Conflicts and Resolution

Overlapping Policies

An overlapping policy is when all the fields in the 5-tuple match another policy. The rules can have the same or different actions, such as “allow” vs. “deny.” The following sections cover different conflicts and resolutions:

• Automatic Access List (ACL) optimization by combining the two matching rules with the same action into a single rule (Shadow Rules)

• Automatic resolution and rule ordering based upon the default Conflict Resolution setting chosen in the Policy Setting

• Manual resolution when policies have overlapping rules with different actions that Apstra can’t auto-resolve.

Shadow Rules

Shadow Rules are policy rules that are covered by another larger policy rule. Consider two different policies:

Policy-A: Rule 10 - Permit SSH from VLAN10 to VLAN20

Policy-B: Rule 20 - Permit TCP 1-1024 from VLAN10 to VLAN20

Since the rule in Policy-A is entirely contained within the rule in Policy-B, the first rule is redundant and does not need to be rendered in the final ACL. When viewing a policy in Apstra, you will see “Shadowing” for rules that are considered Shadow Rules.

Automated Resolution

Apstra can automatically resolve conflicts between multiple policies. This capability is determined by global blueprint settings under Policy Settings, described below.

In this example, Apstra can auto-resolve the conflicts between the two policies.

• Policy-A:

  • Virtual Network `red_vxland_32_v4_1` <--> Virtual network `default-All 0.0.0.0/0`

    • deny TCP 443

• Policy-B:

  • Routing Zone `red` <--> Virtual network `default-All 0.0.0.0/0`

    • deny TCP 443

Manual Conflict Resolution

When Apstra can’t ascertain which rule to use, permit or deny, the conflict is flagged and prompts you to select which rule you want to take priority.

In this example, Apstra can’t ascertain which rule to use: the policy permitting TCP 1-1024 or denying 22-2000. You must resolve the conflict error before you can commit the change to the blueprint.

The policies in this example include:

• Policy-A:

  • Virtual Network ` blue_301_leaf3_v4` <--> Virtual network ` blue_vxlan_31_v4_

  • permit TCP 1-1024

• Policy-B:

  • Virtual Network ` blue_301_leaf3_v4` <--> Virtual network ` blue_vxlan_31_v4_

    • deny TCP 22-2000

Blueprint Policy Settings

Apstra attempts to resolve conflicts automatically based on a few simple settings, which are global on a per-Blueprint basis. The default settings are sane defaults, i.e., more specific rules will be selected, and explicit permit rules are preferred over denying traffic. This setting should be configured once per Blueprint.

You can apply more than one policy to each subnet/endpoint, which means the ordering of rules has an impact on behavior. An implicit hierarchy exists between routing zones, virtual networks, and IP endpoints, so you must consider how policies are applied at different levels of hierarchy. When one rule's match set contains the other's match set (full containment), the rules can conflict. You can set the rules to execute more specific rules first (“exception” focus/mode) or less specific first (“override” focus/mode).

Policy Search

You can search existing policies to determine if a certain type of traffic will be affected by the active combined policies. Your searches can be based on any of the predefined objects, an IP address, or a range of addresses. Examples of searches include:

• Is HTTP traffic allowed from Server-A to Server-B?
• Can any servers route TCP ports 20-21 outside of their subnet?
• What ports are open between the Database and Application virtual networks?