Instiq
Chapter 6 · Automation & Programmability·v1.0.0·Updated 7/18/2026·~16 min

What's changed: Initial version

6.2SDN architecture and the fabric

Key points

Covers the physical underlay and the logical overlay, the fabric that binds the two, Cisco's campus automation SD-Access, the northbound API connecting the controller to applications and the east-west API connecting controllers to one another, and the cloud management dashboard Cisco Catalyst Center (formerly DNA Center) that handles automation and assurance.

Cisco systematizes the controller-based idea from the previous section as SDN (Software-Defined Networking). The crux of SDN is separating a logical layer—policy and virtual networks—laid over the "foundation" of physical cabling. This section organizes the relationship between those two layers (underlay and overlay) and the fabric that binds them, what APIs the controller uses to talk to higher-level applications and to a neighboring controller, and what Cisco's implementation—SD-Access and Catalyst Center—handles, all while avoiding term confusion.

6.2.1Underlay, overlay, and fabric

  • The underlay is the physical foundation network of switches/routers and cabling. It is the base that provides IP reachability between the fabric's nodes, usually built as a simple routed IP network.
  • The overlay is a logical network built with tunnels (e.g., VXLAN) on top of the underlay. It lets you layer virtual segments and policy without changing physical cabling, and user traffic flows over this logical layer.
  • The fabric is the whole—underlay plus overlay—treated as a single managed entity. The controller treats the entire fabric as one system and distributes policy to its nodes.

6.2.2SD-Access (the Cisco campus fabric)

  • SD-Access is Cisco's SDN solution for campus/access networks. It builds a VXLAN overlay on top of the underlay and controls users and devices with group-based policy. The network is automated and monitored from Cisco Catalyst Center.
  • Because policy is expressed by group rather than by IP address or VLAN, the same access control follows a user regardless of which port they connect to. This decouples access-network segmentation from the physical layout.

6.2.3Northbound and east-west APIs

  • The northbound API (N-S) is the interface connecting the controller to the applications/automation scripts above it. It is typically a REST API, through which operators convey "intent" to the controller.
  • The southbound API is the interface connecting the controller to the physical devices below it (switches/routers) (e.g., NETCONF/OpenFlow). It is the path that distributes the controller's decisions to devices.
  • The east-west API (E-W) is the interface for controllers to synchronize and coordinate state with one another (within a cluster or between controllers in different domains). It matters for redundancy and scale-out.
Exam point

Most-tested: the direction of northbound = controller <-> upper applications (REST), southbound = controller <-> lower physical devices, and east-west = controller to controller. Be sure to nail the three-tier distinction: underlay = the physical foundation / overlay = the logical layer above it (VXLAN, etc.) / fabric = the two combined as a whole.

6.2.4Cisco Catalyst Center (formerly DNA Center) and cloud management

  • Cisco Catalyst Center (formerly Cisco DNA Center) is the central controller and management dashboard for enterprise networks including SD-Access. It handles design, provisioning, policy, and assurance (monitoring/health) from a single GUI.
  • The assurance feature applies AI/ML to telemetry to evaluate network health and surface root causes and recommended remediations. Operators drive the whole network through this dashboard (and the northbound REST API) rather than individual CLIs.

Suppose you are tasked with refreshing a campus network, with the requirement that "an employee's access rights automatically follow them whether at headquarters or a branch, wired or wireless." Traditionally, VLANs and ACLs were tied to the IP address plan and maintained by hand per site, so configuration tended to break with every desk move or floor change. Adopting SD-Access, you have the physical cabling serve only as the underlay providing simple IP reachability, then stretch a VXLAN overlay over it and apply policy that groups users into groups (e.g., "Employees," "Guests," "IoT devices"). Regardless of which port a user plugs into, their group is determined from the authentication result and the same policy follows, achieving consistent access control without redesigning IP or VLANs. What binds this design, distribution, and monitoring together is Catalyst Center: operators inject intent via the dashboard (or from scripts through its northbound REST API), and Catalyst Center pushes the concrete configuration down to each node via the southbound path. If you make the controller redundant and scale it out, the east-west API handles state synchronization between controllers. Mixing up the terms and thinking "user traffic flows over the underlay" leads to a design error—user traffic rides the overlay, while the underlay merely provides the foundational IP reachability beneath it.

API directionWhat it connectsTypical example
NorthboundController <-> upper apps/scriptsREST API
SouthboundController <-> lower physical devicesNETCONF / OpenFlow, etc.
East-westController <-> another controllerInter-controller state sync
Warning

Trap: "User traffic flows over the underlay" is wrong—user data rides the overlay (the logical layer such as VXLAN), while the underlay is the layer providing the foundational physical IP reachability. Also wrong: "the northbound API connects the controller to physical devices"—devices are connected via the southbound API; the northbound connects the controller to upper applications.

Underlay/overlay, SD-Access, API directions.
Unifying physical and logical into one managed whole

6.2.5Section summary

  • The underlay is the physical foundation (IP reachability), the overlay is the logical layer above it (where user traffic flows via VXLAN, etc.), and the fabric is the two combined as a managed unit
  • The northbound API = controller <-> upper apps (REST), southbound = controller <-> devices, and the east-west API = controller to controller
  • SD-Access is Cisco's campus fabric delivering group-based policy, and Cisco Catalyst Center (formerly DNA Center) handles design/distribution/AI assurance from a single dashboard

Sign in to track progress — Log in.

Quick check

(just a quick review)

Q1. In an SD-Access fabric design, which layer does an employee PC's business traffic logically flow over, and what role does the physical cabling play? Which pairing is most appropriate?

Q2. An operator wants to send the intent "apply this policy across the entire campus" from a homemade Python script to the controller. Which interface is most appropriate for this purpose?

Q3. For an enterprise network including SD-Access, which product most appropriately provides design, provisioning, policy application, plus AI/ML-based assurance (health evaluation) from a single dashboard?

Check your understandingPractice questions for Chapter 6: Automation & Programmability

Keep track of your progress

The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.