ip dhcp conflict resolution Doesn’t Resolve Anything

[Daniel M]

I noticed one of my dhcp pools was exhausted due to a couple of clients doing hundreds of DHCPD-4-DECLINE_CONFLICT.  While I track this down, I do have “ip dhcp conflict resolution” in place, but this issue occurred almost a week ago and none of the conflict addresses were ever resolved (nothing is actually using these IPs and the Detection method was via Gratuitous ARP.)  So, my question is, why were none of these addresses restored to the pool at the conflict resolution interval?

Thanks.

[paul driver]

Hello

I would check your dhcp lease timings as to why the dhcp lease is not re allocating back to the dhcp server, Howerver the concerning part to me is it sounds like you may have/or are being subjected to a DHCP DOS attack.

I suggest to put some L2 prevention security inplace to negate such a threat if it is apllicable to your situation?

The simlpest thing i can think of at this time is DHCP snopping and rate limitation on the acces ports.
 

This has two usages:

1) all ports by default are untrusted so they will only allow client dhcp messages to pass through the port  but stop dhcp server requests ( bogus dhcp servers)

2) dhcp rate limitation on the access port (if set to do so) will disbale that port if the limitation is reached and that put would be disbaled until you manually enable it or have a feature like error recovery( see below) to reenable it after a period or time.

conf t

ip dhcp snooping
ip dhcp snooping vlan xxx

int ran xx -xxx
ip dhcp snooping limit  rate x
 

int xx

ip dhcp snooping trust ( trust this interace from a trusted dhcp server)

errordisable rcovery cause dhcp rate-limit
errordisable rcovery interval 150

res

Paul

[Daniel M]

Hey Paul—appreciate the prompt reply.  The DHCP lease is only a couple of days, but this still doesn’t explain the “ip dhcp conflict resolution” not restoring the IPs back to the pool.  As for a DoS, I think this might be a proxy arp issue, but I’m still investigating.  The only issue with dhcp snooping is the clients are wireless—which means over thirty clients per switch port—so getting the rate limiting right might be tricky and having a port disabled could cause havok.  That said, I might be interested in other ideas or, perhaps, tweaking dhcp snooping so it’s optimized for wireless/a scenario like this (and since the switch is doing DHCP, I’m not certain how to define a dhcp snooping trust here).

Cheers.

[paul driver]

Hello

"couple of clients doing hundreds of DHCPD-4-DECLINE_CONFLICT" - this dosent sound good!

however saying this - the wlan ap is physcailly conected to a switch and the switch port could be set to be untrusted

"since the switch is doing DHCP, I’m not certain how to define a dhcp snooping trust here".

if dhcp server is on just one switch and all hosts are attched to this one switch - - Then if dhcp snooping is enabled then all ports are untrusted by defaut with dhcp snooping,  meaning that you DONT have specify any trusted ports - unless the DHCP need to traverse switch interconnets.

As for "over thirty clients per switch port" rare limiting to 30 or maybe 40 for is a lot less then 100's

Lastly you can either disable gratuious arp or enable DAI inline with dhcp snoping which records the users ip to mac addres sin teh snooping DB and if they dont match then it drops the grat arp request

res

Paul

[RipGeeker]

I found a solution that works for me although I don't understand why.  It just does.

In my setup I'm using a Cisco router 2911 connnected to a Cisco Catalyst 2960X.  I configured another vlan (vlan 30) as my native vlan.  This is a small office.  Initially I only had about 10 PCs connected to the switch.  The router was already connected to the corporate WAN.

As with everyone else on this forum I noticed that several of the PCs weren't assigned an IP address.  I couldn't understand where were the gratuitous ARP assignments coming from.

The only thing I could think of was that it might have something to do with de default VLAN interface: VLAN1.  I had already created a virtual interface VLAN30 and given it an IP address.  So I shut down the VLAN1 virtual interface.  I cleared the DHCP conflict table. No more gratuitous ARPs... no more IP addresses depleted in the DHCP table.

Hope this works for anyone else looking this up.

-Joey

[mario.jost]

We had a similar case where malfunctioning DHCP clients just sent DHCP_decline messages to our DHCP server slowly exhausting the pool. This was done very slowly like 5 IPs per minute. So none of the solutions proposed above could solve this. We implemented the ip dhcp conflict resolution interval 60 command which didnt really do anything. So we opened up a TAC case where we got a detailed description what the command really does:

All conflicts that are detected using ping method are still pingable and can’t be removed from the conflicts table using the resolution command. The “conflict resolution interval” only retries to resolve conflict after the specified interval, it will clear the conflict binding only if it passes the dhcp ping (not pingable). So, it is possible that the conflict at the time of interval still exists, and the last conflict reported time remains unchanged if the conflict persists.

On the other hand, the “clear ip dhcp conflicts *” command will clear all conflicts regardless of the ping state.

For the ones detected using Gratuitous ARP, the “ip dhcp conflict resolution interval” command resolves only the conflicts detected using the ping method not the ones detected using Gratuitous ARP. After doing some research in our resources, we found that there is a limitation related to this command, the DE determined that these GARP-detected conflicts will not be automatically resolved by the server as they are detected on the client-side. The DHCP conflict resolution feature will only clear conflicts detected by ping on the server side.

For these conflicts, you can use the “clear ip dhcp conflicts *” command.

So in the end, we have to create a TCL script (along with an EEM applet) that runs periodically and checks if the IP is still occupied (by probing the arp cache) and clear the entries manually if they are in fact free.