CCNA Automation study materials
CCNA Automation study resources

Guest Wi-Fi Works, Wired Guests Get Bounced

CCNA Automation · Put your knowledge to work in context.

All case studies

Guest Wi-Fi Works, Wired Guests Get Bounced

An access closet has 120 ports. VLAN 50 is the wired guest VLAN (10.50.0.0/24). DHCP snooping is enabled globally and on VLAN 50; the uplink to the core is trusted. Port security is configured on all access ports with maximum 2, violation shutdown, and sticky MAC addresses. Conference rooms use a laptop dock with a built-in USB-C Ethernet adapter; the dock presents its own MAC plus the laptop MAC, and a desk phone is daisy-chained. Guests report that after swapping laptops at the same desk, the port stops forwarding for about 5 minutes and then recovers. show errdisable recovery shows psecure-violation enabled with a 300-second interval. Separately, a guest connects a travel router that hands out 10.50.0.0/24 addresses with gateway 10.50.0.1; clients behind it get local connectivity but cannot reach the internet.

1. Explain the 5-minute outage after a laptop swap and identify the violation mode.

Read the worked answer

The port is err-disabled by port security, and the 5-minute recovery is an err-disable recovery timer. With maximum 2, the dock MAC, laptop MAC, and phone MAC exceed the limit. violation restrict would drop frames and log but not shut the port; the 5-minute pattern indicates violation shutdown plus errdisable recovery cause psecure-violation with a 300-second interval. After a laptop swap, the new MAC is a third/sticky mismatch; the port goes down, then recovers when the timer expires.

Confirm with show port-security interface Gi1/0/x, show errdisable recovery, and show interfaces status err-disabled. Fix by increasing maximum to 3–4 for docked desks, enabling sticky aging, or changing to violation restrict if blocking is acceptable. Clear the old sticky entries with clear port-security sticky interface.

2. Why is the rogue DHCP server not blocked, and what do you change?

Read the worked answer

Snooping should already drop the rogue OFFER/ACK, so verify the trust boundary and VLAN activation. Check show ip dhcp snooping - VLAN 50 must be listed and the access port must show untrusted. If the port is trusted (common when a phone is daisy-chained and the phone port is configured as trusted), the travel router's DHCP server messages pass. Also check that the rogue device is not connected through an uplink or a trunk that is trusted. Fix by keeping only the core uplink trusted, setting no ip dhcp snooping trust on all access ports, and enabling ip dhcp snooping limit rate 10 on user ports. Add ip dhcp snooping verify mac-address and option 82 if the core needs it.

3. Design an ACL to prevent guest-to-guest lateral traffic while allowing DHCP, DNS, and internet access.

Read the worked answer

Apply an inbound ACL on the guest SVI.

ip access-list extended GUEST-IN
 permit udp any eq 67 any eq 68
 permit udp any eq 53 any
 permit tcp any any eq 53
 deny ip any 10.50.0.0 0.0.0.255
 permit ip any any
!
interface Vlan50
 ip access-group GUEST-IN in

Order matters: DHCP and DNS must be permitted before the guest subnet deny, or guests cannot get addresses or resolve names. The deny blocks guest-to-guest lateral traffic at the first routed hop; it does not block internet-bound traffic, which is permitted last. If the guest subnet must reach a local print server, add a specific permit above the deny. Apply the ACL inbound on the SVI, not on the uplink. Same-VLAN switching is not filtered by an SVI ACL, so pair this with private VLAN or port isolation if same-subnet isolation is required.