Cisco ACI

ACI Cisco

Cisco ACI Components

In today's rapidly evolving digital landscape, businesses constantly seek innovative solutions to streamline their network infrastructure. Enter Cisco ACI (Application Centric Infrastructure), a groundbreaking technology that promises to revolutionize how networks are designed, deployed, and managed.

In this blog post, we will delve into the intricacies of Cisco ACI, its key features, and the benefits it brings to organizations of all sizes.

Cisco ACI is an advanced software-defined networking (SDN) solution that enables organizations to build and manage their networks in a more holistic and application-centric manner. By abstracting network policies and services from the underlying hardware, ACI provides a unified and programmable approach to network management, making it easier to adapt to changing business needs.

Table of Contents

Highlights: Cisco ACI Components

Hardware-based Underlay

In ACI, hardware-based underlay switching offers a significant advantage over software-only solutions due to specialized forwarding chips. Furthermore, thanks to Cisco’s ASIC development, ACI brings many advanced features, including security policy enforcement, microsegmentation, dynamic policy-based redirect (inserting external L4-L7 service devices into the data path), or detailed flow analytics—besides the vast performance and flexibility.

The Legacy data center

The legacy data center topologies have a static infrastructure that specifies the constructs to form the logical topology. We must configure the VLAN, Layer 2/Layer 3 interfaces, and the protocols we need on the individual devices. Also, the process we used to define these constructs was done manually. We may have used Ansible playbooks to backup configuration or check for specific network parameters, but we generally operated with a statically defined process.

  • Poor Resources

The main roadblock to application deployment was the physical bare-metal server. It was chunky and could only host one application due to the lack of process isolation. So, the network has one application per server to support and provide connectivity. This is the opposite of how ACI Cisco, also known as Cisco SDN ACI networks operate.

Related: For pre-information, you may find the following helpful:

  1. Data Center Security 
  2. VMware NSX



Cisco SDN ACI 

Key ACI Cisco Discussion points:


  • Birth of virtualization and SDN.

  • Cisco ACI integrations.

  • ACI design and components.

  • VXLAN networking and ECMP.

  • Focus on ACI and SD-WAN.

Back to Basics: Cisco ACI components

Key Features of Cisco ACI

a) Application-Centric Policy Model: Cisco ACI allows administrators to define and manage network policies based on application requirements rather than traditional network constructs. This approach simplifies policy enforcement and enhances application performance and security.

b) Automation and Orchestration: With Cisco ACI, network provisioning and configuration tasks are automated, reducing the risk of human error and accelerating deployment times. The centralized management framework enables seamless integration with orchestration tools, further streamlining network operations.

c) Scalability and Flexibility: ACI’s scalable architecture ensures that networks can grow and adapt to evolving business demands. Spine-leaf topology and VXLAN overlay technology allow for seamless expansion and simplify the deployment of multi-site and hybrid cloud environments.

Cisco Data Center

Cisco ACI

Key Features

  • Application-Centric Policy Model

  • Automation and Orchestration

  • Scalability and Flexibility

  • Built-in Security 

Cisco Data Center

Cisco ACI 

Key Advantages

  • Enhanced Security

  • Agility and Time-to-Market

  • Simplified Operations

  • Open software flexibility for DevOps teams.

Benefits of Cisco ACI

a) Enhanced Security: By providing granular microsegmentation and policy-based controls, Cisco ACI helps organizations strengthen their security posture. Malicious lateral movement within the network can be mitigated, reducing the attack surface and preventing data breaches.

b) Agility and Time-to-Market: The automation capabilities of Cisco ACI significantly reduce the time and effort required for network provisioning and changes. This agility enables organizations to respond faster to market demands, launch new services, and gain a competitive edge.

c) Simplified Operations: The centralized management and policy-driven approach of Cisco ACI simplify network operations, leading to improved efficiency and reduced operational costs. The intuitive user interface and comprehensive analytics provide administrators with valuable insights, enabling proactive troubleshooting and optimization.

The Cisco ACI SDN Solution

Cisco ACI is a software-defined networking (SDN) solution that integrates with software and hardware. With the ACI, we can create software policies and use hardware for forwarding, an efficient and highly scalable approach offering better performance. The hardware for ACI is based on the Cisco Nexus 9000 platform product line. The APIC centralized policy controller drives the software, which stores all configuration and statistical data.

Nexus Family

To build the ACI underlay, you must exclusively use the Nexus 9000 family of switches. You can choose from modular Nexus 9500 switches or fixed 1U to 2U Nexus 9300 models. Specific models and line cards are dedicated to the spine function in ACI fabric; others can be used as leaves, and some can be used for both purposes. You can combine various leaf switches inside one fabric without any limitations.

Spine and Leaf

For Nexus 9000 switches to be used as an ACI spine or leaf, they must be equipped with powerful Cisco CloudScale ASICs manufactured using 16-nm technology. The following figure shows the Cisco ACI based on the Nexus 9000 series. Cisco Nexus 9300 and 9500 platform switches support Cisco ACI. As a result, organizations can use them as the spine or leaf switches to fully utilize an automated, policy-based systems management approach. 

Cisco ACI Components
Diagram: Cisco ACI Components. Source is Cisco
  • A key point: The birth of virtualization

Server virtualization helped to a degree where we could decouple workloads from the hardware, making the compute platform more scalable and agile. However, the server is not the main interconnection point for network traffic. So, we need to look at how we could virtualize the network infrastructure in a way similar to the agility gained from server virtualization.

This is carried out with software-defined networking and overlays that could map network endpoints and be spun up and down as needed without human intervention. In addition, the SDN architecture includes an SDN controller and an SDN network that enables an entirely new data center topology.

server virtualization
Diagram: The need for virtualization and software-defined networking.

ACI Cisco: Integrations

Routing Control Platform

Then came along Cisco SDN ACI, the ACI Cisco, which operates differently from the traditional data center with an application-centric infrastructure. The Cisco application-centric infrastructure achieves resource elasticity with automation through standard policies for data center operations and consistent policy management across multiple on-premises and cloud instances.

It uses a Software-Defined Networking (SDN) architecture like a routing control platform. The Cisco SDN ACI also provides a secure networking environment for Kubernetes. In addition, it integrates with various other solutions, such as Red Hat OpenShift networking.

