I'm experimenting a strage issue with some AP1142 that prefer getting new IP from DHCP server rather than using the static ip already configured.
I've got more than a hundred of 1142 APs already conected to a 5508, all with static IP, all working fine for about a year.
As i installed 30 more AP, i enabled a dhcp scope on the controller to give IP to the new APs and when the new aps got registered i changed the configuration to static IP.
The problem comes when some of the older AP than have already static ip are gettig ip from dhcp scope.
If i look at my WCS, it reports that this APS are getting DHCP IP because they cannot reach the controller with their static ip. As this is impossible, because the static ip and the dhcp enable scope are in the same subnet in a layer 2 configuration and with the same gateway. (e.g: old AP 10.10.2.10/16; new AP(dhcp 10.10.3.10-50) 10.10.3.15/16; gw 10.10.254.1)
The problem comes when i disable the dhcp scope, all the older aps that got dchp ip from the wlc scope instead of using their staic configured ip are deregistered. If i reset every ap manually, from the swithc disabling PoE, they start to use the static ip and everything comes fine.
This is happening with about ten of fifteen APs from the 100 installed, that is the strange thing because this seem to be very random as the failing APs are installed in different building and connected to different switches.
As now i have disabled dhcp scope and all APs (old and new) have static ip everything is ok, but i will have to add some more APs shortly and every time i enable the dhcp scope on the wlc this is happening, any suggestions?
Can be a kind of bug?
If the AP loses connectivity to the WLC it will directly try to use the DHCP ip address instead of the statically configured IP address.
I doubt that there is some heartbeat loss and when that happen the AP directly falls back to use the static.
usually there is a number of heartbeat loss (3 for example) before declaring the AP as disassociated. In this case what happens it seems the AP loses one heartbeat (not 3) and directly falls back to use the DHCP instead.
You need to check further to isolate. you can use synched sniffer capture on the AP and WLC to see if there is any heartbeat loss.
Keep an eye on the traplog/msglog. If there is any heartbeat loss it will probably be reported.
Also, if you have a console session with the AP that you reproduce with that will be very helpful as well.
- sniffer capture on AP and WLC.
- AP console output.
- Msglog and traplog while the issue is reproduced.
compare and see if there is any packet loss that happens at almost same time as your AP fall back to the DHCP ip address.
This could probably be a weak feature rather than a bug. But if you confirm the packet loss then you can contact cisco with a solid evidence about the root cause.
We need some more informaiton from your side though:
- What code version you are using?
- Are you using local or HREAP access points?
One more thing:
Make 100% sure that the DHCP scope does not overlap with some static IPs that are being already used by some other APs. If so then the disassociation is pretty normal due to the IP conflict and the AP falls back to the DHCP and get an IP address that does not conflict.
just a thought...
I'm on 22.214.171.124 and the APS are on local mode.
I appreciate your response, but it has no sense for me that if the AP losses a packet (heartbeat) to the controller, it uses the controller DHCP to reconnect, the algoritm should be more stable. And why the controller is reacheable through dhcp IP nor via static IP, this seems to be algoritm misfuntion.
I would like to do all this capturing work but i will not have the time, i think this may be done by cisco engineers.
I was expecting that somebody else had gone thru this, as far this is not a big problem anyway. Thanks.
I agree tha it might be a mis-coded algorithm. This is actually what I tried to explain.
Well, Cisco TAC engineer may ask you for more debugs on the WLC besides what is requested above.
But what you can do is to upgrade to 126.96.36.199 to see if that fixes the issue.
Did you ever find a resolution to your issue. I am currently experiencing the same issue in my mesh environment. I have about 40 AP's that fall back to a dynamic IP, while about 100 of the AP's use the static assignment. There does not seem to be a pattern or reason why some use dynamic IP's while others use the assigned static IP's. I have reset all of the AP's that are using the dynamic, but it does not seem to help.
I have never ran into that issue in any of my installs and I do put static ip address on the access points/mesh. I like the idea that when the AP does no have connectivity back to the WLC, it reverts to shop. The reason being is that if the APs are moved to another vlan, as long as it gets an ip address, the ap is able to join the wlc. I would look at the logs on the switch to see if you see anything that might help explain the reason for the ap to fallback to using a dhcp address. You can also look at the ap join statistics which can inform you of why it has disassociated from the wlc. Make sure there is not another dhcp server that might be issuing addresses also.
Sent from Cisco Technical Support iPhone App
I have just experienced this following a router change at a remote office. Due to the router change, the APs in the office, which had WLC defined static IP's, had lost their connection to the WLC in the Data Centre and so reverted to using a DHCP address as described above.
Now that connectivity has been restored between the AP and the WLC, I have tried to re-apply their static IP configuration, but the AP's seem to be ignoring the 'command' from the WLC and are staying with their DHCP address.
I have a 5508 running version 188.8.131.52
I have had a few this week that fell back to dhcp due to some odd reason, but I just blew in CLI commands to set it back to static with no issues. I also tried a few from the GUI with no issues.
Sent from Cisco Technical Support iPhone App
This work around does not resolve the problem. The work around I have to use is change the switchport from trunk mode to then change the port config to access mode with "switchport access vlan X", where X is appropriate management vlan. Then shut/no shut the port. Then wait for the AP to register with static address. Then change port back to trunk mode.
The labor intensive work around I have to use is change the switch port from trunk mode to access mode with "switchport access vlan X", where X is appropriate management vlan. Then shut/no shut the port. Then wait for the AP to register with static address. Then change port back to trunk mode.