[SOLVED] DHCP Client Obtains Sequential Incremental IP

Suncoast · 09-13-2009, 01:24 PM

On every reboot, the DHCP client is requesting it's previous IP plus one. This location has a Firewall with a 20 user license, and a long memory. So the firewall constantly requires someone to manually reset the "Licenses in use" count.

Other than Static IP, is there a way to configure the Linux DHCP client to request the same address on boot?

Linux 2.6.27.31, Slackware 12.2 current. DHCP server is Cisco Router IOS 12.4.

Thanks

catkin · 09-13-2009, 02:18 PM

I don't know Cisco Router IOS 12.4 but imagine it is a fully featured DHCP server and will support configuring an IP address to be given to a specific MAC address.

ilikejam · 09-13-2009, 02:48 PM

Hi.

The configuration for freezing addresses in DHCP is done at the server side:
http://www.cisco.com/en/US/docs/ios/...html#wp1155880

Dave

Suncoast · 09-13-2009, 08:27 PM

I appreciate the replies. Because there are three subnets, I don't believe you can use manual bindings with multiple network DHCP pools.

This is a mixed XP/Vista/Linux environment. Only the Linux client is getting the incremental IP address. I have not done a packet capture to see if it's actually requesting the IP plus 1 address, but I believe it is.

catkin · 09-14-2009, 02:49 AM

It seems improbable that it is requesting the old IP plus 1.

Maybe the problem is that it is not releasing its IP address. That way, if it makes a DHCP request before the lease on its last IP runs out, the DHCP server cannot issue its previous address because it is "in use" so the DHCP server offers the next available IP. On a lightly loaded DHCP pool that is often the old IP plus 1.

Suncoast · 09-15-2009, 04:57 PM

I've finally figured this out. Turns out Microsoft does not follow the rules. And be careful when buying some Firewall appliances.

From Cisco debug, a Linux workstation shuts down, boots up

Code:

Sep 15 19:51:30.845: DHCPD: DHCPRELEASE message received from client 0100.1320.1a82.1f (192.168.24.87).
Sep 15 19:51:30.845: DHCPD: returned 192.168.24.87 to address pool inside.
Sep 15 19:52:44.033: DHCPD: DHCPDISCOVER received from client 0100.1320.1a82.1f on interface FastEthernet2/15
Sep 15 19:52:46.037: DHCPD: assigned IP address 192.168.24.88 to client 0100.1320.1a82.1f.
Sep 15 19:52:46.037: DHCPD: Sending DHCPOFFER to client 0100.1320.1a82.1f (192.168.24.88).
Sep 15 19:52:46.041: DHCPD: creating ARP entry (192.168.24.88, 0013.201a.821f).
Sep 15 19:52:46.041: DHCPD: unicasting BOOTREPLY to client 0013.201a.821f (192.168.24.88).
Sep 15 19:52:46.061: DHCPD: DHCPREQUEST received from client 0100.1320.1a82.1f.
Sep 15 19:52:46.061: DHCPD: Sending DHCPACK to client 0100.1320.1a82.1f (192.168.24.88).
Sep 15 19:52:46.065: DHCPD: creating ARP entry (192.168.24.88, 0013.201a.821f).
Sep 15 19:52:46.065: DHCPD: unicasting BOOTREPLY to client 0013.201a.821f (192.168.24.88).

Now for a Windows Shut Down, Reboot. (Yes, I changed the clock.)

Code:

Sep 15 15:16:16.692: DHCPD: DHCPREQUEST received from client 0100.0d56.8468.23.
Sep 15 15:16:16.692: DHCPD: Sending DHCPACK to client 0100.0d56.8468.23 (192.168.24.99).
Sep 15 15:16:16.692: DHCPD: creating ARP entry (192.168.24.99, 000d.5684.6823).
Sep 15 15:16:16.696: DHCPD: unicasting BOOTREPLY to client 000d.5684.6823 (192.168.24.99).

Turns out Linux does it exactly by the standards. However Microsoft does not release the IP when it shuts down, and does not broadcast a DHCPDISCOVER packet when it boots up. Instead it sends a DHCPREQUEST using the previously assigned IP. And it turns out Cisco's implementation of DHCP intentionally assigns the IP address that has been available for the longest time, so it gets an incremental IP address.

The take-away from this issue is; When you buy a firewall appliance that has a per seat license, ask the vendor if the firewall tracks the license usage by actual concurrent connections, or by some kind of IP address database that has to be cleared as addresses change.

Thanks everyone

Catkin, you get the thumbs up because you got me thinking in a new direction! Thanks!