Study guide
6.2 Controller-Based and Software-Defined Architectures
Cisco Certified Network Associate CCNA
Track your progress as you read
Finished sections get a check mark.
1 Introduction
About the CCNA 200-301 Exam Domains and Weights Study Strategies and Tips
2 Chapter 1: Network Fundamentals (20%)
1.1 Network Components 1.2 Network Topology Architectures 1.3 Physical Interfaces and Cabling 1.4 TCP vs. UDP 1.5 IPv4 Addressing and Subnetting 1.6 IPv6 Addressing and Prefix 1.7 Wireless Principles 1.8 Virtualization Fundamentals 1.9 Switching Concepts 1.10 OSI and TCP/IP Reference Models 1.11 Verifying IP Parameters on Client Operating Systems
3 Chapter 2: Network Access (20%)
2.1 VLANs — Configuration and Verification 2.2 Trunking and 802.1Q 2.3 Layer 2 Discovery Protocols (CDP and LLDP) 2.4 EtherChannel (Link Aggregation) 2.5 Spanning Tree Protocol (STP) and RSTP 2.6 Wireless Architectures and AP Modes 2.7 Network Access Troubleshooting 2.8 Inter-VLAN Routing — Deep Dive
4 Chapter 3: IP Connectivity (25%)
3.1 Routing Table Components 3.2 Router Forwarding Decisions 3.3 IPv4 and IPv6 Static Routing 3.4 Single-Area OSPFv2 — Concepts 3.5 Single-Area OSPFv2 — Configuration 3.6 First Hop Redundancy Protocols (FHRP) 3.7 Troubleshooting IP Connectivity 3.8 OSPF Troubleshooting Scenarios
5 Chapter 4: IP Services (10%)
4.1 NAT (Network Address Translation) 4.2 DHCP and DNS 4.3 NTP, SNMP, and Syslog 4.4 QoS Fundamentals 4.5 TFTP/FTP and Remote Access 4.6 IP Services — Comprehensive Review
6 Chapter 5: Security Fundamentals (15%)
5.1 Key Security Concepts 5.2 Device Access Control and Password Policies 5.3 VPN Fundamentals 5.4 Access Control Lists (ACLs) 5.5 Layer 2 Security Features 5.6 Network Security Best Practices and Hardening 5.7 Threat Mitigation and Incident Response
7 Chapter 6: Automation and Programmability (10%)
6.1 Impact of Automation on Network Management 6.2 Controller-Based and Software-Defined Architectures 6.3 AI and Machine Learning in Network Operations 6.4 REST-Based APIs 6.5 Configuration Management Tools 6.6 JSON-Encoded Data 6.7 Automation and Programmability — Comprehensive Review
6.2 Controller-Based and Software-Defined Architectures
Key Takeaways Explain This Topic AI
SDN separates the control plane (decision-making) from the data plane (packet forwarding).
The controller is the centralized brain that computes and programs forwarding rules into network devices.
Northbound APIs connect applications to the controller; southbound APIs connect the controller down to devices.
Cisco DNA Center, rebranded Cisco Catalyst Center, is Cisco's intent-based controller for enterprise campus networks.
An overlay (e.g., VXLAN) runs on top of the physical underlay; together they form a fabric managed as one entity.
Last updated: June 2026
Control Plane vs. Data Plane
Every network device has two logical planes. The control plane makes decisions — it runs routing protocols (OSPF, EIGRP), builds the routing table, computes the Spanning Tree topology, and learns MAC addresses. The data plane (also called the forwarding plane) simply moves packets out the right interface based on what the control plane decided. A third management plane handles access (SSH, SNMP, syslog).
In a traditional network , every router and switch carries its own control plane and data plane. Each device decides independently and is configured box-by-box. This is the distributed control plane model.
Controller-Based Networking (SDN)
Software-Defined Networking (SDN) centralizes the control plane in an external controller . The controller computes the forwarding behavior for the whole network and programs it into the devices, which are then left to do nothing but forward packets.
The Three SDN Layers
- Layer Also called Role
- Application layer Apps / business apps Security, analytics, and automation apps that consume network services
- Control layer Controller The brain — computes policy and forwarding, the central point of management
- Infrastructure layer Data plane Physical/virtual switches, routers, and APs that forward traffic
- Northbound and Southbound APIs
The APIs that glue the layers together are a guaranteed exam topic. Picture the controller in the middle: applications sit above it, devices sit below it.
API Connects Typical protocols Purpose
Northbound (NBI) Apps ⇄ Controller REST over HTTP/HTTPS Apps request services and pull network data from the controller
Southbound (SBI) Controller ⇄ Devices NETCONF, RESTCONF, OpenFlow , SSH Controller pushes config and forwarding rules to devices
East/Westbound Controller ⇄ Controller Vendor-proprietary Sync state between multiple controllers
Memory hook: N orthbound = N etwork apps (looking up); S outhbound = S witches and routers (looking down).
Underlay, Overlay, and Fabric
Modern campus and data-center SDN designs separate the physical wiring from the logical network.
Concept Definition Example
Underlay The physical IP network — cables, switches, routers and their routing A routed campus running IS-IS or OSPF between switches
- Overlay A virtual network tunneled on top of the underlay VXLAN tunnels carrying segmented traffic
- Fabric Underlay + overlay managed together as one system Cisco SD-Access fabric
- How an Overlay Moves Traffic
The underlay provides plain IP reachability between every switch (the tunnel endpoints).
The overlay builds virtual tunnels — VXLAN encapsulates the original Layer 2 frame inside a UDP/IP packet (VXLAN uses UDP port 4789 ).
The packet rides across the underlay and is decapsulated at the egress switch.
The payoff: a VLAN or subnet can span the entire fabric regardless of where devices physically plug in, and micro-segmentation policy follows the user, not the port.
Cisco DNA Center / Catalyst Center
Cisco DNA Center is Cisco's enterprise SDN controller for campus networks. As of 2023-2024 Cisco rebranded it as Cisco Catalyst Center — it is the same product with a new name, and older API versions still carry the DNA Center label. Expect either name on the exam.
It delivers intent-based networking (IBN) : you declare what you want ("engineering can reach the lab, guests cannot reach corporate") and the controller translates that intent into the device-by-device configuration.
- Feature What it does
- Intent-based networking Business intent → automated device configs
- Automated provisioning Push configs to hundreds of devices at once
- SD-Access Software-defined campus fabric with micro-segmentation
- Assurance AI/ML monitoring, analytics, and root-cause analysis
- Network Plug-and-Play Zero-touch provisioning for new devices
- Common Trap
Do not confuse the directions: a question about configuring the switches points to a southbound protocol (NETCONF/RESTCONF), while a question about an analytics app pulling data from the controller points to a northbound REST API. Also remember SDN does not eliminate physical devices — it just centralizes their control plane.
On the Exam: Know the three layers (application, control, infrastructure), the API directions (northbound = apps-to-controller REST; southbound = controller-to-devices NETCONF/RESTCONF/OpenFlow), and that Catalyst Center (formerly DNA Center) is Cisco's intent-based campus controller.
Degrees of Centralization
Not every controller-based design centralizes the control plane to the same degree, and the exam expects you to appreciate the spectrum. In a fully centralized SDN model, the controller computes every forwarding decision and the devices are essentially dumb forwarders; this is the classic textbook OpenFlow picture. In practice, most enterprise Cisco deployments use a hybrid model: the controller handles policy, provisioning, and assurance, while the devices still run their own routing and switching protocols locally for fast convergence.
Catalyst Center sits in this hybrid space — it automates and monitors, but a switch in an SD-Access fabric still forwards traffic on its own data plane even if the controller is temporarily unreachable.
This matters for a common exam scenario: if the link to the controller goes down, does the network stop forwarding? In a hybrid Cisco design the answer is no, existing flows keep working because the data plane is local; you simply lose the ability to make new centralized policy changes until the controller returns. Contrast that with a purely centralized control plane, where losing the controller could prevent new flows from being programmed at all.
Why Intent-Based Networking Is a Step Beyond Automation
Plain automation pushes the configuration you wrote. Intent-based networking goes one level higher: you describe the business outcome and the controller decides the configuration. You say "contractors get internet but never touch the finance servers," and Catalyst Center generates the VLANs, the Scalable Group Tags, and the access policies on every fabric switch to make that true — then continuously verifies reality still matches the intent and re-mediates if it drifts.
That closed loop of translate, activate, and assure is what distinguishes an intent-based controller from a simple script runner, and it is the conceptual point Cisco wants you to walk away with for this section.