Cisco Certified Network Associate (CCNA) 200-301 · Free study guide

Objective 6.2 — Compare traditional and controller-based networks

Traditional and controller-based networking describe management and control approaches, not a simple old-versus-new device split. In a traditional workflow, operators often configure devices individually and derive network intent from many distributed configurations. A controller-based system exposes centralized abstractions for policy, inventory, provisioning, and assurance while devices still forward traffic.

Understand distributed device operation

Traditional routers and switches run control protocols, build local operational state, and forward using their data-plane tables. Operators may use the CLI, SNMP, syslog, and separate management systems. The design can be resilient and automated, but configuration consistency often depends on disciplined templates, inventory, and change processes.

“Traditional” does not mean no software or APIs. Devices can be centrally automated without a controller owning an intent model. Conversely, installing a controller does not eliminate distributed protocols or local forwarding.

Use controller abstractions carefully

A controller can translate high-level policy into device-specific actions, maintain inventory, collect telemetry, and compare observed state with intent. Northbound interfaces serve applications or operator workflows; southbound interfaces communicate toward managed infrastructure. The exact boundary varies by product and architecture.

Central visibility can simplify consistent change and assurance. It also creates trust, availability, scale, and version-compatibility requirements. Operators must know what happens when the controller or its network path is unavailable. Many devices continue forwarding from existing state, but new policy or telemetry may be affected; the behavior is architecture-specific.

Worked scenario

A company wants every branch guest network isolated from corporate resources. With per-device configuration, engineers translate that intent into VLANs, ACLs, routing, and wireless policy at each branch, then gather evidence from multiple tools. A controller-based workflow may define one policy and render the necessary device actions. In either case, engineers must validate exceptions, device support, propagation, and actual traffic behavior.

Compare operational questions

For either approach, identify the source of truth, unit of change, approval path, failure domain, drift-detection method, and recovery mechanism. Per-device access can be valuable during controller-path failures; unrestricted local changes can also create drift. Define which interface is authoritative and how emergency changes are reconciled.

Verification evidence

In a traditional environment, compare intended templates with running state, routing or switching tables, logs, and end-to-end tests. In a controller-based environment, also inspect policy status, device health, synchronization, rendered configuration, and assurance results. Do not accept a green dashboard without testing the relevant forwarding outcome.

Common traps

• Saying controller-based devices no longer have a data plane.
• Assuming traditional networks cannot use automation.
• Treating centralized policy as proof of successful enforcement.
• Ignoring controller reachability and trust.
• Making local emergency changes with no reconciliation plan.

Readiness checklist

• I can compare per-device and centralized intent workflows.
• I distinguish controller policy from device forwarding.
• I can identify northbound and southbound relationships.
• I include availability, drift, and verification in both models.