Wireless Access

I have an engagement coming up to migrate a 2 node Mobility Conductor cluster from VM to hardware appliances. My original thought was to migrate the backup MM first but then I realized you can't have a VM and hardware in the same cluster (I think - I know that's true for controllers, trying to find the doc for MMs now). I will still do it that way, but break the dependency first. My question is  what kind of gotchas might I get from the controller side? When you initially set up a controller to point to an MM, it asks if the MM is VM or HW. That leads me to believe I may need to make a change on the controllers when I migrate.  For a point of reference, the new MM instance will have all of the old IP addresses, VIP, etc as the old

So to put it in a nutshell, I have 2 main questions
1) What is the best practice to migrate this (restore new HW from flashbackup of old VM, create new instance and copy-and-past and then change the IPs, something else)
2) Is there anything I need to do on the controller side if the MM it is pointing to changes from VM to HW?

Thanks

Jeff Johnston

------------------------------
Jeffrey Johnston
------------------------------

Far as i known you can backup and restore from a virtual to a hardware appliance. 

Licenses on your virtual mobility conductor are bound the the system passphrase and must be migrated through the asp.arubanetworks.com portal (or contact support) to move to the new hardware.

On your Mobility Controller the master-ip must be pointed to the mobility conductor. This IP is used by the mobility controller to initiate a IPSEC tunnel to the mobility conductor, after the IPSEC is established the Mobility Conductor will push the managed device configuration to the mobility controller. Be sure you new Conductor have the same managed device configuration, it will override your current mobility controller configuration when something is different ;).

For your migration you will probably like to use a new IP on your mobility conductor, so you can first move one controller to test your new setup.

When not very familiar with the process i would advice you to work with your local Aruba Partner for a smooth migration.

------------------------------
Marcel Koedijk | MVP Guru 2021 | ACEP | ACMP | ACCP | ACDP | Ekahau ECSE | Not an HPE Employee | Opinions are my own
------------------------------

Thank you for your reply

Just some clarification - at this point the Controllers are set up in a cluster so we cannot move just one to test unfortunately.  Migrating the licenses is not an issue.  My main question comes around "On your Mobility Controller the master-ip must be pointed to the mobility conductor" - since the new MM will have the same IP address as the previous, the ip will already be pointed there (I just need to make sure the IPSec phrase is correct and the IP of the controller is configured in the Mobility Conductor).  But in the initial setup of a controller, the script specifically asks if the MM is VM or HW.  This leads me to believe there may be a different setting that needs to be tweeked to tell the controller that the MM is no longer VM but HW.

Jeff

------------------------------
Jeffrey Johnston
------------------------------

Original Message:
Sent: Jan 05, 2022 06:31 PM
From: marcel koedijk
Subject: Migrate Mobility Conductor from VM to Hardware

Far as i known you can backup and restore from a virtual to a hardware appliance. 

Licenses on your virtual mobility conductor are bound the the system passphrase and must be migrated through the asp.arubanetworks.com portal (or contact support) to move to the new hardware.

On your Mobility Controller the master-ip must be pointed to the mobility conductor. This IP is used by the mobility controller to initiate a IPSEC tunnel to the mobility conductor, after the IPSEC is established the Mobility Conductor will push the managed device configuration to the mobility controller. Be sure you new Conductor have the same managed device configuration, it will override your current mobility controller configuration when something is different ;).

For your migration you will probably like to use a new IP on your mobility conductor, so you can first move one controller to test your new setup.

When not very familiar with the process i would advice you to work with your local Aruba Partner for a smooth migration.

------------------------------
Marcel Koedijk | MVP Guru 2021 | ACEP | ACMP | ACCP | ACDP | Ekahau ECSE | Not an HPE Employee | Opinions are my own
------------------------------

Hi Jeff,

Far as i known the question during the controller setup "connect to physical or virtual mobility conductor" is there for one reason.

A virtual mobility conductor don't have a TPM chip and therefore you can only establish the IPSEC based on PSK

A physical mobility conductor have a TMP chip and therefore you have the choose to use PSK or Certificated based (through the TPM chip_) for IPSEC .

