How Cisco Application Centric Infrastructure Can Help Your Hybrid Cloud Plans

Spine-leaf is usually described as a two-layer topology created to address heavy east-west traffic patterns inside the modern data centre. Based on the Clos network, each leaf node is connected to each spine, thus each leaf node is a hop away from every other leaf node participating in the topology. This approach creates multiple equal paths, which increases resiliency, reduces latency and ensures predictability. Conversely, traditional three-layer topologies were created to address legacy north-south traffic patterns.

Due to the hop-by-hop nature of routing, the biggest benefit from spine and leaf is when it is used as a Layer 3 underlay to build a network fabric on top of it, rather than to spread broadcast domains over it.

A network fabric is a collection of interconnected switches that behave like a single unit. Within the network fabric, the same traditional Layer 2 and Layer 3 network constructs can be applied to any access port, which means that two physically dispersed access ports can belong to the same VLAN, subnet or virtual routing and forwarding (VRF) while consuming the same access policy. Virtual extensible LAN (VXLAN) tunnels are the most deployed data plane encapsulation to achieve Layer 2 and Layer 3 forwarding inside the fabric. The control plane is usually built using multiprotocol BGP with Ethernet VPN (MP-BGP EVPN). The fabric also provides a solution for distributed anycast gateway, so the default gateway always resides on the leaf node directly connected to the end host no matter where the end host moves in the network fabric.

When spine and leaf is deployed combined with multichassis link aggregation group (MLAG) and using Layer 2 links between the spine and leaf nodes, it is not much different from traditional collapse-core topologies. These architectures create a single pod that shares the same network between all devices, building a single failure domain where modification and/or issues affect the whole network.

If the same topology is used with Layer 3 uplinks instead of Layer 2, but without using an overlay, the architecture becomes more rigid and creates individual pods for each pair of top of rack (ToR) nodes, limiting the deployment of the different components of application clusters to inside a rack, with no end-host mobility between pods.

Cisco Application Centric Infrastructure (ACI) is a turnkey solution based on software-defined network (SDN) concepts. The solution uses the Cisco APIC controller for managing and orchestrating the ACI fabric. Network devices are auto-provisioned, and the fabric is built without the need for the network operator to configure VXLAN tunnels or the control plane. From the APIC, network operators can manage physical and virtual networks using a single pane of glass. Network configuration is policy-based and is extended to any device and every single port in the fabric. The APIC integrates with an ecosystem of tools like Nexus Dashboard Insights purposely built by Cisco to support the ACI day-2 operation and to provide automation, monitoring, telemetry and assurance.

Cisco ACI can also integrate with virtualized servers using direct API integration known as Virtual Machine Manager (VMM) integration. It integrates with VMware vSphere, Microsoft Hyper-V, RedHat virtualization, Kubernetes, OpenStack, OpenShift and VMware NSX-T Data Centre (NSX).

Well, the two most common methods for ACI deployments are “network centric” and “application centric.” Most of CDW’s customers start the ACI journey with network centric as the easiest way to migrate existing applications and workloads into the ACI fabric since it will map ACI constructs to traditional networking concepts. In network centric mode, bridge domains (BDs) and endpoint groups (EPGs) are mapped one-to-one with a VLAN ID and the IP subnet is assigned to the BD. The default gateway can either reside inside the BD or in an outside device connected to the fabric (i.e a firewall). Network centric permits the migration of existing networks into the ACI fabric while maintaining the same network structure the network operations team is used to working with.

Bridge domains and VRFs represent traditional Layer 2 and Layer 3 network connectivity concepts, while the EPG represents application groups in the security policy domain. The network domain guarantees endpoint to endpoint communication while contracts are required in the policy domain to allow this communication to happen. All traffic between EPGs is denied by default unless a policy explicitly allows it. This whitelist policy model enforces a zero-trust architecture to the ACI fabric based on application behaviour rather than network segments.

The application centric mode offers more flexibility for segmentation, allowing more complex topologies by creating security zones. In this mode, the BD can be divided into multiple EPGs and several of those EPGs that are associated with the same or a different BD can be grouped into another container called endpoint security group (ESG). Then, contracts can be defined between ESGs that span across different BDs instead of EPGs, or between different ESGs that belong to the same BD, offering a far more flexible segmentation model to match real application flows.

