Choice and Flexibility in deploying L4-L7 services with Cisco ACI and Cisco CloudCenter: An in-depth Journey
Two weeks ago, I posted a blog highlighting the growing customer momentum for Application Centric Infrastructure (ACI), particularly in the context of customer successes in ACI-F5 joint deployments. I am seeing a growing trend among customers of late to directly deploy the Nexus 9k series of switches in ACI mode. At F5 Agility Vienna, in May, I met with quite a few customers who expressed a keen interest in integrating L4-L7 network and security services with ACI.
I had the privilege of understanding customer perspectives on how they plan on deploying the device package, the glue software that integrates Cisco ACI with a given vendor’s L4-L7 service device. In recent months, the Insieme Business Unit has built flexibility and choice with regard to the modes customers can deploy the L4-L7 service devices with ACI and Cisco CloudCenter. This blog is intended to create an expanded awareness on various L4-L7 service integration options with Cisco ACI.
It is best if I start by explaining the various modes of deploying L4-L7 services with ACI. They include:
– Managed Mode (a.k.a Service Policy Mode)
– Unmanaged Mode (a.k.a Network Policy Mode)
– Hybrid Mode (a.k.a Partially Managed Mode)
Service Policy Mode: When ACI first launched with the concept of L4-L7 service automation, it went to market with service policy mode (also known as managed mode). The main purpose and forward looking approach at that time was to have one single source of management, the Cisco APIC, to fully automate the entire L2-L7 stack. This was done through a device package uploaded to the APIC that contained a list of features and policies to configure the service device (ADC or FW for example). You can think of the device package as a plugin with a list of features presented to configure your service device. An important thing to keep in mind is the device package is provided by ACI L4-L7 ecosystem partners who decide which features are exposed or hidden compared to going directly to the device.
We have several customers who have deployed this mode and experienced smooth and seamless operational experience. Whether you have a small DevOps team or separate teams to manage various sized data centers, this can be a solution for you. You can use the GUI, CLI, or API to configure the APIC, which configures all of your network (ACI) and L4-7 services. Another major benefit is when you automate everything through northbound APIs without the need for a GUI or CLI. Again, many different use cases can be addressed, but ultimately, Cisco stands behind this operational model and its ecosystem partners who support this methodology.
I found this great section that goes into more depth on the managed mode, and here’s the link if you need to read more.
Network Policy Mode: With everything being said about the Service Policy Mode, some customers were not yet ready for the APIC to be in full control of their service devices. So, the second mode that was brought to market is called Network Policy Mode (also known as unmanaged mode – since the service device is not being managed by the APIC). ACI is still automating the network for you until the traffic gets to the device. Here’s the simple flow:
- ACI Fabric will deliver the traffic to the service device (ADC or FW, etc…)
- The service device will perform its task(s)
- The ACI Fabric will handle the traffic once it comes out the service device
This mode requires manual network stitching, meaning you provide information about the ports to which it connects, the ports that are part of a cluster, and the device operation mode: go-to mode, go-through mode, or one-arm mode (link to read more). With the proper hardware and software (ACI or service devices), customers can always migrate to Service Policy Mode at a later time when they are ready. This is to show again that ACI is able to adapt to the market, and address customer needs.
Hybrid Mode: The Hybrid mode, also known as the partially managed mode, is the third model of managing your service devices. Hybrid mode enables L4-L7 service devices to be jointly managed through Cisco APIC and a service device controller. It enables L2-L3 network configuration of service devices through APIC. With Hybrid mode, more nuanced L4-L7 feature configuration can be done through a specialized service device controller. Hybrid mode requires a device package. The key difference here between Service Policy Mode and Hybrid Mode is the function of the device package. Hybrid mode allows device package developer to customize and manage subset of L4-L7 features through APIC. To keep things simple, the APIC has a version of a device package that enables it to communicate with service device controller, and there can be many different flavors.
The configuration command comes from the APIC to the service device controller and then pushed down to the service device with the full configuration. This allows simplicity on the device package side and management through the APIC while keeping the full native functions and customizable parameters available for the 3rd party vendors. Hybrid mode enhances security devices like firewalls, IPS, IDS etc., management through APIC. It allows security administrator to manage security policies through a dedicated security controller, while configuring the network parameters and associating security policies to a network through APIC.
The one thing that is common in all Hybrid Modes is that the network portion is still fully automated through the APIC. In other words, don’t worry about L2-L3, but we’re still configuring L4-L7 in a slightly different way.
I am excited to say that we have more for you. Cisco’s recent acquisition of CliQr CloudCenter (now called Cisco CloudCenter) is a strategic tool for delivering simple, self-service application deployment to end users while letting network and IT administrators apply complex automated rules and policies in the background. During the application deployment process, Cisco CloudCenter dynamically deploys and creates objects like APIC managed services, ACI contracts, and endpoint groups. In the image below, you can see how the Cisco CloudCenter application profile models the inclusion of a load balancer managed service (1), the resulting translation of that model into an APIC application profile (2), and lastly the load balancer managed service supplying L4-L7 features, displayed in the APIC service graph (3).
Maybe the best part of all this — no APIC API coding for the networking administrator (Cisco CloudCenter has all of that built in already)! All objects are managed throughout the application lifecycle–ultimately cleaned up upon application termination.
Cisco continues to innovate in the SDN market and address customer needs. Whichever mode is needed, green or brown field deployments,we highly encourage you to get on the SDN journey with us.
In closing, I want to extend my thanks to Insieme’s L4-L7 engineering experts Sameer Merchant and Ahmed Dessouki for their insightful conversations with me on this topic. Also, I extend my appreciation to Zack Kielich of Cloudcenter team for sharing what’s new and exciting on ACI-CloudCenter front.