- Contracts are policies i.e rules intended to regulate the communication between EPGs and between an EPG and an external device.
- Contracts contain Subjects, Labels, Filters and Actions.
- 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.
- The Action can take one of the following values:
- service graph
- Can be as simple as one Subject with one filter or complex with many subjects and filters.
- A filter is reusable across many contracts.
- Many customers design filters under the tenant common.
- 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.
- 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.
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.
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:
- 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.