Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We are in the middle of a migration of our DHCP and DNS services from a Debian-based server to a Windows Server 2008 R2 implementation. The Debian server is running isc-dhcpd-V3.1.1. All of workstations are configured to have fixed-addresses between .3 and .40 (the motivation behind that choice is mostly management/political much like here). DHCP leases are given out in the range of .100 to .175. Statically configured servers live in the .200 block and above (which is mostly empty).

When we move to the Windows platform, management/political considerations require me to move the IP ranges around again. We would like to keep .1 - .10 reserved for network appliances, switches, and other infrastructure. .200 will remain designated for servers. The addressing space in between should be available to clients and IPs should be dynamically allocated (Edit: instead of automatic as originally mentioned) by the server.

My Address Pool on the Windows Server looks like this:

192.168.0.1     192.168.0.254     (Address range for distribution)
192.168.0.1     192.168.0.10      (IP addresses excluded from distribution)
192.168.0.200   192.168.0.254     (IP addresses excluded from distribution)

Currently, we have all of our clients still on the .3 - .40 range, and a few machines still active in the .100 - .175 (although there are lots devices that are powered off that still have expired leases with IPs from that range). Since the lease "database" isn't shared between the old and new DHCP server how can I prevent clients from receiving a lease with an IP address that is currently being held by client with a non-expired lease from the old DHCP server? If I just expand the range on the Debian DHCP server to be 192.168.0.10 - 192.168.0.199 is there a way to force clients to not re-use their old IP address when they send their DHCPDISCOVER? Can I make the Windows DHCP server be authoritiative like the ISC implementation?

The dhcpd.conf from the Debian server:

ddns-update-style none;
authoritative;

default-lease-time 43200;   #12 hours
max-lease-time 86400;       #24 hours

subnet 192.168.0.0 netmask 255.255.255.0 {

    option routers 192.168.0.1;
    option subnet-mask 255.255.255.0;
    option broadcast-address 192.168.0.255;

    range 192.168.0.100 192.168.0.175;
}


host workstation-1 {
 hardware ethernet 00:11:22:33:44:55;
 fixed-address 192.168.0.3;
} ... and so on until 192.168.0.40
share|improve this question
    
I would start with reducing lease time to minimum. –  Vick Vega Feb 9 '11 at 22:21

2 Answers 2

up vote 2 down vote accepted

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.

share|improve this answer

Stop the DHCP server and blow away the leases file. It should be in /var/lib/dhcpd/dhcpd.leases. Restart the DHCP server and clients will start taking different addresses.

I don't know about forcing the Windows DHCP server become authoritative (in the Windows tradition, it may just be authoritative), but removing the directive from your dhcpd configuration will be one of the steps in that direction.

share|improve this answer
    
I'm a little leary about killing my dhcpd.leases file; mostly because I don't want my the server handing out new leases with IP addresses that could overlap with existing un-expired leases (with no dhcpd.leases file to check, how would the server know?). I know that could be remedied by doing a ipconfig release/renew on all my clients but I'd rather not do that. –  kce Feb 11 '11 at 18:48
1  
Any proper DHCP server will check that an IP is unused by sending ARP requests before issuing that IP to a client. –  Arrowmaster Feb 11 '11 at 21:07
    
Server 2003 and up provides 'Conflict Detection' for DHCP. You just have to enable it. Basically the DHCP server pings the address before handing it out, if it gets a reply back it hands out the next address... technet.microsoft.com/en-us/library/cc737924(v=ws.10).aspx –  leftcase Jul 8 '13 at 16:34

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.