Controller-Based Networking

1. What Is Controller-Based Networking?

Controller-based networking is a modern network architecture where a central software platform — the controller — takes responsibility for network-wide intelligence, policy enforcement, and device management. Instead of each switch, router, or access point independently making its own forwarding and configuration decisions, those decisions are centralised in the controller, while the devices themselves focus purely on forwarding traffic according to the controller's instructions.

The core concept is the separation of two traditionally co-located functions:

Control plane: The decision-making logic — what to do with traffic, where to forward it, what policies apply. In controller-based networking, this moves to the centralised controller.
Data plane (forwarding plane): The actual movement of packets/frames through the device based on the rules provided by the control plane. This stays distributed on the physical devices.

Why it matters for CCNA: Controller-based networking underpins Cisco's entire modern portfolio — Catalyst Centre (formerly DNA Center) for enterprise LANs, Cisco WLC for wireless, and SD-WAN for wide area networks. The CCNA exam explicitly tests SDN architecture, plane separation, and the APIs that connect controller layers.

2. Traditional vs. Controller-Based Networking

Understanding the contrast between traditional distributed networking and controller-based architecture is one of the most commonly tested CCNA topics in this domain.

Aspect	Traditional Networking	Controller-Based Networking
Configuration method	CLI — log into each device individually (SSH, console)	Centralised — configure once on controller, pushed to all devices
Control plane location	Distributed — every device runs its own routing/switching protocols	Centralised — controller holds the control plane logic
Data plane location	Local — device forwards using its own locally computed tables	Local — device still forwards at hardware speed using controller-provided rules
Policy changes	Manual — change each device one at a time; risk of inconsistency	Atomic — change defined once, applied simultaneously to all devices
Scalability	Linear effort — every new device requires individual configuration	Sub-linear — controller pushes configuration; new devices auto-register
Visibility	Per-device — operators must query each device separately	Network-wide — controller aggregates telemetry from all devices in one view
Automation	Requires scripts per-device (Ansible, Netmiko, Paramiko)	Native — controller exposes APIs for orchestration platforms
Human error risk	High — mistyped config on one device can break the network	Lower — controller validates policy before pushing; template-based

Real-world example: A company needs to add VLAN 50 across 40 access switches in a campus. Traditional approach: SSH to all 40 switches, repeat the same VLAN commands, verify each one individually — 1–2 hours of work with risk of typos. Controller-based approach (Cisco Catalyst Centre): define VLAN 50 in the controller UI once, select all 40 switches, click deploy — done in under 2 minutes, identical on every switch, logged in the controller audit trail.

3. The SDN Architecture — Three-Layer Model

Software-Defined Networking (SDN) formalises controller-based networking into a three-layer architecture. Each layer communicates with the adjacent layer through defined interfaces. See Northbound & Southbound Interfaces for a full deep dive.

  ┌─────────────────────────────────────────────────────────────┐
  │              APPLICATION LAYER                              │
  │  Business applications, orchestration tools, dashboards,   │
  │  security platforms, analytics engines                      │
  │  (e.g., Ansible, Terraform, custom scripts, ITSM tools)     │
  └──────────────────────┬──────────────────────────────────────┘
                         │  Northbound Interface
                         │  (REST APIs, NETCONF, gRPC, YANG)
  ┌──────────────────────┴──────────────────────────────────────┐
  │              CONTROL LAYER                                  │
  │  SDN Controller — network brain                             │
  │  Topology awareness, policy engine, path computation,       │
  │  device provisioning, monitoring, analytics                 │
  │  (e.g., Cisco Catalyst Centre, OpenDaylight, ONOS)          │
  └──────────────────────┬──────────────────────────────────────┘
                         │  Southbound Interface
                         │  (OpenFlow, NETCONF, RESTCONF, CAPWAP, SNMP)
  ┌──────────────────────┴──────────────────────────────────────┐
  │              INFRASTRUCTURE LAYER                           │
  │  Network devices — data plane only                          │
  │  Switches, routers, access points, firewalls                │
  │  Forward traffic according to controller-installed rules    │
  └─────────────────────────────────────────────────────────────┘

The Three Interfaces

