33 Network Automation, SDN and Controllers · CCNA

Exam topics covered

6.1 Explain how automation impacts network management

6.2 Compare traditional networks with controller-based networking

6.3 Describe controller-based, software-defined architecture (overlay, underlay, and fabric)

6.3.a Separation of control plane and data plane; 6.3.b Northbound and Southbound APIs

6.4 Explain AI (generative and predictive) and machine learning in network operations

Foundation. For most of networking's history, engineers built networks one box at a time: SSH in, type commands, save, move on. That works for ten devices; it struggles with a thousand. This chapter explains why the industry moved to automation and controllers, how a controller-based network differs from a traditional one, and what plane, northbound, southbound, underlay, overlay and fabric really mean. You will meet Cisco SD-Access (managed by Catalyst Center) and SD-WAN, and finish with the newest v1.1 topic: AI and machine learning in network operations. Domain 6.0 is only 10% of the exam, but its questions are conceptual and very learnable.

33.1 How Automation Changes Network Management

In a traditional network each switch and router is an island: configured through its own CLI, running its own protocols, storing its own configuration. Changes are typed or pasted by a human during a maintenance window, and monitoring relies on SNMP, syslog and show commands. The weaknesses are well known: human error (a typo in an ACL, a VLAN missing from a trunk), configuration drift (devices that should be identical slowly diverge), slow change (a new NTP server on 800 switches takes days), poor visibility (each box only knows about itself) and inconsistent policy.

Network automation uses software to do those tasks instead: provisioning devices, pushing configuration, collecting state, checking compliance and even remediating problems. It ranges from a Python script that collects show version from 50 switches to a controller that turns a business intent into configuration for an entire campus.

Table 33-1 Traditional management compared with automated management

Aspect Traditional (manual, per device) Automated / controller-based Speed of

change

Minutes per device; days for many Hundreds of devices in parallel, in minutes Consistency Depends on the engineer; drift is

common
Same template every time; drift detected and
corrected

Errors Typos and missed steps Validated templates; a bug is fixed once, everywhere

Scale Effort grows with device count Adding devices is cheap

Visibility Per-device show commands,

Snmp

Central inventory, topology, telemetry,

analytics

Skills CLI expertise CLI plus APIs, JSON/YAML, scripting, version control

Automation also changes the engineer's role: instead of typing commands, you write and review templates and playbooks, kept in version control and tested before deployment. This is infrastructure as code (IaC); Chapter 34 covers the tools (Ansible and Terraform).

Exam alert

For “how does automation impact network management”, pick reduced human error, consistency, faster provisioning, scalability and centralized visibility. Automation does not remove the need for network knowledge, and devices still forward packets in their own data plane.

33.2 Data, Control and Management Planes

Networking functions are traditionally divided into three planes, meaning categories of work (Figure 33-1).

Router or switch
Management plane
SSH, Telnet, console, SNMP, syslog,
NETCONF, RESTCONF, gRPC, HTTPS GUI
Control plane

Ospf, bgp, stp, arp, cdp/lldp, lacp

builds routing table, MAC table, ARP table
(the "brain": decides where traffic should go)
Data plane (forwarding plane)
forwards frames/packets using FIB, MAC table
encapsulation, ACL filtering, NAT, QoS marking
programs
Admin /

Nms

Figure 33-1 The three planes of a network device. The control plane builds the tables; the data plane uses them to forward

traffic; the management plane is how people and tools configure and monitor the device. The data plane (forwarding plane) moves user traffic: a switch looks up the destination MAC and forwards the frame; a router looks up the destination IP in its FIB, rewrites the Layer 2 header, decrements TTL and forwards. ACL filtering, NAT and QoS marking are data plane actions too, done per packet, usually in ASICs. The control plane decides how traffic should be forwarded: OSPF, STP, ARP and MAC learning build the tables the data plane consults. The management plane is how people and tools reach the device: console, SSH, SNMP, syslog, NTP, the web GUI, and the APIs NETCONF, RESTCONF and gRPC.

