Cisco ACI

ACI Cisco

by Publications

Cisco ACI Components

In today's rapidly evolving technological landscape, organizations are constantly seeking innovative solutions to streamline their network infrastructure. Enter Cisco ACI Networks, a game-changing technology that promises to redefine networking as we know it. In this blog post, we will explore the key features and benefits of Cisco ACI Networks, shedding light on how it is transforming the way businesses design, deploy, and manage their network infrastructure.

Cisco ACI, short for Application Centric Infrastructure, is an advanced networking solution that brings together physical and virtual environments under a single, unified policy framework. By providing a holistic approach to network provisioning, automation, and orchestration, Cisco ACI Networks enable organizations to achieve unprecedented levels of agility, efficiency, and scalability.

Simplified Network Management: Cisco ACI Networks simplify network management by abstracting the underlying complexity of the infrastructure. With a centralized policy model, administrators can define and enforce network policies consistently across the entire network fabric, regardless of the underlying hardware or hypervisor.

Enhanced Security: Security is a top concern for any organization, and Cisco ACI Networks address this challenge head-on. By leveraging microsegmentation and integration with leading security platforms, ACI Networks provide granular control and visibility into network traffic, helping organizations mitigate potential threats and adhere to compliance requirements.

Scalability and Flexibility: The dynamic nature of modern business demands a network infrastructure that can scale effortlessly and adapt to changing requirements. Cisco ACI Networks offer unparalleled scalability and flexibility, allowing businesses to seamlessly expand their network footprint, add new services, and deploy applications with ease.

Data Center Virtualization: Cisco ACI Networks have revolutionized data center virtualization by providing a unified fabric that spans physical and virtual environments. This enables organizations to achieve greater operational efficiency, optimize resource utilization, and simplify the deployment of virtualized workloads.

Multi-Cloud Connectivity: In the era of hybrid and multi-cloud environments, connecting and managing disparate cloud services can be a daunting task. Cisco ACI Networks facilitate seamless connectivity between on-premises data centers and various public and private clouds, ensuring consistent network policies and secure communication across the entire infrastructure.

Cisco ACI Networks offer a paradigm shift in network infrastructure, empowering organizations to build agile, secure, and scalable networks tailored to their specific needs. With its comprehensive feature set, simplified management, and seamless integration with virtual and cloud environments, Cisco ACI Networks are poised to shape the future of networking. Embrace this transformative technology, and unlock a world of possibilities for your organization.

Matt Conran

Highlights: Cisco ACI Components

The ACI Fabric

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.

–The Cisco 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.

a) Cisco ACI Fabric: Cisco ACI’s foundation lies in its fabric, which forms the backbone of the entire infrastructure. The ACI fabric comprises leaf switches, spine switches, and the application policy infrastructure controller (APIC). Each component ensures a scalable, agile, and resilient network.

b) Leaf Switches: Leaf switches serve as the access points for endpoints within the ACI fabric. They provide connectivity to servers, storage devices, and other network devices. With their high port density and advanced features, such as virtual port channels (vPCs) and fabric extenders (FEX), leaf switches enable efficient and flexible network designs.

c) Spine Switches: Spine switches serve as the core of the ACI fabric, providing high-bandwidth connectivity between the leaf switches. They use a non-blocking, multipath forwarding mechanism to ensure optimal traffic flow and eliminate bottlenecks. With their modular design and support for advanced protocols like Ethernet VPN (EVPN), spine switches offer scalability and resiliency.

d) Application Policy Infrastructure Controller (APIC): At the heart of Cisco ACI is the APIC, a centralized management and policy control plane. The APIC acts as a single control point, simplifying network operations and enabling policy-based automation. It provides a comprehensive view of the entire fabric, allowing administrators to define and enforce policies across the network.

e) Integration with Virtualization and Cloud Environments: Cisco ACI seamlessly integrates with virtualization platforms such as VMware vSphere and Microsoft Hyper-V and cloud environments like Amazon Web Services (AWS) and Microsoft Azure. This integration enables consistent policy enforcement and visibility across physical, virtual, and cloud infrastructures, enhancing agility and simplifying operations.

–ACI Architecture: Spine and Leaf–

To be used as ACI spines or leaves, Nexus 9000 switches 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 spines or leaves to utilize an automated, policy-based systems management approach fully. 

Cisco ACI Components
Diagram: Cisco ACI Components. Source is Cisco

**Hardware-based Underlay**

Server virtualization helped by decoupling 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 similarly to the agility gained from server virtualization.

**Mapping Network Endpoints**

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.

**Specialized Forwarding Chips**

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.

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

  1. Data Center Security 
  2. VMware NSX

Cisco ACI Components

 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, a leaf switch set creates 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.

The ACI fabric: Does Not Aggregate Traffic

A key point in the spine-and-leaf design is the fabric concept, like a stretch network. One of the core ideas around a fabric is that it does 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.

Required: Increased Bandwidth Available

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.

Challenge: 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, allowing us to carry the streams parallel.

Required: Routed Multipathing

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. 

**Overlay and Underlay Design**

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.

L3 active-active links: 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. We don’t need to rely on STP to block links or involve STP in fixing the topology.

Challenge: IP – Identity & Location

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 indicate 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.

Required: 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 on a per-packet basis and, therefore, must be done quickly and efficiently.

**Overlay and Underlay Components**

The Cisco SDN ACI has an overlay and underlay concept, which forms 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

Underlay & Overlay Interaction

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.

App-A did not track App-B’s movement at all. App-B’s address identified It, while the switch’s address, S2 or S3, identified its location. App-A can communicate freely with App-B no matter where It is located, allowing the system administrator to place App-B in any area 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 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. 

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 Domains 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. 

Direct host routing for endoints

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 and offers remarkably optimized fabric to know 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 device’s role. 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), which are also known as the physical tunnel endpoints (PTEP) in ACI. These PTEP addresses represent the “WHERE” in the ACI fabric where an endpoint lives. 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, which are 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.

**Anycast IP Addressing**

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.

The ACI optimizations

**Mouse and elephant flow**

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 the traffic to the other Leaf. If not, it will drop it.

**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.

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.

  • Extending & Integrating the fabric

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 Multi-Pod Design

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.

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 network security policy management across on-premises firewalls, SDNs, and cloud environments. They also provide visibility into ACI’s security posture, even across multi-cloud environments. 

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.

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 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.

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.

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.

OpenShift and Cisco ACI

OpenShift does this with an SDN layer and enhances Kubernetes networking to create a virtual network across all the nodes. It is made 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. This forms an OVS network that gets programmed with several OVS rules. The OVS is a popular open-source solution for virtual switching.

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, several modes are 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.

Cisco ACI CNI Plugin

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.

Cisco SDN ACI and AppDynamics

AppDynamis overview

So, an application requires multiple steps or services to work. These services may include logging in and searching to add something to a shopping cart. These services 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, your system will degrade. So, you need ways to discover your business transactions and determine if there are any deviations from baselines. This should also be 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.

AppDynamic topology

AppDynamics will automatically discover the topology for all of your application components. 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, which 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 manually is hard, if not impossible, with complex applications. It is much better to have this done automatically. You must automatically establish the baseline and alert yourself about deviations from it.

This will help you pinpoint the issue faster and resolve it before it 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.

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.

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.

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.

Hyperscale Application Delivery

Application Delivery Architecture

by Blog

Application Delivery Network

In today's fast-paced digital world, where businesses strive to deliver seamless user experiences with lightning-fast performance, application delivery architecture plays a pivotal role. This blogpost explores the importance of optimizing application delivery architecture and how it revolutionizes the way we deliver and consume applications.

Application delivery architecture refers to the framework and infrastructure that enables the efficient and secure delivery of applications to end-users. It encompasses various components such as load balancers, proxies, caching mechanisms, and content delivery networks (CDNs). These components work together to ensure high availability, scalability, and optimal performance.

By optimizing application delivery architecture, businesses can unlock a myriad of benefits. Firstly, it enhances scalability, allowing applications to handle increasing user demands without compromising performance. Secondly, it improves application availability by reducing downtime and ensuring continuous service delivery. Additionally, it boosts security through advanced threat protection mechanisms and secure access controls.

