Cisco ACI has a few basic network constructs that need to be created when first being set up. This could be considered more of a day 1 setup and then something you may not need to do again. If you’re familiar with Cisco UCS, it’s akin to creating pools and then creating service profiles with those pools. In this article I’ll go through the ACI equivalent, which is creating tenants, contexts, and bridge domains that will help us get ACI up and running. I’ve already covered creating tenants in a previous blog found here.
In this case we’re going to create a tenant called Production and give it access to both the all and mgmt security domains. Again, see this blog for more info, but here’s how we build the tenant.
- Login to the ACI APIC GUI.
- Click on Tenants from the menu bar.
- Click on Add Tenant from the sub menu bar.
- In Step 1 of the Add Tenant wizard give it a Name, optional Description, optional Tag, optional Monitoring Policy, and a Security Domain. In this case I’m going to use the name Production.
Figure 1
- We can then click Finish and we’ll have a brand new Tenant which we’ll see up in the sub-menu bar.
Next we’ll go through the exercise of building a context, or VRF. This is also called a private layer 3 network.
- Make sure to click on the tenant you just created while Tenants is selected in the main menu.
- Expand Networking and right click on Private Networks. Click on Create Private Network. This network is basically a VRF.
- Give the network a name, such as Production-VRF.
- Leave the rest as default.
- Leave the Create a Bridge Domain checkmark so it will direct us to that wizard automatically.
Figure 2
After we click Next we’re taken to the Create Bridge Domain wizard. A bridge domain is a layer 2 construct, but it’s a little different from what we’ve done in networking in the past. Traditionally we put one VLAN per subnet and that’s how we assign security policies and the like. We make sure to create ACLs in between subnets and the devices in those associated VLANs and subnets may or may not be permitted to communicate. Although, similarly, we can put subnets into bridge domains, they are not the same as VLANs. We can put multiple subnets into bridge domains (actually we can do this with VLANs as well, but we don’t usually). In fact, a bridge domain is just that, a container for subnets. When we create an End Point Group within ACI we must associate them with a bridge domain. EPGs within the same bridge domain may be configured to talk to each other, but do not have layer 2 adjacency enabled by default. However, if layer 2 adjacency is required (for something like vMotion) you may enable this by merely putting a check in a box.
Put more simply, a bridge domain is a container for subnets. They may or may not have layer 2 flooding enabled, based on user interaction.
Now after all that explanation let’s go ahead and create one.
- Give your Bridge Domain a name.
- Click on the + Sign next to Subnets and enter your gateway address (the address of the next hop router) and click update.
Figure 3
This completes creating a tenant, context (or VRF), and bridge domain. Let’s now talk about why we did all of that.
Figure 4
We created a tenant called production. With ACI we can have anywhere from one tenant, which may be useful for a small commercial environment, to 64,000+ tenants, of which a cloud provider would take advantage. Tenants allow us to isolate resources and objects from other tenants. One use case for this would be in the cloud provider world where the provider is giving several companies access to resources but they want to ensure security and isolation. In this case they would assign each company their own tenant. Another use case would be to have a Dev tenant and a Production tenant. In this case we would be able to create network constructs, EPGs, and policies in our Dev tenant and when we’ve created that to our liking, we can simply copy it to the Prod tenant. Not only does this guarantee dev and prod are the exact same, but it takes away the human error that can come along with manually copying these objects.
We then created a VRF, which is sometimes called a Context or even a private layer 3 network in ACI. For the purposes of this article I’ll continue calling it a VRF. You can almost think of a VRF as a router, or even better, a virtual router. With a regular physical router we can’t have more than one interface serve out the same network. We would need to purchase more routers to accomplish this. However, by creating VRFs, we essentially have different route tables within the same physical router and avoid overlapping address spaces. A great use case for VRFs is that it allows us to specify the same networks, but with different default gateways. For example, I might have my production VRF on the same subnet as the Dev VRF, but depending on which VRF you’re in, you’re taken to different places depending on the IP or FQDN to which you browse. Again, this allows us to reduce operational expenses when administering two different VRFs. Another use case would be if we wanted to create a guest network, which may allow guests to access the internet or certain devices on our network, but not everything in your environment.
After creating the VRF we added a bridge domain. The bridge domains give us our layer 2 boundaries. As I said above, bridge domains are containers for subnets and each EPG will be associated with a bridge domain. By default there is no layer 2 adjacency, so no flooding occurs on the network which can potentially increase performance and takes away the potential for broadcasting loops. In the case that we need layer 2 adjacency this can be enabled easily.
In the Cisco Application Centric Infrastructure Design Guide it states:
For the EPG configuration to work, that is, for endpoints to be discovered and EPG to be propagated to the virtual machine manager [in the case of the virtual environment] remember to verify the following:
- Associate the EPG with the bridge domain
- Create a router [or VRF] in the tenant
- Associate the bridge domain with the router…
With all of that, we can now start creating End Point Groups and assigning policies and service graphs to them, which I will cover in a future article. As always, if you have any questions or comments please leave them in the comments section below or reach out to me on Twitter @malhoit.
