completely clearing DHCP client leases

[LynK]

Hey All,

Quick question in regards to DHCP server running on a router.

Lets say on a router the DHCP lease times are set to 2 days. So a client recieves a DHCP lease for an address, and he has it held for 2 days. If the client loses power the DHCP server issues it the same address.

Now... if I want to clear all DHCP leases on the clients, what is the best way to do so.

If I issue:

Code Select Expand

clear ip dhcp binding *

The clients still technically have their lease, since it has not expired.

I was doing some research on this and apparently people are saying this resets the clients cached lease too:

Code Select Expand

clear ip dhcp pool <POOL NAME> binding *

What I am looking to do is a way to force clearing the cache on the client, as well as the server. I guess the best way is to reboot all the computers, while rebooting clear all leases on the dhcp server?

any thoughts?

[srg]

You can't really clear the IP lease/cache on the clients from the server. There is an RFC describing how to do a forced RENEW on clients, but it's not really widely implemented: http://www.ietf.org/rfc/rfc3203.txt

[LynK]

Crap.

I guess my only other option is a forced group system restart, coupled with a dhcp bindings reset.

[Seittit]

You can't really clear the IP lease/cache on the clients from the server. There is an RFC describing how to do a forced RENEW on clients, but it's not really widely implemented: http://www.ietf.org/rfc/rfc3203.txt

Correct, a host will hold onto a lease based on its parameters within the DHCP offer. Once the lease is halfway up, the client will try to have it extended by verifying with the DHCP server

• if it passes verification, the lease will renew and the DHCP lease timer resets on the client's machine
• if it fails (DHCP server not responding), the client halves the lease again and tries at the 1/4 time marker. This process continues until it receives a verification from the server or eventually times out

Since the client is the active party in this negotiation, there is no way to force an update from the server's perspective. From a security perspective, you'd never want a DHCP servers to have the capabilities of changing a client's IP assignment. This alone would be a nightmare.

[Otanx]

I am sure it is OS dependent, but what if you shut the switchport to the client, and then no shut it. Does the loss of link cause the client to try and renew the lease?

-Otanx

[Seittit]

I am sure it is OS dependent, but what if you shut the switchport to the client, and then no shut it. Does the loss of link cause the client to try and renew the lease?

-Otanx

unfortunately not. the client holds on a DHCP lease like John Travolta holds on to the 70's.

[javentre]

unfortunately not. the client holds on a DHCP lease like John Travolta holds on to the 70's.

That's certainly not my experience.

Many of my users frequently jump between DHCP'd subnets.  If a link down event didn't cause the client to re-DHCP, then it would be a huge problem when they simply move their cables to a new port.

IME:  A link loss on the client end is sufficient for a re-DHCP, but it can leave a stale lease if it changes subnets.

[sgtcasey]

I am sure it is OS dependent, but what if you shut the switchport to the client, and then no shut it. Does the loss of link cause the client to try and renew the lease?

In my experiences with Windows XP and Windows 7 machines I can move a machine from one VLAN to another by shutting the port, changing the port VLAN, and no shutting the port.  The machine comes up with a new IP and I just clear the old one out of the ARP tables.  I've moved hundreds of devices to new VLAN's this way over the years.

[Seittit]

From the DHCP RFC https://www.ietf.org/rfc/rfc2131.txt:

4. The client may choose to relinquish its lease on a network
      address by sending a DHCPRELEASE message to the server.  The
      client identifies the lease to be released with its
      'client identifier', or 'chaddr' and network address in the
      DHCPRELEASE message.

      Note that in this case, where the client retains its network
      address locally, the client will not normally relinquish its
      lease during a graceful shutdown.  Only in the case where the
      client explicitly needs to relinquish its lease, e.g., the client
      is about to be moved to a different subnet, will the client send
      a DHCPRELEASE message.

From the Microsoft TechNet docs http://technet.microsoft.com/en-us/library/cc958919.aspx

Halfway through the lease period, the DHCP client requests a lease renewal, and the DHCP server extends the lease. If a computer stops using its assigned IP address (for example, if a computer is moved to another network segment or is removed), the lease expires and the address becomes available for reassignment.
The renewal process occurs as follows:
The client sends a request to the DHCP server, asking for a renewal and extension of its current address lease. The client sends a directed request to the DHCP server, with a maximum of three retries at 4, 8, and 16 seconds.

