Network management approaches: device, cloud, controller, automation and infrastructure as code

Why this matters

Every network has to be configured, changed and watched, and there is more than one way to do it. A small office might have three switches that an engineer configures by hand. A retail chain might run hundreds of stores from a web dashboard. A campus might be run from a controller, and a modern operations team might keep every configuration in a version-controlled repository. A network technician or junior network engineer joining a team needs to recognise which model the team uses, because it decides where a change is made, where the truth about the configuration lives and what happens if someone makes a change in the wrong place.

Getting this wrong causes real trouble. An engineer who logs in to one switch and fixes it by hand, on a network managed from a controller or a repository, has created a device that no longer matches the system meant to control it. The next automated run may undo the fix, or the fix may hide for months until it breaks something. Knowing the approaches, and their strengths and costs, is how you avoid making that change.

The lesson

Five ways to manage a network

The five approaches differ in two ways: where the configuration is defined, and what pushes it to the devices.

The worked example running through this lesson is one change: point 40 branch switches at a new NTP server, 10.0.0.6, instead of the old one, 10.0.0.5.

Device-based management

Device-based management means configuring each device on its own, normally over SSH (or the console for first setup), with no central system holding the configuration. The device's running and startup configuration is the only record of what it should be.

BR07-SW1#configure terminal
BR07-SW1(config)#no ntp server 10.0.0.5
BR07-SW1(config)#ntp server 10.0.0.6
BR07-SW1(config)#end
BR07-SW1#copy running-config startup-config
Destination filename [startup-config]?
Building configuration...
[OK]

Now repeat that 39 more times. That is the approach's cost: it is slow at scale, each session is a chance for a typing mistake, and nothing stops switch 23 being configured slightly differently from switch 24. Its strengths are that it needs nothing but the device, it works when everything else is broken, and it is the right way to learn how a device behaves. Every CCNA candidate must be fluent at it, because every other approach eventually runs the same commands or their equivalent.

Cloud-based management

Cloud-based management puts the management platform in a cloud that the vendor hosts and maintains. Each device connects outbound over the internet to the vendor's dashboard, receives its configuration from there, and reports its status back. Staff configure every site through a web dashboard; Cisco Meraki is a well-known example of the model.

For the NTP change, an engineer edits one setting in the dashboard, for a network or a group of stores, and the platform pushes it to every device that belongs to it.

What to know:

• There is no controller appliance to run in your own data centre. The vendor runs the platform, patches it and scales it.
• Because devices connect out, a new store usually needs only internet access for its devices to find the dashboard.
• The configuration lives in the vendor's platform, not in files your team versions and reviews, and not only in each device's NVRAM.
• The trade-offs are dependence on internet reachability for management, a subscription, and data about your network held by a third party.

Controller-based management

Controller-based management places a controller inside your own network. The controller holds network-wide policy and a single view of every managed device, and it pushes consistent configuration to them. Cisco Catalyst Center is Cisco's controller for campus and branch networks; Catalyst 9800 wireless LAN controllers manage access points in a similar way.

The main benefit over device-based management is that policy is defined once and pushed to many devices. For the NTP change, the engineer updates the NTP setting in the controller's network settings for the branch sites, and the controller configures all 40 switches. Devices do not keep independent policy, and they still need management addresses so the controller can reach them.

Two terms describe how a controller talks to the world:

• The southbound interface connects the controller down to the devices it manages. It uses protocols such as NETCONF, SSH (CLI) and SNMP (lesson 27) to push configuration and collect state.
• The northbound interface faces up, toward applications and scripts. It exposes APIs, usually REST APIs returning JSON, that let other systems ask the controller for information or request changes.

A script asking Catalyst Center for its device list uses the northbound API, for example:

GET https://catalyst-center.example.internal/dna/intent/api/v1/network-device

When the controller then configures a switch because of that request, it does so southbound. There is no "eastbound interface" in this model, and the out-of-band console is a way into one device, not the controller's channel to the network.