As far as you keep using PSK for the IPSEC tunnels with the same master-ip  there should nothing to be changed on the controller side.

Thats what i think.

------------------------------
Marcel Koedijk | MVP Guru 2021 | ACEP | ACMP | ACCP | ACDP | Ekahau ECSE | Not an HPE Employee | Opinions are my own
------------------------------

Original Message:
Sent: Jan 06, 2022 08:43 AM
From: Jeffrey Johnston
Subject: Migrate Mobility Conductor from VM to Hardware

Thank you for your reply

Just some clarification - at this point the Controllers are set up in a cluster so we cannot move just one to test unfortunately.  Migrating the licenses is not an issue.  My main question comes around "On your Mobility Controller the master-ip must be pointed to the mobility conductor" - since the new MM will have the same IP address as the previous, the ip will already be pointed there (I just need to make sure the IPSec phrase is correct and the IP of the controller is configured in the Mobility Conductor).  But in the initial setup of a controller, the script specifically asks if the MM is VM or HW.  This leads me to believe there may be a different setting that needs to be tweeked to tell the controller that the MM is no longer VM but HW.

Jeff

------------------------------
Jeffrey Johnston
------------------------------


Original Message:
Sent: Jan 05, 2022 06:31 PM
From: marcel koedijk
Subject: Migrate Mobility Conductor from VM to Hardware

Far as i known you can backup and restore from a virtual to a hardware appliance. 

Licenses on your virtual mobility conductor are bound the the system passphrase and must be migrated through the asp.arubanetworks.com portal (or contact support) to move to the new hardware.

On your Mobility Controller the master-ip must be pointed to the mobility conductor. This IP is used by the mobility controller to initiate a IPSEC tunnel to the mobility conductor, after the IPSEC is established the Mobility Conductor will push the managed device configuration to the mobility controller. Be sure you new Conductor have the same managed device configuration, it will override your current mobility controller configuration when something is different ;).

For your migration you will probably like to use a new IP on your mobility conductor, so you can first move one controller to test your new setup.

When not very familiar with the process i would advice you to work with your local Aruba Partner for a smooth migration.

------------------------------
Marcel Koedijk | MVP Guru 2021 | ACEP | ACMP | ACCP | ACDP | Ekahau ECSE | Not an HPE Employee | Opinions are my own

Hi Marcel

Thanks for the update!  That's exactly the kind of info I was looking for.  So it appears as if the only time there would be an issue is if you are moving from HW to VM (not from VM to HW) AND you are using cert based IPSec for authentication.

------------------------------
Jeffrey Johnston
------------------------------

Original Message:
Sent: Jan 06, 2022 03:51 PM
From: marcel koedijk
Subject: Migrate Mobility Conductor from VM to Hardware

Hi Jeff,

Far as i known the question during the controller setup "connect to physical or virtual mobility conductor" is there for one reason.

A virtual mobility conductor don't have a TPM chip and therefore you can only establish the IPSEC based on PSK

A physical mobility conductor have a TMP chip and therefore you have the choose to use PSK or Certificated based (through the TPM chip_) for IPSEC .

As far as you keep using PSK for the IPSEC tunnels with the same master-ip  there should nothing to be changed on the controller side.

Thats what i think.

------------------------------
Marcel Koedijk | MVP Guru 2021 | ACEP | ACMP | ACCP | ACDP | Ekahau ECSE | Not an HPE Employee | Opinions are my own
------------------------------


Original Message:
Sent: Jan 06, 2022 08:43 AM
From: Jeffrey Johnston
Subject: Migrate Mobility Conductor from VM to Hardware

Thank you for your reply

Just some clarification - at this point the Controllers are set up in a cluster so we cannot move just one to test unfortunately.  Migrating the licenses is not an issue.  My main question comes around "On your Mobility Controller the master-ip must be pointed to the mobility conductor" - since the new MM will have the same IP address as the previous, the ip will already be pointed there (I just need to make sure the IPSec phrase is correct and the IP of the controller is configured in the Mobility Conductor).  But in the initial setup of a controller, the script specifically asks if the MM is VM or HW.  This leads me to believe there may be a different setting that needs to be tweeked to tell the controller that the MM is no longer VM but HW.