Load balancing is a crucial aspect of application delivery architecture. It distributes incoming network traffic across multiple servers to prevent overloading and optimize resource utilization. By implementing intelligent load balancing algorithms, businesses can achieve optimal performance, maximize throughput, and eliminate single points of failure.

Content Delivery Networks (CDNs) are instrumental in improving the delivery speed and efficiency of web-based applications. CDNs store cached copies of static content in geographically distributed servers, allowing users to access data from servers closest to their location. This minimizes latency, reduces network congestion, and enhances overall user experience.

In conclusion, optimizing application delivery architecture is a crucial step towards revolutionizing the way we deliver and consume applications. By leveraging the power of efficiency and scalability through load balancing, CDNs, and other components, businesses can ensure seamless user experiences, higher productivity, and a competitive edge in the digital landscape.

Matt Conran

Highlights: Application Delivery Network

Application Delivery Network

Understanding Application Delivery Architecture

Application Delivery Architecture refers to the framework, infrastructure, and processes involved in delivering applications to end-users. It encompasses various elements such as load balancers, web servers, caching mechanisms, content delivery networks (CDNs), and more. The primary goal is to ensure fast, secure, and reliable application delivery while optimizing resource utilization.

Load Balancers: Load balancers distribute incoming application traffic across multiple servers, ensuring efficient workload distribution and preventing any single server from being overwhelmed. They enhance application availability, scalability, and fault tolerance.

Web Servers: Web servers handle incoming requests from clients and deliver the requested web pages or content. They play a critical role in processing dynamic content, executing scripts, and interacting with backend databases or applications.

Caching Mechanisms: Caching mechanisms, such as content caching and session caching, reduce the load on backend servers by storing frequently accessed data or session information closer to the client. This improves response times and reduces network latency.

Content Delivery Networks (CDNs): CDNs are geographically distributed networks of servers that deliver web content to end-users based on their location. By caching content in multiple locations, CDNs ensure faster delivery, lower latency, and improved user experience.

Best Practices for Optimizing Application Delivery Architecture

Scalability and Redundancy: Designing an architecture that allows for horizontal scalability and redundancy is crucial for handling increasing application loads and ensuring high availability. Implementing auto-scaling mechanisms and replicating critical components across multiple servers or data centers helps achieve this.

Security and Performance Optimization: Implementing robust security measures, such as firewalls, intrusion detection systems, and SSL certificates, protects applications from cyber threats. Additionally, optimizing performance through techniques like content compression, connection pooling, and query optimization enhances overall application speed and responsiveness.

Monitoring and Analytics: Monitoring the performance and health of application delivery infrastructure is essential for proactive issue identification and resolution. Utilizing real-time analytics and logging tools helps in identifying bottlenecks, optimizing resource allocation, and ensuring peak performance.

Example: Proxy Servers

Understanding Squid Proxy Server

Squid Proxy Server is an open-source caching and forwarding HTTP web proxy server. It acts as an intermediary between the client and the server, allowing client requests to be fulfilled by caching and forwarding the server’s responses. With its robust architecture and extensive configuration options, Squid Proxy Server provides enhanced performance, security, and control over internet traffic.

Caching Capabilities:

Squid Proxy Server excels in caching web content, which leads to faster response times and reduced bandwidth consumption. By storing frequently accessed web content locally, Squid significantly minimizes the load on the network and accelerates subsequent requests.

Access Control and Security:

One of the notable advantages of Squid Proxy Server is its robust access control mechanisms. It allows administrators to define granular policies, restrict access to specific websites, block malicious content, and enforce authentication protocols, thereby enhancing security and ensuring compliance with organizational requirements.

Bandwidth Management:

With its comprehensive bandwidth management features, Squid Proxy Server enables organizations to optimize network utilization efficiently. It provides options to prioritize or limit bandwidth for different types of traffic, ensuring a fair distribution of resources and preventing congestion.

Highlighting the components:

According to Gartner, application delivery networking combines WAN optimization controllers (WOCs) with application delivery controllers (ADCs). ADNs have Advanced Traffic Management Devices (ADCs), often called web switches, content switches, or multilayer switches. Traffic is distributed between servers or geographically dispersed sites based on application-specific criteria. In addition to caching and compression, ADNs utilize TCP traffic optimization techniques such as prioritization and other methods to reduce the amount of data flowing over the network.

Data centers usually install some WOC components, while PCs and mobile devices install others. Some CDN vendors also offer application delivery networks.

Understanding Load Balancing

Load balancing is the process of distributing incoming network traffic across multiple servers to ensure efficient resource utilization and prevent overload. By intelligently managing requests, load balancers like HAProxy enhance performance and reliability. In this section, we will explore the fundamental concepts of load balancing and its importance in modern web applications.

HAProxy, an abbreviation for High Availability Proxy, is an open-source, software-based load balancer renowned for its speed, reliability, and flexibility. It acts as an intermediary between clients and servers, efficiently distributing incoming requests based on various algorithms and configurations. In this section, we will dive into the features, benefits, and use cases of HAProxy.

To unleash the power of HAProxy, it is essential to set it up correctly. In this section, we will walk you through the step-by-step installation and configuration process for HAProxy on your preferred operating system. From securing your system to fine-tuning load balancing rules, we will cover everything you need to get started with HAProxy.

Google Cloud Google 

Understanding Network Tiers

Network tiers refer to the different levels of network performance and availability offered by cloud service providers. In the case of Google Cloud, there are three tiers: Premium, Standard, and Subnet. Each tier comes with its own set of features, pricing structures, and service level agreements (SLAs). Understanding these tiers is crucial for making informed decisions about network configuration.

The Premium Tier offers the highest network performance and lowest latency, making it ideal for mission-critical applications that require real-time interactions and high bandwidth. By utilizing the Premium Tier for such workloads, businesses can ensure maximum reliability and responsiveness, guaranteeing a seamless user experience even during peak traffic periods.

For applications that don’t require the ultra-low latency of the Premium Tier, Google Cloud’s Standard Tier presents a cost-effective alternative. This tier provides a balance between performance and affordability, making it suitable for a wide range of workloads. By strategically deploying applications on the Standard Tier, businesses can achieve substantial cost savings without compromising on network performance.

VPC Networking

VPC networking is a vital feature provided by cloud service providers, such as Amazon Web Services (AWS) and Google Cloud Platform (GCP). It enables users to create isolated virtual networks within the cloud infrastructure, mirroring the functionality of traditional on-premises networks. By defining their own virtual network environment, users gain complete control over IP addressing, subnets, routing, and security.

Within the realm of VPC networking, several key components play crucial roles. These include subnets, route tables, security groups, network access control lists (NACLs), and internet gateways. Subnets divide the VPC IP address range into smaller segments, while route tables control the traffic flow between subnets. Security groups and NACLs enforce access control and traffic filtering, ensuring the security of the VPC. Internet gateways act as the entry and exit points for internet traffic.

Understanding Load Balancing

Load balancing is the process of efficiently distributing incoming network traffic across multiple servers to optimize resource utilization, maximize throughput, and minimize response time. On Google Cloud, there are several load balancing options available, each serving different purposes and catering to specific needs.

Google Cloud provides three main load balancing options: HTTP(S) Load Balancing, Network Load Balancing, and Internal Load Balancing.

HTTP(S) Load Balancing: HTTP(S) Load Balancing is designed for HTTP/HTTPS traffic and is ideal for web applications. It distributes traffic to backend instances based on various factors such as URL, HTTP headers, and session affinity.

Network Load Balancing: Network Load Balancing is a regional load balancer that operates at the transport layer (Layer 4) of the OSI model. It is suitable for TCP/UDP-based traffic and provides high-performance, low-latency load balancing for non-HTTP workloads.

Internal Load Balancing: Internal Load Balancing is used for load balancing traffic within a Google Cloud Virtual Private Cloud (VPC) network. It ensures that internal services are highly available and can scale seamlessly as needed.

Understanding Cloud CDN

Cloud CDN, powered by Google Cloud, is a network of servers strategically placed across the globe. Its primary function is to efficiently distribute content to end-users by reducing latency and increasing website loading speeds. By caching static content and delivering it from the nearest server to the user, Cloud CDN ensures a seamless browsing experience.

