Cisco ACI – Creating Contracts

Part of the beauty of Cisco Application Centric Infrastructure is the idea of contracts. In ACI we talk a lot about the idea of the policy driven network. Those policies are what we call contracts. Contracts aren’t totally unlike ACLs, but there are some big differences. First, ACLs usually go between IP addresses or subnets, while contracts are between End Point Groups and they are not concerned with specific IP addressing. ACI is also a white list model, so contracts usually allow traffic while ACLs spend a lot of time denying traffic on a traditional network. Finally they can be easily made bidirectional, meaning they can apply the same policy from your web EPG, for example, to your app EPG, and vice versa. You can make it bidirectional by simply clicking a checkbox, instead of writing several more ACLs to make it work.

Let’s go through some basic terms before we get started.

Filter: The traffic you want to manage, or more specifically the protocols you want to permit. For example, you may want to permit https traffic.

Action: What you’re planning to do with the filter. While I said usually this will be a permit action, we do allow for other actions.

• Permit – allows traffic
• Deny (Taboo) – Specific use case, probably during a migration from traditional networking to ACI. In this case you may specify to allow all traffic in a contract, but set up taboos to deny certain traffic.
• Redirect – This may be useful to send traffic from an EPG to a layer 4-7 device such as a firewall, load balancer, or IPS/IDS.
• Mark – You may want to mark traffic for Quality of Service reasons

Label: An optional advanced identifier. When you use labels you can specify more complex relationships between end points

Subject: contains a Filter, Action, and optional Label.

Contract: contains one or more Subjects.

As stated before a contract is placed between two EPGs as shown in the picture below.

Figure 1

These contracts provide a basic stateless firewall between two EPGs. The question I get a lot is “what if I need stateful firewalls or more of a next generations firewall to do application traffic monitoring?” Well, you can do that, too, but you’ll need to use service graphs, which are beyond the scope of this article.

Let’s move on to how we create contracts. We’ll start by creating filters, being the protocols we’re using to allow traffic between two EPGs. For this example we will create a filter for a contract that will go between a Database EPG and an Application EPG. In this example, the database EPG (DB-EPG) will be providing database services to the Application EPG (App-EPG), using port 1433 as a common MS SQL port.

Create Filter:

1. Log in to your APIC
2. Click Tenants and make sure to select the tenant you’re going to use (for more info: https://techgenix.com/cisco-aci-creating-basic-network-constructs/)
3. Expand Security Policies on the Left Navigation Tree
4. Select Filters
5. Right click on Filters and select Create Filter
6. In the pop-up give it a name such as “DB-Filter”
7. You can put in an optional description
8. Click the + sign next to Entries to add a new filter
9. Put in a name such as MSSQL
10. The configurations here will depend on what you’re trying to do. You may want to speak with your firewall administrator to see what is recommended. For this example I will use IP as my Ethertype.
11. I will select TCP as my IP Protocol
12. For my destination ports I’ll type in 1433. Notice I can use the pull down to select ports that are already available, but I don’t have to. I can enter anything I want, just be careful that you don’t hit TAB or it will change the value in this field.

Figure 2

13. Click Update
14. Click Submit

Now that we have the Filter created we can create a Contract in which to put it. Keep in mind, I’m assuming you already have two EPGs, in this case we’re using DB-EPG and App-EPG. For more information on creating EPGs check here.

Create contract:

1. While still in your tenant expand Security Policies
2. Select Contracts
3. Right click on Contracts and click Create Contract. Notice there was an Export Contract there as well, which will let you export the XML or JSON code for later use with the REST API (read: automation)
4. Give it a name such as DB-Contract-MSSQL
5. Give it an optional description
6. Click the + sign next to subjects (remember a subject contains a filter, object, and optional label)
7. Give the subject a name, such as MSSQL-Subject
8. We can leave the two check boxes checked as they will allow for bidirectionality. However, if we only want to apply these filters unidirectionally from provider to consumer we can uncheck these.
9. Click the + Sign next to Filters and select the filter we created in the last step (DB-Filter)
10. Click Update
11. Click OK
12. Click Submit

Figure 3

We have an App-EPG and a DB-EPG, we also have a contract created, so to complete our Application Network Profile, we need to attach our contract between the EPGs.

Create and Application Network Profile:

1. Right click on your DB-EPG
2. Select Add Provided Contract
3. In the pull-down menu select the contract you just created
4. Click Submit

Figure 4

5. Now right click on your App-EPG
6. Select Add Consumer Contract
7. In the pull-down menu select the contract you just created
8. Click Submit

Now if you click on the Application Profile that contains these to EPGs and Contract we see the topology where DB-EPG allows App-EPG to see traffic over port 1433.

Figure 5

Of course this is how you do it all manually. As I’ve mentioned here this can all be done using REST APIs.

Here is what the filter creation looks like in XML. You only need to input this in something like Postman to create the filter automatically (as well as have the correct URL path for your environment).

{
“vzFilter”:{
“attributes”:{
“dn”:”uni/tn-Test_ACI/flt-MSSQL-Filter”,
“name”:”MSSQL-Filter”,
“rn”:”flt-MSSQL-Filter”,
“status”:”created”
},
“children”:[
{
“vzEntry”:{
“attributes”:{
“dn”:”uni/tn-Test_ACI/flt-MSSQL-Filter/e-MSSQL”,
“name”:”MSSQL”,
“etherT”:”ip”,
“prot”:”tcp”,
“dFromPort”:”1433″,
“dToPort”:”1433″,
“rn”:”e-MSSQL”,
“status”:”created”
},
“children”:[

]
}
}
]
}
}

Here’s what the contract creation looks like after we’ve created the filter. Again, this will automatically let you do this. Of course, you can re-use the same object names, but it’s really easy to go through and find something like MSSQL-Contract and change that to Web-Contract, for example.

{
“vzBrCP”:{
“attributes”:{
“dn”:”uni/tn-Test_ACI/brc-MSSQL-Contract”,
“name”:”MSSQL-Contract”,
“rn”:”brc-MSSQL-Contract”,
“status”:”created”
},
“children”:[
{
“vzSubj”:{
“attributes”:{
“dn”:”uni/tn-Test_ACI/brc-MSSQL-Contract/subj-SUBJ-MSSQL”,
“name”:”SUBJ-MSSQL”,
“rn”:”subj-SUBJ-MSSQL”,
“status”:”created”
},
“children”:[
{
“vzRsSubjFiltAtt”:{
“attributes”:{
“status”:”created”,
“tnVzFilterName”:”DB-Filter”
},
“children”:[

]
}
}
]
}
}
]
}
}

Don’t be nervous if you’re confused by the REST API part of this article. That will make sense with time. Try to understand the first part where you’re going through the GUI. The GUI can do everything anything else can do and will help you understand the logic model as you’re moving along. If you have questions about any of this blog, please leave your comments below or reach out to me on Twitter @malhoit.