Cisco ACI: Integration Options

What makes the Cisco ACI interesting is its several vital integrations. I’m not talking about extending the data center with multi-pod and multi-site, for example, with AlgoSec, Cisco AppDynamics, and SD-WAN. AlgoSec enables secure application delivery and policy across hybrid network estates, while AppDynamic lives in a world of distributed systems Observability. SD-WAN enabled path performance per application with virtual WANs.

Cisco ACI Components: ACI Cisco and Multi-Pod

Cisco ACI Multi-Pod is part of the “Single APIC Cluster / Single Domain” family of solutions, as a single APIC cluster is deployed to manage all the interconnected ACI networks. These separate ACI networks are named “pods,” Each looks like a regular two-tier spine-leaf topology. The same APIC cluster can manage several pods, and to increase the resiliency of the solution, the various controller nodes that make up the cluster can be deployed across different pods.

ACI Multi-Pod
Diagram: Cisco ACI Multi-Pod. Source Cisco.

Cisco ACI Components: ACI Cisco and AlgoSec

With AlgoSec integrated with the Cisco ACI, we can now provide automated security policy change management for multi-vendor devices and risk and compliance analysis. The AlgoSec Security Management Solution for Cisco ACI extends ACI’s policy-driven automation to secure various endpoints connected to the Cisco SDN ACI fabric.

These simplify the network security policy management across on-premises firewalls, SDNs, and cloud environments. It also provides the necessary visibility into the security posture of ACI, even across multi-cloud environments. 

Cisco ACI Components: ACI Cisco and AppDynamics 

Then, with AppDynamics, we are heading into Observability and controllability. Now, we can correlate app health and network for optimal performance, deep monitoring, and fast root-cause analysis across complex distributed systems with numbers of business transactions that need to be tracked. This will give your teams complete visibility of your entire technology stack, from your database servers to cloud-native and hybrid environments. In addition, AppDynamics works with agents that monitor application behavior in several ways. We will examine the types of agents and how they work later in this post.

Cisco ACI Components: ACI Cisco and SD-WAN 

SD-WAN brings a software-defined approach to the WAN. These enable a virtual WAN architecture to leverage transport services such as MPLS, LTE, and broadband internet services. So, SD-WAN is not a new technology; its benefits are well known, including improving application performance, increasing agility, and, in some cases, reducing costs.

The Cisco ACI and SD-WAN integration makes active-active data center design less risky than in the past. The following figures give a high-level overview of the Cisco ACI and SD-WAN integration. For pre-information generic to SD-WAN, go here: SD-WAN Tutorial

SD WAN integration
Diagram: Cisco ACI and SD-WAN integration

The Cisco SDN ACI and SD-WAN Integration

The Cisco SDN ACI with SD-WAN integration helps ensure an excellent application experience by defining application Service-Level Agreement (SLA) parameters. Cisco ACI releases 4.1(1i) and adds support for WAN SLA policies. This feature enables admins to apply pre-configured policies to specify the packet loss, jitter, and latency levels for the tenant traffic over the WAN.

When you apply a WAN SLA policy to the tenant traffic, the Cisco APIC sends the pre-configured policies to a vManage controller. The vManage controller, configured as an external device manager that provides SDWAN capability, chooses the best WAN link that meets the loss, jitter, and latency parameters specified in the SLA policy.

Cisco ACI Components: Openshift and Cisco SDN ACI

OpenShift Container Platform (formerly known as OpenShift Enterprise) or OCP is Red Hat’s offering for the on-premises private platform as a service (PaaS). OpenShift is based on the Origin open-source project and is a Kubernetes distribution, the defacto for container-based virtualization. The foundation of the OpenShift networking SDN is based on Kubernetes and, therefore, shares some of the same networking technology along with some enhancements, such as the OpenShift route construct.

Cisco ACI Components: Other data center integrations

Cisco SDN ACI has another integration with Cisco DNA Center/ISE that maps user identities consistently to endpoints and apps across the network, from campus to the data center. Cisco Software-Defined Access (SD-Access) provides policy-based automation from the edge to the data center and the cloud.

Cisco SD-Access provides automated end-to-end segmentation to separate user, device, and application traffic without redesigning the network. This integration will enable customers to use standard policies across Cisco SD-Access and Cisco ACI, simplifying customer policy management using Cisco technology in different operational domains.

Let us recap before we look at the ACI integrations in more detail.

The Cisco SDN ACI Design  

Introduction to leaf and spine

The Cisco SDN ACI works with a Clos architecture, a fully meshed ACI network. Based on a spine leaf architecture. As a result, every Leaf is physically connected to every Spine, enabling traffic forwarding through non-blocking links. Physically, we have a set of Leaf switches creating a Leaf layer attached to the Spines in a full BIPARTITE graph.

This means that each Leaf is connected to each Spine, and each Spine is connected to each Leaf.  The ACI uses a horizontally elongated Leaf and Spine architecture with one hop to every host in an entirely messed ACI fabric, offering good throughput and convergence needed for today’s applications.

Cisco ACI
Diagram: Cisco ACI: Improving application performance.

The ACI fabric: Aggregate

A key point to note in the spine-and-leaf design is the fabric concept, which is like a stretch network. And one of the core ideas around a fabric is that they do not aggregate traffic. This does increase data center performance along with a non-blocking architecture. With the spine-leaf topology, we are spreading a fabric across multiple devices.

The result of the fabric is that each edge device has the total bandwidth of the fabric available to every other edge device. This is one big difference from traditional data center designs; we aggregate the traffic by either stacking multiple streams onto a single link or carrying the streams serially.

SDN data center
Diagram: Cisco ACI fabric checking.

The issues with oversubscription

With the traditional 3-tier design, we aggregate everything at the core, leading to oversubscription ratios that degrade performance. With the ACI Leaf and Spine design, we spread the load across all devices with equidistant endpoints. Therefore, we can carry the streams parallel.

Horizontal scaling load balancing

Then, we have horizontal scaling load balancing.  Load balancing with this topology uses multipathing to achieve the desired bandwidth between the nodes. Even though this forwarding paradigm can be based on Layer 2 forwarding ( bridging) or Layer 3 forwarding ( routing), the ACI leverages a routed approach to the Leaf and Spine design, and we have Equal Cost Multi-Path (ECMP) for both Layer 2 and Layer 3 traffic. 

