Cloud-managed networking: control plane and data plane
What you will learn in this module. By the end of these six chapters you will understand how a cloud-managed network is organised (organization, networks, devices, tags, templates), who may change what (admin roles and least privilege), how one template can drive many branches, and a calm method to troubleshoot a site you cannot touch physically. Prerequisites: only basic IP addressing and Ethernet knowledge (what an IP address, a subnet, a VLAN and a switch are). Every other term is explained when it first appears. You will practise on the Bharat Retail Co dashboard simulator: Mumbai HQ, Bengaluru branch and Delhi branch.
Start with an analogy: a chain of shops and one head office
Imagine a retail chain with 200 shops. In the old way, each shop manager keeps a thick folder of rules and the head office phones them to change anything. In the new way, the head office has one control room with a screen showing every shop. The shop staff still sell, pack and bill locally. If the phone line to the head office is cut for an hour, the shops keep selling. Only the management is paused, not the work.
Cloud-managed networking is exactly this. The switches, access points and security appliances sit in your sites and forward traffic. Their settings are written and monitored from a web page called the dashboard, which runs in the vendor's cloud.
The cloud decides the rules (control plane). The devices at the site forward the packets (data plane).
Control plane and data plane in plain words
- Data plane
- The part that moves user traffic: a packet arrives on a port and leaves on another. It must be fast and local.
- Control plane
- The part that decides the rules: which VLANs exist, which firewall rules apply, which SSIDs are broadcast. In classic networks every box has its own control plane that you reach by CLI. In cloud-managed networking the rules are authored centrally in the dashboard and pushed to the devices.
- Management plane
- The channel between the dashboard and each device, used to send configuration and to bring back status. Devices open it outbound towards the cloud, so you do not need to open inbound holes at the branch.
Why put the dashboard in the cloud?
- One place to see everything. Mumbai, Bengaluru and Delhi appear in one list. You do not need a VPN into each site to read a device.
- Zero-touch rollout. A new device is claimed by its serial number and then fetches its configuration when it first reaches the internet (chapter 3).
- Consistency. One template can drive many sites (chapter 4).
- Auditability. Every change is recorded with who and when (chapter 5).
What keeps working if the cloud is unreachable?
At a high level, devices keep forwarding traffic using the last configuration they received, because the data plane is local. What you lose is the ability to change or see things until the connection returns. Exact timers and edge cases differ by feature, so for real equipment check the vendor documentation. In this simulator you meet a smaller version of the same idea: a device that cannot reach the dashboard shows as offline in the dashboard, even though users behind it may be working fine.
Worked example. SW-BLR is shown offline on the dashboard at 11:05. The Bengaluru staff phone says billing is fine. Both facts are consistent: the data plane (users) is fine, the management path (switch to dashboard) is broken. The first question is therefore not "is the shop down?" but "which of the two planes is broken?".
Network: Bengaluru Branch (blr) Device Role Status Last seen MX-BLR appliance online just now SW-BLR switch offline 11 min ago AP-BLR wireless offline 11 min ago
Common mistake. Treating "offline in the dashboard" as "users are down". It only means the dashboard cannot hear the device. Always ask what users see before escalating, and always ask what changed recently.
Exam trap. "Cloud-managed" does not mean user traffic goes through the cloud. User traffic stays in the site network (or the VPN between sites). Only management traffic goes to the cloud.
The 2 a.m. SMS
The Delhi branch manager wakes you: "Dashboard says our devices are offline." You open the dashboard and see MX-DEL online but SW-DEL and AP-DEL offline. A colleague in Delhi confirms billing works. You deduce the data plane is healthy and only the management path of the switch is broken, so you check the recent change log and find that someone edited the uplink trunk an hour earlier. You roll the change back and the devices return.
Lesson: separate "are users hurt" from "can I see the device", then look at what changed.
"What is the difference between control plane and data plane in a cloud-managed network?"
Strong answer: the data plane forwards user traffic locally on the devices; the control plane (configuration and monitoring) lives in the cloud dashboard and reaches devices over an outbound management connection. If the cloud is unreachable, forwarding generally continues with the last config, but you cannot change or monitor until it returns. Mention that you would verify exact behaviour in the vendor documentation.
Key takeaways
- Cloud-managed means configuration and monitoring are in a cloud dashboard; traffic is forwarded locally.
- Control plane = rules, data plane = packet forwarding, management plane = the channel between them.
- Devices connect outbound to the cloud, so branches need no inbound holes for management.
- Offline in the dashboard is not the same as users down.
- Our tagline: click-ops, but you understand what each click does.