Lesson 1.8.2 — SDN, SD-WAN & VXLAN

Domain 1.0 | Networking Concepts — 23% of exam

Learning Objectives

By the end of this lesson, you will be able to:

• Explain SDN and the separation of the control plane from the data plane
• Distinguish SDN from NFV
• Explain SD-WAN and how it differs from traditional WAN connectivity
• Explain VXLAN and why data centers use it to scale network segmentation

Key Terms

Explanation

One Concept, Two Applications

This lesson covers three terms that get confused constantly, mostly because two of them are really the same idea applied in different places. SDN is the general concept. SD-WAN is that same concept, applied specifically to wide area networking. VXLAN is something else entirely — a way of stretching Layer 2 segments across a Layer 3 network. All three matter for different reasons, and keeping them straight starts with understanding SDN itself.

SDN: Separating the Brain From the Muscle

Every network device does two jobs at once, even if it doesn’t look that way from the outside. The control plane decides what to do — building a routing table, deciding which path is best, running the protocols that make those decisions. The data plane actually does it — forwarding each packet according to whatever the control plane already figured out.

In a traditional network, every single device runs its own control plane independently. Each router makes its own routing decisions. Each switch builds its own MAC address table. Nobody’s in charge of the whole picture at once — the network’s intelligence is scattered across every box in it.

SDN (Software-Defined Networking) changes that. It pulls the control plane out of individual devices and centralizes it in a controller — one system with a complete view of the network, making decisions and pushing them out to every device’s data plane. The devices themselves keep forwarding traffic, but they stop making independent decisions about how. That’s the whole idea in one sentence: SDN separates deciding from doing, and puts the deciding in one central place.

Why bother? Centralizing control makes a network far easier to manage at scale. Instead of logging into fifty individual switches to make a policy change, an administrator makes the change once, at the controller, and it propagates everywhere automatically. It also opens the door to programmability — a controller can be scripted, automated, and integrated with other systems in ways that fifty independently configured boxes never could be.

SDN architecture is usually described using two interfaces, and the exam occasionally names them directly. The southbound interface is how the controller talks down to the actual network devices, pushing forwarding instructions to their data planes. The northbound interface is how the controller talks up to applications and management systems sitting above it — letting other software request network changes programmatically, rather than requiring a human to click through a configuration screen. Picture the controller sitting in the middle: southbound traffic flows down to the hardware doing the forwarding, northbound traffic flows up to whatever business application or orchestration tool needs to request network changes.

SDN vs. NFV: Still Worth Repeating

Lesson 1.3.1 flagged this distinction early, promising a fuller explanation later. Here it is: NFV virtualizes individual network functions — turning a physical firewall or load balancer into a software instance running on general-purpose hardware. SDN centralizes control-plane decision-making — separating the “deciding” part of networking from the “doing” part, regardless of whether the devices involved are physical or virtual.

They solve different problems, and they’re commonly used together rather than as alternatives. An organization might run virtualized firewalls (NFV) that are themselves managed and orchestrated through a centralized SDN controller. One is about what the device is — hardware or software. The other is about where decisions get made — locally on each device, or centrally at a controller. Confusing the two is one of the most consistently tested mix-ups across this entire domain.

SD-WAN: SDN Applied to the WAN

SD-WAN (Software-Defined WAN) takes SDN’s core idea — centralize control, push decisions out from one place — and applies it specifically to how an organization’s wide area network traffic gets routed.

A traditional WAN setup typically routes traffic over a single connection type, often an expensive dedicated MPLS circuit, with limited ability to dynamically adjust based on real-time conditions. SD-WAN instead lets an organization use multiple WAN links simultaneously — MPLS, broadband internet, even LTE — and centrally decide, in real time, which link carries which traffic. A latency-sensitive video call might get routed over the most reliable link available at that moment, while routine file backup traffic gets shunted onto cheaper broadband, all decided automatically based on current conditions rather than fixed, manually configured routing.

This connects directly back to the connectivity options from Lesson 1.3.2 — the underlying links SD-WAN manages might themselves be dedicated connections or site-to-site VPNs. SD-WAN doesn’t replace those transport options; it sits above them, intelligently deciding which one to use for which traffic at any given moment.

Consider a retail chain with 200 branch locations, each historically connected back to headquarters over an expensive MPLS circuit. Under SD-WAN, each branch instead gets a cheaper broadband internet connection as a second link alongside (or even instead of) that MPLS circuit.

