[c-nsp] dai / dhcp snooping bug

[Mike]

On 08/09/2015 12:49 PM, Frank Bulk wrote:
> A little googling reveals this:
> https://tools.cisco.com/bugsearch/bug/CSCus68252/?referring_site=bugquickvie
> wredir
> https://tools.cisco.com/bugsearch/bug/CSCui65252
> https://tools.cisco.com/bugsearch/bug/CSCug52922
>
> So it's a common problem.
>

I think you have uncommonly good google-foo and I thank you for the 
above. I rolled snake eyes when I was poking around myself, and my 
search terms included DAI and dhcp snooping and such variants.

These links say either a) its fixed in a later version (SE6 or above), 
or b) that it's not fixable because dhcp replies are unicast and 
switched in hardware. Completely in conflict, either it's fixable and 
fixed in software, or it cannot be fixed and therefore the feature 
doesn't work because it cannot work. So, it's either, or both. Lets find 
out which!

I've loaded SE7 and - suprise -  same problem, so it's not fixed. I have 
a directly connected device I can cause to refresh it's dhcp lease, and 
sure enough, a refresh doesn't do it, but a reboot of that device which 
casues a new round of dhcp discovery, does in fact work. A packet 
capture seems to confirm the unicast case failing - a client with an 
existing lease renewing will use unicast to the dhcp server, whereas a 
client starting up will use broadcast to find servers, and both the 
'discover' and 'request' phases in that case are broadcast destination. 
That was painful.

More specfically, the packet dumps on my screen right now seem to 
indicate that dhcp snooping works whent the CLIENT uses broadcast to 
'discover' and then 'request'. This likely is just flagging the hardware 
to let the cpu listen in for a bit to see the reply, so it's likely not 
hardware switching during that time or at least copying to an internal 
ring buffer which the cpu is monitoring. In any case, there needs to be 
some way to allow clients refreshing their lease to work here.

I've just now discovered a cli command - 'ip dhcp snooping binging ....' 
- which allows me to directly inject the needed information. This would 
solve my short term problem and let me get back to a reasonably well 
populated dhcp snooping table, but the question becomes, is this going 
to just be what I do if this issue crops up again or is there any 
configuration work I could do that would make the switch able to 
maintain this table itself?

Thanks again frank.
Mike-