[c-nsp] dai / dhcp snooping bug

Mike mike-cisconsplist at tiedyenetworks.com
Mon Aug 10 18:39:40 EDT 2015

On 08/10/2015 12:37 PM, Gert Doering wrote:
> Hi,
> On Mon, Aug 10, 2015 at 06:31:16AM -0700, Mike wrote:
>> 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.
> Wild idea... put an ACL into place that will block the unicast renewal?
> gert

I had that idea too. Another idea was to see if there might be some way 
to work with it... My dhcp model is one where the server is directly 
connected to the vlans being served, but I recently made changes in the 
direction of going to a full-on dhcp relay model instead where all 
switches are doing that instead. The open question then is, does it work 
correctly if the switch is acting as a dhcp relay? I unfortunately don't 
have the equipment on standby to set up a lab and test this out (story 
of my life), but if it worked then my problem would mostly be solved. 
Another idea would be to see if I could configure the dhcp server to 
just ignore unicast requests (easier than putting ACL's on the the 


More information about the cisco-nsp mailing list