Tip

Happens to every packet? Data plane. A protocol that builds a table? Control plane. How an administrator or tool talks to the box? Management plane. SSH passing through a router is data plane; SSH to the router is management plane.

33.3 Traditional Versus Controller-Based Networking

In a traditional network the control plane is distributed: every OSPF router builds its own LSDB and runs its own SPF; every switch takes part in STP. This is robust, with no single point of failure, but network-wide policy is hard to express and change. Software-defined networking (SDN) and controller-based networking move some or all of the control plane, and most of the management plane, into central software called a controller. The controller has a global view, computes the desired state and programs the devices, which keep forwarding traffic in their own data planes: the separation of control plane and data plane.

Traditional: distributed control Controller-based: centralized control Control

Figure 33-2 Distributed control plane in a traditional network compared with a centralized controller.

Centralization varies. Pure, OpenFlow-style SDN removes nearly all control logic from switches; the controller installs entries in each switch's flow table. Most enterprise products are hybrid: devices still run OSPF, IS-IS, BGP or LISP, while the controller configures them, pushes policy and collects analytics (Catalyst Center with SD-Access is like this; SD-WAN centralizes WAN routing in its controllers).

Table 33-2 Traditional networks compared with controller-based networks

Characteristic Traditional network Controller-based network

Control plane Distributed on every device Centralized (fully or partly) in the controller Configuration Per device, usually CLI Centrally, through controller GUI or API Network view Each device sees only its

No single point of control Controller clustered for availability; devices keep forwarding if it fails

33.4 SDN Architecture: Northbound and Southbound APIs

Every SDN architecture can be drawn as three layers with two interfaces between them. Learn this picture.

(e.g., Catalyst Center, SD-WAN Manager/Controller, APIC, OpenDaylight)

Southbound

OpenFlow API (SBI)

Netconf /

Restconf

gRPC, SSH/CLI,
SNMP, OpFlex
Infrastructure
layer L3

Switches, routers, APs, firewalls: forward traffic (data plane)

Figure 33-3 SDN architecture. Applications talk to the controller through the northbound API; the controller talks to devices through the southbound API.

The northbound interface (NBI) sits above the controller and lets applications, scripts and orchestration tools use its services: one API call such as “list every device running software older than 17.9” replaces logging in to 300 switches. NBIs are almost always REST APIs carrying JSON over HTTPS (Chapter 34); Catalyst Center calls its NBI the Intent API. The southbound interface (SBI) sits below the controller and is how it programs and monitors devices.

Table 33-3 Common southbound protocols

Protocol What it does
Transport /
encoding

OpenFlow ONF standard; controller installs match/action entries in a switch's flow table (classic pure SDN)

TCP 6653, binary

NETCONF IETF (RFC 6241); reads/changes config and state using YANG models; candidate datastore and commit

Ssh, tcp 830;

Xml

RESTCONF IETF (RFC 8040); YANG data through a REST interface and HTTP verbs

HTTPS; XML or

Json

gRPC / gNMI RPC framework used for configuration and model-driven streaming telemetry

HTTP/2; Protocol
Buffers
OpFlex Cisco ACI declarative policy protocol TCP; JSON/XML

Ssh/cli,

Snmp

Legacy interfaces many controllers still use TCP 22; UDP 161

YANG (RFC 7950) is a data modelling language, not a protocol: it describes the structure of configuration and state data. NETCONF, RESTCONF and gNMI all carry YANG-modelled data, which software can parse far more reliably than CLI text. Examples of controllers include OpenDaylight (open source, OpenFlow and NETCONF), Cisco ACI (the APIC controller managing a Nexus spine-leaf data centre fabric through OpFlex), Catalyst Center (campus), Catalyst SD-WAN Manager/Controller (WAN) and the cloud-hosted Meraki dashboard.

Exam alert

Northbound = controller to applications (REST APIs). Southbound = controller to devices (OpenFlow, NETCONF, RESTCONF, gRPC, OpFlex, SSH, SNMP).

