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
switches).
Mike-
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
