cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
997
Views
5
Helpful
8
Replies

WLAN 4400 Controllers Failover

mruhenkamp
Level 1
Level 1

Stephen,

I will be deploying 3 4400 WLAN controllers, 50 licenses each. We will have about 75 total lightweight APs being managed. My questions pertain to load balancing and failover. When a new lightweight AP is booted for the first time, is there a way to control what WLAN controller will "discover" the device. What I am after is each controller managing about 25 APs. In the event of a hardware failure on one of the controllers, how do the 25 APs on the failed controller failover to one of the other two operational controllers?

1 Accepted Solution

Accepted Solutions

Rob Huffman
Hall of Fame
Hall of Fame

Hi Mark,

Just wanted to add a note to Ben's good info. Here a two ways to accomplish the desired pre-defined failover config;

One strategy is to "prime" the access points prior to deploying them in their final locations. Priming the access point is accomplished by deploying the access point in a sand-box environment so that it can easily join a wireless LAN controller. Once joined, the access point will have one or more controller IP addresses stored locally. You can also assign the access point a primary, secondary, and/or tertiary WLC at this time. After the access point has been appropriately joined and provisioned, the access point can be deployed in its final location.

Here is a sample set of steps to follow for priming access points:

--------------------------------------------------------------------------------

Step 1 Place the WLC in a sand-box environment connected to a Cisco switch such as a Catalyst 3750.

Step 2 Provision the WLC with its final configuration, including the Management IP address. Provision the WLC Management Interface's VLAN on the switch so that you can connect the access points to that VLAN. Ideally, you want the access points to be able to discover the WLC via LWAPP IP subnet broadcast.

Step 3 Configure a DHCP server to provide IP addresses to the access points (you can use the Catalyst 3750 to do so).

Step 4 Connect the access points to the switchports and power them up. The access points should find the WLC through the LWAPP IP subnet broadcast.

Step 5 Make any access point specific configurations as desired (for example, assign the access point a primary, secondary, and/or tertiary controller).

Step 6 Once all the access points have been provisioned, deploy the WLC in its final location.

Step 7 Make sure there is IP connectivity between the access point's final location and the WLC in its final location.

Step 8 Deploy the access points in their desired location.

These steps are intended as guidelines rather than rules to illustrate the priming process. There are other approaches that essentially follow similar principles.

There are two other points that should be remembered when you use a priming deployment strategy:

"The access point must learn the IP address of the desired WLC when it is primed. When an access point joins a WLC, it learns the IP addresses of all other WLCs in the joined WLC's mobility group.

"When you configure a primary, secondary, and/or tertiary controller, you enter the sysName of the controllers, not the IP address (see the Advanced Deployment section). A controller embeds its sysName in the LWAPP Discovery Response message. So if you choose to configure a primary, secondary, and/or tertiary controller at priming time, the access point must learn the IP address of these WLCs at priming time. Make sure the primary, secondary, and/or tertiary controllers are in the mobility group of the "priming" WLC.

Another deployment strategy is to use the "Master Controller" option during the deployment phase. The idea is to have access points join a Master Controller as they are deployed and then have the administrator assign them a primary, secondary, and/or tertiary controller.

From this excellent doc;

http://www.cisco.com/en/US/products/ps6366/prod_technical_reference09186a00806cfa96.html#wp1052665

Hope this helps!

Rob

View solution in original post

8 Replies 8

Benjamin Solero
Cisco Employee
Cisco Employee

Hi,

Refer to the following URL for a sample configuration and description of how to set it up:

http://cisco.com/en/US/tech/tk722/tk809/technologies_configuration_example09186a008064a294.shtml

Technically, the APs "discover" the controllers. Typically, DHCP Option 43 or DNS are used for initial discovery. Once registered to a controller that is part of the same mobility group as your other controllers, you can manipulate which controller is 'primary', 'secondary', and 'tertiary' in preference for each AP. I think the URL covers all of this pretty well, but if not, then please feel free to ask for more specifics.

Thanks,

Ben

Rob Huffman
Hall of Fame
Hall of Fame

Hi Mark,

Just wanted to add a note to Ben's good info. Here a two ways to accomplish the desired pre-defined failover config;

One strategy is to "prime" the access points prior to deploying them in their final locations. Priming the access point is accomplished by deploying the access point in a sand-box environment so that it can easily join a wireless LAN controller. Once joined, the access point will have one or more controller IP addresses stored locally. You can also assign the access point a primary, secondary, and/or tertiary WLC at this time. After the access point has been appropriately joined and provisioned, the access point can be deployed in its final location.

Here is a sample set of steps to follow for priming access points:

--------------------------------------------------------------------------------

Step 1 Place the WLC in a sand-box environment connected to a Cisco switch such as a Catalyst 3750.

Step 2 Provision the WLC with its final configuration, including the Management IP address. Provision the WLC Management Interface's VLAN on the switch so that you can connect the access points to that VLAN. Ideally, you want the access points to be able to discover the WLC via LWAPP IP subnet broadcast.