33.5 Underlay, Overlay and Fabric

Modern controller-based networks are built in two logical layers on the same equipment. The underlay is the physical network plus a simple routing protocol (often IS-IS or OSPF) giving every device reachability to every other device's loopback; it knows nothing about users or VLANs. The overlay is a virtual network built on top with tunnels: user traffic is encapsulated at one edge, carried across the underlay in an outer IP header and decapsulated at the other edge. Campus and data centre overlays usually use VXLAN; SD-WAN uses IPsec; older examples are GRE and MPLS. The fabric is the whole system (underlay, overlay, control and management) behaving like one giant switch.

Leaf/Edge A 10.255.0.11 Leaf/Edge B 10.255.0.12 Leaf/Edge C 10.255.0.13 Every link is a routed point-to-point link; loopbacks are the tunnel endpoints (VTEPs)

Figure 33-4 A spine-leaf underlay providing IP reachability between loopbacks, with VXLAN overlay tunnels between the edge devices.

The split gives you a simple, fully routed underlay with no spanning tree, while the overlay provides whatever logical connectivity the business needs (stretched Layer 2 segments, separate virtual networks for employees, guests and IoT). VXLAN (RFC 7348) wraps the original Ethernet frame inside UDP. The encapsulating device is a VTEP (VXLAN tunnel endpoint), and the 24-bit VXLAN Network Identifier (VNI) allows about 16 million segments versus 4094 usable VLANs. VXLAN is only a data plane; a control protocol must tell each VTEP which VTEP a host sits behind (BGP EVPN in data centres, LISP in SD-Access). Outer Ethernet

50 bytes of overhead added by the VTEP Payload carried unchanged Underlay MTU is usually raised (for example to 9100 bytes) to absorb the overhead

Figure 33-5 VXLAN encapsulation. The underlay only looks at the outer headers; the original frame is invisible to it.

33.6 Cisco SD-Access

Cisco SD-Access is Cisco's campus fabric, built and operated through Catalyst Center, with Cisco ISE supplying identity and policy. It has three planes of its own:

