Wireless Access

Hi guys,

I am going to configure a RAP deployment which consists of a pair of MM (AOS 8.5), two MCs within a cluster and many RAPs. I will have two public IP addresses NATed to the MC's IP adresses. I will also enable AP LB, which is disabled by default. For ZTP deployment I will use Activate, and within the IAP-to-RAP rule I will set a FQDN/DNS name as the controller IP address. The DNS name will resolve to one of the cluster public IP addresses in a round-robin manner. At this point comes my doubt, please confirm if my reasoning is correct:

RAPs will receive one of the cluster public IP addresses, associated to MC1 or MC2. This address will serve as the master IP, and this master IP (really MC1 or MC2) will return the cluster node list (MC1, MC2) to the RAP. Then RAPs will begin to distribute between MC1 and MC2 according to the 1% rule (1% of each MC's capacity).

Is that right?

Regards,
Julián

Looks about right if your MCs are not virtual, and don't forget the whitelisting.

Let us just keep in mind that the RAP will have a nailed IPSec tunnel to MC in the cluster, no matter which controller is the AAC.

Hi Julian,

Thats correct.

Besure that the vpnpool is only set on the Mobility Master.

"Mobility Master > Configuration > Services > Clusters > Controller Cluster Rap Pool".

And not at the Managed Device Group.

Also put the rap mac-adressen in the RAP whitelist under the Managed Devices (root) folder.

Assume that you use hardware MC controllers and not virtual VMC controller.

After provisioned from a single AP the AP get the full cluster nodelist pushed into the flash. Also RAP works with a A-AC and S-AC tunnels like a campus AP does.

Some extra information for VMC users:

When using a  VMC its also possible, with the exception of certificate based authentication because VMC have no TMP security chip. To work with VMC you need to provising first as CAP and then re-provision to RAP with the use of a self-signed certificate. VMC RAP configuration cannot be pushed through activate.arubanetworks.com.

Thanks makariosm and Marcel,

Yeah, my MCs are hardware appliances, and of course the RAPs' MAC addresses must be configured in the whitelist.

Then, for a RAP, if the DNS name has resolved to the MC1 public IP address, the MC1 will push the node list to the RAP. If the DNS name has resolved to the MC2 address, the MC2 will push the node list to the RAP as well. No matter which MC the DNS name has resolved to, that MC will push the node list to the RAPs. Is that right?

Regards,

Julián

Correct

And put your public IP in your MD Group Cluster Configuration. But that's what you all-ready figured out.

@Marcel,

Sure, the public IP address and its corresponding MC's address must be configured in the cluster.

@ayman_mukaddam

Yeah, I already read that guide. Only the guide doesn't explain what happens or what are the steps after the DNS name has resolved to one of the public IP addresses, and that's the reason of my question.

From the ACMP official certification study guide:

APs are originally distributed among cluster members based on 1% of each MC’s capacity. The first 1% goes to the active-master/LMS controller, then that master/LMS controller distributes the second 1% to another member, third 1% to yet another member.

Once all APs are connected to the cluster, LB thresholds activate and adjust as needed. The APs are notified of their Active AAC via the node list. The node list sent to each AP depends on the 1% rule.

Let's take a case where there are 200 RAPs. The 1% of 200 is 2. Then, within the node list sent to each RAP I believe the first and second RAP will have MC1 as A-AAC and MC2 as S-AAC,  the third and fourth RAP will have MC2 as A-AAC and MC1 as S-AAC, the fifth and sixth RAP will have MC1 as A-AAC and MC2 as S-AAC, and so on. This node list is sent from MC1 or MC2, depending on which public IP address the DNS name has resolved to for each RAP. Is that correct?

Regards,

Julian

Hi everyone,

Is right the above reasoning about the AP LB 1% rule?

Regards,

Julian

Hi Julian,

I don't think the reasoning is accurate since you are calculating the 1% based on the total AP count and not the controller capacity..

If you want additional details about AP load balancing, you might want to check this link

https://www.slideshare.net/ArubaNetworks/airheads-tech-talks-advanced-clustering-in-aos-8x

---

@ayman_mukaddam wrote:

Hi Julian,

 

I don't think the reasoning is accurate since you are calculating the 1% based on the total AP count and not the controller capacity..

 

If you want additional details about AP load balancing, you might want to check this link

https://www.slideshare.net/ArubaNetworks/airheads-tech-talks-advanced-clustering-in-aos-8x

---

Hi ayman_mukaddam,

Thanks for your help and the link.

Yeah, my reasoning about the 1% rule was incorrect as you said. The ACMP official certification study guide is ambiguous about the AP LB, since it talks about the 1% rule, but also about the Active AP Rebalance Threshold and Active AP Unbalance Threshold triggers, as the link explains.

About this, for AP LB triggers, the Active AP Rebalance Threshold (50% by default) AND Active AP Unbalance Threshold (5% by default) must be met. Taking this into account and considering my case where I have two 7210 and 200 RAPs, for AP LB triggers I would need:

AP Rebalance Threshold = 0.5 = Active AP load % = Active AP load / platform capacity   -->   Active AP load = 0.5 x platform capacity = 0.5 x 512 = 256   -->   Will I need at least 256 active APs in one MC for AP LB takes place? This will never happen since I have 200 RAPs altogether. Does that mean I will have to reduce the AP Rebalance Threshold in order to load balance APs between my MCs?

Regards,

Julián

---

@ayman_mukaddam wrote:

Hi Julian,

 

I don't think the reasoning is accurate since you are calculating the 1% based on the total AP count and not the controller capacity..

 

If you want additional details about AP load balancing, you might want to check this link

https://www.slideshare.net/ArubaNetworks/airheads-tech-talks-advanced-clustering-in-aos-8x

---

Hi ayman_mukaddam,

Thanks for your help and the link.

Yeah, my reasoning about the 1% rule was incorrect. The ACMP official certification study guide is ambiguous about AP LB, I realized it talks about the 1% rule, but also about the Active AP Rebalance Threshold and the Active AP Unbalance Threshold as the link explains. About this I still have a doubt. For AP LB triggers, the Active AP Rebalance Threshold (50% by default) AND the Active AP Unbalance Threshold (5% by default) must be met. In my case where I have two 7210 MCs, that means

Active AP Rebalance Threshold = 0.5 = Active AP load / platform capacity  -->  Active AP load = 0.5 x platform capacity = 0.5 x 512 = 256

Will I need at least 256 active APs terminating in one MCs for AP LB takes place? It will never happen since I have 200 RAPs altogether. Does that mean I will have to reduce the Active AP Rebalance Threshold for load balancing APs between the two MCs?

Regards,

Julián

---

@ayman_mukaddam wrote:

Hi Julian,

 

I don't think the reasoning is accurate since you are calculating the 1% based on the total AP count and not the controller capacity..

 

If you want additional details about AP load balancing, you might want to check this link

https://www.slideshare.net/ArubaNetworks/airheads-tech-talks-advanced-clustering-in-aos-8x

---

Hi ayman_mukaddam,

Thanks for your help and the link.

Yeah, my reasoning about the 1% rule was incorrect. The ACMP official certification study guide is ambiguous about AP LB, I realized it talks about the 1% rule, but also about the Active AP Rebalance Threshold and the Active AP Unbalance Threshold as the link explains. About this I still have a doubt. For AP LB triggers, the Active AP Rebalance Threshold (50% by default) AND the Active AP Unbalance Threshold (5% by default) must be met. In my case where I have two 7210 MCs, that means

Active AP Rebalance Threshold = 0.5 = Active AP load / platform capacity  -->  Active AP load = 0.5 x platform capacity = 0.5 x 512 = 256

Will I need at least 256 active APs terminating in one MCs for AP LB takes place? It will never happen since I have 200 RAPs altogether. Does that mean I will have to reduce the Active AP Rebalance Threshold for load balancing APs between the two MCs?

Regards,

Julián

---

@ayman_mukaddam wrote:

Hi Julian,

 

I don't think the reasoning is accurate since you are calculating the 1% based on the total AP count and not the controller capacity..

 

If you want additional details about AP load balancing, you might want to check this link

https://www.slideshare.net/ArubaNetworks/airheads-tech-talks-advanced-clustering-in-aos-8x

---

Hi ayman_mukaddam,

Thanks for your help and the link.

Yeah, my reasoning about the 1% rule was incorrect. The ACMP official certification study guide is ambiguous about AP LB, I realized it talks about the 1% rule, but also about the Active AP Rebalance Threshold and the Active AP Unbalance Threshold as the link explains. About this I still have a doubt. For AP LB triggers, the Active AP Rebalance Threshold (50% by default) AND the Active AP Unbalance Threshold (5% by default) must be met. In my case where I have two 7210 MCs, that means

Active AP Rebalance Threshold = 0.5 = Active AP load / platform capacity  -->  Active AP load = 0.5 x platform capacity = 0.5 x 512 = 256

Will I need at least 256 active APs terminating in one MCs for AP LB takes place? It will never happen since I have 200 RAPs altogether. Does that mean I will have to reduce the Active AP Rebalance Threshold for load balancing APs between the two MCs?

Regards,

Julián

Hi ayman_mukaddam,

Thanks for your help and the link.

Yeah, my reasoning about the 1% rule was incorrect. The ACMP official certification study guide is ambiguous about AP LB, I realized it talks about the 1% rule, but also about the Active AP Rebalance Threshold and the Active AP Unbalance Threshold as the link explains.

Many thanks and regards,

Julián

Hi Julian,

If you want, check this guide as well https://support.hpe.com/hpesc/public/docDisplay?docId=a00097853en_us

Chapter 6 discusses terminating RAP to a cluster in details..