Demystifying Software-defined Networks Part III: SDN via Overlays

SDN is no longer ‘the next big thing’ on the networking horizon, but a reality and inevitability for enterprises and service providers. IDC estimates the SDN market has grown from a $406 million industry in 2013 to more than a $6.6 billion market in 2017, and predicts it will continue to grow at a 25.4% compound annual growth rate to $13.8 billion by 2021[1].

This proliferating nature of SDN deployments is the catalyst for my writing a blog series to ‘demystify’ its architectural approach to making network technology agile and flexible as the virtualized server and storage infrastructure of the modern data center.

In Demystifying Software Defined Networking Part I and Part II, I reviewed:

The basics of SDN and how networking is evolving

The separation between the control plane and the data plane

The three main types of SDN: Open SDN, SDN by APIs and SDN via Overlays

The principles of the first approach, Open SDN, as well as the principles of the second approach, SDN by APIs

In this post I’ll describe the principles of the technology by overlays, a method used by software and networking giants like VMware, Cisco and Juniper Networks. I will also discuss the pros and cons of SDN via Overlay deployments.

So, what’s in an overlay network?

A simple definition is a network built on top of another network, as shown in Figure 1. This concept of overlays is not something new. We have been universally using overlay networks prior to the creation of the Internet.

What makes the overlay networks concept unique, compared to the other two approaches I’ve discussed, is that the current physical network is left untouched with networking devices and their configurations unchanged. On top of that network, SDN hypervisor-based networks are created; an ideal scenario for an enterprise/carrier that doesn’t want to incur major hardware expenses.

Note: a network hypervisor is a piece of software that provides an abstraction layer for network hardware, allowing network engineers to create virtual networks that are completely decoupled and independent from the underlying physical network (see Figures 2 and 3).

Figure 2: Overlay Networks and Physical Network

The beauty of this SDN technology is that the virtual network traffic runs above the physical network infrastructure, hypervisors inject traffic into the overlay network, and receive traffic from it. The network traffic of the overlay networks is passed through physical devices, at the end points, but the endpoints are completely unaware of the details of the physical topology, as well as the routing thought process or any other kind of advanced or basic network functions.

What mechanism makes all of this possible, you ask?

Network encapsulation – the inclusion of one data structure within another structure where the first data structure is hidden for the time being.

Figure 3: Network Encapsulation

Virtual Tunnel Endpoint (VTEP)

When a packet enters the edge of the virtual network at the source, the networking device (usually the hypervisor) will take the packet in its entirety and encapsulate it within another frame. This edge of the virtual network is called a virtual tunnel endpoint or VTEP. The Network hypervisor then takes this encapsulated packet and based on information programmed by the controller, sends it to the destination’s VTEP. This VTEP decapsulates the packet and forwards it to the destination host and then the encapsulated packet is sent across the physical infrastructure. The IP addresses are those of the source and destination VTEP.

This process is also known as MAC in IP tunneling because the entire MAC frame is encapsulated.

Different vendors have developed different technologies to archive this process with different pros and cons, but the underlaying idea is the same. (VMware and Cisco use VXLAN, but Microsoft prefers NVGRE.)

Examples of SDN via Overlays:

There are two major products for this type of SDN implementation.

Juniper Networks

Juniper launched the SDN controller Contrail using NETCONF and XMPP protocols instead of OpenFlow. Confusing for some is that Contrail released the code of Contrail and Open Contrail with varying technical Support levels provided by the company.

But let’s not confuse Open Source with Open SDN as defined in Demystifying Software Defined Networking I. Keep in mind that the southbound API of Contrail is XMPP and indeed a standards-based approach. Since the control plane still resides on those virtual switches and XMPP is not directly programming the data plane, I would not consider it Open SDN, but an SDN via hypervisor-based overlays approach.

Prior to Nicira’s acquisition by VMware in 2012, Nicira’s Network Virtualization Platform (NVP) was a very popular SDN via hypervisor-based overlays offering in the market.

Since the acquisition, NVP is now bundled with VMware’s vCloud Network and Security (vCNS) and is marketed as VMware NSX where it continues to enjoy considerable market success, according to Gartner market data (2016) [2]. VMware’s NSX also includes an open source virtual switch called Open vSwitch (OVS) that works with the hypervisors in the NVP architecture. Open vSwitch has become the most popular Open Source virtual switch implementation, even outside of NVP implementations. Interestingly, NVP uses OpenFlow as the southbound interface from its controller to the OVS switches that form its overlay network. Thus, technically speaking, this solution is both an SDN via hypervisor-based overlays and an Open SDN implementation.

What are the Pros and Cons of Deploying NVP and NSX?

The Pros:

It’s great for data centers as any modern data center would already have some kind of virtualization running for compute and storage, and perhaps a hyperconverged solution.

It minimizes the amount of CAPEX required to bring some of the benefits of SDN to your data center as well as reduce the impact to changes on the running configuration.

It addresses, efficiently and cheaply, issues like the MAC address explosion for cloud and data centers, as in all these devices MACs are hidden within the encapsulated frames

It allows implementation of centralized automation and agility to deploy new networks, taking a fraction of time compared to deploying an entirely new physical network over existing physical ones.

It addresses VLAN limitations, tunneling all the traffic and not needing VLANs for supporting multiple tenants isolated from one another.

Using a solution like VMware NSX is coupled with a robust software product and its technical support provides a distinct advantage.

Leaving the physical infrastructure unchanged, you will still be required to do some manual or script-based configuration and maintenance of the physical network.

You won’t be able to handle traffic prioritization on the physical network.

Summary

SDN is emerging out of the early adopter and into the early mainstream stage of its development and will play a role in shaping the next-generation of networks for use cases such as SD-WAN, microsegmentation and IoT.

Our team of expert Dell EMC Services consultants and advisers, as always, are here to answer your questions and advise a solution that best fits your needs.

About Javier Guillermo

Javier is a technologist with over 20 years of experience in the IT/Telecom industry with a focus on SDN/NFV, OSS/BSS, system integration, automation, cloud and orchestration.

Prior to Dell Technologies, Javier worked at Fujitsu as Principal Planner/Architect, where he was responsible for introducing cutting-edge SDN multi-layer, and NFV application services, as well as building strategical partnerships with third party vendors. In addition, he worked at Juniper Networks Professional Services, Nokia, and Schlumberger, where he assumed different roles such as Customer Support Engineer, Solution Sales Manager, R&D Engineer and Group Manager at the US Technical Assistance Center.

Javier loves to cook and exercise, and is a certified personal fitness trainer. He is tremendously fond of soccer and an avid supporter of his hometown team Real Madrid.