Interface	Direction	Purpose	Examples
Northbound Interface (NBI)	Controller → Applications (upward)	Exposes controller capabilities to orchestration tools, apps, and automation scripts. Applications consume the controller's data and send instructions.	REST API, NETCONF, gRPC, YANG models, Cisco DNA Center API. See Northbound & Southbound Interfaces.
Southbound Interface (SBI)	Controller → Devices (downward)	Controller communicates with managed network devices to push configuration, read state, and install forwarding rules.	OpenFlow, NETCONF/RESTCONF, CAPWAP, SNMP, SSH/CLI (legacy)
East/West Interface	Controller ↔ Controller (peer)	Communication between multiple controllers in a distributed deployment — sharing topology, policy, and state for scalability and redundancy.	Proprietary protocols; BGP in some SD-WAN architectures

4. Types of Controllers

Wireless LAN Controller (WLC)

The WLC is the most commonly encountered controller in enterprise networks and a direct CCNA exam topic. It centralises management of all lightweight access points (APs) using the CAPWAP (Control and Provisioning of Wireless Access Points) protocol. See Access Points & WLC for a full guide and WLC Getting Started for hands-on labs.

APs operate in lightweight mode — they handle only the physical radio and frame transmission (data plane). All decisions about SSIDs, authentication, client association, roaming, RF power, and channel are made by the WLC (control plane).
APs discover the WLC via DHCP Option 43, DNS resolution of "CISCO-CAPWAP-CONTROLLER", or broadcast on the local subnet.
All client traffic is tunnelled back to the WLC via CAPWAP (in centralized mode) before being forwarded to the wired network.
The WLC enables seamless roaming — when a client moves between APs, the WLC maintains the session without re-authentication.
In FlexConnect mode, APs can locally switch traffic even if the WAN link to the WLC fails. See FlexConnect AP Configuration.

  Client ──WiFi──▶ AP (Lightweight)
                      │
                 CAPWAP Tunnel
                      │
                 ┌────┴────┐
                 │   WLC   │ ← Control plane: manages all APs
                 └────┬────┘
                      │
               Wired Network / Internet

See: Access Points & WLC — Full Guide

SDN Controllers

SDN controllers manage both wired and wireless infrastructure through programmatic southbound interfaces rather than CLI. They provide a centralised view of the entire network topology and enable policy-driven automation.

Cisco Catalyst Centre (formerly DNA Center): Cisco's enterprise SDN controller for campus and branch networks. Provides intent-based networking, automated provisioning, assurance analytics, and SD-Access (software-defined access with SGTs).
OpenDaylight (ODL): Open-source Java-based SDN controller with a modular architecture. Widely used in service provider and data centre environments.
ONOS (Open Network Operating System): Open-source controller designed for carrier-grade scalability and high availability.
VMware NSX: Data centre SDN controller providing network virtualisation, micro-segmentation, and distributed firewalling for VM workloads.

SD-WAN Controllers

SD-WAN (Software-Defined WAN) applies controller-based principles to wide-area connectivity. A central orchestrator manages WAN edge devices across multiple sites, dynamically routing traffic across multiple transport links (MPLS, broadband, LTE) based on application policy.

Cisco SD-WAN (formerly Viptela): vManage (orchestration), vSmart (control plane), vBond (onboarding), vEdge/cEdge (data plane devices).
Controllers automatically select the best WAN path per application — video calls prefer low-latency links; bulk transfers use high-bandwidth cheaper broadband.

5. Southbound Protocols — Controller to Device Communication

Southbound protocols are how the controller communicates downward to managed devices — pushing configuration, reading operational state, and installing forwarding rules. See Northbound & Southbound Interfaces for detailed coverage.

Protocol	Type	Description	Use Case	Data Format
OpenFlow	SDN-specific	Directly programs flow tables in OpenFlow-enabled switches, telling them exactly how to handle each type of traffic. The original and most fundamental SDN southbound protocol.	Pure SDN environments, academic networks, data centre automation	Binary protocol (TLV)
NETCONF	Standard (RFC 6241)	Network Configuration Protocol — transports structured configuration data to/from devices. Runs over SSH. Uses YANG data models to describe device capabilities. Supports transactions with commit/rollback.	Automated device configuration, IOS XE/XR/NX-OS management. See RESTCONF Basics.	XML
RESTCONF	Standard (RFC 8040)	HTTP-based equivalent of NETCONF. Uses REST operations (GET, POST, PUT, PATCH, DELETE) with YANG models. Easier to use from scripts and web applications.	Lightweight automation, integration with web-based tools. See RESTCONF Basics (Step-by-Step).	XML or JSON
CAPWAP	Wireless-specific (RFC 5415)	Control and Provisioning of Wireless Access Points. UDP-based tunnelling protocol that carries both control messages (AP management) and data traffic between APs and the WLC. Uses DTLS encryption for the control channel.	Cisco WLC ↔ Lightweight AP communication. See Access Points & WLC.	Binary/UDP
SNMP	Legacy (RFC 1157+)	Simple Network Management Protocol — polling-based monitoring. Reads device MIBs for status information and can write configuration (v2c/v3). Largely superseded by NETCONF/RESTCONF for configuration but still widely used for monitoring.	Status monitoring, fault alerting, legacy device management	ASN.1/BER
gRPC / gNMI	Modern streaming	Google Remote Procedure Call — used with gNMI (gRPC Network Management Interface) for high-speed streaming telemetry. Devices push real-time operational data to the controller without being polled.	Streaming telemetry, real-time analytics, modern IOS XE/XR	Protobuf

