Overview
Cloud computing delivers on-demand IT resources over the network. SDN separates the control plane from the data plane for centralized programmability. Cisco DNA (Digital Network Architecture) applies intent-based automation to campus, branch, and WAN — with DNA Center as the controller and management platform.
Traditional deployment vs cloud
Before cloud, organizations ran on-premises equipment (owned, in your building) or colocation (rent rack space; provider supplies power, cooling, physical security).
Cloud is not simply "servers somewhere else." NIST defines cloud by essential characteristics, not location — private cloud can be on-premises.
| Model | You own hardware? | Location | Provisioning speed |
|---|---|---|---|
| On-premises | Yes | Your building | Days to weeks (manual) |
| Colocation | Yes (in provider DC) | Provider facility | Weeks |
| Cloud (any deployment) | No (consumption) | Varies | Minutes (self-service portal) |
NIST cloud essential characteristics
- On-demand self-service — provision without human interaction
- Broad network access — standard mechanisms (Internet)
- Resource pooling — multi-tenant shared infrastructure
- Rapid elasticity — scale up/down quickly
- Measured service — pay for what you use
Virtualization enables pooling — multiple VMs on shared hardware via a hypervisor:
| Type | Runs on | Example |
|---|---|---|
| Type 1 | Bare metal | VMware ESXi, Hyper-V |
| Type 2 | Host OS | VirtualBox on laptop |
Network devices also support virtualization (VRF, containers on platforms) — same principle: logical isolation on shared hardware.
Cloud service models: IaaS, PaaS, SaaS
The three models stack — each adds provider-managed layers.
| Model | You manage | Provider manages | Examples |
|---|---|---|---|
| IaaS | OS, apps, data | Compute, storage, network | AWS EC2, Azure VMs |
| PaaS | Applications, data | Runtime, middleware, OS | Heroku, Azure App Service |
| SaaS | Data/config | Entire application | Microsoft 365, Salesforce |
Responsibility shift: Moving up the stack (IaaS → PaaS → SaaS) means less operational burden but less control.
SaaS = you use the application (email, CRM). IaaS = you install your own OS on provider VMs. Don't confuse "hosted" with service model — read what you still manage.
Cloud deployment models
| Model | Description |
|---|---|
| Public | Open to general public (AWS, Azure, GCP) — most common |
| Private | Exclusive to one organization; on- or off-premises; self-service portal |
| Community | Shared by organizations with common concerns (government, healthcare) |
| Hybrid | Public + private bound together; cloud burst for peak load; DR in public cloud |
Not true private cloud: Dedicated servers in a public cloud IaaS where only your VMs sit on the hardware but network infrastructure is still shared — marketing label, not NIST private cloud.
Cloud advantages (CCNA awareness)
Scalability, business agility, cost efficiency (OpEx vs CapEx), availability, and faster provisioning. Tradeoffs include dependency on provider SLAs and data governance considerations.
SDN: data, control, and management planes
| Plane | Function |
|---|---|
| Data (forwarding) | Fast path — switch, route, encapsulate, ACL filter |
| Control | Routing protocols, STP, MAC learning — builds forwarding tables |
| Management | Human or API config — SSH, HTTPS, SNMP, NETCONF |
Traditional networking: Every device runs its own control and data planes.
SDN: Control plane moves to a centralized controller. Devices forward traffic but receive forwarding rules from the controller via southbound APIs (OpenFlow, NETCONF, RESTCONF, SNMP).
Applications use northbound APIs on the controller to express intent.
Pure SDN — all control on controller. Hybrid SDN — controller plus local control plane intelligence on devices. Most real deployments are hybrid.
Control layer vs infrastructure layer: The interface between centralized control and device forwarding is the exam framing for "where planes separate" in software-defined architecture.
SDN controllers (Cisco context)
| Controller | Scope | Manages |
|---|---|---|
| APIC | Data center | Nexus switches (ACI) |
| DNA Center | Enterprise campus, branch, WAN | Catalyst switches, routers, wireless |
| WLC / Meraki | Wireless / cloud-managed | APs, policies |
Southbound = controller to devices. Northbound = automation apps and GUIs to controller.
Cisco DNA and intent-based networking
Cisco DNA is a software-driven architecture for digitized enterprise networks. Intent-based networking (IBN) translates business intent ("finance VLAN isolated from guest") into automated, consistent policy across the fabric.
Three DNA building blocks:
- DNA Center — controller and management platform
- SD-Access — campus fabric with identity-based segmentation
- SD-WAN — automated WAN connectivity (Viptela heritage)
DNA Center roles
DNA Center serves two roles:
- SD-Access controller — provisions fabric overlay
- Network management platform — design, policy, provision, assurance for traditional and SDA devices
Four DNA Center sections:
| Section | Purpose |
|---|---|
| Design | Physical/logical topology, device discovery (CDP or IP range) |
| Policy | User/device profiles, segmentation, access control |
| Provision | Drag-and-drop policy assignment; zero-touch for new devices |
| Assurance | Proactive monitoring, path trace, client/app experience |
Path trace visualizes end-to-end flow (client → switches → server) — troubleshooting that once took many show commands.
SD-Access: underlay and overlay
SD-Access uses identity-based access — security follows the user, not just IP and physical port.
| Layer | Role |
|---|---|
| Underlay | Physical connectivity between fabric nodes |
| Overlay | Logical fabric (VXLAN tunnels) carrying segmented traffic |
ISE (Identity Services Engine) authenticates users. DNA Center defines group-based policy (who can talk to whom). Together they form the SD-Access policy stack.
SD-WAN highlights
- Transport-independent (MPLS, Internet, LTE)
- Automated site-to-site setup and failover
- Application-aware path selection
- Centralized policy from DNA Center or vManage
show ip interface brief show cdp neighbors show version show run | section interface
Know DNA Center as enterprise campus controller, Meraki as cloud-managed, WLC as wireless controller. Exam tests categories and intent — not full GUI click paths.
How cloud, SDN, and DNA connect
| Concept | Relationship |
|---|---|
| Cloud IaaS | Virtual networks and APIs replace some physical WAN/CPE tasks |
| SDN | Programmable control plane — DNA is Cisco's enterprise implementation |
| DNA Center | IBN controller tying policy, automation, and assurance |
| Automation APIs | Northbound REST on DNA Center; southbound to devices |
Private cloud at a large enterprise may use DNA Center as the SDN controller while workloads run on virtualized infrastructure — automation ties networking to self-service IT.
Troubleshooting mindset
| Issue | SDN/DNA angle |
|---|---|
| Policy not applied | Provision job failed; device not in inventory |
| Client wrong VLAN/segment | ISE group mapping; policy matrix in DNA Center |
| Path failure | Use path trace; verify underlay reachability first |
| Drift | Manual CLI change outside controller — reconcile or enforce |
Exam checklist
- List IaaS vs PaaS vs SaaS and one example each
- Name five NIST cloud characteristics
- Explain control vs data plane separation in SDN
- Define intent-based networking in one sentence
- Describe DNA Center Design / Policy / Provision / Assurance
- Contrast SD-Access underlay vs overlay