On This Page
Software-defined networking (SDN) is a type of networking architecture that distinguishes the control plane from the traffic-forwarding plane. Software-based controllers are responsible for directing traffic through your network to its destination.
SDN can be implemented in several ways, typically using APIs that surface rules configured in a centralized location. An example of this is Tailscale. Tailscale is a zero-config VPN that provides software networking within your device fleet, even when individual nodes reside in different physical networks.
In this article, you’ll learn what SDN is used for, the benefits it brings, and its drawbacks. You’ll also see which components are involved and how they fit together.
What is SDN?
Routing data through a network has traditionally been handled by dedicated hardware such as routers and switches. SDN is an architecture that moves these functions into software, providing a mechanism by which network control logic is decoupled from the device that implements it. SDN layers software controllers atop your hardware so you can dynamically define network behavior as sets of rules and policies. The network becomes more flexible because you can change its configuration on demand.
As an administrator, you oversee the network using a centralized interface. You can set up new routes, manage bandwidth controls, and monitor network health without having to install or connect to individual pieces of hardware. The software controller automatically applies any changes you make across the infrastructure.
SDN only changes where routing decisions are made. The actual data transfer is still handled by the networking hardware, as it always has been. The router or switch verifies the packets for integrity before redirecting them to the destination indicated by the controller software.
SDN architecture comprises three main components: the application, the SDN controller, and the physical network devices that ultimately route packets.
The application layer is responsible for communicating new routing requests configured by administrators. Applications also monitor broader information about the network, such as its available capacity, to help influence routing decisions. Administrators use the application layer to apply new configurations and interact with the network.
Controllers receive routing requests from the application layer. They use the available rules to decide each data packet’s destination. Although this layer determines how to route traffic, it doesn’t actually move any data through the network.
The physical networking devices in your infrastructure communicate with your SDN controllers to action new routing requests. The device is expected to honor the decision made by the SDN controller. This causes the data packet to be forwarded along the correct network pathway. The device could incorporate some protections to ensure it’s sending traffic to an accessible destination.
How data flows through the architecture
Data moves between applications, controllers, and physical devices using well-defined APIs. The two different layers are sometimes referred to using “northbound” and “southbound” terminology. This describes how dynamic rule changes made by administrators are communicated first to the network controller and then to the physical routers and switches.
Northbound APIs sit between applications and controllers. They allow applications to inform the network of new requirements, such as bandwidth requests and new routing rules. The controllers relay information back to the application to confirm changes have been applied and report any errors.
Southbound APIs form the mesh between controllers and hardware. They let controllers influence the operation of physical devices to enact changes requested by the northbound APIs. Southbound APIs can be open source like OpenFlow, from the Open Networking Foundation, or proprietary solutions offered by individual hardware vendors.
Common SDN use cases
With the opportunities it offers to make networks more configurable and efficient, it’s no wonder SDN adoption is growing. This approach is a good option any time you need to add an element of automation to your network, such as responding to devices being added or removed, or changes to bandwidth consumption. Here are some of the more common use cases.
Centralized network control
SDN is a good option where you need centralized control of a network and its components. A software-based approach lets you make changes to your architecture selectively, without having to interact with the underlying hardware. You can dynamically adjust your network to support new applications as they come online.
Abstracting network functions
SDN abstracts network operations from their configuration. Applications that are connected using SDN components sit separately from the low-level technologies and infrastructure resources that create the physical network. This can make it easier to swap out specific pieces in the future.
SDN unlocks new opportunities for cloud datacenter operators. Compared to bare-metal switches, software routing provides an easily manageable transport layer that can be reconfigured as customers provision new compute instances. This makes the workloads more manageable and efficient.
SDN supports distributed networking tasks such as edge computing, the Internet of Things (IoT), and remote user access. The centralized control plane means new networking devices can be onboarded without compromising the solution’s reliability, security, or ease of management.
With Tailscale, you can set up your own software-defined network using Tailscale as the control plane. Tailscale’s control plane gives all of your devices your network’s routing rules. The Tailscale node agent will then be sure that every machine uses these rules as consistently as possible.
The benefits of SDN
SDN provides agility and flexibility when routing data through networks. Routing decisions can be centralized, changed, and monitored without affecting performance or efficiency. The logic of working out how to handle a data packet is separated from the action of moving it through the infrastructure.
This abstraction of control helps administrators dynamically adjust their network’s parameters in response to changing traffic requirements. Communication between components is achieved using standardized APIs that simplify network implementation and operation.
SDN’s ability to adapt in real time makes it well-suited to emerging technologies such as IoT. Distributed devices that are networked using LTE and 5G need to rapidly transfer data between locations while remaining resilient to changing network conditions.
The drawbacks of SDN
Because SDNs are still relatively new, there are some downsides. You may struggle to find reference implementations or hire staff who are trained in relevant technologies. SDN also requires you to learn new management tools for configuring and monitoring your network.
Security is another concern. Moving routing into software creates a new attack vector. A successful compromise of your SDN controller would expose your network’s architecture and prevent devices from receiving their config policies. You must ensure that access to your SDN system is restricted to essential users.
SDN can also create new failure points in your network. The SDN controller is a particular weak spot, as its loss could destroy network connectivity. Researching the reliability of your chosen SDN solution before you start your deployment is a good idea. It’s also worth rehearsing how you would handle an unresponsive or malfunctioning controller.
Get started with SDN
To give SDN architecture a try, get started with Tailscale by creating an account and installing the client installing the client on each of the devices you want to access in your network.
Get started with Tailscale today.
Frequently Asked Questions
SDN can seem complicated if you're approaching the concept from a background in physical networks. Here are some common questions about SDN and their answers.
How does SDN differ from virtual networks?
SDN and virtual networks are different tools for different use cases.
In traditional networking setups, each networking device has its own control plane and must communicate with other control planes via protocols such as BGP or OSPF. SDN replaces these individual control planes with a centralized control plane, which enables the fleet to act as one cohesive whole, rather than multiple autonomous systems that happen to be configured to work together.
Network virtualization, on the other hand, allows you to nest more networks together — but each of those networks still must be configured with multiple autonomous control planes.
How can SDN be implemented?
Several SDN implementation models are available. The OpenFlow programmable networking protocol is a popular approach that provides an open standard for controlling switches.
SDN infrastructure can also be assembled using custom APIs that facilitate information exchanges between applications, controllers, and network hardware. In other situations, an overlay model might be used, where SDN sits atop existing infrastructure to provide new networking tunnels between devices.
Hybrid approaches are sometimes seen, too. Regular on-device networking protocols can be used alongside SDN with each handling a share of the traffic. This is useful when you’re introducing SDN to your infrastructure, such as in a system that’s gradually gaining IoT functionality.
How does SDN impact security?
SDN can have a positive impact on security. SDN makes it easier to segment parts of your network so that sensitive aspects are kept away from less critical ones. These decisions can be made on a workload-by-workload basis, letting you safely try out new technologies without putting your existing infrastructure at risk.
Centralization also brings consistency benefits. You can ensure all your networking hardware is running the same set of policies, preventing situations where individual switches run outdated configurations. SDN gives you an overall view of your networking position, improving transparency for administrators.
But there are trade-offs. SDN’s controller-centric model means a breach of the controller grants attackers access to your entire network. SDN has a greater attack surface because it has more moving parts. You need to audit, patch, and secure the controller, your devices, and the communication APIs between them. This can create additional challenges beyond those that network administrators are typically familiar with.