Highlighting the overlay and underlay

Mapping Traffic

So you may be asking how we can have Layer 3 routed core and pass Layer 2 traffic. This is done using the overlay, which can map different traffic types to other overlays. So, we can have Layer 2 traffic mapped to an overlay over a routed core. ACI links between the Leaf and the Spine switches are L3 active-active links. Therefore, we can intelligently load balance and traffic steer to avoid issues. And we don’t need to rely on STP to block links or involve STP to fix the topology.

When networks were first developed, there was no such thing as an application moving from one place to another while it was in use. So the original architects of IP, the communication protocol used between computers, used the IP address to mean both the identity of a device connected to the network and its location on the network.  Today, in the modern data center, we need to be able to communicate with an application or application tier, no matter where it is.

Overlay Encapsulation

One day, it may be in location A and the next in location B, but its identity, which we communicate with, is the same on both days. An overlay is when we encapsulate an application’s original message with the location to which it needs to be delivered before sending it through the network.

Once it arrives at its final destination, we unwrap it and deliver the original message as desired. The identities of the devices (applications) communicating are in the original message, and the locations are in the encapsulation, thus separating the place from the identity. This wrapping and unwrapping is done per-packet basis and, therefore, must be done quickly and efficiently.

Overlay and underlay components

The Cisco SDN ACI has a concept of overlay and underlay, forming a virtual overlay solution. The role of the underlay is to glue together devices so the overlay can work and be built on top. So, the overlay, which is VXLAN, runs on top of the underlay, which is IS-IS. In the ACI, the IS-IS protocol provides the routing for the overlay, which is why we can provide ECMP from the Leaf to the Spine nodes. The routed underlay provides an ECMP network where all leaves can access Spine and have the same cost links. 

ACI overlay
Diagram: Overlay. Source Cisco

Example: 

Let’s take a simple example to illustrate how this is done. Imagine that application App-A wants to send a packet to App-B. App-A is located on a server attached to switch S1, and App-B is initially on switch S2. When App-A creates the message, it will put App-B as the destination and send it to the network; when the message is received at the edge of the network, whether a virtual edge in a hypervisor or a physical edge in a switch, the network will look up the location of App-B in a “mapping” database and see that it is attached to switch S2.

It will then put the address of S2 outside of the original message. So, we now have a new message addressed to switch S2. The network will forward this new message to S2 using traditional networking mechanisms. Note that the location of S2 is very static, i.e., it does not move, so using traditional mechanisms works just fine.

Upon receiving the new message, S2 will remove the outer address and thus recover the original message. Since App-B is directly connected to S2, it can easily forward the message to App-B. App-A never had to know where App-B was located, nor did the network’s core. Only the edge of the network, specifically the mapping database, had to know the location of App-B. The rest of the network only had to see the location of switch S2, which does not change.

Let’s now assume App-B moves to a new location switch S3. Now, when App-A sends a message to App-B, it does the same thing it did before, i.e., it addresses the message to App-B and gives the packet to the network. The network then looks up the location of App-B and finds that it is now attached to switch S3. So, it puts S3’s address on the message and forwards it accordingly. At S3, the message is received, the outer address is removed, and the original message is delivered as desired.

The movement of App-B was not tracked by App-A at all. The address of App-B identified App-B, while the address of the switch, S2 or S3, identified App-B’s location. App-A can communicate freely with App-B no matter where App-B is located, allowing the system administrator to place App-B in any location and move it as desired, thus achieving the flexibility needed in the data center.

Multicast Distribution Tree (MDT)

We have a Multicast Distribution Tree MDT tree on top that is used to forward multi-destination traffic without having loops. The Multicast distribution tree is dynamically built to send flood traffic for specific protocols. Again, it does this without creating loops in the overlay network. The tunnels created for the endpoints to communicate will have tunnel endpoints. The tunnel endpoints are known as the VTEP. The VTEP addresses are assigned to each Leaf switch from a pool that you specify in the ACI startup and discovery process.

Normalize the transports

VXLAN tunnels in the ACI fabric are used to normalize the transports in the ACI network. Therefore, traffic between endpoints can be delivered using the VXLAN tunnel, resulting in any transport network regardless of the device connecting to the fabric. 

Building the VXLAN tunnels 

So, using VXLAN in the overlay enables any network, and you don’t need to configure anything special on the endpoints for this to happen. The endpoints that connect to the ACI fabric do not need special software or hardware. The endpoints send regular packets to the leaf nodes they are connected to directly or indirectly. As endpoints come online, they send traffic to reach a destination.

Bridge domain and VRF

Therefore, the Cisco SDN ACI under the hood will automatically start to build the VXLAN overlay network for you. The VXLAN network is based on the Bridge Domain (BD), or VRF ACI constructs deployed to the leaf switches. The Bridge Domain is for Layer 2, and the VRF is for Layer 3. So, as devices come online and send traffic to each other, the overlay will grow in reachability in the Bridge Domain or the VRF. 

Horizontal scaling load balancing
Diagram: Horizontal scaling load balancing.

Routing for endpoints

Routing within each tenant, VRF is based on host routing for endpoints directly connected to the Cisco ACI fabric. For IPv4, the host routing is based on the /32, giving the ACI a very accurate picture of the endpoints. Therefore, we have exact routing in the ACI.

In conjunction, we have a COOP database that runs on the Spines that offers remarkably optimized fabric in terms of knowing where all the endpoints are located. To facilitate this, every node in the fabric has a TEP address, and we have different types of TEPs depending on the role of the device. The Spine and the Leaf will have TEP addresses but will differ from each other.

COOP database
Diagram: COOP database

The VTEP and PTEP

The Leaf’s nodes are the Virtual Tunnel Endpoints (VTEP). In ACI, this is known as PTEP, the physical tunnel endpoints. These PTEP addresses represent the “WHERE” in the ACI fabric that an endpoint lives in.

Cisco ACI uses a dedicated VRF and a subinterface of the uplinks from the Leaf to the Spines as the infrastructure to carry VXLAN traffic. In Cisco ACI terminology, the transport infrastructure for VXLAN traffic is known as Overlay-1, which is part of the tenant “infra.” 

