Once upon a time, there were networks and network engineers, but programmers came and took over the field… actually, I am just kidding. Networks and network engineers still exist and they will never go away, however, they are definitely not going to be the same. I remember that terminologies such as Software Defined Networking (SDN), OpenFlow, and OpenDaylight started to pop up around my work environment in late 2013 and even though initially there were just these 3 terminologies, they did bring a lot of confusion to classic network engineers (even today that is still the case for many). The concept of SDN is a lot more mature today and has brought many other terminologies (just when you thought it could not get anymore confusing) into the mix: Cisco Application Centric Infrastructure (ACI), Cisco Digital Network Architecture (DNA), Cisco Network Services Orchestrator (NSO), Cisco Intelligent WAN (iWAN), and Software Defined WAN (SD-WAN) to name a few. Network Function Virtualization (NFV) and VMware NSX are other terminologies that popped up around the same time, but are actually something different. I want to briefly break down these terminologies and give you some concepts to help you understand the differences and prepare you for another blog entry that will solely focus on the technical details of NSO.

As it turns out, Software Defined Networking (SDN) is not as new as you might have thought. It dates back to April of 2004 when the Internet Engineering Task Force (IETF) published the informational Request for Comment (RFC) number 3746. As you may already know, the idea did not gain much attention and the networking industry continued to build networks in a monolithic fashion. What exactly do I mean by monolithic fashion? I mean a couple of things:

1.    Without major technological changes: They continued to use Ethernet, RIP, EIGRP, OSPF, BGP, etc forever.

2.    Deploying and troubleshooting networks in the same manner over and over: Configuration and troubleshooting of network devices are done individually via the command line interface (CLI) and the control plane and the data plane are tied to a single device.

 

Recall that control plane is a functional area of a network device that builds forwarding information whereas data plane is another functional area of a network device that leverages forwarding information built by the control plane to physically move or switch packets from one port to another. With this in mind, network devices in classic networking are managed and configured individually and the outcome is that each device in the network learns and makes forwarding decisions autonomously. Until we get to the proprietary SDN discussion section, I will be referring to SDN from an industry standard perspective unless otherwise specified.

SDN is an architecture that promotes the separation of the control plane from the data plane functionality of a network device and centralizes management. How exactly is this achieved? The control plane and management responsibility are taken out of each device in the network and placed in a central device, otherwise known as the SDN controller. This allows you to configure the entire network from a single device as opposed to on a device per device basis, with the exception of the data plane as this network device functionality stays within each device. The picture below depicts a network of 6 routers being managed by an SDN controller via an out-of-band (OOB) management network:

How is it that the SDN controller can communicate with network devices and make configuration changes? Much like a network engineer in the classic way of network management uses Telnet or SSH (protocols that allow you to remotely connect to a device and manage it) to connect to a device and make configuration changes, a network engineer in the SDN way of network management logs in to the SDN controller and uses its interface (Web or CLI) to make configuration changes to a network device. In turn, the SDN controller uses the OpenFlow protocol (managed by the Open Networking Foundation) to communicate with a network device for management purposes, but today other options are also available: NETCONF and APIs (this is where programming skills come handy, hence the network programmability term was born) for example. The last piece that glues the SDN architecture together is OpenDaylight (managed by the Linux Foundation), which is a software-based SDN controller contained within a Java Virtual Machine (JVM). This SDN controller is typically installed on a Linux box and is used for configuration and management of network devices that support the OpenFlow protocol. Let’s do a quick recap to make sure that we have a solid understanding of SDN, OpenFlow, and OpenDaylight:

1.    SDN is a network architecture that separates the control plane and data plane of network devices and provides with an SDN controller for centralized management of these.

2.    OpenFlow is a standard protocol managed by the Open Networking Foundation (ONF) used for communication between the SDN controller and managed network devices.

3.    OpenDaylight is a standard software-based SDN controller managed by the Linux Foundation (LF) that speaks OpenFlow to manage OpenFlow enabled network devices.

