Coming from the traditional routing and switching world, stepping into Cisco ACI felt like entering an entirely new universe. If you’ve ever worked with ACI, you probably know exactly what I mean.
The questions that always lingered in my mind were: Why application-centric networking? Why is it important? And how is it achieved?
In the beginning, I made the mistake of constantly trying to connect the “high-level concepts” of ACI with every single detail I was learning on the ground. The reality is, you can’t always correlate things that way. Sometimes, you need to focus entirely on the ground realities, get your hands dirty, and only after seeing enough of those details does the bigger picture start to reveal itself.
I wasn’t this wise when I started with ACI. Knowing it was designed for application-centric networking, I developed a bad habit of trying to map every ACI construct directly to that vision. That only confused me further.
Understanding Application centric networking with Infosec Audit
So, what is the real strategy behind application-centric networking?
The idea is simple, drive network deployments in coherence with applications. In fact, application-centric networking can mean different things to different people. The good part is that it can be explained with a simple and relatable examples like, an information security audit.
Imagine you are a data center manager running applications for multiple business verticals within the same data center. For each vertical, you must guarantee isolation and security. Without a data-center-native security approach, this becomes extremely difficult to manage at scale.
Before diving deeper, let’s consider what kind of questions an InfoSec audit team would ask from the perspective of application isolation and security.
• “What are the precise communication flows (ingress and egress) for this entire application?”
We need to know that application as a whole should have a controlled egress and ingress point. It will help to optimize the security and also control the performance of the application as a whole.
• “How is this application completely isolated from other applications or environments (e.g., Development, Test, other Production applications)?”
In the environment that we are discussing where the DC is running multiple business vertical’s application , this is very important. Application isolation is needed to be handled in a way that can be easily identifiable for the purposes of audit etc.
• “What uniform security policies are applied across all tiers (e.g., web, application, database) of this application, regardless of their network location?”
Even though the security is always present in DC either between the apps , between the workloads, between the app tiers but think of the complexity of configuring this at scale. Even for the traditional three tier app architecture this is not simple to achieve. And even after achieving it , there is no guarantee of uniform security policy. For example we have 100s of severs scattered across the different application tier, and some compliance need has come to apply certain security rule to all those apps running on those 100s of servers. Can you imaging how many whiteboards will get dirty in the process?
• “How can we quickly review and verify the security posture of this application for compliance audits?”
Backtracking the security configuration easily is very-very important. At any given point of time I should be able to present the security posture of the entire application just with few clicks of mouse. Just a quick example would be , suppose you need to scroll though 100 lines of access control list on a switch to identify which ACL belongs to which APP, it feels nightmarish.
• “If a new vulnerability is discovered, how quickly can we implement a mitigating security policy across all relevant components of this application?”
This is also very important as we need to execute so many patch windows, maintenance needs in our networks which requires isolating certain workloads. DC should be able to provide all levels of granularity to classify and isolate the host into quarantine zones, be it vm tag based, ip based, mac based, vlan tag based, port based etc.
Looking at all these questions you might be able to visualize a solution or something that can package my entire application in one policy domain. I should have a key to that package and have control to allow/disallow, define security posture etc. Lets see how Cisco has been solving this problem.
How Cisco ACI ESG (Endpoint security group) and Cisco Nexus NXOS based GPO(group policy option) solving the problem
Cisco ACI is well known for its ability to deliver microsegmentation. It provides multiple ways to segment endpoints, starting from uSeg EPGs, which allow segmentation within already defined EPGs(segments), all the way to Endpoint Security Groups (ESGs), which operate at the VRF level to achieve segmentation across multiple networks and application construct boundaries.
The key use cases for ESGs are closely tied to the idea of application-centric infrastructure. For example, with ESGs you can group an entire application tier under one construct, even if those tiers span multiple networks, VLANs, or subnets. In effect, ESGs let you bind these disparate elements into a single VRF-level construct — forming an application bundle.
For application owners, this is a major advantage. They don’t need to dive into network device configurations to understand the underlying complexity. Instead, they can simply view the ESG as the representation of their application and easily see which policies are applied to it. This makes policy visualization, troubleshooting, and governance far simpler, while still preserving the granular control that ACI provides at the infrastructure level.
When we try to fit network construct to the application construct to achieve application centric network infrastructure the overall picture looks something like below image . The design provides a coupling of the application and network constructs and it helps.
The same idea of ESG is now available in Cisco’s Nexus 9000’s NXOS based VxLAN fabrics as well. In ACI we know that segmentation was achieved with the help of pcTAGs that are carried inside the iVXLAN header. We did not have this capability in the VxLAN implementation on Nexus 9000 devices earlier. Now this has changed, the vxlan header now carries the group policy ID assigned for the traffic.
The Most important bits here are “G” Bit and “A” bit, Cisco NXOS for now doesn’t use D bit. G bit set means the source group ID is being carried in the header. “A” bit tells whether the policy has been applied already or not.
BGP EVPN conntrol plane can also be used to transfer these group IDs for a particular Type2 and Type5 routes, the receiving VTEP will put these the route along with the group tags in the respective forwarding tables to apply policy whenever needed.
The implementation is almost similar to what we have seen so far in ACI.
- We enable the vrf to work in enforced mode
- Then we create security groups
- For the security group creation we have number of selectors like IP, VLAN, MAC+VLAN, VLAN + ports etc
- Once the source and destination security group is configured we can create contracts for the intended traffic
- And lastly apply those contracts between the security groups.
With this implementation of GPO(group policy option) in NXOS we can achieve number of use cases which was not possible earlier like intent based networking, application centric networking, Service chaining based on GPO, Micro segmentation etc
Why it was necessary to enable NXOS also for application centric networking?
Well, to answer this question I will get back to the Infosec questions that were raised at the beginning of the blog and answer them.
These Infosec audit questions were effectively answered with the ESG implementation in ACI but now the same can be achieved with NXOS GPO implementation. The effective automation provided by Nexus dashboard is playing a key role in this capability expansion.
Also, Infosec audit is just one example of the benefits of application centric networking, there are many more in operations and security. This is why it is a must have toolkit in your data center today.