Lesson 3 — SDN, Cloud, and Virtualization
SDN, Cloud, and Virtualization
Separate the control plane from the data plane in an SDN architecture, place northbound and southbound APIs on the right side of a controller, and distinguish cloud service models, VMs, containers, and VRFs.
Lesson orientation
What you'll learn (4 objectives)~50 min: video → lesson → check → apply → lab prep
Learning objectives
- Explain how SDN moves control-plane decisions to a centralized controller while forwarding stays distributed
- Place northbound APIs (apps to controller) and southbound APIs (controller to devices) correctly
- Distinguish underlay, overlay, and fabric in a controller-based network
- Contrast VMs and containers, define a VRF, and match IaaS/PaaS/SaaS cloud models
Terms you will see
Time breakdown
- Read the SDN and API sections20 min
- Read the cloud and virtualization sections18 min
- Work the API-direction and VM-versus-container cases12 min
Assigned video
Free CCNA | Software-Defined Networking | Day 62 | CCNA 200-301 Complete Course
By Jeremy's IT Lab · Opens externally on YouTube
- Assigned watch
- ~6 min
The link opens in a new browser tab. Return here when you finish watching.
Watch for these concepts
- How the control plane centralises while forwarding stays on the devices
- Where northbound and southbound APIs sit relative to the controller
Go beyond the video
The assigned video introduces the idea. CCNA Practice Labs completes the learning path: clarify core concepts, explore how each device behaves, visualize the communication path, check your understanding, and prepare for hands-on lab work.
Watch the concept → understand it → visualize it → practice it → apply it.
SDN splits deciding from doing
Traditional networking runs a full control plane and data plane on every device — each switch independently learns MACs, runs STP, and builds its own tables. Software-defined networking pulls the deciding part, the control plane, onto a centralized controller. The devices keep the doing part, the data plane, and forward traffic locally, but they receive their forwarding rules from the controller. Deciding centralises; forwarding stays distributed. Most real deployments are hybrid SDN, where devices retain enough local control-plane intelligence to keep forwarding known traffic if the controller becomes unreachable.
| Direction | Between | Used for | Examples |
|---|---|---|---|
| Southbound | Controller down to network devices | Pushing configuration and reading state | OpenFlow, NETCONF, RESTCONF, SNMP |
| Northbound | Applications up to the controller | Expressing intent from automation apps and dashboards | Typically REST APIs — the ones from Lesson 2 |
| Layer | What it is |
|---|---|
| Underlay | The physical devices and links providing raw connectivity between nodes |
| Overlay | A logical network, built from tunnels such as VXLAN, riding on the underlay and carrying segmented user traffic |
| Fabric | The underlay and overlay together, managed as one system by the controller |
Why build an overlay rather than just using the physical network? Because the overlay lets policy and segmentation follow the user or workload regardless of which physical port they plug into. The underlay only has to move packets between fabric nodes; the overlay carries the identity-based segments on top. Separating them means policy can change without re-cabling, and the physical design stays simple.
Cloud is a behaviour, and virtualization is what makes it possible
"Cloud" does not simply mean "servers somewhere else". It is defined by essential characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured pay-per-use service. A private cloud can sit in your own building — what makes it cloud is the self-service, elastic, metered model rather than the postcode.
| Model | You manage | Provider manages | Example |
|---|---|---|---|
| IaaS | OS, apps, data | Compute, storage, network | Cloud VMs |
| PaaS | Apps, data | Runtime, OS, middleware | Managed app platform |
| SaaS | Data and configuration only | The whole application | Hosted email or CRM |
Moving from IaaS to PaaS to SaaS trades control for less operational burden. The classic trap is deciding the model from the word "hosted", which tells you nothing — read what remains your responsibility instead, because that is what actually distinguishes the three.
| Thing | What it virtualises | Key property |
|---|---|---|
| Virtual machine | A whole computer, via a hypervisor | Carries its own guest OS — heavier, but strongly isolated |
| Container | An application and its dependencies | Shares the host OS kernel — lighter and faster to start |
| VRF | Routing inside one router | Multiple independent routing tables on one physical device |
What you should retain
- SDN centralises the control plane on a controller; the data plane stays on the devices and keeps forwarding.
- Southbound APIs point down to devices (OpenFlow, NETCONF, RESTCONF); northbound APIs point up to apps and are typically REST.
- Decide API direction by which way the call flows, never by the transport protocol.
- Underlay is the physical network, overlay is the logical network on tunnels such as VXLAN, and fabric is both managed as one.
- Cloud is defined by self-service, pooling, elasticity, and metering — not by location.
- IaaS, PaaS, SaaS differ by what you still manage; "hosted" alone tells you nothing.
- A VM carries its own OS; a container shares the host kernel; a VRF is several routing tables inside one router.
Before you read on
(1) In a software-defined network, which plane moves onto the controller and which stays on every switch and router? (2) A dashboard application tells the controller "segment these users"; the controller then programs the switches. Which call is northbound and which is southbound — and does it matter that both use HTTPS? (3) A team wants twenty small, fast-starting microservices on one server with the least overhead per service: VMs or containers?
See it happen
Automation Sandbox
Work the API-direction items until north and south are automatic rather than reasoned out each time — under exam pressure the reasoning is what gets skipped.
Section quiz follows Lesson 4, once the AI layer has joined the architecture.
Study deeper
Topic guides extend this lesson — they do not replace the first-party walkthrough above.
Cloud & SDN
For fuller plane-separation detail and the controller context around it