Re: dhcp client test case

• Previous message: Ohmster: "Re: Lost connections and reboots with RP PPPoE"
• In reply to: James Knott: "Re: dhcp client test case"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: 3 Apr 2005 09:24:55 -0700

James Knott wrote:
> Jim Berwick wrote:
>
> > With the way DHCP works, the client will begin trying to renew its
lease
> > long before the expiration of
it. I believe up until 87.5% of the lease
> > is expired the client will try to renew the lease from the server
it got
> > it from.
>
> Actually, the lease duration and renewal are controlled by the dhcp
server.
> For example, on my cable modem connection, the lease time is 7 days,
but
> the renewal time is 1 day. I recently saw one network, with a lease
time
> of 4 hours.

More accurate to say "may" be controlled by server ;)

>>From rfc2131:
[q]
4.4.5 Reacquisition and expiration ...

   Times T1 and T2 are configurable by the server through options. T1
   defaults to (0.5 * duration_of_lease). T2 defaults to (0.875 *
   duration_of_lease). Times T1 and T2 SHOULD be chosen with some
   random "fuzz" around a fixed value, to avoid synchronization of
   client reacquisition.

   A client MAY choose to renew or extend its lease prior to T1. The
   server MAY choose to extend the client's lease according to policy
   set by the network administrator. The server SHOULD return T1 and
   T2, and their values SHOULD be adjusted from their original values
to
   take account of the time remaining on the lease.

   In both RENEWING and REBINDING states, if the client receives no
   response to its DHCPREQUEST message, the client SHOULD wait one-half
   of the remaining time until T2 (in RENEWING state) and one-half of
   the remaining lease time (in REBINDING state), down to a minimum of
   60 seconds, before retransmitting the DHCPREQUEST message.

   If the lease expires before the client receives a DHCPACK, the
client
   moves to INIT state, MUST immediately stop any other network
   processing and requests network initialization parameters as if the
   client were uninitialized. If the client then receives a DHCPACK
   allocating that client its previous network address, the client
   SHOULD continue network processing. If the client is given a new
   network address, it MUST NOT continue using the previous network
   address and SHOULD notify the local users of the problem.
[eq]

RENEWING -> unicast request to the original lease server
REBINDING -> broadcast to any lease server available

Defaults are built into the protocol in case there is a boo-boo at the
dchpd server or in case T1 and T2 are not configured explicitly at the
server.

I know. Picky, picky, picky ;)

regards,
prg

• Previous message: Ohmster: "Re: Lost connections and reboots with RP PPPoE"
• In reply to: James Knott: "Re: dhcp client test case"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]