Wireless Access

Hi Airheads,

I'm seeking guidance on the best way to replace both Mobility Masters in a cluster in regards to limiting downtime (and effort, if possible).  8.2.0.1 for now, we need this move in order to be able to upgrade everything to 8.3.

The first plan is to re-use the current IP addresses, but if not advisable we'll change them.

The plan is to pre-configure the new MM offline using the second interface and copy all MD config, and when ready to shutdown the previous MM and enable the interface on the new ones.

Is there any foreseable issue with this method?  How will the MDs react when their master-ip ipsec tunnels go to the same IP with the same PSK but with a different MM (MAC address, etc) behind?

Thank you,

Can you further explain what you are doing (I'm confused)? You mention MMs in a cluster, but MCs are clustered, not MMs. Why are you needing to replace the MMs? Are they virtual or physical? You mention a move. Are you physically moving between location? Is there a reason you are not just upgrading from 8.2.0.1 to 8.3?

How many MMs, MCs, and APs do you have? What models? What OS version? What are you needing to get to?

Sorry, I ommited a lot of details in order to try to make it short.

I used the word "cluster", but yes, I was refering to an active/standby pair of redundant MMs.

All MMs (old and new) are virtual, and we have to rebuild new ones on the advice of Aruba TAC (and local engineer) as there is flash sizing and other issues with the current ones that they were not able to fix.

All in all it's a pair of MM, 4 7280 controllers (2 clusters), and 1-2k APs.  Everything is currently at 8.2.0.1, and we cannot perform an upgrade for now because of the MM coruption issue mentionned above which prevents it.  The goal is to rebuild a new MM pair, on the advice of Aruba, tie up the controllers to it and then upgrade everything to 8.3 (or whatever is the latest Conservative release at that time).

Thanks,

Hello,

I assume that you have an,

Existing vMM1 --> x.x.x.1/24

Existing vMM2 --> x.x.x.2/24

VRRP IP --> x.x.x.5/24

New vMM3 --> x.x.x.3/24

New vMM4 --> x.x.x.4/24

All the configurations are going to be in L2 VRRP redundancy. (Even for L3 we can still follow the below process, in DC/DR kindof setup.)

I understand that you are having an issue of spec sizing with the existing MM setup and your upgrading process is dragging on because of it.

If the Configuration on the MM is fine. we can add one New vMM3 as another Standby and bring down (remove with different IP or replace with same IP) one of the existing vMM1/vMM2.

The configuration will be shared with the new vMM.

Please remmber you don't have to worry about bringing down the MM, as long as there are MCs to take care of the APs and Clients.

I believe, we can bring up more than 2 nodes as MMs as we are leveraging the VRRP feature, if it is true we can try the below steps:

-Hope you have configured the IPwithPSK as the authentication for the IPsec between the MM and MCs

-Also I hope you have pointed VRRP IP as the MM IP in the MCs

-Even if you have mentioned the Physical IP as the MM in the MCs, while bringing up the New MM3 in the network remove the standby

-Make sure you have the same set of configurations on the New MM3 before proceeding to the New MM4

If bringing more than 2 nodes as MM is not possible, we can remove the standby then add the MM3 as the standby. Then after confirming that configs sync is successful we can proceed to the MM4.

The New MM Active MM Controller should come up with the same configurations (atleast MC folder, WLAN/AAA profiles and VLANs) as the old controllers to prevent any unfortunate incidents in the network.

But, the above steps will not require down time for the network but only for the MM setup.

If you are still not sure, please share the above steps with TAC, if no response from @Westcott.

Please keep us posted about the result.

Hope this helps you!!

- Jeeva Selvakumar

Thanks a lot for your answer.  I did not consider the possibility of adding the new MMs to the existing cluster, but this sure seems like an easier solution.  The MCs are currently pointing at the VRRP as well so not having to touch them would be nice, it would make the window approval easier.

My only remaining interogation in this case would be about the licensing.  Will it permanently follow the cluster as the MMs roll over and the original ones are not reachable anymore?  I believe they are usually tied to the virtual serial number of the MM?

Thanks,

Hi Barf,

The 8.x setup follows the Centralized server license feature from the 6.x, so when we remove the MM Primary (Active License server) the Standby (Backup License Server) will become Primary License Server.

Likewise, the shared LIcense pool will be retained by the new Server for 30 days of lifetime and the network will not be affected even if the License pool expires, as long as there is no reboot of the AP or the MCs.

Bringing in New APs is not possible though.

But, 30 days is more than enough to check the MM pasphrase key and license DB with the commands below:

- show license passphrase --> On the New and Existing MM which you want to make as Primary MM

- show license --> On the existing primary MM, Collect the output

Share the both outputs from both controllers with the WC team of the TAC, they will do the license transfer. Verify that existing and new set of licenses with an engineer from the TAC, make sure about the count in each feature set.

After which you can dismantle/remove the existing MMs that are causing issues.You can take few days time to monitor before removing them.

- Jeeva Selvakumar

Excellent, we will proceed this way.

Thanks a lot for you help.

Hello

Please note you might have to have a MM license while adding the 2 new nodes.

It can be tackled with exisiting license sets or can take demo license frm Aruba SE or TAC team.

If you came across any issue, please share your experience here in community link.

Best of Luck!!

- Jeeva Selvakumar