The Spine TEP

The Spines also have a PTEP and an additional proxy TEP. This is used for forwarding lookups into the mapping database. The Spines have a global view of where everything is, which is held in the COOP database synchronized across all Spine nodes. All of this is done automatically for you.

For this to work, the Spines have an Anycast IP address known as the Proxy TEP. The Leaf can use this address if they do not know where an endpoint is, so they ask the Spine for any unknown endpoints, and then the Spine checks the COOP database. This brings many benefits to the ACI solution, especially for traffic optimizations and reducing flooded traffic in the ACI. Now, we have an optimized fabric for better performance.

Cisco ACI
Diagram: Routing control platform.

The ACI optimizations

Mouse and elephant flows

This provides better performance for load balancing different flows. For example, in most data centers, we have latency-sensitive flows, known as mouse flows, and long-lived bandwidth-intensive flows, known as elephant flows. 

The ACI has more precisely load-balanced traffic using algorithms that optimize mouse and elephant flows and distribute traffic based on flow lets: flow let load-balancing. Within a Leaf, Spine latency is low and consistent from port to port. The max latency of a packet from one port to another in the architecture is the same regardless of the network size. So you can scale the network without degrading performance. Scaling is often done on a POD-by-POD basis. For more extensive networks, each POD would be its Leaf and Spine network.

ARP optimizations: Anycast gateways

The ACI comes by default with a lot of traffic optimizations. Firstly, instead of using an ARP and broadcasting across the network, that can hamper performance. The Leaf can assume that the Spine will know where the destination is ( and it does via the COOP database ), so there is no need to broadcast to everyone to find a destination.

If the Spine knows where the endpoint is, it will forward it to the other Leaf. If not, it will drop the traffic.

Fabric anycast addressing

This again adds performance benefits to the ACI solution as the table sizes on the Leaf switches can be kept smaller than they would if they needed to know where all the destinations were, even if they were not or never needed to communicate with them. On the Leaf, we have an Anycast address too.

These fabric anycast addresses are available for Layer 3 interfaces. On the Leaf ToR, we can establish an SVI that uses the same MAC address on every ToR; therefore, when an endpoint needs to route to a ToR. It doesn’t matter which ToR you use. The Anycast Address is spread across all ToR leaf switches. 

Pervasive gateway

Now we have predictable latency to the first hop, and you will use the local route VRF table within that ToR instead of traversing the fabric to a different ToR. This is the Pervasive Gateway feature that is used on all Leaf switches. The Cisco ACI has many advanced networking features, but the pervasive gateway is my favorite. It does take away all the configuration mess we had in the past.

The Cisco SDN ACI Integrations

OpenShift and Cisco ACI

  • OpenSwitch virtual network

OpenShift does this with an SDN layer and enhances Kubernetes networking to have a virtual network across all the nodes. It is created with the Open Switch standard. For OpenShift SDN, this pod network is established and maintained by the OpenShift SDN, configuring an overlay network using a virtual switch called the OVS bridge, forming an OVS network that gets programmed with several OVS rules. The OVS is a popular open-source solution for virtual switching.

Openshift sdn
Diagram: OpenShift SDN.

OpenShift SDN plugin

We mentioned that you could tailor the virtual network topology to suit your networking requirements, which can be determined by the OpenShift SDN plugin and the SDN model you select. With the default OpenShift SDN, there are several modes available. This level of SDN mode you choose is concerned with managing connectivity between applications and providing external access to them. Some modes are more fine-grained than others. The Cisco ACI plugins offer the most granular.

Integrating ACI and OpenShift platform

The Cisco ACI CNI plugin for the OpenShift Container Platform provides a single, programmable network infrastructure, enterprise-grade security, and flexible micro-segmentation possibilities. The APIC can provide all networking needs for the workloads in the cluster. Kubernetes workloads become fabric endpoints, like Virtual Machines or Bare Metal endpoints.

The Cisco ACI CNI plugin extends the ACI fabric capabilities to OpenShift clusters to provide IP Address Management, networking, load balancing, and security functions for OpenShift workloads. In addition, the Cisco ACI CNI plugin connects all OpenShift Pods to the integrated VXLAN overlay provided by Cisco ACI.

The Cisco SDN ACI and AppDynamics

AppDynamis overview

So, you have multiple steps or services for an application to work. These services may include logging in and searching to add something to a shopping cart. These services will invoke various applications, web services, third-party APIs, and databases, known as business transactions.

The user’s critical path

A business transaction is the essential user interaction with the system and is the customer’s critical path. Therefore, business transactions are the things you care about. If they start to go, it will cause your system to degrade. So, you need ways to discover your business transactions and determine if there are any deviations from baselines. This should also be done automated, as learning baseline and business transitions in deep systems is nearly impossible using the manual approach.

So, how do you discover all these business transactions?

AppDynamics automatically discovers business transactions and builds an application topology map of how the traffic flows. A topology map can view usage patterns and hidden flows, acting as a perfect feature for an Observability platform.

Cisco AppDynamics
Diagram: Cisco AppDynamics.

AppDynamic topology

AppDynamics will discover the topology for all of your application components. All of this is done automatically for you. It can then build a performance baseline by capturing metrics and traffic patterns. This allows you to highlight issues when services and components are slower than usual.

AppDynamics uses agents to collect all the information it needs. The agent monitors and records the calls that are made to a service. This is from the entry point and follows executions along its path through the call stack. 

Types of Agents for Infrastructure Visibility

If the agent is installed on all critical parts, you can get information about that specific instance. This can help you build a global picture. So we have an Application Agent, Network Agent, and Machine Agent for Server visibility and Hardware/OS.

  • App Agent: This agent will monitor apps and app servers, and example metrics will be slow transitions, stalled transactions, response times, wait times, block times, and errors.  
  • Network Agent: This agent monitors the network packets, TCP connection, and TCP socket. Example metrics include performance impact Events, Packet loss and retransmissions, RTT for data transfers, TCP window size, and connection setup/teardown.
  • Machine Agent Server Visibility: This agent monitors the number of processes, services, caching, swapping, paging, and querying. Example Metrics include hardware/software interrupts, virtual memory/swapping, process faults, and CPU/DISK/Memory utilization by the process.
  • Machine Agent: Hardware/OS – disks, volumes, partitions, memory, CPU. Example metrics: CPU busy time, MEM utilization, and pieces file.