Improved Performance: With Cloud CDN, businesses can significantly reduce latency, resulting in faster loading times for their websites and applications. This enables a smoother user experience and increases customer satisfaction.

Enhanced Scalability: Cloud CDN automatically scales resources based on demand, ensuring high availability and preventing performance degradation, even during peak traffic periods. This scalability eliminates concerns about sudden traffic spikes and allows businesses to focus on their core operations.

Cost-Effective: By leveraging Cloud CDN, businesses can reduce bandwidth costs and decrease the load on their origin servers. The distributed nature of Cloud CDN optimizes content delivery and minimizes the need for additional infrastructure investments.

Understanding Load Balancing in Google Cloud

Before we dive into the specifics of network and HTTP load balancers, it’s essential to grasp the fundamental concept of load balancing in Google Cloud. Load balancing distributes incoming traffic across multiple instances or backend services, enabling efficient resource utilization and improved application performance.

Network Load Balancing: Network Load Balancing is a powerful service provided by Google Cloud that operates at the transport layer (Layer 4) of the OSI model. It efficiently distributes traffic to backend instances based on configurable forwarding rules and health checks. With network load balancers, you can achieve high throughput, low latency, and fault tolerance for your applications.

HTTP Load Balancing: HTTP Load Balancing, on the other hand, works at the application layer (Layer 7) and provides advanced features specific to HTTP and HTTPS traffic. With HTTP load balancers, you can perform content-based routing, SSL offloading, and session affinity, among other capabilities. It’s an excellent choice for web applications that require intelligent traffic distribution and flexibility.

To ensure optimal performance and reliability of your load balancers, it’s crucial to follow best practices. Some key recommendations include setting up health checks to monitor backend instances, using multiple regions for high availability, optimizing load balancer configurations based on your application’s requirements, and regularly reviewing and adjusting capacity settings.

The Role of Applications

Applications are delivered to end users using a variety of technologies and processes. Modern digital landscapes require flawless application delivery to meet user expectations, maintain business operations, remain competitive, and adapt to changing needs.

Many organizations and individuals rely on applications every day to conduct their day-to-day operations and daily lives. Secure and reliable application delivery is a keystone of the modern app economy. Many applications must respond instantly and reliably to millions of concurrent users to boost customer satisfaction and revenue.

Example Technology: Netflow

Netflow is a network protocol developed by Cisco Systems that enables the collection and analysis of IP traffic data. It records information about the source and destination IP addresses, ports, protocol types, and other relevant network flow details. Netflow allows network administrators to gain visibility into the traffic traversing their networks by capturing this information.

Netflow offers a multitude of benefits for network monitoring and management. Firstly, it provides valuable insights into network traffic patterns, allowing administrators to identify bandwidth-hungry applications, detect anomalies, and optimize network performance. Additionally, Netflow data can aid in identifying and mitigating security threats, as it provides detailed information about potential malicious activities and suspicious traffic behavior.

Application Delivery and Its Role

Optimizing the speed and responsiveness of applications is one of the primary roles of application delivery. Our increasingly digital lives require end users to have fast and efficient access to the applications they use to shop, bank, work, and play. In addition to ensuring business continuity and user convenience, application delivery focuses on ensuring that applications are available and accessible at all times. Securing applications is vital, protecting sensitive data, preventing cyberattacks, and maintaining user trust.

Delivering applications effectively is essential.

User frustration can result from frequent downtime or interruptions of service. When sluggish or unresponsive, applications can frustrate users and negatively affect their overall experience. Users expect smooth and fast application loading. Consistently accessible and fast-loading applications contribute to user satisfaction. 

Application performance directly impacts customer experience in industries where customer-facing applications are critical to business, such as e-commerce or online services. High availability and high-performance applications give companies a competitive advantage, increasing market share and revenue. When customers are satisfied, the likelihood of making purchases is higher. 

Delivering Applications

Application Delivery Architecture is a crucial aspect of modern software development and deployment. It plays a significant role in ensuring the efficient delivery of applications to end-users. With the increasing demand for high-performance applications and the need for seamless user experiences, organizations are investing heavily in optimizing their application delivery architecture.

In a nutshell, application delivery architecture refers to the framework and infrastructure that enables the delivery of applications to end-users. It encompasses various components, including networking, load balancing, security, and scalability. The ultimate goal is to ensure that applications are delivered efficiently, reliably, and securely, regardless of the user’s location or device.

Example Technology: Fault Tolerance

Fault tolerance is provided at the server level, within pools and farms. If the primary server(s) in the pool fails, the ADN activates a backup server automatically.

In case of a hardware or software failure, the ADN ensures application availability and reliability by seamlessly switching to a secondary device. In this way, traffic continues to flow even if one device fails, ensuring application fault tolerance. ADNs implement fault tolerance either through network connections or serial connections.

Failover based on the network.

Two devices share a Virtual IP Address (VIP). A heartbeat daemon on the secondary device verifies the primary device to be active. If the heartbeat is lost, the secondary device takes over the VIP. Although most ADN replicate sessions from the primary to the secondary, this is not an immediate process, and there is no way to guarantee that sessions initiated before the secondary assumes the VIP will be maintained.

Application Delivery Components

Application delivery systems that optimize network availability rely on the following three components: high availability, which benefits both users and businesses by ensuring a seamless user experience, faster application response times, and efficient resource usage.

Load Balancer

A load balancer distributes incoming network traffic across multiple server instances, ensuring application or service availability and performance. It also ensures redundancy and failover capabilities if one server becomes unavailable or overloaded. Load balancers use various algorithms to determine how traffic should be distributed to backend servers. 

Modern networked environments require load balancing to manage and optimize traffic flows. This ensures a seamless and responsive user experience while maintaining system availability and responsiveness, even under heavy load or when servers fail.

Caching

Caching is a critical component of an ADN that improves application response times. Caches store frequently accessed data, such as web pages or images, closer to the end-user. When a user requests the same content again, the cache delivers it quickly, reducing the need for data retrieval from the source. This accelerates application delivery and reduces the load on backend servers.

Content Delivery Networks (CDNs)

CDNs, distributed servers strategically located in various geographic locations, cache and serve content such as web pages, images, videos, and other static assets. When a user makes a request, content is delivered from the nearest edge server to reduce latency, improve load times, and increase application efficiency. 

CDNs benefit both content providers and end users by optimizing the delivery of web content and applications. Most CDNs have servers around the globe, so users can access content quickly, regardless of where they are. Security features are also often included in CDNs, including DDoS protection, web application firewall capabilities, and encryption to guard against malicious traffic and cyberattacks.

Application Delivery Network (ADN)

ADNs optimize the performance, availability, and security of web applications. In addition to CDNs, they provide web apps, APIs, and other transactional services that overcome the complexities associated with dynamic, interactive, and personalized content delivery. ADNs are primarily responsible for ensuring that web apps and services are delivered efficiently, reliably, and securely.

CDNs and ADNs are similar in optimizing content and applications but serve distinct purposes. A CDN reduces latency and increases the speed of content retrieval for static content, such as images, videos, and scripts. By optimizing the entire application stack, ADNs go beyond static content delivery and are suited for web applications, e-commerce platforms, and services that require efficient transactional handling. To achieve a more vital, holistic approach to content and application delivery, many organizations integrate both CDNs and ADNs into their infrastructure.

Application Acceleration

Techniques and technologies used to accelerate applications are known as application acceleration. Data compression reduces data sent over the network, improves response times, and reduces bandwidth consumption by reducing the amount of data sent. Streaming videos, playing games online, and participating in video conferences require real-time or low-latency communication. Another technique to accelerate applications is data caching, which stores frequently accessed data at edge locations in a cache. The cache is checked first when a user or application requests data. A cached version of the data can be delivered much faster than a source-based one. 

Web and application servers, application delivery controllers, and load balancers can perform applications such as data caching and compression outside CDNs. 

Vendor Example: AVI Networks

Avi networks offer load balancing as a hyper-scale application delivery architecture and optimization service. Hyperscale can be defined as the ability of the architect to scale as demand increases for the system. At the same time, application demand changes, so the system architecture is automatically based on traffic load. The Avi load balancer requires no capacity pre-provisioning, making it a perfect cloud application delivery platform.

