Hide Forgot
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:
(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.
(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.
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.