Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

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 conflict in network access control. Blue circle: Permit SSH on port 22. Dark blue: Deny ports 1-1024. Red overlap: conflict on 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 security policy interface showing two rules. Rule 1: Deny HTTPS traffic from red_vxlan_32_v4_1 to Default-All port 443. Rule 2: Allow HTTP traffic from red to Default-All port 443. Both 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.

Network security policy interface showing a conflict between two rules: one permits and one denies TCP traffic from virtual network blue_301_leaf3_v4 to blue_vxlan_31_v4 on overlapping ports. Status requires attention.

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

Settings page for configuring security policies with tabs for Security Policies, Security Policy Search, Conflicts, and Settings selected. Conflict resolution options include More specific first selected, More generic first, and Disabled. Default action options are Permit, Permit and Log, Deny, and Deny and Log. Save Changes button to apply settings.

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 selecting Source Point Type with IPv4 Subnet selected, part of network configuration tool.