A centralized SD-WAN controller monitors both links’ real-time performance — latency, jitter, packet loss — at every branch simultaneously, and automatically routes each type of traffic over whichever link currently performs best for it. Point-of-sale transactions might always prefer the more reliable MPLS link, while routine software updates default to the broadband connection, and if the MPLS link ever degrades or fails at a specific branch, that branch’s traffic shifts to broadband automatically, without anyone driving out to reconfigure a router by hand.

VXLAN: Stretching Layer 2 Across Layer 3

VLANs have a hard limit worth remembering: the VLAN ID field is 12 bits, capping the usable count at 4,094 VLANs. That’s plenty for most single organizations. It’s nowhere near enough for a large multi-tenant cloud provider trying to keep thousands of different customers’ networks logically separated on shared infrastructure.

VXLAN (Virtual Extensible LAN) solves this by using a 24-bit identifier — the VXLAN Network Identifier, or VNI — supporting over 16 million distinct segments instead of VLAN’s 4,094. But VXLAN does something more fundamental than just widening the ID field: it’s an overlay technology, meaning it creates a virtual Layer 2 network that rides on top of an existing Layer 3 network (the underlay), rather than requiring that Layer 2 adjacency exist physically.

In practice, this means two servers can behave as though they’re on the same Layer 2 segment, even if the physical network connecting them — like the spine-leaf architecture covered earlier — is a pure Layer 3 design underneath. Devices called VTEPs (VXLAN Tunnel Endpoints) handle the actual work: encapsulating Layer 2 frames inside Layer 3 packets on the way out, and stripping that encapsulation back off on the way in, making the whole process invisible to the servers actually generating and receiving the traffic.

Walk through what actually happens to a single frame. A virtual machine sends an ordinary Ethernet frame, addressed to another VM it believes is on the same local segment — as far as that VM knows, nothing unusual is happening at all. The frame reaches a VTEP, which wraps it inside a VXLAN header (carrying the VNI that identifies which virtual segment this traffic belongs to), then wraps that again inside a standard IP/UDP packet for transport across the Layer 3 underlay.

That packet travels across the physical spine-leaf fabric like any other Layer 3 traffic, with the underlay’s switches and routers having no idea an entire Ethernet frame is riding inside it. On arrival, the destination VTEP strips off the outer IP/UDP and VXLAN headers, and delivers the original, untouched Ethernet frame to the destination VM — which, again, never knew any of this encapsulation happened at all.

Putting the Three Together

A large cloud provider’s data center is a good place to see all three ideas in one deployment. The physical network underneath is a spine-leaf design, pure Layer 3 — the underlay.

On top of that, VXLAN creates thousands of isolated virtual Layer 2 segments, one or more per customer, each identified by its own VNI, letting completely unrelated tenants share the same physical infrastructure without ever seeing each other’s traffic. Managing and provisioning all of this centrally, rather than configuring every individual switch by hand, is handled through an SDN controller — and if that same provider also operates its own private WAN connecting multiple data center sites together, SD-WAN intelligently manages traffic across those inter-site links. Three distinct technologies, three distinct jobs, all working at once in the same overall system.

Recognition-Level Verification Concepts

This objective is conceptual, but a few patterns are worth recognizing:

• A network managed from one central controller dashboard, rather than device-by-device, is a strong signal of an SDN deployment.
• Traffic dynamically shifting between multiple WAN links based on real-time conditions, rather than always following one fixed path, is the signature of SD-WAN in action.
• A packet capture showing a VXLAN header with a 24-bit VNI field, wrapping an inner Ethernet frame, is unmistakably VXLAN encapsulation at work.

Common Exam Traps

• SDN and NFV are not the same thing, and they get tested against each other constantly. SDN centralizes control-plane decisions; NFV virtualizes individual network functions. They complement each other but solve different problems.
• SD-WAN is SDN applied specifically to WAN connectivity — not a separate, unrelated technology. If you understand SDN’s core idea, SD-WAN is just that idea pointed at a specific problem.
• VXLAN’s 24-bit VNI is what allows over 16 million segments, dramatically more than a traditional VLAN’s 12-bit ID and its 4,094-segment ceiling. This is the single most tested VXLAN fact.
• VXLAN is an overlay riding on top of a Layer 3 underlay — the physical network doesn’t need Layer 2 adjacency at all. Don’t assume VXLAN requires the same physical topology constraints as traditional VLANs.
• VTEPs do the actual encapsulation and decapsulation work in VXLAN. Servers generating the traffic have no awareness that VXLAN is even involved — that abstraction is the whole point.