Rayas, It is all about Networking & Security: ACI Contract

Introduction

In ACI, Endpoints on different EPGs can’t communicate with each other unless a contract has been configured. A contract is therefore basically an ACL to allow or deny communications between EPGs.

Communication between Endpoints in the same EPG (Intra EPG) is by default allowed.

Contracts consist of one or more subjects. Each subject contains one or more filters. Each filter contains one or more entries. Each Entry is equivalent to a line in an Access Control List (ACL) that is applied on the leaf switch to which the endpoint within the EPG is attached.

Filter's entries (ACL) are used to classify traffic on which the contract will be applied. There are several defaut filter defined in the Common Tenant
Subjects are used to allow or deny traffic classified by ACLs

The following figure shows two filters were created

TEST_FILTER with 2 entries (ACL) POP3_ACL and DNS_ACL. These 2 entries classify POP3 and DNS traffic.

TEST_Filter2 with 2 entries (ACL) HTTP_ACL and HTTPS_ACL. These 2 entries classify HTTP and HTTPS traffic.

The following figure shows a contract with one Subject TEST_Subject was Created. TEST_Subject contains 2 filters previously created TEST_Filter and TEST_Filter2.

Traffic classified by TEST_Filter will be permitted
Traffic classified by TEST_Filter2 will be droped

Consumed Vs Provided Contract

A contract is applied to an EPG either as a Consumer or a Provider. Let’s take for example a contract that permit HTTP traffic to Wed Servers, this contract will be applied as fellow:

EPG Web will be the Provider.

EPG User will be the consumer.

Bellow figure shows how to configure EPG Web as a contract Provider.

Bellow figure shows how to configure EPG User as a contract Consummer.

Contracts are unidirectional. In the example above the configured contract will only permit EPG User to initiate HTTP sessions to EPG Web. If we need EPG Web to initiate sessions to EPG User, another Contract is needed where EPG User will be the Provider and EPG Web will be the Consumer.

Contracts are Stateless by nature. In the example above the contract will permit traffic from EPG User to EPG Web on destination TCP Port 80 only, in order to permit the response from EPG Web to EPG User, we have to check the Apply Both Directions and Reverse Filter Ports options in the Contract Subject configuration. By default these two options are chcked.

Apply Both Directions: the contract is checked for packets in both directions (from Consumer to Provider and from Provider to Consumer). When this option is not checked, Contract is only checked for traffic from Consumer to Provider, therefore, another contract with SRC PORT 80 is needed (EPG User as a Provider and EPG Web a consumer) to allow return packets.

Reverse Filter Ports: an exact reverse Filter rule is automatically created to allow packets from the Provider to the Consumer (the reply packets), This makes the contract emulate Stateful Firewall.
This option is only available if Apply Both Directions is checked. If the option is unchecked, a manual reverse filter must be created in the Contract to allow return packets.

Contract Scope

A contract has scope. A contract will not be consumed by any EPG outside the scope of the provider EPG.

There are 4 types of Contract Scope:

Application Profile: Can be applied for any EPG within the same Application Profile

VRF: Can be applied for any EPG within the same VRF

Tenant: Can be applied for any EPG within the same Tenant

Global: Can be applied for any EPG within the Fabric

A contract created in a Tenant is visible to any EPG within this Tenant, exception for this, contract created in the Common Tenant which are visible to any EPG throughout the fabric.

The scope of a Contract must be chosen carefully in order to avoid permitting communications between non intended EPGs. In the example bellow, the goal is to permit communication between EPGs within each VRF only, but due to Contract C Application Profile Scope, inter VRF communication is also allowed. The Scope should be set to VRF here.

To allow inter Tenants communications, let’s say between EPG1 in the Tenant TNT1 and EPG2 in the Tenant TNT2, fellow this steps:

Step 1: Create a Contract with Global Scope in Tenant TNT1.

Step 2: Export the Contract to Tenant TNT2.

Step 3: Add the Contract to EPG1 as a provided Contract.

Step 4: Add the Contract to EPG2 as a Consumed Contract Interface.

EPG Label

A Contract Label adds another control level for communication between EPGs. Communication is allowed between 2 EPGs if:

A contract is configured.

Consumer EPG label match Provider EPG Label.

Label concept can be used to simplify Contract configuration. Suppose we have 4 EPGs EPG1, EPG2, EP3 and EPG4. EPG1 should communicate only with EPG2, and EPG3 should communicate only with EPG4. For this we must configure two contracts C1 and C2 as illustrated in the following Figure:

With the use of Labels, we need only one Contract, EPG2 will only consume the Contract provided by EPG1 because Label RED match and EPG2 will only consume the Contract provided by EPG1 because Label BLUE match.

Labels are configured at EPG instance level in the APIC.

Several Labels can be attached to an EPG. There is 4 match type that can be configured: ALL, AtleastOne, AtmostOne, and None. The Label matching algorithm details can be found in this document

https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/aci-fundamentals/b_ACI-Fundamentals/b_ACI-Fundamentals_appendix_01001.html

In the example bellow, there is a match, EPG1 and EPG2 can communicate with each other.

In the example bellow, there is not a match, EPG1 and EPG2 can’t communicate with each other.

Match Type for EPG Label is configured is configured at EPG instance level in the APIC GUI.

Subject Label

Subject Label allow to specify which subjects of a contract an EPG can Provide or Consume. To configure Subject Labels fellow the following steps:

Step 1: at the Subject instance level, attach one or more labels.

Step 2: at the EPG instance level, define which Subjects of the Contract EPG should Provide or Consume. In the example bellow, EPG1 will consume or Provide all subjects with labels named RED.

Taboo Contract

Taboo Contract is used to deny a traffic that was allowed by another contract. Taboo contract denies matching traffic toward EPG where it attached. Taboo rules are applied before standard Contract rules

In the example bellow, TCP Ports 100 to 300 are allowed toward EPG2 and TCP Ports 100 to 300 except 200 are allowed toward EPG3, the Contract configuration for this use case will be:

Create a single standard contract to allow TCP Port 100 to 300. EPG1 will be the Consumer, EPG2 and EPG3 the Provider.
Create a Taboo Contract to deny TCP Port 200 and attach it to EPG3.

There is no consumer/provider relationship needed to complete the contract flow. The taboo contract will insert a deny specific to that endpoint group once it has been associated to an endpoint group.

Taboo Contract are configured much like standard Contract

There is no option to configure Permit or Deny in Taboo Contract Subjects. Taboo contract only denies specified traffic

Taboo Contract is associated at EPG instance level and is allways Provided

VzAny Feature

VzAny is Managed Object used to group all EPGs in a VRF including L2Out and L3Out, instead of associating a contract to each EPG, the contract will be associated to VzAny Object. VzAny can be a Contract Consumer, a Contract Provider or Both.
The interest of using VzAny is twofold:

Ease of configuration management
Optimize hardware ressources comsumption. A contract is applied to a group of EPGs rather than to each single EPG in the VRF

VzAny Object, “EPG Collection for VRF” , is located under VRF instance, Contracts are added to this object.

It is worth to note that if the contract scope is set to application-profile, the vzAny configuration is ignored and filter rules are expanded; CAM utilization is the same as if specific consumers and providers are deployed. In this case, there is no saving in CAM usage.

Preferred Group

EPGs in VRF included in a Preferred Group can communicate freely with each other without the need of Contract and even if Policy enforcement is enabled.

EPGs in VRF excluded from a Preferred Group still needs Contract to communicate with each other.