Traditional vs. controller-based networking

A real-life situation

Your company has 40 branch offices. Security asks for a new ACL on every access switch, and a new VLAN for IP cameras. Done the traditional way, an engineer logs in to more than 120 switches one by one with SSH, pastes commands and hopes nothing was missed. A week later two switches still have the old ACL and one has a typo.

Controller-based networking changes this. You describe what you want once, in one central system, and that system configures every device and keeps checking that they stay that way. This lesson explains the idea, the vocabulary the CCNA exam uses for it, and what you set up on a Cisco device so a controller can manage it.

What it is: the three planes

Every network device does three different jobs. Cisco calls them planes:

In a traditional network every device runs all three planes on its own. Each router runs its own OSPF, each switch runs its own Spanning Tree, and an engineer manages each box through its own CLI. The control plane is distributed: no single device sees the whole network.

Software-defined networking (SDN) moves some of that work into a central controller: software, usually on a server or cluster of servers, that knows the whole network. The controller holds the policy and talks to every device through software interfaces called APIs (application programming interfaces: defined ways for one program to ask another to do something).

The SDN architecture

The CCNA uses a three-layer model for controller-based networks. Here it is drawn for this course's lab, where Catalyst Center manages R1, SW1 and SW2:

• Northbound interface (NBI): how apps and people talk to the controller. Almost always a REST API with JSON.
• Southbound interface (SBI): how the controller talks to the devices. Common ones:
  • NETCONF: XML messages over SSH, TCP port 830.
  • RESTCONF: REST-style HTTPS requests with JSON or XML.
  • SSH and CLI commands, and SNMP: the older but still common methods.
  • OpenFlow: the original open SDN protocol, which programs flow tables directly.
  • OpFlex: used by Cisco ACI in the data centre.

NETCONF and RESTCONF use YANG data models. A YANG model is a schema: a precise description of which settings exist (an interface has a name, a description, an enabled flag, addresses) and what values they accept. Because the model is fixed, a program can read and change settings without parsing human-readable CLI output.

Why it works that way

Distributed control planes are very good at one thing: surviving failures. If one router dies, OSPF on the others reconverges with no central brain needed. That is why even controller-based Cisco networks keep routing protocols running on the devices.

What distributed networks are bad at is consistency and scale of management. Hundreds of hand-typed configurations drift apart over time, and nobody has one view of health. A controller fixes the management problem:

• One source of truth: the intended configuration lives in the controller, not in each engineer's notes.
• Consistency: the same template goes to every device, so typos are made once or not at all.
• Speed: one change reaches 500 devices in minutes.
• Visibility: the controller collects health data from every device in one place.
• Programmability: other tools can drive the network through the northbound API.

Cisco calls the idea of describing what you want ("cameras may only talk to the video server") instead of how to configure it intent-based networking (IBN). The controller translates the intent into device configuration.

How it works step by step

Here is a change made through Catalyst Center in the course lab. The NetOps PC and Catalyst Center sit on the management network 10.10.0.0/24 behind R1; the switches are managed on VLAN 99 (10.10.1.0/24).

Before it can manage a device, the controller must discover it and add it to its inventory. With Catalyst Center this happens over the southbound protocols you configure on the device:

Underlay, overlay and fabric

Controller-based campus networks such as Cisco SD-Access (software-defined access, run by Catalyst Center) add two more terms:

• Underlay: the physical switches, links and a routing protocol (IS-IS in SD-Access) that give every device IP reachability to every other. It is a plain routed network with no Spanning Tree between switches.
• Overlay: virtual tunnels built on top of the underlay that carry user traffic between edge switches. SD-Access uses VXLAN for the data plane, LISP as the control plane (it tracks where each endpoint is), and Cisco TrustSec group tags for policy.
• Fabric: underlay and overlay together, managed as one system.

The benefit is that a user's VLAN and policy can follow them to any switch, while the underlay stays simple and stable.

Traditional vs. Catalyst Center management

Neither replaces knowing the CLI. When a controller reports a problem, you still verify it on the device with show commands.

How to configure a device for controller management

You don't configure the controller from IOS. What you do on each device is prepare its management plane: a reachable address, SSH with a local or AAA account, SNMPv3, and (on IOS XE) NETCONF. Here is SW1 in the lab.

The complete management configuration for SW1:

⚠️ Turning on aaa new-model changes how every line authenticates. Configure the local user and the aaa authentication login default local line in the same session, and keep a console or second SSH session open, or you can lock yourself out.

How to verify it

SW1#show ip ssh
SSH Enabled - version 2.0
Authentication methods:publickey,keyboard-interactive,password
Authentication timeout: 120 secs; Authentication retries: 3
...

SW1#show snmp user
User name: cc-user
Engine ID: 800000090300A0B1C2D3E4F5
storage-type: nonvolatile        active
Authentication Protocol: SHA
Privacy Protocol: AES128
Group-name: CC-GROUP

SW1#show netconf-yang status
netconf-yang: enabled
netconf-yang ssh port: 830
netconf-yang candidate-datastore: disabled

On the controller side, the device should appear in the inventory as reachable and managed, with its software version and serial number filled in.

What goes wrong and how to troubleshoot it

Common mistakes

• Thinking the controller forwards user traffic. It doesn't; the data plane stays on the devices.
• Mixing up the directions: northbound faces the apps above, southbound faces the devices below.
• Listing REST as a southbound-only API. Controllers use REST northbound; RESTCONF is a REST-style southbound option too.
• Forgetting that SNMPv3 users don't show in the running configuration, then re-creating them.
• Making hand changes on a controller-managed device. The next template push or compliance check will undo or flag them.

💡 Exam tip: expect questions that ask which plane does a task (OSPF is control plane, forwarding a frame is data plane, SSH is management plane), which way an API faces, and how controller-based management differs from traditional device management. Know the terms overlay, underlay and fabric, and that NETCONF uses SSH on TCP 830 while RESTCONF uses HTTPS.

Key takeaways

• Data plane forwards, control plane decides, management plane configures and monitors.
• Traditional networks distribute all three; controllers centralize management and policy.
• Northbound API: apps to controller (REST/JSON). Southbound API: controller to devices (NETCONF, RESTCONF, SSH, SNMP, OpenFlow).
• Underlay = physical routed network; overlay = virtual tunnels on top; fabric = both.
• Prepare devices with a management IP, SSH, SNMPv3 and netconf-yang.

Check yourself