data center design

Open Networking

Open Networking

In today's digital age, connectivity is at the forefront of our lives. From smart homes to autonomous vehicles, the demand for seamless and reliable network connectivity continues to grow. This is where Open Networking comes into play. In this blog post, we will explore the concept of Open Networking, its benefits, and its impact on the future of technology.

Open Networking refers to separating hardware and software components of a network infrastructure. Traditionally, network equipment vendors provided closed, proprietary systems that limited flexibility and innovation.

However, with Open Networking, organizations can choose the hardware and software components that best suit their needs, fostering greater interoperability and driving innovation.

Table of Contents

Highlights: Open Networking

The Role of Transformation

To undertake an effective SDN data center transformation strategy, we must accept that demands on data center networks come from internal end-users, external customers, and considerable changes in the application architecture. All of which put pressure on traditional data center architecture.

Dealing effectively with these demands requires the network domain to become more dynamic, potentially introducing Open Networking and Open Networking solutions. We must embrace digital transformation and the changes it will bring to our infrastructure for this to occur. Unfortunately, keeping current methods is holding back this transition.

Modern Network Infrastructure

In modern network infrastructures, as has been the case on the server side for many years, customers demand supply chain diversification regarding hardware and silicon vendors. This diversification reduces the Total Cost of Ownership because businesses can drive better cost savings. In addition, replacing the hardware underneath can be seamless because the software above is standard across both vendors.

Further, as architectures streamline and spine leaf architecture increases from the data center to the backbone and the Edge, a typical software architecture across all these environments brings operational simplicity. This perfectly aligns with the broader trend of IT/OT convergence.  

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

  1. OpenFlow Protocol
  2. Software-defined Perimeter Solutions
  3. Network Configuration Automation
  4. SASE Definition
  5. Network Overlays
  6. Overlay Virtual Networking



Open Networking Solutions

Key Open Networking Discussion points:


  • Popularity of Spine Leaf architecture.

  • Lack of fabric-wide automation.

  • Automation and configuration management.

  • Open networking vs open protocols.

  • Challenges with integrated vendors.

Back to Basics: Open Networking

SDN and an SDN Controller

SDN’s three concepts are:

  • Programmability.
  • The separation of the control and data planes.
  • Managing a temporary network state in a centralized control model, regardless of the degree of centralization.

So, we have an SDN controller. In theory, an SDN controller provides services that can realize a distributed control plane and abet temporary state management and centralization concepts. 

open networking
Diagram: Open Networking for a data center topology.

The Role of Zero Trust

Zero Trust Security Strategy

Zero Trust Security Main Components

  • Zero trust security is a paradigm shift in the way organizations approach their cybersecurity.

  • Every user, device, or application, regardless of its location, must undergo strict verification and authorization processes.

  • Organizations can fortify their defenses, protect sensitive data, and mitigate the risks associated with modern cyber threats.

♦ Benefits of Open Networking:

1. Flexibility and Customization: Open Networking enables organizations to tailor their network infrastructure to their specific requirements. By decoupling hardware and software, businesses can choose the best-of-breed components and optimize their network for performance, scalability, and cost-effectiveness.

2. Interoperability: Open Networking promotes interoperability by fostering open standards and compatibility between different vendors’ equipment. This allows organizations to build multi-vendor networks, reducing vendor lock-in and enabling seamless integration of network components.

3. Cost Savings: With Open Networking, organizations can lower their networking costs by leveraging commodity hardware and open-source software. This reduces capital expenditures and allows for more efficient network management and more effortless scalability.

4. Innovation and Collaboration: Open Networking encourages collaboration and innovation by providing a platform for developers to create and contribute to open-source networking projects. The community’s collective effort drives continuous improvements, leading to faster adoption of new technologies and features.

Open Networking in Practice:

Open Networking is already making its mark across various industries. Cloud service providers, for example, rely heavily on Open Networking principles to build scalable and flexible data center networks. Telecom operators also embrace Open Networking to deploy virtualized network functions, enabling them to offer services more efficiently and adapt to changing customer demands.

Moreover, adopting Software-Defined Networking (SDN) and Network Functions Virtualization (NFV) further accelerates the realization of Open Networking’s benefits. SDN separates the control plane from the data plane, providing centralized network management and programmability. NFV virtualizes network functions, allowing for dynamic provisioning and scalability.

Open Networking in Practice

Cloud service providers

Virtualized Network Function

Virtual Private Networks

