I have enabled DHCP Snooping on all my new Cat 9300 access switches using the below commands
ip dhcp snooping vlan 100,110,120,130
no ip dhcp snooping information option
ip dhcp snooping
I then trusted the uplink interfaces that connect directly to the core. (ip dhcp snooping trust)
The DHCP server is connected to the core, on vlan 120, and is a MS Windows 2008 R2 server
The Voice VLAN is 110, and all clients plug their computers into the computer port on the back of the phone
Everything worked fine in my testing but today there were a ton of users on various VLANs who could not get IP addresses
To resolve, I turned off snooping for all switches, and everything was fine. I turned it back on for 1 VLAN to try to troubleshoot the issue, but I did not have a problem. It was working as expected.
Can't figure this one out. Any ideas?
Solved! Go to Solution.
Waht version of ios is running on the switches? Are there any error in the logs? Is this happening randomly or does it happen when the lease is being renewed?
are you also using Cat 9300's?
I don't have a solution yet. In my case, ip phones were already up, so they were fine, but once I tried restarting one, it would no longer get an ip address.
We are having the same issue with our 9300s. When the switches are first configured DHCP snooping is configured and seems to work. Then it stops working.
Turning it off and back on doesn't see to fix it.
Has anyone found a solution yet?
So I have been battling both of the DHCP snooping bugs and although v16.9.1 fixed the Ether-Channel issue I am still seeing the other issue that starts up every few days to a week where users are unable to get an address from the DHCP server. I opened a new case and sent them the Show tech but I have also figured out a workaround until they get a new version.
I know it's not ideal using a kron and some of you hate them, but it's what I have for now so I can have my cake and eat it too. If you have a better solution please let me know.
My other option was to disable DHCP snooping completely, and I was not about to do that because we have Software/Hardware engineers here that have to have isolated networks but be able to reach the internet so they use small home NAT routers. When we didn't have snooping enabled, we would have an outage once a week because those smart people can't differentiate the WAN from the LAN ports nor the Labels above the WALL Jacks at their desk that say LAB and CORP.
Anyway, Here is what I did for the Workaround and it seems to work for now. Basically every day at 03:00UTC it runs the command to clear all of the DHCP snooping bindings. You may need to do this more often depending on how active you network is with devices moving around but this works for me. I will definitely remove this once there is a fix for the issue and suggest you do too. You can use whatever name you want I just used "Clear-Snoop".
kron occurrence DAILY-WrMem at 3:00 recurring
kron policy-list Clear-Snoop
cli clear ip dhcp snooping binding *
That's good to know. I tried the latest 16.6 ios on the 3650 platform a few months back and ran into similar issues with dhcp snooping (couldn't find a specific bug for it though).
Cisco TAC told me we are hitting the same bug->
for the fix, they told me the following->
Regarding the final fix to these bug as I mentioned there are two releases that are documented will include the fix, they are:
16.6.4 estimate date to be available is Jun 29th
16.9.1 estimate date to be available is July 18th.
I received same update from Cisco that the bug will be fixed in 16.6.4.
Is there a way to search for bugs by model, instead of by bug ID?
Also, I was wondering where do you all store the dhcp snooping database? I left it at the default, but maybe I should store on flash?