Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 615995 - dhcpd offers multiple ip addresses to the same mac address
dhcpd offers multiple ip addresses to the same mac address
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: dhcp (Show other bugs)
5.7
All Linux
urgent Severity high
: rc
: ---
Assigned To: Jiri Popelka
Release Test Team
: ZStream
: 612952 (view as bug list)
Depends On:
Blocks: 627572
  Show dependency treegraph
 
Reported: 2010-07-19 09:08 EDT by Martin Osvald
Modified: 2011-07-21 05:04 EDT (History)
9 users (show)

See Also:
Fixed In Version: dhcp-3.0.5-24.el5
Doc Type: Bug Fix
Doc Text:
Previously, the dhcpd service sometimes started to give new leases to clients in the INIT state rather than to presently active clients. That led to premature exhaustion of available leases for new clients. With this update, the server's "by client-id" and "by hardware address" hash table lists are sorted according to the preference to re-allocate the lease to returning clients, and the pool starvation problem no longer occurs in the described scenario.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-07-21 05:04:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
the patch which sorts lease queue linked lists (10.01 KB, patch)
2010-07-19 09:08 EDT, Martin Osvald
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1038 normal SHIPPED_LIVE dhcp bug fix and enhancement update 2011-07-20 11:43:54 EDT

  None (edit)
Description Martin Osvald 2010-07-19 09:08:22 EDT
Created attachment 432866 [details]
the patch which sorts lease queue linked lists

Description of problem:

After some time dhcpd starts to offer multiple addresses to the same clients leading to premature exhaustion of available addresses for new clients.


Version-Release number of selected component (if applicable):

dhcp-3.0.5-23.el5


How reproducible:

Don't know how reproducible this is, but when the behaviour starts to happen, it happens every DHCPREQUEST coming from the clients.


Steps to Reproduce:

To be determined.

  
Actual results:

Dhcpd offers a client different ip address everytime the client sends DHCPDISCOVER ('###' means my comments, '...' means snipped unrelated lines):

=== <snip> ===
### See the client with <the_same_MAC>, it has XXX.XXX.113.131 assigned
May 11 13:15:08 server1 dhcpd: DHCPREQUEST for XXX.XXX.113.131 from <the_same_MAC> (Hostname Unsuitable for Printing) via eth0
May 11 13:15:08 server1 dhcpd: DHCPACK on XXX.XXX.113.131 to <the_same_MAC> (Hostname Unsuitable for Printing) via eth0
...
### The client from uknown reason sent DHCPDISCOVER, both servers received this broadcast message
May 11 13:18:12 server1 dhcpd: DHCPDISCOVER from <the_same_MAC> via XXX.XXX.113.250
May 11 13:18:12 server2 dhcpd: DHCPDISCOVER from <the_same_MAC> via XXX.XXX.113.250 
...
### The client from uknown reason sent second DHCPDISCOVER (it is not crucial that it is second DHCPREQUEST in a short time
### as it happens also for one DHCPDISCOVER, but it better demonstrates the problem - see the bellow DHCPOFFER messages)
May 11 13:18:12 server1 dhcpd: DHCPDISCOVER from <the_same_MAC> (Hostname Unsuitable for Printing) via XXX.XXX.113.250
May 11 13:18:12 server2 dhcpd: DHCPDISCOVER from <the_same_MAC> via XXX.XXX.113.250 
...
### we can see two responses from servers, but every time with different ip adress (see the previous XXX.XXX.113.131 was not offered)..
May 11 13:18:13 server1 dhcpd: DHCPOFFER on XXX.XXX.113.169 to <the_same_MAC> (Hostname Unsuitable for Printing) via XXX.XXX.113.250
May 11 13:18:13 server1 dhcpd: DHCPOFFER on XXX.XXX.113.102 to <the_same_MAC> (Hostname Unsuitable for Printing) via XXX.XXX.113.250
May 11 13:18:13 server2 dhcpd: DHCPOFFER on XXX.XXX.113.90 to <the_same_MAC> (Hostname Unsuitable for Printing) via XXX.XXX.113.250 
May 11 13:18:13 server2 dhcpd: DHCPOFFER on XXX.XXX.113.95 to <the_same_MAC> (Hostname Unsuitable for Printing) via XXX.XXX.113.250
May 11 13:18:13 server1 dhcpd: uid lease XXX.XXX.113.105 for client <the_same_MAC> is duplicate on XXX.XXX.113/24
### Now we can see client chose and got completely different addres  XXX.XXX.113.102 instead of XXX.XXX.113.131
May 11 13:18:13 server1 dhcpd: DHCPREQUEST for XXX.XXX.113.102 (XXX.XXX.114.9) from <the_same_MAC> (Hostname Unsuitable for Printing) via XXX.XXX.113.250
May 11 13:18:13 server1 dhcpd: DHCPACK on XXX.XXX.113.102 to <the_same_MAC> (Hostname Unsuitable for Printing) via XXX.XXX.113.250
May 11 13:18:13 server2 dhcpd: uid lease XXX.XXX.113.179 for client <the_same_MAC> is duplicate on XXX.XXX.113/24 
May 11 13:18:13 server2 dhcpd: DHCPREQUEST for XXX.XXX.113.102 (XXX.XXX.114.9) from <the_same_MAC> via XXX.XXX.113.250: lease owned by peer
=== </snip> ===

