Software Defined Networking 101

Published Sep 28, 2026

Your business may rely on your ability to speak knowledgeably about software-defined networks, and you may have only a vague idea of what the term covers. The original day-long tutorial walked through background, definitions, players, use cases, and critics. Here is the same path in a few minutes.

The background

A traditional router or switch combines two jobs in one box. The data plane forwards packets at high speed, and the control plane decides where they should go. Each device makes those decisions largely on its own, based on what it hears from its neighbors and on configuration typed in by an engineer. That design is robust, but changing anything across hundreds of devices is slow and error-prone.

The definition

Software-defined networking separates the two jobs. Forwarding stays in the hardware, while decisions move to a logically central controller that sees the whole network. Applications talk to the controller through northbound interfaces, and the controller programs the devices through southbound ones. OpenFlow, which came out of academic research at Stanford around 2008, was the best-known southbound protocol and did much to popularize the idea.

Where it worked

• Hyperscale data centers adopted the approach early, often with their own software and custom switches.
• Private wide-area networks benefited too. Google's published work on its B4 network showed how central traffic engineering could run links much closer to full capacity.
• SD-WAN became the product most companies actually bought, steering branch office traffic across broadband and private lines by policy.

Multi-site operators with many small locations and a low tolerance for outages make natural SD-WAN customers. Retail chains and banks were among the first, and regional casino groups and betting-shop chains fit the same profile, since each property or shop needs a dependable path back to central systems and a clean way to keep payment and gaming traffic apart.

The neighbors

SDN is often confused with network functions virtualization. NFV moves network functions such as firewalls into software on standard servers. SDN changes how the forwarding is controlled. They complement each other, but either can exist without the other.

Myths and critics

The most persistent myth held that SDN would turn networking hardware into a cheap commodity and put the big vendors out of business. That did not happen. The vendors absorbed the ideas and sold controllers of their own. Critics also warned that a central controller could become a single point of failure, and they had a point: real deployments use clusters of controllers and leave the devices able to keep forwarding if contact is lost.

OpenFlow itself has faded from view, yet the principle won. Network engineers now expect intent, APIs and automation, even where the word SDN is no longer on the box. For how that thinking reached the wider infrastructure, see Network Infrastructure for a Data-Centric World.