ACI has the ability to divide the fabric up into multiple tenants, or multiple VRFs within a tenant. If communication is required between tenants or between VRFs, one common approach is to route traffic via an external device (e.g. a firewall or router). However, ACI is also able to provide inter-tenant or inter-VRF connectivity directly, without traffic ever needing to leave the fabric. For inter-VRF or inter-tenant connectivity to happen, two fundamental requirements must be satisfied:

Routes must be leaked between the two VRFs or tenants that need to communicate.

Security rules must be in place to allow communication between the EPGs in question (as is always the case with ACI).

The 1.1(1j) & 11.1(1j) release of ACI introduced support for transit routing. Prior to this, the ACI fabric acted as a ‘stub’ routing domain; that is, it was not previously possible to advertise routing information from one routing domain to another through the fabric. I covered L3 Outsides in part 9 of this series where I discussed how to configure a connection to a single routed domain. In this post, we’ll look at a scenario where the fabric is configured with two L3 Outsides and how to advertise routes from one to another. Here is the setup I’m using:

Everything I’ve shown so far in this blog series has been focused on using the APIC GUI to achieve what we need. This is fine for small environments or for becoming familiar with ACI, but what if you need to configure 100 tenants, each with 50 EPGs, tens of private networks and bridge domains, multiple contracts to allow traffic and a L3 Outside or two thrown in? Configuring all of that through the GUI is clearly going to be massively time consuming and probably quite error prone, so we need to find a better way of doing things. ACI has a wide variety of programmability options that can be used to automate the provisioning of the fabric and its policies.

So far in this series, everything we have discussed has been concerned with what happens inside the ACI fabric. At some point however, you will want to connect your fabric to the outside world, either at layer 2 or layer 3. In this part, we’ll take a look at how to set up layer 3 connectivity from ACI to an external router, using a construct called the Layer 3 Outside.

Let’s first take a look at the topology I’m going to discuss in this post:

In part 6, we discussed access policies and how they are used to provision ports.

Last time out in part 7, I walked through setting up basic connectivity between two bare metal hosts.

OK, so what’s next? In this part, we’ll discuss VMM Integration. What does this mean exactly? Firstly, VMM stands for Virtual Machine Manager – in other words, we are talking about integration with a VM management system such as VMware vCenter, Microsoft SCVMM and so on. At the time of writing this post, ACI supports integration with vCenter (others will be supported later), so this is what we’ll concentrate on here. I should also point out that we could also use the Cisco Application Virtual Switch (AVS) to achieve this integration, but I’m going to focus on using the regular VMware distributed virtual switch in this post. Read the rest of this entry »

Welcome back! In this instalment, I’ll look at how to get two bare metal hosts talking to each other in the fabric. In the last post, we talked about access policies. At the end of that post, we had created a number of policies and applied them to our switching nodes. If you recall, by doing that we had provisioned a range of VLANs on one or more ports on a leaf node, but we had not actually enabled any VLANs on a port. In order to do that, we need to create at least one EPG and associate it with a port.

In the last blog, part 4, we took a look at some of the most important policy constructs within ACI – application profiles, EPGs, contracts and filters.

Next on the list, we’ll have a look at some networking concepts within ACI – namely private networks, bridge domains and subnets. Some of these are terms that you might not recognise, so what are they for? Read the rest of this entry »

In this post, we’ll take a closer look at some of the most important constructs within the ACI solution – application profiles, End Point Groups (EPGs), contracts and filters. Hopefully you’ve taken a look at the other parts in this series – in part 1, I gave a brief overview of ACI and what I would be covering in the series. Part 2 discussed the fabric bring-up process, with part 3 giving a short tour of the APIC. Read the rest of this entry »

Hello again! Hopefully you’re back after reading parts one and two of this series – in the first post, I covered a basic introduction to ACI and then in the last post, we looked at how the fabric initialisation and discovery process works. After the incredible excitement of building an ACI fabric, what do we do with it? Well, if you’ve never seen what an APIC looks like before, in this post we’ll have a look around the APIC and start to find our way around the GUI.