Cisco ACI – Configuring VMware Integration on the APIC

In the previous article I wrote on Cisco ACI I referenced the Quickstart guide found in the APIC under System>>Quickstart. I wrote about the second step, configuring user accounts. I also wrote an article about creating basic network constructs, such as tenants and bridge domains. In this article I’m going to continue on with the third step in the Quick Start guide which is “Connect to a virtual machine (VM) management system.” This article will solely concentrate on VMware for the most part as that is what’s available with the GA version of ACI as of the writing of this article. Hyper-V integration will be available soon. We’ll also be using the VMware vCenter to do most of this configuration. As of now, ACI is only compatible with versions of vSphere 5.1 and 5.5, and likely vSphere 6 when that is released. As a side note, the APIC can also use vShield to integrate with ACI, but we’ll be talking about that in a future article.

We can use VMware and other virtual or physical platforms with ACI even if we don’t have a solution like vCenter to connect them. It would just be more of a manual process. However when we integrate vCenter and ACI we’re able to automate the processes of creating virtual port groups, for example, which also allows us to manage network policies in VMware through the APIC. Obviously, since a main reason to use ACI is to take advantage of programmability and automation, this is a good thing.

As noted in the Quick Start for Connecting to a VM Management System we must have connectivity to an external network using inband-management network before we create a VMM domain profile. A Virtual Machine Manager domain is a group of virtual controllers (like vCenter) with similar policies associated. So, we’ll go ahead and create that layer 2 connectivity if we haven’t already. I’m assuming the fabric and all other things have been setup at this point. Please see my previous articles or the Cisco documentation for help with this.

Brief Reminder:

1. Click on Tenants, and then click mgmt. (remember mgmt a default tenant)
2. On the left side navigation pane expand Networking
3. Right click on Bridge Domains and click on Create Bridge Domains
4. Give it a name and network.
5. Click on the + next to Subnets and enter the subnet you would like it to use

For the purposes of this article we are going to imagine we have a three tier application that we are trying to set up. Typically, people are familiar with a Web Server, Application Server, and database server that makes up this three-tier app, though it really could be any number of servers and tiers in the real world. We’ll stick with Web, App, and DB for this, though. After we’ve created our Tenant, VRFs, and bridge domains with subnets we’ll go to the VMware vSphere Client. We’ll then go back to our APIC to begin the process of connecting ACI to the VMware vCenter.

1. In the APIC GUI click on VM Networking and select the Policies sub-tab.
2. In the navigation pane on the left select VM Provider VMware.
3. Click on actions and then Create vCenter Domain. A domain is how Cisco refers to any virtual connection, whether it is Hyper-V, Xen, or VMware.
4. Fill in the Name of the vCenter and make sure it matches the name of your vCenter. In this case I’m going to use My-vCenter.
5. Next to VLAN Pool select the drop down arrow and select Create VLAN Pool. These will be the pools that get created on the Distributed Virtual Switch within vCenter.
6. Give the pool a name such as Production_VLAN_Pool and leave Dynamic Allocation selected. This lets the pool creation on vCenter be automated.
7. Then click on the + sign next to Encap Blocks. Add your VLAN range here and click Submit (If you’re used to creating Pools in UCS, this is a lot like that, we are reserving pools for later use).
8. Click the + sign next to vCenter credentials to add the proper credentials for connecting to vCenter.

Figure 1

9. Click the + sign next to vCenter/vShield. Again, we’re not using vShield in this case, but here we’ll enter the vCenter connection information.
10. Give it a name to match your vCenter.
11. Specify the proper IP address for vCenter.
12. You can leave the DVS version at default.
13. Enter the Datacenter information.
14. Choose the associated credential, which we created before this. In this case it’s administrator.
15. Finally click submit to finish the creation of the VM Provider.

This should connect everything at this point. We should be able to verify on the APIC that we have successfully connected to the vCenter management server by clicking on VM Networking again and selecting Inventory this time. If we expand VMware >> vCenter Name (vcva in my case) >> and then click on the datacenter name (also vcva in this case) we can see the VMware information as shown in the figure below.

Figure 2

As you can see in this example I have a vCenter by the name of vcva and its state is Online. Its address is 198.18.133.211 and it is VMware vCenter Server 5.5.0 build-1312298. It also gives me a serial number and tells me how many distributed virtual switches I’m controlling from the APIC. Under Hypervisors it shows two ESX servers, which is what I’m running in my particular lab in this case.

We may also verify the connection on the VMware side, and we should make sure everything is running properly. So let’s log back in to the vSphere client.

1. Log in to vSphere Client.
2. Click on the top drop down menu next to inventory where it says Hosts and Clusters and change it to Networking.
3. Expand your vCenter folder to show a distributed virtual switch, in my case its called vcva. This was created automatically when we created the connection on the APIC.

Figure 3

Now that we’ve created the connection between the APIC and the vCenter we’re able to automate certain things like adding networks and VLANs to vCenter. We’ll be able to add our VMware guests to these networks and they’ll be using the ACI fabric to communicate at that point. All we really have left is to add the ESX hosts to the distributed virtual switch and then create groups and networks to put the VMs on, but we’ll save that for the next blog in the series.

As always if you have any questions or comments, please feel free to leave your comments below or reach out to me on Twitter @Malhoit.