Traditional Networks vs Controller-Based Networking

What it is

A traditional network is managed device by device, while a controller-based network is managed as a group from one central system.

In a traditional network, every router and switch holds its own settings and makes its own decisions about forwarding. An engineer reaches each device through its command line, one by one.

In a controller-based network, a central system called a controller holds the policy for the whole network. Engineers describe what they want once, and the controller works out how to apply it to every device. The devices still forward the traffic, but they are managed as a group.

How it works

Every device does three kinds of work, and the two network styles differ in where the planes are placed.

The three planes

The three kinds of work are called planes.

• Data plane: forwards the actual traffic. It acts on each packet or frame as it arrives, using tables already built. Examples are looking up a destination in the routing table and sending the packet on.
• Control plane: builds the tables that the data plane uses. It runs protocols such as OSPF and Spanning Tree, learns routes and MAC addresses, and decides the paths.
• Management plane: how people and tools configure and monitor the device, through SSH, SNMP, syslog or an API.

In a traditional network, all three planes live in each device. The control plane is distributed, so every router runs its own routing protocol and makes its own decisions. The network works because they agree with each other.

This is robust, but a change in policy must be made on each device by hand.

In a controller-based network, the management plane, and often much of the control plane, moves into the controller. The devices keep the data plane and do the fast forwarding. The next topic goes deeper into how the controller and the devices talk to each other.

A comparison

Benefits of controller-based networking

Central policy and a single view. The controller knows the whole network. Engineers see all devices, links and clients in one place, and can apply a policy such as "guests may only reach the internet" without touching each device.

Automation. Controllers expose APIs, so other software can request changes, and tasks that once took days can be done by a workflow. New devices can be added with zero touch provisioning: they power up, find the controller and receive their configuration with no one typing anything.

Assurance and analytics. Because the controller collects data from every device, it can notice problems, show the path a client's traffic took and suggest causes. This helps with troubleshooting.

Intent-based networking. The engineer states the intent, meaning the desired outcome. The controller translates it into device configuration and continuously checks that the network still matches. That moves attention from commands to goals.

Examples of controllers

• Cisco Catalyst Center (earlier called DNA Center) manages campus wired and wireless networks, and provides automation and assurance.
• Wireless LAN controllers manage many access points, as described in the Network Access chapter.
• SD-WAN controllers manage branch routers across a wide area network.

Trade-offs

A controller adds its own considerations.

It becomes a critical system that must be made highly available and secured, since someone who controls it controls the network. Staff need new skills, and not every device supports every controller.

Most designs are therefore built so that if the controller is unreachable, devices continue to forward with their current configuration. What is lost is the ability to make changes and to see analytics.