Strange Option82 Anomoly in lease allocation

project722 project722 at gmail.com
Wed Oct 19 14:56:01 UTC 2016


After enabling Option 82 on our Adtran and Calix shelves, along with
enabling the relay agent and log profile on the server to capture the O82
data, all of our test Genexis RG's, after a reboot, came back online with a
30 minute lease. Here is a sample conf line from one of them:

Before reboot:

Option  51 : lease-time 2592000

After Reboot:

Option  51 : lease-time 1800

And, in the lease file on the DHCP server, I see 2 leases written in the
"active" binding state, one for the new 30 minute lease, and another for
the existing lease. The new 30 minute lease record includes the option 82
data:

lease 192.168.10.5 { (30 minute)
  starts 3 2016/10/19 06:46:22;
  ends 3 2016/10/19 07:16:22;
  tstp 5 2016/11/18 07:01:22;
  tsfp 3 2016/10/19 06:43:59;
  cltt 3 2016/10/19 06:46:22;
  binding state active;
  next binding state expired;
  hardware ethernet 00:0r:24:c1:18:d0;
  uid "\001\000\017\224\301\030\320";
  option agent.circuit-id "Option82 data here";

And here is the existing lease:(30 day)

lease 192.168.10.5 {
  starts 5 2016/10/07 05:51:44;
  ends 0 2016/11/06 05:51:44;
  tstp 3 2016/08/24 05:35:15;
  tsfp 1 2016/11/21 05:51:44;
  atsfp 1 2016/11/21 05:51:44;
  binding state active;
  next binding state expired;
  hardware ethernet 00:0r:24:c1:18:d0;
  uid "\001\000\017\224D\022\200";
}

Whats even more interesting, is that once the 30 minute lease expires it
moves into a brand new 30 day lease, which is our default. My understanding
is that the RG should move directly into its new 30 day lease upon coming
back online. (I verified that these did signal a DHCPRELEASE on the
reboot).

We do not have 30 minute lease times declared on the server for any market,
and I find it strange that I see a lease record in the leases file for 2
active leases, one being the 30 minute one, and with the option 82 data
present. This seems to be happening from behind both our Adtran and Calix
shelves.

Does anyone have any thoughts on this?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20161019/e1b04078/attachment.html>


More information about the dhcp-users mailing list