AP Association

Unanswered Question
Jan 16th, 2009

Current set up is:

1 - 4402 - 50ap WLAN Controller with code 4.2.130.0

1 - 2125- 25ap WLAN controller with code 5.2.157

35 - AP1010 access points

17 - 1100 series access points

I've told each access point which controller is its primary controller but after rebooting the controllers at the same time 13 of the 1100 series APs go to the 2125 controller & all the others go to the 4402 controller. Any ideas for me to check while I wait to the TAC to call me back?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
jeff.kish Fri, 01/16/2009 - 12:16

Access points do not fail back to their primary controllers by default. You either need to reboot the AP or enable "AP Fallback Mode" on the Controller tab of the GUI. Enabling this mode forces an AP to go to its primary controller the moment it becomes available.

If you don't have this mode enabled, my guess is that the APs are associating to the first controller that comes up until they're both up, at which point they connect to their primaries.

Also, make sure you enter controller NAMES in the primary/secondary/tertiary slots, and not IP addresses.

I hope that helps!

Jeff

gjcluttrell Fri, 01/16/2009 - 12:34

I just looked & AP Fallback is enabled on both controllers & the correct controller name & IP address is in the primary box.

Scott Fella Fri, 01/16/2009 - 17:26

The problem is the code you are running. 4.2.130 and 5.2.157?????? If the ap's did failover, then the ap would have to obtain the code of the controller it failed to. Also I bet your mobility is not up, which is also a requirement for ap fallback to work.

If you told TAC this, they would tell you to run the same code.

Leo Laohoo Sun, 01/18/2009 - 21:11

I know of a bug in the v4.x regarding the primary/secondary/tertiary controller options which forces me to go to the CLI of the v4.0 and enter the following commands manually:

config ap primary-base

config ap secondary-base

config ap tertiary-base

Hope this helps.

gjcluttrell Mon, 01/19/2009 - 16:52

Thanks leolahoo,

I'll try this & see. TAC is also stumped on this one after logging into my controllers & seeing for themselves. They've been working on this for 3 days.... but I don't think they've done this.

Matthew Fowler Mon, 01/19/2009 - 16:56

5.2 runs CAPWAP and an AP with a CAPWAP image will only fall back to LWAPP if it can't discover a CAPWAP controller.

So, the APs on your 2125 will only join the 4400 if they can't reach the 2125.

You're in a tough spot because of the AP1010s....which only support 4.2 and earlier....and the fact that the WLC2125 only supports 5.1 and later.

-Matt

gjcluttrell Mon, 01/19/2009 - 17:45

Yes, the only way I figured out to keep from having c0-channel interfernce with neighboring APs on different controllers is to power down the 2125 & reboot the 4402. Then 50 of the APs (all the 1010 series) will connect to the 4402 & the few others will connect to the 2125 when I bring it back up. I guess I will keep doing this until we can afford to upgrade the 1010 series APs to newer ones & then get the controller code on both controllers on the same page.

wesleyterry Mon, 01/19/2009 - 18:25

Ok, so why not just completely split these two systems. If you don't want the 1100's on the 4402, and the 1010's can't go to your 2125, why not just make these two completely different wireless systems?

Can you just make the two controllers in different networks (and make the related AP's in different networks)...?

OR could you just make sure the controllers are in different mobility groups and then make sure that each AP only has a primary controller defined?

What is your controller Discovery? Is it DNS? DHCP? Broadcast?

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