11.6 2 Lab Switch Security Configuration

You're staring at the lab instructions. Day to day, the PDF says "11. Day to day, again. Think about it: 6. 2 Lab - Configure Switch Security Features" and your brain is already trying to decide: do I actually learn this, or do I just copy the commands from the answer key and move on?

Been there. We've all been there.

But here's the thing — switch security isn't just another checkbox on your CCNA journey. It's the difference between a network that survives a Tuesday morning attack and one that becomes a case study in "what not to do.Practically speaking, " And unlike routing protocols that mostly just work once configured, switch security features fight you. Still, they shut down ports you need. But they block legitimate traffic. They generate syslog messages at 3 AM that wake you up for no reason.

So let's actually walk through this lab. In real terms, not the "type these commands" version. The "here's why each command exists and where it'll bite you" version That alone is useful..

What Is the 11.6.2 Switch Security Lab

If you're in the current CCNA curriculum (200-301), this lab sits in the switching module — specifically the section on securing Layer 2. The lab topology is straightforward: a couple of switches, a router for inter-VLAN routing, a few PCs, and maybe a wireless access point hanging off an access port Which is the point..

The lab asks you to configure:

• Port security with sticky MAC addresses
• DHCP snooping and DAI (Dynamic ARP Inspection)
• IP Source Guard
• Storm control
• BPDU guard and root guard
• 802.1X authentication (sometimes optional depending on packet tracer version)

That's a lot. And Packet Tracer — bless its heart — only supports a subset of these features properly. You'll configure DHCP snooping and it'll accept the commands, but good luck seeing actual binding tables populate the way they do on real hardware.

The Real-World Context

This lab exists because Layer 2 is inherently trusting. So a switch assumes every device plugged into it is legitimate. Every frame is forwarded based on MAC address tables built dynamically. Every ARP request is believed. Every DHCP reply is accepted.

That trust model made sense in 1995. Today? It's how attackers pivot from a compromised receptionist's PC to your core database VLAN in twenty minutes.

Why This Lab Actually Matters

Most students treat switch security as "config I memorize for the exam." That's a mistake.

Port security stops the intern from plugging in a 5-port dumb switch under their desk and connecting three unauthorized devices. DHCP snooping prevents a rogue DHCP server from handing out gateway addresses that point traffic through an attacker's laptop. DAI stops ARP poisoning — the technique that lets someone silently intercept every packet between your CFO and the financial server The details matter here..

Storm control? That's your insurance policy against the broadcast storm that happens when someone loops two ports on the same switch with a single cable. It happens. More often than you'd think.

BPDU guard and root guard protect your spanning-tree topology. That said, without them, a misconfigured switch plugged into an access port can become the new root bridge and reconverge your entire Layer 2 domain. That said, during business hours. While you're explaining to the CIO why the VoIP phones all dropped.

These aren't theoretical. I've seen every single one in production networks Easy to understand, harder to ignore..

How to Configure Each Feature — And Why the Details Matter

Let's go feature by feature. I'll show you the commands, but more importantly, I'll tell you the knobs you need to turn and the defaults that will surprise you.

Port Security: The First Line of Defense

interface range GigabitEthernet1/0/1 - 24
 switchport mode access
 switchport port-security
 switchport port-security maximum 2
 switchport port-security violation restrict
 switchport port-security mac-address sticky

What most people miss: The default violation mode is shutdown. That means the first violation puts the port in err-disabled state. You'll be manually running shutdown / no shutdown on ports all day. restrict drops violating frames but keeps the port up and logs the event. protect drops frames silently — no logs, no alerts. Don't use protect unless you enjoy debugging invisible problems Small thing, real impact..

Sticky MAC addresses learn the first MAC(s) seen and save them to the running config. But — and this catches everyone — they don't persist across reloads unless you copy running-config startup-config. Your lab grade might depend on that Worth keeping that in mind..

Maximum 2 allows a PC and a VoIP phone (which often shares the port via a mini-switch in the phone base). If you set it to 1, the phone won't register. Ask me how I know And that's really what it comes down to. No workaround needed..

DHCP Snooping: Trust But Verify

ip dhcp snooping
ip dhcp snooping vlan 10,20,30
ip dhcp snooping limit rate 10
no ip dhcp snooping information option
!
interface GigabitEthernet1/0/1
 ip dhcp snooping limit rate 10
!
interface GigabitEthernet1/0/24
 ip dhcp snooping trust