Step 3 Configure a DHCP server to provide IP addresses to the access points (you can use the Catalyst 3750 to do so).

Step 4 Connect the access points to the switchports and power them up. The access points should find the WLC through the LWAPP IP subnet broadcast.

Step 5 Make any access point specific configurations as desired (for example, assign the access point a primary, secondary, and/or tertiary controller).

Step 6 Once all the access points have been provisioned, deploy the WLC in its final location.

Step 7 Make sure there is IP connectivity between the access point's final location and the WLC in its final location.

Step 8 Deploy the access points in their desired location.

These steps are intended as guidelines rather than rules to illustrate the priming process. There are other approaches that essentially follow similar principles.

There are two other points that should be remembered when you use a priming deployment strategy:

"The access point must learn the IP address of the desired WLC when it is primed. When an access point joins a WLC, it learns the IP addresses of all other WLCs in the joined WLC's mobility group.

"When you configure a primary, secondary, and/or tertiary controller, you enter the sysName of the controllers, not the IP address (see the Advanced Deployment section). A controller embeds its sysName in the LWAPP Discovery Response message. So if you choose to configure a primary, secondary, and/or tertiary controller at priming time, the access point must learn the IP address of these WLCs at priming time. Make sure the primary, secondary, and/or tertiary controllers are in the mobility group of the "priming" WLC.

Another deployment strategy is to use the "Master Controller" option during the deployment phase. The idea is to have access points join a Master Controller as they are deployed and then have the administrator assign them a primary, secondary, and/or tertiary controller.

From this excellent doc;

http://www.cisco.com/en/US/products/ps6366/prod_technical_reference09186a00806cfa96.html#wp1052665

Hope this helps!

Rob

Another approach to force LWAPs to connect to a specific WLC is to enable Master Control Mode on one controller at a time. (It is important that only ONE WLC is in this mode at any given time - otherwise the LWAPs may not connect at all).

If you perform a controlled LWAP deployment (starting out with the LWAPs connected and powered by the Ethernet switch, but without setting the correct VLAN for the LWAPs initially) you can see the LWAPs power up and connect to the switch but then continuously reboot as they attempt to find the controller.

Alternatively, you may decide to simply to initially SHUTDOWN the Ethernet switch ports prior to installing the LWAPs. This is less desirable because your installation team won't get feedback from the LWAP's LED light to indicate that it has a good connection to the Ethernet switch.

In either case, when your desired WLC is ready, put it in Master Controller Mode and apply the correct VLAN to the Ethernet Switch ports. You will likely have to apply a SHUTDOWN / NO SHUTDOWN on each port to force the LWAPs to get the correct IP address from the DHCP server (this is a bug that I have observed in the 1131 series - they do not continously reboot as advertised if not connected to the WLC - they need a kick in the pants with a SHUT / NO SHUT to get a new IP address).

You should see all the LWAPs you have enabled now attach to the desired WLC that is in master control mode. You can now configure your access points as desired.

Don't forget to turn Master Control Mode back off.

Now, you can repeat the steps for each of the other two controllers.

I prefer this approach, where possible, because it enables you to skip the priming process which is somewhat labor and time intensive.

However, you may decide to have the added piece of mind of priming the APs. But in certain situations, you may not find it necessary. We just successfully completed an installation of 176 access points using the Master Controller Mode methodology outlined above with no complaints.

Also, a caveat: If your APs are on different VLANs from the WLC (exa: LWAPs other buildings, where routing may be required to get from the LWAP to the WLC, etc.) you may want to implement the very excellent options above.

Hope this helps,

- John

I have followed the example in your post and configured two WLCs to be in the same Mobility Group. I configured half of the access points to use the first WLC as primary and the second WLC as secondary. Then the other have be configured the opposite way. If one WLC is rebooted, all Access Points register with the one WLC. When the rebooted WLC back up, I expected that those Access Points that have primary pointing to the rebooted WLC automatically switch back to it.

This does not happen in our test. The Cisco documentation stated that it should happen if two WLC in the same Mobility group.

When look at the Mobility Statistics in WLC,

Handoff Requests Received 34

Handoff Requests Ignored 34

Any reason why this be ignored??

Thanks.

Wenqian

Check in Controller-->General that a feature called "AP Fallback" is enabled.

This feature is enabled on both controllers.

Now I have different problems. I configured all APs with primary and secondary WLC. However, the load balance seems working between two WLCs, i.e., half APs registered with WLC1 and the other half with WLC2. But the primary and secondary configuration on each AP is totally ignored. Most of APs with primary pointing to WLC1 are actually registering with WLC2. Any idea why primay and secondary WLC setting not working?

Thanks.

I have the same issue, I have a TAC case open. Did you fix this issue?

My problem has not been fixed. Please post here if you get a fix from Cisco. Thanks.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card