Wireless Access

Hi experts,

 

I have a master-local topology with ArubaOS 6.5 and want to migrate to ArubaOS 8.x, but I don't know about ArubaOS 8.x. Let's say I have a topology like this, with master and master-standby and three locals:

Also the master is the backup LMS if a local controller fails. When I migrate to ArubaOS 8.x, the Aruba Solution Exchange tool gives me the recommended topology with Mobility Master, which is like this:

The tool also gives the following design details:

But I am confused with the re-marked lines. My locals are geographically separated from the master, but the locals are also geographically separated. So, when I migrate to ArubaOS 8.x, what is the role of my current master controllers? Do they operate as usual controllers (MCs) all in the same cluster (MC1-MC5)? The last line says that, but also says all the locals were part of a large campus, but it is not my case, since my locals are also geographically separated.

 

Regards,

Julián

I suggest you take a look at the AOS 8 fundamentals guide
https://community.arubanetworks.com/t5/Controller-Based-WLANs/ArubaOS-8-Fundamentals-Guide/ta-p/428914

It should answer all your questions



Thank you

Victor Fabian

Pardon typos sent from Mobile

---

@fjulianom wrote:

Hi experts,

 

I have a master-local topology with ArubaOS 6.5 and want to migrate to ArubaOS 8.x, but I don't know about ArubaOS 8.x. Let's say I have a topology like this, with master and master-standby and three locals:

Also the master is the backup LMS if a local controller fails. When I migrate to ArubaOS 8.x, the Aruba Solution Exchange tool gives me the recommended topology with Mobility Master, which is like this:

The tool also gives the following design details:

But I am confused with the re-marked lines. My locals are geographically separated from the master, but the locals are also geographically separated. So, when I migrate to ArubaOS 8.x, what is the role of my current master controllers? Do they operate as usual controllers (MCs) all in the same cluster (MC1-MC5)? The last line says that, but also says all the locals were part of a large campus, but it is not my case, since my locals are also geographically separated.

 

Regards,

Julián

---

Julian,

 

In your specific case, what ASE recommended was the addition of two redundant Mobility Masters to be deployed where your Master controllers are today. This frees up your Master controllers to be redeployed as Managed Devices under the Mobility Master (M1 and M2 become MC4 and MC5), similar to the Local controllers which will also be Managed Devices under the Mobility Master (L1, L2, and L3 become MC1, MC2, and MC3).

 

ASE did not know about your geographic separation, so could not recommend a specific clustering configuration. In your case, since the Local controllers are distributed geographically, they would not need to be part of a cluster. Your existing configuration should port over so that the AP Group points the LMS IP to the geographically closest controller (MC1, 2, or 3), with the Backup LMS IP being the central MC4/MC5 controllers.

---

@cclemmer wrote:

 

ASE did not know about your geographic separation, so could not recommend a specific clustering configuration. In your case, since the Local controllers are distributed geographically, they would not need to be part of a cluster. Your existing configuration should port over so that the AP Group points the LMS IP to the geographically closest controller (MC1, 2, or 3), with the Backup LMS IP being the central MC4/MC5 controllers.

---

Hi Charlie,

 

Many thanks for your interest. Do you mean MC4/MC5 to not terminate APs and stay as backup LMS IP for MC1, MC2 and MC3, similar to the many-to-one (N+1) redundancy model?

 

Regards,

Julián
 

---

@fjulianom wrote:

---

@cclemmer 

---

Many thanks for your interest. Do you mean MC4/MC5 to not terminate APs and stay as backup LMS IP for MC1, MC2 and MC3, similar to the many-to-one (N+1) redundancy model?

---

Because you would be adding a pair of Mobility Masters to the environment, MC4/MC5 are capable of terminating APs as your existing master/backup master do today. 

 

If doing DNS based controller discovery as I understand this site does, aruba-master can continue to point to a VRRP IP that's shared across MC4 and MC5. When the AP boots and pulls down it's AP Group config, it will know to terminate to MC1/MC2/MC3 based on the geographically closest controller, as the current behavior exists. 

 

In the environment as it operates today, do the APs have an LMS IP pointing to their local L1/L2/L3 controller with the backup LMS IP pointing to the master, or are you achieving HA using a different mechanism?

---

 wrote:

In the environment as it operates today, do the APs have an LMS IP pointing to their local L1/L2/L3 controller with the backup LMS IP pointing to the master, or are you achieving HA using a different mechanism?

---

Hi Charlie

 

Yes, exactly. Actually there is only one master (say M1 which becomes MC4) and the APs point to their closest controller (L1, L2, L3) as LMS IP and have the master M1 as backup LMS IP.

 

Regards,

Julián

---

@fjulianom wrote:

 

Yes, exactly. Actually there is only one master (say M1 which becomes MC4) and the APs point to their closest controller (L1, L2, L3) as LMS IP and have the master M1 as backup LMS IP.

 

Regards,

Julián

---

Then the same config would hold true here. The APs point to MC1 - M3 as their LMS IP, and MC4 would be the backup LMS IP in case of a local controller failure. All four MCs (1-4) are managed by the Mobility Master so that the needed configuration components are available across all MCs.

Hi Charlie,

 

In case of a new implementation where there is only a MM and MC1, MC2 and MC3 (not MC4 and MC5), can the MCs be members of the same cluster if the have only L3 connectivity? If so, can the advantages of ArubaOS 8 be achieved with this topology (seamless failover, live upgrade, user load balancing, etc.)? My sites have L3 connectivity by MPLS but the document recommended by Víctor says the following in the clustering section:

 

Clustered can be formed over a layer 2 or a layer 3 network. Aruba strongly recommends configuring clusters with layer 2 connectivity to enable VRRP. Doing so provides CoA support for the cluster and facilitates controller discovery.

 

Regards,

Julián

---

@fjulianom wrote:

Hi Charlie,

 

In case of a new implementation where there is only a MM and MC1, MC2 and MC3 (not MC4 and MC5), can the MCs be members of the same cluster if the have only L3 connectivity? If so, can the advantages of ArubaOS 8 be achieved with this topology (seamless failover, live upgrade, user load balancing, etc.)? My sites have L3 connectivity by MPLS but the document recommended by Víctor says the following in the clustering section:

 

---

A cluster can be either L2 or L3, but an L3 cluster does not provide seemless failover, live upgrades, etc ... because the user is forced to obtain a new IP address when they move from one controller/VLAN to a different controller/VLAN.

Hi Charlie,

 

On the one hand, I understand that although is not seamless failover, if one controllers fails, the APs can failover to other controllers in the L3 cluster, right?

 

On the other hand, if my controllers have no L2 connectivity and features like seamless failover, user load balancing, live upgrades, etc. cannot be achieved, does it make sense to upgrade to ArubaOS 8?

 

Regards,

Julián

 

---

@fjulianom wrote:

Hi Charlie,

 

On the one hand, I understand that although is not seamless failover, if one controllers fails, the APs can failover to other controllers in the L3 cluster, right?

 

On the other hand, if my controllers have no L2 connectivity and features like seamless failover, user load balancing, live upgrades, etc. cannot be achieved, does it make sense to upgrade to ArubaOS 8?

 

---

What is the reasoning for going to AOS 8 in this environment?

 

AOS8 still brings AirMatch, new AP models, centralized AirGroup, etc which may be of value.

 

Using the cluster configuration, the AP will have active and standby tunnels pre-built, without the need for backup LMS. The end result is a faster switch to the standby controller ... but as noted, since there is no L2 between sites the client devices will need to obtain a new IP after their session moves over as there is no state sync. 

OK clear! Many thanks for your help Charlie!

 

Regards,

Julián