A little over three years ago, I was introduced to Cisco’s Application Centric Infrastructure (ACI) for the first time. For someone who had spent many years at Cisco working on “traditional” networking platforms, this was something of a revelation – the ability to define network connectivity in a programmable manner using a policy based model was a major departure from anything I had done before. Since then, I’ve been lucky enough to work with a variety of customers around the globe, helping them to design and deploy the ACI solution. I’ve been part of a great team of people, worked closely with the INSBU team (responsible for ACI) and presented to hundreds of people at Cisco Live.

Over the last few months, I’ve spent some time thinking about what I do next: as ACI becomes more mainstream, do I continue with more of the same – expanding my skill set to include the other great products (Tetration, Cloudcenter,etc) that Cisco has in the data centre – or do I take a slightly different path? After some serious consideration, I’ve decided to go with the latter option – later this month, I’ll be joining Microsoft as a Cloud Solutions Architect, working with the Azure platform.

I’ve thoroughly enjoyed writing this blog over the last few years and want to thank everyone who has read the posts, commented or given me feedback. I’m hoping to continue blogging occasionally, so keep an eye out for the odd Azure-related post!

Adam

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:

  1. Routes must be leaked between the two VRFs or tenants that need to communicate.
  2. Security rules must be in place to allow communication between the EPGs in question (as is always the case with ACI).

Read the rest of this entry »

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:

Transit-Routing

Read the rest of this entry »

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.

Read the rest of this entry »

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:

L3-Outside Read the rest of this entry »

Welcome to part 8 – let’s quickly recap what we have covered so far in this series:

  • Part 1 introduced this series and discussed what topics would be covered, as well as a very brief overview of ACI.
  • In part 2, I took a look at the fabric bring up process
  • Next, we took a tour through the APIC GUI to get us familiar with the interface.
  • Part 4 looked at some of the most important ACI constructs – app profiles, EPGs, contracts and filters.
  • We had a look at networking concepts in ACI in part 5.
  • 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.

Read the rest of this entry »

Just a quick note to say that both my ACI sessions from Cisco Live Milan in January are available now for viewing online:

BRKACI-2345 – ACI: What We Have Learnt From Early Deployments

BRKACI-1789 – How To Perform Common Tasks In ACI

You’ll need a login to access both the slides and the videos.

Enjoy!

Adam

So far in this series, we’ve covered some basic concepts in ACI, including fabric bringup, APIC familiarisation, application profiles / EPGs / contracts as well as some of the networking concepts in ACI. At some point though, you’ll want to actually start attaching hosts and other devices to the fabric – in order to do this, you’ll need to get familiar with the concept of access policies.

Access Policies

Read the rest of this entry »

Welcome to part 5 of this blog series – so far I have covered the following topics:

  • Part 1 contained a very brief overview of ACI and what the series would cover.
  • In part 2, I talked through the fabric bring-up process.
  • Part 3 was all about getting familiar with the APIC controller GUI.
  • 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 »