cloudparts

Software-defined networking

Run a network from software: a controller holds the whole picture and programs the switches and virtual switches through APIs, instead of engineers configuring each box by hand.

7 technologies on this page ↓

How it works

Every network device has a data plane, which forwards packets using tables, and a control plane, which decides what goes in those tables. In a traditional network both live inside each switch or router, from one vendor, and each box is configured on its own through its command line. Software-defined networking (SDN) pulls control into software that can see and change the whole network. A controller keeps a model of the topology and of the desired state, such as which tenants exist, which paths traffic should take and which links are drained, works out what every device needs, and pushes it down through southbound protocols: OpenFlow to write flow-table entries directly, or NETCONF, RESTCONF and gNMI to set configuration described in YANG models and stream telemetry back. Applications and orchestrators talk to the controller through northbound APIs, usually REST. Two other ideas travel with it. Disaggregation separates the switch hardware from its software: a network operating system such as SONiC runs on switches from many vendors, using a common interface to their forwarding chips, so the same software and automation work across all of them. Network virtualisation builds tenants’ networks in software on top of a shared physical fabric: a virtual switch on every server encapsulates traffic in tunnels, and the controller programs those switches. That is how a cloud’s virtual private networks are made, which is why creating a subnet takes an API call rather than a cable.

Think of it as

A railway with a central signalling centre. Instead of a signal box at every junction where someone pulls levers by local rules, one control room sees every train and sets every signal and point remotely. Opening a new route or closing a line for repairs becomes one change at the desk, not a visit to every junction.

Reach for it when

  • Large fabrics of hundreds or thousands of switches, where configuring each one by hand is too slow and too error-prone
  • Multi-tenant networks, where each customer or team needs isolated networks that are created and deleted on demand
  • Mixing switch hardware from several vendors under one operating system and one set of automation
  • Traffic engineering across a WAN, where a central view can steer flows and fill links better than each router deciding alone

Think twice when

  • Small networks of a few switches: a controller, its database and its high availability are more to run than the switches themselves
  • Teams without software skills: SDN replaces CLI changes with APIs, models and code that someone has to write, test and own
  • A controller you can’t make highly available: if it fails, the network should keep forwarding with the last state, so design and test for that
  • Inside a public cloud: the provider already runs the SDN, and you configure it through VPC, routing and firewall APIs

A real example

An operator runs a data centre of 96 leaf and 8 spine switches bought from two vendors, all running SONiC. Each switch keeps its configuration in a local database, and BGP between leaves and spines spreads routes as usual. Instead of logging in to switches, the network team keeps the intended state in Git: ports, VLANs, BGP neighbours, which spine is in maintenance. A controller turns that into each switch’s configuration and pushes it over gNMI, then subscribes to streamed counters from every port. To replace a spine, an engineer changes one line to drain it; the controller raises its BGP cost so traffic moves to the other seven, waits until the counters show it idle, and reports that the box can be unplugged.

Technologies

Specific products, and what each does differently.

What each provider calls it

AWS
No controller to run: VPC networking is software-defined underneath and programmed through the EC2 and VPC APIs. AWS Cloud WAN builds a global network across Regions and sites from one declarative JSON policy of segments and Regions
Google Cloud
No controller to run: Andromeda, Google’s SDN stack, sits under every VPC network and isn’t configured directly; Google’s WAN between data centres, B4, is centrally controlled SDN
Azure
SDN in Azure Local for on-premises clusters (Network Controller, Software Load Balancer and gateways); Azure’s own data centres run SONiC, which Microsoft built for them
Open source & others
At the Linux Foundation: OpenDaylight (an SDN controller), SONiC (a switch operating system), Open vSwitch (virtual switches on hosts) with OVN (the control plane above them), FRRouting for routing, and DPDK and P4 for programming the data plane. Commercial: VMware NSX, now VMware Cloud Foundation Networking, and Cisco ACI with its APIC controller

Where the software sits#

SDN products work at different layers, and many networks combine them.

LayerWhat it doesTalks to devices withExamples
ControllerKeeps the network model and desired state, computes what each device needs, exposes northbound APIsOpenFlow, NETCONF, RESTCONF, gNMI, BGPOpenDaylight, OVN, Cisco APIC
Network operating systemRuns on a physical switch and drives its forwarding chip through a common interfaceConfigured locally or by a controller; routes with BGPSONiC
Host virtual switchBuilds tenants’ virtual networks on each server, tunnelling their traffic across the physical fabricProgrammed by a controller, e.g. over OpenFlowOpen vSwitch, VMware NSX
Cloud network serviceThe provider’s own SDN, exposed as API resources such as VPCs, routes and policiesCloud APIsAWS VPC and Cloud WAN, Google Andromeda

Often confused with

Virtual private cloudsNetwork protocolsService discovery & meshLoad balancersInfrastructure as code
Where it came from2008–2022

By the mid-2000s networks were built from closed boxes: each vendor’s switches came with its own software and command line, and researchers couldn’t try new ideas on real networks. In April 2008 Nick McKeown and colleagues from Stanford, Berkeley, MIT, Princeton and elsewhere published OpenFlow, a way for an external controller to write entries into a switch’s flow table over a secure channel, so experiments could run on campus switches alongside normal traffic. In March 2011 six network operators, Deutsche Telekom, Facebook, Google, Microsoft, Verizon and Yahoo!, founded the Open Networking Foundation to take OpenFlow forward and promote software-defined networking.

Clouds made the idea mainstream. In July 2012 VMware agreed to buy Nicira, whose network virtualisation platform built tenants’ networks out of Open vSwitch on every host, for about $1.26 billion. In April 2013 Cisco, IBM, Microsoft, Red Hat, VMware and others launched OpenDaylight at the Linux Foundation as a shared open-source controller. In August 2013 Google described B4, the WAN between its data centres, which used OpenFlow and a central traffic engineering service to run links close to full, and in 2014 it named Andromeda, the SDN stack under its cloud’s virtual networks.

Disaggregation followed. Microsoft had the Open Compute Project accept SAI, a common interface to switch chips, in July 2015, and in March 2016 it open-sourced SONiC, the Linux-based switch operating system it built for Azure. The Linux Foundation grouped its networking projects, OpenDaylight among them, into LF Networking in January 2018, and SONiC moved to the Linux Foundation in April 2022.

Why it’s built this way

Separate the control plane from the data plane
Switch hardware is good at forwarding fast, but per-box control software made the network hard to change. Moving decisions into software on servers lets operators change behaviour without waiting for each vendor’s firmware.
A logically central controller
With a global view, a controller can compute paths, tenants and policies for the whole network at once instead of hoping that each box’s local decisions add up to the right result.
Models and APIs instead of command lines
Describing devices in YANG and changing them over NETCONF or gNMI lets automation treat thousands of switches from different vendors the same way and check the result.

Timeline

  1. 2008

    OpenFlow paper published in April

  2. 2011

    Open Networking Foundation founded by six network operators in March

  3. 2012

    VMware agrees to buy Nicira for about $1.26 billion in July

  4. 2013

    OpenDaylight launches at the Linux Foundation in April; Google describes B4 in August

  5. 2016

    Microsoft open-sources SONiC in March

  6. 2018

    LF Networking formed in January, with OpenDaylight as a founding project

  7. 2022

    SONiC moves to the Linux Foundation in April

Sources11

Improve this page on GitHub