difference between DHCPREQUEST sent through rely on rebinding and renewing

[perl-list]

> From: "Simon Hobson" <dhcp1 at thehobsons.co.uk>
> To: "Users of ISC DHCP" <dhcp-users at lists.isc.org>
> Sent: Thursday, December 8, 2016 7:07:48 AM
> Subject: Re: difference between DHCPREQUEST sent through rely on rebinding and
> renewing

> Nick Urbanik <nick.urbanik at optusnet.com.au> wrote:

> > I have been asked what the difference is between the DHCPREQUESTs as
> > seen through a DHCP relay by the server.

> > The reason for the question is that the number of instances of
> > DHCPREQUESTs for clients in the rebinding state are reported to be
> > about five times higher than the DHCPREQUESTs for the clients in the
> > renewing state.

> If you are looking only at requests that have been relayed, then I am not
> surprised. A client renewing any existing lease should not be using the relay
> at all as it should be unicasting the request to the server. If a lot of
> renewal requests are being received via the relay then that indicates that
> there may be a network problem preventing renewal by unicast and so the clients
> are (eventually) falling back to broadcasts which the relay agent can pick up.
This is not necessarily true in an ISP environment. Some types of equipment (Cisco ASR 9k for example) will not send the IP of the DHCP server to the client. The client can only communicate with the Relay Agent (what Cisco is calling a dhcp proxy on the 9k). Other types of ISP equipment I have seen will grab the unicast renews and so forth and relay them anyway thus not allowing direct communication between the client and server. So everything being relayed is certainly possible in an ISP environment and operating as intended. 

> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20161208/b8d3fcef/attachment.html>