When companies buy load balancers ( application delivery platforms ), they buy 2 x 10G load balancer appliances and check they can support x of Secure Sockets Layer ( SSL ) connections—probably purchased without application analytics, causing the appliance to be under or over-utilized. Avi scaling feature enables application delivery services to be elastically scaled out and scaled in on-demand. They are maximizing network resources and enabling hyper-scale application delivery architecture.

VMware NSX ALB

**What is NSX ALB?**

NSX ALB, formerly known as Avi Networks, is a modern, software-defined load balancing solution that integrates seamlessly into VMware’s NSX ecosystem. Unlike traditional hardware-based load balancers, NSX ALB offers a flexible, cloud-native approach to managing network traffic. With its advanced analytics, automation, and multi-cloud capabilities, NSX ALB stands out as a game-changer in the field of network services.

**Key Features of NSX ALB**

– **Scalability:** NSX ALB can dynamically scale to handle increasing traffic loads, ensuring optimal performance during peak times.

– **Automation:** The platform automates routine network management tasks, reducing the need for manual intervention and minimizing human error.

– **Analytics:** With real-time insights and detailed analytics, NSX ALB allows administrators to monitor network performance, troubleshoot issues, and make data-driven decisions.

– **Security:** NSX ALB includes robust security features, such as SSL/TLS termination and DDoS protection, to safeguard your network from threats.

Understanding Browser Caching

Browser caching is a mechanism that allows web browsers to store certain resources locally. By doing so, subsequent visits to the website can be significantly faster, as the browser retrieves the cached resources instead of fetching them from the server. This reduces the amount of data that needs to be transferred, resulting in faster page load times.

Nginx, a popular web server and reverse proxy server, offers a powerful module called “header” that enables fine-grained control over HTTP headers. These headers can be leveraged to implement browser caching directives, instructing the browser on how long it should cache specific resources.

One of the key directives provided by Nginx’s header module is “Cache-Control.” By properly configuring the Cache-Control header, we can specify caching behavior for different resources. For example, we can set a longer cache duration for static resources like CSS and JavaScript files, while ensuring that dynamic content remains fresh by setting appropriate cache-control directives.

While setting cache durations is important, it’s equally crucial to handle cache invalidation effectively. Nginx’s header module offers various mechanisms to achieve this. By using techniques like cache busting and cache purging, we can ensure that updated resources are fetched by the browser when necessary, while still benefiting from the performance gains of browser caching.

Before you proceed, you may find the following useful:

  1. Virtual Firewalls.
  2. Scaling Load Balancers
  3. What is BGP Protocol in Networking
  4. Application Delivery Network
  5. Full Proxy
  6. A10 Networks

Application Delivery Network

A load balancer is a physical or virtual appliance that sits before your servers and routes client requests across all servers. A load balancer has a lot of additional capabilities that can fulfill those requests in a manner that maximizes speed and capacity utilization and ensures that no one server is overworked, which could degrade application performance.

It does all of this with a load balancer algorithm. Consider a load balancer to act as a reverse proxy and distribute network or application traffic across several servers. Load balancers increase applications’ capacity (concurrent users) and reliability.

application delivery architecture
Diagram: Application delivery architecture.

High Availability and Low Latency

One of the critical components of application delivery architecture is the network infrastructure. A robust network infrastructure is essential for ensuring high availability and low latency. This involves deploying multiple data centers in geographically diverse locations, interconnected with high-speed links. Organizations can achieve improved performance, fault tolerance, and resilience by distributing application delivery across multiple data centers.

Load balancing is another critical aspect of application delivery architecture. It involves distributing network traffic across multiple servers to optimize resource utilization and ensure high availability. Load balancers act as intermediaries between the user and the application servers, intelligently routing requests to the most suitable server based on server load, response time, and server health. This helps to prevent any single server from becoming overwhelmed and ensures that applications are accessible and responsive.

Security is paramount

Security is a paramount concern in application delivery architecture. With increasing cyber threats, organizations must implement robust security measures to protect sensitive data and prevent unauthorized access. This includes implementing firewalls, intrusion detection systems, and encryption technologies to safeguard the application infrastructure and user data. Additionally, application delivery controllers can provide advanced security features such as web application firewalls and SSL/TLS termination to protect against common web-based attacks.

Scalability

Scalability is another important consideration in application delivery architecture. As user demand fluctuates, organizations must scale their application infrastructure accordingly to accommodate increasing traffic. This can be achieved through horizontal scaling, where additional servers are added to handle the increased load, or vertical scaling, which involves upgrading existing servers with more powerful hardware. By adopting a scalable architecture, organizations can ensure that their applications can handle peak traffic without compromising performance or user experience.

The Need for Application Delivery Architecture

Today’s application – less deterministic

Application flows are becoming less deterministic, and architects can no longer rely on centralized appliances for efficient application delivery. Avi Networks overcome this problem by offering a scale-out application delivery controller. Avi describes their product as a cloud application delivery platform. The core of its technology is based on analyzing application and network telemetry.

From this information, the application delivery appliance can efficiently balance the load. The additional information gained from analytic gathering arms Avi networks against unpredictable application experiences and “Black Friday” events. Traditional load balancers route user requests or sessions to servers based on the request’s characteristics. Avi operates with the same principles and adds additional value by analyzing other telemetry parameters of request characteristics.

A lot has changed in the data center with emerging trends such as mobile and cloud. Customers are looking to redesign the data center with increasing user experience. As a result, the quality of user experience becomes increasingly unpredictable and inconsistent. Load balancers should be analytics-driven, but unfortunately, many enterprise customers do not have that type of network assessment. Avi networks aim to bring the enterprise the additional benefits of analytically driven load-balancing decisions.

Hyperscale application delivery: How does it work?

They offer a scalable load balancer; the critical point is that it is driven by analytics. It tracks real-time users, servers, and network telemetry and feeds all this information to databases that influence the application’s decision. Application visibility and load balancing are combined under one hood creating an elastic software load balancer.

In terms of scalability, if the application gets too many requests, it can spin up new virtual load balancers in VM format to deal with requests and additional loads. You do not have to provision upfront. This type of use case is ideal for “Black Friday” events. But you can see the load in advance since you are tracking the real-time analytics. They typically run in VM format, so you do not need additional hardware. Mid-sized companies are getting the same benefits as massive hyper-scale companies—an ideal solution for retail companies dealing with sporadic peak loads at random intervals.

Avi does not implement any caps on input. So, if you have a short period of high throughput, it is not capped – invoicing is backdated based on traffic peak events. In addition, Avi does not have controls to limit the appliance, so if you need additional capacity in the middle of the night, it will give it to you.

Control and Data Plane

If you want to deal with a scale-out architecture, you need a data plane that can scale out, too. Something must control that data plane, i.e., the control plane. So Avi consists of two components. The first component is the scale-out controller, which has a REST API. The second component is the Service Engine ( SE ).

SE is similar to an HTTP proxy. However, they are terminating one TCP session and opening a different session to the server, so you have to do Source NAT. Source NAT changes the source address in the IP header of a packet. It may also change the source port in the TCP/UDP headers.

With this method, the client IP addresses are Assigned to the load balancer’s local IP. This ensures that server responses go through the correct load-balancing device. However, it also hides the original client’s source IP address.

And since you are sitting at layer 7, you can intercept and do what you want with the HTTP headers. This is not a problem with an HTTP application as they can put the client IP in the HTTP header – X-Forwarded-For (XFF) HTTP header field. The XFF HTTP Header field is the de facto standard for identifying the originating client IP address that is connected to the web server via an HTTP proxy or load balancer. From this, you can tell who the source client is, and because they know the client telemetry, they can do various TCP optimizations for high latency links, high band links, low bandwidth, and low latency links.

The SE sites in the data plane provide essential load-balancing services. Depending on throughput requirements, you can have as many SEs as you want—up to 200. Potentially, you can carve up the SE into admin domains so that sure tenants can access an exact amount of SE regardless of network throughput.  