• If the DHCP server can be located, it typically sends a DHCP acknowledgment message to the client. This renews the lease.
  
• If the client is unable to communicate with its original DHCP server, the client waits until 87.5 percent of its lease time elapses. Then the client enters a rebinding state, broadcasting (with a maximum of three retries at 4, 8, and 16 seconds) a DHCPDiscover message to any available DHCP server to update its current IP address lease.

If a server responds with a DHCPOffer message to update the client's current lease, the client renews its lease based on the offering server and continues operation.
If the lease expires and no server has been contacted, the client must immediately discontinue using its leased IP address. The client then proceeds to follow the same process used during its initial startup to obtain a new IP address lease.

This doesn't paint a clear picture on what to expect when changing subnets. It looks as though the RFC is flexible when stating that the client can send a DHCPRELEASE message when detecting a subnet (VLAN) migration, but at the same time the Windows hosts describe no such intelligence in determining this migration. Results may vary, but in my experience hosts hang onto their DHCP lease through reboots, switchport shutdowns, migrations, etc.

[javentre]

Results may vary, but in my experience hosts hang onto their DHCP lease through reboots, switchport shutdowns, migrations, etc.

Please post a sniffer capture of a Windows host rebooting, or dropping link, where it doesn't re-DHCP .

"hang onto their DHCP lease" is a bit ambiguous.  Continuing an existing lease, or getting the same IP that it has been previously assigned (but may be expired) because of a DHCP assignment hash or other DHCP server config, is not the same thing as keeping an IP and not contacting DHCP through one of the above events.

[icecream-guy]

set the lease to 1 minute

lease 0 0 1

wait a few minutes, (maybe that should be wait a day)

reload the dhcp router. if it takes longer than 30 seconds to reboot, all your client DHCP leases should be reset

reset the lease back to it's original value

[Fred]

set the lease to 1 minute

lease 0 0 1

wait a few minutes, (maybe that should be wait a day)

During these few minutes/one day, the clients who have a lease that is valid for 2+ more days will never try to get a new lease.  This won't work.

I'm with the other camp, though, if you can cause a link-down even on the windows machine, it will send a new request.  This won't work fi there is another device such as a hub, switch, or powered phone in-line, as the machine will never lose link.

That said, if it comes back up, it will request the same IP it had before, and if the DHCP server thinks it's available, it will grant it. This might be why some think it "holds the lease", when in fact it's simply renewing it.

[deanwebb]

Best way to clear a DHCP lease? Give it a static IP address. Clear any lease in the DHCP server during that time it has a static IP address, then have it do DHCP again.

[sgtcasey]

This doesn't paint a clear picture on what to expect when changing subnets. It looks as though the RFC is flexible when stating that the client can send a DHCPRELEASE message when detecting a subnet (VLAN) migration, but at the same time the Windows hosts describe no such intelligence in determining this migration. Results may vary, but in my experience hosts hang onto their DHCP lease through reboots, switchport shutdowns, migrations, etc.

This was a concern when we began a huge re-ip addressing push where I work.  For some reason or other someone on the network team years and years ago decided that a non-private IP scheme was the way to go.  So thousands of machines are on these VLAN's.  Luckily we do not yet need to actually route traffic to the Internet to the parts of the world where these non-private subnets are actually being used.  (I should add this was well before I ever got on the team and all those folks are long gone now)

I would wait until a site was closed for the day and get to work.  Hit up a switch, grab the MAC from the switch port, run it through the ARP table for the site distribution router (usually a 4507 but sometimes a 6509) to get the non-private IP, shut the switch port, change the VLAN, no shut the switch port and then check the ARP table for the new IP.  Once the new IP shows up and is pingable I clear the old one from the ARP table and move on to the next switch port.

If I'd find one that didn't pick up a new IP then I'd just set the port back to the original VLAN and move to the next.  I've done hundreds of devices this way over the past year or so.

[LynK]

set the lease to 1 minute

lease 0 0 1

wait a few minutes, (maybe that should be wait a day)

reload the dhcp router. if it takes longer than 30 seconds to reboot, all your client DHCP leases should be reset

reset the lease back to it's original value

I thought the same thing. Unfortunately after looking further into it, this would not work either.