19 hands-on Management Plane scenarios you build in your own Cisco Modeling Labs instance and grade against the answer key. Management Plane configuration and troubleshooting practice for CCNA and CCNP.
Included with a subscription
Stand up a small enterprise-style network where routers forward device logs and SNMP notifications to a central collector. You will configure SSH management, verify reachability from end hosts, and implement Syslog + SNMP on multiple routers so the network is observable from a single collector host.
Harden a single-site management LAN by replacing insecure Telnet with SSH-only access on the router. You will generate RSA keys, define a domain name, create a local admin user with a secret, force SSHv2, and restrict VTY lines to SSH with local login. Validate success from an admin workstation and confirm Telnet is refused. The topology is intentionally simple: one router, one access switch, and two hosts on a dedicated management VLAN.
Harden Cisco IOS edge interfaces by disabling CDP/LLDP toward untrusted endpoints while keeping discovery active on trusted infrastructure links. Routers share a management LAN with a server and form a direct router-to-router adjacency for CDP/LLDP. The learner enables discovery globally, selectively suppresses it on the client-facing edge, and verifies the outcome with show commands.
Enable the open-standard LLDP on adjacent Cisco IOS routers over direct point-to-point links while also attaching the devices to a shared management LAN. Learners configure deterministic LLDP behavior (global enable plus per-interface transmit/receive) and verify neighbor discovery without adding any routing protocols or static routes.
Enable Cisco Discovery Protocol (CDP) on R1 to map directly-connected Cisco neighbors while suppressing CDP advertisements on the untrusted management-edge interface. Routers are directly cabled for true CDP adjacency and also share a common management LAN via SW1 alongside an Alpine MGMT host.
Free with an account
Advanced discovery and monitoring capstone, run as a fault hunt. The NMS has stopped seeing this site: neighbours are missing from the topology map, no traps are arriving, and syslog went quiet — while every device is reachable and pingable. You get symptoms and the required end state — no fault list. Faults span both routers and the switch they all peer through, and more than one of them leaves the monitoring configuration looking complete.
Tune which syslog messages go where on Cisco IOS using severity levels: keep detailed logs locally in a 16 KB buffer, reduce console noise to warnings, and send notifications to a central server. Single management LAN, no routing. Grading focuses on three R1 commands steering severity: logging buffered 16384 debugging, logging console warnings, and logging trap notifications.
Configure a Cisco IOS router (R1) to forward its logs to a central syslog server with accurate date/time and millisecond timestamps. Validate the remote host and trap level in show logging. This is Lab 4 of 10 in the Network Discovery & Monitoring series.
Configure a Cisco IOS router (R1) to proactively send SNMPv2c trap notifications to a centralized NMS host. Learners practice the difference between polling and traps, add the trap destination and enable device-initiated notifications, and verify deterministically with show commands. Flat L2-only management LAN; no routing, no VLAN/STP complexity.
Configure Cisco IOS SNMPv2c read-only access on R1 so an NMS on a trusted management LAN can poll device status. You will add a read-only community string and device identity (location/contact), validate from IOS show commands, and confirm basic reachability from the MGMT host. No routing protocols or static routes are used; all devices share a single management subnet bridged by an L2 switch.
Enable and verify DNS-based name resolution on Cisco IOS. R1 will use a central DNS resolver on the management LAN and also maintain a static host mapping for R2, demonstrating resolution order and operational differences between local host tables and DNS queries.
Harden the monitoring plane by replacing cleartext SNMPv2c with authenticated and encrypted SNMPv3 (authPriv) on R1. You will create a v3 group that requires privacy and a user with SHA authentication and AES-128 encryption, then verify the configuration. The flat management LAN avoids routing complexity so you can focus on the security mechanics of SNMPv3.
Harden the management plane of a single IOS router by throttling brute-force login attempts and presenting a legal-warning banner. You will enable SSH-based management, configure login block-for and delay to resist password-guessing, and verify behavior from an ADMIN Linux workstation.
Harden privileged access on a single IOS router by configuring a hashed enable secret, creating a local admin user with privilege 15 and a secret, and enabling service password-encryption. Verify that privileged access requires the secret and that the running-config contains no cleartext passwords.
Harden a Cisco IOS router so remote management is allowed only via SSH. You will remove Telnet from the VTY lines, keep local authentication, and add an idle-session timeout. Verify success from a Linux ADMIN host by confirming SSH works and Telnet is refused.
Harden the console and VTY lines on a single Cisco IOS router so idle sessions close automatically and every access path requires authentication. You will configure login local on both console and VTY, set 5-minute exec timeouts, enable logging synchronous on the console, and restrict VTY to SSH. Verification uses show outputs; grading evaluates the deterministic running-config.
Harden R1’s management plane by moving SSH login authentication and exec authorization under the IOS AAA framework using the local user database. You will start from a secure SSH-only baseline that still uses login local, enable aaa new-model, define default AAA methods that point at local, and bind VTY lines to AAA. Success is proven by authenticating from the ADMIN host over SSH and landing at the user’s privilege level.
Bring up secure remote management (SSH) on a single Cisco IOS router using a dedicated management LAN. You will configure the deterministic set of running-config lines that enable SSH with a local admin account, restrict VTY to SSH, and verify from a Linux workstation. RSA key generation is performed as an exec step and is not graded; the grading focuses on the presence of the configuration lines that make SSH functional and secure.
Free with an account
Diagnose and remediate a trunk misconfiguration between an access switch and a distribution switch so that same-VLAN hosts across two access switches can communicate end-to-end. Use CDP and trunk verification commands to investigate the fault and restore proper trunk operation, without introducing any Layer-3 routing.
The management plane is everything a device does to be administered and observed rather than to forward traffic — remote access, authentication, logging, time, discovery and telemetry. It is the least glamorous part of the syllabus and the first thing an auditor asks about, because a router nobody can log into safely, whose logs have no usable timestamps, is a router nobody can operate.
These labs build that layer properly on real Cisco IOS. You'll configure SSH with a domain name, key pair and transport restrictions, set up local and AAA authentication with privilege levels, point syslog at a collector and set the logging level that makes the output useful rather than deafening, sync the clock with NTP (including authenticated NTP, because timestamps you cannot trust are worse than none), enable SNMP with communities or SNMPv3 users, and use CDP and LLDP to discover what a device is actually connected to. Verification runs through show run | section, show logging, show ntp status and show cdp neighbors detail. Submissions are graded per requirement — note that secrets themselves are never matched literally, since IOS stores them hashed, so the checks verify the configuration is present and correct in shape rather than demanding a particular password.
Every log line, certificate check and troubleshooting correlation depends on the clock. If two devices disagree about the time, matching an event on one against an event on the other becomes guesswork — which is why the NTP labs cover authenticated sync rather than just pointing at a server.
Both. v2c with read-only communities and trap destinations, and v3 with authentication and privacy, so you can see why the version matters for anything crossing an untrusted network.
No. IOS stores secrets as one-way hashes, so a rubric that demanded a specific string would be unpassable. The checks confirm that the right kind of credential is configured on the right line, not what you chose.
Study the theory behind these labs — the concept explainer and step-by-step guides.
Looking for something else? Browse the full lab archive, narrow it to self-standing labs, or see today's daily lab.