6. Northbound Interfaces — Controller to Application Communication

Northbound interfaces expose the controller's capabilities upward to orchestration tools, automation scripts, dashboards, and business applications. They abstract the underlying network complexity into a programmable API. See Northbound & Southbound Interfaces for a full conceptual overview.

REST API — The Dominant Northbound Interface

REST (Representational State Transfer) APIs are the most common northbound interface used by modern controllers. They use standard HTTP methods over HTTPS and return data in JSON or XML format — making them consumable by virtually any programming language or tool. See REST APIs in Networking for a full explanation.

HTTP Method	Operation	Example Use
`GET`	Read/retrieve data	Get a list of all devices managed by Cisco Catalyst Centre
`POST`	Create a new resource	Create a new VLAN policy on the controller
`PUT`	Replace/update a resource completely	Replace the full configuration of a site profile
`PATCH`	Partially update a resource	Update only the QoS policy within an existing network design
`DELETE`	Remove a resource	Delete a decommissioned site from the controller inventory

Cisco Catalyst Centre REST API Example

# Authenticate and get a token
POST https://catalyst-centre-ip/dna/system/api/v1/auth/token
Authorization: Basic <base64-credentials>
→ Returns: {"Token": "eyJhbGciOiJSUzI1NiIsInR5c..."}

# Get all network devices (using token)
GET https://catalyst-centre-ip/dna/intent/api/v1/network-device
X-Auth-Token: eyJhbGciOiJSUzI1NiIsInR5c...
→ Returns JSON array of all managed devices with hostname, IP, type, status

Other Northbound Interfaces

NETCONF (over northbound): Some controllers expose NETCONF northbound for integration with other management platforms that speak NETCONF natively.
YANG models: Not a protocol themselves, but define the data structure that NETCONF and RESTCONF APIs use — think of them as a schema or data model for network device configuration and state.
Python SDK / Ansible modules: Many controllers provide language-specific libraries that wrap the REST API for easier automation scripting.

See: NETCONF & RESTCONF Explained | REST APIs in Networking | Network Automation Overview | RESTCONF Basics (Step-by-Step)

7. Control Plane vs. Data Plane — The Core Distinction

The control/data plane separation is the architectural foundation of all controller-based and SDN solutions. The CCNA exam tests this distinction frequently.

Plane	What It Does	Traditional Location	Controller-Based Location	Examples
Control Plane	Makes decisions about where to send traffic — builds routing tables, STP topology, ACL logic, QoS policy	Distributed — runs on every device (OSPF, STP, etc.)	Centralised — runs on the controller; devices receive the results	OSPF SPF calculation, STP root election, BGP best-path, ACL evaluation
Data Plane	Moves packets/frames as fast as possible using the tables built by the control plane	Local hardware (ASIC, CAM, FIB) on the device	Still on the device — hardware forwarding is too fast to centralise	Layer 2 switching, IP forwarding, MPLS label swapping
Management Plane	Administrative access to the device — SSH, SNMP, syslog, NTP sync	On the device (management interface)	Often managed centrally through controller (but still present locally)	SSH login, SNMP polling, NETCONF sessions, syslog messages

Critical exam point: In controller-based networking, if the controller fails, existing forwarding continues — the data plane keeps working based on the rules already installed. However, no new policy changes, re-routing decisions, or automated responses can occur until the controller recovers. This is why controller high availability matters.

8. Cisco Catalyst Centre (DNA Center) — Enterprise Controller

Cisco Catalyst Centre (formerly Cisco DNA Center — Digital Network Architecture Center) is Cisco's primary enterprise SDN controller. It provides intent-based networking — administrators express what they want the network to do in business terms, and the controller figures out how to configure the devices to achieve it.

