Phones Register but Every PC Behind a Phone Fails DHCP
Riverside branch runs a single Catalyst 9200 (48 ports) with the uplink to the branch router on Gi1/0/1. After a rogue DHCP server incident three months ago, DHCP snooping was enabled on VLAN 10 (data) and VLAN 20 (voice), with Gi1/0/1 configured as trusted. Port security is enabled on every access port with maximum 1, sticky learning, and violation restrict. Each desk has a Cisco 8841 phone with a PC daisy-chained through the phone's PC port; the voice VLAN is configured on the ports and phones register normally via CDP. Last week DHCP for the PCs was moved to a new scope on a server in another building. Since then phones come up and register, but every PC behind a phone fails DHCP and falls back to 169.254.x.x. show port-security interface Gi1/0/12 shows Status Secure-up, 1 sticky MAC, and Security Violation Count 27 and climbing. show ip dhcp snooping binding lists phone MACs only, in VLAN 20. show ip dhcp snooping shows VLAN 10 and 20 enabled with Gi1/0/1 trusted.
1. Two independent faults could produce 'phone gets an address, PC does not'. Name both, and give the show output that distinguishes them.
Read the worked answer
Candidate 1 - port security is throttling the second MAC. maximum 1 allows the phone's MAC and nothing else. When the PC's DHCP DISCOVER arrives, the switch sees a second source MAC on the port and, with violation restrict, drops the offending frames and increments the violation counter. The phone keeps working because its traffic already matches the sticky entry.
Signature: a rapidly increasing Security Violation Count, exactly one sticky MAC per port, port still Secure-up (a shutdown violation would have err-disabled it, which is why it is easy to miss).
Candidate 2 - the DHCP path for VLAN 10 broke when the scope moved. The new server is on another subnet, so the data VLAN SVI needs a working ip helper-address, the return path must exist, and if the snooping switch inserts option 82, a new server or relay may drop the request. There is also a plain configuration angle: the new scope may simply not be authorised for relay on the router.
Signature: the violation counter is static, and show ip dhcp snooping statistics shows drops, or debug ip dhcp server events / show ip helper-address shows no request ever leaving the SVI for VLAN 10.
Telling them apart: the violation counter. Twenty-seven and climbing while the counter on a quiet port stays flat is candidate 1. Note the two are not mutually exclusive - fix port security, then re-test before assuming the relay is clean.
2. Write the interface configuration that fixes the failure while preserving the protection added after the rogue DHCP incident. Explain each line.
Read the worked answer
On every user-facing port:
interface range GigabitEthernet1/0/2 - 48
switchport port-security maximum 3
switchport port-security mac-address sticky
switchport port-security violation restrict
ip dhcp snooping limit rate 10
no ip dhcp snooping trust
Why each line
maximum 3- one slot for the phone, one for the PC, one spare for a replacement handset, a dock, or a technician's laptop. Three is the practical minimum for a phone-plus-PC design; two leaves no headroom and produces the same ticket the next time hardware is swapped.sticky- keeps the learned MACs pinned so a rogue device cannot simply take the port over later. Existing sticky entries remain valid; raising the maximum is enough, no need to clear them.violation restrict- deliberately chosen overshutdown. A violation on a voice port must not drop an emergency call; restrict drops only the offending frames and logs it.ip dhcp snooping limit rate 10- the actual anti-rogue-DHCP control at the edge. It caps DHCP messages per second per port so a flood from a misbehaving device cannot exhaust the snooping database.no ip dhcp snooping trust- keeps access ports untrusted so server offers arriving from a user port are discarded. Only Gi1/0/1 (the router) stays trusted.
Do not disable snooping to make the PCs work - that reopens the original incident.
3. How do you confirm PCs are now getting addresses and that rogue-DHCP protection still works? Give specific commands and one active test.
Read the worked answer
Passive verification
show ip dhcp snooping bindingshould now show two entries per active port: the phone MAC in VLAN 20 and the PC MAC in VLAN 10.show port-security interface Gi1/0/12should show two sticky MACs, Status Secure-up, and a violation count that has stopped climbing. Freeze the timestamp and compare again in 10 minutes - a flat counter is the proof, a static snapshot is not.show ip dhcp snooping statisticsshould show no unexpected drops from user ports during business hours.- Spot-check a handful of PCs with
ipconfig /all: correct subnet, correct gateway, lease from the new scope, and no 169.254 address retained afteripconfig /releaseand/renew.
Active test (do this, don't assume)
Take a spare small router with DHCP enabled, configure a scope that would obviously win a race (for example 192.168.x.0/24 with a short lease), and plug it into an unused access port in VLAN 10. Expected: the switch discards the OFFERs because the port is untrusted, and show ip dhcp snooping statistics records the drops. Unplug it afterwards.
Document the residual risk: with restrict, a determined insider can keep hammering a port and generate log noise. Pair this with syslog alerting on violation counts and on DHCP_SNOOPING drop messages so the next occurrence is noticed the same day, not three weeks later.