Control plane: LISP (Locator/ID Separation Protocol) maps each endpoint identifier (EID, the host's IP or MAC) to a routing locator (RLOC, the loopback of its edge node). Edge nodes register and query hosts instead of flooding.

Data plane: VXLAN (VXLAN-GPO, with room for a group tag) between fabric nodes. Policy plane: Cisco TrustSec. ISE assigns each user or device a Scalable Group Tag (SGT), and policy is written as “group A may talk to group B” instead of IP-based ACLs.

Table 33-4 SD-Access fabric roles

Role Function
Fabric edge
node

Access switch for endpoints; anycast default gateway (same gateway IP/MAC on every edge); registers endpoints with LISP; VXLAN encap/decap

Control plane
node
LISP map server/map resolver: the host tracking database

Border node Connects the fabric to outside networks: data centre, WAN, Internet, non-fabric campus

Intermediate
node
Underlay-only router/switch; unaware of the overlay
Fabric WLC /
AP

WLC handles wireless control and registers clients; fabric APs send client data in VXLAN to the edge node, not CAPWAP to the WLC

Vxlan

Fabric edge nodes

connect endpoints, anycast gateway, register EIDs with LISP

Figure 33-6 SD-Access fabric roles. Catalyst Center automates the fabric; ISE supplies identity and group-based policy.

Catalyst Center can build the routed underlay automatically with LAN Automation (IS-IS on point-to-point links), or an existing routed network can serve as underlay. The overlay consists of virtual networks (VNs), essentially VRFs, for macro-segmentation; SGTs provide micro-segmentation within a VN.

Exam alert

SD-Access trio: LISP = control plane, VXLAN = data plane, TrustSec/SGT = policy plane. Catalyst Center (formerly DNA Center) is the controller.

33.7 SD-WAN in Brief

Cisco Catalyst SD-WAN applies the controller model to the WAN. It combines any transports (MPLS, broadband, 4G/5G) into one overlay and steers applications across them by policy and measured path quality. Its components map to planes: SD-WAN Manager (formerly vManage) is the management plane, with GUI, templates and REST API; SD-WAN Controller (formerly vSmart) is the control plane, distributing routes, keys and policy with the Overlay Management Protocol (OMP); SD-WAN Validator (formerly vBond) is the orchestration plane, authenticating devices and helping with NAT traversal; and the WAN Edge routers form the data plane, building IPsec tunnels over every transport and measuring loss, latency and jitter with BFD.

Mpls

Figure 33-7 Cisco Catalyst SD-WAN components. Dashed lines are control connections to the controllers; solid lines are IPsec

data plane tunnels between WAN edges, one per transport. BFD measures each tunnel's loss, latency and jitter. Because the controllers know each path's real-time quality, SD-WAN performs application-aware routing (voice on the lowest-jitter path, backups on the cheapest) and shifts traffic automatically when a path degrades. Zero-touch provisioning lets a new branch router contact the Validator and download its configuration with no engineer on site.

33.8 Catalyst Center and Intent-Based Networking

Cisco Catalyst Center, renamed from Cisco DNA Center in 2023, is a physical or virtual appliance that manages campus and branch networks, fabric or not. Its main functions are discovery, inventory and topology; design and provisioning (site hierarchy, global settings such as DNS, NTP and AAA, IP pools, templates); Plug and Play (PnP) zero-touch onboarding; Software Image Management (SWIM) with golden images; policy (group-based access, application QoS); assurance (health scores, issues with suggested fixes, path trace, AI analytics); and a northbound REST Intent API.

Table 33-5 Traditional campus device management compared with Catalyst Center Task Traditional management With Catalyst Center

Upgrade IOS XE Copy, verify and reload each device SWIM: golden image, pre-checks, scheduled rollout

Security policy ACLs on many devices, tied to IP
addresses
Group-based policy defined once,
enforced by SGT

Network Controller › Assurance › Health | Site: Global / Toronto / HQ-Bldg-1 | Last 24 hours Network health

P1: 1 · P2: 2 · P3: 4

Device health (1–10 scale) Poor (1–3): 4 · Fair (4–7): 12 · Good (8–10): 184 AI-driven baseline Onboarding time above dynamic baseline on floor 3 Priority Issue Device / Location Suggested action

P1 Interface Gi1/0/48 down: uplink
to distribution
HQ-ACC-3F-02 Check cable and SFP; view path trace
P2 Wireless clients failing DHCP HQ / Floor 3 /
SSID Corp
Verify DHCP scope 10.30.3.0/24 utilization

P2 High CPU utilization (91%) HQ-DIST-01 Run CLI command runner: show processes cpu sorted

Figure 33-8 A generic mock-up of a controller assurance dashboard showing network, client and application health with

prioritized issues. (Illustrative layout; not an exact reproduction of any product screen.) Intent-based networking (IBN) means administrators describe what they want and the system works out how, then continuously verifies that reality matches. “Guests reach the Internet but nothing internal” is intent; the ACL, VLAN and VRF lines on 60 switches are the how. In Catalyst Center, design and policy capture intent, provisioning translates and activates it, and assurance closes the loop.

1. Intent

business goal

"isolate IoT devices"

2. Translation

intent to policy

and config

3. Activation

automated push to

devices via SBI

4. Assurance

Figure 33-9 The intent-based networking closed loop.

33.9 AI and Machine Learning in Network Operations

Topic 6.4 is new in v1.1. You need the vocabulary, the difference between predictive and generative AI, and how each helps operate networks. Artificial intelligence (AI) is the broad field of systems that perform tasks needing human-like intelligence. Machine learning (ML) is a subset of AI in which a system learns from data instead of following programmed rules: training builds a model, and inference applies it to new data. Supervised learning uses labelled examples (for example, to classify endpoints); unsupervised learning finds structure in unlabelled data (clustering, learning what “normal” looks like); deep learning uses many-layered neural networks and underpins large language models (LLMs).

Table 33-6 Predictive AI compared with generative AI in network operations Predictive AI Generative AI

Main risk False positives/negatives; model drift Hallucination; leaking sensitive data in prompts

Anomaly detection. Static thresholds (“alert above 80% CPU”) are noisy and miss subtle problems. ML learns a dynamic baseline: the normal range of each metric for each time of day, day of week and site, and flags anything outside it (Figure 33-10).

Figure 33-10 A dynamic baseline learned by ML catches a mid-afternoon anomaly that a fixed threshold would miss.

AIOps (AI for IT operations) applies AI/ML to operational data to collect telemetry, syslog, flows and client events; correlate hundreds of symptoms into one root-cause issue; detect anomalies and compare sites with their peers; predict problems such as a degrading optic or a DHCP scope that will run out on Monday; and recommend or remediate, sometimes automatically through the controller. Examples include Catalyst Center AI network and endpoint analytics and AI-driven radio resource management. Generative AI assistants also help engineers ask natural-language questions of a controller, summarize logs and incidents, draft configuration or scripts for review, and explain unfamiliar output.

WATCH OUT: CAUTIONS FOR AI IN OPERATIONS

Hallucination: an LLM can invent a command or produce subtly wrong configuration with complete confidence; validate in a lab or dry run. Data privacy: configs hold passwords, keys and IP plans; never paste them into unapproved public AI services. Human in the loop: introduce automated remediation gradually, with approvals and rollback. Model drift and explainability: models age as the network changes, and engineers must understand why an alert fired. AI augments engineers; it does not replace networking knowledge.

Exam alert

Forecasting, baselining, anomaly detection or classification = predictive AI/ML. Creating text, code, configuration or summaries from a prompt = generative AI. ML is a subset of AI.

LAB Enable NETCONF and RESTCONF on an IOS XE router

Goal: prepare router R1 (G1 192.168.10.1/24) so an automation host on the same management subnet (192.168.10.50) can manage it through NETCONF (SSH, TCP 830) and RESTCONF (HTTPS). Chapter 34 uses the same router.

Automation host
192.168.10.50
R1 (IOS XE)
G1 192.168.10.1/24

Tcp 830, 443

Figure 33-11 Lab topology: an automation host managing R1 over the management network.

Steps: (1) create a privilege 15 local user and enable AAA; (2) enable NETCONF; (3) enable the HTTPS server and RESTCONF.

R1(config)# username netadmin privilege 15 secret Str0ngP@ss
R1(config)# aaa new-model
R1(config)# aaa authentication login default local
R1(config)# aaa authorization exec default local
R1(config)# netconf-yang ! NETCONF over SSH, TCP 830
R1(config)# ip http secure-server ! HTTPS server for RESTCONF
R1(config)# ip http authentication local
R1(config)# restconf

Verify: after a minute or two the YANG management processes start. (Output in this chapter is illustrative of IOS XE 17.x.)

R1 — ssh

R1# show platform software yang-management process
confd : Running
nesd : Running
syncfd : Running
ncsshd : Running
dmiauthd : Running
nginx : Running
ndbmand : Running
pubd : Running
R1# show netconf-yang status
netconf-yang: enabled
netconf-yang ssh port: 830
netconf-yang candidate-datastore: disabled

Figure 33-12 The confd process serves NETCONF; nginx serves RESTCONF over HTTPS.

Expected results: ssh -p 830 netadmin@192.168.10.1 -s netconf returns a NETCONF

<hello> listing capabilities, and an HTTPS GET to /restconf/data/ietf-interfaces:interfaces returns the interfaces as YANG-modelled JSON or XML.

Sdn

controller
northbound API
southbound API
OpenFlow

Netconf / restconf

Yang

underlay
overlay
fabric

Vxlan / vni

Lisp

SD-Access

Sd-wan

1. Which plane of a router builds the routing table by exchanging OSPF LSAs?

A. Data plane
B. Control plane
C. Management plane
D. Forwarding plane

2. An engineer connects to a switch with SSH to change its configuration. Which plane is being used?

A. Data plane
B. Control plane
C. Management plane
D. Overlay plane

3. Which two statements describe the impact of automation on network management? (Choose two.)

A. It reduces configuration errors caused by manual entry.
B. It removes the need for a data plane on network devices.
C. It allows consistent configuration to be deployed to many devices quickly.
D. It requires every device to run OpenFlow.
E. It eliminates the need to understand networking protocols.

4. Which interface does a Python application use to request a device inventory from an SDN controller?

A. Southbound API
B. Northbound API
C. Eastbound API
D. Console port

5. Which two protocols are examples of southbound interfaces? (Choose two.)

A. NETCONF
B. SMTP
C. OpenFlow
D. HTTP basic authentication
E. DHCP

6. What is the main characteristic of a controller-based network compared with a traditional network?

A. Each device computes its forwarding decisions independently.
B. Control plane functions are centralized in software with a global view of the network.
C. The data plane runs in the controller.
D. Devices no longer need IP addresses.

7. In a software-defined fabric, what is the underlay?

A. The virtual networks built with tunnels for user traffic
B. The physical network providing IP reachability between nodes
C. The northbound API layer
D. The policies stored in the controller

8. Which protocol provides the control plane in Cisco SD-Access?

A. VXLAN
B. OMP
C. LISP
D. OpFlex

9. Which SD-Access node connects the fabric to external networks such as the WAN?

A. Edge node
B. Intermediate node
C. Border node
D. Control plane node

10. Which Cisco SD-WAN component provides the control plane and distributes routes with

Omp?

A. SD-WAN Manager
B. SD-WAN Validator
C. SD-WAN Controller
D. WAN Edge

11. Which capability is an example of predictive AI in network operations?

A. Drafting a configuration template from a natural-language request
B. Summarizing a long incident report
C. Learning a dynamic baseline and flagging unusual client onboarding times
D. Writing a Python script to back up configurations

12. Which two are valid concerns when using generative AI to create network configurations? (Choose two.)

A. The output may contain plausible but incorrect commands.
B. Generative AI cannot produce text output.
C. Sensitive configuration data could be exposed if pasted into an unapproved service.
D. Generative AI only works with SNMP data.
E. Generated configuration is always validated automatically.

13. Which Catalyst Center feature defines a golden image and upgrades devices to it?

A. Plug and Play
B. SWIM
C. Path trace
D. LAN Automation

Answers

1. B. Routing protocols are control plane functions; the data plane uses their output to forward packets.
2. C. SSH, SNMP, console and APIs used to configure and monitor a device are management plane.
3. A, C. Automation reduces human error and delivers consistent, fast change. Devices still forward traffic, OpenFlow is not required, and protocol knowledge is still needed.
4. B. Applications reach the controller through the northbound API, typically REST with JSON.
5. A, C. NETCONF and OpenFlow program devices. SMTP, DHCP and an authentication method are not SBIs.
6. B. The controller centralizes control with a global view; devices keep their own data planes.
7. B. The underlay is the physical routed network; the overlay is the tunnel-based virtual network on top.
8. C. LISP maps endpoint IDs to edge-node locators. OMP is SD-WAN; OpFlex is ACI; VXLAN is the data plane.
9. C. Border nodes connect the fabric to outside networks; edge nodes connect endpoints.
10. C. The SD-WAN Controller (vSmart) runs OMP. Manager is management, Validator is orchestration, WAN Edges are data plane.
11. C. Baselining and anomaly detection are predictive uses of ML. The others create new content (generative AI).
12. A, C. Hallucination and data leakage are the main cautions; output is never automatically trustworthy.
13. B. SWIM manages golden images and upgrades. PnP onboards devices; LAN Automation builds the SD-Access underlay.