Key Catalyst Centre Capabilities

Capability	Description
Design	Define the network hierarchy (global → area → building → floor), VLAN/IP addressing schemes, DNS, NTP, AAA servers — the "intent" for all sites
Policy	Define access policies using Scalable Group Tags (SGTs) — e.g., "HR devices can only reach HR servers" expressed as a business rule, not ACL syntax
Provision	Automated device onboarding (PnP — Plug and Play), configuration templates, zero-touch deployment for new sites and devices
Assurance	Continuous monitoring of network health using streaming telemetry — identifies issues before users report them, with root-cause analysis
Platform	REST API for integration with ITSM tools (ServiceNow), security platforms (Cisco ISE), and custom automation scripts

SD-Access with Catalyst Centre

SD-Access (Software-Defined Access) is Cisco's campus network automation solution built on Catalyst Centre. It creates a virtual overlay network (using VXLAN and LISP) on top of the physical underlay, enabling consistent policy enforcement regardless of where a user or device connects.

  SD-Access Architecture:
  ┌─────────────────────────────────────────────────┐
  │  Catalyst Centre (Controller + Policy Engine)   │
  └────────────────────┬────────────────────────────┘
              Southbound (NETCONF/RESTCONF)
  ┌─────────────────────────────────────────────────┐
  │  Control Plane Node (LISP — location/identity)  │
  └────────────────────┬────────────────────────────┘
  ┌─────────────────────────────────────────────────┐
  │  Fabric Edge Nodes (Access switches/APs)        │
  │  VXLAN overlay carries traffic between nodes    │
  └─────────────────────────────────────────────────┘
  User connects anywhere → same policy follows them

9. Benefits of Controller-Based Networking

Benefit	Detail	Real-World Impact
Simplified management	One interface to manage all devices — no more CLI device by device	Ops team of 3 engineers manages 500 switches across 10 sites
Policy consistency	Single policy definition pushed identically to all devices atomically	Security policy enforced uniformly — no device missed or misconfigured
Faster deployment	Zero-touch provisioning — new devices auto-register and self-configure	New branch office brought online in hours instead of days
Network-wide visibility	Controller aggregates telemetry from all devices — single pane of glass	Identify a client experiencing poor Wi-Fi without touching the AP
Automated remediation	Controller can detect and fix issues automatically (e.g., rogue AP isolation)	Security incidents contained automatically without human intervention
Programmability	REST APIs enable integration with ITSM, IPAM, security, and cloud platforms	Network changes triggered automatically by ServiceNow ITSM tickets
Audit trail	All changes logged centrally with timestamp, user, and before/after state. Forward to an external SIEM via syslog.	Compliance requirements met; rapid root cause analysis for outages

10. Challenges and Limitations

Challenge	Impact	Mitigation
Single point of failure	If the controller becomes unavailable, no new automated changes can be made. Existing forwarding continues but the network is "frozen" — no policy updates, no new device registrations, no automated healing	Deploy controller clusters with high availability (HA); Cisco Catalyst Centre supports 3-node clusters for redundancy
Controller scalability	A single controller instance has limits on how many devices it can manage. Very large networks may exceed these limits	Horizontal scaling with controller clusters; hierarchical deployment with regional controllers reporting to a central orchestrator
Vendor interoperability	Some controllers only support their own vendor's devices. OpenFlow promised multi-vendor support but adoption was inconsistent	Use open standards (NETCONF/RESTCONF with YANG) which have broader support; evaluate controller compatibility before deployment
Southbound channel dependency	If the network path between a device and controller is disrupted, the device loses contact and cannot receive new policies	Design the management network (out-of-band) separately from the data network; ensure controller reachability is redundant. Use a dedicated management VLAN.
Complexity and skills gap	Controller-based networking requires new skills — REST API programming, intent-based design, YANG models — that traditional network engineers may lack	Training and upskilling; phased adoption starting with simpler automation use cases before full SDN deployment
Migration cost	Replacing legacy infrastructure with controller-compatible hardware and software is expensive and disruptive	Phased migration; hybrid mode where some devices are controller-managed and others remain traditional during transition

11. Security Considerations

A controller-based network has a high-value target — the controller. Compromising the controller gives an attacker control of the entire network. Security must be layered across the controller itself, its communication channels, and access controls.

Controller Security Best Practices

