ACI Contract Priority

Belete Ageze 2xCCIE | CCDE

1. Introduction

This blog post will focus on ACI contract priority. Contract is applied in a provider / consumer relationship and a leaf program a security policy (zoning rules) on TCAM (Ternary Content Addressable Memory). Zoning rule entry defines an action (permit, deny, redirect, log) based on the source EPG, the destination EPG, and filter. The source EPG and destination EPG are represented by a unique class ID ( pcTag ). Zoning rules are per VRF, defined with a unique scope and has a priority. The lower the number of the priority, the higher the priority. Zoning rule with the lower value (higher priority) win over zoning rule with a higher value (lower priority). When a traffic between EPGs match more than one zoning rules, the zoning rule priority with some higher level rules is used to decide the action applied on the traffic flow.

ACI contract priority - Tag
Figure 1 – Class ID (pcTag) and Scope information for EPGs
  • Class ID assignment scope:
    • System Reserved pcTag – system internal rules (1-15)
    • Globally scoped pcTag – for shared service (16-16384)
    • Locally scoped pcTag – locally used per VRF (range from 16385-65535)

ACI contract priority
Figure 2 – Zoning rules as shown from the output of ‘show zoning-rule scope <scope ID>’

Rule ID – an ID assigned to a specific zoning rule programmed on TCAM.

SrcEPG – a class ID (pcTag) of a source EPG for the specific zoning rule programmed on TCAM.

DstEPG – a class ID (pcTag) of a destination EPG for the specific zoning rule programmed on TCAM.

FilterID – an ID of a filter entry used by the zoning rule to match against traffic flow between source and destination EPGs to apply an action.

Dir – this column indicates the direction of the zoning rule. uni-dir indicates unidirectional zoning rule. bi-dir and uni-dir-ignore are a paired unidirectional zoning rules. If compression is enabled both bi-dir and uni-dir-ignore use on hardware entry.

operSt – this indicates the operating state of the zoning rule. For zoning rule to function it should show as “enabled”.

Scope – this is a unique identifier of the VRF the zoning-rule is operating.

Name – a name of the contract used to program the zoning rule.

Action – an action (deny, permit, redirect, log) the leaf switch will do if traffic flow matches the zoning rule entry.

Priority – the order of preference for zoning rules to apply on a traffic flow with multiple rules match. The lower the number, the higher the priority.

2. Rules to Choose between Same Priority Zoning Rules

If traffic flow matches multiple zoning rules with same priority level the following rules apply.

  • Deny + log wins over deny. Deny wins over redirect or permit
  • Between permit and redirect
    • A specific protocol wins over any
    • A specific L4 destination wins over a L4 specific source (for permit and redirect only)
    • Between redirect and permit, if the filters are the same, redirect wins over permit
    • If there’s the same level of specificity the result is not deterministic, hence this configuration should not be used
  • Rules with the log option win over rules with compression
  • Rules configured for compression are hit before the ones that have no compression enabled
  • “Default” is of higher priority than “implicit”

The following table shows the rules used when multiple contracts (zoning rules) have the same priority. A contract with specific protocol, specific source and destination L4 port is preferred even if the zoning rule has the same priority. A contract with unspecified (any) protocol, any source and destination is less preferred even if the zoning rule has the same priority.

ACI contract priority - L4 ports
Figure 3 – Priority based on source and destination L4 ports specificity

3. Zoning Rule Priorities

3.1 Unenforced VRF

When the VRF’s ‘Policy Control Enforcement Preference’ is selected as ‘unenforced’, communication is allowed with out configuring any contract between EPGs|ESGs within a VRF. The leaf switch programs a zoning rule which allows traffic flow from any source to any destination. The following implicit zoning rule output shows for a VRF with unenforced policy control enforcement preference. The SrcEPG and DstEPG are showing as 0, which means any. The leaf programs a zoning rule with priority 21.

ACI contract priority - unenforced
Figure 4 – Zoning rule for VRF with unenforced policy control.

3.2 vzAny

vzAny contract (zoning rule) priority depends on if the filter has the ethertype set to “unspecified” (i.e. any)  or if the filter has the ethertype set to “IP” (or other specific ethertypes) and whether the zoning rule is between vzAny and vzAny or between EPG and vzAny.

ACI contract priority - vzAny
Figure 5 – vzAny zoning rule priorities

Figure 6 – vzAny to vzAny contract priority with specific ethertype
Figure 7 – vzAny to vzAny contract priority with ethertype unspecified
Figure 8 – vzAny to EPG, EPG to vzAny contract priority with ethertype unspecified and IP

3.3 Preferred Group

Preferred group allows unrestricted communication/access between a subset of EPGs|ESGs in a VRF that are member of the preferred group. Communication between members of the preferred group and non-members uses the regular contract application.

Preferred group creates a deny zoning rule entries for each EPG|ESG excluded from the preferred group. The entries are:

  1. From any to EPG|ESG excluded from preferred group with priority 19 (Rule ID: 4225)
  2. From EPG|ESG excluded from preferred group to any with priority 18 (Rule ID: 4265)
  3. Implicit deny rule for traffic from VRF class ID to any (Rule ID: 4184). This entry is to deny traffic from L3Out EPG with 0.0.0.0/0 subnet to any in the VRF.
  4. Implicit deny rule for traffic from any to 15 (Rule ID: 4274). Always created unless a VRF is in unenforced mode. The priority changes to 19 from 22 with a preferred group. L3Out EPG with 0.0.0.0/0 subnet uses Class ID 15 when used as a distention.

The preferred group also creates a permit zoning rule from any to any with priority 20 (shown in green on the ‘show zoning-rule’ output below – Rule ID: 4196). The policy rule is used to allow a free communication between EPGs|ESGs within the preferred group since the none preferred group member EPGs|ESGs are denied based on deny policy rule with priority of 18 and 19. For any communication requirements of none preferred group member EPGs|ESGs, a specific contract with better priority than 18 & 19 need to be implemented.

