Inconsistent behaviour with a valid lease(s) in the leases' DB and no DHCP server up.

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Inconsistent behaviour with a valid lease(s) in the leases' DB and no DHCP server up.

Tomasz Motyl
Hello All,

I ran into some interesting behaviour of the ISC DHCP client v4.4.1. It happens when a host boots up in a network with the DHCP server (temporarily) down and having at least one valid lease recorded.
I had created a bug entry here: For the track record I had created a bug entry here: Inconsistent behaviour with a valid lease(s) in the leases' DB and no DHCP server up. (#162) · Issues · ISC Open Source Projects / dhcp but I shall repeat the information right below.

Client has timeout set-up to  133[s]:

timeout 131;
retry 33;
reboot 9;
select-timeout 3;
initial-interval 2;

interface "eth1" {
  request subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-name-servers, host-name, ntp-servers, vendor-encapsulated-options, dhcp-renewal-time, dhcp-rebinding-time;
  require subnet-mask;
}

The current date and time are: Wed 03 Feb 2021 12:33:20 PM PST
The lease entry is as follows:

lease {
  interface "eth1";
  fixed-address 10.1.1.92;
  option subnet-mask 255.255.255.128;
  option routers 10.1.1.1;
  option dhcp-lease-time 3600;
  option dhcp-message-type 5;
  option domain-name-servers ...;
  option dhcp-server-identifier ...;
  option domain-name "...";
  renew 4 2021/02/04 13:10:16;
  rebind 4 2021/02/04 13:11:16;
  expire 4 2021/02/04 13:13:16;
}
The exchange with a DHCP server (that is down at the very moment) is nothing extraordinary:
- Request
- Discover
- Discover
....
- Discover

(133 seconds passed) and stop. Of course the client starts using formerly assigned IP address of 10.1.1.92 .

When the date changes at midnight so the 4th of February starts, the client starts sending DHCP Discovers again.
First couple questions are: Is this expected behaviour? If not so, why it stopped sending Discovers ?

I was curious and manually modified the lease to expire not the next day but in 30 minutes:

lease {
  interface "eth1";
  fixed-address 10.1.1.92;
  option subnet-mask 255.255.255.128;
  option dhcp-lease-time 3600;
  option routers 10.1.1.1;
  option dhcp-message-type 5;
  option dhcp-server-identifier ....;
  option domain-name-servers ....
  option domain-name "....";
  renew 3 2021/02/03 13:02:23;
  rebind 3 2021/02/03 13:03:23;
  expire 3 2021/02/03 13:05:23;
}
Interestingly the client did not start with DHCP Request as if the lease would already have expired. I thought it might have been the time-zone setting playing role but this was not the case checked the system UTC time and the lease should still be valid.
The client has kept sending Discovers perpetually and accordingly to the configured protocol timings (as one would expect) of course not getting any offer (server still down).

Would the afore described behaviour be an indication of an undocumented feature (bug) ? I read in the documentation that client stopping sending discovers after a timeout would be anticipated in the case of a valid static lease, which is not the case here.

I would hugely appreciate any insight in the described behaviour.

With my best wishes
     Tomasz Motyl

_______________________________________________
ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information.

dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users