SE assignments can be fixed or flexible. You can spin up the virtual machine for load-balancing services or have a certain VM per tenant. For example, the DEV test can have a couple of dedicated engines. It depends on the resources you want to dedicate.

Application delivery architecture is critical to modern software development and deployment. Organizations can deliver applications efficiently, reliably, and securely by optimizing the network infrastructure, implementing load balancing, ensuring robust security measures, and adopting scalable practices. As technology continues to evolve, application delivery architecture will remain a key factor in ensuring the success of businesses in the digital age

Highlights: Application Delivery Network

In the ever-evolving world of technology, the smooth and efficient delivery of applications is crucial for businesses to thrive. This blog post delved into the fascinating realm of Application Delivery Architecture (ADA), shedding light on its significance and exploring its various components.

Understanding ADA

ADA, in essence, refers to the overall framework and processes involved in the deployment, management, and optimization of applications. It encompasses a range of elements such as load balancing, content caching, security protocols, and traffic management. Understanding ADA is fundamental to ensure seamless user experiences and enhance overall application performance.

The Key Components of ADA

Load Balancing: The Backbone of ADA

Load balancing plays a pivotal role in ADA by distributing the incoming application traffic across multiple servers, thereby preventing any single server from becoming overwhelmed. This ensures optimal resource utilization and improves application responsiveness.

Content Caching: Accelerating Application Delivery

Content caching involves storing frequently accessed content closer to the end-users, reducing latency and bandwidth consumption. By caching static elements of an application, ADA enhances responsiveness and reduces the strain on backend servers.

Security Protocols: Safeguarding Applications

ADA incorporates robust security protocols to protect applications from potential threats. These measures include firewalls, intrusion detection systems, and SSL encryption, ensuring the confidentiality and integrity of data.

Traffic Management: Efficient Routing for Superior Performance

Efficient traffic management is a critical component of ADA. By intelligently routing requests, ADA optimizes the performance of applications, minimizes response times, and ensures high availability.

Section 4: Benefits of ADA

Enhanced User Experience

ADA plays a vital role in providing users with seamless experiences by optimizing application performance, reducing downtime, and improving responsiveness.

Scalability and Flexibility

With ADA, businesses can easily scale their applications to accommodate growing user demands. The flexibility of ADA allows for efficient resource allocation and dynamic adjustments to meet changing needs.

Improved Security

The comprehensive security measures integrated into ADA ensure that applications are protected against potential threats and vulnerabilities, safeguarding sensitive user data.

Challenges and Considerations

Complexity and Learning Curve

Implementing ADA may pose challenges due to its complexity, requiring businesses to invest in skilled IT personnel or seek assistance from experts.

Cost Considerations

While ADA offers numerous benefits, there may be associated costs involved in terms of hardware, software, and maintenance. Careful planning and cost analysis are essential to ensure a viable return on investment.

Conclusion

In conclusion, Application Delivery Architecture is a vital aspect of modern-day application deployment and management. By leveraging its key components, businesses can achieve enhanced user experiences, improved performance, and robust security. While challenges and costs exist, the benefits of ADA far outweigh the complexities. Embracing ADA empowers businesses to stay at the forefront of technology, delivering applications that captivate and delight users.

What is OpenFlow

What is OpenFlow

by Blog

What is OpenFlow?

In today's rapidly evolving digital landscape, network management and data flow control have become critical for businesses of all sizes. OpenFlow is one technology that has gained significant attention and is transforming how networks are managed. In this blog post, we will delve into the concept of OpenFlow, its advantages, and its implications for network control.

OpenFlow is an open-standard communications protocol that separates the control and data planes in a network architecture. It allows network administrators to have direct control over the behavior of network devices, such as switches and routers, by utilizing a centralized controller.

Traditional network architectures follow a closed model, where network devices make independent decisions on forwarding packets. On the other hand, OpenFlow introduces a centralized control plane that provides a global view of the network and allows administrators to define network policies and rules from a centralized location.

OpenFlow operates by establishing a secure channel between the centralized controller and the network switches. The controller is responsible for managing the flow tables within the switches, defining how traffic should be forwarded based on predefined rules and policies. This separation of control and data planes allows for dynamic network management and facilitates the implementation of innovative network protocols.

One of the key advantages of OpenFlow is its ability to simplify network management. By centralizing control, administrators can easily configure and manage the entire network from a single point of control. This reduces complexity and enhances the scalability of network infrastructure. Additionally, OpenFlow enables network programmability, allowing for the development of custom networking applications and services tailored to specific requirements.

OpenFlow plays a crucial role in network virtualization, as it allows for the creation and management of virtual networks on top of physical infrastructure. By abstracting the underlying network, OpenFlow empowers organizations to optimize resource utilization, improve security, and enhance network performance. It opens doors to dynamic provisioning, isolation, and efficient utilization of network resources.

Matt Conran

Highlights: What is OpenFlow?

How does OpenFlow work?

OpenFlow allows network controllers to determine the path of network packets in a network of switches. There is a difference between switches and controllers. With separate control and forwarding, traffic management can be more sophisticated than access control lists (ACLs) and routing protocols. An OpenFlow protocol allows switches from different vendors, often with proprietary interfaces and scripting languages, to be managed remotely. Software-defined networking (SDN) is considered to be enabled by OpenFlow by its inventors.

With OpenFlow, Layer 3 switches can add, modify, and remove packet-matching rules and actions remotely. By doing so, routing decisions can be made periodically or ad hoc by the controller and translated into rules and actions with a configurable lifespan, which are then deployed to the switch’s flow table, where packets are forwarded at wire speed for the duration of the rule. If the switch cannot match packets, they can be sent to the controller. The controller can modify existing flow table rules or deploy new rules to prevent a structural traffic flow. It may even forward the traffic itself if the switch is instructed to forward packets rather than just their headers.

OpenFlow uses Transport Layer Security (TLS) over Transmission Control Protocol (TCP). Switches wishing to connect should listen on TCP port 6653. In earlier versions of OpenFlow, port 6633 was unofficially used. The protocol is mainly used between switches and controllers.

Introducing SDN

Recent changes and requirements have driven networks and network services to become more flexible, virtualization-aware, and API-driven. One major trend affecting the future of networking is software-defined networking ( SDN ). The software-defined architecture aims to extract the entire network into a single switch.

Software-defined networking (SDN) is an evolving technology defined by the Open Networking Foundation ( ONF ). It involves the physical separation of the network control plane from the forwarding plane, where a control plane controls several devices. This differs significantly from traditional IP forwarding that you may have used in the past.

The activities around OpenFlow

Even though OpenFlow has received a lot of industry attention, programmable networks and decoupled control planes (control logic) from data planes have been around for many years. To enhance ATM, Internet, and mobile networks’ openness, extensibility, and programmability, the Open Signaling (OPENING) working group held workshops in 1995. A working group within the Internet Engineering Task Force (IETF) developed GSMP to control label switches based on these ideas. June 2002 marked the official end of this group, and GSMPv3 was published.

What is OpenFlow

Data and control plane

Therefore, SDN separates the data and control plane. The main driving body behind software-defined networking (SDN) is the Open Networking Foundation ( ONF ). Introduced in 2008, the ONF is a non-profit organization that wants to provide an alternative to proprietary solutions that limit flexibility and create vendor lock-in.

The insertion of the ONF allowed its members to run proof of concepts on heterogeneous networking devices without requiring vendors to expose their software’s internal code. This creates a path for an open-source approach to networking and policy-based controllers. 

Building blocks: SDN Environment 

As a fundamental building block of an SDN deployment, the controller, the SDN switch (for example, an OpenFlow switch), and the interfaces are present in the controller to communicate with forwarding devices, generally the southbound interface (OpenFlow) and the northbound interface (the network application interface). In an SDN, switches function as basic forwarding hardware, accessible via an open interface, with the control logic and algorithms offloaded to controllers. Hybrid (OpenFlow-enabled) and pure (OpenFlow-only) OpenFlow switches are available.

OpenFlow switches rely entirely on a controller for forwarding decisions, without legacy features or onboard control. Hybrid switches support OpenFlow as well, in addition to traditional operation and protocols. Today, hybrid switches are the most common type of commercial switch. A flow table performs packet lookup and forwarding in an OpenFlow switch.

