Security Command List
Device hardening, ACLs, Layer 2 defenses, and secure management verification.
Secure management
enable secret <password> username admin secret <password> ip domain-name example.local crypto key generate rsa modulus 2048 login local transport input ssh
ACL workflow
ip access-list extended EDGE-IN permit tcp <source> <wildcard> <destination> <wildcard> eq 443 deny ip any any log ip access-group EDGE-IN in show access-lists
Layer 2 protections
switchport port-security switchport port-security mac-address sticky ip dhcp snooping ip arp inspection vlan 10 spanning-tree bpduguard enable
What and why
ACL reasoning
ACL entries are processed top-down and stop at the first match. Put specific exceptions before broad statements.
Every ACL ends with an implicit deny, so explicitly permit required traffic.
Standard IPv4 ACLs match only source address; extended ACLs can match protocol, source, destination, and transport ports.
Real scenarios you'll actually face
"I applied the new ACL and now I can't reach the device at all — including from where I'm sitting." This is the single scariest, most common ACL mistake: applying an ACL whose implicit deny-all now blocks your own management traffic, from your own IP, with no warning before you hit enter. Console access is the only way back in when this happens — it doesn't depend on the network path the ACL just broke — which is exactly why you test a new ACL from console first, or set a reload-in timer as a safety net before applying anything to a VTY line or management interface you're currently connected through.
"We found an unauthorized DHCP server handing out bad addresses on the network." Symptoms show up as scattered — some hosts get a working address, some get one pointing to a wrong or nonexistent gateway, and it looks random device to device. `ip dhcp snooping` classifies switch ports as trusted (uplinks toward the real server) or untrusted (everything else) and drops DHCP server-originated messages (Offer/Ack) arriving on untrusted ports — which is the actual fix, not chasing down which specific device someone plugged in this time, since the next rogue device is a when, not an if.
"Port security keeps shutting down a port that's supposed to be fine." `show port-security interface` reveals the actual violation count and the specific MAC address that triggered it — commonly a phone and PC daisy-chained through one port exceeding the configured MAC limit, or someone swapping which device plugs into a port without the port ever being cleared first. `err-disable recovery` can auto-recover after a timer, but recovering it without checking WHY it violated just delays the same shutdown happening again — the port isn't the problem, whatever changed on that segment is.
Want a printable copy?
This complete guide is also available as a professionally formatted PDF.
Download PDF ↓