SDN basics: planes, flows and abstractions

Traditional switches make forwarding decisions locally. SDN pulls that logic into a central controller, leaving switches to do one thing well: move packets.

Before SDN, every switch and router was an island with its own opinion. Each box ran its own routing protocols, held its own view of the topology, and had to be configured individually. It worked, but the network's behaviour existed only as the sum of several hundred separate configurations — and nobody could see it in one place.

The two planes

The data plane forwards packets at line rate. The control plane decides where they should go. In classic gear both live in every box; in SDN the control plane moves to software you can program. That separation is the whole idea, and almost everything else in SDN is a consequence of it.

Flows, not routes

A controller installs flow rules into switches: match on header fields, then act (forward, drop, rewrite). This lets you express policy as code rather than per-box configuration. A flow rule can match on far more than a destination address — port, protocol, VLAN, source — which is why SDN policy can be specific in ways traditional routing never was.

Reactive versus proactive

Flow rules arrive one of two ways. Reactive means the switch meets an unknown packet, asks the controller what to do, and caches the answer — flexible, but the first packet pays a latency cost and the controller becomes a bottleneck under load. Proactive means rules are installed before traffic arrives. Most production deployments lean heavily proactive for exactly that reason.

Why it matters

• One place to reason about the whole network.
• APIs instead of hand-typed CLI.
• Faster iteration on topology and policy.
• Network behaviour that can be tested before it is deployed.

What it does not solve

Centralising the control plane centralises the failure mode too. A controller outage is a different class of problem from a single switch failing, which is why production designs run controllers in clusters and keep enough state in the switches to survive losing them. Next: how controllers turn intent into flow rules.