Cisco ACI Contracts

Contracts Definitions

Contracts are policies i.e rules intended to regulate the communication between EPGs and between an EPG and an external device.

A Contract contain Subjects and Labels. Each Subject points to one or more Filters. A Filter contains an Action.

A Contract can be as simple as one Subject with one filter or complex with many subjects and filters. In fact, a Network Engineer has some flexibility to design the ACI contracts: one filter per subject, all filters under the same subject, etc. The more granular the contract design, the more it is possible to apply network policies such as QoS policies.


A Subject can be seen as a function. An example of this would be a web server providing HTTP, HTTPS and FTP services. A subject can be configured with labels. The Use of labels is to sort of restrict the act of consuming a contract to the EPGs that have a matching label value.


  • A filter is reusable across many contracts.
  • Many customers design filters under the tenant common.

The Action can take one of the following values:

  • permit
  • deny
  • log
  • mark
  • QoS
  • redirect
  • service graph

Provided Contracts and Consumed Contracts

  • A contract is like a service or group of services that can be associated to an EPG, depending on whether the EPG will provide or consume the services.
  • We distinguish a <Consumer, Provider> pair for each contract. In other words, a contract is provided by an EPG and consumed by another EPG. Here is a hint when selecting which EPG is the provider and which is the consumer: the EPG who generates the traffic is the contract consumer. And so, the traffic direction is “opposite” to the contract generation.
  • To define Ping capability between two end hosts (for example Web server and internal Web client) in two EPGs, the Network Engineer configures a contract with one subject and one ICMP filter. Then he configures one of the EPGs as consumer and the other as provider. And it does not matter if the Web client EPG is the contract consumer or provider.
  • a contract can be leveraged by more than one EPG, i.e
    • an EPG A and an EPG B can provide the same Contract.
    • EPG C, D and E can consume the same Contract
  • can be used by an EPG as an intra-EPG Contract, to allow/deny selected traffic between endpoints in the same EPG.
    • intra-EPG Contracts are not supported by Cisco AVS for VMware.
  • A particular kind of contracts is called Taboo. A Taboo defines a list of deny actions and is applied to an EPG, i.e that EPG will be denied access to these ressources. Taboos enforce the black list model used particularly by clients migrating their infrastructure to ACI.
  • When both a taboo and a contract are applied to an inter-EPG relation, the taboo directives take precedence.
  • Using the default contract between EPGs is equivalent to using a blacklist model.
  • to enable communication between EPGs on two different tenants, and if the required contract is not on the tenant common:
    • the contract scope must be set to global
    • the contract must be exported from the Tenant in which the provider EPG resides
    • the contract must be imported as a consumed contract interface. The term consumed contract interface refers to a contract that was exported and which is going to be consumed. It does not have a different configuration than a normal contract.

Contract Scope

A contract has a scope. The scope value can be set to one of the following values:

  • Application Profile: the contract will be invokable only within the Application Profile
  • VRF: the contract will be invokable only within the attached VRF
  • Tenant: the contract will be invokable only within the tenant
  • Global: the contract will be invokable throughout the ACI fabric.

Configuring Contracts

We concentrate on creating a standard contract. Remember that Taboos are also a type of contracts.

To configure a contract:

  • set yourself under the desired tenant
  • Contracts -> Contracts -> Rightclick on Standard -> Create a Contract:

Name the contract and specify a scope. We will set a scope of Global

Create Subjects and Filters

Click on the + sign to add one or more Subjects. I am creating in this example only one subject:

Name the Subject, and click the + sign to add one or more filters:

There are a bunch of predefined filters for us. I am going to define my own filter. So I click on the drop down list:

Then on the + sign above the word “tenant”:

I name the filter and click the + sign to add one or more entries:

Since this subject provides HTTP service, I define a filter entry this way:

Then click Update:

So I’ve defined a filter entry for HTTP service. That’s all I need for now. I click OK to exit the Filter configuration menu and find myself at the Subject configuration menu:

