Jason Plank's Blog

… technology and stuff …

ACI Policy Model: Introduction to some of the fundamentals of an ACI Policy and how it’s enforced

What’s in your Policy Model?

Today I’ve decided to focus on a couple of concepts that I think are quite relevant to what’s happening in the Cloud/DC space. With the announcement of ACI in November of last year, we’ve seen a lot of buzz in the industry around defining policy in the Data Center.

Enforcement of a policy across a fabric is a very powerful tool. It allows you to scale out tenants and applications in a horizontal manner. If you’ve been introduced to ACI, you understand that one of the fundamental components in the architecture is that we are abstracting the network and by leveraging a policy driven automation model we are allowed to consistently deploy applications and services across the system (or, fabric).

With that intro, I’ll break down two fundamentals of ACI. The first is an introduction to the policy model. The second is an example of how a policy is enforced in the ACI fabric.

Policy Model – Introduction

The concept of the ACI Policy Model is that it follows the notion of being “declarative”. If you pause for a moment and think of programming models, you can break it down into imperative or declarative models.

What’s the difference? Imperative programming focuses on telling a machine (or software) what to do, how to do it, when to do it, and who to do it with. It’s similar to standing over your child while they do their homework and tell telling them how to write, what the answers are, and what spaces to write the answers in.

With a declarative policy model we’re telling the machine (or system) what we want to see happen, and letting the machine figure out how to implement. To draw a parallel, you’ve decided to give your child a chance in this cruel world and let them do some homework on their own.

Going with a declarative policy (or programming model) allows you be a bit more efficient (few lines of code, less complexity, and etc). It also allows you to abstract things, which is a fundamental goal of ACI. Network abstraction allows us to better utilize resources and allows us to not be limited by the placement of things in the system.

Below is a block overview of some of the components in a policy. As you can see, the highest-level construct of the Policy Model is a Tenant. From the tenant view down, you can apply various constructs that allow you to scale out to offer various policy options for your Services and/or Applications.

PolicyBlock

Block view of some ACI Policy Model components.

 

I won’t go through defining all components above further right now, but I will quickly focus on the End Point Groups (EPG) piece of the policy model. An EPG is a way of classifying a like minded set of workloads that attach to the fabric. This could translate to a number of things like: 1) A simply zone for an IaaS providers customer. 2) a “Web” tier of a 3 tier app. 3) Some other manner in which the admin decides to classify workloads.

From a logical point of view, you could consider that a VLAN could simply equate to an EPG. You could also consider, if you are running VXLAN in the hypervisor on a virtual switch – you could have a VNI (VXLAN Network Identifier) equate to an EPG. There are other options as well, but for now you can understand that you classify a set of physical or virtual workloads as an end point group.

If you now take what I’ve shown you above, you can translate that into a functional deployment of a policy model, which I’ve drawn below:

PolicyModel3tierapp

Example of a 3 tier policy model.

Now, in this example we are looking at a typical three-tier application. What I want to caution some of my Service Provider customers is that just because I am showing this example, it doesn’t mean that you are restricted to follow this model. You can let your customer dictate which EPGs in their tenant profile need to communicate with each other. This means you can have EPGs in silos or you can have them linked together via policy model options.

I will also point out, that as you can see there is a “Service” in blue. In this example, traffic between Web and Application traverse a Service chain. While the focus of this blog is not to go over the services aspect, I will simply point out that you can consume a number of L4-L7 services. This is not limited to Cisco, but an example of some of the services you could consume are (FW, SLB, VPN, and etc.) and some of the eco system partners that we could service chain are (F5, Citrix, Embrane, and more to come). Worth noting, is that we will also support the consumption of, for example Virtual (and physical) ASA appliances.

If you are following at home, this allows us to attach various resources to the fabric, and then consume them. While there are other declarative models out there, a key differentiator with ACI, is that via the APIC we are handing the automation of the fabric as well as the service chaining of L4-L7 services.

Another key point to mention, and we will make sure to go over this in detail – is that as you create this profile, you also have the ability to provide health scores based on tenant, service chain, and etc.

This allows you to provide some intelligent value to the services and applications that you are offering to your customers (internal and external).

How is a policy Pushed and/or consumed to the fabric?

The first thing I’m going to mention here, is that the APIC does not participate at all in the forwarding of traffic in the fabric. This allows us to not be constrained by a centralized forwarding model.

As you create your policy construct on the APIC, the APIC pushes the policy model meta data down to the leaf switches in the fabric. The leaf switches do not install that policy into hardware immediately. Instead, the policy is stored into software and as end points (VMs, Physical Servers, and etc) attach to the fabric – the policy is pushed into hardware.

 

ACIPolicyEnforce2

Basic example of enforcing the policy on the fabric.

 

As you can see, the first thing we will do is match the endpoint to source EPG.  Once we’ve identified what the “source” EPG of the packet is we will forward it off to the destination leaf. At the destination leaf we will look at the destination – see that it’s attached to the fabric and append a “destination” EPG. The policy then gets enforced.

Keep in mind that this is the first packet of a conversation. Any further conversation that happens between endpoints is enforced at the ingress leaf. There are some additional implementation details that are being left out, but as you can decode – the leaf in which the destination endpoint is located triggers a message to the ingress leaf which allows the ingress leaf to store a policy entry into it’s table.

That concludes today’s blog. Be sure to check back for more details around ACI and other technology topics. Feel free to leave some feedback and/or ask questions!

 

April 25, 2014 Posted by | ACI | , , | Leave a comment