You may find the following useful for pre-information:

  1. OpenFlow Protocol
  2. Network Traffic Engineering
  3. What is VXLAN
  4. SDN Adoption Report
  5. Virtual Device Context

What is OpenFlow?

What is OpenFlow?

OpenFlow was the first protocol of the Software-Defined Networking (SDN) trend and is the only protocol that allows the decoupling of a network device’s control plane from the data plane. In most straightforward terms, the control plane can be thought of as the brains of a network device. On the other hand, the data plane can be considered hardware or application-specific integrated circuits (ASICs) that perform packet forwarding.

Numerous devices also support running OpenFlow in a hybrid mode, meaning OpenFlow can be deployed on a given port, virtual local area network (VLAN), or even within a regular packet-forwarding pipeline such that if there is not a match in the OpenFlow table, then the existing forwarding tables (MAC, Routing, etc.) are used, making it more analogous to Policy Based Routing (PBR).

What is OpenFlow
Diagram: What is OpenFlow? The source is cable solutions.

What is SDN?

Despite various modifications to the underlying architecture and devices (such as switches, routers, and firewalls), traditional network technologies have existed since the inception of networking. Using a similar approach, frames and packets have been forwarded and routed in a limited manner, resulting in low efficiency and high maintenance costs. Consequently, the architecture and operation of networks need to evolve, resulting in SDN.

By enabling network programmability, SDN promises to simplify network control and management and allow innovation in computer networking. Network engineers configure policies to respond to various network events and application scenarios. They can achieve the desired results by manually converting high-level policies into low-level configuration commands.

Often, minimal tools are available to accomplish these very complex tasks. Controlling network performance and tuning network management are challenging and error-prone tasks.

A modern network architecture consists of a control plane, a data plane, and a management plane; the control and data planes are merged into a machine called Inside the Box. To overcome these limitations, programmable networks have emerged.

How OpenFlow Works:

At the core of OpenFlow is the concept of a flow table, which resides in each OpenFlow-enabled switch. The flow table contains match-action rules defining how incoming packets should be processed and forwarded. The centralized controller determines these rules and communicates using the OpenFlow protocol with the switches.

When a packet arrives at an OpenFlow-enabled switch, it is first matched against the rules in the flow table. If a match is found, the corresponding action is executed, including forwarding the packet, dropping it, or sending it to the controller for further processing. This decoupling of the control and data planes allows for flexible and programmable network management.

What is OpenFlow SDN?

The main goal of SDN is to separate the control and data planes and transfer network intelligence and state to the control plane. These concepts have been exploited by technologies like Routing Control Platform (RCP), Secure Architecture for Network Enterprise (SANE), and, more recently, Ethane.

In addition, there is often a connection between SDN and OpenFlow. The Open Networking Foundation (ONF) is responsible for advancing SDN and standardizing OpenFlow, whose latest version is 1.5.0.

  • An SDN deployment starts with these building blocks.

For communication with forwarding devices, the controller has the SDN switch (for example, an OpenFlow switch), the SDN controller, and the interfaces. An SDN deployment is based on two basic building blocks: a southbound interface (OpenFlow) and a northbound interface (the network application interface).

As the control logic and algorithms are offloaded to a controller, switches in SDNs may be represented as basic forwarding hardware. Switches that support OpenFlow come in two varieties: pure (OpenFlow-only) and hybrid (OpenFlow-enabled).

Pure OpenFlow switches do not have legacy features or onboard control for forwarding decisions. A hybrid switch can operate with both traditional protocols and OpenFlow. Hybrid switches make up the majority of commercial switches available today. In an OpenFlow switch, a flow table performs packet lookup and forwarding.

OpenFlow reference switch

The OpenFlow protocol and interface allow OpenFlow switches to be accessed as essential forwarding elements. A flow-based SDN architecture like OpenFlow simplifies switching hardware. Still, it may require additional forwarding tables, buffer space, and statistical counters that are difficult to implement in traditional switches with integrated circuits tailored to specific applications.

There are two types of switches in an OpenFlow network: hybrids (which enable OpenFlow) and pores (which only support OpenFlow). OpenFlow is supported by hybrid switches and traditional protocols (L2/L3). OpenFlow switches rely entirely on a controller for forwarding decisions and do not have legacy features or onboard control.

Hybrid switches are the majority of the switches currently available on the market. This link must remain active and secure because OpenFlow switches are controlled over an open interface (through a TCP-based TLS session). OpenFlow is a messaging protocol that defines communication between OpenFlow switches and controllers, which can be viewed as an implementation of SDN-based controller-switch interactions.

Openflow switch
Diagram: OpenFlow switch. The source is cable solution.

Identify the Benefits of OpenFlow

Application-driven routing. Users can control the network paths.

The networks paths.A way to enhance link utilization.

An open solution for VM mobility. No VLAN reliability.

A means to traffic engineer without MPLS.

A solution to build very large Layer 2 networks.

A way to scale Firewalls and Load Balancers.

A way to configure an entire network as a whole as opposed to individual entities.

A way to build your own encryption solution. Off-the-box encryption.

A way to distribute policies from a central controller.

Customized flow forwarding. Based on a variety of bit patterns.

A solution to get a global view of the network and its state. End-to-end visibility.

A solution to use commodity switches in the network. Massive cost savings.

The following table lists the Software Networking ( SDN ) benefits and the problems encountered with existing control plane architecture:

Identify the benefits of OpenFlow and SDN

Problems with the existing approach

Faster software deployment.

Large scale provisioning and orchestration.

Programmable network elements.

Limited traffic engineering ( MPLS TE is cumbersome )

Faster provisioning.

Synchronized distribution policies.

Centralized intelligence with centralized controllers.

Routing of large elephant flows.

Decisions are based on end-to-end visibility.

Qos and load based forwarding models.

Granular control of flows.

Ability to scale with VLANs.

Decreases the dependence on network appliances like load balancers.

  • A key point: The lack of a session layer in the TCP/IP stack.

Regardless of the hype and benefits of SDN, neither OpenFlow nor other SDN technologies address the real problems of the lack of a session layer in the TCP/IP protocol stack. The problem is that the client’s application ( Layer 7 ) connects to the server’s IP address ( Layer 3 ), and if you want to have persistent sessions, the server’s IP address must remain reachable. 

This session’s persistence and the ability to connect to multiple Layer 3 addresses to reach the same device is the job of the OSI session layer. The session layer provides the services for opening, closing, and managing a session between end-user applications. In addition, it allows information from different sources to be correctly combined and synchronized.

The problem is the TCP/IP reference module does not consider a session layer, and there is none in the TCP/IP protocol stack. SDN does not solve this; it gives you different tools to implement today’s kludges.

what is openflow
What is OpenFlow? Lack of a session layer

Control and data plane

When we identify the benefits of OpenFlow, let us first examine traditional networking operations. Traditional networking devices have a control and forwarding plane, depicted in the diagram below. The control plane is responsible for setting up the necessary protocols and controls so the data plane can forward packets, resulting in end-to-end connectivity. These roles are shared on a single device, and the fast packet forwarding ( data path ) and the high-level routing decisions ( control path ) occur on the same device.

What is OpenFlow | SDN separates the data and control plane

Control plane

The control plane is part of the router architecture and is responsible for drawing the network map in routing. When we mention control planes, you usually think about routing protocols, such as OSPF or BGP. But in reality, the control plane protocols perform numerous other functions, including:

Connectivity management ( BFD, CFM )

Interface state management ( PPP, LACP )

Service provisioning ( RSVP for InServ or MPLS TE)

Topology and reachability information exchange ( IP routing protocols, IS-IS in TRILL/SPB )

Adjacent device discovery via HELLO mechanism

ICMP

Control plane protocols run over data plane interfaces to ensure “shared fate” – if the packet forwarding fails, the control plane protocol fails as well.

Most control plane protocols ( BGP, OSPF, BFD ) are not data-driven. A BGP or BFD packet is never sent as a direct response to a data packet. There is a question mark over the validity of ICMP as a control plane protocol. The debate is whether it should be classed in the control or data plane category.

