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

The three planes of a network device

Before you can understand software-defined networking (SDN), you need to know that every network device does three different kinds of work, called planes.

The data plane must be extremely fast, so on real switches and routers it runs in dedicated hardware (ASICs) that consult pre-built tables such as the CAM table (MAC addresses), the TCAM (ACLs and QoS), and the FIB (forwarding information base, the hardware copy of the routing table built by CEF). The control plane runs as software on the device’s general-purpose CPU because it needs to make decisions, not just look things up.

6.3.a Separation of control plane and data plane

Software-defined networking (SDN) is the idea of taking the control plane out of the individual devices and placing it (or at least the policy portion of it) in a centralized controller. The devices keep the data plane and become simpler forwarding elements that receive their instructions from the controller. This is the “separation of the control plane and data plane.”

The purest version of this idea is OpenFlow, where switches have essentially no local intelligence: the controller programs flow entries (“if a packet matches these fields, do this action”) directly into the switch’s forwarding table. Cisco’s enterprise products use a more practical hybrid: the devices still run protocols locally (for example, IS-IS in an SD-Access underlay), but the controller centrally defines policy, provisions configuration, and collects telemetry. The exam treats both as examples of SDN.

The architecture is drawn as three layers:

+----------------------------------------------------+
|  Application layer: scripts, apps, GUI, monitoring |
+----------------------------------------------------+
            ^  Northbound API (usually REST)
            v
+----------------------------------------------------+
|  Control layer: the SDN controller                 |
|  (e.g., Cisco Catalyst Center, APIC, SD-WAN)       |
+----------------------------------------------------+
            ^  Southbound API (NETCONF, RESTCONF,
            v   OpenFlow, SSH/CLI, SNMP, OpFlex)
+----------------------------------------------------+
|  Infrastructure layer: switches, routers, APs      |
|  (data plane / forwarding)                         |
+----------------------------------------------------+

Benefits of separating the planes include a global view of the network in one place, policy defined once and applied everywhere, programmability through the controller’s API, and faster innovation because new features are added to the controller software rather than to every device’s operating system.

Underlay, overlay, and fabric

These three words are the vocabulary of Cisco SD-Access, and the exam objective names them explicitly.

• Underlay: the physical network. It consists of the switches, the cables between them, and a plain IP routing protocol whose only job is to make every switch reachable from every other switch. In SD-Access the underlay is typically built as a routed (Layer 3) network using IS-IS, although OSPF is also supported. The underlay does not know anything about users, VLANs, or policy; it just delivers packets between switch loopback addresses.
• Overlay: a virtual network built on top of the underlay using tunnels. User traffic is wrapped (encapsulated) in a tunnel header at the switch where it enters the fabric and unwrapped at the switch where it leaves. Because the overlay is virtual, you can create many isolated virtual networks over the same physical underlay, and endpoints can move around without changing the underlay.
• Fabric: the combination of the underlay and the overlay together, managed as one system by the controller. When Cisco says “the SD-Access fabric,” they mean the whole thing: physical switches plus tunnels plus the policy applied on top.

The three protocols of the SD-Access overlay

SD-Access uses three separate protocols for the overlay, one for each plane. These are common exam questions.

The logic of LISP is worth understanding because it explains why SD-Access is flexible. In a traditional network, an IP address tells you both who a host is and where it is (its subnet lives on one switch). LISP separates these: the endpoint keeps its identity (EID) no matter which edge switch it plugs into, and the mapping database records which locator (RLOC) currently hosts it. When a user moves from one building to another, only the mapping changes; the user’s IP address and policy follow them.

SD-Access fabric node roles

A single physical switch can hold more than one role (for example, border and control-plane nodes are often co-located).

6.3.b Northbound and Southbound APIs

An API (application programming interface) is a defined way for one piece of software to talk to another. In an SDN architecture, the controller sits in the middle and has APIs on two sides. Directional names are used: “north” is toward the applications and users, “south” is toward the devices. Remember it by the diagram earlier: applications on top, devices on the bottom.

Northbound APIs (NBI) connect the controller to the things above it: applications, scripts, orchestration tools, and dashboards. Almost universally these are REST APIs carried over HTTPS and exchanging JSON. A Python script that asks Catalyst Center “give me a list of all devices” or “create a new VLAN in site X” is using the northbound API. The northbound API abstracts the network: the script never needs to know which devices are involved or what CLI syntax they use.

Southbound APIs (SBI) connect the controller to the things below it: the switches, routers, and access points. The controller uses these to push configuration and pull operational data. Common southbound protocols: