DHCP Snooping: Offer Dropped "IP address is already assigned" but time left 0

[Felicio Guimaraes Santo]

We have a 8206zl with dhcp snooping enabled and some users cannot obtain DHCP lease, on dhcp-debug packet I got the message:

0089:17:09:40.38 DSNP mUDPFCtrl:DHCP OFFER: port Trk10, vid 5, from
   A45D36-4B6200 from server-id: 10.1.1.44 offered: 10.1.5.37 lease time 259200
   seconds, drop: offered IP address is already assigned.

Those IP on binding database had "time left" equals to 0 (zero). I can't find out what could make the dhcp snooping to do not detect the DHCPRELEASE, but if the time left is zero, the OFFER should not be forwarded insted of dropped ? If not, someone can figure out if could have a network/environment issue/misconfiguration that could cause the DHCPRELEASE don't be detected by 8206zl or it could be just a abrupt poweroff of dhcp client that does not issue the DHCPRELEASE packet (in this case should not the time left deal with this ?) ?

Anyway my environment it's formed by a couple of DHCP servers on Windows Server 2012 R2, virtualized on Windows Server 2012 R2 Hyper-V running in FailOver Cluster. The cluster nodes runs on BL460c Gen8 using converged network on VC FlexFabric with is connected to the 8206zl.

Sorry by many questions in one single post, but I can't find another source for answer it, before open a support case on HP.

TIA,

Felicio Santos.

P.S. This thread has been moved from  HP Networking to ProCurve / ProVision-Based. -HP Forum Moderator

[Vince-Whirlwind]

Do a packet capture on the link(s) between your switch and your server farm and see if the switch is getting two simultaneous offers on two different VLANs.

[Felicio Guimaraes Santo]

Thanks for your reply Vince,

I think that have found the source of issue and it's actually on DHCP Failover feature of Windows 2012, where Microsoft actually had an recently article (reviewed on July 15, 2014) referring issues of this feature with DHCP Snooping: http://support.microsoft.com/kb/2978225

So far I was able to understand/figure out with this feature running on “load balance” mode, there is a delay between one server offer an IP address and the other one get updated about those release as also this could create situations where a different server reply/deal with NAK/RELEASE of an IP address ACK”ed” by other server, creating situations that could trigger DHCP Snooping DROP action.

I had changed the DHCP Failover mode to “stand by” and so far, I did not get additional cases reported by users/help desk team.

Anyway, I still concerned about why even with “time left” “zeroed”, the DHCP Snooping still drop OFFER packages to different client/MAC address…

More information about DHCP Failover feature of Windows 2012:

- Available Modes: http://technet.microsoft.com/en-us/library/dn338976.aspx

- MS DHCP Team Description of Modes (StandBy): http://blogs.technet.com/b/teamdhcp/archive/2012/09/03/dhcp-failover-hot-standby-mode.aspx

- MS DHCP Team Description of Modes (Load Balance): http://blogs.technet.com/b/teamdhcp/archive/2012/08/06/dhcp-failover-load-balancing-mode.aspx

[Felicio Guimaraes Santo]

Unfortunately the issue raised again after the DHCP clients lease start to expire – the scope it’s configured to offer leases with 03 days/72 hours long – as even disabling the Windows 2012 DHCP Failover or reducing the IP Helper to only one server the issue still occurring so we had to disable the DHCP Snooping on switch and being to open a case at HP Support.

[Felicio Guimaraes Santo]

Hello Vince,

As I incorrectly think that had solved the issue, I didn't answered you request looking to save our time.

Now that I found the issue still occuring there is yours answers:

When the Windows 2012 R2 DHCP Failover was running on Load Balance mode, both servers send an DHCPOFFER, but to same  VLAN and from same  VLAN (both servers are behind the vConnect, on same C7000 enclosure, but different blade servers that are member of a single Windows 2012 R2 Hyper-V Failover Cluster.

After the Windows 2012 R2 DHCP Failover mode was changed to StandBy only the primary server send the DHCPOFFER.

But either setting the debug caught the same message where IP address was active to another dhcp client, but with lease time zero, and the lease was already inactive on DHCP server, not even showing on active leases database of server.

Running packet capture simultaneously on servers and client we confirm that the DHCPREQUEST from dhcp client reach the servers, but the servers DHCPOFFER does not reach the dhcp client.

Regards,

Felicio Santos.

[Vince-Whirlwind]

DHCP snooping has given me a few headaches, too.

I'll be interested in hearing the details when you solve it... :)