Software-Defined Networking (SDN

Network Function Virtualization

Dynamic Provisioning and Scalability

Open-source network operating systems (NOS)

Leveraging White-box Switches

Reducing Vendor Lock-in

Freedom to choose best-of-breed components

Intent-based Networking

Network Virtualization

 

Open Networking Solutions

Open networking solutions: Data center topology

Now, let’s look at the evolution of data centers to see how we can achieve this modern infrastructure. So, to evolve and to be in line with current times, you should use technology and your infrastructure as practical tools. You will be able to drive the entire organization to become digital.

Of course, the network components will play a key role. Still, the digital transformation process is an enterprise-wide initiative focusing on fabric-wide automation and software-defined networking.

Open networking solutions: Lacking fabric-wide automation

One central pain point I have seen throughout networking is the necessity to dispense with manual work lacking fabric-wide automation. In addition, it’s common to deploy applications by combining multiple services that run on a distributed set of resources. As a result, configuration and maintenance are much more complex than in the past. You have two options to implement all of this.

First, you can connect up these services by, for example, manually spinning up the servers, installing the necessary packages, SSHing to each one, or you can go down the path of open network solutions with automation, in particular, Ansible automation with Ansible Engine or Ansible Tower with automation mesh. As automation best practice, use Ansible variables for flexible playbook creation that can be easily shared and used amongst different environments.  

Agility and the service provider

For example, in the case of a service provider that has thousands of customers, it needs to deploy segmentation to separate different customers. Traditionally, the technology of choice would be VRFs or even full-blown MPLS, which requires administrative touchpoints for every box.

As I was part of a full-blown MPLS design and deployment for a more significant service provider, the costs and time were extreme. Even when it is finally done, the design lacks agility compared to what you could have done with Open Networking.

This would include Provider Edge (PE) Edge routers at the Edge, to which the customer CPE would connect. And then, in the middle of the network, we would have what is known as P ( Provider ) routers that switch the traffic based on a label.

Although the benefits of label switching were easy to implement IPv6 with 6PE ( 6PE is a technique that provides global IPv6 reachability over IPv4 MPLS ) that overcomes many IPv6 fragmentation issues, we could not get away from the manual process without investing heavily again. It is commonly a manual process.

Fabric-wide automation and SDN

However, deploying a VRF or any technology, such as an anycast gateway, is a dynamic global command in a software-defined environment. We now have fabric-wide automation and can deploy with one touch instead of numerous box-by-box configurations.

Essentially, we are moving from a box-by-box configuration to the atomic programming of a distributing fabric of a single entity. The beauty is that we can carry out deployments with one configuration point quickly and without human error.

fabric wide automation
Diagram: Fabric wide automation.

Open networking solutions: Configuration management

Manipulating configuration files by hand is a tedious and error-prone task. Not to mention time-consuming. Equally, performing pattern matching to make changes to existing files is risky. The manual approach will result in configuration drift, where some servers will drift from the desired state.

Configuration drift is caused by inconsistent configuration items across devices, usually due to manual changes and updates and not following the automation path. Ansible architecture can maintain the desired state across various managed assets.

The managed assets that can range from distributed firewalls to Linux hosts are stored in what’s known as an inventory file, which can be static or dynamic inventory. Dynamic inventories are best suited for a cloud environment where you want to gather host information dynamically. Ansible is all about maintaining the desired state for your domain.

ansible automation
Diagram: Ansible automation.

The issue of Silos

To date, the networking industry has been controlled by a few vendors. We have dealt with proprietary silos in the data center, campus/enterprise, and service provider environments. The major vendors will continue to provide a vertically integrated lock-in solution for most customers. They will not allow independent, 3rd party network operating system software to run on their silicon.

Typically, these silos were able to solve the problems of the time. The modern infrastructure needs to be modular, open, and straightforward. Vendors need to allow independent, 3rd party network operating systems to run on their silicon to break from being a vertically integrated lock-in solution.

Cisco has started this for the broader industry regarding open networking solutions with the announcement of the Cisco Silicon ONE. 

network overlay
Diagram: The issue of vendor lock-in.

The Rise of Open Networking Solutions

New data center requirements have emerged; therefore, the network infrastructure must break the silos and transform to meet these trending requirements. One can view the network transformation as moving from a static and conservative mindset that results in cost overrun and inefficiencies to a dynamic routed environment that is simple, scalable, secure, and can reach the far edge. For effective network transformation, we need several stages. 

Firstly, transition to a routed data center design with a streamlined leaf-spine architecture. Along with a standard operating system across cloud, Edge, and 5G networks. A viable approach would be for all of this to be done with open standards, without proprietary mechanisms. Then, we need good visibility.

The need for visibility

As part of the transformation, the network is no longer considered a black box that needs to be available and provide connectivity to services. Instead, the network is a source of deep visibility that can aid a large set of use cases: network performance, monitoring, security, and capacity planning, to name a few. However, visibility is often overlooked with an over-focus on connectivity and not looking at the network as a valuable source of information.

Network management
Diagram: The requirement for deep visibility.

Monitoring a network: Flow level

For efficient network management, we must provide deep visibility for the application at a flow level on any port and device type. Today, you would deploy a redundant monitoring network if you want anything comparable. Such a network would consist of probes, packet brokers, and tools to process the packet for metadata.

The traditional network monitoring tools, such as packet brokers, require life cycle management. A more viable solution would integrate network visibility into the fabric and would not need many components. This enables us to do more with the data and aids with agility for ongoing network operations.

There will always be some requirement for application optimization or a security breach, where visibility can help you quickly resolve these issues.

Monitoring is used to detect known problems and is only valid with pre-defined dashboards with a problem you have seen before, such as capacity reaching its limit. On the other hand, we have the practices of Observability that can detect unknown situations and is used to aid those in getting to the root cause of any problem, known or unknown: Observability vs Monitoring

Evolution of the Data Center

We are transitioning, and the data center has undergone several design phases. Initially, we started with layer 2 silos, suitable for the north-to-south traffic flows. However, layer 2 designs hindered east-west communication traffic flows of modern applications and restricted agility, which led to a push to break network boundaries.

Hence, there is a move to routing at the Top of the Rack (ToR) with overlays between ToR to drive inter-application communication. This is the most efficient approach, which can be accomplished in several ways. 

The leaf spine “clos” popularity

The demand for leaf and spine “clos” started in the data center and spread to other environments. A clos network is a type of non-blocking, multistage switching architecture. This network design extends from the central/backend data center to the micro data centers at the EdgeEdge. Various parts of the edge network, PoPs, central offices, and packet core have all been transformed into leaf and spine “clos” designs. 

leaf spine
Diagram: Leaf Spine.

The network overlay

Building a complete network overlay is common to all software-defined technologies when increasing agility. An overlay is a solution that is abstracted from the underlying physical infrastructure. This means separating and disaggregating the customer applications or services from the network infrastructure. Think of it as a sandbox or private network for each application that is on an existing network.

More often, the network overlay will be created with VXLAN. The Cisco ACI uses an ACI network of VXLAN for the overlay, and the underlay is a combination of BGP and IS-IS. The overlay abstracts a lot of complexity, and Layer 2 and 3 traffic separation is done with a VXLAN network identifier (VNI).

The VXLAN overlay

VXLAN uses a 24-bit network segment ID, called a VXLAN network identifier (VNI), for identification. This is much larger than the 12 bits used for traditional VLAN identification. The VNI is just a fancy name for a VLAN ID, but it now supports up to 16 Million VXLAN segments. 

This is considerably more than the traditional 4094 supported endpoints with VLANs. Not only does this provide more hosts, but it enables better network isolation capabilities, having many little VXLAN segments instead of one large VLAN domain.

The VXLAN network has become the de facto overlay protocol and brings many advantages to network architecture regarding flexibility, isolation, and scalability. VXLAN effectively implements an Ethernet segment virtualizing a thick Ethernet cable.

VXLAN unicast mode

Traditional policy deployment

Traditionally, deploying an application to the network involves propagating the policy to work through the entire infrastructure. Why? Because the network acts as an underlay, segmentation rules configured on the underlay are needed to separate different applications and services.

This creates a rigid architecture that cannot react quickly and adapt to changes, therefore lacking agility. The applications and the physical network are tightly coupled. Now, we can have a policy in the overlay network with proper segmentation per customer.

How VXLAN works: ToR

What is VXLAN? Virtual networks and those built with VXLAN are built from servers or ToR switches. Either way, the underlying network transports the traffic and doesn’t need to be configured to accommodate the customer application. That’s all done in the overlay, including the policy. Everything happens in the overlay network, which is most efficient when done in a fully distributed manner.

Overlay networking
Diagram: Overlay Networking with VXLAN

Now, application and service deployment occurs without touching the physical infrastructure. For example, if you need to have Layer 2 or Layer 3 paths across the data center network, you don’t need to tweak a VLAN or change routing protocols.

Instead, you add a VXLAN overlay network. This approach removes the tight coupling between the application and network, creating increased agility and simplicity in deploying applications and services.

the network overlay
Diagram: The VXLAN overlay network.

Extending from the data center

Edge computing creates a fundamental disruption among the business infrastructure teams. We no longer have the framework where IT only looks at the backend software, such as Office365, and OT looks at the routing and switching product-centric elements. There is convergence.

Therefore, you need a lot of open APIs. The edge computing paradigm brings processing closer to the end devices. This reduces the latency and improves the end-user experience. It would help if you had a network that could work with this model to support this. Having different siloed solutions does not work. 

Common software architecture

So the data center design went from the layer 2 silo to the leaf and spine architecture with routing to the ToR. However, there is another missing piece. We need a standard operating software architecture across all the domains and location types for switching and routing to reduce operating costs. The problem remains that even on one site, there can be several different operating systems.

Through recent consultancy engagements, I have experienced the operational challenge of having many Cisco operating systems on one site. For example, I had an IOS XR for service provider product lines, IOS XE for enterprise, and NS OX for the data center, all on a single site.

Open networking solutions and partially open-source 

Some major players, such as Juniper, started with one operating system and then fragmented significantly. It’s not that these are not great operating systems. Instead, it would be best if you partitioned into different teams, often a team for each operating system.

Standard operating system software provides a seamless experience across the entire environment. Therefore, your operational costs go down, your ability to use software for the specific use cases you want goes up, and you can reduce the cost of ownership. In addition, this brings Open Networking and partially open source.

What Is Open Networking

The traditional integrated vendor

Traditionally, networking products were a combination of hardware and software that had to be purchased as an integrated solution. Open networking, on the other hand, disaggregates hardware from software. They were allowing IT to mix and match at will.

With Open Networking, we are not reinventing how packets are forwarded or routers communicate. With Open Networking solutions, you are never alone and never the only vendor. The value of software-defined networking and Open Networking is doing as much as possible in software so you don’t depend on delivering new features from a new generation of hardware. If you want a new part, it’s quickly implemented in software without swapping the hardware or upgrading line cards.

Move intelligence to software.

You want to move as much intelligence as possible into software, thus removing the intelligence from the physical layer. You don’t want to build in hardware features; you want to use the software to provide the new features. This is a critical philosophy and is the essence of Open Networking. Software becomes the central point of intelligence, not the hardware; this intelligence is delivered fabric-wide.

As we have seen with the rise of SASE. From the customer’s point of view, they get more agility as they can move from generation to generation of services without having hardware dependency and don’t have the operational costs of constantly swapping out the hardware.

SDN network

Open Networking Solutions and Open Networking Protocols

Some vendors build into the hardware the differentiator of the offering. For example, with different hardware, you can accelerate the services. With this design, the hardware level is manipulated to make improvements but does not use standard Open Networking protocols. 

When you look at your hardware to accelerate your services, the result is that you are 100% locked and unable to move as the cost of moving is too much. You could have numerous generations of, for example, line cards, and all have different capabilities, resulting in a complex feature matrix.

It is not that I’m against this, and I’m a big fan of the prominent vendors, but this is the world of closed networking, which has been accepted as the norm until recently. So you must adapt and fit; we need to use open protocols.

Open networking is a must; open source is not.

The proprietary silo deployments led to proprietary alternatives to the prominent vendors. This meant that the startups and options offered around ten years ago were playing the game on the same pitch as the incumbents. Others built their software and architecture by, for example, saying the Linux network subsystem and the OVS bridge are good enough to solve all data center problems.

With this design, you could build small PoPs with layer 2. But the ground shifts as the design requirements change to routing. So, let’s glue the Linux kernel and Quagga FRRouting (FRR) and devise a routing solution. Unfortunately, many didn’t consider the control plane architecture or the need for multiple data center use cases.

Limited scale

Gluing the operating system and elements of open-source routing provides a limited scale and performance and results in operationally intensive and expensive solutions. The software is built to support the hardware and architectural demands.

Now, we see a lot of open-source networking vendors tackling this problem from the wrong architectural point of view, at least from where the market is moving to. It is not composable, microservices-based, or scalable from an operational viewpoint.

There is a difference between open source and Open Networking. The open-source offerings (especially the control plane) have not scaled because of sub-optimal architectures. 

On the other hand, Open Networking involves building software from first principles using modern best practices, with Open API (e.g., OpenConfig/NetConf) for programmatic access without compromising on the massive scale-up and scale-out requirements of modern infrastructure.

SDN Network Design Options

We have both controller and controllerless options. With a controllerless solution, setup is faster, increases agility, and provides robustness in single-point-of-failure, particularly for out-of-band management, i.e., connecting all the controllers.

A controllerless architecture is more self-healing; anything in the overlay network is also part of the control plane resilience. An SDN controller or controller cluster may add complexity and impede resiliency. Since the network depends on them for operation, they become a single point of failure and can impact network performance. The intelligence kept in a controller can be a point of attack.

So, there are workarounds where the data plane can continue forward without an SDN controller but always avoid a single point of failure or complex ways to have a quorum in a control-based architecture.

software defined architecture
Diagram: Software defined architecutre.

Software Defined Architecture & Automation

We have two main types of automation to consider. Day 0 and days 1-2. First and foremost, day 0 automation simplifies and reduces human error when building the infrastructure. Days 1-2 touch the customer more. This may include installing services quickly on the fabric, e.g., VRF configuration and building Automation into the fabric. 

Day 0 automation

As I said, day 0 automation builds basic infrastructures, such as routing protocols and connection information. These stages need to be carried out before installing VLANs or services. Typical tools software-defined networking uses are Ansible or your internal applications to orchestrate the build of the network.

These are known as fabric automation tools. Once the tools discover the switches, the devices are connected in a particular way, and the fabric network is built without human intervention. It simplifies traditional automation, which is helpful in day 0 automation environments.

Configuration Management

Ansible is a configuration management tool that can help alleviate manual challenges. Ansible replaces the need for an operator to tune configuration files manually and does an excellent job in application deployment and orchestrating multi-deployment scenarios.  

Ansible configuration
Diagram: Ansible Configuration

Pre-deployed infrastructure

Ansible does not deploy the infrastructure; you could use other solutions like Terraform that are best suited for this. Terraform is infrastructure as a code tool. Ansible is often described as a configuration management tool and is typically mentioned along the same lines as Puppet, Chef, and Salt. However, there is a considerable difference in how they operate.

Most notably, the installation of agents. Ansible automation is relatively easy to install as it is agentless. The Ansible architecture can be used in large environments with Ansible Tower using the execution environment and automation mesh. I have recently encountered an automation mesh, a powerful overlay feature that enables automation closer to the network’s edge.

Current and desired stage [ YAML playbooks, variables ]

Ansible ensures that the managed asset’s current state meets the desired state. Ansible is all about state management. It does this with Ansible Playbooks, more specifically, YAML playbooks. A playbook is a term Ansible uses for a configuration management script and ensuring the desired state is met. Essentially, playbooks are Ansible’s configuration management scripts. 

open networking solutions
Diagram: Configuration management.

Day 1-2 automation

With day 1-2 automation, SDN does two things.

Firstly, the ability to install or provision services automatically across the fabric. With one command, human error is eliminated. The fabric synchronizes the policies across the entire network. It automates and disperses the provisioning operations across all devices. This level of automation is not classical, as this strategy is built into the SDN infrastructure. 

Secondly, it integrates network operations and services with virtualization infrastructure managers such as OpenStack, VCenter, OpenDaylight, or, at an advanced level, OpenShift networking SDN. How does the network adapt to the instantiation of new workloads via the systems? The network admin should not even be in the loop if, for example, a new virtual machine (VM) is created. 

There should be a signal that a VM with specific configurations should be created, which is then propagated to all fabric elements. You shouldn’t need to touch the network when the virtualization infrastructure managers provide a new service. This represents the ultimate in agility as you are removing the network components. 

The first steps of creating a software-defined data center

It is agreed that agility is a necessity. So, what is the prime step? One critical step is creating a software-defined data center that will allow the rapid deployment of computing and storage for workloads. In addition to software-defined computing and storage, the network must be automated and not be an impediment. 

The five critical layers of technology

To achieve software-defined agility for the network, we need an affordable solution that delivers on four essential layers of technology:

  1. Comprehensive telemetry/granular visibility into endpoints and traffic traversing the network fabric for performance monitoring and rapid troubleshooting.
  2. Network virtualization overlay, like computer virtualization, abstracts the network from the physical hardware for increased agility and segmentation.
  3. Software-defined networking (SDN) involves controlling and automating the physical underlay to eliminate the mundane AND error-prone box-by-box configuration.
  4. Open network underlay is a cost-effective physical infrastructure with no proprietary hardware lock-in that can leverage open source.
  5. Open Networking solutions are a must, as understanding the implications of open source in large, complex data center environments is essential.

The Future of Open Networking:

Open Networking will be crucial in shaping the future as technology evolves. The rise of 5G, the Internet of Things (IoT), and artificial intelligence (AI) will require highly agile, scalable, and intelligent networks. Open Networking’s flexibility and interoperability will meet these demands and enable a connected future.

Summary: Open Networking

Networking is vital in bringing people and ideas together in today’s interconnected world. Traditional closed networks have their limitations, but with the emergence of open networking, a new era of connectivity and collaboration has dawned. This blog post explored the concept of open networking, its benefits, and its impact on various industries and communities.

Section 1: What is Open Networking?

Open networking uses open standards, open-source software, and open APIs to build and manage networks. Open networking promotes interoperability, flexibility, and innovation, unlike closed networks that rely on proprietary systems and protocols. It allows organizations to customize and optimize their networks based on their unique requirements.

Section 2: Benefits of Open Networking

2.1 Enhanced Scalability and Agility

Open networking enables organizations to scale their networks more efficiently and adapt to changing needs. Decoupling hardware and software makes adding or removing network components easier, making the network more agile and responsive.

2.2 Cost Savings

With open networking, organizations can choose hardware and software components from multiple vendors, promoting competition and reducing costs. This eliminates vendor lock-in and allows organizations to use cost-effective solutions without compromising performance or reliability.

2.3 Innovation and Collaboration

Open networking fosters innovation by encouraging collaboration among vendors, developers, and users. Developers can create new applications and services that leverage the network infrastructure with open APIs and open-source software. This leads to a vibrant ecosystem of solutions that continually push the boundaries of what networks can achieve.

Section 3: Open Networking in Various Industries

3.1 Telecommunications

Open networking has revolutionized the telecommunications industry. Telecom operators can now build and manage their networks using standard hardware and open-source software, reducing costs and enabling faster service deployments. It has also paved the way for adopting virtualization technologies like Network Functions Virtualization (NFV) and Software-Defined Networking (SDN).

3.2 Data Centers

In the world of data centers, open networking has gained significant traction. Data center operators can achieve greater agility and scalability by using open standards and software-defined networking. Open networking also allows for better integration with cloud platforms and the ability to automate network provisioning and management.

3.3 Enterprise Networks

Enterprises are increasingly embracing open networking to gain more control over their networks and reduce costs. Open networking solutions offer greater flexibility regarding hardware and software choices, enabling enterprises to tailor their networks to meet specific business needs. It also facilitates seamless integration with cloud services and enhances network security.

Conclusion:

Open networking has emerged as a powerful force in today’s digital landscape. Its ability to promote interoperability, scalability, and innovation makes it a game-changer in various industries. Whether revolutionizing telecommunications, transforming data centers, or empowering enterprises, open networking connects the world in ways we never thought possible.

Cisco ACI

ACI Cisco

Cisco ACI Components

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

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

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

Table of Contents

Highlights: Cisco ACI Components

Hardware-based Underlay

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

The Legacy data center

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

  • Poor Resources

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

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

  1. Data Center Security 
  2. VMware NSX



Cisco SDN ACI 

Key ACI Cisco Discussion points:


  • Birth of virtualization and SDN.

  • Cisco ACI integrations.

  • ACI design and components.

  • VXLAN networking and ECMP.

  • Focus on ACI and SD-WAN.

Back to Basics: Cisco ACI components

Key Features of Cisco ACI

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

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

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

Cisco Data Center

Cisco ACI

Key Features

  • Application-Centric Policy Model

  • Automation and Orchestration

  • Scalability and Flexibility

  • Built-in Security 

Cisco Data Center

Cisco ACI 

Key Advantages

  • Enhanced Security

  • Agility and Time-to-Market

  • Simplified Operations

  • Open software flexibility for DevOps teams.

Benefits of Cisco ACI

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

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

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

The Cisco ACI SDN Solution

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

Nexus Family

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

Spine and Leaf

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

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

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

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

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

ACI Cisco: Integrations

Routing Control Platform

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

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

Cisco ACI: Integration Options

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

Cisco ACI Components: ACI Cisco and Multi-Pod

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

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

Cisco ACI Components: ACI Cisco and AlgoSec

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

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

Cisco ACI Components: ACI Cisco and AppDynamics 

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

Cisco ACI Components: ACI Cisco and SD-WAN 

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

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

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

The Cisco SDN ACI and SD-WAN Integration

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

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

Cisco ACI Components: Openshift and Cisco SDN ACI

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

Cisco ACI Components: Other data center integrations

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

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

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

The Cisco SDN ACI Design  

Introduction to leaf and spine

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

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

Cisco ACI
Diagram: Cisco ACI: Improving application performance.

The ACI fabric: Aggregate

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

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

SDN data center
Diagram: Cisco ACI fabric checking.

The issues with oversubscription

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

Horizontal scaling load balancing

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

Highlighting the overlay and underlay

Mapping Traffic

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

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

Overlay Encapsulation

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

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

Overlay and underlay components

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

ACI overlay
Diagram: Overlay. Source Cisco

Example: 

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

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

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

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

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

Multicast Distribution Tree (MDT)

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

Normalize the transports

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

Building the VXLAN tunnels 

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

Bridge domain and VRF

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

Horizontal scaling load balancing
Diagram: Horizontal scaling load balancing.

Routing for endpoints

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

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

COOP database
Diagram: COOP database

The VTEP and PTEP

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

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

The Spine TEP

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

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

Cisco ACI
Diagram: Routing control platform.

The ACI optimizations

Mouse and elephant flows

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

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

ARP optimizations: Anycast gateways

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

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

Fabric anycast addressing

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

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

Pervasive gateway

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

The Cisco SDN ACI Integrations

OpenShift and Cisco ACI

  • OpenSwitch virtual network

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

Openshift sdn
Diagram: OpenShift SDN.

OpenShift SDN plugin

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

Integrating ACI and OpenShift platform

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

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

The Cisco SDN ACI and AppDynamics

AppDynamis overview

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

The user’s critical path

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

So, how do you discover all these business transactions?

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

Cisco AppDynamics
Diagram: Cisco AppDynamics.

AppDynamic topology

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

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

Types of Agents for Infrastructure Visibility

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

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

Automatic establishment of the baseline

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

Summary: Cisco ACI Components

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

Section 1: Understanding Cisco ACI Architecture

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

1. Application Policy Infrastructure Controller (APIC):

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

2. Nexus Switches:

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

3. Application Network Profiles:

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

Section 2: The Power of Network Automation

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

Section 3: Security and Microsegmentation with Cisco ACI

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

Conclusion:

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

young-man-wearing-vr-glasses-with-neon-light-futu-2021-12-17-19-01-47-utc

Intent-Based Networking

 

 

Intent-Based Networking

In today’s fast-paced digital world, networks connect people, devices, and services. However, managing these networks efficiently and effectively has become increasingly complex. This is where Intent-Based Networking (IBN) comes in. This blog post will explore what IBN is, how it differs from traditional network management approaches, and why it revolutionizes how networks are managed.

Intent-Based Networking is a paradigm shift in network management that leverages automation, artificial intelligence, and machine learning to simplify network operations. Instead of configuring individual devices manually, IBN focuses on defining the desired outcome or intent and allows the network infrastructure to configure and optimize itself accordingly. This intent-driven approach enables organizations to manage their networks more agile, responsive, and scalable.

 

Highlights: Intent-Based Networking

  • The lack of Agility

Intent-based networking is not just hype; we see many intent-driven networks already with many SD WAN overlay roll-outs. It is a necessary development; from a technology standpoint, it has arrived. However, cultural acceptance will take a little longer. Organizations are looking to modernize their business processes and their networks.

Yet, the traditional vertically integrated monolithic networking solutions prohibit the network from achieving agility. This is why we need intent-based networking systems. So, what is intent-based networking? Intent-based networking is where an end-user describes what the network should do, and the system automatically configures the policy. It uses declarative statements, i.e., what the network should do, instead of imperative statements. 

  • Converts the What into How

You are telling the network what you want to accomplish, not precisely what to do and how to do it, i.e., tell me what you want, not how to do it, all of which gets translated behind the scenes. Essentially, intent-based networking is a piece of open networking software that takes the “what” and converts it into the “how.” The system generates the resulting configuration for design and device implementation.

The system is provided with algorithms that translate business intent into network configurations. Humans can not match the speed of algorithms, and this is key. The system is aware of the network state and can ingest real-time network status from multiple sources in a transport and protocol-agnostic way.

  • The Desired State

It adds the final piece of the puzzle by validating in real time that the intent is being met. The system continuously compares the actual to the desired state of the running network. If the desired state is unmet, corrective actions such as modifying a QoS policy or applying an access control list (ACL) can occur. This allows for a closer alignment between the network infrastructure and business initiatives and maintains the network’s correctness.

 

Related: Before you proceed, you may find the following posts helpful.

  1. Network Configuration Automation
  2. Distributed Systems Observability
  3. Reliability in Distributed Systems
  4. Container Networking
  5. Overlay Virtual Networking

 



Kubernetes Attack Vectors

Key Kubernetes Security Best Practice Discussion points:


  • The issues with traditional security constructs.

  • The growing hacker sophistication.

  • Recap on the Kubernetes architecture.

  • Details on the Kubernetes security best practice.

  • Security 101 for containers and Kubernetes.

 

  • A key point: Video on intent-based networking

In this video, we will discuss the basics of intent-based networking: informing the controller about the end goal and allowing the controller-based network to figure out the low-level device and configuration details. Finally, as a product reference, we discuss Cisco SD-Access.

 

Tech Brief Video Series - Enterprise Networking | SD-Access & Intent-based networking
Prev 1 of 1 Next
Prev 1 of 1 Next

 

Back to basics: Intent-Based Networking

To understand what Intent-Based Networking is, learning more about what Intent encompasses is essential. An intent is a brief description of the purpose and a concrete predetermined set of steps that must be executed to (successfully) achieve the Intent. This principle can also be applied to the operation of a network infrastructure. The Intent and its steps precisely describe what needs to be done on the network to accomplish a specific task. 

For example, the application is migrating to the cloud. In this case, the Intent or steps may include the following. First, take the existing access policy for that application from the data center policy, transform the policy into an application policy for Internet access, deploy the procedure on all perimeter firewalls, and change the routing for that application to the cloud.

Intent Based Networking

Main Intent Based Networking Components

Intent Based Networking 

  • Translates high-level business objectives into network policies and configurations

  • Automating routine network tasks, such as provisioning, configuration, and troubleshooting.

  • Continuous monitoring and verification of network behavior against the intended state

Key Principles of Intent-Based Networking:

1. Translation: Intent-based networking automatically translates high-level business objectives into network policies and configurations. By understanding the desired intent, the network infrastructure can autonomously make the necessary adjustments to align with the organization’s goals.

2. Automation: Automation is a fundamental aspect of IBN. By automating routine network tasks, such as provisioning, configuration, and troubleshooting, network administrators can focus on strategic activities that add value to the organization. Automation also reduces the risk of human error, leading to improved network reliability and security.

3. Assurance: IBN provides continuous monitoring and verification of network behavior against the intended state. By constantly comparing the network’s current state with the desired intent, IBN can promptly identify and mitigate any configuration drift or anomalies. This proactive approach enhances network visibility, performance, and compliance.

Data Center

Intent-based Networking

Key Benefits

  • Simplified Network Management

  • Enhanced Agility and Scalability

  • Improved Network Security

  • Optimized Performance

Benefits of Intent-Based Networking:

1. Simplified Network Management: With IBN, network administrators can easily manage complex networks. By abstracting the complexity of individual devices and focusing on business intent, IBN simplifies network operations, reducing the need for manual configuration and troubleshooting.

2. Enhanced Agility and Scalability: IBN enables organizations to respond quickly to changing business requirements and scale their networks effortlessly. By automating network provisioning and configuration, IBN supports rapid deployment and seamless integration of new services and devices.

3. Improved Network Security: Security is a top concern for modern networks. IBN offers enhanced security by continuously monitoring network behavior and enforcing security policies. This proactive approach reduces the risk of security breaches and enables faster threat detection and response.

4. Optimized Performance: IBN leverages real-time analytics and machine learning to optimize network performance. By dynamically adjusting network configurations based on traffic patterns and user behavior, IBN ensures optimal performance and user experience.

 

Example Solution: Cisco SD-Access

The Cisco SD-Access digital network evolution transforms traditional campus LANs into intent-driven, programmable networks. Campus Fabric and DNA Center are Cisco SD-Access’ two main components. Creating and monitoring the Cisco Campus Fabric is automated and assured through the Cisco DNA Center.

Cisco Campus Fabric Architecture
In Cisco SD-Access, fabric roles and terminology differ from those in traditional three-tier hierarchical networks. To create a logical topology, Cisco SD-Access uses overlay networks running on a physical network (underlay network) to implement fabric technology.

Underlay networks are the traditional physical networks that connect LAN devices such as routers and switches. A primary function of an underlay network is to provide IP connectivity for traffic to travel from one point to another. Due to the IP-based underlay, any interior gateway protocol (IGP) can be utilized.

Overlay and Underlay Networking

Fabrics are overlay networks. Internet Protocol Security (IPsec), Generic Routing Encapsulation (GRE), Dynamic Multipoint Virtual Private Networks (DMVPN), Multiprotocol Label Switching (MPLS), Location Identifier Separation Protocol (LISP), and others are commonly used with overlay networks in the IT world to virtual connect devices. Virtually connecting devices over a topology-independent physical underlay network, an overlay network is a logical topology.

MPLS forwarding
Diagram: MPLS forwarding

Forwarding and control planes are separated in overlay networks, resulting in a flexible, programmable, and scalable network. To simplify the underlay, the control plane and data plane are separated. As the control plane becomes the network’s brain, it allows faster forwarding and optimizes packets and network reliability. As an underlay for the centralized controller, Cisco SD-Access supports building a fabric using an existing network.

Underlay networks can be automated with Cisco DNA Center. As a result, it is helpful for new implementations or infrastructure growth since it eliminates the hassle of setting up the underlay. For differentiation, segmentation, and mobility, overlay networks often use alternate forwarding attributes in an additional header.

Cisco SD AccessNetworking Complexity

Networks continue to get more complex as traffic demands increase. While software-defined networking (SDN) can abstract the underlying complexities, we must consider how we orchestrate the policy and intent across multi-vendor, multi-domain elements.

To overcome complexity, you have to abstract. We have been doing this with tunneling for decades. However, different abstractions are used at the business and infrastructure resource levels.

At a business level, you need to be flexible as rules will change and must be approached differently from how the operating system comes modeling resources. We must make new architecture decisions for this, as it’s not just about configuration management and orchestrations. None of these can look at the network state, which we need to do.

For this, we need network intelligence. How networks are built and managed today uses a manual approach without algorithmic validation. The manual process of networking is not viable in the future.  Let’s face it: humans make mistakes.

There are many reasons for network outages, ranging from software bugs and hardware/power failure to security breaches. All of which comes from a lack of implementing network security. But human error is still the number one cause. We are inhibited by manual configuration. Intent-based networking eliminates this inhibition.

 

intent-based networking
Diagram: Intent-Driven Network.

 

The traditional approach to networking

In the traditional network model, there is a gap between the architect’s intent and what’s achieved. Not just for device configuration but also for achieved runtime behavior. Until now, there has not been a way to validate the original intent or to have a continuous verification mechanism.

Once you have achieved this level of assurance, you can focus on business needs and not be constrained by managing a legacy network. For example, Netflix moved its control plane to the cloud and now focuses all its time on its customer base.

We have gone halfway and spent billions of dollars on the compute, storage, and applications, but the network still lags. The architecture and protocols have become more complex, but the management tools have not kept pace. Fortunately, now, this is beginning to change.

 

Software-defined networking; slow deployments

SDN shows great promise that could release networking, but deployments have been slow. Primarily down to large cloud-scale organizations with ample resources and dollars. But what can the rest of the industry do if we do not have that level of business maturity?  Intent-based networking is a natural successor to SDN, as many intent-based vendors have borrowed the same principles and common architectures.

The systems are built on the divide between the application and the network infrastructure. However, SDN operates at the network architecture level, where the control plane instructs the data plane forwarding node. Intent-based systems work higher at the application level to offer true brownfield network automation.

SDN and SD-WAN have made considerable leaps in network programmability, but intent-based networking is a further leap to zero-touch self-healing networks. For additional information on SD-WAN, including the challenges with existing WANs, such as lack of agility with BGP ( what is BGP protocol in networking ) and the core features of SD-WAN, check out this SDWAN tutorial.

 

  • A key point: Video on BGP in the data center

In this whiteboard session, we will address the basics of BGP. A network exists specifically to serve the connectivity requirements of applications, and these applications are to serve business needs. So, these applications must run on stable networks and stable networks are built from stable routing protocols.

Routing Protocols are a set of predefined rules used by the routers that interconnect your network to maintain the communication between the source and the destination. These routing protocols help to find the routes between two nodes on the computer network.

 

BGP in the Data Center
Prev 1 of 1 Next
Prev 1 of 1 Next

 

Intent-Based Networking Use Case

The wide-area network (WAN) edge consists of several network infrastructure devices, including Layer 3 routers, SD-WAN appliances such as Viptela SD-WAN, and WAN optimization controllers. These devices could send diagnostic information for the intent-based system to ingest. The system can ingest from multiple sources, including a monitoring system and network telemetry.

As a result, the system can keep track of application performance over a variety of links. Suppose there is a performance-related problem, the policies are unmet, and application performance degrades.

In that case, the system can take action, such as to re-route the traffic over a less congested link or notify a network team member. The intent-based system does not have to take corrective action, similar to how IDS/IPS is deployed. These devices can take disciplinary action if necessary, but many use IDS/IPS to alert.

Looking deeper on intent based networking systems

The intent-based architecture combines machine learning (ML), cognitive computing, and deep analytics, providing enhanced levels of automation and programmability through an easy-to-use GUI. Combining these technologies allows you to move from a reactive to a proactive system.

ML, a sub-application of artificial intelligence (AI), allows intent-based systems to analyze and learn from data without explicit programming automatically. Therefore, it enables systems to understand and predict the data for autonomous behavior. Intent-based networking represents a radical new approach to network architecture and takes networking to the next level in intelligence.

It is not a technology that is going to be accepted overnight. Its adoption will be slow as, to some, a fully automated network can sound daunting, placing the faith of your business, which for many organizations is the network.

However, deploying intent-based networking systems offers a new way to build and operate networks, which increases agility, availability, and security compared to traditional networking.

Conclusion: Intent-Based Networking is transforming the way networks are managed. By shifting the focus from device-centric configurations to intent-driven outcomes, IBN simplifies network management, enhances agility and scalability, improves security, and optimizes network performance. As organizations strive to meet the demands of the digital age, embracing this innovative approach can pave the way for a more efficient and intelligent network infrastructure.

 

 

network-automation3

Network Configuration Automation

 

automate network configuration

 

Network Configuration Automation

In today’s fast-paced digital landscape, businesses rely heavily on efficient network operations to stay competitive. Network configuration automation has emerged as a game-changer, enabling organizations to streamline their network management processes and enhance overall operational efficiency. This blog post will delve into network configuration automation, its benefits, and how it revolutionizes how businesses manage their networks.

Network configuration automation is the practice of using software tools to automate the management and configuration of network devices. Traditionally, network administrators have manually configured and managed network devices, which can be time-consuming, error-prone, and resource-intensive. With network configuration automation, these tasks are automated, enabling administrators to manage and control their network infrastructure centrally, reducing the risk of human error and accelerating network deployment and updates.

 

Highlights: Network Configuration Automation

  • Application Changes

How applications are deployed today is so different from the way applications were deployed 10-15 years ago. So much has changed with the app. The problem we are seeing today is that the network is not tightly coupled with these other developments. The provision of various network policies and corresponding configurations are not tightly associated with the application.

Most of the time, they are loosely coupled and reactive. For example, analyzing firewall rules and providing a network assessment is nearly impossible with old security devices driving the need for network configuration automation and the ability to automate network configuration.

 

Before you proceed, you may find the following articles of interest:

  1. Open Networking
  2. A10 Networks
  3. Brownfield Network Automation

 



Automate Network Configuration.

Key Network Configuration Automation Discussion Points:


  • Introduction to Network Configuration Automation and what is involved.

  • Highlighting the components of Automate Network Configuration.

  • Critical points on the use of Ansible and Ansible variables.

  • Technical details on how virtualization changes the manual approach.

  • Technical details on SDN as a companion to automation.

 

Back to basics with the Network Automation.

One of the easiest and quickest ways to get started with network automation is to automate the creation of the device configuration files used for initial device provisioning and push them to network devices. You can also extra a lot of information with automation. For example, network devices have enormous static and ephemeral data buried inside, and using open-source tools or building your own gets you access to this data.

Examples of this type of data include entries in the BGP table, OSPF adjacencies, active neighbors, interface statistics, specific counters and resets, and even counters from application-specific integrated circuits (ASICs) themselves on newer platforms.

 

  • A key point: Lab guide with Ansible Core

We have Ansible installed and a managed host already prepared in the following. The managed host needs to have SSH enabled and a user with admin privileges. Ansible finds managed hosts by looking at the inventory file. The inventory file is also a great place to pass variables that can be used to remove site-specific information; this is set under the host var section below.

Remember that Ansible requires Python, and below, we are running Python version 3.0.3 and Jinja version 3.0.3, which is used for templating. You can pass information to ansible managed hosts with playbooks and ad hoc commands. Below, I’m using an ad hoc command, calling the command module by default, and testing with a ping.

 

Ansible configuration
Diagram: Ansible Configuration

 

Benefits of Network Configuration Automation:

1. Time and Resource Efficiency: Organizations can free up their IT staff to focus on more strategic initiatives by automating repetitive and time-consuming network configuration tasks. This results in increased productivity and efficiency across the organization.

2. Enhanced Accuracy and Consistency: Manual configuration processes are prone to human error, leading to misconfigurations and network downtime. Network configuration automation eliminates these risks by ensuring consistency and accuracy in network configurations, reducing the chances of costly errors.

3. Rapid Network Deployment: Network administrators can quickly deploy network configurations across multiple devices simultaneously with automation tools. This accelerates network deployment and enables organizations to respond faster to changing business needs.

4. Improved Security and Compliance: Network configuration automation enhances security by enforcing standardized configurations and ensuring compliance with industry regulations. Automated security protocols can be applied consistently across the network, reducing vulnerabilities and enhancing overall network protection.

5. Simplified Network Management: Automation tools provide a centralized platform for managing network configurations, making it easier to monitor, troubleshoot, and maintain network devices. This simplifies network management and reduces the complexity associated with manual configuration processes.

Implementing Network Configuration Automation:

To implement network configuration automation, organizations need to consider the following steps:

1. Assess Network Requirements: Understand the specific network requirements, including device types, network protocols, and security policies.

2. Select an Automation Tool: Evaluate different automation tools available in the market and choose the one that aligns with the organization’s needs and network infrastructure.

3. Create Configuration Templates: Develop standardized configuration templates that can be easily applied to network devices. These templates should include best practices, security policies, and network-specific configurations.

4. Test and Validate: Before deploying automated configurations, thoroughly test and validate them in a controlled environment to ensure their effectiveness and compatibility with the existing network infrastructure.

5. Monitor and Maintain: Regularly monitor and maintain the automated network configurations to identify and resolve any issues or security vulnerabilities that may arise.

 

The Need to Automate Network Configuration

There are always hundreds, if not thousands, of outdated rules even though the application service is not required. Another example is unused VLANs left configured on access ports, posing a security risk. The problem lies in the process: how we change and provision the network is not tied to the application. It is not automated. Inconsistent configurations tend to grow as human interaction is required to tidy things up. People move on and change roles.

You cannot guarantee the person creating a firewall rule will be the engineer deleting the rule once the corresponding applications are decommissioned or changed. And if you don’t have a rigorous change control process, deprecated configurations will be idle on active nodes.

 

  • A key point: The use of Ansible variables in an Ansible architecture.

For configuration management, you could opt for Red Hat Ansible. The Ansible architecture consists of modules with tasks on the target hosts listed in the inventory. Various plugins are available for additional context and Ansible variables for flexible playbook development. Ansible Core is the CLI-based version of automation, and Ansible Tower is the platform.

The recommended approach for enterprise-wide security would be a platform-based approach to the Ansible architecture. Using a platform approach using Ansible variables creates a very flexible automation journey where you can have one playbook with Ansible variables, removing any site-specific information running against several different inventories that could relate to your other function, Dev, Staging, and Production.

Network Automation

The network is critical for business continuity, resulting in real uptime pressure. The operational uptime is directly tied to the success of the business. This results in a manual. The culture that manifests is manual and slow. The actual bottleneck is our manual culture for network provision and operation.

 

Virtualization – Beginning the change

Virtualization vendors are changing the manual approach. For example, if we look at essential MAC address learning and its process with traditional switches. The source MAC address of an incoming Ethernet frame is examined, and if the source MAC address is known, it doesn’t need to do anything, but if it’s not known, it will add that MAC to its table and make a note of the port the frame entered. The switch has a port for MAC mapping. The table is continually maintained, and MAC addresses are added and removed via timers and flushing.

 

The virtual switch

The virtual switch operates differently. Whenever a VM spins up, and a VNIC attaches to the virtual switch, the Hypervisor programs everything it needs to know to forward that traffic into its process on the virtual switch. There is no MAC learning. When you spin down the VM, the hypervisor does not need to wait for a timer.

It knows the source is no longer there; as a result, it no longer needs to have that state. Less state in a network is a good thing. The critical point is that the provision of the application/ virtual machine is tightly coupled with the provisioning of network resources. Tightly coupling applications to network resources/provisioning offers less “Garbage Collection.”

 

Box mentality  

When the contents of HLD / LLD are completed, and you are now moving to the configuration stage, the current implementation-specific details are done per box. The commands are defined on individual boxes and are vendor-specific. This works functionally, and it’s how the Internet was built, but it lacks agility and proper configuration management. Many repetitive tasks with a box mentality destroy your ability to scale.

Businesses are mainly concerned with agility and continuity, but you cannot have these two things with manual provisions. You must look at your network as a system, not as individual boxes. When you look at applications and their scaling, the current network-style implementation method does not scale and keeps in line with the apps. A move to network configuration automation and automatic interaction is the solution.

 

Configuration management

Network Configuration Automation and Automate Network Configuration

We must move out of a manual approach and into an automated system. Focus initially on low-hanging fruit and easy wins. What takes engineers the longest to do? Do VLAN and Subnet allocation sheets ring a bell? We should size according to demand and not care about the type of VLAN or the Internal subnet allocation. Microsoft Azure cloud is a perfect example.

They do not care about the type of private address they assign to internal systems. They automate the IP allocation and gateway assignment so you can communicate locally. Designing optimum networks to last and scale is not good enough anymore. The network must evolve and be programmed to keep up with app placement. The configuration approach needs to change, and we should move to proper configuration management and automation.

A widespread tool of choice is Ansible. As previously mentioned, we have Ansible Tower as a platform, and for CLI-based devices, we have Ansible Core—both support variable substitution with Ansible variables.

 

SDN: A companion to network automation?

One benefit of Software Defined Networking (SDN) is that it lets you view your network holistically, with a central viewpoint. Network configuration automation is not SDN, and SDN is not network automation. They work side by side and complement each other. SDN allows you to be abstract and prevents those not needing to see the detail from not seeing it.

The application owners do not care about VLANs. Application designers should also not care about local IP allocations if they have designed the application correctly. Centralization is also a goal for SDN. Centralization with SDN is different from control-plane centralization. Central SDN controller devices should not fully control the control plane.

SDN companies have learned this and now allow network nodes to handle some or part control plane operations.  

 

  • Programming network: Automate network configuration

You don’t need to be a programmer, but you should start to think like one. Learning to program will make you better equipped to deal with things. Programming networks is a diagonal step to what you are doing now, offering an environment to run code and ways to test code before you run it out.

The current CLI is the most dangerous approach to device configuration; you can even lock yourself out of a device. Programming adds a safety net. It’s more of a mental shift. Stop jumping to the CLI and THINK FIRST. Break the task down and create workflows. Workloads are then mapped to an automation platform.

 

  • A key point: TCL and EXPECT

TCL ( Tool Command Language ) is a scripting language that was created in 1988 at UC Berkeley. It aims to tie together Shell scripts and Unix commands. EXPECT is a TCL extension written by Don Libes. It automates Telnet, SSH, and Serial sessions to perform many repetitive tasks.

EXPECT’s main drawback is that it is not secure and is synchronous only. If you log onto a device, you display login credentials in the EXPECT scripts and cannot encrypt that data in the code. In addition, it operates sequentially, meaning you send a command and wait for the output; it does not send send send and wait to receive; it’s a send and waits, sends and wait for mythology.

 

  • A key point: SNMP has failed | NETCONF begins

SNMP is used for fault handling, monitoring equipment, and retrieving performance data, but very few use SNMP to set configurations. More often, there is no 1:1 translation between a CLI configuration operation and an SNMP “SET.” It’s hard to get this 1-2-1 correlation. As a result, not many people use SNMP for device configuration and management of structures.

CLI scripting was the primary approach to automating configuration changes to the network before NETCONF. Unfortunately, CLI scripting has several limitations, including a lack of transaction management, no structured error management, and the ever-changing structure and syntax of commands, making scripts fragile and costly to maintain. Even the use of autocorrelation scripts won’t be able to fix it.

People make mistakes, and ultimately, people are bad at stuff. It’s the nature of the beast. Human error plays a significant role in network outages, and if a person is not logging in doing CLI, they are less likely to make a costly mistake. Human interaction with the network is a major cause of network outages.

 

NETCONF & Tail-F

NETCONF ( network control protocol ) is an XML-based data encoding for configuration and protocol messages. It offers secure transport and is Asynchronous, so it’s not sequential like TCL and EXPECT. Asynchronous makes NETCONF more efficient. It allows the separation of the configuration from the non-configuration items.

Backup and restore are complex with SNMP, as you have no idea what fields are used to restore. Also, because of the binary nature of SNMP, it isn’t easy to compare configurations from one device to another. NETCONF is much better at doing this.

 

A final note: Transaction-based approach

It offers a transaction-based approach. A transaction is a set of configuration changes, not a sequence. SNMP for configuration requires everything to be in the correct sequence/order. But with a transaction, you throw in everything, and the device figures out how to roll it out.

What matters is that operators can write service-level applications that activate service-level changes and don’t have to make the application aware of all the sequence of changes that must be completed before the network can serve application responses and requests. Check out an exciting company called Tail-F (now part of Cisco) which offers a family of NETCONF-enabled products.

 

Conclusion:

Network configuration automation is revolutionizing how businesses manage their networks. It offers many benefits, including time and resource efficiency, enhanced accuracy, rapid network deployment, improved security, and simplified network management. By embracing this technology, organizations can streamline network operations, reduce human error, and stay ahead in the dynamic and ever-evolving digital landscape.

 

Automation Network Configuration

SDN applications

HP SDN Controller

 

HP OpenFlow

 

HP SDN Controller

In today’s fast-paced digital world, efficient network management is crucial for organizations to stay competitive. Traditional network infrastructures often struggle to keep up with the increasing demands of modern applications and services. Enter the HP SDN Controller, a revolutionary solution transforming how networks are managed. In this blog post, we will delve into the world of the HP SDN Controller, exploring its features, benefits, and how it is reshaping the future of network management.

The HP SDN Controller is a software-defined networking (SDN) solution designed to simplify and automate network management. By decoupling the network control plane from the underlying infrastructure, the SDN Controller empowers organizations to manage and control their networks centrally, making it easier to deploy, scale, and adapt to changing business needs.

 

Highlights: SDN Controller

  • Application SDN

This post discusses HP SDN Controller and its approach to HP OpenFlow based on the OpenFlow protocol. All of which enables an exciting approach to Application SDN. It takes too long to provision network services for an application. As a result, the network lacks agility, and making changes is still a manual process.

Usually, when an application is rolled out, you must reconfigure every device with a command CLI interface. This type of manual configuration cannot accommodate today’s application requirements. Furthermore, static rollout frameworks prohibit dynamic changes to the network, blocking the full potential that applications can bring to the business.

  • The Role of SDN

Software-Defined Networking (SDN) aims to take rigidity out of networks and give you the visibility to make real-time changes and responses. The HP SDN Application Suite changes how the network responds to business needs by programming the network differently. The following post discusses the HP SDN controller and how it works with HP OpenFlow, where HP operates the best part of OpenFlow and uses it with traditional routing and switching. I will also provide an example of an application SDN, such as a network protector and network optimizer.

 

Before you proceed, you may find the following helpful post for pre-information:

  1. SDN Traffic Optimizations
  2. What Is OpenFlow
  3. BGP SDN 
  4. What Does SDN Mean
  5. SDN Adoption Report
  6. WAN SDN 
  7. Hyperscale Networking

 



SDN Controller

Key HP SDN Controller Discussion Points:


  • Introduction to HP SDN Controller and what is involved.

  • Highlighting HP OpenFlow and the components involved.

  • Critical points on the SDN VAN controller.

  • Technical details on Application SDN: Network Protector.

  • Technical details on Application SDN: Network Optimizer

 

Back to basics with SDN

Software-Defined Networking (SDN) is the decoupling of network control from networking devices that are used to forward the traffic. The network control functionality, also known as the control plane, is decoupled from the data forwarding functionality (also known as the data plane). Furthermore, the split control is programmable by exposing several APIs. The migration of control logic, which used to be tightly integrated into networking devices into logically centralized controllers, enables the underlying networking infrastructure to be abstracted from an application’s point of view.

 

Key Features of HP SDN Controller:

Centralized Management: The SDN Controller provides a centralized platform for managing and configuring network devices, eliminating the need for manual configurations on individual switches or routers. This streamlined approach improves efficiency and reduces the risk of human errors.

Programmable Network: With the HP SDN Controller, network administrators can program and control the behavior of the network through open APIs. This programmability enables organizations to tailor their network infrastructure to meet specific requirements, such as optimizing performance, enhancing security, or enabling new services.

Network Virtualization: Virtualizing the network infrastructure allows organizations to create multiple virtual networks on a shared physical infrastructure. The SDN Controller enables network virtualization, providing isolation and segmentation of traffic, improving network scalability, and simplifying network management.

Traffic Engineering and Performance Optimization: HP SDN Controller enables dynamic traffic engineering, allowing administrators to route traffic based on real-time conditions intelligently. This capability improves network performance, reduces congestion, and enhances user experience.

Benefits of HP SDN Controller:

Improved Network Agility: The SDN Controller enables organizations to respond quickly to changing business needs, allowing for a more agile and flexible network infrastructure. It simplifies the deployment of new applications and services, reduces time-to-market, and enhances the organization’s ability to innovate.

Enhanced Security: With the SDN Controller’s centralized control and programmability, organizations can implement security policies and access control measures more effectively. It enables granular control and visibility, empowering administrators to monitor and secure the network infrastructure against potential threats.

Cost Savings: By automating network management tasks and optimizing resource allocation, HP SDN Controller helps organizations reduce operational costs. It eliminates the need for manual configurations on individual devices, reduces human errors, and improves overall network efficiency.

Scalability and Flexibility: The SDN Controller allows organizations to scale their network infrastructure as their business snowballs. It supports integrating new devices, services, and technologies without disrupting the existing network, ensuring flexibility and future infrastructure-proofing.

Real-World Applications of HP SDN Controller:

Data Centers: HP SDN Controller facilitates the management and orchestration of network resources in data centers, enabling organizations to allocate resources efficiently, optimize workload distribution, and enhance overall performance.

Campus Networks: By centralizing network management, the SDN Controller simplifies the configuration and deployment of services across campus networks. It allows for seamless integration of wired and wireless networks, improves scalability, and enhances user experience.

Service Providers: HP SDN Controller empowers providers to deliver agile and scalable customer services. It enables the creation of virtualized network functions and improves service provisioning, reducing time-to-market and enhancing service quality.

 

HP SDN

Hewlett Packard (HP) has taken a different approach to SDN. They do not want to recreate every wheel invented and roll out a blanket greenfield OpenFlow solution. Routing has worked for 40 years, so we cannot expect to see some revolutionary change to routing as it’s simply not there. Consider how complicated distributed systems are. Filing all Layer 2 and 3 protocols with OpenFlow is nearly impossible.

Layer 2 switches learn MAC addresses automatically, building a table that can selectively forward packets. So, why is there a need to replace how switches learn via Layer 2? The layer 2-learning mechanism works fine, and no real driver can replace it. There are Potential drivers for Spanning Tree Protocol (STP) replacement as it is dangerous, but there is no reason to replace the layer 2-learning mechanism. So, why attempt this with OpenFlow?

 

HP OpenFlow

OpenFlow comes with its challenges. It derives from Stanford and is very academic. It’s hard to use and deploy in its pure form. HP adds to it and makes it more usable. They tune its implementation to match today’s network requirements using parts of OpenFlow, considering this to be HP OpenFlow and traditional routing. OpenFlow is generally not good, but certain narrow niche cases exist where it can be used. Campus networks are one of those niches, and HP is marketing its product set for this niche.

Their HP SDN controller product sets markets the network edge and leaves the core to what it does best. This allows an easy migration path by starting at the edge and moving gradually to the core ( if needed). This type of migration path keeps the potential blast radius to a minimum. An initial migration strategy by starting at the edge with SDN islands sounds appealing.

 

Diagram: HP SDN Controller.

 

HP SDN: The SDN VAN controller

HP removed the North-South bottleneck communication. They are not sending anything to the controller. Any packets that miss an OpenFlow rule hit what is known as the last rule and are sent with standard packet processing via traditional methods.

The last rule, “Forward match all – forward normal,” reverts to the regular forwarding plane, and the network does what it’s always done. If no OpenFlow match exists, packets are forwarded via traditional means. They use a conventional distributed control plane so it can scale. Suppose you consider a controller that has to learn the topology and compute the best path through a topology.

In that case, controller-based “routing” is almost certainly more complex than distributed routing protocols. HP SDN design does not do this and combines the best from OpenFlow and Routing. OpenFlow rules take precedence over most of the control plane elements.

However, most Layer 2-control plane protocols are left to traditional methods. As a general rule, you keep time-critical things such as Link Aggregation Control Protocol (LACP) and Bidirectional Forwarding Detection (BFD) with conventional methods, and other controls that are not as time-critical can be done with OpenFlow.

 

  • HP OpenFlow: HP uses Openflow to glean and not modify the forwarding plane.

 

The controller can work in several modes. The first is the Hybrid model that forwards with OpenFlow rules. If all OpenFlow rules are not matched, it will fall back to standard processing. The second mode is Discovery. This is where the local SDN switches send copies of ARP and DHCP packets to the controller. By analyzing this information, the controller knows where all the hosts are and can build a network topology map. A centralized view of the network topology is a significant benefit to SDN.

They also use BBDP, which is similar to LLDP. It uses a broadcast domain and is not just link-level, enabling it to fly through OpenFlow-enabled switches. The controller is not directly influencing forwarding; it scans the topology by listening to endpoint discovery information. The controller now contains a topology view, but there is no intercepting or redirecting traffic. Instead, it provides endpoint visibility across the network.

HP has started to integrate its SDN controller with Microsoft Active Directory. This gives the controller a different layer of visibility, not just IP and Subnet-based. It now gives you a higher-level language to control your network. It is making decisions based on users and groups, not subnets.

 

Application SDN: Network Protector  

There are a lot of issues with Malware and Spyware, and the HP Protector product can help with these challenges. It enables real-time assessment and security across all SDN devices. The application SDN pushes down one rule – UDP 53 redirects to the controller. It intercepts UDP 53 and can push down ACL rules to block certain types of traffic.

They extract DNS traffic on the network’s edge and pass it to the controller. Application features rank the reputation of an external site and determine how likely you will get something nasty if you go to that site. Additional hit count capability lets the network admin track who requests what. For example, if a host requests 3000 DNS requests per second, it is considered an infected host and quarantined by sending down additional OpenFlow rules.

 

application sdn
Diagram: Application SDN

 

  • A key point: Application SDN and Network visualizer  

SDN application for network admins assists in troubleshooting by defining where the traffic is and where it is going. The network admin can select traffic, make copies, and send it to a location. Similar to tapping, except it is quicker and easier to roll out. Now, your network traffic is viewable on any port and switch. This App lets you go the wire straight away.

As it is now integrated with Active Directory, when a user calls and says he has a network problem, you can extract his traffic by user ID and debug it remotely.

All you need is the User ID; in 30 seconds, you can see his packets. This is a level of visibility previously not available. HP gives you a level of network traffic detail incapable in the past. You could also grab ingress OSPF for analysis. This is not something you could do in the past. You can mirror LSAs and recreate the entire topology. You need access to one switch in the OSPF area.

 

  • A key point: Application SDN and Network optimizer  

This application SDN is used for Microsoft LYNC and SKYPE for business. It provides automated provisioning of network policy and quality of service to endpoints. Lync and Microsoft created a diagnostic API called SDN API. This diagnostic API sends information about the calls, username, IP, and port number on both sides – ingress and egress.

It can reach the ingress switch on each side and remark the Differentiated Services Code Point (DSCP) for the ingress flows. This is how SDN applications should work. SDN implementations should be where the application requests service from the network, and the network responds. We were at Layer 4 with ACL and QoS, not the Layer 7 application. Now, with HP Network Optimizer, the application can notify the network, and the network can respond.

 

Closing SDN comments

The HP SDN suite is about adding value to the network’s edge. Where do you allow the dynamic value of SDN to give value up to customers’ risk appetite? Keeping the dynamic SDN to the edge while keeping the core static is a significant value of SDN and an excellent migration strategy. The SDN concept takes information otherwise out of the network to the network.

 

Conclusion:

The HP SDN Controller is a game-changer in network management, revolutionizing how organizations manage their networks. Its centralized control, programmability, and automation capabilities provide numerous benefits, including improved network agility, enhanced security, cost savings, and scalability. As organizations strive to keep up with the ever-evolving digital landscape, the HP SDN Controller offers a powerful solution to streamline network management and drive innovation.

 

HP OpenFlow

MPLS forwarding

Segment Routing – Introduction

 

 

Segment Routing

In today’s interconnected world, where data traffic is growing exponentially, network operators face numerous challenges regarding scalability, flexibility, and efficiency. To address these concerns, segment routing has emerged as a powerful networking paradigm that offers a simplified and programmable approach to traffic engineering. In this blog post, we will explore the concept of segment routing, its benefits, and its applications in modern networks.

Segment routing is a forwarding paradigm that leverages source routing principles to steer packets along a predetermined path through a network. Instead of relying on complex routing protocols and their associated overhead, segment routing enables the network to be programmed with predetermined instructions, known as segments, to define the path packets should traverse. These segments can represent various network resources, such as links, nodes, or services, and are encoded in the packet’s header.

 

Highlights: Segment Routing

  • MPLS and BGP-free Core

So, what is segment routing? Firstly, before we start discussing a segment routing solution and the details of segment routing vs MPLS. Let us recap how MPLS works and the protocols used. MPLS environments have both control and data plane elements.

A BGP-free core operates at network edges, participating in full mesh or route reflection design. BGP is used to pass customer routes, Interior Gateway Protocol (IGP) to pass loopbacks, and Label Distribution Protocol (LDP) to label the loopback.

  • Labels and BGP next hops

LDP or RSVP establishes MPLS label-switched paths ( LSPs ) throughout the network domain. Labels are assigned to the BGP next hops on every router where the IGP in the core provides reachability for remote PE BGP next hops.

As you can see, several control plane elements interact to provide complete end-to-end reachability. Unfortunately, the control plane is performed hop-by-hop, creating a network state and the potential for synchronization problems between LDP and IGP.

 

Before you proceed, you may find the following post helpful:

  1. Observability vs Monitoring
  2. Network Traffic Engineering
  3. What Is VXLAN
  4. Technology Insight for Microsegmentation
  5. WAN SDN

 



What is Segment Routing

Key Segment Routing Discussion Points:


  • Introduction to Segment Routing and what is involved.

  • Highlighting the issues around synchronization problems.

  • Critical points on Segment Routing vs MPLS.

  • Technical details on Segment Routing segments

  • Technical details on Segment Routing adjacency. 

 

Back to basics with Segment Routing Solution

Keep complexity to edges.

2002 IETF published RFC: RFC 3439 – Some Internet Architectural Guideline and Philosophy. It states, “In short, the complexity of the Internet belongs at the edges, and the IP layer of the Internet should remain as simple as possible.” When applying this concept to traditional MPLS-based networks, we must bring additional network intelligence and enhanced decision-making to network edges. Segment Routing is a way to get intelligence to the edge and Software-Defined Networking (SDN) concepts to MPLS-based architectures.

 

  • A key point: Lab Guide on a BGP-free core.

Here we have a typically pre-MPLS setup. The main point is that the P node is only running OSPF. It does not know the CE routers or any other BGP routes. Then BGP runs across a GRE tunnel and to the CE nodes. The GRE tunnel we are running is point-to-point.

When we run a traceroute from CE1 to CE2, the packets traverse the GRE tunnel, and no P node interfaces are in the trace. The main goal here is to free up resources in the core, which is the starting point of MPLS networking. We will upgrade this to MPLS in the following lab guide below.

 

overlay networking

 

Source Packet Routing

Segment routing is a development of the Source Packet Routing in the Network (SPRING) working group of the IETF. The fundamental idea is the same as Service Function Chaining (SFC), but rather than assuming the processes along the path will manage the service chain; Segment Routing considers the routing control plane will handle the flow path through a network.

Segment routing (SR) is a source-based routing technique streamlining traffic engineering across network domains. It removes network state information from transit routers and nodes and puts the path state information into packet headers at an ingress node.

 

segment routing solution
Diagram: Issues with MPLS and the need for a segment routing solution.

 

Benefits of Segment Routing:

1. Simplified Network Operations: By decoupling the control plane from the forwarding plane, segment routing simplifies network operations and reduces the complexity of traditional routing protocols. Network operators can define explicit paths for specific traffic flows, eliminating the need for complex and dynamic routing algorithms.

2. Enhanced Scalability: Segment routing offers improved scalability by enabling network operators to leverage the existing routing infrastructure while avoiding the scalability issues associated with traditional routing protocols. By leveraging a distributed control plane and existing MPLS (Multi-Protocol Label Switching) infrastructure, segment routing allows for efficient forwarding of packets across large-scale networks.

3. Traffic Engineering Flexibility: With segment routing, network operators have fine-grained control over the path packets take through the network. This flexibility allows for efficient traffic engineering, enabling operators to optimize network resources, prioritize specific traffic flows, and adjust the path based on real-time network conditions.

MPLS Traffic Engineering

MPLS TE is an extension of MPLS, a protocol to route data packets across networks efficiently. It provides a mechanism for network operators to control and manipulate traffic flow, allowing them to allocate network resources effectively. MPLS TE utilizes a technique known as traffic engineering to optimize network paths and allocate bandwidth based on specific requirements.

It allows network operators to set up explicit paths for traffic, ensuring that critical applications receive the necessary resources and are not affected by congestion or network failures. MPLS TE achieves this by establishing Label Switched Paths (LSPs) that bypass potential bottlenecks and follow pre-determined routes, resulting in a more efficient and predictable network.

  • A Key Point: Lab Guide on MPLS TE

In this lab, we will look at MPLS TE with ISIS configuration. Routers PE1, P1, P2, P3, and PE2 are our MPLS core network. The CE1 and CE2 routers use regular IP routing. All routers are configured to use IS-IS L2. 

There are four main items we have to configure:

  • Enable MPLS TE support:
    • Globally
    • Interfaces
  • Configure IS-IS to support MPLS TE.
  • Configure RSVP.
  • Configure a tunnel interface.
MPLS TE
Diagram: MPLS TE

 

Synchronization Problems

Packet loss can occur in two scenarios when the actions of IGP and LDP are not synchronized. Firstly, when an IGP adjacency is established, the router begins to forward packets using the new adjacency before the actual LDP exchange occurs between peers on that link.

Secondly, when an LDP session terminates, the router forwards traffic using the existing LDP peer link. This issue is resolved by implementing network kludges and turning on auto-synchronization between IGP and LDP. Additional configurations are needed to get these two-control planes operating safely.

  

Solution – Segment Routing

Segment Routing is a new architecture built with SDN in mind. The idea of separating data and the control plane is all about network simplification. SDN is a great concept, and; now, we need to take this concept and integrate it into today’s networks. SDN concept of simplification is a driver for the introduction of Segment Routing.

 

Segment routing vs MPLS

Segment Routing utilizes the basics of MPLS but with fewer protocols, less-protocol interaction, and less state, and is applied to MPLS architecture with no change to the forwarding plane. Existing devices switching based on labels may only need a software upgrade. The virtual overlay network concept is based on source routing. Source chooses the path you take through the network. It steers a packet through an ordered list of instructions called segments.

Like MPLS, Segment Routing is based on label switching without LDP or RSVP. Labels are called segments, and we still have push, swap, and pop actions. You do not keep the state in the middle of the network, as the state is in the packet instead. In the packet header, you put a list of segments. A segment is an instruction – if you want to go to C, use A-B-C.

 

  • With Segment Routing, the Per-flow state is only maintained at the ingress node to the domain.

 

It is all about getting a flow concept, mapping it to a segment, and putting that segment on a true path. It keeps the properties of resilience ( fast reroute) but simplifies the approach with fewer protocols. As a result, it provides enhanced packet forwarding behavior while minimizing the need to maintain the network state.

 

  • A key point: Lab guide on MPLS forwarding.

The previous lab guide can easily be upgraded to MPLS. We removed the GRE tunnel and the iBGP neighbors. MPLS is enabled with the mpls ip command on all interfaces on the P node and the PE node interfaces facing the P node. Now we have MPLS forwarding based on labels while maintaining a BGP-free core. Notice how the two CEs can ping each other, and there is no route for 5.5.5.5 in the P node.

 

MPLS forwarding
Diagram: MPLS forwarding

 

Two types of initial segments are defined

Node and Adjacency

Nodel label: Nodel label is globally unique to each node. For example, a node labeled “Dest” has label 65 assigned to it, so any ingress network traffic with label 65 goes straight to Dest. By default, it will take the best path. Then we have the Adjacency label: a locally significant label that takes packets to an adjacent path. It forces packets through a specific link and offers more specific path forwarding than a nodel label.

segment routing vs mpls
Diagram: Segment routing vs MPLS and the use of labels.

 

Segment routing: A new business model

Segment Routing addresses current issues and brings a new business model. It aims to address the pain points of existing MPLS/IP networks in terms of simplicity, scale, and ease of operation. Preparing the network with an SDN approach allows application integration directly on top of it.

Segment Routing allows you to take certain traffic types and make a routing decision based on that traffic class. It permits you to bring traffic that you think is important such as Video or Voice, to go a different way than best efforts traffic.

Traffic paths can be programmed end-to-end for a specific class of customer. It moves away from the best-path model by looking at the network and deciding on the source. Very similar to MPLS, but you are using the labels differently.

 

SDN controller & network intelligence

Controller-based networks sit perfectly with this technology. It’s a very centralized and controller application methodology. The SDN controller gathers network telemetry information, decides based on a predefined policy, and pushes information to nodes to implement data path forwarding. Network intelligence such as link utilization, path response time, packet drops, latency, and jitter are extracted from the network and analyzed by the controller.

The intelligence now sits at the edges. The packet takes a path based on the network telemetry information extracted by the controller. The result is that the ingress node can push a label stack to the destination to take a specific path.

 

  • Your chosen path at the network’s edge is based on telemetry information.

 

Applications of Segment Routing:

1. Traffic Engineering and Load Balancing: Segment routing enables network operators to dynamically steer traffic along specific paths to optimize network resource utilization. This capability is handy in scenarios where certain links or nodes experience congestion, enabling network operators to balance the load and efficiently utilize available resources.

2. Service Chaining: Segment routing allows for the seamless insertion of network services, such as firewalls, load balancers, or WAN optimization appliances, into the packet’s path. By specifying the desired service segments, network operators can ensure traffic flows through the necessary services while maintaining optimal performance and security.

3. Network Slicing: With the advent of 5G and the proliferation of the Internet of Things (IoT) devices, segment routing can enable efficient network slicing. Network slicing allows for virtualized networks, each tailored to the specific requirements of different applications or user groups. Segment routing provides the flexibility to define and manage these virtualized networks, ensuring efficient resource allocation and isolation.

Conclusion:

Segment routing offers a promising solution to the challenges faced by modern network operators. Segment routing enables efficient and optimized utilization of network resources by providing simplified network operations, enhanced scalability, and traffic engineering flexibility. With its applications ranging from traffic engineering to service chaining and network slicing, segment routing is poised to play a crucial role in the evolution of modern networks. As the demand for more flexible and efficient networks grows, segment routing emerges as a powerful tool for network operators to meet these demands and deliver a seamless and reliable user experience.

 

WAN Virtualization

WAN Virtualization

 

 

WAN Virtualization

Organizations constantly seek innovative solutions in modern networking to enhance their network infrastructure and optimize connectivity. One such solution that has gained significant attention is WAN virtualization. In this blog post, we will delve into the concept of WAN virtualization, its benefits, and how it revolutionizes how businesses connect and communicate.

WAN virtualization, also known as Software-Defined WAN (SD-WAN), is a technology that enables organizations to abstract their wide area network (WAN) connections from the underlying physical infrastructure. It leverages software-defined networking (SDN) principles to decouple network control and data forwarding, providing a more flexible, scalable, and efficient network solution.

 

Highlights: WAN Virtualization

  • VPN and SDN Components

So, what is WAN virtualization? WAN virtualization is an essential technology in the modern business world. It creates virtualized versions of wide area networks (WANs) – networks spanning a wide geographic area. The virtualized WANs can then manage and secure a company’s data, applications, and services.

Regarding implementation, WAN virtualization requires using a virtual private network (VPN), a secure private network accessible only by authorized personnel. This ensures that only those with proper credentials can access the data. WAN virtualization also requires software-defined networking (SDN) to manage the network and its components.

 

Before you proceed, you may find the following posts helpful:

  1. SD WAN Overlay
  2. Generic Routing Encapsulation
  3. WAN Monitoring
  4. SD WAN Security 
  5. Container Based Virtualization
  6. SD WAN and Nuage Networks

 



WAN Virtualization

Key WAN Virtualization Discussion Points:


  • Introduction to WAN Virtualization and what is involved.

  • Highlighting the issues around internet traffic left to its defaults.

  • Critical points on WAN utilization problems.

  • Technical details on routing protocol convergence.

  • Technical details on SD WAN Overlay and how this changes the WAN.

 

Back to Basics: WAN virtualization.

WAN Challenges

Deploying and managing the Wide Area Network (WAN) has become more challenging. Engineers face several design challenges, such as traffic flow decentralizing, inefficient WAN link utilization, routing protocol convergence, and application performance issues with active-active WAN edge designs. Active-active WAN designs that spray and pray over multiple active links present technical and business challenges.

To do this efficiently, you have to understand application flows. There may also be performance problems. When packets get to the other end, there may be out-of-order packets as each one of the links propagates at different speeds. The remote end has to reassemble and put back together, causing jitter and delay. Both high jitter and delay are bad for network performance. To recap on WAN virtualization, including the drivers for SD-WAN, you may follow this SD WAN tutorial.

What is WAN Virtualization
Diagram: What is WAN virtualization? Source Linkedin.

 

SD-WAN vs. DMVPN

Two popular WAN solutions are DMVPN and SD-WAN.

DMVPN (Dynamic Multipoint Virtual Private Network) and SD-WAN (Software-Defined Wide Area Network) are popular solutions to improve connectivity between distributed branch offices. DMVPN is a Cisco-specific solution, and SD-WAN is a software-based solution that can be used with any router. Both solutions provide several advantages, but there are some differences between them.

DMVPN is a secure, cost-effective, and scalable network solution that combines underlying technologies and DMVVPN phases (for example, the traditional DMVPN phase 1 ) to connect multiple sites. It allows the customer to use existing infrastructure and provides easy deployment and management. This solution is an excellent choice for businesses with many branch offices because it allows for secure communication and the ability to deploy new sites quickly.

SD-WAN is a software-based solution that is gaining popularity in the enterprise market. It provides improved application performance, increased security, and improved network reliability. SD-WAN is a great choice for businesses that require high-performance applications across multiple sites. It provides an easy-to-use centralized management console that allows companies to deploy new sites and manage the network quickly.

 

 

Dynamic Multipoint VPN
Diagram: Example with DMVPN. Source is Cisco
  • A key point: Lab on DMVPN operating over the WAN

The following show DMVPN operating over the WAN. The SP node represents the WAN network. Then we have R11 as the hub and R2, R3 as the spokes.  The DMVPM network over the WAN is made possible with several protocols. We have GRE; in this case, the tunnel destination is specified as a point-to-point GRE tunnel instead of a mGRE tunnel.

Then we have NHRP that this used to help create a mapping as this is a nonbroadcast network; we can not use ARP. So, we need to manually set this up on the spokes with the command: ip nhrp NHS 192.168.100.11

DMVPN configuration
Diagram: DMVPN Configuration.

 

Shift from network-centric to business intent.

The core of WAN virtualization involves shifting focus from a network-centric model to a business intent-based WAN network. So instead of designing the WAN for the network, we can create the WAN for the application. This way, the WAN architecture can simplify application deployment and management.

First, however, the mindset must shift from a network topology focus to an application services topology. A new application style consumes vast bandwidth and is very susceptible to variations in bandwidth quality. Things such as jitter, loss, and delay impact most applications, which makes it essential to improve the WAN environment for these applications.

wan virtualization
Diagram: WAN virtualization.

 

The spray and pray method over two links increase bandwidth but decreases “goodput.” It also affects firewalls as they will see asymmetric routes. When you want an active-active model, you need application session awareness and a design that eliminates asymmetric routing. It would help if you could slice the WAN properly so application flows can work efficiently over either link.

 

What is WAN Virtualization: Decentralizing Traffic

Decentralizing traffic from the data center to the branch requires more bandwidth to the network’s edges. As a result, we see many high-bandwidth applications running on remote sites. This is what businesses are now trying to accomplish. Traditional branch sites usually rely on hub sites for most services and do not host bandwidth-intensive applications. Today, remote locations require extra bandwidth, which is not cheaper yearly.

 

Inefficient WAN utilization

Redundant WAN links usually require a dynamic routing protocol for traffic engineering and failover. Routing protocols require complex tuning to load balance traffic between border devices. Border Gateway Protocol (BGP) is the primary protocol for connecting sites to external networks.

It relies on path attributes to choose the best path based on availability and distance. Although these attributes allow granular policy control, they do not cover aspects relating to path performance, such as Round Trip Time (RTT), delay, and jitter.

Furthermore, BGP does not always choose the “best” path, while the “best” path may have different meanings for customers. For example, customer A might consider the path via provider A as the best due to the price of links. Default routing does not take this into account. Packet-level routing protocols are not designed to handle the complexities of running over multiple transport agnostic links. Therefore, a solution must arise that eliminates the need for packet-level routing protocols.

BGP Path Attributes
Diagram: BGP Path Attributes Source is Cisco.

 

Routing protocol convergence

WAN designs can also be active standby, which requires routing protocol convergence in the event of primary link failure. However, routing convergence is slow, and to speed up, additional features, such as Bidirectional Forwarding Detection (BFD), are implemented that may stress the network’s control plane. Although mechanisms exist to speed up convergence and failure detection, there are; still several convergence steps, such as:

Rouitng Convergence

Convergence


Detect


Describe


Switch 


Find

 

Branch office security

With traditional network solutions, branches connect back to the data center, with the data center typically providing Internet access. The application world has evolved, and branches directly consume applications such as Office 365 in the cloud. This drives a need for branches to access these services over the Internet without going to the data center for Internet access or security scrubbing.

Extending the security diameter into the branches should be possible without requiring onsite firewalls / IPS and other security paradigm changes. A solution must exist that allows you to extend your security domain to the branch sites without costly security appliances at each branch—essentially, building a dynamic security fabric.

 

WAN Virtualization

The solution to all these problems is SD-WAN ( software-defined WAN ). SD-WAN is a transport-independent overlay software-based networking deployment. It uses software and cloud-based technologies to simplify the delivery of WAN services to branch offices. Similar to Software Defined Networking (SDN), SD-WAN works by abstraction. It abstracts network hardware into a control plane with multiple data planes to make up one large WAN fabric.

 

 SD-WAN in a nutshell 

At a basic level, when we consider the Wide Area Network (WAN) environment, we connect data centers to several branch offices to deliver packets between those sites, supporting the transport of application transactions and services. SD-WAN platform allows you to pull Internet connectivity into those sites, becoming part of one large transport-independent WAN fabric.

SD-WAN monitors the paths and the application performance on each link (Internet, MPLS, LTE ) and chooses the best path based on performance.

There are many forms of Internet connectivity (cable, DSL, broadband, and Ethernet). They are quick to deploy at a fraction of the cost of private MPLS circuits. SD-WAN provides the benefit of using all these links and monitoring which is best for what applications.

Application performance is continuously monitored across all eligible paths-direct internet, internet VPN, and private WAN. It creates an active-active network and eliminates the need to use and maintain traditional routing protocols for active-standby setups—no reliance on the active-standby model and associated problems.

WAN virtualization
Diagram: WAN virtualization. Source is Juniper

 

SD-WAN simplifies WAN management

SD-WAN simplifies managing a wide area network by providing a centralized platform for managing and monitoring traffic across the network. This helps reduce the complexity of managing multiple networks, eliminating the need for manual configuration of each site. Instead, all of the sites are configured from a single management console.

SD-WAN also provides advanced security features such as encryption and firewalling, which can be configured to ensure that only authorized traffic is allowed access to the network. Additionally, SD-WAN can optimize network performance by automatically routing traffic over the most efficient paths.

what is wan virtualization

SD WAN Packet Steering

SD-WAN packet steering is a technology that efficiently routes packets across a wide area network (WAN). It is based on the concept of steering packets so that they can be delivered more quickly and reliably than traditional routing protocols. Packet steering is crucial to SD-WAN technology, allowing organizations to maximize their WAN connections.

SD-WAN packet steering works by analyzing packets sent across the WAN and looking for patterns or trends. Based on these patterns, the SD-WAN can dynamically route the packets to deliver them more quickly and reliably. This can be done in various ways, such as considering latency and packet loss or ensuring the packets are routed over the most reliable connections.

Spraying packets down both links can result in 20% drops or packet reordering. SD-WAN makes packets better utilized, no reorder, and better “goodput.” SD-WAN increases your buying power and results in buying lower bandwidth links and running them more efficiently. Over-provision is unnecessary as you are using the existing WAN bandwidth better.

 

Benefits of WAN Virtualization:

1. Enhanced Network Performance: WAN virtualization allows organizations to optimize network performance by intelligently routing traffic across multiple WAN links. Organizations can achieve improved application performance and reduced latency by dynamically selecting the most efficient path based on real-time network conditions.

2. Cost Savings: Traditional WAN solutions often require expensive dedicated circuits for each branch office. With WAN virtualization, organizations can leverage cost-effective internet connections, such as broadband or LTE, while ensuring secure and reliable connectivity. This flexibility in choosing connectivity options can significantly reduce operational costs.

3. Simplified Network Management: WAN virtualization provides centralized management and control of the entire network infrastructure. This simplifies network provisioning, configuration, and monitoring, reducing traditional WAN deployments’ complexity and administrative overhead.

4. Increased Scalability: WAN virtualization offers the scalability to accommodate evolving network requirements as organizations grow and expand their operations. It allows for the seamless integration of new branch offices and additional bandwidth without significant infrastructure changes.

5. Enhanced Security: With the rise in cybersecurity threats, network security is paramount. WAN virtualization enables organizations to implement robust security measures, such as encryption and firewall policies, across the entire network. This helps protect sensitive data and ensures compliance with industry regulations.

  • A final note on what is WAN virtualization

Server virtualization and automation in the data center are prevalent, but WANs are stalling in this space. It is the last bastion of hardware models that has complexity. Like hypervisors have transformed data centers, SD-WAN aims to change how WAN networks are built and managed. When server virtualization and hypervisor came along, we did not have to worry about the underlying hardware. Instead, provision a Virtual Machine (VM) and run an application of choice. Today’s WAN environment requires you to manage details of carrier infrastructure, routing protocols, and encryption. 

 

  • SD-WAN pulls all WAN resources together and slices up the WAN to match the applications on them.

 

The Role of WAN Virtualization in Digital Transformation:

In today’s digital era, where cloud-based applications and remote workforces are becoming the norm, WAN virtualization is critical in enabling digital transformation. It empowers organizations to embrace new technologies, such as cloud computing and unified communications, by providing secure and reliable connectivity to distributed resources.

Conclusion:

WAN virtualization is transforming how organizations connect and communicate in the digital age. By providing enhanced network performance, cost savings, simplified management, scalability, and improved security, it offers a compelling solution for businesses of all sizes. As the demand for agile and efficient network infrastructures continues to grow, WAN virtualization will undoubtedly remain at the forefront of network technology advancements, empowering organizations to unlock the full potential of their network connectivity.

 

Application Delivery Controllers

Application Delivery Network

 

Application Delivery Network

 

Application Delivery Network

In today’s fast-paced digital world, businesses rely heavily on applications to deliver services and engage customers. However, as the demand for seamless connectivity and optimal performance increases, so does the need for a robust and efficient infrastructure. This is where Application Delivery Networks (ADNs) come into play. In this blog post, we will explore the importance of ADNs and how they enhance the delivery of applications.

An Application Delivery Network is a suite of technologies designed to optimize applications’ performance, security, and availability across the internet. It bridges users and applications, ensuring data flows smoothly, securely, and efficiently.

 

Highlights: Application Delivery Network

Varying Applications

Compared to 15 years ago, applications exploded when load balancers first arrived. Content such as blogs, content sharing, wiki, shared calendars,s, and social media exist that load balancers ( ADC ) must now serve. A plethora of “chattier” protocols exist with different requirements. Every application has additional network requirements for the functions they provide.

And each application has different expectations for the service levels of the application itself. Slow networks and high server load mean you cannot efficiently run applications and web-based services. Data is slow to load, and productivity slips. Application delivery controllers ( ADC ) or load balancers can detect and adapt to changing network conditions for public, private, and hybrid cloud traffic patterns.

 

Before you proceed, you may find the following posts helpful:

  1. Stateful Inspection Firewall
  2. Application Delivery Architecture
  3. Load Balancer Scaling
  4. A10 Networks
  5. Stateless Network Functions
  6. Network Security Components
  7. WAN SDN

 

Back to basics with load balancing

Load balancing is distributing network traffic across a group of endpoints. In addition, load balancing is a solution to hardware and software performance. So, when you are faced with scaling user demand and maxing out the performance, you have two options: scale up or scale out. Scaling up, or vertical scaling, has physical computational limits and can be costly. Then scaling out (i.e., horizontal scaling) allows you to distribute the computational load across as many systems as necessary to handle the workload. When scaling out, a load balancer can help spread the workload.

The Benefits of Application Delivery Networks:

1. Enhanced Network Connectivity: ADNs utilize various techniques like load balancing, caching, and content optimization to deliver applications faster and improve user experience. Distributing traffic intelligently, ADNs ensure that no single server is overwhelmed, leading to faster response times and reduced latency.

2. Scalability: ADNs enable businesses to scale their applications effortlessly. With the ability to add or remove servers dynamically, ADNs accommodate high traffic demands without compromising performance. This scalability ensures businesses can handle sudden spikes in user activity or seasonal fluctuations without disruption.

3. Security: In an era of increasing cyber threats, ADNs provide robust security features to protect applications and data from unauthorized access, DDoS attacks, and other vulnerabilities. To safeguard critical assets, ADNs employ advanced security mechanisms such as SSL encryption, web application firewalls, and intrusion detection systems.

4. Global Load Balancing: With the expansion of businesses across different geographical regions, ADNs offer global load balancing capabilities. By strategically distributing traffic across multiple data centers, ADNs ensure that users are seamlessly connected to the nearest server, reducing latency and optimizing performance.

5. Improved Availability: ADNs employ techniques like health monitoring and failover mechanisms to ensure the high availability of applications. In a server failure, ADNs automatically redirect requests to healthy servers, minimizing downtime and improving overall reliability.

  • A key point: Lab on GLBP

GLBP is a Cisco proprietary routing protocol designed to provide load balancing and redundancy for IP traffic across multiple routers or gateways. It enhances the commonly used Hot Standby Router Protocol (HSRP). It is primarily used in enterprise networks to distribute traffic across multiple paths, ensuring optimal utilization of network resources. Notice below when we change the GLBP priority, the role of the device changes.

Gateway Load Balancer Protocol
Diagram: Gateway Load Balancer Protocol (GLBP)

 

Application Delivery Network and Network Control Points.

Application delivery controllers act as network control points to protect our networks. We use them to improve application service levels delivered across networks. Challenges for securing the data center range from preventing denial of service attacks from the network to application.

Also, how do you connect data centers to link on-premise to remote cloud services and support traffic bursts between both locations? When you look at the needs of the data center, the network is the control point, and nothing is more important than this control point. ADC allows you to insert control points and enforce policies at different points of the network.

Application delivery network
Diagram: Application delivery network.

 

Case Study: Citrix Netscaler

The Company was founded in 1998; the first product was launched in 2000. The first product was a simple Transmission Control Protocol (TCP) proxy. All it did was sat behind a load balancer, proxy TCP connections at layer 4, and offload them from backend servers. As the web developed, scalability issues were the load on the backend servers from servicing the increasing amount of TCP connections. So they wrote their own performance-orientated custom TCP stack.

They have a quick PCI architecture. No, interrupts. Netscaler has written the code with x86 architecture in mind. The way x86 is written is to have fast processors and slower dynamic random-access memory (DRAM). The processor should work on the local cache, but that does not work for how network traffic flows. Netscaler has a unique code that processes a packet while permitting entry to another packet. This gives them great latency statistics.

 

Application delivery network and TriScale technology

TriScale technology changes how the Application Delivery Controller (ADC) is provisioned and managed. It brings cloud agility to data centers. TriScale allows networks to scale up, out, and in via consolidation.

 

Scale-out: Clustering

For high availability (HA), Netscaler only has active / standby and clustering. They oppose active/active. Active/active deployments are not truly active. Most setups are accomplished by setting one application via one load balancer and another via a 2nd-load balancer. It does not give you any more capacity. You cannot oversubscribe if one fails. The other node has to take over and service additional load from the failed load balancer.

Netscaler skipped this and went straight to clustering. They can cluster up to 32, allowing a cloud of Netscaler. Clustering is a cloud of Netscaler. All are active, sharing states and configurations, so if one of your ADCs goes down, others can pick up transparently. All nodes know all information about sessions, and that information is shared.

 

Stateless vs. stateful

Netscaler offer-dynamic failover for long-lived protocols, like Structured Query Language (SQL) sessions and other streaming protocols. Different from when you are load-balancing Hypertext Transfer Protocol (HTTP). HTTP is a generic and stateless application-level protocol. No information is kept across requests; applications must remember the per-user state.

Every HTTP request is a valid standalone request per the protocol. No one knows or cares that much if you lose an HTTP request. Clients try again. High availability is generally not an issue for web traffic. With HTTP 2.0, the idea of sustaining the connection during failover means that the session never gets torn down and restarted. 

 

HTTP ( stateless ) lives on top of TCP ( stateful ). Transmission Control Protocol (TCP) is stateful in the sense that it maintains state in the form of TCP windows size (how much data endpoints can receive) and packet order ( packet receipts confirmation). TCP endpoints must remember what state the other is in. Stateless protocols can be built on top of the stateful protocol, and stateful protocols can be built on top of the stateless protocol.

Applications built on top of HTTP aren’t necessarily stateless. Applications implement state over HTTP. For example, a client requests data and is first authenticated before data transfer. This is common for websites requiring users to visit a login page before sending a message.

 

Scale-in: Multi-tenancy

In the enterprise, you can have network overlays ( such as VXLAN) that allow the virtualization of segments. We need network services like firewalls and load balancers to do the same thing. Netscaler offers a scale in service that allows a single platform to become multiple. Not a software partition; it’s a hardware partition.

100% of CPU, crypto, and network resource are all isolated. It enabled the management of individual instances without affecting others. If you experience a big traffic spike on one load balancer, it does not affect other cases of load balancing on that device.

Every application or application owner can have a dedicated ADC. This approach lets you meet the application requirement without worrying about contention or overrun from other application configurations. In addition, it enables you to run several independent Netscaler instances on a single 2RU appliance. Every application owner looks like they have a dedicated ADC, and from the network view, each application is running on its appliance.

Behind the scenes, Netscaler consolidated all this down to a single device. So, what Netscaler did was to get the MPX platform and add a load of VPX on it to create an SDX product. When you spin up the VPX on the SDX, you allocate isolated resources such as CPU and disk space.

 

Scale-up: pay as you grow

Scale-up is a software license key upgrade that increases performance. In addition, it offers customers much more flexibility. For example, if you buy an MPX, you are not locked into specific performance metrics of that box. With a license upgrade, you can double its throughput, packets per second, connections per second, and Secure Sockets Layer (SSL) transactions per second.

 

Netscaler and Software-defined networking (SDN)

When we usually talk about SDN, we talk about Layer 2 and 3 networks and what it takes to separate the control and data plane. The majority of SDN discussions are Layer 2 and Layer 3-centric conversations. However, layer 4 to Layer 7 solutions need to integrate into the SDN network. Netscaler is developing centralized control capabilities for integrating Layer 4 to Layer 7 solutions into SDN networks.

So, how can SDN directly benefit the application at Layer 7? As applications become more prominent, there must be ways to auto-deploy applications. Storage and computing have been automated for some time now. However, the network is more complex, so virtualization is harder. This is where SDN comes into play. SDN takes all the complexity away from managing networks.

Conclusion:

In an era where applications are businesses’ backbone, ensuring optimal performance, scalability, and security is crucial. Application Delivery Networks play a vital role in achieving these objectives. From enhancing performance and scalability to providing robust security and global load balancing, ADNs offer a comprehensive solution for businesses seeking to optimize application delivery. By leveraging ADNs, businesses can deliver seamless experiences to their users, gain a competitive edge, and drive growth in today’s digital landscape.

Application Delivery Controllers

hyperscale networking

Hyperscale Networking

 

 

Hyperscale Networking

In today’s digital age, where data is generated at an unprecedented rate, traditional networking infrastructures are struggling to keep up with the demand. Enter hyperscale networking, a revolutionary paradigm transforming how we build and manage networks. In this blog post, we will explore the concept of hyperscale networking, its benefits, and its impact on various industries.

Hyperscale networking refers to quickly and seamlessly scaling network infrastructure to accommodate massive amounts of data, traffic, and users. It is a distributed architecture that leverages cloud-based technologies and software-defined networking (SDN) principles to achieve unprecedented scalability, agility, and efficiency.

Throughout the last 5-years, data center innovation has come from companies such as Google, Facebook, Amazon, and Microsoft. These companies are referred to as hyper-scale players. The vision of Big Switch is to take hyperscale concepts developed by these companies and bring them to smaller data centers around the world in the version of hyperscale networking, enabling a hyperscale architecture.

 

Before you proceed, you may find the following helpful post for pre-information:

  1. Virtual Data Center Design
  2. ACI Networks
  3. Application Delivery Architecture
  4. ACI Cisco
  5. Data Center Design Guide

 



Hyperscale Networking

Key Hyperscale Architecture Discussion Points:


  • Introduction to hyperscale architecture and what is involved.

  • Highlighting the challenges of a standard chassis design.

  • Critical points on bare metal switches.

  • Technical details on the core and pod designs.

  • SDN controller architecture and distributed routing.

 

  • A key point: Video on Hyperscale computing

In the following video, we will address Hyperscale computing. In computing, hyperscale is the ability of an architecture to scale appropriately as increased demand is added to the system. Hyperscale is the ability to scale, for example, compute, memory, networking, and storage resources appropriately to demand to facilitate distributed computing environments.

They employ a disaggregated architectural approach, scaling to over 50,000 servers, often seen in cloud computing and big data environments. Hyperscale architecture is the secret sauce for Facebook and Google. It allowed them to respond efficiently to massively complex workloads while lowering costs.

 

Technology Brief : Cloud Computing - Introducing Hypercomputing
Prev 1 of 1 Next
Prev 1 of 1 Next

 

Back to basic with OpenFlow

With OpenFlow, the switching device has no control plane, as the controller interacts directly with the FIB. Instead, OpenFlow provides a packet format and protocol to carry these packets that now describes forwarding table entries in the FIB. In OpenFlow documentation, the FIB is referred to as the flow table, as it contains information about each flow the switch needs to know about.

Critical Benefits of Hyperscale Networking:

1. Scalability: Hyperscale networking allows organizations to scale their networks effortlessly as demand grows. With traditional networking, scaling often involves costly hardware upgrades and complex configurations. In contrast, hyperscale networks can scale horizontally by adding more commodity hardware, resulting in significantly lower costs and simplified network management.

2. Agility: In the fast-paced digital landscape, businesses must adapt quickly to changing requirements. Hyperscale networking enables organizations to deploy and provision network resources on demand, reducing time-to-market for new services and applications. This agility empowers businesses to respond rapidly to customer demands and gain a competitive edge.

3. Enhanced Performance: Hyperscale networks are designed to handle massive data and traffic efficiently. By distributing workloads across multiple nodes, these networks can deliver superior performance, low latency, and high throughput. This translates into a seamless user experience and improved productivity for businesses.

4. Cost Efficiency: Traditional networking often involves significant upfront investments in proprietary hardware and complex infrastructure—hyperscale networking leverages off-the-shelf hardware and cloud-based technologies, resulting in cost savings and reduced operational expenses. Moreover, the ability to scale horizontally eliminates the need for expensive equipment upgrades.

Hyperscale Networking in Various Industries:

1. Cloud Computing: Hyperscale networking is the backbone of cloud computing platforms. It enables cloud service providers to deliver scalable and reliable services to millions of users worldwide. By leveraging hyperscale architectures, these providers can efficiently manage massive workloads and deliver high-performance cloud services.

2. Internet of Things (IoT): The proliferation of IoT devices generates enormous amounts of data that must be processed and analyzed in real time. Hyperscale networking provides the infrastructure to handle the massive data influx from IoT devices, ensuring seamless connectivity, efficient data processing, and rapid insights.

3. E-commerce: The e-commerce industry heavily relies on hyperscale networking to handle the ever-increasing number of online transactions, user interactions, and inventory management. With hyperscale networks, e-commerce platforms can ensure fast and secure transactions, reliable inventory management, and personalized user experiences.

 

Hyperscale Architecture

Hyperscale networking consists of three things. The first element is bare metal and open switch hardware. Bare metal switches are sold without software, making up 10% of all ports shipped. The second hyperscale aspect is Software Defined Networking (SDN). In SDN vision, you have one device acting as a controller, which manages the physical and virtual infrastructure.

The third element is the actual data architecture—Big Switch leverages what’s known as the Core-and-Pod design. Core-and-Pod differs from the traditional core, aggregation, and edge model, allowing incredible scale and automation when deploying applications.

 

hyperscale networking
Diagram: Hyperscale Networking

 

Standard Chassis Design vs. SDN Design

Standard chassis-based switches have supervisors, line cards, and fabric backplanes. In addition, a proprietary protocol runs between the blades for controls. Big Switch has all of these components but is named differently. Under the covers, the supervisor module acts like an SDN controller, programming the line cards and fabric backplane.

Instead of supervisors, they have a controller, and the internal chassis proprietary protocol is OpenFlow. The leaf switches are treated like line cards, and the spine switches are like the fabric backplane. In addition, they offer an OpenFlow-integrated architecture.

Hyperscale architecture
Diagram: Hyperscale architecture

 

Traditional data center topologies operate on hierarchical tree architecture. The big switch follows a new networking architecture called spine leaf architecture, which overcomes the shortcomings of conventional tree architectures. To map the leaf and spine to traditional data center terminology, the leaf is accessed, and the spine is a core switch.

In addition, the leaf and spine operate on the concept that every leaf has equidistant endpoints. Designs with equidistant endpoints make POD placement and service insertion easier than hierarchical tree architecture.

Big Switch hyperscale architecture has multiple connection points. Similar to Equal Cost Multipath (ECMP) fabric and Multi-Chassis Link Aggregation (MLAG), enabling layer 2 and layer 3 multipathing. This type of connectivity allows you to have network partition problems without having a global effect. You still lose your spin switch’s capacity but have not lost connectivity. The controller controls all this and has a central view.

 

  • Losing a leaf switch in a leaf and spine architecture is not a big deal as long as you have configured multiple paths.

Bare metal switches

The first hyperscale design principle is to utilize bare metal switches. Bare metal switches are Ethernet switches sold without software. Disaggregating the hardware from the switches software allows you to build your switch software stack. Cheaper in terms of CAPEX and allows you to better tune the operating system to what you need. It gives you the ability to tailor the operations to specific requirements.

 

Core and pod design

Traditional core-agg-edge is a monolithic design that cannot evolve. Hyperscale companies are now designing to a core-and-pod design, allowing operations to improve faster. Data centers are usually made up of two core components. One is the core with the Layer 3 routes for ingress and egress routing. Then, you have a POD, a self-contained unit connected to the core.

Intra-communication between PODs is done via core. A POD is a certified design of servers, storage, and network. They are all grouped into standard services. Each POD contains an atomic networking, computing, and storage unit attached directly to the core via Layer 2 or Layer 3. Due to a PODs-fixed configuration, automation is simple and stable.

 

Hyperscale Networking and Big Switch Products

Big Tap and Big Cloud Fabric are two-product streams from Big Switch. Both use a fabric architecture built on white box switches with a centralized controller and POD design. Big clouds hyperscale architecture is designed to be a network for a POD.

Each Big Cloud architecture instance is a pair of redundant SDN controllers, and a leaf/spine topology is the network for your POD. Switches have zero-touch, so they are stateless, turn them on, and it boots and downloads the switch image and configuration. It auto-discovers all of the links and troubleshoots any physical problems.

 

OpenFlow

 

 

SDN controller architecture

There are generic architectural challenges of SDN controller-based networks. The first crucial question is, where are the controller and network devices split? In OpenFlow, it’s clear that the split is between the control plane and the data plane. The split affects the outcomes from various events, such as a controller bug, controller failure, network partitions, and the size of the failure domain.

You might have an SDN controller cluster, but every single controller is; still a single point of failure. The controller cluster protects you from hardware failures but not from software failures. If someone misconfigures or corrupts the controller database, you lose the controller regardless of how many controllers are in a cluster.

Every controller is a single fat fingers domain. Due to the complexity of clusters and clustering protocols, you could implement failures by the lousy design. Every distributed system is complex, and it is even more challenging if it has to work with real-time data.

 

SDN Controllers

 

 

SDN controller – Availability Zones

The optimum design is to build controllers per availability zones. If one controller fails, you lose that side of the fabric but still have another fabric. You must-have applications that can run in multiple availability zones to use this concept. Availability zones are great, but applications must be adequately designed to use them. Availability zones usually relate to a single failure domain.

How do you deal with failures, and what failure rate is acceptable? The failure rate acceptance level drives the redundancy in your network. Full redundancy is a great design goal as it reduces the probability of total network failure. But full redundancy will never give you 100% availability. Network partitions still happen with fully redundant networks.

Be careful of split-brain scenarios when you have one controller looking after one partition and another looking after the other partitions. The way Big Switch overcomes time is with a distributed control plane. The forwarding elements are aligned so a network partition can happen.

 

Hyperscale Architecture: Big Switch distributed routing.

For routing, they have the concept known as a tenant router. With the tenant router, you can say that these two-broadcast domains can talk to each other via policy points. A tenant router is a logical router physically distributed throughout the entire network. Every switch has a copy of the tenant routers routing table local to it. The routing state is spread everywhere. No specific layer 3 points that traffic needs to cross to get from one layer 2 segment to the other.

As all the leaf switches have a distributed copy of the database, all routing takes the most optimal path. When two-broadcast domains are on the same leaf switch, traffic does not have to hairpin to a physical layer 3 points.

You can map the application directly to the tenant router, which acts like a VRF with VRF packet forwarding hardware. This is known as micro-segmentation. With this, you can put a set of applications or VM in a tenant, demarc the network by the tenant, and have per tenant policy.

Conclusion:

Hyperscale networking is revolutionizing how we build and manage networks in the digital era. Its ability to scale effortlessly, provide agility, enhance performance, and reduce costs makes it a game-changer in various industries. As data volumes grow, organizations must embrace hyperscale networking to stay competitive, deliver exceptional user experiences, and drive innovation in a rapidly evolving digital landscape.

 

wan-sdn

WAN SDN

 

Software defined networking

 

WAN SDN

In today’s fast-paced digital world, organizations constantly seek ways to optimize their network infrastructure for improved performance, scalability, and cost efficiency. One emerging technology that has gained significant traction is WAN Software-Defined Networking (SDN). By decoupling the control and data planes, WAN SDN provides organizations unprecedented flexibility, agility, and control over their wide area networks (WANs). In this blog post, we will delve into the world of WAN SDN, exploring its key benefits, implementation considerations, and real-world use cases.

WAN SDN is a network architecture that allows organizations to manage and control their wide area networks using software centrally. Traditionally, WANs have been complex and time-consuming to configure, often requiring manual network provisioning and management intervention. However, with WAN SDN, network administrators can automate these tasks through a centralized controller, simplifying network operations and reducing human errors.

 

Highlights: WAN SDN

  • SDN and APIs

WAN SDN is a modern approach to network management that uses a centralized control model to manage, configure, and monitor large and complex networks. It allows network administrators to use software to configure, monitor, and manage network elements from a single, centralized system. This enables the network to be managed more efficiently and cost-effectively than traditional networks.

SDN uses an application programming interface (API) to abstract the underlying physical network infrastructure, allowing for more agile network control and easier management. It also enables network administrators to rapidly configure and deploy services from a centralized location. This enables network administrators to respond quickly to changes in traffic patterns or network conditions, allowing for more efficient use of resources.

  • Scalability and Automation

SDN also allows for improved scalability and automation. Network administrators can quickly scale up or down the network by leveraging automated scripts depending on its current needs. Automation also enables the network to be maintained more quickly and efficiently, saving time and resources.

 

Before you proceed, you may find the following posts helpful:

  1. WAN Virtualization
  2. Software Defined Perimeter Solutions
  3. What is OpenFlow
  4. SD WAN Tutorial
  5. What Does SDN Mean
  6. Data Center Site Selection

 



SDN Internet

Key WAN SDN Discussion Points:


  • Introduction to WAN SDN and what is involved.

  • Highlighting the challenges of a traditional WAN design.

  • Critical points on the rise of WAN SDN.

  • Technical details Internet measurements.

  • The LISP protocol.

 

Back to Basics with WAN SDN

A Deterministic Solution

Technology typically starts as a highly engineered, expensive, deterministic solution. As the marketplace evolves and competition rises, the need for a non-deterministic, inexpensive solution comes into play. We see this throughout history. First, mainframes were/are expensive, and with the arrival of a microprocessor personal computer, the client/server model was born. The Static RAM ( SRAM ) technology was replaced with cheaper Dynamic RAM ( DRAM ). These patterns consistently apply to all areas of technology.

Finally, deterministic and costly technology is replaced with intelligent technology-using redundancy and optimization techniques. This process is now appearing in Wide Area Networks (WAN). Now, we are witnessing changes to routing space with the incorporation of Software Defined Networking (SDN) and BGP (Border Gateway Protocol). By combining these two technologies, companies can now perform  intelligent routing, aka SD-WAN path selection, with an SD WAN Overlay

 

  • A key point: SD-WAN Path Selection

SD-WAN path selection is essential to a Software-Defined Wide Area Network (SD-WAN) architecture. SD-WAN path selection selects the most optimal network path for a given application or user. This process is automated and based on user-defined criteria, such as latency, jitter, cost, availability, and security. As a result, SD-WAN can ensure that applications and users experience the best possible performance by making intelligent decisions on which network path to use.

When selecting the best path for a given application or user, SD-WAN looks at the quality of the connection and the available bandwidth. It then looks at the cost associated with each path. Cost can be a significant factor when selecting a path, especially for large enterprises or organizations with multiple sites.

SD-WAN can also prioritize certain types of traffic over others. This is done by assigning different weights or priorities for different kinds of traffic. For example, an organization may prioritize voice traffic over other types of traffic. This ensures that voice traffic has the best possible chance of completing its journey without interruption.

SD WAN traffic steering
Diagram: SD WAN traffic steering. Source Cisco.

 

 

  • Back to basics with DMVPN

Wide Area Network (WAN) DMVPN (Dynamic Multipoint Virtual Private Network) is a type of Virtual Private Network (VPN) that uses an underlying public network, such as the Internet, to transport data between remote sites. It provides a secure, encrypted connection between two or more private networks, allowing them to communicate over the public network without establishing a dedicated physical connection.

 

Critical Benefits of WAN SDN:

Enhanced Network Flexibility:

WAN SDN enables organizations to adapt their network infrastructure to meet changing business requirements dynamically. Network administrators can quickly respond to network demands through programmable policies and automated provisioning, ensuring optimal performance and resource allocation.

Improved Network Agility:

By separating the control and data planes, WAN SDN allows for faster decision-making and network reconfiguration. This agility enables organizations to rapidly deploy new services, adjust network traffic flows, and optimize bandwidth utilization, ultimately enhancing overall network performance.

Cost Efficiency:

WAN SDN eliminates manual configuration and reduces the complexity associated with traditional network management approaches. This streamlined network management saves cost through reduced operational expenses, improved resource utilization, and increased network efficiency.

Critical Considerations for Implementation:

Network Security:

When adopting WAN SDN, organizations must consider the potential security risks associated with software-defined networks. Robust security measures, including authentication, encryption, and access controls, should be implemented to protect against unauthorized access and potential vulnerabilities.

Staff Training and Expertise:

Implementing WAN SDN requires skilled network administrators proficient in configuring and managing the software-defined network infrastructure. Organizations must train and upskill their IT teams to ensure successful implementation and ongoing management.

Real-World Use Cases:

Multi-Site Connectivity:

WAN SDN enables organizations with multiple geographically dispersed locations to connect their sites seamlessly. Administrators can prioritize traffic, optimize bandwidth utilization, and ensure consistent network performance across all locations by centrally controlling the network.

Cloud Connectivity:

With the increasing adoption of cloud services, WAN SDN allows organizations to connect their data centers to public and private clouds securely and efficiently. This facilitates smooth data transfers, supports workload mobility, and enhances cloud performance.

Disaster Recovery:

WAN SDN simplifies disaster recovery planning by allowing organizations to reroute network traffic during a network failure dynamically. This ensures business continuity and minimizes downtime, as the network can automatically adapt to changing conditions and reroute traffic through alternative paths.

 

The Rise of WAN SDN

The foundation for business and cloud services are crucial elements of business operations. The transport network used for these services is best efforts, weak, and offers no guarantee of an acceptable delay. More services are being brought to the Internet, yet the Internet is managed inefficiently and cheaply.

Every Autonomous System (AS) acts independently, and there is a price war between transit providers, leading to poor quality of transit services. Operating over this flawed network, customers must find ways to guarantee applications receive the expected level of quality.

Border Gateway Protocol (BGP), the Internet’s glue, has several path selection flaws. The main drawback of BGP is the routing paradigm relating to the path-selection process. BGP default path selection is based on Autonomous System (AS) Path length; prefer the path with the shortest AS_PATH. It misses the shape of the network with its current path selection process. It does not care if propagation delay, packet loss, or link congestion exists. It resulted in long path selection and utilizing paths potentially experiencing packet loss.

 

WAN SDN with Border6 

Border6 is a French company that started in 2012. It offers a Non-Stop Internet, an integrated WAN SDN solution influencing BGP to perform optimum routing. It’s not a replacement for BGP but a complementary tool to enhance routing decisions. For example, it automates changes in routing in cases of link congestion/blackouts.

“The agile way of improving BGP paths by the Border 6 tool improves network stability” Brandon Wade, iCastCenter Owner.

Customers wanted to bring additional intelligence to routing as the Internet became more popular. Additionally, businesses require SDN traffic optimizations as many run their entire service offerings on top of it.

 

What is non-stop internet?

Border6 offers an integrated WAN SDN solution with BGP that adds intelligence to outbound routing. A common approach when designing SDN in real-world networks is to prefer that SDN solutions incorporate existing field testing mechanisms (BGP) and not reinvent all the wheels ever invented. Therefore, the border6 approach to influence BGP with SDN is a welcomed and less risky approach to implementing a greenfield startup. In addition, Microsoft and Viptela also use the SDN solution to control the behavior of BGP.

Border6 takes BGP as a sort of guidance of what might be reachable. Based on various performance metrics, they measure how well paths perform. They use BGP to learn the structure of the Internet and then run their algorithms to know what is essential for individual customers. Every customer has different needs to reach different subnets. Some prefer costs; others prefer performance.

They elect several interesting “best” performing prefixes, and the most critical prefixes are selected. Next, they find probing locations and measure the source with automatic probes; to determine the best path. All these tools combined enhance the behavior of BGP. Their mechanism can detect if ISP has hardware/software problems, drops packets, or rerouting packets worldwide. 

 

Thousands of tests per minute

The Solution offers the best path by executing thousands of tests per minute and enabling results to include the best paths for packet delivery. Outputs from the live probing of path delays and packet loss inform BGP on which path to route traffic. The “best path” is different for each customer. It depends on the routing policy the customer wants to take. Some customers prefer paths without packet loss; others want cheap costs or paths under 100ms. It comes down to customer requirements and the applications they serve.

 

BGP – Unrelated to Performance

Traditionally, BGP is getting its information to make decisions based on data unrelated to performance. Broder 6 tries to correlate your packet’s path to the Internet by choosing the fastest or cheapest link, depending on requirements.

They are taking BGP data service providers are sending them as a baseline. Based on that broad connectivity picture, they have their measurements – lowest latency, packets lost, etc.- and adjust the data from BGP to consider these other measures. They were, eventually, performing optimum packet traffic forwarding. They first look at Netflow or Sflow data to determine what is essential and use their tool to collect and aggregate the data. From this data, they know what destinations are critical to that customer.

 

BGP for outbound | Locator/ID Separation Protocol (LISP) for inbound

Border6 products relate to outbound traffic optimizations. It can be hard to influence inbound traffic optimization with BGP. Most AS behave selfishly and optimize the traffic in their interest. They are trying to provide tools that help AS optimize inbound flows by integrating their product set with Locator/ID Separation Protocol (LISP). The diagram below displays generic LISP components. It’s not necessarily related to Border6 LISP design.

LISP decouples the address space so you can optimize inbound traffic flows. Many LISP uses cases are seen with active-active data centers and VM mobility. It decouples the “who” and the “where,” which allows end-host addressing not to correlate with the actual host location. The drawback is that LISP requires endpoints that can build LISP tunnels.

Currently, they are trying to provide a solution using LISP as a signaling protocol between Border6 devices. They are also working on performing statistical analysis for data received to mitigate potential denial-of-service (DDoS) events. More DDoS algorithms are coming in future releases.

 

Conclusion:

WAN SDN is revolutionizing how organizations manage and control their wide area networks. WAN SDN enables organizations to optimize their network infrastructure to meet evolving business needs by providing enhanced flexibility, agility, and cost efficiency.

However, successful implementation requires careful consideration of network security, staff training, and expertise. With real-world use cases ranging from multi-site connectivity to disaster recovery, WAN SDN holds immense potential for organizations seeking to transform their network connectivity and unlock new opportunities in the digital era.

 

Software defined networking

 

viptela1

Viptela Software Defined WAN (SD-WAN)

 

viptela sd wan

Viptela SD WAN

Why can’t enterprise networks scale like the Internet? What if you could virtualize the entire network?

Wide Area Network (WAN) connectivity models follow a hybrid approach, and companies may have multiple types – MPLS and the Internet. For example, branch A has remote access over the Internet, while branch B employs private MPLS connectivity. Internet and MPLS have distinct connectivity models, and different types of overlay exist for the Internet and MPLS-based networks.

The challenge is to combine these overlays automatically and provide a transport-agnostic overlay network. The data consumption model in enterprises is shifting. Around 70% of data is; now Internet-bound, and it is expensive to trombone traffic from defined DMZ points. Customers are looking for topological flexibility, causing a shift in security parameters. Topological flexibility forces us to rethink WAN solutions for tomorrow’s networks and leads towards Viptela SD-WAN.

 

Before you proceed, you may find the following helpful:

  1. SD WAN Tutorial
  2. SD WAN Overlay
  3. SD WAN Security 
  4. WAN Virtualization
  5. SD-WAN Segmentation

 

Solution: Viptela SD WAN

Viptela created a new overlay network called Secure Extensible Network (SEN) to address these challenges. For the first time, encryption is built into the solution. Security and routing are combined into one solution. Enables you to span environments, anywhere-to-anywhere in a secure deployment. This type of architecture is not possible with today’s traditional networking methods.

Founded in 2012, Viptela is a Virtual Private Network (VPN) company utilizing concepts of Software Defined Networking (SDN) to transform end-to-end network infrastructure. Based in San Jose, they are developing an SDN Wide Area Network (WAN) product offering any-to-any connectivity with features such as application-aware routing, service chaining, virtual Demilitarized Zone (DMZ), and weighted Equal Cost Multipath (ECMP) operating on different transports.

The key benefit of Viptela is any-to-any connectivity product offering. Connectivity was previously found in Multiprotocol Label Switching (MPLS) networks. They purely work on the connectivity model and not security frameworks. They can, however, influence-traffic paths to and from security services.

Viptela sd wan

 

Ubiquitous data plane

MPLS was attractive because it had a single control plane and a ubiquitous data plane. As long as you are in the MPLS network, connection to anyone is possible. Granted, you have the correct Route Distinguisher (RD) and Route Target (RT) configurations. But why can’t you take this model to Wide Area Network? Invent a technology that can create a similar model and offer ubiquitous connectivity regardless of transport type ( Internet, MPLS ).

 

Why Viptela SDN WAN?

The business today wants different types of connectivity modules. When you map service to business logic, the network/service topology is already laid out. It’s defined. Services have to follow this topology. Viptela is changing this concept by altering the data and control plane connectivity model using SDN to create an SDN WAN technology.

SDN is all about taking intensive network algorithms out of the hardware. Previously, in traditional networks, this was in individual hardware devices using control plane points in the data path. As a result, control points may become congested (for example – OSPF max neighbors reached). Customers lose capacity on the control plane front but not on the data plane. SDN is moving the intensive computation to off-the-shelf servers. MPLS networks attempt to use the same concepts with Route-Reflector (RR) designs.

They started to move route reflectors off the data plane to compute the best-path algorithms. Route reflectors can be positioned anywhere in the network and do not have to sit on the data path. Controller-based SDN approach, you are not embedding the control plane in the network. The controller is off the path. Now, you can scale out and SDN frameworks centrally provision and push policy down to the data plane.

Viptela can take any circuit and provide the ubiquitous connectivity MPLS provided, but now, it’s based on a policy with a central controller. Remote sites can have random transport methods. One leg could be the Internet, and the other could be MPLS. As long as there is an IP path between endpoint A and the controller, Viptela can provide the ubiquitous data plane.

 

Viptela SD WAN and Secure Extensible Network (SEN)

Managed overlay network

If you look at the existing WAN, it is two-part: routing and security. Routing connects sites, and security secures transmission. We have too many network security and policy configuration points in the current model. SEN allows you to centralize control plane security and routing, resulting in data path fluidity. The controller takes care of routing and security decisions.

It passes the relevant information between endpoints. Endpoints can pop up anywhere in the network. All they have to do is set up a control channel for the central controller. This approach does not build excessive control channels, as the control channel is between the controller and endpoints. Not from endpoint to endpoint. The data plane can flow based on the policy in the center of the network.

Viptela SD WAN

 

Viptela SD WAN: Deployment considerations

Deployment of separate data plane nodes at the customer site is integrated into existing infrastructure at Layer 2 or 3. So you can deploy incrementally, starting with one node and ending with thousands. It is so scalable because it is based on routed technology. The model allows you to deploy, for example, a guest network and then integrate it further into your network over time. Internally they use Border Gateway Protocol (BGP). One the data plane, they use standard IPSec between endpoints. It also works over Network Address Translation (NAT), meaning IPSec over UDP.

When an attacker gets access to your network, it is easy for them to reach the beachhead and hop from one segment to another. Viptela enables per-segment encryption, so even if they get to one segment, they will not be able to jump to another. Key management on a global scale has always been a challenge. Viptela solves this with a propitiatory distributed manager based on a priority system. Currently, their key management solution is not open to the industry.

 

SDN controller

You have a controller and VPN termination points i.e data plane points. The controller is the central management piece that assigns the policy. Data points are modules that are shipped to customer sites. The controller allows you to dictate different topologies for individual endpoint segments. Similar to how you influence-routing tables with RT in MPLS.

The control plane is at the controller.

 

Data plane module

Data plane modules are located at the customer site. They connect this data plane module, which could be a PE hand-off to the internal side of the network. The data plane module must be in the data plane path on the customer site. Internal side, they discover the routing protocols and participate in prefix learning. At Layer 2, they discover the VLANs. Their module can either be the default gateway or perform the router neighbor relationship function. WAN side, data plane module registers uplink IP address to WAN controller/orchestration system. The controller builds encrypted tunnels between the data endpoints. The encrypted control channels are only needed when you build over untrusted third parties.

If the problem occurs with controller connectivity, the on-site module can stop being the default gateway and usually participate in Layer 3 forwarding for existing protocols. It backs off from being the primary router for off-net traffic. It’s like creating VRF for different businesses and default routes for each VRF with a single peering point to the controller; Policy-Based Routing (PBR) for each VRF for data plane activity. The PBR is based on information coming from the controller. Each control segment can have a separate policy (for example – modifying the next hop). From a configuration point of view, you need an IP on the data plane module and the remote controller IP. The controller pushes down the rest.

 

  • Viptela SD WAN: Use cases

For example, you have a branch office with three distinct segments, and you want each endpoint to have its independent topology. The topology should be service driven, and the service should not follow existing defined topology. Each business should depict how they want their business to connect to the network team should not say this is how the topology is, and you must obey our topology.

From a carrier’s perspective, they can expand their MPLS network to areas they do not have a physical presence. And bring customers with this secure overlay to their closest pop where they have an MPLS peering. MPLS providers can expand their footprint to areas where they do not have service. If MPLS has customers in region X and wants to connect to the customer in region Y, they can use Viptela. Having those different data plane endpoints through a security framework would be best before entering the MPLS network.

Viptela allows you to steer traffic based on the SLA requirements of the application, aka Application-Aware Routing. For example, if you have two sites with dual connectivity to MPLS and Internet, data plane modules (located at customer sites) nodes can steer traffic over either the MPLS or Internet transport based on end-to-end latency or drops. They do this by maintaining the real-time loss, latency, and jitter characteristics and then applying policies on the centralized controller. As a result, critical traffic is always steered to the most reliable link. This architecture can scale to 1000 nodes in a full mesh topology.

 

viptela sd wan