Belete Ageze 2xCCIE | CCDE

Introduction

This blog post focuses on the concept of ACI contract priority, which is crucial for managing security policies within a Cisco ACI environment. In ACI, contracts are applied in a provider/consumer relationship, where leaf switches program security policies, known as zoning rules, into the Ternary Content Addressable Memory (TCAM). These zoning rules dictate actions such as permit, deny, redirect, or log, based on the source Endpoint Group (EPG), destination Endpoint Group (EPG), and filter criteria. Both the source and destination EPGs are represented by unique class IDs, referred to as pcTags. Zoning rules are configured per Virtual Routing and Forwarding (VRF) instance, each with a unique scope and priority. Each rule has a designated priority, indicated by a numerical value. The priority of a zoning rule is inversely proportional to its numerical value— a zoning rule with a lower value (higher priority) will take precedence over one with a higher value (lower priority). This structure provides a robust and flexible mechanism for controlling network traffic and maintaining security within the ACI fabric.

Class-ID / pcTags

The class ID, or pcTag, of an Endpoint Group (EPG) is a unique identifier used within Cisco’s Application Centric Infrastructure (ACI) to manage and apply contracts or policies to network traffic. This identifier plays a critical role in both intra-fabric communication and interactions between the ACI fabric and external networks. By using the pcTag, ACI can efficiently enforce security policies ensuring that the appropriate rules are applied to the correct traffic flows. This mechanism enables precise and scalable traffic management within the ACI environment, enhancing overall network security and performance.

Class ID are auto assigned based on the following scope:

• Class ID assignment scope:
  • System Reserved pcTag – system internal rules (1-15)
  • Globally scoped pcTag – for shared services (16-16384)
  • Locally scoped pcTag – locally used per VRF (range from 16385-65535)

To verify the pcTag of an Endpoint Group (EPG) in Cisco’s Application Centric Infrastructure (ACI), you can use the following method:

Log in to the APIC -> Navigate to the Tenant -> Operational -> Resource IDs -> EPGs

Zoning Rule and Contract Priority

Zoning rules are the backbone of security policy enforcement within a Cisco ACI fabric. They define how traffic flows between different Endpoint Groups (EPGs). These rules reside on the leaf switches and are programmed based on how contracts are configured.

Let’s delve deeper and dissect the actual output you might see when running ‘show zoning-rule scope <scope>’ command.

The output will typically display a table with several columns, each providing valuable information about the configured zoning rules. Here’s the output and a breakdown of the columns you’ll encounter:

Zoning Rule Selection Algorithm

Rules to Choose between Same Priority Zoning Rules

While contract priorities offer a robust way to manage and enforce security policies in Cisco ACI, there can be scenarios where traffic flow matches multiple zoning rules with the same priority level. In these situations, additional factors come into play to determine which rule takes precedence. Here’s a breakdown of the tie-breaking mechanisms used by ACI:

When multiple contracts (zoning rules) have the same priority, the following table illustrates the priority order.

A contract with a specific protocol, specific source, and destination Layer 4 (L4) port takes precedence, even if other zoning rules share the same priority. Conversely, a contract with unspecified (any) protocol, any source, and destination is considered less preferred, even if it shares the same priority as other rules.

Zoning Rule Priorities

Unenforced VRF

When the VRF’s ‘Policy Control Enforcement Preference’ is set to ‘unenforced’, communication is permitted without configuring any contracts between EPGs or Endpoint Security Groups (ESGs) within the VRF. In this case, the leaf switch programs a zoning rule that allows traffic flow from any source to any destination. The implicit zoning rule output for a VRF with unenforced policy control enforcement preference shows SrcEPG and DstEPG as 0, indicating ‘any’. The leaf programs this zoning rule with priority 21.

vzAny

The priority of the vzAny contract (zoning rule) depends on whether 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 also on whether the zoning rule is between vzAny and vzAny or between an EPG and vzAny.

For priority with vzAny contracts, the following table illustrates the priority order:

Preferred Group

The preferred group feature enables unrestricted communication/access between a subset of EPGs|ESGs in a VRF that are members of the preferred group. Communication between members of the preferred group and non-members follows the regular contract application process.

When a preferred group is configured, deny zoning rule entries are created for each EPG|ESG excluded from the preferred group. These entries are as follows:

Additionally, the preferred group creates a permit zoning rule from any to any with priority 20 (highlighted in green on the ‘show zoning-rule’ output below – Rule ID: 4196). This policy rule allows unrestricted communication between EPGs|ESGs within the preferred group. Communication from non-preferred group member EPGs|ESGs is denied based on deny policy rules with priorities 18 and 19. For communication requirements between non-preferred group member EPGs|ESGs, a specific contract with a priority higher than 18 and 19 must be implemented.

