DHCP-3-ADDR_NOTIN_POOL message on WLC 4400's

[mike.purdon]

Hi Everyone, We're seeing these messages in the logs of a couple of WLC's configured to be anchor controllers. The two WLC's each have a dhcp scope that is part of the same network. 

WLC1 has a scope of 10.60.48.1-255, a network of 10.60.48.0, a netmask of 255.255.240.0. and a dg of 10.60.63.254

WLC2 has a scope of 10.60.56.1-255, a network  of 10.60.56.0, a netmask of 255.255.240.0. and a dg of 10.60.63.254

The alarm is seen when a user of the guest wireless access service connects having used the service the  day before. The dhcp client is trying to renew an existing DHCP lease rather than request a new lease. When the client connects  they are request a reuse of their current old IP address.

They seem to get an IP address from the DHCP lease pool from both controllers allocated if you analyse the DHCP leases in use on the controllers. Is this normal behavious for the setup using mobility?

If the message DHCP-3-ADDR_NOTIN_POOL is seen in the logs then we see a client connected using their  ' old' ip address in one of the WLCs and there's a lease used on the second WLC controller

This isn't affecting the user login but it does mean a  higher number of DHCP ip addresses are being used than is really needed. Could anyone advise whether this is a known problem?

In the attached screenshot  the 10.60.56.54 client connects to the 'wrong' WLC and a DHCP-3-ADDR_NOTIN_POOL error message is seen. The DHCP request must then be handed to the 'correct' WLC  by mobility and the client  gets allocated the 10.60.56.54 address  but there's also a DHCP lease used in the 'wrong' controller , the DHCP lease list shows 10.60.48.130 used for the same client

best wishes

Mike

[Scott Fella]

The WLC's of course aren't true DHCP servers.... so they don't communicate with each other.  When a device gets an ip address for the first time from WLC1 and then the next day tries to get the same ip address from WLC2... well, since that ip address is not in the DHCP scope, you get that error and since WLC2 does not have that scope range, will issue another ip address.... you might just want to setup your DHCP lease times for around 8 hours.

[mike.purdon]

Hi, thanks for your response. The lease time has been configured to 10 hours.Normal DHCP operarion though is for a client to contact a DHCP server and request the same IP address provided the network address hasn't changed. My assumption is that because the two ranges are part of the same network the client assumes it can reuse it's old address and the controller flags an error message. The confusing thing is that both WLC's then tie up a lease from the pool of IP addresses when only one lease is actually being used. Do you know whether the message can be suppressed or whether a later version of WLC code ( we've using 5.2.157) handles DHCP requests differently? best wishes, and thanks again for your answer , Mike

[Scott Fella]

I do not see any docs that show that new code would do DHCP differently.  That is why setting a short lease time will free up the ip address not being used anymore.  Is this issue with redundant guest anchors or your foreign WLC's?

[mike.purdon]

Thanks for your answer Scott, the problem  seems to be with the two anchor controllers acting as active/active instead of active/standby. Both are being handed DHCP requests over their EoIP tunnels by foreign WLC's on what looks like a round robin scheme. Is there any way to stop this and only use the second anchor if the primary has failed?  A shorter lease time may cure the problem but it would be preferrable to fix the cause rather than the effect. best wishes, Mike

[Scott Fella · Accepted solution]

I have ran into the same issue as you and had a TAC case open because I needed traffic to flow to one anchor controller in one data center and not the the other wlc in another data center.  I was told and as you have seen also, there are no configurations to force the foreign WLC to send guest traffic to one instead of another..... I had this in 4.2 and TAC told me that it might be a feature in the new code, but I have not seen it yet.

[mike.purdon]

Thanks again for your answer Scott.

If you've seen an identical problem and escalted to the TAC then I guess there's nothing we can do other than ignore the messages until a guest wireless solution that supports redundancy is supported.

best wishes and thanks again for your help

Mike