With an understanding of this early SDN solution (OpenFlow and OpenDaylight), the proprietary and additional industry standard solutions become easier to understand.

Cisco has a few SDN solutions that offer different use cases and have their own place in the network (campus, branch, data center, or service provider). Some, if not all of these solutions, were obtained through acquisition. ACI is probably the first Cisco SDN solution, which uses the following components and as depicted in the picture below:

1.    Spine and leaf fabric architecture: Network devices connect to the leaf switches and all leaf switches connect to every spine in the network. Traffic uses equal cost multipath (ECMP) and always flows leaf, spine, and leaf.

2.    Application Policy Infrastructure Controller (APIC): This is a hardware-based SDN controller for this solution.

At a high level, ACI is meant for data center environments and allows management of the switches as a single fabric. It is a very robust solution but you are locked with Cisco Nexus 9300 and 9500 switches.

The next Cisco SDN solution is DNA, which brings the concept of intent-based networking. Intent-based networking promises to translate business needs into technical solutions and DNA is built with enough intelligence to allow this to happen. Think of DNA as your network consultant if it helps you better grasp the concept. DNA is a lot broader than ACI in that it has a lot of places in the network, but mainly it is used for campus and branch networks and uses the DNA Center appliance (the SDN controller) to manage network devices.

Let’s continue with Cisco NSO. This is probably the simplest Cisco SDN solution and it is mainly used in service provider environments where network service deployments require a lot of repetitive tasks. For instance, creating L2VPN or L3VPN services for different customers would typically require nearly identical configurations, with the exception of customer specific information: Interface name, IP address, VLAN tag, Virtual Routing and Forwarding (VRF) name, etc. NSO is a multi-vendor controller installed in Linux that supports NETCONF, OpenFlow, SNMP, and APIs to name a few.

In the final section of our SDN discussion, I will cover iWAN and SD-WAN at the same time. SD-WAN is a standard concept that deals with creating and managing WAN connections using a cloud-based environment. There are several vendors offering this solution and Cisco does it via the Application Policy Infrastructure Controller Enterprise Module (APIC-EM) controller and via Viptela SD-WAN (more on Viptela in just a moment). iWAN is Cisco’s first SD-WAN solution, which initially did not have a controller and was deployed natively on Integrated Services Routers (ISRs), but later it was added as an application to the APIC-EM controller. The problem with iWAN is that it is not a true cloud-based solution so the industry has not widely adopted it. In an attempt to remain relevant in this space, Cisco acquired a company called Viptela (I told you I would get to this) and with that, the Viptela SD-WAN solution became part of Cisco’s SDN arsenal. This solution has three main software based controllers: vEdge, vManage, and vSmart. Other vendors in this space are Barracuda, Citrix, Fortinet, and Riverbed Networks.

The next and final discussion is about Network Function Virtualization (NFV), which is often confused with SDN. First I would like to remind you of the traditional way of using computers versus the new way. In the traditional way, you have your desktop or laptop hardware and you use some kind of media (e.g. CD, DVD, USB) to install an operating system such as Windows, Linux, or Mac OS. When done, you have a complete system composed of hardware and software that allows you to perform tasks and install applications. In the new way, your hardware is abstracted and shared among several computer instances that are called virtual machines. Each virtual machine represents a single physical computer where you can install the operating system of your choice and finally perform tasks and install applications just like you would in a traditional system. In essence, virtualization separates the operating system (software) from the desktop or laptop (hardware).

The concept of NFV is to separate network software functionality from hardware. If you use the same virtualization concept of computers, this translates to virtualization of routers, switches, wireless controllers, and firewalls. VMware NSX was probably one of the first, if not the first, NFV solutions presented to the public. This solution became part of VMware through the acquisition of a company called Nicira. Cisco is also in this space with products like the CSR1000v and ASAv as an example.

Hopefully this gives you a good foundation on SDN concepts and terminology and sparks your interest in exploring one of them. What is going to be your choice?