Security Measure	Implementation
TLS/SSL for all communication	All controller-to-device (southbound) and controller-to-application (northbound) communication must use TLS — never plain HTTP or unencrypted management protocols
Strong authentication	Role-Based Access Control (RBAC) for controller admin accounts; integrate with RADIUS/TACACS+ for centralised authentication; enforce MFA for admin access. See AAA RADIUS Configuration.
API authentication	Northbound API calls authenticated with tokens (OAuth 2.0, API keys); tokens must expire and be rotated; never embed credentials in scripts
Network isolation	Place controller in a dedicated management VLAN/VRF; restrict access via ACLs to only authorised management hosts; consider out-of-band management network
Software patching	Keep controller software updated — vulnerabilities in the controller affect the entire managed network; schedule maintenance windows for updates
Certificate management	Use PKI certificates for device-to-controller mutual authentication (not just password); CAPWAP uses DTLS certificates for AP-to-WLC authentication
Audit logging	Enable comprehensive audit trails — all configuration changes, API calls, and admin logins logged to an external SIEM; enables forensic investigation. See show logging.
Controller HA	Redundant controller deployment prevents the controller from being a denial-of- service target that takes down network management

12. Troubleshooting Controller-Based Networks

Troubleshooting in a controller-based network follows a different flow than traditional CLI- based diagnosis. The controller is the primary diagnostic tool, but device-level verification is still essential when controller-to-device connectivity fails.

Common Issues and Diagnostics

Symptom	Likely Cause	Diagnostic Steps
Device not appearing in controller inventory	Device cannot reach controller; wrong controller IP in DHCP Option 43; firewall blocking CAPWAP/NETCONF port	Ping controller from device; check DHCP Option 43 config; verify firewall/ACL rules allow UDP 5246/5247 (CAPWAP) or TCP 830 (NETCONF)
Policy not applied to device after change	Controller-to-device southbound communication failed; device in unmanaged state; template error	Check controller event logs and syslog; verify device managed status; view deployment history for error messages
AP not joining WLC	CAPWAP tunnel cannot establish; AP in wrong VLAN; DTLS certificate mismatch; WLC at capacity	`show capwap client rcb` on AP (if accessible); check WLC AP join logs; verify AP management VLAN reachability to WLC. See Access Points & WLC.
REST API calls returning 401 Unauthorized	Authentication token expired; incorrect credentials; account locked	Re-authenticate and get a new token; check token expiry; verify API account permissions in RBAC settings. See AAA Authentication Methods.
Controller UI showing device as "unreachable"	Network path from controller to device failed; device rebooted; southbound protocol session dropped	Ping device from controller; check interface status on device with SSH; re-establish southbound session if needed

Troubleshooting with Cisco Catalyst Centre

Key diagnostic locations in Catalyst Centre UI:
• Assurance → Network Health: Per-device health scores and issues
• Assurance → Client 360: End-to-end client experience analysis
• Provision → Device Inventory: Device managed/unmanaged status
• Activity → Audit Logs: All changes with timestamps and status
• Platform → Developer Toolkit: Test API calls interactively

13. Popular Controller Platforms — Reference

Controller	Vendor	Domain	Key Features
Cisco Catalyst Centre (DNA Center)	Cisco	Enterprise campus & branch	Intent-based networking, SD-Access, Assurance telemetry, PnP, REST API
Cisco WLC (9800 series)	Cisco	Enterprise wireless	CAPWAP AP management, seamless roaming, SSID policy, RF management. See WLC Getting Started.
Cisco SD-WAN (vManage)	Cisco (Viptela)	Wide area network	Application-aware routing, ZTP, multi-transport (MPLS/broadband/LTE), analytics
OpenDaylight (ODL)	Open-source (Linux Foundation)	Service provider, data centre	Modular Java platform, multi-vendor, OpenFlow + NETCONF support
ONOS	Open-source (ONF)	Carrier-grade	High availability, distributed clustering, carrier and peering automation
VMware NSX	VMware (Broadcom)	Data centre virtualisation	Network virtualisation, micro-segmentation, distributed firewalling for VMs
Aruba Central	Aruba (HPE)	Enterprise wireless & wired	Cloud-managed APs, switches, SD-WAN; AI-powered analytics

14. Common Misconceptions

