CCNA ACLs and Switch Security: Test the Policy
CCNA ACLs and Switch Security: Test the Policy
Security controls become convincing only when their effect can be measured. An access list that appears correct in configuration can be applied in the wrong direction, match the wrong source address or unintentionally block a legitimate application. DHCP snooping and Dynamic ARP Inspection can protect a switched VLAN yet also disrupt it if ports or bindings are misclassified. This CCNA 200-301 lab focuses on evidence from permitted and denied traffic, not on copying a security template.
Use a private isolated lab with a client subnet, an authorized administrative workstation, a test server and a distribution switch. Start by writing the policy in plain language: which sources should reach which destinations and services? Then implement one control at a time and verify positive tests as well as negative tests. The current v1.1 blueprint covers security fundamentals; the revised CCNA exam is scheduled for February 2027 and has its own published objectives.
| Control | Positive and negative validation |
|---|---|
| Extended IPv4 ACL | Authorized HTTPS passes; unauthorized source/port is denied |
| Management restriction | Approved admin workstation authenticates; other user source cannot |
| DHCP snooping | Lease from intended server passes; untrusted server response does not |
| Dynamic ARP Inspection | Valid bound host resolves; invalid ARP mapping is rejected |
| Port security | Approved endpoint operates; unauthorized MAC triggers the configured action |
Write a policy matrix before typing any ACL
Assume users in VLAN 20 need HTTPS to a web server in VLAN 30 and DNS to an approved resolver, but not SSH access to the server. The operations workstation in VLAN 99 may use SSH to the router’s management interface. A useful policy matrix lists source, destination, transport and action. The intent is measurable: successful HTTPS, successful approved DNS and denied unauthorized SSH must all be observed from the correct source.
Use only documentation prefixes and reserved test networks for any external-looking addresses, and confirm that the lab topology has no path to real production systems. Distinguish traffic headed to a router’s management plane from transit traffic forwarded through it. A policy protecting administrative login is not interchangeable with an ACL that filters client-to-server data. A single vague statement such as “block insecure traffic” is not precise enough to test or troubleshoot.
Understand direction and address matching
Cisco IPv4 extended access lists can match protocol, source and destination parameters, including ports when supported. An ingress ACL is evaluated as packets arrive on the relevant interface; an egress ACL applies as packets leave. The choice affects which source and destination values appear at evaluation time and what other permitted flows might be caught. A rule written for user-to-server traffic may do nothing if attached to the wrong interface or direction.
Before applying a policy, trace one example packet: original source address, destination, protocol and destination port. Follow the packet across the intended interfaces and mark the point at which the ACL will evaluate it. This is especially important in networks with translation or multiple Layer 3 boundaries. The correct fix for a no-match counter is to check the attachment and tuple first, not to broaden the rule until unrelated traffic begins passing.
Ordering and the implicit deny need practical tests
ACL entries are tested according to their defined ordering and matching behavior, and many Cisco ACL use cases include an implicit deny at the end. A broad deny entry placed before a narrow intended permit can make the permit unreachable. Conversely, a broad permit placed too early can swallow traffic that a later rule was supposed to restrict. Good implementation begins with the narrow requirements, then verifies the actual order the device is using.
Create a test with one authorized HTTPS client, a second unauthorized client and an SSH attempt that should be denied. Apply the ACL in the lab and inspect show access-lists or the platform’s corresponding counter view while generating known traffic. Counters are useful when they increment, but their absence does not always prove traffic never passed—platform acceleration and logging behavior may affect visibility. Combine them with endpoint success/failure results and explicit interface attachment checks.
Separate the management plane from user data
A router or switch may accept administrative access through console or virtual terminal lines, management interfaces and local or centralized identity controls. Granting ordinary client VLANs unrestricted access to these surfaces creates avoidable risk. In the lab, the operational workstation should be able to establish an authorized SSH session while an ordinary client should not. Verify the rule without disabling the administrative path on which you depend to recover the device.
If using an access-class or VTY restriction, distinguish that mechanism from a routed interface ACL. Test from more than one source and preserve a safe console or out-of-band management method before applying restrictions. A device might be perfectly reachable for forwarding while management login is correctly denied. That is a valid policy result; do not mistake it for a routing failure and undo a working security control.
DHCP snooping decides which ports can supply leases
DHCP snooping is designed to distinguish authorized DHCP server paths from untrusted client-facing switch ports. A rogue DHCP responder on an access port should not be permitted to dictate leases. The trusted/untrusted classification must follow the actual topology; a misplaced untrusted designation on the real server-facing path can prevent legitimate clients from receiving valid configuration.
Use a small VLAN in which one uplink leads to the intended DHCP server. Enable the feature only on supported lab hardware and apply trust according to the design. Verify the learned binding table using show ip dhcp snooping binding where supported. Intentionally misclassify the server path in the isolated lab, observe the failed lease transaction, then restore the correct trust boundary. Avoid turning every client-facing port into a trusted port just to make DHCP work.
A complete DHCP snooping test also asks what happens when a server is moved to another switch or an uplink is reconfigured. The trust boundary should follow the authorized server path, not a memorized physical port number. Capture the offered DHCP server identifier and expected client lease before making the change, and verify afterward that the new trusted path carries legitimate offers while access ports still cannot inject unauthorized ones. Document the decision as a topology rule; otherwise a future maintenance change can silently undo the intended protection.
Dynamic ARP Inspection depends on credible bindings
Dynamic ARP Inspection (DAI) validates relevant ARP information against trusted sources such as DHCP-snooping bindings or explicit authorized entries, depending on platform and configuration. This can help limit certain ARP-spoofing attacks, but the protection also depends on knowing which hosts legitimately use static addresses. Applying DAI without accounting for such devices may result in apparent random reachability failures.
After DHCP snooping builds a correct binding for a leased host, enable the intended DAI policy in the lab and observe normal ARP learning. Then introduce a deliberately inconsistent sender IP-to-MAC mapping on an isolated test device and verify that the switch records or drops it according to policy. Cisco documentation emphasizes validating bindings and trust points; a drop is meaningful only when the observed packet and configured intent are understood.
Port security has a separate role
Port security can limit or control which source MAC addresses are permitted on an access interface, with violation actions varying by configuration. It is not a substitute for DHCP snooping or ARP validation. A legitimate endpoint replacement may trigger a violation if a stale sticky MAC or restrictive limit remains in effect. The answer is not to turn off the control whenever a helpdesk ticket appears, but to verify the design and the exact violation evidence.
In a controlled lab, attach an expected endpoint, record learned secure MAC state, then substitute a second device and observe the configured reaction. Restore the approved endpoint and recover the interface according to the platform’s supported procedure. Compare this incident with a DHCP snooping failure: both can leave a client without useful connectivity, but one centers on MAC admission and the other on DHCP message validation.
Build a positive and negative test matrix
A policy is not verified by demonstrating only that unwanted traffic is blocked. Test the intended HTTPS and DNS connections, the expected failure of unauthorized SSH, legitimate DHCP lease renewal and ARP reachability for approved clients. When a rule is changed, repeat both kinds of checks to detect collateral damage. The evidence table should include source endpoint, service, expected result, observed result and applicable device counter or log.
Add one compound scenario: a new workstation receives no lease and also cannot reach the server after a manual static address assignment. DHCP snooping may explain the failed lease, while an ACL can independently explain the traffic denial. A correct incident resolution identifies both constraints without broadening unrelated permits. This develops the skill of finding several simultaneous faults without losing track of which observation supports each conclusion.
Make the conclusion about intent, not rule count
A short, precisely attached ACL can be more secure and maintainable than dozens of poorly ordered entries. Similarly, DHCP snooping or DAI should not be enabled simply because the feature sounds defensive; it must match where DHCP servers and trusted infrastructure actually sit. State the behavior to protect, gather baseline traffic evidence, introduce the control and prove the resulting allowed and denied flows.
These implementation details connect to a broader Cisco security architecture in which identity, segmentation, device management and telemetry interact. The associate-level lab keeps the scope small, but the reasoning is the same in production: secure the intended path, preserve legitimate service and use observable evidence to distinguish a policy violation from a networking fault.
- Category: Certifications Cisco