Some ICMP packets are sent as replies to other ICMP packets, and others are triggered by data plane packets, i.e., data-driven. My view is that ICMP is a control plane protocol that is triggered by data plane activity. After all, the “C” is ICMP does stand for “Control.”

Data plane

The data path is part of the routing architecture that decides what to do when a packet is received on its inbound interface. It is primarily focused on forwarding packets but also includes the following functions:

ACL logging

 Netflow accounting

NAT session creation

NAT table maintenance

The data forwarding is usually performed in dedicated hardware, while the additional functions ( ACL logging, Netflow accounting ) typically happen on the device CPU, commonly known as “punting.” The data plane for an OpenFlow-enabled network can take a few forms.

However, the most common, even in the commercial offering, is the Open vSwitch, often called the OVS. The Open vSwitch is an open-source implementation of a distributed virtual multilayer switch. It enables a switching stack for virtualization environments while supporting multiple protocols and standards.

Software-defined networking changes the control and data plane architecture.

The concept of SDN separates these two planes, i.e., the control and forwarding planes are decoupled. This allows the networking devices in the forwarding path to focus solely on packet forwarding. An out-of-band network uses a separate controller ( orchestration system ) to set up the policies and controls. Hence, the forwarding plane has the correct information to forward packets efficiently.

In addition, it allows the network control plane to be moved to a centralized controller on a server instead of residing on the same box carrying out the forwarding. Moving the intelligence ( control plane ) of the data plane network devices to a controller enables companies to use low-cost, commodity hardware in the forwarding path. A significant benefit is that SDN separates the data and control plane, enabling new use cases.

A centralized computation and management plane makes more sense than a centralized control plane.

The controller maintains a view of the entire network and communicates with Openflow ( or, in some cases, BGP with BGP SDN ) with the different types of OpenFlow-enabled network boxes. The data path portion remains on the switch, such as the OVS bridge, while the high-level decisions are moved to a separate controller. The data path presents a clean flow table abstraction, and each flow table entry contains a set of packet fields to match, resulting in specific actions ( drop, redirect, send-out-port ).

When an OpenFlow switch receives a packet it has never seen before and doesn’t have a matching flow entry, it sends the packet to the controller for processing. The controller then decides what to do with the packet.

Applications could then be developed on top of this controller, performing security scrubbing, load balancing, traffic engineering, or customized packet forwarding. The centralized view of the network simplifies problems that were harder to overcome with traditional control plane protocols.

A single controller could potentially manage all OpenFlow-enabled switches. Instead of individually configuring each switch, the controller can push down policies to multiple switches simultaneously—a compelling example of many-to-one virtualization.

Now that SDN separates the data and control plane, the operator uses the centralized controller to choose the correct forwarding information per-flow basis. This allows better load balancing and traffic separation on the data plane. In addition, there is no need to enforce traffic separation based on VLANs, as the controller would have a set of policies and rules that would only allow traffic from one “VLAN” to be forwarded to other devices within that same “VLAN.”

The advent of VXLAN

With the advent of VXLAN, which allows up to 16 million logical entities, the benefits of SDN should not be purely associated with overcoming VLAN scaling issues. VXLAN already does an excellent job with this. It does make sense to deploy a centralized control plane in smaller independent islands; in my view, it should be at the edge of the network for security and policy enforcement roles. Using Openflow on one or more remote devices is easy to implement and scale.

It also decreases the impact of controller failure. If a controller fails and its sole job is implementing packet filters when a new user connects to the network, the only affecting element is that the new user cannot connect. If the controller is responsible for core changes, you may have interesting results with a failure. New users not being able to connect is bad, but losing your entire fabric is not as bad.

Spanning tree VXLAN
Diagram: Loop prevention. Source is Cisco

A traditional networking device runs all the control and data plane functions. The control plane, usually implemented in the central CPU or the supervisor module, downloads the forwarding instructions into the data plane structures. Every vendor needs communications protocols to bind the two planes together to download forward instructions. 

Therefore, all distributed architects need a protocol between control and data plane elements. The protocol binding this communication path for traditional vendor devices is not open-source, and every vendor uses its proprietary protocol (Cisco uses IPC—InterProcess Communication ).

Openflow tries to define a standard protocol between the control plane and the associated data plane. When you think of Openflow, you should relate it to the communication protocol between the traditional supervisors and the line cards. OpenFlow is just a low-level tool.

OpenFlow is a control plane ( controller ) to data plane ( OpenFlow enabled device ) protocol that allows the control plane to modify forwarding entries in the data plane. It enables SDN to separate the data and control planes.

identify the benefits of openflow

Proactive versus reactive flow setup

OpenFlow operations have two types of flow setups: Proactive and Reactive.

With Proactive, the controller can populate the flow tables ahead of time, similar to a typical routing. However, the packet-in event never occurs by pre-defining your flows and actions ahead of time in the switch’s flow tables. The result is all packets are forwarded at line rate. With Reactive, the network devices react to traffic, consult the OpenFlow controller, and create a rule in the flow table based on the instruction. The problem with this approach is that there can be many CPU hits.

OpenFlow protocol

The following table outlines the critical points for each type of flow setup:

Proactive flow setup

Reactive flow setup

Works well when the controller is emulating BGP or OSPF.

 Used when no one can predict when and where a new MAC address will appear.

The controller must first discover the entire topology.

 Punts unknown packets to the controller. Many CPU hits.

Discover endpoints ( MAC addresses, IP addresses, and IP subnets )

Compute forwarding paths on demand. Not off the box computation.

Compute off the box optimal forwarding.

 Install flow entries based on actual traffic.

Download flow entries to the data plane switches.

Has many scalability concerns such as packet punting rate.

No data plane controller involvement with the exceptions of ARP and MAC learning. Line-rate performance.

 Not a recommended setup.

Hop-by-hop versus path-based forwarding

The following table illustrates the key points for the two types of forwarding methods used by OpenFlow: hop-by-hop forwarding and path-based forwarding:

Hop-by-hop Forwarding

 Path-based Forwarding

Similar to traditional IP Forwarding.

Similar to MPLS.

Installs identical flows on each switch on the data path.

Map flows to paths on ingress switches and assigns user traffic to paths at the edge node

Scalability concerns relating to flow updates after a change in topology.

Compute paths across the network and installs end-to-end path-forwarding entries.

Significant overhead in large-scale networks.

Works better than hop-by-hop forwarding in large-scale networks.

FIB update challenges. Convergence time.

Core switches don’t have to support the same granular functionality as edge switches.

Obviously, with any controller, the controller is a lucrative target for attack. Anyone who knows you are using a controller-based network will try to attack the controller and its control plane. The attacker may attempt to intercept the controller-to-switch communication and replace it with its commands, essentially attacking the control plane with whatever means they like.

An attacker may also try to insert a malformed packet or some other type of unknown packet into the controller ( fuzzing attack ), exploiting bugs in the controller and causing the controller to crash. 

Fuzzing attacks can be carried out with application scanning software such as Burp Suite. It attempts to manipulate data in a particular way, breaking the application.

The best way to tighten security is to encrypt switch-to-controller communications with SSL and self-signed certificates to authenticate the switch and controller. It would also be best to minimize interaction with the data plane, except for ARP and MAC learning.

To prevent denial-of-service attacks on the controller, you can use Control Plane Policing ( CoPP ) on Ingress to avoid overloading the switch and the controller. Currently, NEC is the only vendor implementing CoPP.

sdn separates the data and control plane

The Hybrid deployment model is helpful from a security perspective. For example, you can group specific ports or VLANs to OpenFlow and other ports or VLANs to traditional forwarding, then use traditional forwarding to communicate with the OpenFlow controller.

Software-defined networking or traditional routing protocols?

The move to a Software-Defined Networking architecture has clear advantages. It’s agile and can react quickly to business needs, such as new product development. For businesses to succeed, they must have software that continues evolving.

Otherwise, your customers and staff may lose interest in your product and service. The following table displays the advantages and disadvantages of the existing routing protocol control architecture.

+Reliable and well known.

-Non-standard Forwarding models. Destination-only and not load-aware metrics**

+Proven with 20 plus years field experience.

 -Loosely coupled.

+Deterministic and predictable.

-Lacks end-to-end transactional consistency and visibility.