I forgot to add a filter for HTTPS traffic, because I am intending to configure an EPG later to provide both HTTP and HTTPS services. No problem; I can always add as many filters as I want in a subject, at any point in time:

  • Open the Subject configuration menu
  • under Filters click the + sign
  • in the drop-down list go to the bottom and select create Filter

Then parameter your filter for HTTPS and update:

The new filter appears right away:

Exiting from the Subject configuration menu I return to the Contract configuration menu. There I see my created subject:

Finally I submit the contract to create it.

What if I wanted only one filter per Subject? I am going to delete the HTTPS filter, create another subject under the contract and define a new HTTPS filter under it.

But my Subject name includes HTTP and HTTPS, so it will be misleading.

That is why I am deleting the subject and recreating it:

Notice that I was able to re-use the filter HTTP I defined earlier:

When I click on the small symbol I can see the filter settings:

and so I have created a contract with two subjects:

By the way, our created filters are stored under Contracts -> Filters

And I can create filters separately from contrats or subjects:

Configuring EPGs to Provide and/or Consume Contracts

Contracts take effect only when they are provided and/or consumed by EPGs.

Configuring an EPG to Provide a Contract

The setup is as follows: Bouga_T/Fomula1_ANP/Bellar_EPG will provide a contract of HTTP and HTTPS services.

I also can define one label for the contract and one for the subject:

The graphical topology within the Application Profile looks like this:

Configuring an EPG to Consume a Contract

Contract Consumption Between EPGs Within the same Tenant

I want Bouga_T/Formula1_ANP/Plastik_EPG to consume Web_services_C from Bouga_T/Formula1_ANP/Bellar_EPG.

In our case, all contract scopes but VRF would have given the same result of having the possibility for Plastik_EPG to see the contract Web_services_C, because both Plastik_EPG and Bellar_EPG:

  • are in the same Application Profile
  • are in the same Tenant.

Defining Provided/Consumed Contract while EPG Creation

In the Application Profile menu, while creating EPGs, we can specify which contract an EPG provides and/or consumes:

Contract Consumption Between an Internal EPG and an External EPG, Both on the Same Tenant

In order to allow communication between an internal EPG and an external EPG as part of a L3out networking block, we need one or more contracts between them. With contracts between internal and external EPGs, we can control the granularity and type of resources the external subnet ID have access to.

For example, an ACI-external user wants to access web services on the ACI fabric. So one of our internal EPG is providing the web services; he has a provided Contract for web:

Which invokes the subject subj1, which itself invokes the filter http-F:

and we set the external EPG to consume this same contract:

Our external EPG now has a consumed contract defined; it can consume the services specified in this contract.

Contract Consumption Between EPGs on Different Tenants

It is not enough for this purpose to set the contract scope to global; We must export the contract too.

The setup is as follows: Juices_T/Juices_ANP/Orangina_EPG will consume the HTTPS service provided previously by Bellar_EPG. That means, Juices_T/Juices_ANP/Orangina_EPG will consume the contract Web_services_C defined in Tenant Bouga_T.

First I export the desired contract from the Bouga_T tenant:

I name the exported contract to something meaningful to me, and choose the destination tenant:

The newly created contract appears under the standard contracts section. The column Exported Tenants is misleading; It refers to the destination tenant actually. Cisco should have named it “Exported TO tenants”:

The exported contract is injected automatically into the folder Contracts -> Imported of the destination tenant:

Now I go under the EPG and configure it to consume the imported contract:

As I have defined the scope of our desired contract to Global, I was able to see it in the drop-down list:

The contract gets added under the Contracts directory, under the consumer EPG:

Contract Inheritance


  • EPG_A has contracts (either consumed and/or provided), and
  • EPG_A is defined as Contract Master for EPG_B, and
  • EPG_A and EPG_B are in the same tenant


  • EPG_B inherits dynamically all EPG_A’s contracts, and
  • if EPG_A changes any of its contract policies
    • then the changes are mirrored on EPG_B, and
    • Taboos + intra-EPG contracts + Vzany contracts are not inherited.

Click here to read the rest of my Cisco ACI study notes.

Be First to Comment

Leave a Reply

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