APs jumping controllers

Unanswered Question
Oct 16th, 2008

We have access points spontaneously jumping between 2 controllers. When this happens, the WLAN associations on the radios are lost. Each time an AP jumps to the other controller, the WLAN is re-assigned to the radio and the configuration is saved. This is highly problematic because the WLAN that is lost is our voice WLAN and calls are being droppped. Can anyone explain why this is happening?

We are running software version 5.1.151.0 on the WiSMs and using 1252 (a/b/g/n) access points.

Any help would be greatly appreciated.

Ryan

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Scott Fella Thu, 10/16/2008 - 11:54

Ryan,

An ap will only join another controller if it has lost its communication with the primary wlc. What I would do is disable ap fallback so that your ap's are not bouncing around. this will stabalize your netwrok for now, but you must troubleshoot why the LAP's are loosing connectivity to their primary. Could be an infrastructure issue or a wlc configuration issue... jsut review everything again.

dinger76 Thu, 10/16/2008 - 12:06

Can you advise on things to look for? I don't see anything in the WLC logs or 6509 logs

Scott Fella Thu, 10/16/2008 - 12:17

What have you observed... do you see the ap's trying to get back to the primary or are they actually joining the primary again and then after x amount of minutes, hours, days, the ap's fails to the secondary? Is it all the ap's on a wlc or just some. Let me know more detail, because it can be many things.

Scott Fella Thu, 10/16/2008 - 18:55

What I would also look at at the uptime of the AP... this can tell you if the ap lost power or went through the discovery process. Also note the association time of the ap.

CFayNTAdmin83 Fri, 10/17/2008 - 05:38

I would just like to add my thoughts to this post. I have noticed a few oddities with the AP fallback on my networks. I've determined that if you have WLC's running different code revisions, the AP's will have to download each particular mini ios before it can register. I have been able to stabilize the AP's falling back to their correct controller (eventually) by doing the following.

1. Make sure a Primary controller name is set in the AP config. It must match the system name of the WLC.

2. Try to have each WLC on the same code version. This will prevent the extra code download when they fallback.

3. If you have a WCS Server, do the Configure--> Controllers --> Refresh Config from Controller, and then choose the "delete" option. This will sync the info you programmed into the WLC into the WCS server's database.

Hope this helps!

Craig

dennischolmes Fri, 10/17/2008 - 09:25

What you want to look for are heartbeat timeouts. If you see heartbeat timeout errors then the AP is losing communications with the controller. This happens often when layer 3 lwapp control packets are blocked or not forwarded.

dinger76 Mon, 10/20/2008 - 07:17

The APs get the controller information via DNS when booting up. So far, only a few APs are having this issue and it occurs spontaneously. The only common thread is that all of the APs experiencing this are the new 1252 a/b/g/n APs and are isolated in one closet.

The APs get controller information via DNS on bootup. Sometimes the APs join the controller specified in DNS and other times they join the second controller.

The AP power injectors are plugged into a UPS (with very little load). The WLC and 6509 logs do not show anything indicating a problem.

That's probably not very helpful, but that's all I have at the moment.

dinger76 Mon, 10/20/2008 - 07:18

The biggest problem is that the WLAN associations are being lost. Even if the APs "fall back" to a controller they were previously associated to, wouldn't they maintain the WLAN associations on the radio?

dennischolmes Mon, 10/20/2008 - 07:53

You might call TAC and have them publish 4.2.130.6 for you. It is only available from TAC but has several 1252 fixes in it.

dinger76 Mon, 10/20/2008 - 08:08

That'll be a problem because we're running Spectralink VoIP handsets that require WLC v5 software.

ericwoodin Tue, 12/23/2008 - 12:05

Which version of Spectralink handsets do you have? We've been running controller code 4.2.130 due to Vocera and haven't had an issue with Spectralink.

tdieterich Mon, 01/05/2009 - 13:49

Had kinda a similar problem...Aps would not spontaneously move from controller to controller but some would ignore the primary controller config. and move to another controller (eventually). Although we had controller for specific APs and do not want them to move, I configured all the mobility stuff (RF names) adding controller mac addresses and all the stuff. Once I was done, I restarted both controllers, and the APs found their primary controllers and have not moved since (about 5 weeks now).

dinger76 Tue, 01/06/2009 - 05:22

I did the same thing and now the APs are remaining with their primary controller. The problem that has cropped up has been the APs losing their WLAN assignments. We have a "Voice" WLAN that keeps losing its assignment to the "a" radio on 1252 APs. I think I'm going to need to contact TAC.

Leo Laohoo Tue, 01/13/2009 - 21:30

Do you want to "nail" your AP to associate to WLC1 as the primary and WLC2 as the secondary? If so, then log into the WLC where the problematic AP is currently associated to and do the following CLI commands:

config ap primary-base

config ap secondary-base

Does this help?

dennischolmes Wed, 01/14/2009 - 03:06

They have already tried setting a primary and secondary controller. The issue is that the APs are not associating to the proper controller. The controllers really need to be in the same mobility group and failover must be correctly configured. Which it is in this case. I think its a problem with routing the traffic back the same route each packet.

Actions

This Discussion

 

 

Trending Topics: Other Wireless Mobility

client could not be authenticated
Network Analysis Module (NAM) Products
Cisco 6500 nam
reason 440 driver failure
Cisco password cracker
Cisco Wireless mode