Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Conflicts and Resolution

Juniper Apstra supports multiple policies applied to a single Blueprint. When conflicting or overlapping rules are present, a few different results occur. In some cases, Apstra can automatically resolve the policy conflict, while in other instances, user intervention is required to resolve the conflict. Let’s look at some of these instances in more detail.

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.

Venn diagram showing a conflict in network security rules: permit SSH port 22 and deny ports 1-1024, including port 22.

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


Network policy configuration interface with two rules: DenyHTTPS denies TCP traffic from virtual network red_vxlan_32_v4_1 to external endpoint on port 443. AllowHTTP permits TCP traffic from routing zone red to external endpoint on port 443. Both rules auto-resolved by AOS.

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.


Security Policies tab in a network tool displays two rules: "www-to-db-permit / permit-tcp-db" allows TCP traffic, and "www-to-db-deny / permit-tcp-db" blocks TCP traffic, both from blue_301_leaf3_v4 to blue_vxlan_31_v4. Conflict indicator shows a red exclamation mark due to overlapping rules.

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).


Configuration interface for managing security policies with tabs for navigation. Security Policies section shows selected options: More specific first for conflicts resolution and Permit for default action. Save Changes button and dropdown menu with options for Policies, Policy Search, Conflicts, and Settings are visible. Green checkmarks indicate active or configured sections.

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?

User interface for querying network security policies with options to specify Source and Destination Point Types including IPv4 Subnet and protocol selection.