Why automate: SDN and controller-based networking

Why automate at all?

Imagine a bank with 1,200 branches. Each branch has a router and two switches, so the network team looks after more than 3,600 devices. A new security rule must go on every router by Friday. If one engineer logs in to each router over SSH and types the commands, it takes weeks, and somewhere a typo will block the ATM network of a branch.

Automation means letting software do this repetitive work. It gives three things: speed (a change reaches all devices in minutes), consistency (every device gets exactly the same lines) and fewer human errors (nobody types the same thing 1,200 times). It also makes changes easy to review and to undo, because the change is written down as a file before it is applied.

The three planes of a network device

A plane is a group of jobs a device does. Every router and switch does three kinds of work, and SDN is easiest to understand once you can separate them.

Traditional versus controller-based networking

In a traditional network, every device has its own control plane and its own management plane. Each router runs OSPF and works out its own routes. Engineers configure each device separately through its CLI. This works, but it does not scale well, and the network as a whole has no single place that knows everything.

In controller-based networking, a software controller (a program running on a server or a cluster of servers) becomes the central brain. Depending on the design, it takes over part of the control plane, or it keeps the devices running their own protocols and centralises management and policy. Either way, engineers and programs talk to the controller, and the controller talks to the devices. The data plane always stays on the devices: switches still forward the packets.

Northbound and southbound APIs

An API (application programming interface) is a defined way for one program to ask another program for something. In SDN diagrams the controller sits in the middle, apps sit on top and devices sit below, so the APIs are named by direction.

• Northbound API: between the controller and the apps or scripts above it. It is usually a REST API that sends JSON over HTTPS. Your Python script or a monitoring dashboard uses it to ask "list all switches" or "add VLAN 30 at every store".
• Southbound API: between the controller and the network devices below it. Examples are OpenFlow (the controller programs flow tables directly), NETCONF and RESTCONF (configuration using YANG data models), plain SSH and CLI commands, SNMP, and OpFlex (Cisco ACI, where the controller sends policy and the devices decide how to apply it).

Underlay, overlay and fabric

Modern controller-based networks are often built in two layers. The underlay is the physical network: the cables, switches and routers, with a simple routing protocol that just gives every device IP reachability. The overlay is a set of virtual networks built on top using tunnels, where the original packet is wrapped inside a new one. The underlay and overlay together are called the fabric.

Cisco SD-Access is a campus fabric. Its underlay is a routed network (often IS-IS). Its overlay uses VXLAN to carry traffic and LISP as the control plane that tracks where each endpoint is. Cisco Catalyst Center (formerly called DNA Center) is the controller that builds and manages it, assigns users to groups and pushes policy, and also offers northbound REST APIs and health dashboards.

SD-WAN

SD-WAN (software-defined WAN) applies the same idea to links between sites. Picture a retail chain with 300 stores across India. Each store has a cheap broadband line and a 4G backup instead of an expensive leased line. The SD-WAN edge router at each store builds encrypted tunnels over both links. The controllers measure loss and delay on every path and send billing and UPI payment traffic over the best link, while CCTV uploads use whatever is left. If the broadband fails, traffic moves to 4G within seconds. A new store is plugged in, contacts the controller, and downloads its configuration (zero-touch provisioning). In Cisco Catalyst SD-WAN, the main parts are SD-WAN Manager (formerly vManage), SD-WAN Controller (formerly vSmart), SD-WAN Validator (formerly vBond) and the WAN edge routers.

Intent-based networking

Intent-based networking (IBN) means you describe what you want (the intent) and the controller works out how. Intent sounds like "guests may reach only the internet" or "billing gets priority over video". The controller translates it into VLANs, ACLs and QoS on hundreds of devices, then keeps checking (assurance) that the network still does what you asked.