Shared (inter-VRF) Contract

Inter-VRF traffic policy enforcement occurs on the consumer VRF. The provider VRF (as shown in Figure 11) includes an implicit zoning rule allowing inter-VRF traffic from provider EPGs|ESGs to pcTag 14, which is the system-reserved class ID for inter-VRF traffic. This implicit zoning rule permits provider-to-consumer traffic at the provider VRF without the “policy applied bit” being set. Inter-VRF contracts modify the class-ID (pcTag) of an EPG|ESG to a publicly defined range (16-16384).

The consumer VRF has an implicit zoning rule with a priority of 12 that denies traffic from provider EPG|ESG to any destination unless defined by an inter-VRF contract. For instance, Rule ID: 4174, from the ‘show zoning-rule’ output below, denies traffic from EPG|ESG with class ID 25 to any destination unless explicitly allowed by Rule ID: 4108, from the ‘show zoning-rule’ output below, which permits traffic between EPG 25 and EPG 16388 based on the contract Web_App_Contr.

Additionally, the consumer VRF includes zoning rules with priorities 10 and 11 for inter-VRF traffic when the consumer is vzAny. As shown in the ‘show zoning-rule’ output below, Rule IDs 4277 and 4270 facilitate traffic flow from provider EPG to vzAny consumer.

Standard Contract between EPG|ESG

Communication between endpoints in EPG, ESG, or extEPG requires a standard contract. However, communication between endpoints within the same EPG, ESG, or extEPG is allowed without a contract. The priority of the contract depends on the filter’s ethertype setting: if the ethertype is set to “unspecified” (i.e., any), it has a priority of 9; if the ethertype is set to “IP” or another specific ethertype, it has a priority of 7.

Taboo Contract Priority

A Taboo contract is used to deny specific types of traffic from any EPG to an EPG while allowing other traffic to pass through using standard contracts. When a Taboo contract is applied to an EPG or ESG, it takes precedence with a priority of 5, which is higher than the priority of standard contracts applied between EPGs or ESGs.

Intra-EPG Isolation and Contract Priority

Intra-EPG isolation prevents communication between endpoints within an EPG or ESG. This feature is enabled by setting intra-EPG isolation to “enforced” under the EPG Policy > General settings. For instance, Rule IDs 4222 and 4137, from the ‘show zoning-rule’ output below, deny traffic between endpoints within an EPG with a priority of 2 due to this enforcement.

Conversely, an intra-EPG contract allows specific communications between endpoints within an EPG or ESG while intra-EPG isolation is enforced. This is configured under EPG > Contract as an intra-EPG contract. For example, Rule ID 4221, from the ‘show zoning-rule’ output below, allows ICMP traffic between endpoints within an EPG with pcTag 49160, and Rule IDs 4260 and 4186, from the ‘show zoning-rule’ output below, permit port 80 traffic between endpoints within an EPG with pcTag 49155. Intra-EPG contracts have the highest priority of 1, ensuring they override the isolation enforcement for specified traffic types.

Priority for Deny filter

Deny action filters have four different priorities options:

Example scenarios

EPG1 and EPG2 have two contracts, as shown below, applied. Since both are using IPv4 as an ethertype, the priority is the same (7). Based on the section “Rules to Choose between Same Priority Zoning Rules”, deny rules take precedence over permit rules. Therefore, HTTP traffic between EPG1 and EPG2 will be denied.

EPG1 and EPG2 have two contracts, as shown below, applied. Since both are using IPv4 as an ethertype, the priority is the same (7). Based on the section “Rules to Choose between Same Priority Zoning Rules”, permit+log rules take precedence over permit rules. Therefore, any traffic between EPG1 and EPG2 will be permitted and logged, and the action for SSH traffic will be permit+log.

EPG1 and EPG2 have two contracts applied, as shown below. Since both are using IPv4 as an ethertype, the priority is the same (7). According to the section “Rules to Choose between Same Priority Zoning Rules”, a specific destination port wins over a specific source port for permit and redirect action. Therefore, SSH traffic sourced from port 100 between EPG1 and EPG2 will be permitted.

EPG1 and EPG2 have two contracts applied, as shown below. Since both are using IPv4 as an ethertype, the priority is 7 by default, but according to the section “Priority for Deny filter” above, the priority for deny with the ‘lowest priority, option is 17. Therefore, HTTPS traffic between EPG1 and EPG2 will be permitted.

Priority Infographic

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