Automatic establishment of the baseline

A baseline is essential, a critical step in your monitoring strategy. Doing this manual is hard, if not impossible, with complex applications. Having this automatically done for you is much better. You must automatically establish the baseline and alert yourself about deviations from the baseline. This will help you pinpoint the issue faster and resolve issues before the problem can be affected. Platforms such as AppDynamics can help you here. Any malicious activity can be seen from deviations from the security baseline and performance issues from the network baseline.

Summary: Cisco ACI Components

In the ever-evolving world of networking, organizations are constantly seeking ways to enhance their infrastructure’s performance, security, and scalability. Cisco ACI (Application Centric Infrastructure) presents a cutting-edge solution to these challenges. By unifying physical and virtual environments and leveraging network automation, Cisco ACI revolutionizes how networks are built and managed.

Section 1: Understanding Cisco ACI Architecture

At the core of Cisco ACI lies a robust architecture that enables seamless integration between applications and the underlying network infrastructure. The architecture comprises three key components:

1. Application Policy Infrastructure Controller (APIC):

The APIC serves as the centralized management and policy engine of Cisco ACI. It provides a single point of control for configuring and managing the entire network fabric. Through its intuitive graphical user interface (GUI), administrators can define policies, allocate resources, and monitor network performance.

2. Nexus Switches:

Cisco Nexus switches form the backbone of the ACI fabric. These high-performance switches deliver ultra-low latency and high throughput, ensuring optimal data transfer between applications and the network. Nexus switches provide the necessary connectivity and intelligence to enable the automation and programmability features of Cisco ACI.

3. Application Network Profiles:

Application Network Profiles (ANPs) are a fundamental aspect of Cisco ACI. ANPs define the policies and characteristics required for specific applications or application groups. By encapsulating network, security, and quality of service (QoS) policies within ANPs, administrators can streamline the deployment and management of applications.

Section 2: The Power of Network Automation

One of the most compelling aspects of Cisco ACI is its ability to automate network provisioning, configuration, and monitoring. Through the APIC’s powerful automation capabilities, network administrators can eliminate manual tasks, reduce human errors, and accelerate the deployment of applications. With Cisco ACI, organizations can achieve greater agility and operational efficiency, enabling them to rapidly adapt to evolving business needs.

Section 3: Security and Microsegmentation with Cisco ACI

Security is a paramount concern for every organization. Cisco ACI addresses this by providing robust security features and microsegmentation capabilities. With microsegmentation, administrators can create granular security policies at the application level, effectively isolating workloads and preventing lateral movement of threats. Cisco ACI also integrates with leading security solutions, enabling seamless network enforcement and threat intelligence sharing.

Conclusion:

Cisco ACI is a game-changer in the realm of network automation and infrastructure management. Its innovative architecture, coupled with powerful automation capabilities, empowers organizations to build agile, secure, and scalable networks. By leveraging Cisco ACI’s components, businesses can unlock new levels of efficiency, flexibility, and performance, ultimately driving growth and success in today’s digital landscape.

Routing Control Platform

BGP-based Routing Control Platform (RCP)

 

IGP platform

 

Routing Control Platform (RCP)

Routing Control Platforms (RCPs) have become essential tools for efficiently managing and controlling network traffic. In today’s digital age, where businesses rely heavily on network connectivity, the need for optimized routing has never been greater. In this blog post, we will explore the concept of Routing Control Platforms, their benefits, and how they empower organizations to take control of their network routing.

Routing Control Platforms are software-based solutions that give network administrators greater control over the routing decisions within their networks. These platforms provide a centralized interface for managing and distributing routing information, allowing organizations to optimize network performance, enhance security, and improve overall network resilience.

 

Highlights: Routing Control Platform

  • Centralized Forwarding Solution

The Routing Control Platform (RCP) is a centralized forwarding solution, similar to BGP SDN that enables the collection of a network topology map, running an algorithm, and selecting the preferred BGP route for each router in an Autonomous System (AS). It does this by peering both the IGP platform and iBGP to neighboring routers and communicating the preferred routes using unmodified iBGP.

It acts similarly to an enhanced route reflector and does not sit in the data path. It is a control plane device, separate from the IP forwarding plane. The RCP protocol exhibits the accuracy of a full mesh iBGP design and scalability enhancements of route reflection without sacrificing route selection correctness.

  • Hot Potato Routing

A potential issue with route reflection is that AS exit best path selection (hot potato routing) is performed by route reflectors from their IGP reference point, which in turn gets propagated to all RR clients scattered throughout the network. As a result, the best path selected may not be optimal for many RR clients as it depends on where the RR client is logically placed in the network.

You may also encounter MED-induced route oscillations. The Routing Control Platform aims to solve this problem.

 

Before you proceed, you may find the following blog BGP of interest:

  1. What is BGP protocol in networking
  2. Full Proxy
  3. What Does SDN Mean
  4. DNS Reflection Attack
  5. Segment Routing

 



Routing Control.

Key Routing Control Platform Discussion Points:


  • Introduction to Routing Control Platform and how it can be used.

  • Discussion on BGP Route Reflectors (RR) and BGP Confederations.

  • Discussion on an IGP platform and how RCP works.

  • Details on extracting the topology.

 

Back to Basics Routing Control Platform

Routing Foundations

A network carries traffic where traffic flows from a start node to an end node; generally, we refer to the start node as the source node and the end node as the destination node. We must pick a path or route from the source node to the destination node. A route can be set up manually; such a route is static. Or we can have a dynamic routing protocol, such as an IGP or EGP.

With dynamic routing protocols, we have the use a routing algorithm. The role of the routing algorithm is to determine a route. Each routing algorithm will have different ways of choosing a path. Finally, a network can be expressed as a graph by mapping each node to a unique vertex in the graph, where links between network nodes are represented by edges connecting the corresponding vertices. Each edge can carry one or more weights; such weights may depict cost, delay, bandwidth, and so on. Many of these methods are now enhanced with an IGP platform and different types of routing control.

 

  • A key point: Replacing iBGP with the OpenFlow protocol