ACI contract priority - preferred group
Figure 9 – Preferred group zoning rule priorities

ACI contract priority - preferred group
Figure 10 – Zoning rules programmed because of preferred group configuration

3.4 Shared (inter-VRF) Contract

Inter-VRF traffic policy enforcement happens on the consumer VRF. The provider VRF (Figure 11) has an implicit zoning-rule to permit inter-VRF traffic from the provider EPGs|ESGs to pcTag 14 (the system-reserved class ID for inter-VRF traffic). With the implicit zoning rule, the provider-to-consumer traffic is permitted at the provider VRF without “policy applied bit” set. Inter-VRF contract modify the class-ID (pcTag) of an EPG|ESG to a public defined range (16-16384).

Figure 11 – Zoning rules programmed on the provider VRF because of inter-VRF contract

The consumer VRF has an implicit zoning rule of provider EPG|ESG to any with a priority of 12 to deny traffic not defined with inter-VRF contract. Rule ID: 4174 is an implicit zoning rule to deny traffic from EPG|ESG with class ID 25 to any with priority 12 that are not allowed by Rule ID: 4108 which allow traffic between EPG 25 and EPG 16388 based on contract Web_App_Contr.

Consumer VRF has priority 10 and priority 11 zoning rules for inter-VRF traffic when the consumer is vzAny. The Rule ID 4277 and 4270, on Figure 12, are used for provider EPG to vzAny consumer traffic flow.

ACI contract priority - inter-VRF
Figure 12 – Inter-VRF zoning rule priorities
Figure 13 – Zoning rules programmed on the consumer VRF because of inter-VRF contract

3.5 Standard Contract between EPG|ESG

Communication between endpoints in EPG|ESG|extEPG requires a standard contract. Communication between endpoints with in EPG|ESG|extEPG is allowed without contract. Priority depends on if the filter has the ethertype set to “unspecified” (i.e. any)  or if the filter has the ethertype set to “IP” (or other specific ethertypes). Ethertype set as unspecified has a priority 9 and ethertype set to “IP” (or other specific ethertypes) has a priority of 7.

ACI contract priority - standard
Figure 14 – EPG|ESG to EPG|ESG zoning rule priorities.

Figure 15 – Zoning rules priority for EPG|ESG to EPG|ESG contract

3.6 Taboo Contract Priority

Taboo contract denies specific services traffic to an EPG while allowing other traffic using standard contract. Taboo contract applied on EPG|ESG has a priority of 5, that’s a higher priority than standard contracts applied between EPGs|ESGs.

Figure 16 – Zoning rules priority for taboo contract applied to EPG|ESG

3.7 Intra-EPG Isolation and Contract Priority

Intra-EPG isolation denies communication between endpoints with in an EPG|ESG. Enabled by choosing intra-EPG isolation to enforced under the EPG Policy > General. Rule-ID:4222 and 4137 deny traffic between endpoints within EPG with priority of 2 due to intra-EPG isolation enforcement.

Intra-EPG contract allows communications between endpoints within EPG|ESG while intra-EPG isolation enforced. It’s applied under EPG >Contract as intra-EPG contract. Rule-ID:4221 allows ICMP between endpoints in EPG with pcTag 49160 and Rule-ID:4260 & 4186 allows port 80 between endpoints in EPG with pcTag 49155. Intra-EPG contract has a priority of 1.

Figure 17 – Zoning rules priority for intra-EPG isolation and contract

3.8 Priority for Deny filter

Deny action filters have four different priorities options.

  1. default level – it is the same as the classification outlined above and is the same as the priority in case of permit for the same EPG pair.
  2. lowest priority – equivalent of any-any rules with ethertype specified (any_any_filter) which is 17.
  3. medium priority – equivalent priority of src EPG to any rules or any to EPG rules with ethertype specified (src_any_filter or dst_any_filter) which is 13 or 14.
  4. highest priority – equivalent priority of src EPG to dst EPG with ethertype specified (fully_qual) which is 7.

ACI contract priority - Deny options
Figure 18 – Deny action filters priority options

Figure 19 – deny action with default level
Figure 20 – deny action with lowest priority

ACI contract priority - medium priority
Figure 21 – deny action with medium priority

Figure 22 – deny action with highest priority

4. Example scenarios

4.1 EPG1 & EPG2 have two contracts, shown below, applied.  Since both are using IPv4 as an ethertype the priority is the same (7). Based on section 2 above deny wins over permit so http traffic between EPG1 and EPG2 will be denied.

ACI contract priority - example

4.2 EPGX & EPGY have two contracts, shown below, applied.  Since both are using IPv4 as an ethertype the priority is the same (7). Based on section 2 above permit+log wins over permit for ssh traffic between EPGX and EPGY.

4.3 EPG1 & EPG2 have two contracts, shown below, applied.  Since both are using IPv4 as an ethertype the priority is the same (7). Based on section 2 above a specific destination port wins over a specific source port for permit and redirect action. Permit wins for ssh traffic sourced from port 100 between EPG1 and EPG2.

4.4 EPGX & EPGY have two contracts, shown below, applied.  Since both are using IPv4 as an ethertype the priority is 7 by default but based on section 3.8 above the priority for deny with lowest priority is 17. Permit wins for https traffic between EPGX and EPGY.

ACI contract priority - example

5. Priority Infographic

ACI contract priority - infographic

6. Reference

https://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/white-paper-c11-743951.html#contract_priorities

A blog post on ACI contract fundamentals

1 thought on “ACI Contract Priority”

Leave a Comment

Your email address will not be published. Required fields are marked *