Centos – fixed-address is not behaving properly with DHCP version 4.2.5

centosisc-dhcp

If I configure an IP address range in dhcp, and allocate two addresses to two different MACs using fixed-address, and if those two or one of the systems is not active in the network, then the corresponding IP address is getting assigned to some other system which is not mentioned in any host declaration.

I have configured dhcp server 4.2.5 on CentOS 7.1 and configured dhcpd.conf as given below:

log-facility local7;
ping-checks;
ping-timeout 5;
deny declines;
lease-file-name "/etc/dhcp/dhcpd.leases";
infinite-is-reserved on;

#######################- eth0 -#######################
subnet 192.168.72.0 netmask 255.255.255.0 {
        range 192.168.72.56 192.168.72.100;
        option domain-name-servers 192.168.72.35;
        option routers 192.168.72.35;
        default-lease-time 86400;
        max-lease-time 172800;
}
host abc {
        hardware ethernet 00:90:fb:38:15:ae;
        fixed-address 192.168.72.56;
}
host xyz {
        hardware ethernet 11:22:88:55:66:22;
        fixed-address 192.168.72.57;
}

Now if the system with MAC address "11:22:88:55:66:22" is not active in the network, then IP address "192.168.72.57" can be assigned to any other machine.

But if the system with MAC address "11:22:88:55:66:22" is active then it's working properly.

Please tell me whether it is expected behaviour or not. In the previous version of dhcp 4.1 I never observed this behaviour.

I thought a reserved IP address should not get assigned to any other system.

Best Answer

Adding an entry in dhcpd.leases solved my problem.

I added the following entry in the /etc/dhcp/dhcpd.leases file:

lease 192.168.72.56 {
  binding state active;
  reserved;
  hardware ethernet 00:90:fb:38:15:ae;
}

Related Solutions

ISC DHCP – How to Force Clients to Get a New IP Address

This is probably not the best way to solve this problem but it worked. Here's what I did.

1) I added the following restriction to my Debian-based DHCP server and removed all of the fixed-address entries. This forces any clients in those IP ranges to move somewhere into the .41 - .199 range, otherwise when I turn on the Windows Server clients will receive leases with IPs in the .11 - .40 range that are already present on the network. I then let things sit long enough for any leases in that IP range to expire and have a new one issued.

subnet 192.168.61.0 netmask 255.255.255.0 {

        option routers 192.168.61.1;
        option subnet-mask 255.255.255.0;
        option broadcast-address 192.168.61.255;

        pool {
                range 192.168.61.0 192.168.61.40;
                deny all clients;
        }
        pool {
                range 192.168.61.41 192.168.61.199;

        }
}

I could not figure out a way to make the Windows Server DHCP implementation act as "authoritative"; the behavior I wanted is when clients with leases from the old Debian-based DHCP server sent their DHCPINFORM packets to the new Windows Server, I wanted those clients to receive a DHCPNAK and the go through the whole process again to get a lease, thus "re-populating" the addressing space from .11 and up.... regardless, continuing on.

2) I cheated by expanding the Exclusion range on the new Windows DHCP server to include 192.168.61.100 - 192.168.61.199. This will force any clients who were assigned an IP in that range by the Debian-based DHCP serve to have their DHCPINFORM denied and then issued a new lease at the "bottom" of the addressing space (.11 and greater).

3) At this point I simply turned the Debian DHCP server off, and the Windows Server on and let the expiry time sort things out. Because of the "deny all clients" line in my dhcpd.conf, there were no clients with "old leases" in the .11 - .40 addressing space that could cause an IP conflict, and because of the Exclusion of .100 - .199 ranges all DHCPINFORM requests were denied (at least I imagine that's what happened... I didn't bother looking at the transaction using a packet sniffer... I probably should of) and the addressing space was re-populated starting from the lower bound of .11.

DHCP – Resolving Double Lease Issues with Fixed and Dynamic IPs in ISC DHCP

The configuration checker would just match your defined pools and host address definitions against each other to find definition intersections, it would not evaluate access lists.

So you would have to explicitly exclude your host definitions range from the "deny all" pool definition:

pool {
    # IP range which will be assigned statically
    range 192.168.11.1 192.168.11.10
    range 192.168.1.12 192.168.11.240;
    deny all clients;
}

Related Topic