There are proposed enhancements to the Routing Control Platform by replacing iBGP with the OpenFlow protocol, providing additional capabilities beyond next-hop forwarding. This may be useful for a BGP-free edge core and will be addressed later. The following discusses the original Routing Control Platform proposed by Princeton University and AT&T Labs-Research.

 

Benefits of Routing Control Platforms:

1. Enhanced Network Performance:

RCPs offer granular control over routing decisions, allowing network administrators to optimize traffic flow and minimize latency. By intelligently distributing traffic across multiple paths, RCPs ensure that network resources are utilized efficiently, improving network performance and end-user experience.

2. Improved Network Resilience:

RCPs enable organizations to build highly resilient networks by implementing diverse routing paths. In the event of a network failure or congestion, RCPs automatically reroute traffic to alternative paths, ensuring uninterrupted connectivity and minimizing downtime.

3. Increased Security:

Organizations’ network security has become a top priority with the rise in cyber threats. RCPs provide advanced security features, such as traffic filtering and access control, to protect against malicious activities. By centralizing routing control, RCPs enable network administrators to implement robust security policies and mitigate potential risks.

4. Scalability and Flexibility:

As businesses grow and networks expand, scaling and adapting becomes crucial. RCPs offer scalability by allowing organizations to add or remove network devices seamlessly. Additionally, RCPs provide flexibility in managing routing protocols, allowing administrators to easily configure and customize routing policies based on specific business requirements.

Use Cases of Routing Control Platforms:

1. Internet Service Providers (ISPs):

ISPs can leverage RCPs to optimize network performance, enhance customer experience, and manage bandwidth effectively. RCPs allow ISPs to distribute traffic intelligently across their networks, ensuring optimal utilization of infrastructure and reducing congestion.

2. Data Centers:

In data center environments, where high availability and low latency are critical, RCPs play a vital role in achieving efficient routing. By implementing RCPs, data centers can distribute traffic across multiple paths, balancing the load and minimizing response times.

3. Enterprise Networks:

Large enterprises with complex network infrastructures can benefit from RCPs to gain control over routing decisions. RCPs provide centralized management capabilities, simplifying the configuration and monitoring of routing policies across the entire network.

 

iBGP and eBGP

Routers within an AS exchange routes to external destinations using internal BGP (iBGP), and routers are peering external to their AS using external BGP (eBGP). All BGP speakers within a single AS must be fully meshed to propagate external destinations. For loop prevention, the original BGP design states reachability information learned from an iBGP router can not be forwarded to another iBGP router inside the full mesh. eBGP designs use AS-PATH for loop prevention. All routing protocols, not just BGP, require some mechanism to prevent loops.

  • With iBGP, the maximum number of iBGP hops an update can traverse is 1.

 

Route-reflection (RR) and confederations

To combat the scalability concerns with an iBGP full mesh design, in 1996, several alternatives, such as route reflection and confederations, were proposed. Both of these enable hierarchies within the topology. However, route reflection has drawbacks, which may result in path diversity and network performance side effects. There is a trade-off between routing correctness and scalability. With iBGP full mesh designs, if one BGP router fails, it will have a limited impact. An update travels only one i-BGP hop. However, if a route reflector fails, it has an extensive network impact. All iBGP peers peering with the route reflector are affected. 

An update message may traverse multiple route reflectors with a route reflection design before reaching the desired i-BGP router. This may have adverse effects, such as prolonged routing convergence. One of route reflection’s most significant adverse effects is reduced path diversity. A high path diversity can increase resilience, while low path diversity will decrease resilience. Since a route reflector only passes its best route, all clients peering with that route reflector use the same best path for that given destination.

 

  • A key point: Lab on BGP Route-Reflection

The following lab guide will look at the BGP RR if you don’t want a full mesh of iBGP speakers. Route reflectors (RR) are one method to eliminate the full mesh of IBGP peers in your network. The other method is BGP confederations.

The route reflector allows all IBGP speakers within your autonomous network to learn about the available routes without introducing loops. 

The route reflector can have three types of peerings:

    • EBGP neighbor
    • IBGP client neighbor
    • IBGP non-client neighbor

In the example below, we have 3 IBGP routers. With standard IBGP rules, when R2 receives a route from R1, it will not be forwarded to R3 (IBGP split horizon). We will configure R2 as the route reflector to get around this.

BGP Route Reflection
Diagram: BGP Route Reflection

 

Proper route reflector placement and design can eliminate some of these drawbacks. We now have path diversity mechanisms such as the BGP ADD Path capability and parallel peerings for better route reflection design. These were not available during the original RCP proposal.

 

Routing Control Platform (RCP)

The RCP consists of several components, 1) Route Control Server ( RCS), 2) BGP Engine, and 3) IGP platform viewer. It is similar to the newer BGP SDN platform proposed by Petr Lapukhov but has an additional IGP platform viewer function. Petr’s BGP SDN solution proposes a single Layer 3 protocol with BGP – a pure Layer 3 data center.

The RCP platform has two types of peerings: IGP and iBGP. It obtains IGP information by peering with IGP and learns BGP routes with iBGP. The Route Control Server component then analyzes the IGP and BGP viewer information to compute the best path and send it back via iBGP. Notice how the IGP Viewer only needs one peering into each partition in the diagram below.

Routing Control Platform
Diagram: Routing Control Platform

 

Since the link-state protocol uses reliable LSA flooding, the IGP viewer has an up-to-date topology view. To keep the IGP viewer out of the data plane, higher costs are configured on the links to the controller. As discussed, the BGP engine creates iBGP sessions for other directly reachable speakers or via the IGP.

By combining these elements, the RCS has full BGP and IGP topology information and can make routing decisions for routers in a particular partition. The RCP must have complete visibility. Otherwise, it could assign routes that create black holes, forwarding loops, or other issues preventing packets from reaching their destinations.

 

Centralized controller: Extract the topology

RPC uses a centralized controller to extract the topology and make routing decisions. These decisions are then pushed to the data plane nodes to forward data packets. It aims to offer the correctness of full-mesh iBGP designs and the scalability of route reflector designs. It uses iBGP sessions to peer with BGP speakers, learn topology information, and send routing decisions for destination prefixes.