When first introduced in 2014, Cisco ACI covered a single data centre network, but with the boundaries of application stacks rapidly expanding from geographically fixed locations to distributed hybrid and multicloud environments, the Cisco ACI solution evolved to meet the ever-growing demands of the new application stacks.

The most basic deployment of ACI will encompass a single pod/fabric managed by a single APIC cluster. This topology can expand to up to six spine and 400 leaf nodes. The APIC cluster can have a minimum of three nodes to a maximum of seven.

The Cisco ACI Multi-Pod solution allows the creation of multiple network pods that run as a single large operational fabric. A pod is similar to an availability zone in public cloud concepts. This topology is used to fulfill the requirements for interconnecting data centres in active/active fashion with application clusters that expand across multiple pods.

A single APIC cluster can handle up to twelve pods with 24 spines and 500 leaf nodes under the same change domain. Management and operations are simplified due to the fact that a policy definition reaches every single node across all pods, but configuration mistakes inside a tenant could also reach all nodes in the fabric. Nevertheless, the Multi-Pod solution has specific enhancements to isolate failure domains between pods like running separate instances of fabric control plane across them. This isolation is what makes a pod and availability zone. On the other hand, configuration errors inside a tenant are not propagated to other tenants.

Pods only require IP reachability for interconnection to each other over an IP network (IPN). This facilitates the deployment since the routers that are part of the IPN don’t need to support features like VXLAN or MP-BGP since they are not part of the control plane. The specific functionalities required for the IPN are:

• A maximum latency of 50 sec round trip time (RTT)
• A maximum transmission unit (MTU) greater than 1550 bytes
• Configuration of OSPFv2 over a VLAN 4 as a sub-interface
• DHCP-Relay support
• PIM BiDir Multicast support

The Cisco ACI Multi-Site architecture was introduced with ACI Release 3.0(1) and although it is usually positioned as an enhancement to the Multi-Pod, the two topologies complement each other. The ACI Multi-Site interconnects different APIC cluster domains, each of them associated with a single or multiple pods. The typical use case for this solution is for disaster recovery from a secondary or tertiary data centre if the main data centre is down.

Each APIC management domain is seen as a fabric that represents a region in public cloud constructs. Customers can combine the two topologies to achieve both disaster-avoidance and disaster recovery capabilities by deploying different instances of applications across redundant availability zones (pods), and across independent regions (fabrics).

The separated Cisco ACI fabrics are managed from the Nexus Dashboard Orchestrator (NDO) that provides centralized policy definition and management that is distributed to the APIC controllers on each fabric.

The multisite solution includes an option called remote leafs where the ACI policy model can be extended to a pair of Nexus switches in a remote location that could be used as fabric leaf nodes without the need to buy and deploy spine nodes and/or an APIC cluster.

The Cisco Cloud Controller (formerly known as Cisco Cloud APIC) can be deployed in Microsoft Azure, AWS and Google Cloud to extend the on-premises ACI fabrics into multiple public clouds, which allows instances of the same application deployed on-premises and in the public cloud to be part of the same policy. The Cisco Cloud Controller translates ACI constructs into cloud-native constructs. This level of abstraction enhances Cisco’s customers’ capabilities to connect and consume public clouds since operations teams can continue to use the same policy model and language used on-premises to any cloud, regardless of the specific constructs used by the different cloud providers. The result is a homogeneous and consistent operational model across the hybrid multicloud infrastructure.

To extend the fabric, VXLAN is extended over IPSec tunnels to cloud edge routers deployed in the cloud that become part of the network fabric. The Cisco Cloud Controllers provide organizations with universal policy, consistent routing, security and an operational model for multicloud environments, adding flexibility and accelerating business agility and elasticity.

CDW has been involved with Cisco ACI since its introduction to the market and we have helped many customers migrate their legacy network infrastructure into Cisco ACI. We can help customers with conducting assessments, initial discussions, defining requirements, choosing the best topology and hardware options, full design and implementation services. Our main goal is to help our customers to achieve their business goals through technology. We have a group of pre-sales solution architects that can help you plan and design your next Cisco ACI network infrastructure.