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-
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
