DHCP Snooping problem

[virtualpedia]

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?

[jasonm002]

you can store the snooping database on a number of different targets:
flash:
ftp:
http:
https:
rcp:
scp:
tftp:

[lynne.meeks]

We have verified that 16.6.4 does fix the DHCP snooping bug.

Lynne

[davisionz]

I can confirm that 16.6.3 DOES suffer from this same bug.  

I have just run across this and the workaround to disable ip dhcp snooping trust on the etherchannel and then re-enabling it restored dhcp functionality. 

[virtualpedia]

Someone posted 16.6.4 fixes the issue but I see 16.6.3 is still the recommended version from cisco.

I'm hesitant to go with 16.6.4.

[davisionz]

It did fix it for us, we had already started migrating to 16.6.4 before we came across this bug; however, 16.6.4 broke ise dot1x authentication for us AND loses non-master stack member interface configs upon upgrade.

[CCBCCPRO]

We have run into this problem with Cat9300 switch stacks running 16.08.01a

Newly connected phones (older Cisco 7600 series phones) will not always pass DAI and they get blocked.  After several migrations, started seeing the switch not updating, or even losing, the dhcp snooping database.  Reloads usually fix the problem, but I'm now seeing where multiple reloads are required to get dhcp snooping to work properly.

Even phones that have valid IP addresses will get blocked by DAI after a reload.  Now I'm actually noticing that the switch stack is deleting port configs on some of the switches after a reload.

Does anyone have experience with Fuji on these switches?  Should we be running Everest instead?  It's getting to the point where it's affecting production and the situation is very unpredictable.

Ticket with Cisco TAC is pending.

[Georg Pauwen]

Hello,

check if the bug below might apply (fix is in 16.11(0.50) and 16.10(1.3)):

DHCP snooping table not updated from DHCP snooping DB file upon reload.
CSCvk34927
Description
Symptom:
On Cat9K, DHCP snooping table is not getting updated from the DHCP snooping database upon reload of the device.

Conditions:
-- DHCP snooping Binding DB configured.

-- When the switch is reloaded and when the NTP is not configured.

Workaround:

Further Problem Description:
This issue is causing feature like DAI to block end clients forcing them to initiate a release/renew to resume connectivity back.

The issue is seen only on reload. No issues on creating binding table entry and writing to DB seen when switch is up.

Issue also not seen on Sup failover.

[CCBCCPRO]

Not really.  Yes and no.

I have seen issues with bindings not updating, and what seems like clients not being able to request a new IP, but for the most part the issue has been prior to a reload.

Upon reload, most of the time this is corrected.  But prior to a reload, like during a migration when moving phones from a previous stack to a new one, the bindings are not created until a reload takes place.  Reloading made sense the first time I ran into this, but the issue I had yesterday was reloading the stack multiple times did not renew/ rebuild the snooping database.

Additionally, I ran into a problem where the port config for one of my switches were deleted.  I know I had phones registered on that switch prior to reload, but after they were not and the reasons was the port configs had been defaulted.  Weird, huhn?

[rgmamaril]

The C9500-40x Stackwise virtual switch (Version 16.9.2) is not working when IP DHCP snooping enabled and we couldn't even log in from the console of Switch1, although it can be see it on the router via CDP neighbor, but we couldn’t ping the IP of interconnection port that connect to router on C9500 from router as well.

[virtualpedia]

Is anyone still running into this DHCP Snooping issues on code 16.6.4?  How about 16.6.5?  I'm planning to upgrade my 9300's to 16.6.5

[steeleryan]

I'm running 16.06.04 and snooping/DAI is a mess and buggy. Also running 16.6.5 on another stack and it seems much improved although I'm having issues with PXE boot on that switch. Trying to figure out why.

[virtualpedia]

Thanks @steeleryan

That is frustrating!

[Frank Osberg]

Hi guys,

Does anybody knows if this is fixed?? I am running 16.6.1 upgrading to 16.9.2 and now 16.9.3 on my 450 x C9300 switches. :)

And from time to time we are facing this issue, but not very often :)

Keep me posted please :)

[Mark Malone]

haven't seen it on Everest 16.6.5 on 93s yet myself seems stable enough

[Frank Osberg]

Great to hear that you are not seeing any issue here on 1.6.6.x version, is anybody running 16.9.x version and can confirm that this is not a issue here :)