"If the controller fails, the network stops working."
Not entirely. The data plane continues operating — devices keep forwarding traffic based on the rules already installed. What stops is the ability to make new automated policy changes, provision new devices, or trigger automated responses. Basic connectivity is maintained, but the network is effectively frozen in its last known state.
"SDN means all traffic goes through the controller."
No — forwarding traffic through the controller would create a catastrophic bottleneck. Only control messages (policy, configuration, telemetry) flow between controller and devices. Data traffic flows directly between devices at hardware speed. The separation of control and data planes specifically prevents this scenario.
"NETCONF and RESTCONF are northbound interfaces only."
NETCONF and RESTCONF serve as both southbound interfaces (controller to device) and northbound interfaces (application to controller), depending on context. When Catalyst Centre uses NETCONF to push config to a Catalyst 9000 switch, that is southbound. When a Python script queries Catalyst Centre via RESTCONF, that is northbound. See Northbound & Southbound Interfaces.
"OpenFlow is the only SDN protocol."
OpenFlow was the first and most prominent SDN southbound protocol, but it is just one option. NETCONF/RESTCONF with YANG models are now more widely deployed for device management. Many enterprise SDN deployments use no OpenFlow at all.
"Controller-based networking eliminates all CLI work."
Controllers significantly reduce routine CLI work but do not eliminate it. SSH/CLI access to individual devices is still essential for troubleshooting connectivity between the device and controller, emergency recovery when the controller is unavailable, and low-level diagnostics that the controller doesn't expose. See Python Netmiko for SSH-based automation that bridges the gap.

15. Key Points & Exam Tips

Core concept: Controller-based networking separates the control plane (centralised in the controller) from the data plane (distributed on devices).
Three SDN layers: Application layer (northbound) → Control layer (controller) → Infrastructure layer (devices, southbound). See SDN and Northbound & Southbound Interfaces.
Northbound = controller to applications/automation (REST API, NETCONF, YANG).
Southbound = controller to devices (OpenFlow, NETCONF, RESTCONF, CAPWAP, SNMP).
OpenFlow directly programs switch flow tables — the original SDN southbound protocol.
NETCONF (XML over SSH) and RESTCONF (HTTP/JSON) use YANG data models for structured configuration — increasingly preferred over OpenFlow for enterprise. See RESTCONF Basics (Step-by-Step).
CAPWAP is the WLC-to-AP protocol — carries both control and data traffic in a UDP tunnel with DTLS encryption on the control channel. See Access Points & WLC.
WLC centralises wireless control plane — APs in lightweight mode have no local control intelligence; they just forward frames and tunnel back to the WLC.
Cisco Catalyst Centre (DNA Center) is Cisco's enterprise SDN controller — intent-based, supports SD-Access, Assurance, and PnP.
Controller failure: data plane keeps working but no new policies or provisioning until the controller recovers.
Security: always TLS for southbound and northbound; ACL/VLAN isolation for the controller; RADIUS/TACACS+ for admin auth; audit to syslog. Controller is a high-value attack target.
Traditional CLI automation (Netmiko, Ansible) lacks transaction support and structured data — controller-based NETCONF/RESTCONF is more robust.

16. Controller-Based Networking Quiz

1. A network engineer is designing a campus SDN deployment. She wants automation scripts to programmatically query the controller for device inventory and push policy changes. Which interface of the SDN architecture does this describe, and what protocol would typically be used?

A. Southbound interface using OpenFlow — scripts communicate directly with switches B. East/West interface using BGP — controllers exchange inventory between themselves C. Southbound interface using CAPWAP — used for all external integrations D. Northbound interface using a REST API — applications and scripts interact with the controller through this interface

Correct answer is D. The northbound interface (NBI) sits between the controller and the application/automation layer — above the controller. It exposes the controller's capabilities to automation scripts, dashboards, and orchestration tools via REST APIs (and sometimes NETCONF). Southbound interfaces go downward from the controller to managed network devices. Scripts querying the controller and pushing policies are classic northbound API interactions. See Northbound & Southbound Interfaces.

2. A company runs Cisco Catalyst Centre managing 200 switches. The controller server experiences a hardware failure and goes offline. What immediately happens to network traffic flowing between users and servers?

A. All traffic stops — switches cannot forward without the controller providing real-time forwarding decisions B. Existing traffic continues — switches forward based on rules already installed in their data planes, but no new policy changes or provisioning can occur until the controller recovers C. Switches automatically revert to traditional distributed mode and re-run OSPF/STP independently D. Traffic is re-routed through a backup controller in the cloud automatically