The critical concept: Trusted vs. untrusted ports. Only uplink ports toward your legitimate DHCP server should be trusted. Every access port is untrusted by default — and that's correct.

Rate limiting matters. A DHCP starvation attack sends thousands of DISCOVER frames with spoofed MACs, exhausting your pool. The default rate limit is unlimited. Set it. Ten per second is reasonable for normal clients. If you have PXE boot environments, you might need higher during morning boot storms Turns out it matters..

Option 82 (the information option) inserts circuit ID and remote ID into DHCP requests. Some legacy DHCP servers choke on it. The lab often has you disable it. In production, leave it enabled — it helps your DHCP server make policy decisions based on switch/port.

Dynamic ARP Inspection: Stopping the Man in the Middle

ip arp inspection vlan 10,20,30
ip arp inspection validate src-mac dst-mac ip
!
interface GigabitEthernet1/0/24
 ip arp inspection trust

DAI validates ARP packets against the DHCP snooping binding table. If a device claims an IP-MAC pairing that isn't in the table, the frame is dropped Simple, but easy to overlook..

Here's the catch: DAI requires DHCP snooping to be functional first. No binding table = no validation = every static IP device fails ARP. You must configure static bindings for servers, printers, and any device with a static IP:

ip source binding 0011.2233.4455 vlan 10 192.168.10.50 interface GigabitEthernet1/0/5

Forget this step and your management VLAN goes dark. The lab might not test static IPs, but real networks absolutely have them Easy to understand, harder to ignore..

IP Source Guard: The Partner to DAI

interface range GigabitEthernet1/0/1 - 20
 ip verify source

IP Source Guard filters traffic at Layer 2/3, ensuring a host only sends traffic with its assigned IP (from DHCP snooping binding or static binding). It prevents IP spoofing on the local segment Small thing, real impact..

