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.
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.
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.
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.
On Cat9K, DHCP snooping table is not getting updated from the DHCP snooping database upon reload of the device.
-- DHCP snooping Binding DB configured.
-- When the switch is reloaded and when the NTP is not configured.
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.
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?
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.
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.
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 :)
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 :)