WLC AP Failover

Unanswered Question

Hello Friends,

We recently installed 2 4402 WLCs. I configured Mobility group and split the APs between 2 WLCs by configuring Primary Controller on each AP. No secondary or tertiary Controller was configured.

Now when WLC1 goes down, the APs on WLC1 register with the WLC2. However, when WLC1 comesback up the APs don't fall back to WLC1. They stay associated with WLC2 until they are rebooted.

is this normal or am i missing anything?

thanks

Anand

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Leo Laohoo Wed, 05/06/2009 - 21:54

Hi Anand,

Configure the Secondary Controller and this should be fine.

gamccall Thu, 05/07/2009 - 04:59

Make sure AP Fallback is turned on. "config network ap-fallback enable", or it's under the Controller:General tab in the GUI.

George Stefanick Thu, 05/07/2009 - 09:45

As gmccall pointed out ...

If you set AP fall back the APs will fall back to their main controller once the controller comes back online. Do keep in mind, this may be a slow process. They dont all jump at once ..

you can find this on your controller @:

Controller (TAB on dashboard) --> AP FALL BACK (drop down ENABLE)

thanks for your replies guys. Actually the AP fall back is enabled. the mobility group is also configured however in the mobility summary the control path shows down and mping and eping fails between the controller. The controller management IPs are in same subnet and no firewall blocking the required ports for mobility.

thanks

Anand

gamccall Fri, 05/08/2009 - 04:32

If you can't find any other problems that might cause this (i.e. routing or ACL issues) you might try deleting and recreating your mobility group.

salterinc Fri, 05/22/2009 - 10:09

We currently have only one WLC on our network. Is it possible to configure the AP's to use default settings when a WLC goes down or is not available? Or do we need a second controller?

George Stefanick Fri, 05/22/2009 - 11:19

I think your question is, "if the controller goes down, can the APs still service clients".

If that is your question, your anwser is no. If your controller does down so will the connecitivy to your APs (unless you use HREAP local switching).

salterinc Sat, 05/23/2009 - 14:20

Thank George, I am using HREAP local switching for all my WLAN's. What exactly is HREAP.

How can I safely test this during normal hours? Disconnect WLC from network?

Thanks Bob

George Stefanick Sun, 05/24/2009 - 10:56

Here is an HREAP design and deployment guide that should get you off and running:

http://www.cisco.com/en/US/products/ps6087/products_tech_note09186a0080736123.shtml

Introduction

Hybrid Remote Edge Access Point (H-REAP) is a wireless solution for branch office and remote office deployments. It enables customers to configure and control access points in a branch or remote office from the corporate office through a wide area network (WAN) link without deploying a controller in each office. The H-REAP access points can switch client data traffic locally and perform client authentication locally when the connection to the controller is lost. When connected to the controller, H-REAPs can also tunnel traffic back to the controller.

How do you plan on using HREAP? Do you have local / remote offices? If you plan to use this on an your internal hospital network you may want to rethink your design, if its large HREAP isn't a wise choice.

Also read the section on security. What are you using for layer 2 security for your wireless clients?

salterinc Sun, 05/24/2009 - 15:51

I will review that document.

Our deployment is very small, 4 units/hallways in our primary facility. The same in our remote offices. We use WPA2+PSK for security. All our facilities are connected via ptp IPSec vpn using Cisco Routers over Verizon FIOS.

You say if it's a large enviroment, HREAP is not a good choice. Why is that?

George Stefanick Sun, 05/24/2009 - 17:24

When I mean large enviroment i mean a large hospital all deployed in HREAP APs. Funny, i had another engineer wanting to design his entire hospital with HREAP.

In my consulting days i designed and deployed 50 remote offices with HREAP in NYC. Works great for remote offices so long as you arent using 802.1x....

I understand there is extra processing used when deploying HREAP (per TAC), this is why they limited the amount of access points in HREAP (in the ealry days 2 - 3 years ago), but since then they have opened it up.

salterinc Sun, 05/24/2009 - 17:30

George, your input is much appreciated. I will mostly likely add more controllers in the future, but for now, this will work considering our size.

One last question, H-REAP was designed for remote offices, but will it work in the central office as well?

Thanks again!

George Stefanick Sun, 05/24/2009 - 20:41

yup, but keep in mind, like the remote offices, if their apps reside central wise what value is there to wireless if you cant get to your apps should the central go down?

Back to the offices i did .... their apps/server farm resided in a local off site. If their central went down their wireless still worked, but their apps were hosed... so they could gain access

to wireless but go nowhere....

salterinc Sun, 05/24/2009 - 20:54

I see your point. All of our facilities use the wireless for three main functions. Medcarts, point-of-care kiosks and resident wireless access.

The app for Medcarts is hosted at an off-site vendor.

The app for Kiosks is hosted on-site locally at either facility.

Wireless access for residents is not a high priority. We provide it free of charge.

I was preparing more for a hardware failure of the WLC, not so much for an Internet failure. Is this a good way of thinking?

Leo Laohoo Sun, 05/24/2009 - 17:11

How can I safely test this during normal hours?

Reboot your WLC while associated. If H-REAP is working during the reboot stage, you should not loose your association and/or authentication.

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