Wireless Access

I am trying to figure out the best controller design for our environment, and also add in another controller. I have been reading the reverence design and looking at our current configurations, but getting more confused as to the best route and how we are currently set up. I believe we have some inconsistencies that I will need to straighten out as I go forward.

We currently have two 3600 controllers in a master/local configuration. Each controller is licensed for 128 WAPs. I have a third 3600 that I need to put into service to add redundancy that is licensed for 64 WAPs. Our sites are grouped with AP groups. The master supports 3 sites (site 1 has 57 WAPs, site 2 has 22 WAPs, site 3 has 1 WAP = 80 total) and the local supports 2 sites (site 4 has 21 WAPs and site 5 has 34 WAPs = 55 total) too many to just swap between the two in a failure. My thought for the best setup so far is to put the new 3600 into service as the master with no WAPs, demote the current master to a local. The reference designs seem to push for a master with no WAPs. In the event of a failure I would group the AP groups of each local to use the master as one backup and the other local as the other. For instance I would build the AP group for site 4 to use local 1 as the primary and local 2 as secondary (via VRRP) and site 5 would use local 1 as the primary and the new master as the secondary. I would do something similar for the other sites. This way if the master goes down, no one would be affected, if a local went down then about half would be for a short time.

The other option would be to just add the 64 licensed controller as a new local and move some AP groups to it, and leave things as is. Is there another option that would be best?

I also think we have some inconsistencies with LMS and VRRP. We have two VRRP instances, 1 and 2:

(ArubaSlave) #show vrrp

Virtual Router 1:

    Description Secondary

    Admin State UP, VR State MASTER

    IP Address 172.25.64.210, MAC Address 00:00:5e:00:01:01, vlan 1

    Priority 150, Advertisement 1 sec, Preemption Enable Delay 0

    Auth type NONE ********

    tracking is not enabled

Virtual Router 2:

    Description VIP 220 Primary

    Admin State UP, VR State BACKUP

    IP Address 172.25.64.220, MAC Address 00:00:5e:00:01:02, vlan 1

    Priority 100, Advertisement 1 sec, Preemption Enable Delay 0

    Auth type NONE ********

    tracking is not enabled

But I also see that we have an AP system profile that specifies an LMS ip for the VRRP instance that the master is primary for and the other for the VRRP that the local is primary for. There is no backup-LMS specified.

ap system-profile "VIP 210"

   lms-ip 172.25.64.210

!

ap system-profile "VIP 220 Primary"

   lms-ip 172.25.64.220

Is this the correct way of setting up VRRP and balancing the WAPs between controllers? I see in the reference designs the concepts but these low level commands I am having trouble finding examples for.

Last question, in a master-standby configuration, the standby cannot have any WAP’s, correct?

Based on the data provided, following is the current scenario: 

Master (80) AP License: 128
Local (55) AP License: 128
3600 (?) AP License: 64

Total APs: 135

 

 

 

Deployment recommendation: 

 

Master - No APs 

Local1 - 75 APs (total 128 licenses available)

Local2 - 60 APs (total 64 licenses available) 

 

 VRRP1 running between Local1 and Master with Local1 being the master of VRRP IP1

VRRP2 running between Local1 and Local2 with Local2 being the master of VRRP IP2

 

AP group 

 

Local1: 

AP system profile local1

lms-ip VRRP1 IP 

bkup-lms-ipNo need for bkup-lms-ip

Local2:

AP system profile local2

lms-ip VRRP2 IP 

bkup-lms-ipMaster controller IP 

 

The above configuration will make sure that you get redundancy when the local controllers go down. 

 

 Last question, in a master-standby configuration, the standby cannot have any WAP’s, correct?

[HT]Yes. You cannot have any APs terminate on the standby controller

 

 

Hope that answers your questions. 

 

Regards, 

--

HT

Thank you for that recommendation. That actually helped my understanding quite a bit, and is prompting me to ask a couple of follow up questions…

VRRP 1 establishes redundancy between Local1 and the Master. If Local1 is the primary and it goes down then the Master becomes the primary. What is the need of entering the LMS IP?

VRRP 2 is between Local1 and Local2, Local2 being primary. Local2 fails and Local1 is primary. (Same LMS IP question as above here too). Local1 is not able to support all of those AP’s, so is that what the Backup LMS IP is for? Once Local1 is full then the unlucky AP’s that didn’t find room will use the Backup LMS IP of the Master to move to the Master?

If both Local Controllers go down then it first come first served on the Master until there are 128 AP’s.

VRRP is used to create a single virtual IP address for redundancy purposes. 

LMS IP is used to direct the AP to the controller where it should terminate.

We set it to the virtual IP of VRRP instance as the LMS IP. Without setting the LMS IP, the AP will continue to stay on the master controller. 

Local 1 will be able to support all the APs since it has 128 license count. 

In case both Local1 and Local2 go down then all APs will move to master controller and 7 APs will stay INACTIVE since the controller will be able to support only 128 /135 APs. 

I hope that answers your questions. 

Regards,

--

HT 

Sorry to keep hammering this, but I guess I am not getting it.

Master - No APs

Local1 - 75 APs (total 128 licenses available)

Local2 - 60 APs (total 64 licenses available)

If Local2 fails, Local1 will not be able to take all 135 AP’s because of the 128 AP limit on Local1. OR does the backup-LMS command force all of them (or only those past the 128 limit) to move to the Master regardless of the VRRP IP still being up? If that is the case wouldn’t it be better to make VRRP 2 run between the Master and Local2 and not use backup-LMS?

I have read that VRRP is preferred over LMS because of speed.

I appreciate your willingness to help me on this.

The LMS IP settings don't know if about AP license limits.  If local2 fails, all 135 APs will be talking to local1 and only the first 128 will work.  The other 7 will sit on the controller under "IL" status (inactive, unlicensed). 

Its not best practice to terminate AP tunnels on the master, but in a small network, it will work.  You can run VRRP between master and local1 AND master and local2.  That way, if either local fails, the master will take over the VIP and the APs will continue to work.

11davie,

Both hthakker and olino have given good possiblities of layouts.  I have enjoyed reading their posts.

It can get a little confusing so if I summarize it may may help you and me to better understand (hthakker/olino please correct any mistakes).

hthakker solution:

provides redunancy in case local1 fails. local1 APs will be handled on the master (via VRRP).  local2 APs still function as normal.

provides redundancy in case local2 fails. all APs will be handled on local1, 7 APs will be INACTIVE (licenses limits) 

provides redundancy in rare case of both local1 and local2 fail.  Master handles all AP, 7 APs will be INACTIVE (license limits)

olino solution:

provides redundancy in case local1 fails.  local1 APs will be handled on the master (via VRRP).  local2 APs still function as normal.

provides redundancy in case local2 fails. local2 APs will be handled on the master (via VRRP).  local1 APs still function as normal.  No APs Inactive.

does NOT provide redundancy in case of both local1 and local2 failing at same time.

Both are good solutions.  Choose one depending on your need.

Please correct any missunderstanding I may have.

thanks

Thanks for that summary, and for everyone's input. It has been very helpful!

I would just like to add that I think olino's solution would still provide redundency if both Local1 and Local2 fail for all but 7 AP's since VRRP would rehome them to the Master. This is the design that I think I will use. Although not best practice to have AP's on the Master, this will only happen during an issue.

Thanks!