Correct answer is B. This is a critical architectural concept: the data plane is distributed and local to each device. Switches store the forwarding rules (flow table entries, FIBs, CAM tables) locally in hardware. When the controller fails, the data plane keeps forwarding based on what was already programmed. What ceases is the control plane intelligence — no new policy changes, no automated responses to topology changes, no new device registrations. The network is functional but "frozen" at its last configured state.

3. A Cisco lightweight AP cannot join the WLC. The AP is powered on and shows a link light, but the WLC inventory shows it as "Not Joined." Which protocol's failure is the most likely root cause?

A. OpenFlow — the AP is trying to join via an SDN controller instead of the WLC B. NETCONF — the WLC uses NETCONF to manage APs and the session failed C. CAPWAP — the tunnel between the AP and WLC could not be established, possibly due to the AP not getting WLC IP from DHCP Option 43, a firewall/ACL blocking UDP 5246/5247, or a DTLS certificate issue D. SNMP — the WLC cannot poll the AP's status

Correct answer is C. Lightweight APs use CAPWAP (Control and Provisioning of Wireless Access Points) on UDP ports 5246 (control) and 5247 (data) to discover and register with a WLC. The AP learns the WLC's IP address via DHCP Option 43 (most common), DNS lookup of "CISCO-CAPWAP-CONTROLLER", or local subnet broadcast. Common join failures include missing or incorrect DHCP Option 43, a firewall/ACL blocking UDP 5246/5247, DTLS certificate mismatch, or the AP being in the wrong VLAN with no routed path to the WLC. See Access Points & WLC.

4. What is the fundamental difference between NETCONF and OpenFlow as SDN southbound protocols, and when would you use each?

A. NETCONF is a general-purpose configuration protocol using XML over SSH for structured device management; OpenFlow directly programs switch flow tables with specific forwarding rules. NETCONF is used for enterprise device configuration; OpenFlow for data-centre SDN with OpenFlow-capable hardware B. OpenFlow runs over HTTPS while NETCONF runs over UDP — making OpenFlow more secure C. NETCONF is proprietary to Cisco while OpenFlow works with all vendors D. They are functionally identical — just different names for the same protocol

Correct answer is A. NETCONF (RFC 6241) is a general- purpose network management protocol that carries structured configuration and state data (using YANG models) over an SSH session — it can configure any aspect of a device (interfaces, routing, QoS, security) on any NETCONF-capable device. OpenFlow is purpose- built for SDN: it directly installs flow table entries in switch ASICs, telling them precisely how to handle specific traffic flows. OpenFlow requires hardware support for OpenFlow-capable flow tables. In practice, NETCONF/RESTCONF is far more widely deployed in enterprise networks today. See RESTCONF Basics.

5. A Python automation script sends:
`GET https://catalyst-centre/dna/intent/api/v1/network-device`
with a valid X-Auth-Token header. Which SDN plane and which interface is this interaction using?

A. Data plane — the script is querying switch forwarding tables via the southbound interface B. Control plane — the script is modifying routing decisions via the southbound interface using REST C. Application layer interacting with the control layer via the northbound REST API — the script queries the controller, not the devices directly D. Management plane — HTTPS is only used for management plane access

Correct answer is C. Cisco Catalyst Centre exposes its northbound REST API at the /dna/intent/api path. A script calling this endpoint is operating at the application layer of the SDN architecture, interacting with the control layer (the controller) via the northbound interface. The controller — not the script — then communicates with the actual switches via the southbound interface. The script never communicates directly with network devices; it always goes through the controller's API. See Northbound & Southbound Interfaces.

6. Which statement correctly describes the role of YANG in controller-based networking?

A. YANG is a transport protocol that carries XML data over TCP between the controller and devices B. YANG is a data modelling language that defines the structure and constraints of configuration and state data — used by NETCONF and RESTCONF to ensure both sides agree on data format C. YANG is Cisco's proprietary protocol for communicating between Catalyst Centre and Cisco switches only D. YANG replaces SNMP entirely and is used for polling device status via GET requests

Correct answer is B. YANG (Yet Another Next Generation) is a data modelling language (RFC 6020/7950) that describes the structure, types, constraints, and relationships of network device configuration and operational state. Think of YANG as a schema — it defines what data looks like, but does not transport it. NETCONF and RESTCONF use YANG models as the basis for their data payloads, ensuring that both the controller and device agree on the structure of configuration data. Open YANG models (OpenConfig, IETF) enable multi-vendor interoperability.

7. In an SD-Access deployment with Cisco Catalyst Centre, a user authenticates from a different floor than usual. The same access policy still applies to the user. Which SD-Access feature enables this location-independent policy enforcement?