Jeff

------------------------------
Jeffrey Johnston


Original Message:
Sent: Jan 05, 2022 06:31 PM
From: marcel koedijk
Subject: Migrate Mobility Conductor from VM to Hardware

Far as i known you can backup and restore from a virtual to a hardware appliance. 

Licenses on your virtual mobility conductor are bound the the system passphrase and must be migrated through the asp.arubanetworks.com portal (or contact support) to move to the new hardware.

On your Mobility Controller the master-ip must be pointed to the mobility conductor. This IP is used by the mobility controller to initiate a IPSEC tunnel to the mobility conductor, after the IPSEC is established the Mobility Conductor will push the managed device configuration to the mobility controller. Be sure you new Conductor have the same managed device configuration, it will override your current mobility controller configuration when something is different ;).

For your migration you will probably like to use a new IP on your mobility conductor, so you can first move one controller to test your new setup.

When not very familiar with the process i would advice you to work with your local Aruba Partner for a smooth migration.

------------------------------
Marcel Koedijk | MVP Guru 2021 | ACEP | ACMP | ACCP | ACDP | Ekahau ECSE | Not an HPE Employee | Opinions are my own

One additional quick question - the current MM licenses are VM licenses.  Am I able to migrate them directly to HW or will I need to go thru TAC for that?

------------------------------
Jeffrey Johnston
------------------------------

Original Message:
Sent: Jan 06, 2022 03:51 PM
From: marcel koedijk
Subject: Migrate Mobility Conductor from VM to Hardware

Hi Jeff,

Far as i known the question during the controller setup "connect to physical or virtual mobility conductor" is there for one reason.

A virtual mobility conductor don't have a TPM chip and therefore you can only establish the IPSEC based on PSK

A physical mobility conductor have a TMP chip and therefore you have the choose to use PSK or Certificated based (through the TPM chip_) for IPSEC .

As far as you keep using PSK for the IPSEC tunnels with the same master-ip  there should nothing to be changed on the controller side.

Thats what i think.

------------------------------
Marcel Koedijk | MVP Guru 2021 | ACEP | ACMP | ACCP | ACDP | Ekahau ECSE | Not an HPE Employee | Opinions are my own
------------------------------


Original Message:
Sent: Jan 06, 2022 08:43 AM
From: Jeffrey Johnston
Subject: Migrate Mobility Conductor from VM to Hardware

Thank you for your reply

Just some clarification - at this point the Controllers are set up in a cluster so we cannot move just one to test unfortunately.  Migrating the licenses is not an issue.  My main question comes around "On your Mobility Controller the master-ip must be pointed to the mobility conductor" - since the new MM will have the same IP address as the previous, the ip will already be pointed there (I just need to make sure the IPSec phrase is correct and the IP of the controller is configured in the Mobility Conductor).  But in the initial setup of a controller, the script specifically asks if the MM is VM or HW.  This leads me to believe there may be a different setting that needs to be tweeked to tell the controller that the MM is no longer VM but HW.

Jeff

------------------------------
Jeffrey Johnston


Original Message:
Sent: Jan 05, 2022 06:31 PM
From: marcel koedijk
Subject: Migrate Mobility Conductor from VM to Hardware

Far as i known you can backup and restore from a virtual to a hardware appliance. 

Licenses on your virtual mobility conductor are bound the the system passphrase and must be migrated through the asp.arubanetworks.com portal (or contact support) to move to the new hardware.

On your Mobility Controller the master-ip must be pointed to the mobility conductor. This IP is used by the mobility controller to initiate a IPSEC tunnel to the mobility conductor, after the IPSEC is established the Mobility Conductor will push the managed device configuration to the mobility controller. Be sure you new Conductor have the same managed device configuration, it will override your current mobility controller configuration when something is different ;).

For your migration you will probably like to use a new IP on your mobility conductor, so you can first move one controller to test your new setup.

