Bug 758746

Summary: The server attempts to provide reserved IP addresses to clients, when the IP is inside the range.
Product: Red Hat Enterprise Linux 5 Reporter: Alexander Chuzhoy <sasha>
Component: dhcpAssignee: Jiri Popelka <jpopelka>
Status: CLOSED NOTABUG QA Contact: Release Test Team <release-test-team>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 5.2CC: vgrinco
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-12-01 14:26:09 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Alexander Chuzhoy 2011-11-30 16:17:05 UTC
Description of problem:
Hello,
I have a dynamic range of 2 C classes. I have reserved a few addresses that are inside the range for specific MACs.
The thing is that the DHCP still tries to supply those reserved IP addresses to other hosts.

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


How reproducible:
Have a range with reserved IP addresses that's nearly full. Disconnect several machines with reserved IP from the network (to pass the ICMP test) and try connecting new clients. 


Steps to Reproduce:
1.Have a range with reserved IP addresses that's nearly full.
2.Disconnect several machines with reserved IP from the network (to pass the ICMP test)
3.try connecting new clients. 
  
Actual results:
The new clients may get reserved IP addresses.

Expected results:
The reserved IP addresses are never suggested for non matching MAC.

Additional info:

Comment 1 Jiri Popelka 2011-12-01 12:43:43 UTC
(In reply to comment #0)
> Steps to Reproduce:
> 1.Have a range with reserved IP addresses that's nearly full.
Just to be sure I understand that right: The 'reserved' adjective means addresses that have already been assigned (there exists a valid lease with this address) to clients ?

> 2.Disconnect several machines with reserved IP from the network (to pass the
> ICMP test)
And here the 'machines with reserved IP' means machines that are specified in some host statement or machines that have valid lease ?

> Actual results:
> The new clients may get reserved IP addresses.
And the same here: 'reserved' means addresses that are specified in some host statement or addresses that have already been assigned (there exists a valid lease with this address) to clients ?


It would be best if you could attach example dhcpd.conf with a short description so I can be sure we talk about the same.

Comment 2 Alexander Chuzhoy 2011-12-01 13:23:01 UTC
(In reply to comment #1)
> (In reply to comment #0)
> > Steps to Reproduce:
> > 1.Have a range with reserved IP addresses that's nearly full.
> Just to be sure I understand that right: The 'reserved' adjective means
> addresses that have already been assigned (there exists a valid lease with this
> address) to clients ?
Yes.
> 
> > 2.Disconnect several machines with reserved IP from the network (to pass the
> > ICMP test)
> And here the 'machines with reserved IP' means machines that are specified in
> some host statement or machines that have valid lease ?
Yes.
> 
> > Actual results:
> > The new clients may get reserved IP addresses.
> And the same here: 'reserved' means addresses that are specified in some host
> statement or addresses that have already been assigned (there exists a valid
> lease with this address) to clients ?
> 
> 
> It would be best if you could attach example dhcpd.conf with a short
> description so I can be sure we talk about the same.

For the moment I'll refrain from posting the dhcpd.conf file for security reasons. Please let me know if you need more details/info.

Here are the relevant entries:

range                          192.168.17.1 192.168.18.254;

host foo {
                hardware ethernet       xx:xx:xx:xx:xx:xx;
                fixed-address           192.168.17.220;
}

The MAC above is unique of course in the dhcpd.conf file.
The IP was already provided to host foo and effectively used by it - I could ssh to foo.

Then, later at some point, a client with another unique MAC received the same IP.

While trying to debug this, I saw the following in the logs:

Nov 30 16:54:23 ns1 dhcpd: DHCPDISCOVER from 00:xx:xx:23:12:32 via eth0
Nov 30 16:54:23 ns1 dhcpd: Abandoning IP address 192.168.17.222: pinged before offer
Nov 30 16:54:26 ns1 dhcpd: DHCPDISCOVER from 00:xx:xx:23:12:32 via eth0
Nov 30 16:54:26 ns1 dhcpd: Abandoning IP address 192.168.18.220: pinged before offer
Nov 30 16:54:31 ns1 dhcpd: DHCPDISCOVER from 00:xx:xx:23:12:32 via eth0
Nov 30 16:54:31 ns1 dhcpd: Abandoning IP address 192.168.17.221: pinged before offer
Nov 30 16:54:39 ns1 dhcpd: DHCPDISCOVER from 00:xx:xx:23:12:32 via eth0
Nov 30 16:54:40 ns1 dhcpd: DHCPOFFER on 192.168.17.220 to 00:xx:xx:23:12:32 via eth0
Nov 30 16:54:40 ns1 dhcpd: DHCPREQUEST for 192.168.17.220 (192.168.16.1) from 00:xx:xx:23:12:32 via eth0
Nov 30 16:54:40 ns1 dhcpd: DHCPACK on 192.168.17.220 to 00:xx:xx:23:12:32 via eth0
Nov 30 16:54:41 ns1 dhcpd: DHCPDISCOVER from xx:xx:d1:22:47:88 via eth0
Nov 30 16:54:41 ns1 dhcpd: DHCPOFFER on 192.168.17.220 to xx:xx:d1:22:47:88 via eth0
Nov 30 16:54:41 ns1 dhcpd: DHCPREQUEST for 192.168.17.220 (192.168.16.1) from xx:xx:d1:22:47:88 via eth0
Nov 30 16:54:41 ns1 dhcpd: DHCPACK on 192.168.17.220 to xx:xx:d1:22:47:88 via eth0


Thanks.

Comment 3 Jiri Popelka 2011-12-01 14:26:09 UTC
That's enough info, thanks.

I'm afraid this behavior is not a bug but designed so.
I haven't found any indication that it should work as you expect.

The reason why you see it (probably) only when the pool of reserved addresses is nearly full is described in  'IP ADDRESS CONFLICT PREVENTION' section of dhcpd.conf
   " If a DHCP client tries to get an IP address, but none are available, but there are abandoned IP addresses, then the DHCP server will attempt to reclaim an abandoned  IP  address. It marks one IP address as free, and then does the same ICMP Echo request check described previously. If there is no answer to the ICMP Echo request, the address is assigned to the client. "

There's also this note in example dhcpd.conf in RHEL-6.
"  Fixed IP addresses can also be specified for hosts. These addresses should not also be listed as being available for dynamic assignment. "

This all leads me to closing this BZ as NOTABUG.
I have no idea how else solve your problem other than excluding the fixed addresses from the pools of dynamically allocated addresses.