Network Management Approaches

Mental model

The five approaches in CCNA v2.0 objective 5.3 are five answers to two questions:

1. How does a change get made? A person typing CLI, a click in a web dashboard, a controller pushing policy, a script, or a reviewed change to a file in a Git repository.
2. Where does the configuration source of truth live? On each device, in a vendor cloud, on a controller, in whatever data the script reads, or in version control.

Most exam scenarios for this objective can be answered with those two questions. In the v2.0 blueprint this objective sits in domain 5.0, “AI, and Network Operations and Management”, next to SNMP, syslog and Ansible.

The five approaches at a glance

Device-based

This is the classic way. You SSH to a switch (or plug in a console cable), enter configure terminal, type commands, and save with copy running-config startup-config. Then you move to the next switch and do it again.

• Source of truth: each device’s own config. There is no central copy unless someone backs one up.
• Pros: needs nothing but the device, works when everything else is down, and it is how you troubleshoot at the lowest level.
• Cons: slow at scale, easy to typo, and configs drift apart over time because every change is manual.

Cloud-based

Here the management platform runs in the vendor’s cloud. Devices connect out to it, and you manage them from a web browser or through the cloud’s API. Cisco Meraki is the standard example: switches, access points and security appliances are configured in the Meraki Dashboard.

Some Catalyst 9000 switches can also be cloud managed in the Meraki Dashboard. In cloud configuration mode, Meraki’s documentation says the Meraki cloud is the authoritative source for all configuration. In device configuration mode, the config stays on the switch.

• Source of truth: the vendor cloud (in cloud configuration mode).
• Pros: no management server to install or patch, easy to run many small sites, simple interface.
• Cons: needs a subscription and internet reachability to the cloud, and you get the features the dashboard exposes, not every CLI knob.

Controller-based

A controller is a management system you deploy (as an appliance or a virtual machine) that holds the policy and pushes it to the devices it manages. This is the approach covered in more depth on the SDN and controllers page.

Cisco examples:

• Catalyst Center (formerly DNA Center) for campus and branch networks. See Catalyst Center.
• Wireless LAN Controller (WLC) managing lightweight access points.
• Catalyst SD-WAN Manager (formerly vManage) for the SD-WAN fabric.

You make a change once on the controller (GUI or REST API), and it works out what each device needs.

• Source of truth: the controller’s database of intent and templates.
• Pros: one place to manage many devices, consistent policy, built-in visibility and assurance.
• Cons: the controller itself must be sized, licensed, backed up and made highly available. Changes made on the device CLI behind its back can cause drift.

Cloud-based and controller-based feel similar because both are central. The difference is where the brain runs: in the vendor’s cloud, or on a system in your own environment.

Automation-based

Automation means a program does the repetitive work instead of a person. A Python script using the Netmiko library can SSH to 50 switches and push the same commands. An Ansible playbook can run show commands or push config across an inventory. Scripts can also use model-driven APIs such as NETCONF and RESTCONF instead of screen-scraping CLI.

• Source of truth: usually still the devices. The script is just a faster pair of hands.
• Pros: fast, repeatable, fewer typos.
• Cons: a bad script makes the same mistake everywhere at once, and ad hoc runs are hard to audit.

For a working example with an Ansible playbook in the v2.0 context, see the CCNA v2.0 AI domain guide.

Infrastructure as code

Infrastructure as code (IaC) takes automation one step further. Cisco describes IaC as defining and provisioning infrastructure using definition files containing code. In practice for networks that looks like this:

1. The desired state of the network (VLANs, interfaces, routing, policy) is written in files, usually declarative data such as YAML or Terraform configuration.
2. Those files live in a version control system such as Git.
3. A change is a commit. Someone reviews it (a pull request) before it merges.
4. A pipeline tests the change and then uses a tool such as Terraform or Ansible to make the network match the files.

• Source of truth: the repository. If the network and the repo disagree, the repo wins and the next run fixes the network.
• Pros: full history of who changed what and why, peer review, and easy rollback to a previous commit.
• Cons: takes discipline and tooling to set up. Manual CLI changes break the model unless they are brought back into the repo.

How they fit together

Real networks mix these. A common picture:

• Campus switches managed by Catalyst Center (controller-based).
• Branch sites on Meraki (cloud-based).
• An Ansible playbook that pulls inventory and backs up configs every night (automation-based).
• Data center fabric config stored in Git and applied by Terraform through a pipeline (IaC).
• An engineer on the console fixing a switch that lost its uplink (device-based).

The approaches also stack. An IaC pipeline can call a controller’s API instead of touching devices directly. When a scenario mentions more than one tool, look for where the truth lives and how the change was approved.

Common mistakes

1. Calling any script “infrastructure as code”. Running a script is automation. It becomes IaC when the declared desired state lives in version control, changes go through review, and that repository is the source of truth. A Python script run by hand from a laptop is automation-based even if the script is saved in Git.

2. Mixing up cloud-based and controller-based. Both are central. Meraki Dashboard runs in the vendor cloud. Catalyst Center, a WLC or SD-WAN Manager is a controller you deploy and operate.

3. Thinking device-based is obsolete. Console and SSH access are still how you recover and troubleshoot. Every other approach assumes someone can fall back to the device when needed.

4. Assuming Ansible always means IaC. Ansible can be used either way. A playbook run ad hoc is automation. The same playbook driven from a reviewed Git repository through a pipeline is part of IaC.

5. Ignoring drift. With controller, cloud or IaC management, a quick CLI fix on the device makes the device disagree with the source of truth. Either put the change back into the central system or expect it to be overwritten.

Practice: which approach is it?

1. An engineer consoles into a new router and types the base config line by line. Answer: device-based.
2. A retail company manages switches and access points at 300 stores from a web portal hosted by the vendor, with no management server on site. Answer: cloud-based.
3. The team defines a campus fabric policy once in Catalyst Center, and it is pushed to all access switches. Answer: controller-based.
4. A Python script with Netmiko logs into 80 switches and adds an NTP server to each. Answer: automation-based.
5. VLAN definitions live in YAML files in Git. A pull request is reviewed, merged, and a pipeline applies it to the network. Answer: infrastructure as code.

Cheat strip

Frequently asked questions

Q: What is the difference between automation-based and infrastructure as code? A: Automation uses scripts or playbooks to make changes faster. Infrastructure as code also uses automation, but the desired state is declared in files under version control, changes are reviewed, and that repository is the source of truth.

Q: Is Meraki cloud-based or controller-based? A: For CCNA purposes, Meraki is the standard cloud-based example because the management platform runs in Cisco’s cloud. Catalyst Center, WLCs and SD-WAN Manager are the controller-based examples.

Q: Is Catalyst Center the same as DNA Center? A: Yes. Cisco renamed DNA Center to Catalyst Center. Older documents and some API versions still use the DNA Center name.

Q: Do I need to write Terraform for the CCNA? A: No. Objective 5.3 asks you to describe the approaches. Objective 5.5 is the hands-on one, and it names Ansible.