The lease file contains many entries with the same /mac address/uid/, but different ip:

lease XXX.XXX.113.178 {
  starts 1 2010/05/10 23:31:26;
  ends 1 2010/05/10 23:37:07;
  tstp 3 2010/04/28 18:19:39;
  tsfp 2 2010/05/11 03:31:56;
  atsfp 2 2010/05/11 03:31:56;
  cltt 1 2010/05/10 23:31:26;
  binding state free;
  hardware ethernet <the_same_MAC>;
  uid "\001\000\240\321\227\246\227";
}
--
lease XXX.XXX.113.208 {
...
  hardware ethernet <the_same_MAC>;
  uid "\001\000\240\321\227\246\227";
}
--
lease XXX.XXX.113.131 {
...
  hardware ethernet <the_same_MAC>;
  uid "\001\000\240\321\227\246\227";
}
--
lease XXX.XXX.113.179 {
...
  hardware ethernet <the_same_MAC>;
  uid "\001\000\240\321\227\246\227";
}
--
lease XXX.XXX.113.203 {
...
  hardware ethernet <the_same_MAC>;
  uid "\001\000\240\321\227\246\227";
}
--
lease XXX.XXX.113.90 {
...
  hardware ethernet <the_same_MAC>;
  uid "\001\000\240\321\227\246\227";
}
--
lease XXX.XXX.113.95 {
...
  hardware ethernet <the_same_MAC>;
  uid "\001\000\240\321\227\246\227";
}
--
lease XXX.XXX.113.105 {
...
  hardware ethernet <the_same_MAC>;
  uid "\001\000\240\321\227\246\227";
}
--
lease XXX.XXX.113.118 {
...
  hardware ethernet <the_same_MAC>;
  uid "\001\000\240\321\227\246\227";
}
--
lease XXX.XXX.113.169 {
...
  hardware ethernet <the_same_MAC>;
  uid "\001\000\240\321\227\246\227";
}
--
lease XXX.XXX.113.100 {
...
  hardware ethernet <the_same_MAC>;
  uid "\001\000\240\321\227\246\227";
}
--
lease XXX.XXX.113.102 {
...
  hardware ethernet <the_same_MAC>;
  uid "\001\000\240\321\227\246\227";
}
--
lease XXX.XXX.113.173 {
...
  hardware ethernet <the_same_MAC>;
  uid "\001\000\240\321\227\246\227";
}


Expected results:

The server should offer the client previously offered ip address.


Additional info:

So far, I haven't been able to reproduce the issue, so setting 'Steps to Reproduce' to TBD, but you can use similar setup from BZ #610219 to play with it.

I can understand why the client gets different ip address every time the client sends DHCPDISCOVER as dhcpd internally sets for every uid/hwaddr a linked list of previously leased leases, from which the dhcpd takes the first lease when DHCPDISCOVER request comes in and puts lease there at the end of the list after DHCPOFFER. The list should contain maximally two leases - one lease leased by the primary and one lease leased by the secondary in case of turned off load balancing (e.g. by increasing startup interval in dhcp packet in dhclient sources), but what I don't understand is why there are more than two leases, which in case of unsorted linked list (leases leased for the last time goes at the end of list) leads to offering different addresses. I can see from DHCP release notes that this was fixed (http://www.isc.org/files/release-notes/4.2.1rc1RELNOTES.txt):

=== <snip> ===
			Changes since 3.0.5

- The server's "by client-id" and "by hardware address" hash table lists
  are now sorted according to the preference to re-allocate that lease to
  returning clients.  This should eliminate pool starvation problems
  arising when "INIT" clients were given new leases rather than presently
  active ones.
=== </snip> ===

I have attached a patch regarding the above and it should solve the problem, but surely doesn't solve the root cause. The patch was created by backporting changes from dhcp 3.0.6 to 3.0.5 (you can find old versions here: ftp://ftp.isc.org/isc/dhcp/dhcp-3.0-history/).
Comment 1 Martin Osvald 2010-07-20 01:43:48 EDT
I am sorry, I made a typo, the correct URL to release notes is http://ftp.isc.org/isc/dhcp/dhcp-4.1.1-P1-RELNOTES
Comment 3 Jiri Popelka 2010-07-20 04:06:32 EDT
*** Bug 612952 has been marked as a duplicate of this bug. ***
Comment 20 Tomas Capek 2011-05-31 04:15:10 EDT
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Previously, the dhcpd service sometimes started to give new leases to clients in the INIT state rather than to presently active clients. That led to premature exhaustion of available leases for new clients. With this update, the server's "by client-id" and "by hardware address" hash table lists are sorted according to the preference to re-allocate the lease to returning clients, and the pool starvation problem no longer occurs in the described scenario.
Comment 23 errata-xmlrpc 2011-07-21 05:04:34 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-1038.html

Note You need to log in before you can comment on or make changes to this bug.