Wireless Access

Hi Guys, 

 

Just had a question in regards to AP discovery when the controllers are deployed in a L2-cluster & L3-cluster. 

 

In the version 8 guide it states the following: "At boot time, the AP builds a list of managed device IP addresses and then tries these addresses in order until it successfully reaches a managed device."

 

I understand the AP does ADP, DHCP, and then DNS resolution in order to discover the controller. 

 

My question is that if two controllers are deployed in a L2 cluster how does the AP recieve the list of IPs for the managed devices. On the DHCP server can you define multiple IPs for option 43? On the DNS server can you define multiple IP's to resolve to aruba-master. I usually do not touch the DHCP or DNS server, the client normally has this configured as per what we tell them. My question here really is around the DHCP/DNS server having multiple entries?

 

My other question is if a client had a L3-cluster:

Area 1 with controller 1 - this AP subnet resolves to both MC's, but it sees the closet one first. Would this work?

Area 2 with controller 2 - this AP subnet resolves to both MC's, but it sees the closet one first. Would this work?

I hope my second question makes sense. 

 

On version 6 installs I usually advised clients to use DHCP and point all AP's to the master and then push the AP's to the local controllers based on the ap-system profile 

 

Thanks, 

In an L2 cluster, you should build a VRRP between all the controllers (MDs) in that cluster, and that is what you should point your access point to via DNS or dhcp option 43 and 60.  When the AP connects to that VRRP successfully, all the ip addresses of the controllers in that cluster are pushed to the access point (nodelist).  The AP is assigned a controller, terminates its traffic on that controller and starts operating.   If it loses connectivity to that controller, it will first attempt to go to its designated standby controller.  If that controller does not respond, it will try the ip addresses in the nodelist one by one.

Everything described above is based on a layer 2 cluster.

 

I would avoid a Layer 3 cluster because it does not provide all the hitless advantages of a cluster.  It is better in the AP system profile to provide a second cluster as a backup-lms-ip that can be used when the primary nodelist would be exhausted.

 

Please see the ArubaOS 8 Fundamentals Guide here:  http://community.arubanetworks.com/t5/Controller-Based-WLANs/ArubaOS-8-Fundamentals-Guide/ta-p/428914 and look at the "Migration to ArubaOS 8" Chapter to understand the parallels between what you are doing now and how things would be done in ArubaOS 8.

 

 

Thank you for your reply once again it has really helped me alot. Doing VRRP between the MC's make sense now for AP discovery.

 

What would happen if you more than 2 controllers in a L2 cluster would you still use VRRP between them? I know potentially you could have 12 controllers in a cluster so would you have one shared IP between all of them and then set that IP for your discovery. 

 

I understand the L3 cluster should be avoided as key features are lost, but we inevitably may have to deploy it for someone in the future even though we will recommend against it. So just to confirm MC's that are deployed in subnets that are L3 connected whats the best way for AP discovery for each of those MC's? Would it be using the DHCP discovery method and set the dhcp option to be different per AP subnet? 

 

What would happen if you more than 2 controllers in a L2 cluster would you still use VRRP between them? I know potentially you could have 12 controllers in a cluster so would you have one shared IP between all of them and then set that IP for your discovery. 

YES

 

So just to confirm MC's that are deployed in subnets that are L3 connected whats the best way for AP discovery for each of those MC's? Would it be using the DHCP discovery method and set the dhcp option to be different per AP subnet? 

Controllers that are part of a cluster should be l2 connected for all of their user and management VLANs.  Controllers that do not share the same l2 VLANs should be in a separate cluster.  Both clusters should have a cluster vrrp.  If you want access points to discover cluster A first, you should point your DHCP option or whatever discovery method to that cluster.  You have the option of putting a backup-lms-ip in those ap-groups to discover cluster B if for some reason all controllers in cluster A fails.  If you want access points to discover and function on cluster B first, you should have the dhcp option of those ap subnets ponit to the VRRP incluster B and have a backup lms pointing to cluster A.

 

Clustering exists for two reasons: (1) redundancy and (2) capacity.  If you have 12 controllers at a site more than one of them would have to fail for you to even consider failing over to another site (very, very rare).  That is the reason why layer 3 clustering is adding a belt to suspenders, which could make things more complicated to manage in the end, with little benefit.

 

There is one more possibility:

 

You can point all of your access points using your discovery method to the VRRP in cluster A.  The ap-group for the access points you want on cluster B can simply have an LMS-ip pointing to the VRRP of cluster B.  That way you would only have to specify a single ip address in your discovery...

Thanks this all make sense now. 

During the initial discovery the AP (new AP) will use one of the following : Static, DHCP , DNS (Aruba-Master) , ADP , etc..

After you provision the AP in a cluster environment the AP will no longer use the other methods instead it will build a list of all the nodes that are part of the cluster and save it in RAM

You can also define another controller or another cluster under the LMS-IP / Backup-LMS-IP if the AP is not able to find any of the controllers in the node list

Sent from Mail for Windows 10

Thanks Victor, this pieace of info is very helpful also.