As previously discussed, a route reflector design only sends its best path to clients, which limits path diversity. However, the RCP platform overcomes this route reflector limitation and sends each router a route it would have selected in an iBGP full mesh design.

Conclusion:

Routing Control Platforms empower organizations to take control of their network routing, leading to enhanced performance, improved resilience, and increased security. By leveraging RCPs, businesses can optimize their network infrastructure, ensuring smooth operations and a seamless user experience. As the demand for robust and flexible networks grows, Routing Control Platforms will play an increasingly vital role in effectively managing and controlling network traffic.

 

data center security

BGP SDN – Centralized Forwarding

 

 

BGP SDN: How BGP Works?

The networking landscape has significantly shifted towards Software-Defined Networking (SDN) in recent years. With its ability to centralize network management and streamline operations, SDN has emerged as a game-changing technology. One of the critical components of SDN is Border Gateway Protocol (BGP), a routing protocol that plays a vital role in connecting different autonomous systems. In this blog post, we will explore the concept of BGP SDN and its implications for the future of networking.

Border Gateway Protocol (BGP) is a dynamic routing protocol that facilitates the exchange of routing information between different networks. It enables the establishment of connections and the exchange of network reachability information across autonomous systems. BGP is the glue that holds the internet together, ensuring that data packets are delivered efficiently across various networks.

 

Highlighting: BGP SDN

  • Traffic Engineering

Networks with multiple Border Gateway Protocol (BGP) Autonomous Systems (ASNs) under the same administrative control implement traffic engineering with policy configurations at border edges. Policies are applied on multiple routers distributedly, which can be hard to manage and scale. Any per-prefix traffic engineering changes may need to occur on multiple devices and levels.

A new BGP Software Defined Networking (SDN) solution introduced by P. Lapukhov & E. Nkposong proposes a centralized routing model. It introduces the concept of a BGP SDN controller, also known as an SDN BGP controller with a routing control platform. No protocol extensions or additional protocols are needed to implement the SDN architecture. BGP is employed to push down new routes and peers iBGP with all existing BGP routers.

  • BGP-only Network

A BGP-only network has many advantages, and this solution promotes a more stable Layer 3-only network, utilizing one control plane protocol – BGP. BGP captures topology discovery and links up/down events. BGP can push different information to different BGP speakers, while an IGP has to flood the same LSA throughout the IGP domain.

 



How BGP Works.

Key BGP SDN Discussion Points:


  • Introduction to BGP SDN and how it can be used.

  •  Discussion on traffic forwarding.

  • Discussion on traffic patterns and how they effect designs.

  • BGP SDN and centralized forwarding.

  • A final note on BGP and OpenFlow.

 

For additional pre-information, you may find the following helpful:

  1. OpenFlow Protocol
  2. What Does SDN Mean
  3. BGP Port 179
  4. WAN SDN

 

Back to basics with BGP SDN

BGP Peering Session Overview

A BGP neighbor relationship is called a peer relationship in BGP terminology, unlike OSPF and EIGRP, which implement their transport mechanism. In place of TCP, BGP utilizes BGP TCP port 179 as its transport protocol. A BGP peering session can only be established between two routers after a TCP session has been established between them. Selecting a BGP session consists of establishing a TCP session and exchanging BGP-specific information to establish a BGP peering session.

A TCP session operates on a client/server model. On a specific TCP port number, the server listens for connection attempts. Upon hearing the server’s port number, the client attempts to establish a TCP session. Next, the client sends a TCP synchronization (TCP SYN) message to the listening server to indicate that it is ready to send data.

Upon receiving the client’s request, the server responds with a TCP synchronization acknowledgment (TCP SYN-ACK) message. Finally, the client acknowledges receipt of the SYN-ACK packet by sending a simple TCP acknowledgment (TCP ACK). TCP segments can now be sent from the client to the server. As part of this process, TCP performs a three-way handshake.

BGP explained
Diagram: BGP explained. The source is IPcisco.

 

So how BGP works? BGP is a path-vector protocol that stores routes in the Routing Information Bases (RIBs). The RIB within a BGP speaker consists of three parts:

  1. The Adj-RIB-In,
  2. The Loc-RIB,
  3. The Adj-RIB-Out.

The Adj-RIB-In stores routing information learned from the inbound UPDATE messages advertised by peers to the local router. The routes in the Adj-RIB-In define routes that are available to the path decision process. The Loc-RIB contains routing information the local router selected after applying policy to the routing information in the Adj-RIB-In.

 

  • A Key Point: Lab Guide on BGP Route Reflection

The following lab guide will look at the famous BGP RR if you don’t want a full mesh of iBGP speakers.

Route reflectors (RR) are one method to eliminate the full mesh of IBGP peers in your network. The other method is BGP confederations. The route reflector allows all IBGP speakers within your autonomous network to learn about the available routes without introducing loops.

In the example below, we have 3 IBGP routers. With standard IBGP rules, when R2 receives a route from R1, it will not be forwarded to R3 (IBGP split horizon). We will configure R2 as the route reflector to get around this.

BGP Route Reflection
Diagram: BGP Route Reflection

 

Benefits of BGP Route Reflectors:

1. Scalability: Using BGP RRs, network administrators can significantly reduce the number of iBGP sessions required to maintain full connectivity within an AS. This results in a more scalable network architecture, as the complexity of managing and maintaining a full mesh of iBGP connections is eliminated.

2. Reduced Resource Consumption: With BGP RRs, the burden on individual routers to maintain iBGP sessions is alleviated. Instead, the RRs are responsible for reflecting BGP updates to the appropriate routers within the AS. This reduces the processing and memory requirements on the individual routers, freeing up valuable resources.

3. Simplified Configuration: Implementing BGP RRs simplifies the configuration process by centralizing the distribution of BGP updates. Rather than configuring iBGP sessions between every router within the AS, administrators only need to establish iBGP sessions with the RRs. This streamlined configuration process saves time and reduces the potential for misconfigurations.

 

The Emergence of BGP in SDN:

Software-Defined Networking (SDN) introduces a paradigm shift in how networks are managed and operated. Traditionally, network devices such as routers and switches were responsible for handling routing decisions. However, with the advent of SDN, the control plane is decoupled from the data plane, allowing for centralized management and control of the network.