When not very familiar with the process i would advice you to work with your local Aruba Partner for a smooth migration.

------------------------------
Marcel Koedijk | MVP Guru 2021 | ACEP | ACMP | ACCP | ACDP | Ekahau ECSE | Not an HPE Employee | Opinions are my own

Hi Jeffrey,

Your licenses are bound to the virtual appliance based on the "show license passphrase". The AP capacity, PEF, RFProtect, etc. can only be move to the new hardware appliance to regenerate your keys in the asp.arubanetworks.com portal under licenses > transfer license. Your virtual mobility master licence (mm-va-xxx) isn't needed for a hardware appliance.

When run in some trouble with the license migration you should contact TAC support to assist you.





------------------------------
Marcel Koedijk | MVP Guru 2021 | ACEP | ACMP | ACCP | ACDP | Ekahau ECSE | Not an HPE Employee | Opinions are my own
------------------------------

Original Message:
Sent: Jan 10, 2022 10:40 AM
From: Jeffrey Johnston
Subject: Migrate Mobility Conductor from VM to Hardware

One additional quick question - the current MM licenses are VM licenses.  Am I able to migrate them directly to HW or will I need to go thru TAC for that?

------------------------------
Jeffrey Johnston
------------------------------


Original Message:
Sent: Jan 06, 2022 03:51 PM
From: marcel koedijk
Subject: Migrate Mobility Conductor from VM to Hardware

Hi Jeff,

Far as i known the question during the controller setup "connect to physical or virtual mobility conductor" is there for one reason.

A virtual mobility conductor don't have a TPM chip and therefore you can only establish the IPSEC based on PSK

A physical mobility conductor have a TMP chip and therefore you have the choose to use PSK or Certificated based (through the TPM chip_) for IPSEC .

As far as you keep using PSK for the IPSEC tunnels with the same master-ip  there should nothing to be changed on the controller side.

Thats what i think.

------------------------------
Marcel Koedijk | MVP Guru 2021 | ACEP | ACMP | ACCP | ACDP | Ekahau ECSE | Not an HPE Employee | Opinions are my own


Original Message:
Sent: Jan 06, 2022 08:43 AM
From: Jeffrey Johnston
Subject: Migrate Mobility Conductor from VM to Hardware

Thank you for your reply

Just some clarification - at this point the Controllers are set up in a cluster so we cannot move just one to test unfortunately.  Migrating the licenses is not an issue.  My main question comes around "On your Mobility Controller the master-ip must be pointed to the mobility conductor" - since the new MM will have the same IP address as the previous, the ip will already be pointed there (I just need to make sure the IPSec phrase is correct and the IP of the controller is configured in the Mobility Conductor).  But in the initial setup of a controller, the script specifically asks if the MM is VM or HW.  This leads me to believe there may be a different setting that needs to be tweeked to tell the controller that the MM is no longer VM but HW.

Jeff

------------------------------
Jeffrey Johnston


Original Message:
Sent: Jan 05, 2022 06:31 PM
From: marcel koedijk
Subject: Migrate Mobility Conductor from VM to Hardware

Far as i known you can backup and restore from a virtual to a hardware appliance. 

Licenses on your virtual mobility conductor are bound the the system passphrase and must be migrated through the asp.arubanetworks.com portal (or contact support) to move to the new hardware.

On your Mobility Controller the master-ip must be pointed to the mobility conductor. This IP is used by the mobility controller to initiate a IPSEC tunnel to the mobility conductor, after the IPSEC is established the Mobility Conductor will push the managed device configuration to the mobility controller. Be sure you new Conductor have the same managed device configuration, it will override your current mobility controller configuration when something is different ;).

For your migration you will probably like to use a new IP on your mobility conductor, so you can first move one controller to test your new setup.

When not very familiar with the process i would advice you to work with your local Aruba Partner for a smooth migration.

------------------------------
Marcel Koedijk | MVP Guru 2021 | ACEP | ACMP | ACCP | ACDP | Ekahau ECSE | Not an HPE Employee | Opinions are my own