Packet Tracer limitation: This often doesn't work in PT. The commands accept, but traffic filtering doesn't actually happen. On real gear (2960-X,

Working Around Packet Tracer’s IP Source Guard Shortcomings

In Packet Tracer the ip verify source command is accepted but the switch does not actually enforce the filter. This is by design—the emulation focuses on higher‑level networking behavior rather than low‑level hardware ACLs. To get a realistic feel for how IP Source Guard works, you can:

If you’re stuck with PT, focus on the configuration and verification commands; the actual traffic filtering will be observed only on real hardware.

Verifying IP Source Guard on Real Hardware

After applying ip verify source (or ip verify source port-security for stricter checking) you should confirm that the binding table is being used:

Switch# show ip source binding
IP source bindings:
    0011.2233.4455, VLAN 10, 192.168.10.50, GigabitEthernet1/0/5
    0022.3344.5566, VLAN 20, 192.168.20.75, GigabitEthernet1/0/12
Switch# show ip dhcp snooping binding
Total number of bindings: 2
    192.168.10.50 0011.2233.4455 vlan 10
    192.168.20.75 0022.3344.5566 vlan 20
Switch# show ip verify source
Interface          Source IP Verification
Gi1/0/5            Enabled
Gi1/0/12           Enabled
Switch# show ip arp inspection
...

These commands confirm that:

• Bindings exist – either from DHCP snooping (dynamic) or static entries.
• IP Source Guard is active on the designated ports.
• DAI can later reference the same binding table for ARP validation.

If a port shows “Disabled” or the binding table is empty, the protection isn’t operational and you must revisit the preceding DHCP Snooping configuration.

Troubleshooting Common IP Source Guard Issues

Additional Troubleshooting Scenarios

1. Rate‑limit misconfiguration – If the DHCP‑snooping limit is set too low, legitimate DHCPDISCOVER packets can be discarded before the binding table is populated, causing the switch to treat the host as untrusted and drop subsequent traffic. Raise the limit to a value that comfortably exceeds the expected renewal frequency (e.g., ip dhcp snooping limit rate 20) and then re‑apply the ip verify source command on the affected ports.

2. VLAN‑mismatch between DHCP snooping and source‑guard – The protection only works when the VLAN in which the binding is learned matches the VLAN on which ip verify source is enabled. A common oversight is enabling the command on a port that belongs to a different VLAN than the one used for DHCP snooping. Confirm with show ip verify source that the interface and VLAN pair align with the bindings shown by show ip dhcp snooping binding That's the part that actually makes a difference..

3. Static‑IP devices bypassing DHCP – Servers that use manually assigned addresses do not generate DHCP traffic, so no binding is learned automatically. If such a device is placed on a port that relies on DHCP‑derived bindings, the switch will never create a valid entry, and the source‑guard check will fail. Manually insert a static binding with ip source binding <MAC> vlan <VLAN> <IP> interface <IF> and verify that the MAC‑IP pair appears in the binding table.

4. Trunk ports and source‑guard – Source‑guard is typically applied only to access ports. When a trunk port is mistakenly placed under source‑guard, the command may be rejected or the verification may be ineffective because the switch cannot associate a single IP address with a trunk that carries multiple VLANs. If trunk ports must be protected, consider using port‑security with MAC‑limit or DHCP‑snooping alone, as source‑guard does not provide meaningful filtering on trunks Still holds up..

5. Interaction with other security features – Enabling IP Source Guard alongside IP DHCP Snooping and ARP Inspection creates a tightly coupled security pipeline. If any of the companion features is mis‑configured (e.g., ARP‑inspection disabled on a VLAN), the overall protection can be weakened. Verify the entire chain with show ip arp inspection and show ip dhcp snooping to ensure each component is operational before relying on source‑guard for enforcement And that's really what it comes down to..

6. Logging and alerting – When a spoofed packet is dropped, the switch logs the event with a severity level that can be tuned. Enable logging for security events (logging buffered 10000 severity informational) and monitor the syslog for “IP source guard drop” messages. Correlating these logs with the binding table helps pinpoint mis‑configurations quickly Simple, but easy to overlook..

Best‑Practice Checklist for a Production Deployment

1. Enable DHCP snooping globally and per‑VLAN, then set a conservative rate limit that matches the expected DHCP traffic pattern.
2. Configure IP Source Guard only on access ports that host end‑devices; avoid applying it to trunks or server farms.
3. Create static bindings for any device that does not obtain its address via DHCP, and verify the entry appears in the binding table.
4. Validate the binding table with show ip source binding and show ip verify source after every change.
5. Test the protection by attempting to spoof an IP address from a controlled host; confirm that the switch drops the traffic and logs the event.
6. Document the VLAN‑interface mapping for each protected port to prevent future mismatches during network re‑architecting.
7. Integrate logging and monitoring into your NMS so that drop events trigger alerts and can be correlated with other security telemetry.

Conclusion

IP Source Guard provides a straightforward yet powerful mechanism for preventing IP‑address spoofing on switched LANs, but its effectiveness hinges on a correctly built DHCP‑snooping binding table and precise application of the verification command to the appropriate ports. By systematically configuring DHCP snooping, establishing both dynamic and static bindings, enabling source‑guard on the right interfaces, and continuously verifying the binding table, network administrators can reliably block unauthorized IP usage. When issues arise — whether due to rate‑limit thresholds, VLAN mismatches, or static‑IP devices — targeted troubleshooting steps such as adjusting DHCP

rate limits, verifying VLAN associations, or auditing static bindings can resolve most problems. The key to success lies in treating IP Source Guard not as a standalone feature but as part of a layered defense strategy. Combining it with features like Dynamic ARP Inspection (DAI) and DHCP Snooping ensures that even if an attacker bypasses one layer, subsequent protections remain intact. Here's one way to look at it: if a spoofed IP address is used to send malicious ARP traffic, DAI will detect and drop the frame, while IP Source Guard prevents the spoofed IP from communicating in the first place.

To further enhance reliability, consider deploying IP Source Guard in conjunction with endpoint authentication mechanisms such as 802.1X. While IP Source Guard secures the network layer, 802.1X ensures only authenticated devices gain access to the network, adding another layer of identity verification. This hybrid approach is particularly effective in high-security environments where both IP and MAC address integrity are critical And it works..

Finally, continuous monitoring and automation are essential for maintaining dependable IP Source Guard configurations. Network management systems (NMS) should be configured to alert administrators to suspicious activity, such as sudden spikes in drop events or binding table discrepancies. Automated scripts can periodically validate binding tables and verify that source guard is enabled on the correct interfaces, reducing the risk of human error during manual updates.

To wrap this up, IP Source Guard is a cornerstone of modern LAN security, but its success depends on meticulous configuration, integration with complementary features, and proactive management. By adhering to best practices, validating configurations, and leveraging monitoring tools, network administrators can see to it that IP Source Guard effectively mitigates spoofing attacks and safeguards network integrity. As networks grow in complexity, adopting a holistic security posture—where IP Source Guard plays a critical role—will remain critical to defending against evolving threats.