Network controller

Programs and people talk to the controller through its northbound API (usually REST); the controller talks to the devices through its southbound side (SSH, NETCONF, OpenFlow, a vendor API) and makes the change there. One request reaches every device it concerns. The controller becomes the source of truth: a change made by hand on a device behind its back is overwritten or reported, so changes go through the controller.

How an SDN controller works, step by step

Software-defined networking splits a switch in two. The data plane forwards packets; the control plane decides where they go. A classic switch runs both itself. SDN pulls the control plane out into one controller that holds the whole map and programs every switch, as in control plane and data plane. Follow the SDN controller lab, where three Open vSwitch switches s1, s2, s3 form a triangle, hosts alice (10.0.1.13), bob (10.0.1.14) and webServer (10.0.1.15) hang off them, and a controller reaches each switch on a management network 10.0.9.0/24:

1. The switches decide nothing. Each runs in fail_mode: secure and listens for a controller on TCP 6653. With an empty flow table, alice cannot even reach webServer.
2. The controller surveys. It knows the topology from its configuration and asks each switch which ports are up (an OpenFlow PORT_DESC request). That is the southbound interface: OpenFlow 1.3 here, though a controller may also use NETCONF, gNMI or a vendor API.
3. It computes paths. A breadth-first search over the up links gives, for each switch, the next hop toward every host. The controller writes a flow table into each switch: match on destination, output to the right port, plus a low-priority drop for everything else.
4. The data plane forwards. With the flows installed, packets move switch to switch with no further help. Pull the controller's link and traffic keeps flowing: the control plane is separate from the data plane.
5. The northbound side. People and programs drive the controller through its own API, usually a REST API, so one request reaches every device it concerns and the controller becomes the source of truth. The REST API lab builds that side.

What it looks like on a Linux machine

Before the controller acts, a switch has no flows and hosts cannot talk:

$ ovs-ofctl -O OpenFlow13 dump-flows br0
OFPST_FLOW reply (OF1.3) (xid=0x2):
$ ping -c 2 -W 1 10.0.1.15
2 packets transmitted, 0 received, 100% packet loss

The controller's survey reports switches, links and hosts:

$ sdn-controller status
Switches (OpenFlow, TCP 6653):
  s1   10.0.9.10   ports: alice up, s2 up, s3 up
  s2   10.0.9.11   ports: bob up, s1 up, s3 up
  s3   10.0.9.12   ports: s1 up, s2 up, webServer up
Links:
  s1 - s2  up
  s2 - s3  up
  s1 - s3  up
Hosts:
  alice      10.0.1.13   on s1, port alice

apply programs the flow tables and prints the computed paths:

$ sdn-controller apply
s1: 7 flows installed
...
Paths:
  alice -> webServer: s1 -> s3

The installed flows are match-and-action entries; dump-flows shows them counting packets:

$ ovs-ofctl -O OpenFlow13 --names dump-flows tcp:10.0.9.10:6653
 n_packets=2, n_bytes=196, priority=100,ip,nw_dst=10.0.1.15 actions=output:s3
 priority=0 actions=drop

Cut the s1-s3 cable and status shows s1 - s3 DOWN; the next apply reroutes alice -> webServer: s1 -> s2 -> s3 and rewrites s1's flow to actions=output:s2.

What goes wrong, and how you see it

The controller cannot reach a switch. apply prints s1: unreachable, not programmed and leaves its table as it was. The southbound session (TCP 6653 on the management network) is down; check the management link and that the switch shows Controller "ptcp:6653".

A failure does not reroute by itself. Unlike OSPF, a pure SDN data plane does nothing when a cable dies until the controller recomputes. The symptom is traffic black-holing on the old path; running apply installs the way round. This is the cost of a central control plane.

A hand-made flow vanished. Adding a flow directly with ovs-ofctl add-flow works until the next apply, which does replace-flows and wipes anything not in the controller's model. The controller is the source of truth; put the rule in its configuration instead.

fail_mode is wrong. A switch left in fail_mode: standalone acts as a learning switch when the controller is gone, forwarding traffic the policy meant to block. ovs-vsctl show should read fail_mode: secure.

Questions people ask

What is the difference between northbound and southbound APIs? Southbound is how the controller talks to the devices (OpenFlow, NETCONF, gNMI, a vendor API). Northbound is how people and programs talk to the controller, usually a REST API. One northbound call can touch every device.

Is SDN the same as OpenFlow? No. SDN is the idea of a separated, centralised control plane; OpenFlow is one southbound protocol for it. Many controllers now use NETCONF or gNMI instead, and the lab happens to use OpenFlow 1.3.

Does the network stop if the controller dies? Already-installed flows keep forwarding, so existing paths survive. What stops is adaptation: no new paths and no rerouting until the controller returns.

See it on real machines