This post is a follow up to Ethan’s post and Edward’s post. Both were very useful to me as I began to plan rolling out this feature. I wanted to verify something TimA said in the comments at the bottom of Ethan’s post, namely that a switch running DHCP Snooping will drop DHCP Discovers from clients, not responses from servers. I’ve found that my lab 3750s didn’t exhibit the log messages Ethan mentioned so I tried (and failed) to find an alternative way of proving DHCP was working. Given that the first server to respond to a Discover will win, I would like to be sure my switch is doing what I expect.
I set up the following simple lab.
I spun up a DHCP server on my router (SW-7 as it happens) as follows:
ip dhcp pool DHCP_SNOOP_10 network 192.168.10.0 255.255.255.0 default-router 192.168.10.254 ! int vlan 10 ip address 192.168.10.254 255.255.255.0 !
I then configured DHCP Snooping on SW-6. Note that I disabled the default feature of adding option 82 information to the DHCP requests. I work in an enterprise environment and couldn’t see a benefit to the additional complexity.
ip dhcp snooping vlan 10 no ip dhcp snooping information option ip dhcp snooping int gig 0/7 ip dhcp snooping trust
I then enabled VLAN 10 SVIs on SW-5 and SW-6 thus:
interface Vlan10 ip address dhcp
Obviously VLAN 10 was trunked everywhere.
Let’s have a look at SW-6’s DHCP Snooping settings:
SW-6#show ip dhcp snooping Switch DHCP snooping is enabled DHCP snooping is configured on following VLANs: 10 DHCP snooping is operational on following VLANs: 10 DHCP snooping is configured on the following L3 Interfaces: Insertion of option 82 is disabled circuit-id default format: vlan-mod-port remote-id: 000f.2301.bb00 (MAC) Option 82 on untrusted port is not allowed Verification of hwaddr field is enabled Verification of giaddr field is enabled DHCP snooping trust/rate is configured on the following Interfaces: Interface Trusted Allow option Rate limit (pps) ----------------------- ------- ------------ ---------------- GigabitEthernet1/0/7 yes yes unlimited Custom circuit-ids:
SW-5 and SW-6 picked up their leases as expected:
SW-7#show ip dhcp binding Bindings from all pools not associated with VRF: IP address Client-ID/ Lease expiration Type Hardware address/ User name 192.168.10.20 0063.6973.636f.2d30. May 17 1993 12:27 AM Automatic 3031.632e.6639.6135. 2e37.3663.352d.566c. 3130 192.168.10.21 0063.6973.636f.2d30. May 17 1993 12:27 AM Automatic 3031.632e.6639.6135. 2e36.6634.322d.566c. 3130
And SW-6 was aware of this:
SW-6#show ip dhcp snooping binding MacAddress IpAddress Lease(sec) Type VLAN Interface ------------------ --------------- ---------- ------------- ---- -------------------- 00:1C:F9:A5:76:C5 192.168.10.20 86223 dhcp-snooping 10 GigabitEthernet1/0/4 00:1C:F9:A5:6F:42 192.168.10.21 86226 dhcp-snooping 10 GigabitEthernet1/0/5 Total number of bindings: 2
What I did next was to repeat my config on SW-7 over on SW-5, but I gave its VLAN 10 SVI an address of 192.168.10.104 and set the default-router to the same in the DHCP config. What I found was that SW-5 didn’t seem to see any DHCP Requests at all.
debug ip dhcp server packet
on SW-7 and SW-5 (my two DHCP servers) and then shut / no shut the VLAN 10 SVI on SW-4 to force a DHCP Release / Discover. SW-7 got very chatty, here is an example:
May 16 00:27:52.729: DHCPD: DHCPDISCOVER received from client 0063.6973.636f.2d30.3031.632e.6639.6135.2e37.3663.352d.566c.3130 on interface Vlan10. *May 16 00:27:52.729: DHCPD: using received relay info. *May 16 00:27:54.743: DHCPD: Sending DHCPOFFER to client 0063.6973.636f.2d30.3031.632e.6639.6135.2e37.3663.352d.566c.3130 (192.168.10.20). *May 16 00:27:54.743: DHCPD: no option 125 *May 16 00:27:54.743: DHCPD: broadcasting BOOTREPLY to client 001c.f9a5.76c5. *May 16 00:27:54.751: DHCPD: Reload workspace interface Vlan10 tableid 0. *May 16 00:27:54.751: DHCPD: tableid for 192.168.10.254 on Vlan10 is 0 *May 16 00:27:54.751: DHCPD: client's VPN is . *May 16 00:27:54.751: DHCPD: DHCPREQUEST received from client 0063.6973.636f.2d30.3031.632e.6639.6135.2e37.3663.352d.566c.3130. *May 16 00:27:54.751: DHCPD: Sending DHCPACK to client 0063.6973.636f.2d30.3031.632e.6639.6135.2e37.3663.352d.566c.3130 (192.168.10.20). *May 16 00:27:54.751: DHCPD: no option 125 *May 16 00:27:54.751: DHCPD: broadcasting BOOTREPLY to client 001c.f9a5.76c5. *May 16 00:27:55.347: DHCPD: Reload workspace interface Vlan10 tableid 0. *May 16 00:27:55.347: DHCPD: tableid for 192.168.10.254 on Vlan10 is 0
SW-5 had nothing in the logs at all.
I looked on SW-6 to try and find a way to show that it was doing its DHCP Snooping duties locally but came up with nothing.
SW-6#show ip dhcp snooping ? binding DHCP snooping bindings database DHCP snooping database agent statistics DHCP snooping statistics | Output modifiers SW-6#show ip dhcp snooping database Agent URL : Write delay Timer : 300 seconds Abort Timer : 300 seconds Agent Running : No Delay Timer Expiry : Not Running Abort Timer Expiry : Not Running Last Succeded Time : None Last Failed Time : None Last Failed Reason : No failure recorded. Total Attempts : 0 Startup Failures : 0 Successful Transfers : 0 Failed Transfers : 0 Successful Reads : 0 Failed Reads : 0 Successful Writes : 0 Failed Writes : 0 Media Failures : 0 ! Prior to the VLAN 10 SVI shut / no shut: SW-6#clear ip dhcp snooping statistics ! After it: SW-6#show ip dhcp snooping statistics Packets Forwarded = 7 Packets Dropped = 0 Packets Dropped From untrusted ports = 0
My lab isn’t nearby and I don’t have a Wireshark Server over there so I can’t easily SPAN the ports to prove this. However, I can see empirically that DHCP Snooping causes the switch to silently not forward DHCP Discover Packets to untrusted ports. I can also see that the verification tools on the 3750 are somewhat lacking.