Automation-based management

Automation-based management uses scripts or tools, such as Python or Ansible, to apply the same change to many devices in one run. There is no controller, and the tool does not keep a declared desired state between runs. It does what it is told, on demand.

For the NTP change, an engineer writes a short task that connects to all 40 switches over SSH and sends the two NTP lines. Lesson 28 shows how to do this with an Ansible playbook:

- name: Move branch switches to the new NTP server
  hosts: branch_switches
  gather_facts: false
  tasks:
    - name: Replace the NTP server
      cisco.ios.ios_config:
        lines:
          - no ntp server 10.0.0.5
          - ntp server 10.0.0.6

The difference from device-based management is who does the work. In device-based management a person types the change at each router's CLI, one session at a time. In automation-based management a tool pushes the wanted configuration to many devices in one run. The commands that reach the devices can be identical.

The difference from infrastructure as code is subtler. A script that "reads a list of 200 router addresses, pushes three logging commands, runs once and stores nothing" is automation-based. Nothing records what the routers should look like afterwards, so nothing notices if one changes later.

Infrastructure as code

Infrastructure as code (IaC) treats a set of declared configuration files in version control, usually a Git repository, as the source of truth for the network. The files say what each device should look like. A change is a change to the files.

The workflow:

1. An engineer edits the file, for example changing the NTP server for the branch group.
2. The change is peer reviewed, as a pull request or merge request.
3. A pipeline tests it and then applies it, using tooling such as Ansible.
4. The repository keeps a full history: who changed what, when, why, and how to put it back.

# group_vars/branch_switches.yml (in the repository)
ntp_servers:
  - 10.0.0.6
logging_hosts:
  - 10.20.0.50

Because the tooling knows the declared state, it can compare it with what is running and change only what differs. That property is called idempotence: applying the same declaration twice leaves the device in the same state, and the second run reports no change.

Configuration drift is the gap between the declared configuration in version control and what is actually running. It usually appears when someone changes a device by hand over SSH. Here an engineer added a logging host directly on one switch:

BR07-SW1#show running-config | include logging host
logging host 10.20.0.50
logging host 10.20.0.99

The repository declares only 10.20.0.50, so 10.20.0.99 is drift. IaC tooling exists to detect and correct drift: a check run reports the difference, and the next applied run removes the unrecorded line unless someone adds it to the files through review. That is why the rule on an IaC network is simple: change the files, not the device.

One term that sounds related but is not: zero-touch provisioning (ZTP) is the automatic onboarding of a brand new device the first time it boots, when it fetches an initial configuration from the network. It is about first boot, not about unrecorded changes.

Comparing the approaches

• Scale. Device-based is slowest at scale. The other four all change many devices from one place.
• Source of truth. Device-based: each device. Cloud-based: the vendor's platform. Controller-based: your controller. Automation-based: none kept between runs. IaC: the repository.
• Hosting. Cloud-based is the only approach where the vendor hosts and maintains the management platform.
• Review and history. IaC builds them in. The others need separate change control.
• Mixing. Real networks combine approaches. A team might use IaC with Ansible for routers, a controller for campus switching and wireless, and still use the CLI for troubleshooting. The CLI is also how you recover a device when the central system cannot reach it.

What the exam is really asking

• One SSH session per device is device-based, however many devices there are.
• A vendor-hosted dashboard that devices connect out to is cloud-based. A controller appliance in your data centre is controller-based, not cloud-based.
• Southbound vs northbound. Controller to devices is southbound (NETCONF, SSH, SNMP). Applications to controller is northbound (REST APIs).
• Main benefit of a controller. Policy defined once and pushed to many devices.
• Automation-based vs IaC. A script that pushes commands and stores no desired state is automation-based. Declared files in Git, reviewed and applied by a pipeline, are infrastructure as code.
• Drift is running configuration that no longer matches the repository. ZTP is first-boot onboarding.
• Idempotent means a second run with no changes reports nothing changed.