A. Static VLAN assignment per floor — all users on the floor get the same VLAN and policy B. ACLs applied to each switch port individually — same ACL on every port C. DHCP reservations that assign the same IP regardless of location D. Scalable Group Tags (SGTs) — policy is bound to the user's identity, not their physical location; the tag follows the user wherever they connect

Correct answer is D. SD-Access uses Scalable Group Tags (SGTs) to assign policy based on user identity (authenticated via Cisco ISE using AAA/RADIUS) rather than network location (IP address or VLAN). When the user authenticates, ISE assigns their SGT. Catalyst Centre enforces policy based on source SGT to destination SGT — regardless of which floor or building the user connects from. This is the core "intent-based" abstraction: policy defined in business terms ("HR users can access HR servers") not in network terms ("VLAN 30 can reach subnet 10.10.30.0/24"). See AAA RADIUS Configuration.

8. A security audit finds that the Catalyst Centre REST API is accessible from any workstation on the corporate LAN using only a username and password via plain HTTP. What are the two most critical security improvements needed?

A. Enforce HTTPS/TLS for all API communication, and restrict API access via ACLs/firewall rules to only authorised management hosts or a dedicated management VLAN/network B. Change the admin password and move the controller to a different IP address C. Enable SNMP v2c polling and disable REST API access entirely D. Add more network devices to the controller to distribute the attack surface

Correct answer is A. The two critical flaws are: (1) plain HTTP — all API traffic including credentials and configuration data is transmitted in cleartext, trivially interceptable. The fix is TLS (HTTPS) for all API communication. (2) No access restriction — any corporate LAN workstation can reach the controller API, meaning any compromised workstation is one credential away from controlling the entire network. The fix is isolating the controller in a management network segment with ACLs/ firewall rules permitting access only from authorised admin workstations and automation servers. The controller is the highest-value target in a controller-based network. See AAA Authentication Methods for RBAC and RADIUS integration.

9. RESTCONF is described as the "HTTP equivalent" of NETCONF. Which statement most accurately distinguishes the two protocols?

A. NETCONF uses JSON while RESTCONF uses XML — the only difference is the data format B. RESTCONF supports YANG models while NETCONF does not C. NETCONF uses RPC operations over SSH sessions with XML payloads and supports transaction-based commit/rollback; RESTCONF uses standard HTTP methods (GET/POST/PUT/PATCH/DELETE) over HTTPS and supports XML or JSON — simpler to use from scripts but lacks native transaction support D. NETCONF is for device monitoring only; RESTCONF is for configuration changes only

Correct answer is C. Both NETCONF and RESTCONF use YANG data models and can both read configuration/state and make changes. The key differences: NETCONF uses an SSH transport with XML-encoded RPC operations and supports transaction-based operations (candidate configuration, commit, rollback, lock) — making it more powerful for complex atomic changes. RESTCONF uses standard HTTP verbs over HTTPS, supports both XML and JSON payloads, and is stateless — making it easier to consume from web applications, Python scripts, and standard HTTP libraries without a persistent session. NETCONF offers more operational power; RESTCONF offers simpler integration. See RESTCONF Basics (Step-by-Step).

10. A traditional network engineer argues that controller-based networking is unnecessary because scripts using SSH and Netmiko can automate CLI commands on all devices. What is the most significant limitation of this approach compared to a proper controller-based architecture?

A. SSH-based scripts cannot run on Cisco devices — only SNMP can be used for automation B. CLI screen-scraping is fragile, unstructured, and lacks transactional integrity — a script sending 40 SSH commands has no way to roll back if command 25 fails, leaving the network in a partially-configured broken state C. SSH automation is faster than controller-based approaches but requires more storage space D. SSH scripts cannot be scheduled — they must be run manually every time

Correct answer is B. SSH/CLI automation (screen-scraping) has several fundamental problems compared to NETCONF/RESTCONF-based controller automation: (1) It is fragile — any change in CLI output format (IOS version upgrade, platform difference) breaks the script. (2) It produces unstructured text — scripts must parse human-readable output with regex, which is error-prone. (3) There is no transaction support — if a script applies 40 commands and fails at command 25, there is no automatic rollback. NETCONF supports candidate configurations and commit/rollback. (4) No validation — the script sends commands blindly; NETCONF validates against YANG models before applying. Controllers using NETCONF/RESTCONF address all of these issues fundamentally. See Network Automation Overview.

← Back to Home