+Self-Healing. Traffic can reroute around a failed node or link.

-Limited Topology discovery and extraction. Basic neighbor and topology tables.

+Autonomous.

-Lacks the ability to change existing control plane protocol behavior.

+Scalable.

-Lacks the ability to introduce new control plane protocols.

+Plenty of learning and reading materials.

** Basic EIGRP IETF originally proposed an Energy-Aware Control Plane, but the IETF later removed this.

Software-Defined Networking: Use Cases

Edge Security policy enforcement at the network edge.

Authenticate users or VMs and deploy per-user ACL before connecting a user to the network.

Custom routing and online TE.

The ability to route on a variety of business metrics aka routing for dollars. Allowing you to override the default routing behavior.

Custom traffic processing.

For analytics and encryption.

Programmable SPAN ports

 Use Openflow entries to mirror selected traffic to the SPAN port.

DoS traffic blackholing & distributed DoS prevention.

Block DoS traffic as close to the source as possible with more selective traffic targeting than the original RTBH approach**. The traffic blocking is implemented in OpenFlow switches. Higher performance with significantly lower costs.

Traffic redirection and service insertion.

Redirect a subset of traffic to network appliances and install redirection flow entries wherever needed.

Network Monitoring.

 The controller is the authoritative source of information on network topology and Forwarding paths.

Scale-Out Load Balancing.

Punt new flows to the Openflow controller and install per-session entries throughout the network.

IPS Scale-Out.

OpenFlow is used to distribute the load to multiple IDS appliances.

**Remote-Triggered Black Hole: RTBH refers to installing a host route to a bogus IP address ( RTBH address ) pointing to NULL interfaces on all routers. BGP is used to advertise the host routes to other BGP peers of the attacked hosts, with the next hop pointing to the RTBH address, and it is mainly automated in ISP environments.

SDN deployment models

Guidelines:

  1. Start with small deployments away from the mission-critical production path, i.e., the Core. Ideally, start with device or service provisioning systems.
  2. Start at the Edge and slowly integrate with the Core. Minimize the risk and blast radius. Start with packet filters at the Edge and tasks that can be easily automated ( VLANs ).
  3. Integrate new technology with the existing network.
  4. Gradually increase scale and gain trust. Experience is key.
  5. Have the controller in a protected out-of-band network with SSL connectivity to the switches.

There are 4 different models for OpenFlow deployment, and the following sections list the key points of each model.

Native OpenFlow 

  • They are commonly used for Greenfield deployments.
  • The controller performs all the intelligent functions.
  • The forwarding plane switches have little intelligence and solely perform packet forwarding.
  • The white box switches need IP connectivity to the controller for the OpenFlow control sessions. If you are forced to use an in-band network for this communication path using an isolated VLAN with STP, you should use an out-of-band network.
  • Fast convergence techniques such as BFD may be challenging to use with a central controller.
  • Many people believe that this approach does not work for a regular company. Companies implementing native OpenFlow, such as Google, have the time and resources to reinvent the wheel when implementing a new control-plane protocol ( OpenFlow ).

Native OpenFlow with Extensions

  • Some control plane functions are handled from the centralized controller to the forwarding plane switches. For example, the OpenFlow-enabled switches could load balancing across multiple links without the controller’s previous decision. You could also run STP, LACP, or ARP locally on the switch without interaction with the controller. This approach is helpful if you lose connectivity to the controller. If the low-level switches perform certain controller functions, packet forwarding will continue in the event of failure.
  • The local switches should support the specific OpenFlow extensions that let them perform functions on the controller’s behalf.

Hybrid ( Ships in the night )

  • This approach is used where OpenFlow runs in parallel with the production network.
  • The same network box is controlled by existing on-box and off-box control planes ( OpenFlow).
  • Suitable for pilot deployment models as switches still run traditional control plane protocols.
  • The Openflow controller manages only specific VLANs or ports on the network.
  • The big challenge is determining and investigating the conflict-free sharing of forwarding plane resources across multiple control planes.

Integrated OpenFlow

  • OpenFlow classifiers and forwarding entries are integrated with the existing control plane. For example, Juniper’s OpenFlow model follows this mode of operation where OpenFlow static routes can be redistributed into the other routing protocols.
  • No need for a new control plane.
  • No need to replace all forwarding hardware
  • It is the most practical approach as long as the vendor supports it.

Closing Points on OpenFlow

Advantages of OpenFlow:

OpenFlow brings several critical advantages to network management and control:

1. Flexibility and Programmability: With OpenFlow, network administrators can dynamically reconfigure the behavior of network devices, allowing for greater adaptability to changing network requirements.

2. Centralized Control: By centralizing control in a single controller, network administrators gain a holistic view of the network, simplifying management and troubleshooting processes.

3. Innovation and Experimentation: OpenFlow enables researchers and developers to experiment with new network protocols and applications, fostering innovation in the networking industry.

4. Scalability: OpenFlow’s centralized control architecture provides the scalability needed to manage large-scale networks efficiently.

Implications for Network Control:

OpenFlow has significant implications for network control, paving the way for new possibilities in network management:

1. Software-Defined Networking (SDN): OpenFlow is a critical component of the broader concept of SDN, which aims to decouple network control from the underlying hardware, providing a more flexible and programmable infrastructure.

2. Network Virtualization: OpenFlow facilitates network virtualization, allowing multiple virtual networks to coexist on a single physical infrastructure.

3. Traffic Engineering: By controlling the flow of packets at a granular level, OpenFlow enables advanced traffic engineering techniques, optimizing network performance and resource utilization.

Conclusion:

OpenFlow represents a paradigm shift in network control, offering a more flexible, scalable, and programmable approach to managing networks. By separating the control and data planes, OpenFlow empowers network administrators to have fine-grained control over network behavior, improving efficiency, innovation, and adaptability. As the networking industry continues to evolve, OpenFlow and its related technologies will undoubtedly play a crucial role in shaping the future of network management.

Summary: What is OpenFlow?

In the rapidly evolving world of networking, OpenFlow has emerged as a game-changer. This revolutionary technology has transformed the way networks are managed, offering unprecedented flexibility, control, and efficiency. In this blog post, we will delve into the depths of OpenFlow, exploring its definition, key features, and benefits.

What is OpenFlow?

OpenFlow can be best described as an open standard communications protocol that enables the separation of the control plane and the data plane in network devices. It allows centralized control over a network’s forwarding elements, making it possible to program and manage network traffic dynamically. By decoupling the intelligence of the network from the underlying hardware, OpenFlow provides a flexible and programmable infrastructure for network administrators.

Key Features of OpenFlow

a) Centralized Control: One of the core features of OpenFlow is its ability to centralize network control, allowing administrators to define and implement policies from a single point of control. This centralized control improves network visibility and simplifies management tasks.

b) Programmability: OpenFlow’s programmability empowers network administrators to define how network traffic should be handled based on their specific requirements. Through the use of flow tables and match-action rules, administrators can dynamically control the behavior of network switches and routers.

c) Software-Defined Networking (SDN) Integration: OpenFlow plays a crucial role in the broader concept of Software-Defined Networking. It provides a standardized interface for SDN controllers to communicate with network devices, enabling dynamic and automated network provisioning.

Benefits of OpenFlow

a) Enhanced Network Flexibility: With OpenFlow, network administrators can easily adapt and customize their networks to suit evolving business needs. The ability to modify network behavior on the fly allows for efficient resource allocation and improved network performance.

b) Simplified Network Management: By centralizing network control, OpenFlow simplifies the management of complex network architectures. Policies and configurations can be applied uniformly across the network, reducing administrative overhead and minimizing the chances of configuration errors.

c) Innovation and Experimentation: OpenFlow fosters innovation by providing a platform for the development and deployment of new network protocols and applications. Researchers and developers can experiment with novel networking concepts, paving the way for future advancements in the field.

Conclusion:

OpenFlow has ushered in a new era of network management, offering unparalleled flexibility and control. Its ability to separate the control plane from the data plane, coupled with centralized control and programmability, has opened up endless possibilities in network architecture design. As organizations strive for more agile and efficient networks, embracing OpenFlow and its associated technologies will undoubtedly be a wise choice.