Software-Defined Networking (SDN) is reshaping how networks are designed, managed, and automated. For the CCNA 200-301 exam, understanding SDN architecture is critical under exam objective 6.1 (Automation). This chapter will demystify SDN by breaking down its core components—the controller, southbound and northbound APIs, and the separation of control and data planes. You'll learn how SDN enables centralized policy enforcement, programmability, and automation, moving beyond traditional distributed control. Mastering these concepts is essential not only for passing the exam but for working in modern data centers and enterprise networks that demand agility.
Jump to a section
Imagine a major city's road network without a central traffic control system. Each intersection is managed by its own traffic light, which makes decisions based only on local sensors (like induction loops). This is a traditional distributed network: each router or switch makes forwarding decisions independently using protocols like OSPF or spanning tree. Now, replace that with a centralized air traffic control tower for the entire city. The tower has a complete, real-time view of all roads, traffic jams, and construction zones. Instead of each intersection deciding when to turn green, the tower sends direct commands: 'Intersection 5, turn green for 30 seconds; Intersection 12, turn red for 45 seconds.' The tower uses a southbound protocol (like a radio frequency) to talk to the traffic lights. The lights themselves are simple—they just obey commands; they don't think. This is the SDN model: a centralized controller (the tower) with a global view, communicating with forwarding devices (the lights) via a southbound API (OpenFlow or similar). The controller makes all routing decisions (control plane), while the switches only forward packets based on flow tables (data plane). If you want to change traffic patterns—say, prioritize emergency vehicles—you just reprogram the controller, not every light. This analogy underscores the key benefits: centralized control, programmability, and simplified device hardware. The exam tests whether you understand this separation and the role of APIs.
What is SDN and Why Does It Exist?
Traditional networking uses a distributed control plane: each router runs its own routing protocols (OSPF, EIGRP) and builds its own forwarding table. This model works but has drawbacks: configuration is device-by-device, policy enforcement is complex, and network changes are slow. SDN decouples the control plane (the logic that decides where traffic goes) from the data plane (the hardware that forwards packets). The control plane is centralized in an SDN controller, which has a global view of the network. The controller programs flow tables in switches via a southbound API, defining exactly how to handle packets (e.g., forward out port 5, drop, or modify header). This separation enables:
Centralized policy management: Change once, apply everywhere.
Programmability: Automate network behavior via scripts or orchestration tools.
Innovation: New services (like network slicing) can be added without upgrading hardware.
SDN Architecture Layers
The SDN architecture has three layers: - Application Layer: Contains business applications (e.g., firewall, load balancer, network monitoring) that communicate their network requirements to the controller via northbound APIs (e.g., RESTful APIs). - Control Layer: The SDN controller (e.g., Cisco APIC-EM, OpenDaylight, ONOS). It translates application requirements into flow entries and manages the network state. - Infrastructure Layer: The physical or virtual switches and routers that perform packet forwarding based on flow tables received from the controller.
How It Works Step by Step
A host sends a packet to a switch. The switch looks up the packet's header fields (e.g., destination IP, MAC, VLAN) in its flow table.
If there is no matching flow entry (a "table-miss"), the switch encapsulates the packet and sends it to the controller via the southbound API (e.g., OpenFlow Packet-In message).
The controller receives the packet, consults its network topology and policy database, and decides how to handle the flow.
The controller installs a flow entry in the switch's flow table (e.g., via OpenFlow Flow-Mod message). This entry includes match criteria and actions (e.g., forward out port 3, rewrite destination MAC, drop).
Subsequent packets of the same flow match the flow entry and are forwarded at line rate without controller involvement.
Key Components and Protocols
Southbound API: The interface between controller and forwarding devices. OpenFlow is the most common standard. Other examples include Cisco OpFlex and I2RS.
Northbound API: The interface between controller and applications. Usually RESTful APIs (HTTP/HTTPS with JSON/XML).
Flow Table: A table in an OpenFlow switch containing entries with match fields, priority, counters, instructions, timeouts, and cookie. Each entry has a hard timeout (max lifetime) and idle timeout (lifetime after last match).
Controller Placement: Often deployed in clusters for high availability. The controller can be physical or virtual.
SDN Deployment Models
Cisco SD-Access: Uses Cisco APIC-EM (now DNA Center) as the controller. It automates fabric provisioning, policy, and assurance. The underlay is IP (IS-IS), and the overlay uses VXLAN with LISP and Cisco TrustSec.
Open SDN: Uses open standards like OpenFlow and Open vSwitch (OVS). Common in research and some data centers.
API-based SDN: Uses device-level APIs (e.g., Cisco NX-API, NETCONF/YANG) for automation. This is more of a "programmable network" than pure SDN.
IOS CLI Verification Commands
While SDN controllers typically have GUIs, you can verify SDN-related configurations on Cisco devices. For example, on a switch running OpenFlow:
show openflow switch summaryExample output:
OpenFlow Switch Summary:
Datapath ID: 0000000000000001
Number of tables: 2
Number of flows: 5
Number of ports: 24
Active connections: 1
Capabilities: FLOW_STATS TABLE_STATS PORT_STATSshow openflow switch flowsExample output:
cookie=0x0, duration=100s, table=0, n_packets=10, n_bytes=1200
priority=100,ip,nw_dst=10.1.1.0/24 actions=output:5
cookie=0x1, duration=50s, table=0, n_packets=5, n_bytes=600
priority=10,arp actions=CONTROLLERInteraction with Related Protocols
SDN does not replace all traditional protocols. For example, underlay routing (e.g., IS-IS in SD-Access) still uses distributed protocols for switch-to-switch reachability. SDN overlays (e.g., VXLAN) encapsulate frames. The controller manages the overlay but relies on the underlay. Also, SDN controllers may use NETCONF/YANG to configure devices as an alternative to OpenFlow.
Identify SDN Architecture Components
Start by recognizing the three layers: application, control, and infrastructure. The application layer includes network services like firewalls and load balancers. The control layer is the SDN controller (e.g., Cisco DNA Center). The infrastructure layer consists of switches and routers. Understand that the controller communicates with applications via northbound APIs (REST) and with devices via southbound APIs (OpenFlow, NETCONF). The exam may ask you to match components to layers.
Understand Control and Data Plane Separation
In traditional networking, each device runs its own control plane (routing protocols) and data plane (forwarding). In SDN, the control plane is centralized in the controller. The data plane remains in the switches, which now only forward based on flow table entries installed by the controller. This separation allows for centralized policy and simplified hardware. The exam tests this concept: you should know that the controller handles routing decisions, while switches handle packet forwarding.
Learn Southbound APIs and OpenFlow
Southbound APIs are used for controller-to-device communication. OpenFlow is the most prominent standard. OpenFlow defines messages: Packet-In (switch to controller when no flow match), Flow-Mod (controller to switch to add/delete flows), and Packet-Out (controller to switch to send a packet out a port). Flow entries have match fields (e.g., IP src/dst, MAC, VLAN), priority, counters, and actions (e.g., output, drop, set-field). Timeouts: hard_timeout (max lifetime) and idle_timeout (lifetime after last packet). The exam may ask about OpenFlow message types or flow table concepts.
Explore Northbound APIs and REST
Northbound APIs allow applications to communicate with the controller. RESTful APIs over HTTP/HTTPS are common. Applications use GET, POST, PUT, DELETE to retrieve network state or request changes. For example, a monitoring app might GET /network/topology to get the network graph. The controller processes these requests and updates the network accordingly. The exam focuses on understanding that northbound APIs enable programmability and integration with orchestration tools like Ansible or Puppet.
Cisco SD-Access and DNA Center
Cisco's SDN solution is SD-Access, managed by DNA Center. It uses a fabric architecture with LISP (Locator/ID Separation Protocol) for endpoint mobility, VXLAN for overlay tunneling, and Cisco TrustSec for policy. The underlay is IP (IS-IS). DNA Center provides a centralized dashboard for automation, assurance, and policy. The exam may ask about the role of DNA Center or compare it to other controllers. Know that DNA Center uses NETCONF/YANG and REST APIs for device management.
Compare SDN to Traditional Networking
Traditional networking: distributed control, device-by-device CLI, slow change, complex troubleshooting. SDN: centralized control, automated via API, rapid change, global view. However, SDN introduces single point of failure (controller) and requires careful planning. The exam expects you to identify scenarios where SDN is beneficial (e.g., large data centers, campus networks requiring policy automation) and where it might not be (small networks with static routing).
In a large enterprise campus, deploying SD-Access with DNA Center solves the problem of manual VLAN and ACL management. Traditionally, adding a new user group required configuring VLANs, trunk ports, and ACLs on dozens of switches. With SD-Access, the network engineer defines policies in DNA Center (e.g., 'HR users can access payroll server only'). DNA Center automatically pushes the necessary VXLAN tunnel configurations and policy tags to all fabric edge switches. The result: changes take minutes instead of days, and consistency is guaranteed. A common pitfall is underestimating the underlay requirements: SD-Access requires a routed underlay (IS-IS) with proper MTU (at least 1550 bytes for VXLAN overhead). If the underlay is not correctly configured, overlay traffic may fail silently.
Another scenario is a data center using OpenFlow for traffic engineering. A cloud provider wants to steer large data transfers away from congested links. An SDN controller monitors link utilization via OpenFlow statistics and dynamically reroutes flows by modifying flow entries. This is more responsive than traditional MPLS-TE. However, if the controller fails, the switches may continue forwarding existing flows but cannot learn new ones. To mitigate, controllers are clustered and switches can fall back to normal operation (if supported).
A third scenario is a service provider using NETCONF/YANG for device automation. Instead of SDN per se, they use model-driven programmability to configure thousands of routers from a central system. This is often called 'SDN-lite' because it automates configuration but doesn't separate control and data planes. The exam may blur the lines; be clear that pure SDN implies control plane separation.
Misconfiguration example: An engineer sets the idle_timeout on flow entries too low (e.g., 5 seconds). This causes switches to frequently send Packet-In messages to the controller for the same flow, overwhelming the controller and causing packet loss. Best practice: set idle_timeout to 60 seconds or more, and hard_timeout to 0 (no hard limit) for critical flows.
Exam objective 6.1 (Automation) focuses on SDN architecture, including controller types, APIs, and the separation of control and data planes. Expect 2-3 questions on this topic. The most common wrong answers candidates choose:
Confusing southbound and northbound APIs: Candidates often select 'REST API' as a southbound API. REST is northbound. Southbound examples are OpenFlow, NETCONF, and Cisco OpFlex. Remember: North = Application to Controller, South = Controller to Device.
Believing SDN eliminates all routing protocols: Even in SDN, the underlay network (e.g., IS-IS in SD-Access) still uses a traditional routing protocol for switch-to-switch reachability. The controller manages the overlay. The exam may present a scenario asking what protocol runs in the underlay.
Thinking SDN requires OpenFlow: OpenFlow is one southbound protocol, but Cisco uses NETCONF/YANG and REST in many products. The exam does not mandate OpenFlow; it tests understanding of the concept.
Misunderstanding flow table timeouts: Questions may ask what happens when a flow entry expires. The switch sends a Packet-In to the controller if a new packet matches no entry. Candidates may incorrectly think the switch drops the packet or forwards it to all ports.
Specific values: OpenFlow flow entries have idle_timeout (default often 60 seconds) and hard_timeout (default 0, meaning no limit). The controller can also set a priority (0-65535). The datapath ID is a 64-bit identifier. On the exam, you might see a show command output and be asked to interpret the number of flows or actions.
Decision rule: If a question asks about centralized control and automation, think SDN. If it asks about device-by-device CLI, think traditional. For scenario questions with 'global view' or 'programmatic interface', SDN is the answer. Elimination: Options mentioning 'distributed control plane' are wrong for SDN.
SDN separates control plane (centralized controller) from data plane (forwarding devices).
Northbound APIs (e.g., REST) connect applications to the controller; southbound APIs (e.g., OpenFlow, NETCONF) connect controller to devices.
OpenFlow uses flow tables with match fields, priority, counters, and actions; idle_timeout and hard_timeout control flow entry lifetime.
Cisco SD-Access uses DNA Center as controller, with LISP, VXLAN, and TrustSec for overlay and policy.
Traditional networking uses distributed control; SDN enables centralized policy and automation.
The underlay in SD-Access uses IS-IS routing; the overlay uses VXLAN tunnels.
SDN controllers can be clustered for high availability; a single controller is a single point of failure.
These come up on the exam all the time. Here's how to tell them apart.
Traditional Networking
Control plane distributed on each device
Configuration via CLI per device
Slow network-wide changes
Difficult to enforce global policies
Hardware-dependent forwarding logic
SDN (Software-Defined Networking)
Control plane centralized in controller
Configuration via controller APIs
Fast, automated changes
Centralized policy management
Hardware-agnostic (forwarding based on flow tables)
Mistake
SDN eliminates all routing protocols.
Correct
SDN centralizes the control plane for overlay, but the underlay network still uses traditional routing protocols (e.g., IS-IS, OSPF) for device-to-device reachability.
Candidates assume 'centralized control' means no distributed protocols, but the underlay still needs a routing protocol to forward packets between switches.
Mistake
REST APIs are used for southbound communication.
Correct
REST APIs are northbound (application to controller). Southbound APIs include OpenFlow, NETCONF, and OpFlex.
The terms 'northbound' and 'southbound' are often confused; remembering the direction (North = up to apps, South = down to devices) helps.
Mistake
OpenFlow is the only SDN southbound protocol.
Correct
OpenFlow is a common standard, but other southbound protocols exist, such as NETCONF/YANG, Cisco OpFlex, and I2RS.
Cisco often uses NETCONF/YANG, leading candidates to think OpenFlow is universal.
Mistake
In SDN, the controller makes all forwarding decisions for every packet.
Correct
The controller installs flow entries in switches; subsequent packets matching a flow entry are forwarded at line rate without controller involvement. Only the first packet of a new flow (table-miss) triggers controller interaction.
Candidates think the controller is in the critical path for every packet, but the data plane is still fast.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Northbound APIs (e.g., REST) are used by applications to communicate with the SDN controller. They allow network services like monitoring or policy to request network state or changes. Southbound APIs (e.g., OpenFlow, NETCONF) are used by the controller to communicate with network devices (switches, routers). They install flow entries, collect statistics, and manage device configuration. Remember: North = up to apps, South = down to devices. Exam tip: If a question mentions an application making an HTTP request to the controller, it's northbound.
No. OpenFlow is a common southbound protocol, but SDN is a broader architecture. Cisco's SD-Access uses NETCONF/YANG and REST for device management, not OpenFlow. Other southbound protocols include OpFlex and I2RS. The exam tests the concept of separation of control and data planes, not a specific protocol. However, you should know OpenFlow's basic operation (Packet-In, Flow-Mod, flow table) as a representative example.
If the controller fails, switches can continue forwarding packets based on existing flow entries. However, new flows (table-misses) cannot be resolved, so new traffic may be dropped. To mitigate, controllers are deployed in clusters for redundancy. Some switches support a fallback mode (e.g., normal operation) if controller connection is lost. The exam may ask about high availability features or the impact of controller failure.
SDN involves separating the control plane from the data plane and centralizing it in a controller. Ansible is a configuration management tool that automates device configuration via SSH/CLI or APIs, but it does not change the control plane architecture. Ansible can be used with SDN (e.g., to configure DNA Center) but is not itself SDN. The exam distinguishes between SDN (architectural change) and automation (tooling).
A flow entry is a rule in a switch's flow table that defines how to handle packets that match certain criteria. It includes: match fields (e.g., source/destination IP, MAC, VLAN), priority, counters (packets/bytes matched), instructions (actions like output port, drop, modify header), timeouts (idle_timeout, hard_timeout), and a cookie for controller use. When a packet arrives, the switch looks up the highest priority matching entry and executes its actions.
DNA Center is the SDN controller for Cisco SD-Access. It provides a centralized dashboard for network design, policy, provisioning, and assurance. It uses northbound APIs for integration with IT systems and southbound APIs (NETCONF/YANG, REST) to configure fabric devices. DNA Center automates the deployment of VXLAN overlays, LISP mobility, and TrustSec policy. The exam may ask about its functions or compare it to other controllers.
Pure SDN (OpenFlow) requires switches that support the OpenFlow protocol. Many legacy switches do not. However, Cisco's SD-Access uses existing Catalyst switches (e.g., 9000 series) that support the required features (VXLAN, LISP, NETCONF). In a hybrid approach, you can use SDN controllers to manage traditional devices via APIs (e.g., NETCONF) without requiring OpenFlow. The exam may ask about compatibility requirements.
You've just covered SDN Architecture — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?