Wireless Access

Is there a method to load balance APs across a series of controllers that exist on the same network (192.168.0.2-5/24 for example) automatically without having to assign AP groups to specific controllers? 

What I'd like is for the AP to boot, and "find" a controller that has an available license on its own (or with the Master pointing it to an available controller). We basically are looking at four 3400 with max licenses but only 192 APs deployed (75% capacity). We're betting that two controllers won't fail at the same time hence the max of 192 APs deployed (actually short of that). Controller .2 is the master.

Thanks

You still have to define the ap-system profile in the AP-GROUP .

You could move APs over to the different controllers using DHCP option 43

I think you are referring to LMS correct (and blms)? That still requires that I manually assign LMS to AP group. I'm hoping for a more dynamic way of establishing the load balancing. Something along the lines of, at boot, the master instructs the AP to go to controller .3 or .4. Could VRRP help in this? If so, I see how to do a two controller VRRP and have done one in a test environment. How would I do a 4 controller VRRP? 

If I have 192 APs and 4 64 licensed controllers, ideally wouldn't I want 48 APs to be assigned to each controller? Then if one failed, 16 APS would redistribute to one controller (excuse me, let me use the proper terminology).... terminate to one controller, another 16 would go to the second controller, and the last 16 to the third one? Or would it be better to set it up such that a master and local represent one VRRP pair and the other two local controllers represent the other pair?

Thanks in advance..

What you are trying to do cannot be done in the method you are describing.  The controller discovered during boot will be the point of configuraiton for the AP; the AP Group (through the AP System profile) will then instruct it where to terminate.    It is possible to setup your enviornment in this redundant setup, however it will require the creation of multiple AP Groups and AP System profiles to support the primary and backup LMS addresses; even though it sounds as though that is what you are trying to avoid.

To do what you want, I think you'd need at least 12 AP Groups.

Group 1 - 16 APs - Primary LMS = Controller 1; Backup LMS = Controller 2

Group 2 - 16 APs - Primary LMS = Controller 1; Backup LMS = Controller 3

Group 3 - 16 APs - Primary LMS = Controller 1; Backup LMS = Controller 4

Group 4 - 16 APs - Primary LMS = Controller 2; Backup LMS = Controller 1

Group 5 - 16 APs - Primary LMS = Controller 2; Backup LMS = Controller 3

Group 6 - 16 APs - Primary LMS = Controller 2; Backup LMS = Controller 4

Group 7 - 16 APs - Primary LMS = Controller 3; Backup LMS = Controller 1

Group 8 - 16 APs - Primary LMS = Controller 3; Backup LMS = Controller 2

Group 9 - 16 APs - Primary LMS = Controller 3; Backup LMS = Controller 4

Group 10- 16 APs - Primary LMS = Controller 4; Backup LMS = Controller 1

Group 11 - 16 APs - Primary LMS = Controller 4; Backup LMS = Controller 2

Group 12 - 16 APs - Primary LMS = Controller 4; Backup LMS = Controller 3

You can create 4 AP-GROUPS since you still need to define under the AP-SYSTEM to what controller the APs will be going to.

And with VRRP you can do the following :

AP-GROUP100 - AP system profile : Virtual IP of VRRP 100

AP-GROUP200

AP-GROUP300

AP-GROUP400

VRRP 100

Controller1 - Master

Controller2 - Backup

VRRP IP address (AP-System profile)

VRRP 200

Controller2 - Master

Controller1 - Backup

VRRP 300

Controller3 - Master

Controller4 - Backup

VRRP 400

Controller4 - Master

Controller3 - Backup

But you have to make sure that you have enough licenses on each controller to support the active APs and the one that will failover 

vfabian,

Your method described is how I was thinking of deploying with 2 VRRP groups. I guess we will have to do the math on our own to determine which AP group should go where to ensure we don't overrun the 32 AP limit per controller (resulting in the dreaded IL flag) so that any one controller can fail and APs reterminate successfully. It would have been nice to have some feature where the controller distributes the APs on its own as we don't really care where they terminate since all of the controllers are in our datacenter on campus. 

Will let you know how it goes...

You mentioned having 4 x 3400 controllers and 192 APs; so that is 64 APs max per controller.   The VRRP design shown will result in 48 APs per controller.  In the event of any one failover, only 16 would move; leaving 32 unlicensed (IL).  To achieve what you want with what you have, you need to create even more VRRP/AP Groups.    The 12 example I provided would do this, whether using VRRP or Primary/Backup LMS.   It is more complicated than you may want, but it will ensure that if there is any one given failure, all APs will be available.

However, please consider that in this type of design, you need to carefully plan your AP Groups and AP placements and consider L3 roaming between controllers, etc.

Yep... As I started doing the math, I noticed that as well... Need to put it down for a moment... Will pick it up afterhours!