How To Use Cisco ACI To Deploy A Best Practice Configuration Down to the Network in Seconds


March 30, 2015

Cisco’s Application Centric Infrastructure (ACI) deploys policies on a stateless infrastructure. When we talk about ACI, we’re referring to the deployment and/or support of critical line-of-business applications within a data center.  The deployment of applications has changed over the past 30 years, moving from single-tier/single-server applications, to multi-tier/multi-server applications, to cloud deployment models, and now big data models that use the networks in a very different fashion.  At the same time, the way we manage the network construct has remained very stagnant, using the same complex protocols to support the applications and the business.  We are using IP routing, STP, Policy Based Routing, Layer 2 QoS, Layer 3 Qos, etc., and tailoring the way we configure these protocols to support critical line-of-business applications.


Configuring Complex Protocols Requires Deep Expertise

It takes significant time and talent to configure complex route/switch protocols.  Most organizations have in-house experts or hire outside consultants, which can be cost prohibitive.  Because it’s difficult to tailor the network for the applications in traditional architectures, and the time it takes to implement these policies, we have built a layer of complexity between the application team and network team.  This layer of complexity means your businesses may be slower to change and adapt to new business demands. If your CEO said, “I need this new application deployed on our network this week” would you struggle to get it done?


Cisco’s ACI Simplifies the Complexity

Cisco’s ACI abstracts the complexity layer between the application and network teams, so in-house IT teams are as nimble as cloud solutions.  Cisco’s ACI programs the network fabric in an automated fashion based on the exact requirements of the application. Most common applications exist on the network In three tiers:

  • Web Tier – how we present the application to the users
  • App Tier  – provides information to the web-tier so it can be presented in whatever format the application writers wants it to appear to the users
  • Database Tier  – the App-Tier needs to access data – the data typically exists in a Database Tier

The only thing missing from this equation is the policies needed for connectivity.  For instance, to connect to the Web Tier, you need a set of policies in place that users require – policies might include Layer 4 – 7 services, load balancers, firewalls rules, and more.   For the connectivity between the Web and App Tier, you probably need some load balancers, additional firewall rules, and perhaps some quality-of-service policies.  And, finally, you’ll need another set of policies between the App and Database Tier.  Ultimately, the IT team draws out a set of cohesive policies to look at an application as a whole.


Cisco ACI Application Network Profile

Cisco’s ACI groups all of these policies together into an Application Network Profile. An Application Network Profile is a logical profile outlining how an application will look, connect, and be treated on the network fabric.  The application profile, which is a logical template, gets deployed down onto a stateless network infrastructure including the layer 4 – 7 network services that are required for that application deployment.  Essentially, we are using a model that makes sense to the application owners deployed onto the network via a logical GUI- driven template that is installed in seconds, as opposed to the weeks it can take to tailor a network in traditional architectures.   This is what provides the policy-based connectivity in an application centric network fashion.  This is the core of Cisco ACI.


Endpoint Groups (EPGs)

Endpoint groups (EPGs) are what make up any of the given tiers within this Application Network Profile model.  ACI groups endpoints together for the enforcement of policy and uses these EPGs as a policy instantiation point.   Typically, the way that we do policy instantiation (qos, SLAs, Layer 4-7 services, security) in traditional architectures is based on things like layer 3 IP address, layer 4 TCP, or UDP port numbers.

The problem with traditional network terms (layer 3 IP addresses and Layer 4 port information) is they aren’t really application relevant terms, and they aren’t terms that an application developer knows or should have to know.   So, ACI uses things that make sense to a developer; such as the components of the tiers of the application.  ACI uses EPGs to put endpoints into these groups – endpoints are virtual servers, physical servers, or services running on any given server.   ACI then implements policy based on those boundaries of groupings, rather than implementing it on traditional networking information such as IP address or Layer 4 TCP/UDP port.

At this point, it doesn’t matter what IP subnet an EPG is in, or if that EPG has multiple IP subnets, or specific layer 4 information; we are grouping based on the fact that they are a tier or component of the application and require a common policy.  Then, we implement a policy between these groups based on the connectivity graph that we draw within the Application Network Profile.


Cisco Service Chaining

A common question is “how do we get the policy implemented down to the stateless network fabric?”  ACI accomplishes this with service graphs, or what Cisco calls service chaining.  When we integrate with layer 4 – 7 devices, or any other devices within the fabric, there are three ways to approach that device within ACI:

  • Redirect Traffic – if, for example, a firewall is already configured and you want to leave it alone, or you don’t want ACI touching it, just redirect the traffic and let the device do its job.
  • Device Package – Simply name the features you want to expose from your device and state the python script for the commands you want to implement on the device.  The device package plugs into the APIC controller and, when deployed, the device package is written down to the actual physical device.  Although the device packages can be written by anyone, typically vendors develop and provide Cisco ACI the actual device package to be implemented on their devices.
  • OpFlex – OpFlex is a control protocol, like the APIC, and talks to and controls the Nexus devices.  OpFlex tells the device the intended state, ‘what it wants it to do and look like.’  It’s a way to tell the layer 4 – 7 what you want it do and allow it to implement the changes.  You don’t have to know the deep level configuration on a particular device, the device knows how to interpret the OpFlex commands, so it can turn around and implement it in it’s own command language. Cisco ACI trusts the device and lets it do what it needs to do as opposed to trying to understand all the intricacies of every device.  Companies that are partnered with Cisco on the OpFlex language include IBM, F5, and Citrix.

In conclusion, Cisco ACI is a valuable tool because it essentially abstracts the complexity of typical traditional architectures, via Application Network Profiles, allowing a logical GUI driven template (that makes sense to both the network and applications teams) to deploy a best practice configuration down to the network in seconds rather than weeks. If you’d like to learn more about how Cisco’s ACI can take the complexity out of your current architecture, please contact us.


Download Our Free White Paper:

The next big breakthrough in networking technology is here, and it’s called software defined networking. Yet, many IT environments are not prepared to take advantage of it. Learn how SDN can improve your network and discover how you can update your environment to fully realize the potential of SDN in our white paper. Download, “Modernizing Your IT Environment with Software Defined Networking” today.


Like what you read? 


Contact us today to discuss Cisco ACI.


About Mindsight

Mindsight, a Chicago IT consultancy and services provider, offers thoughtfully-crafted and thoroughly-vetted perspectives to our clients’ toughest technology challenges. Our recommendations come from our experienced and talented team of highly certified engineers and are based on a solid understanding of our clients’ unique business and technology challenges.



For Further Reading:

Combining Cisco ACI and VMware NSX Together

Related Articles

View All Blog Posts

Contact Us
close slider


Fill out the form below to get the answers you need from one of Mindsight's experts.

hbspt.forms.create({ portalId: "99242", formId: "dfd06c5c-0392-4cbf-b2cb-d7fb4e636b7f" });