BGP plays a crucial role in the SDN architecture by acting as a control protocol that enables communication between the controller and the network devices. It provides the intelligence and flexibility required for orchestrating network policies and routing decisions in an SDN environment.

Benefits of BGP SDN:

1. Simplified Network Management: BGP SDN simplifies network management by centralizing control and configuration. This allows network administrators to easily define and enforce policies across the entire network, reducing complexity and improving operational efficiency.

2. Scalability and Flexibility: BGP SDN offers enhanced scalability and flexibility compared to traditional networking approaches. With BGP, network administrators can dynamically adapt the routing policies based on network conditions, ensuring optimal traffic flow and load balancing.

3. Improved Network Security: BGP SDN provides enhanced security features by allowing fine-grained control over network access and traffic routing. It enables the implementation of robust security policies, such as traffic isolation and encryption, to protect against potential threats.

4. Increased Network Resilience: BGP SDN improves network resilience by enabling automated failover mechanisms. In a network failure, the centralized controller can efficiently reroute traffic, ensuring uninterrupted connectivity and minimizing downtime.

 

Layer-2 and Layer-3 Technologies

Traditional forwarding routing protocols and network designs comprise a mix of Layer 2 and 3 technologies. Topologies resemble trees with different aggregation levels, commonly known as access, aggregation, and core. IP routing is deployed at the top layers, while Layer 2 is in the lower tier to support VM mobility and other applications requiring Layer 2 VLANs to communicate.

Fully routed networks are more stable as they confine the Layer 2 broadcast domain to certain areas. Layer 2 is segmented and confined to a single switch, usually used to group ports. Routed designs run Layer 3 to the Top of the Rack (ToR), and VLANs should not span ToR switches. As data centers grow in size, the stability of IP has been preferred over layer 2 protocols.

 

  • A key point: Traffic patterns

Traditional traffic patterns leave the data center, known as north-to-south traffic flow. In this case, traditional tree-like designs are sufficient. Upgrades consist of scale-out mechanisms, such as adding more considerable links or additional line cards. However, today’s applications, such as Hadoop clusters, require much more server-to-server traffic, known as east-to-west traffic flow.

Scaling up traditional tree topologies to match these traffic demands is possible but not an optimum way to run your network. A better choice is to scale your data center horizontally with a CLOS topology ( leaf and spine ), not a tree topology.

Leaf and spine topologies permit equidistant endpoints and horizontal scaling, resulting in a perfect combination for optimum east-to-west traffic patterns. So what layer 3 protocol do you use for your routing design? An Interior Gateway Protocol (IGP), such as ISIS or OSPF? Or maybe BGP? BGP’s robustness makes it a popular Layer 3 protocol for reducing network complexity.

how bgp works

How BGP works with BGP SDN: Centralized forwarding

What is BGP protocol in networking? Regarding internal data structures, BGP is less complex than a link-state IGP. Instead of forming adjacency maintenance and controls, it runs all its operations over Transmission Control Protocol (TCP) and uses TCP’s robust transport mechanism.

BGP has considerably less flooding overhead than IGPs, with a single flooding domain propagation scope. BGP is great for reducing network complexity and is selected as this SDN solution’s singular control plane mechanism for these reasons.

Peter has written a draft called “Centralized Routing Control in BGP Networks Using Link-State Abstraction,” discussing the use case of BGP for centralized control of routing in the network.

The main benefit of the architecture is centralized control as opposed to distributed. There is no need to configure policies on multiple devices. All changes are done with an API into the controller.

BGP SDN
Diagram: BGP SDN. The inner workings.

 

A link-state map 

The network looks like a collection of BGP ASN, and the entire routing is done with BGP only. First, BGP builds a link-state map of the network in the controller memory.

Then, they use BGP to discover the topology and notice link-up and link-down events. Instead of installing a 5-tuple that can install flows based on the entire IP header, the BGP SDN solution offers destination-based forwarding only. For additional granularity, implement BGP flow spec, RFC 55745, entitled “Dissemination of Flow Specification Rules.” 

 

Routing Control Platform

The proposed method was inspired by the Routing Control Platform (RCP). The RCP platform uses a controller-based function and selects BGP routes on behalf of the routers in an AS using a complete view of the available routes and IGP topology. The RCP platform has similar properties to the BGP SDN solution.

Both run iBGP peers to all routers in the network and influence the default topology by changing the controller and pushing down new routes. However, a significant difference is that the RCP has additional IGP peerings. It’s not a BGP-only network. BGP SDN promotes a single control plane of BGP without any IGPs.

BGP is used to health detect, build a link-state map, and represent the network to a 3rd party application as multiple topologies. You can map prefixes to different topologies and change link costs from the API.

 

Multi-Topology view

The agent builds the link-state database and presents a multi-topology view of this data to the client applications. You may clone this topology and give certain links higher costs, mapping some prefixes to this new non-default topology. The controller pushes new routes down with BGP.

The peering is based on iBGP, so new routes are set with a better Local Preference, enabling them to be selected higher in the BGP path decision process. It is possible to do this with eBGP, but iBGP can be more accessible. With iBGP, you don’t need to care about the next hops.

 

BGP and OpenFlow

What is OpenFlow? BGP works like OpenFlow and pushes down the forwarding information. It populates routes in the forwarding table. Instead of using BGP in a distributed fashion, they centralize it. One main benefit of using BGP over OpenFlow is that you can shut the controller down, and regular BGP operation continues on the network.

But if you transition to an OpenFlow configuration, you cannot roll back as quickly as you could with BGP. Using BGP inband has great operational benefits. A great design by P. Lapukhov. No need to deploy BGP-LS or any other enhancements to BGP.

 

Future Outlook:

As the demand for more agile and efficient networks continues to grow, BGP SDN is expected to play a pivotal role in shaping the future of networking. Its ability to simplify network management, enhance scalability, and improve security makes it an ideal choice for organizations seeking to modernize their network infrastructure.

Conclusion:

BGP SDN represents a significant advancement in networking technology, allowing organizations to build agile, scalable, and secure networks. By centralizing control and leveraging the intelligence of BGP, SDN has the potential to revolutionize how networks are managed and operated. As the industry embraces SDN, BGP will continue to play a crucial role in enabling the next generation of network infrastructure.