De-Mystifying Cisco ACI Multi-Site
By John Gardner | 3 Min Read | Technical Level: Beginner
In today’s fast-paced market, being able to provision not just applications and customers, but entire sites are becoming more and more important. One of the options we have in the industry right now is Cisco’s Application Centric Infrastructure (ACI). Cisco ACI brings in the best technologies such as fabric deployment automation, orchestrated application deployment, and centralized configuration management. But again, the industry is evolving. Five years ago, provisioning a customer in a hosted solution (single fabric) in minutes was the major focus. Now, we are starting to see a push towards rapidly deploying entire sites. And not only deploying the site, but actually having a consistent policy across multiple sites.
The Evolution of Cisco ACI
When Cisco ACI began, it was essentially developed to rapidly deploy a data center fabric. As shown in the graphic above, the popularity of this deployment method drove more feature requests. One of those features was a “Stretched Fabric”. This gave us the ability to finally have a centralized controller that could instantiate policy across multiple sites. The problem was that the administration was still done via a single APIC (Application Policy Infrastructure Controller) cluster. In the 2.0 version of ACI, we can start using the Spine switches for Inter Data Center connections but only using a stretched cluster. This creates a single point of failure for administration and configuration consistency. So this brings us o the 3.0 version of ACI. It allows us to build APIC clusters at each site and then use a Multi-Site Orchestrator to control the sites simultaneously.
The ability to have a Centralize Orchestrator opens the flood gates to many different options when designing Data Center inter-connectivity. In the graphic below, you can see we are now able to separate our ACI fabrics into redundant “pods” for local failover. It also gives us the ability to then create another site as another backup location. All the while, maintaining the environment from the centralized controller called the Multi-Site Director.
One of the technologies that is used to effectively communicate policy intent across the multiple Data Centers is called a MP-BGP (Multi-Protocol Border Gateway Protocol) EVPN (Ethernet VPN). This makes it possible to move the traffic from one Data Center to another without having to modify header information. Effectively, making the two Data Centers “look” like they are the same fabric. This is accomplished by creating a Layer 3 OUT policy on the Spine switches, and then an OSPF neighbor adjacency to your edge routers connected to your IP transport technology. Once the location of the endpoint is identified, OSPF finds the path to the correct Data Center, and the EVPN transports it without modifying the Layer 2 or Layer 3 header information.
One of the last technologies, that is really the underlying technology of ACI, is VXLANS. The VXLAN header that is applied to the data from one fabric to another has a special header that allows us to identify the source of the data and the location from which the data originated. From a fabric perspective, it’s possible to understand what policies need to be applied to the traffic for security.
To conclude, the Cisco ACI innovation is evolving. It’s providing more and more flexibility in our network designs and deployments. Moving into the future, we may see more integration with third-party vendors for even more robust, flexible fabrics.
For more information on Configuring Cisco Nexus 9000 Series Switches in ACI Mode, visit this course page or contact us for private inquiries.Tags: Cisco Data Center