For many years, networks were exclusively built, operated, and maintained as a grouping of individual devices. To build networks, we would log into devices individually and manually, or by using some sort of scripting solution. For network operations, each network device had to have its own knowledge of the picture of the network. Each device had to build and maintain its own control plane (routing table) to be able to properly route and forward packets throughout the network. As far as troublehsooting and maintenance, we have been logging into devices individually and manually for quite some time to run troublehsooting commands when diagnosing problems, and when performing software upgrades. Now, don’t get me wrong, I can imagine that many networks are still designed and operate in this way and it works well and is by no means a broken process. That being stated, I think we can all see where there is room for improvement. What are these specific areas of improvement? First off, management and troubleshooting for the network could be made to be easier and more streamlined. Manaully logging into the command line interface (CLI) of each network device can be tedious and error prone. Also, unless there is another system set up for log aggregation and correlation, all of the valuable data used troubleshooting and diagnosing issues is right there on the device and needs to be accessed manually and individually. Secondly, with these traditional networks that we have been highlighting so far, there is not much flexibility when it comes to logical topology and design. We know that building Layer 3 networks to the edge (access layer) takes away the complexity of having to manage and deal with large Layer 2 topologies and spanning tree protocol (STP), but there can be many cases in which Layer 2 networks need to span multiple switches, so that complexity has to be there. It would be nice if we had a way for deploying the solid foundation of Layer 3 networks across the board to maintain stability, while still being able to support client mobility (spanned Layer 2 networks). Well, we do have that, and it is the concept of software defined networking (SDN). SDN in it of itself is not a specific product, it is a methodology for building, managing, and maintaining networks. In my eyes, software defined networking has two major characteristics that set it apart from traditional networking.
Decoupling the Control Plane
A large component of SDN is that of underlays and overlays. We can think of an underlay as the foundation of our network infrastructure. The sole purpose of the underlay is to route packets quickly and efficiently. To me, route is the key word here. Software defined networking and the concept of underlays and overlays allows us to build solid, Layer 3 networks from end to end that do not have to rely on the complexity of spanning tree protocol (STP). Overlay protocols can then be used on top of these underlay networks to create different logical topologies to support our different applications and use cases. A use case that I often come back to is Layer 2 extension over a Layer 3 underlay. This gives us the ability to allow devices to roam through a facility, maintain their existing IP addresses, and keep Layer 2 adjacencies with devices on the broadcast domain, even though in the underlay we are crossing Layer 3 boundaries. How is this able to happen? By using the concept of SDN, through overlay technologies, we are able to decouple the control and data planes on network infrastructure devices. In a traditional networking sense, each router or Layer 3 switch in a network needs to directly know how to get to every destination in the network, and does this with a combination of dynamic routing protocols and static routing. With software defined networking in the overlay network, the control plane concept is removed from the individual router or Layer 3 switch, and replaced with a centralized controller and lookup process so that the individual network infrastructure device can figure out where to forward packets in the data plane. I like to relate this to the DNS lookup process. Clients do not need to learn or download a database of all possible hostname to IP resolutions. When they need to resolve a name that is not already in their cache, they ask a DNS server. Decoupling the control plane from routers and Layer 3 switches is a similar concept. The network devices query the centralized control plane for a destination network, then are able to build an overlay tunnel with the far end router (if one doesn’t exist already), to forward packets to it over the underlay network. The concept of a centralized control plane is what makes me think of the term fabric. When we remove the control plane function from the individual devices and centralize it on the controller, I feel that we are treating the network as a single cohesive unit, rather than multiple individual routers sharing information and communicating.
Centralized Management
At the end of the previous section, I mentioned that when we centralize the control plane, we are treating the network infrastructure as a single entity rather than a grouping of individual devices. Well, with the concept of centralized management in SDN, the same thing is happening. With traditional networking, devices are managed separately and individually, typically via the CLI or with abstraction and scripting. Conversely, similar to the control plane, software defined networking centralizes the management plane. This allows network administrators and engineers to manage their infrastructure from a single point. This can be done either through the specific SDN product’s graphical user interface (GUI), or through another management platform that organizations may already leverage. SDN embraces the use of application programming interfaces (APIs) to communicate northbound with management and other systems, and southbound to communicate with the network devices it manages. Outside of configuration, software defined networking platforms can aggregate logs and telemetry from network devices and provide a centralized point for network monitoring and troubleshooting. Another large benefit of centralized management is the ability to handle code upgrades on the network infrastructure centrally, rather than having to address each device manually.
Closing
Over recent years, software defined networking has really changed how we manage and operate networks. There are many benefits we can gain from leveraging SDN including centralized control and management planes. These concepts give us the benefits of standardization and flexibility at the same time. That being stated, there are typically trade-offs with many things, including SDN and overlays. For instance, with building overlays on top of Layer a 3 underlay, yes we are essentially removing the complexity that comes with STP, but we are adding the complexity of overlay technologies. In the end, with overlays, I like to think of it as not removing complexity, but hiding it. As I started writing this, I completely forgot that I had written about SDN already as part of my Cloud Essentials+ Journey series. Feel free to check out that article as well to see how much I may have contradicted myself with this post.
*Featured image from Manuel Geissinger.
Netication 