BeginnerPublished 2026-09-17
CCNA Break/Fix: The Management Filter That Guards Nothing
Archive lab
Lab 3 of 13 in CCNA Break/Fix II: Read the Symptom · ← Previous · Next →
A security audit showed that routers accepted SSH from outside the management LAN despite an existing filter. Diagnose how the management ACL is bound to the VTY lines and make it govern which inbound sessions the routers accept, without breaking data-plane reachability.
Learning objectives
- Diagnose why a management-plane filter fails to block unwanted SSH sessions
- Trace SSH reachability end-to-end to distinguish control-plane filters from data-plane routing
- Isolate the binding point that governs which terminal sessions a router accepts
- Compare terminal idle policies across devices and verify a consistent five-minute timeout
- Verify that data-plane ICMP remains unaffected while management access is corrected
Troubleshooting focus
- Check data-plane reachability first: verify R3-REMOTE can ping R1-MGMT's management IP using the transit interface as source; if pings fail, fix routing before management-plane work.
- From each router, examine how the management filter is associated with the terminal lines and whether that association controls incoming sessions vs. other traffic classes.
- Confirm the SSH management plane is complete on each router: hostname, domain name, RSA keys, local user, VTY using SSH and local login; missing prerequisites produce connection or authentication errors unrelated to the filter.
- Differentiate the filter's effect from data-plane ACLs: a VTY-bound filter should not block ICMP or other forwarding; if it does, it's not the right control used.
- Compare terminal idle policies on all routers and align them to the intended five-minute standard so dormant sessions do not persist indefinitely.
Topology
Subscribe to preview this lab's topology.
See plansGrade your work
How this lab is graded
- Build it your way. Where a lab lets you choose a value — a VLAN name, an interface description — grading checks that you configured it, not which name you picked. Names that another line has to reference, like an ACL applied with
access-class, are stated in the guide and do have to match. - Addresses, modes and protocol keywords are exact. An IP address, a subnet mask,
switchport mode trunk, an encapsulation — these carry the meaning of the lab, so they are graded as written in the guide. - Grading reads your saved configuration. Export the lab from CML after you have configured it, and make sure anything you set is in the
running-config— a change that only exists in a terminal session never reaches the grader. - You can submit as many times as you like. Your best score stands, and each attempt tells you which checks passed so you can work the gaps.
- Scored something you believe is correct? Use Report an issue on this page — that is exactly how the grading fixes in the changelog got found.
Create a free account to submit your lab for grading.
Create a free accountFound a problem with this lab?
Please sign in to report a problem — tying it to your attempts lets us reproduce and fix it faster.