Wireless Access

I originally designed the Aruba Controllers to have a High Availability (H.A.) Cluster for the Mobility Masters and then again for the Managed Devices (Local Hardware Controllers).   The local Controllers are managed by the MM and each office has 2 local controllers.

I did not setup router pre-emption on the Mobility Masters or the local controllers; but now since I am updating the version of the MM I learned that router pre-emption was required for the Mobility master. Otherwise both MM's were not able to out as the 'stand-by mode and not able to communicate with the local controllers.   After I set the router pre-emption and made 1 MM a priority over the other Mobility master then the MM's were able to see the local controllers as I would expect them to.

I have 3 questions.

1).  What benefits does having router pre-emption bring for the Mobility masters?   

2).  Does anyone know why it is necessary to have router pre-emption on the Mobility Masters at least for version 8.7?

3).  Is router pre-emption needed for the hardware controllers as well?

I was told by Aruba Support that it is not required for the local controllers; but, I will be updating the local controllers in the middle of the night and I would prefer not to have any surprises.  I am planning on updating 2 controllers that are not used in production yet, so I will see what will happen to those controllers; but, I do want to discuss the 3 questions above.

------------------------------
Stavros K
------------------------------

Router pre-emption is something that is used in many active-standby systems. If you have a redundancy system, in case of a failure you can move the shared IP address/Virtual IP to the other node/controller to make that one active. Then when the original system returns you basically have two choices: leave everything as it is, or move the Virtual IP back to the system that was holding the IP in the first place. Benefit of moving back is that you know that if there are no special conditions, it's always the same node that is active. Drawbacks are that moving back may introduce a brief interruption while the IP transfers over, and the risk that if the same problem triggers again on the 'primary node' that you will get in an bounce up-down situation where the primary node stops, secondary takes over, primary returns and becomes active, stops again, secondary takes over, and so on. For the mobility conductor, it's not only the IP that moves over, but it's also the software function. A secondary MCR sits there and becomes active only when the primary fails, so that means that where the IP lives must correspond to where the software is running. For many routers it does not really matter as each node is active (and supposed to have the same configuration). Same applies for controllers.

Hope that asnwers your 3 questions.

------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.

In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.
------------------------------

Original Message:
Sent: May 12, 2023 06:30 AM
From: StavrosK
Subject: What does router pre-emption do and is it required for Aruba

I originally designed the Aruba Controllers to have a High Availability (H.A.) Cluster for the Mobility Masters and then again for the Managed Devices (Local Hardware Controllers).   The local Controllers are managed by the MM and each office has 2 local controllers.

I did not setup router pre-emption on the Mobility Masters or the local controllers; but now since I am updating the version of the MM I learned that router pre-emption was required for the Mobility master. Otherwise both MM's were not able to out as the 'stand-by mode and not able to communicate with the local controllers.   After I set the router pre-emption and made 1 MM a priority over the other Mobility master then the MM's were able to see the local controllers as I would expect them to.

I have 3 questions.

1).  What benefits does having router pre-emption bring for the Mobility masters?   

2).  Does anyone know why it is necessary to have router pre-emption on the Mobility Masters at least for version 8.7?

3).  Is router pre-emption needed for the hardware controllers as well?

I was told by Aruba Support that it is not required for the local controllers; but, I will be updating the local controllers in the middle of the night and I would prefer not to have any surprises.  I am planning on updating 2 controllers that are not used in production yet, so I will see what will happen to those controllers; but, I do want to discuss the 3 questions above.

------------------------------
Stavros K
------------------------------

thanks yout response answered the 1st ofmy 3 questions.

I have 3 questions.

1).  What benefits does having router pre-emption bring for the Mobility masters?   

2).  Does anyone know why it is necessary to have router pre-emption on the Mobility Masters at least for version 8.7?

3).  Is router pre-emption needed for the hardware controllers as well?

------------------------------
Stavros K
------------------------------

Original Message:
Sent: May 12, 2023 09:04 AM
From: Herman Robers
Subject: What does router pre-emption do and is it required for Aruba

Router pre-emption is something that is used in many active-standby systems. If you have a redundancy system, in case of a failure you can move the shared IP address/Virtual IP to the other node/controller to make that one active. Then when the original system returns you basically have two choices: leave everything as it is, or move the Virtual IP back to the system that was holding the IP in the first place. Benefit of moving back is that you know that if there are no special conditions, it's always the same node that is active. Drawbacks are that moving back may introduce a brief interruption while the IP transfers over, and the risk that if the same problem triggers again on the 'primary node' that you will get in an bounce up-down situation where the primary node stops, secondary takes over, primary returns and becomes active, stops again, secondary takes over, and so on. For the mobility conductor, it's not only the IP that moves over, but it's also the software function. A secondary MCR sits there and becomes active only when the primary fails, so that means that where the IP lives must correspond to where the software is running. For many routers it does not really matter as each node is active (and supposed to have the same configuration). Same applies for controllers.

Hope that asnwers your 3 questions.

------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.

In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.

Original Message:
Sent: May 12, 2023 06:30 AM
From: StavrosK
Subject: What does router pre-emption do and is it required for Aruba

I originally designed the Aruba Controllers to have a High Availability (H.A.) Cluster for the Mobility Masters and then again for the Managed Devices (Local Hardware Controllers).   The local Controllers are managed by the MM and each office has 2 local controllers.

I did not setup router pre-emption on the Mobility Masters or the local controllers; but now since I am updating the version of the MM I learned that router pre-emption was required for the Mobility master. Otherwise both MM's were not able to out as the 'stand-by mode and not able to communicate with the local controllers.   After I set the router pre-emption and made 1 MM a priority over the other Mobility master then the MM's were able to see the local controllers as I would expect them to.

I have 3 questions.

1).  What benefits does having router pre-emption bring for the Mobility masters?   

2).  Does anyone know why it is necessary to have router pre-emption on the Mobility Masters at least for version 8.7?

3).  Is router pre-emption needed for the hardware controllers as well?

I was told by Aruba Support that it is not required for the local controllers; but, I will be updating the local controllers in the middle of the night and I would prefer not to have any surprises.  I am planning on updating 2 controllers that are not used in production yet, so I will see what will happen to those controllers; but, I do want to discuss the 3 questions above.

------------------------------
Stavros K
------------------------------

Hi Stavros,

Router pre-emption is a feature vim VRRP protocol.

As Herman wrote, the VRRP protocol is often used in active-standby systems. The master from the VRRP instance is active, the backup from the VRRP instance is passive. In L2 conductor-redundancy the mobility conductors check who is VRRP master and who is VRRP backup. This results in the role in the conductor-redundancy context. If the VRRP role changes, then the conductor-redundancy role also changes. With router pre-emption you achieve that the VRRP master becomes the master again after a failure or reboot. 

With L2 conductor-redundancy you can activate pre-emption, but you do not have to. Check which IP is configured as conductor IP on the mobiliti controllers, the VRRP IP or the IP of the primary mobility conductor. If you configured IP from primary mobility conductor, but it is currently VRRP backup and therefore conductor-redundancy backup - mobility controllers will not be able to tunnel to it.

VRRP protocol is implemented in controller OS, it doesn't matter if you are using hardware controller or VM, in both variants controllers behave the same.

If your mobility controllers are configured in the cluster, VRRP is not required for operation. If you use COA, VRRPs must also be configured, but this is a special case.

If you use a VRRP instance on the mobility controllers for L3 controller discovery, you can enable pre-emption if you want the IP to always connect to the same controller for L3 discovery.

------------------------------
Regards,

Waldemar
ACCX # 1377, ACEP, ACA - Network Security
If you find my answer useful, consider giving kudos and/or mark as solution
------------------------------

Original Message:
Sent: May 12, 2023 02:54 PM
From: StavrosK
Subject: What does router pre-emption do and is it required for Aruba

thanks yout response answered the 1st ofmy 3 questions.

I have 3 questions.

1).  What benefits does having router pre-emption bring for the Mobility masters?   

2).  Does anyone know why it is necessary to have router pre-emption on the Mobility Masters at least for version 8.7?

3).  Is router pre-emption needed for the hardware controllers as well?

------------------------------
Stavros K

Original Message:
Sent: May 12, 2023 09:04 AM
From: Herman Robers
Subject: What does router pre-emption do and is it required for Aruba

Router pre-emption is something that is used in many active-standby systems. If you have a redundancy system, in case of a failure you can move the shared IP address/Virtual IP to the other node/controller to make that one active. Then when the original system returns you basically have two choices: leave everything as it is, or move the Virtual IP back to the system that was holding the IP in the first place. Benefit of moving back is that you know that if there are no special conditions, it's always the same node that is active. Drawbacks are that moving back may introduce a brief interruption while the IP transfers over, and the risk that if the same problem triggers again on the 'primary node' that you will get in an bounce up-down situation where the primary node stops, secondary takes over, primary returns and becomes active, stops again, secondary takes over, and so on. For the mobility conductor, it's not only the IP that moves over, but it's also the software function. A secondary MCR sits there and becomes active only when the primary fails, so that means that where the IP lives must correspond to where the software is running. For many routers it does not really matter as each node is active (and supposed to have the same configuration). Same applies for controllers.

Hope that asnwers your 3 questions.

------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.

In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.

Original Message:
Sent: May 12, 2023 06:30 AM
From: StavrosK
Subject: What does router pre-emption do and is it required for Aruba

I originally designed the Aruba Controllers to have a High Availability (H.A.) Cluster for the Mobility Masters and then again for the Managed Devices (Local Hardware Controllers).   The local Controllers are managed by the MM and each office has 2 local controllers.

I did not setup router pre-emption on the Mobility Masters or the local controllers; but now since I am updating the version of the MM I learned that router pre-emption was required for the Mobility master. Otherwise both MM's were not able to out as the 'stand-by mode and not able to communicate with the local controllers.   After I set the router pre-emption and made 1 MM a priority over the other Mobility master then the MM's were able to see the local controllers as I would expect them to.

I have 3 questions.

1).  What benefits does having router pre-emption bring for the Mobility masters?   

2).  Does anyone know why it is necessary to have router pre-emption on the Mobility Masters at least for version 8.7?

3).  Is router pre-emption needed for the hardware controllers as well?

I was told by Aruba Support that it is not required for the local controllers; but, I will be updating the local controllers in the middle of the night and I would prefer not to have any surprises.  I am planning on updating 2 controllers that are not used in production yet, so I will see what will happen to those controllers; but, I do want to discuss the 3 questions above.

------------------------------
Stavros K
------------------------------

Hello Lord,

Forgive; but but unless I am not understanding you correctly, you are saying that the Mobility Conductors in a layer-2 cluster that have a VRRP do not require Pre-Emption.  I have found that to be untrue.  I needed to enable Pre-Emption in roder for the Mobility Masters (Conductors) to be able to view the local controllers.

My question is why.

I updated other local hardware controllers that also have a cluster configured and Pre-Emption was not required to function and update.

------------------------------
Stavros K
------------------------------

Original Message:
Sent: May 13, 2023 12:19 PM
From: lord
Subject: What does router pre-emption do and is it required for Aruba

Hi Stavros,

Router pre-emption is a feature vim VRRP protocol.

As Herman wrote, the VRRP protocol is often used in active-standby systems. The master from the VRRP instance is active, the backup from the VRRP instance is passive. In L2 conductor-redundancy the mobility conductors check who is VRRP master and who is VRRP backup. This results in the role in the conductor-redundancy context. If the VRRP role changes, then the conductor-redundancy role also changes. With router pre-emption you achieve that the VRRP master becomes the master again after a failure or reboot. 

With L2 conductor-redundancy you can activate pre-emption, but you do not have to. Check which IP is configured as conductor IP on the mobiliti controllers, the VRRP IP or the IP of the primary mobility conductor. If you configured IP from primary mobility conductor, but it is currently VRRP backup and therefore conductor-redundancy backup - mobility controllers will not be able to tunnel to it.

VRRP protocol is implemented in controller OS, it doesn't matter if you are using hardware controller or VM, in both variants controllers behave the same.

If your mobility controllers are configured in the cluster, VRRP is not required for operation. If you use COA, VRRPs must also be configured, but this is a special case.

If you use a VRRP instance on the mobility controllers for L3 controller discovery, you can enable pre-emption if you want the IP to always connect to the same controller for L3 discovery.

------------------------------
Regards,

Waldemar
ACCX # 1377, ACEP, ACA - Network Security
If you find my answer useful, consider giving kudos and/or mark as solution

Original Message:
Sent: May 12, 2023 02:54 PM
From: StavrosK
Subject: What does router pre-emption do and is it required for Aruba

thanks yout response answered the 1st ofmy 3 questions.

I have 3 questions.

1).  What benefits does having router pre-emption bring for the Mobility masters?   

2).  Does anyone know why it is necessary to have router pre-emption on the Mobility Masters at least for version 8.7?

3).  Is router pre-emption needed for the hardware controllers as well?

------------------------------
Stavros K

Original Message:
Sent: May 12, 2023 09:04 AM
From: Herman Robers
Subject: What does router pre-emption do and is it required for Aruba

Router pre-emption is something that is used in many active-standby systems. If you have a redundancy system, in case of a failure you can move the shared IP address/Virtual IP to the other node/controller to make that one active. Then when the original system returns you basically have two choices: leave everything as it is, or move the Virtual IP back to the system that was holding the IP in the first place. Benefit of moving back is that you know that if there are no special conditions, it's always the same node that is active. Drawbacks are that moving back may introduce a brief interruption while the IP transfers over, and the risk that if the same problem triggers again on the 'primary node' that you will get in an bounce up-down situation where the primary node stops, secondary takes over, primary returns and becomes active, stops again, secondary takes over, and so on. For the mobility conductor, it's not only the IP that moves over, but it's also the software function. A secondary MCR sits there and becomes active only when the primary fails, so that means that where the IP lives must correspond to where the software is running. For many routers it does not really matter as each node is active (and supposed to have the same configuration). Same applies for controllers.

Hope that asnwers your 3 questions.

------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.

In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.

Original Message:
Sent: May 12, 2023 06:30 AM
From: StavrosK
Subject: What does router pre-emption do and is it required for Aruba

I originally designed the Aruba Controllers to have a High Availability (H.A.) Cluster for the Mobility Masters and then again for the Managed Devices (Local Hardware Controllers).   The local Controllers are managed by the MM and each office has 2 local controllers.

I did not setup router pre-emption on the Mobility Masters or the local controllers; but now since I am updating the version of the MM I learned that router pre-emption was required for the Mobility master. Otherwise both MM's were not able to out as the 'stand-by mode and not able to communicate with the local controllers.   After I set the router pre-emption and made 1 MM a priority over the other Mobility master then the MM's were able to see the local controllers as I would expect them to.

I have 3 questions.

1).  What benefits does having router pre-emption bring for the Mobility masters?   

2).  Does anyone know why it is necessary to have router pre-emption on the Mobility Masters at least for version 8.7?

3).  Is router pre-emption needed for the hardware controllers as well?

I was told by Aruba Support that it is not required for the local controllers; but, I will be updating the local controllers in the middle of the night and I would prefer not to have any surprises.  I am planning on updating 2 controllers that are not used in production yet, so I will see what will happen to those controllers; but, I do want to discuss the 3 questions above.

------------------------------
Stavros K
------------------------------

Hi Stavros,

is no problem, we just make a little trip to my Aruba LAB - but only because you ask so nice ;).
So we have 2 mobility master with L2 redundancy and 4 mobility controller. The mm01 is currently the master, the mm02 is the backup-master.

(aruba-mm01) [mynode] (config) #show conductor-redundancy

Conductor redundancy configuration:
    VRRP Id 81 current state is MASTER
    Peer's IP Address is 192.168.81.12
    Peer's IPSEC Key is ********
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

(aruba-mm02) [mynode] (config) #show conductor-redundancy

Conductor redundancy configuration:
    VRRP Id 81 current state is BACKUP
    Peer's IP Address is 192.168.81.11
    Peer's IPSEC Key is ********

The mm's track the state of VRRP ID 81, thats how we determine who is master and who is backup.

(aruba-mm01) [mynode] #show vrrp 81

Virtual Router 81:
    Description MM-VRRP
    Admin State UP, VR State MASTER
    IP Address 192.168.81.10, MAC Address 00:00:5e:00:01:51, vlan 81
    Priority 200, Advertisement 1 sec, Preemption Disable Delay 0
    Auth type PASSWORD, Auth data: ********
    tracking is not enabled
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

(aruba-mm02) [mynode] (config) #show vrrp 81

Virtual Router 81:
    Description MM-VRRP
    Admin State UP, VR State BACKUP
    IP Address 192.168.81.10, MAC Address 00:00:5e:00:01:51, vlan 81
    Priority 180, Advertisement 1 sec, Preemption Disable Delay 0
    Auth type PASSWORD, Auth data: ********
    tracking is not enabled

The mm01 has priority 200, the mm02 has priority 180. Preemption is disabled on both mm's. 200 is greater than 180, therefore the mm01 is master in this VRRP instance.

All controllers are connected to the mm01, the status is up, Configuration State is UPDATE SUCCESSFUL.

(aruba-mm01) [mynode] #show switches

All Switches
------------
IP Address     IPv6 Address  Name         Location          Type       Model       Version         Status  Configuration State  Config Sync Time (sec)  Config ID  Release Type
----------     ------------  ----         --------          ----       -----       -------         ------  -------------------  ----------------------  ---------  ------------
192.168.81.11  None          aruba-mm01   Building1.floor1  conductor  ArubaMM-VA  8.10.0.6_86193  up      UPDATE SUCCESSFUL    0                       835        LSR
192.168.81.12  None          aruba-mm02   Building1.floor1  standby    ArubaMM-VA  8.10.0.6_86193  up      UPDATE SUCCESSFUL    10                      835        LSR
192.168.84.12  None          aruba-ho02   Building1.floor1  MD         ArubaMC-VA  8.10.0.6_86193  up      UPDATE SUCCESSFUL    10                      835        LSR
192.168.86.11  None          aruba-dmz01  Building1.floor1  MD         ArubaMC-VA  8.10.0.6_86193  up      UPDATE SUCCESSFUL    10                      835        LSR
192.168.86.12  None          aruba-dmz02  Building1.floor1  MD         ArubaMC-VA  8.10.0.6_86193  up      UPDATE SUCCESSFUL    10                      835        LSR
192.168.84.11  None          aruba-ho01   Building1.floor1  MD         ArubaMC-VA  8.10.0.6_86193  up      UPDATE SUCCESSFUL    10                      835        LSR

Total Switches:6
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

(aruba-mm02) [mynode] (config) #show switches

All Switches
------------
IP Address     IPv6 Address  Name        Location          Type     Model       Version         Status  Configuration State  Config Sync Time (sec)  Config ID  Release Type
----------     ------------  ----        --------          ----     -----       -------         ------  -------------------  ----------------------  ---------  ------------
192.168.81.12  None          aruba-mm02  Building1.floor1  standby  ArubaMM-VA  8.10.0.6_86193  up      UPDATE SUCCESSFUL    10                      835        LSR

Total Switches:1

Now let's boot the mm01 and see what happens.

(airit-mm01) [mynode] (config) #reload
Do you really want to restart the system(y/n): y

System will now restart!
Log infrastructure ended gracefully.

[SSH] INFO: DISCONNECT

The VRRP advertisement of the mm01 are missing, therefore the mm02 takes over the master role in the VRRP instance.

(aruba-mm02) [mynode] (config) #show vrrp 81

Virtual Router 81:
    Description MM-VRRP
    Admin State UP, VR State MASTER
    IP Address 192.168.81.10, MAC Address 00:00:5e:00:01:51, vlan 81
    Priority 180, Advertisement 1 sec, Preemption Disable Delay 0
    Auth type PASSWORD, Auth data: ********
    tracking is not enabled

The mobility master role follows the VRRP master, so the the mm02 also becomes the master in our L2-Redundancy construct.

(aruba-mm02) [mynode] (config) #show conductor-redundancy

Conductor redundancy configuration:
    VRRP Id 81 current state is MASTER
    Peer's IP Address is 192.168.81.11
    Peer's IPSEC Key is ********

It's very nice, of course, but the really interesting question is - what happens to the mobility controllers?

(aruba-mm02) [mynode] (config) # show switches

All Switches
------------
IP Address     IPv6 Address  Name         Location          Type       Model       Version         Status  Configuration State  Config Sync Time (sec)  Config ID  Release Type
----------     ------------  ----         --------          ----       -----       -------         ------  -------------------  ----------------------  ---------  ------------
192.168.81.12  None          aruba-mm02   Building1.floor1  conductor  ArubaMM-VA  8.10.0.6_86193  up      UPDATE SUCCESSFUL    0                       835        LSR
192.168.84.12  None          aruba-ho02   Building1.floor1  MD         ArubaMC-VA  8.10.0.6_86193  up      UPDATE SUCCESSFUL    10                      835        LSR
192.168.86.12  None          aruba-dmz02  Building1.floor1  MD         ArubaMC-VA  8.10.0.6_86193  up      UPDATE SUCCESSFUL    10                      835        LSR
192.168.86.11  None          aruba-dmz01  Building1.floor1  MD         ArubaMC-VA  8.10.0.6_86193  up      UPDATE SUCCESSFUL    10                      835        LSR
192.168.84.11  None          aruba-ho01   Building1.floor1  MD         ArubaMC-VA  8.10.0.6_86193  up      UPDATE SUCCESSFUL    10                      835        LSR

Total Switches:5

As we can see, all controllers are now connected to the mm02.
Magic? No, just proper configuration.
For L2 redundancy it is important that the VRRP IP address is used when configuring the mobility controller, as we see in the example of the aruba-ho01 controller.

(aruba-ho01) #show running-config | include 192.168.81.10
Building Configuration...
conductorip 192.168.81.10 ipsec ****** interface vlan 84
(aruba-ho01) #

The mobility controller connects to the VRRP IP address and thereby lands on the mobility master, which currently has the master role.

Now that we're doing magic in the LAB, let's see what happens when a mobility controller connects directly to the Interface IP from the mm02. We reconfigure the aruba-ho01 and take a look.

(aruba-mm02) [mynode] 
conf t
cd aruba-ho01
  conductorip 192.168.81.12 ipsec aruba123 interface vlan 84
Change in the conductorip configuration requires device to reload. Make sure the modified configuration ensures connectivity to the Conductor. Do you want to continue [y/n]: y
write mem

The controller aruba-ho01 boots automatically after the configuration, the mm02 displays it with status down.

(aruba-mm02) [xx:xx:xx:xx:xx:xx] (config) #show switches

All Switches
------------
IP Address     IPv6 Address  Name         Location          Type       Model       Version         Status  Configuration State  Config Sync Time (sec)  Config ID  Release Type
----------     ------------  ----         --------          ----       -----       -------         ------  -------------------  ----------------------  ---------  ------------
192.168.81.12  None          aruba-mm02   Building1.floor1  conductor  ArubaMM-VA  8.10.0.6_86193  up      UPDATE SUCCESSFUL    0                       836        LSR
192.168.84.12  None          aruba-ho02   Building1.floor1  MD         ArubaMC-VA  8.10.0.6_86193  up      UPDATE REQUIRED      0                       835        LSR
192.168.81.11  None          aruba-mm01   Building1.floor1  standby    ArubaMM-VA  8.10.0.6_86193  up      UPDATE REQUIRED      0                       835        LSR
192.168.86.12  None          aruba-dmz02  Building1.floor1  MD         ArubaMC-VA  8.10.0.6_86193  up      UPDATE REQUIRED      0                       835        LSR
192.168.86.11  None          aruba-dmz01  Building1.floor1  MD         ArubaMC-VA  8.10.0.6_86193  up      UPDATE REQUIRED      0                       835        LSR
192.168.84.11  None          aruba-ho01   Building1.floor1  MD         ArubaMC-VA  8.10.0.6_86193  down    UPDATE REQUIRED      0                       835        LSR

Total Switches:6

Some time later the aruba-ho01 is online again with the status up and configuration state UPDATE SUCCESSFUL.

(aruba-mm02) [xx:xx:xx:xx:xx:xx] (config) #show switches

All Switches
------------
IP Address     IPv6 Address  Name         Location          Type       Model       Version         Status  Configuration State  Config Sync Time (sec)  Config ID  Release Type
----------     ------------  ----         --------          ----       -----       -------         ------  -------------------  ----------------------  ---------  ------------
192.168.81.12  None          aruba-mm02   Building1.floor1  conductor  ArubaMM-VA  8.10.0.6_86193  up      UPDATE SUCCESSFUL    0                       836        LSR
192.168.84.12  None          aruba-ho02   Building1.floor1  MD         ArubaMC-VA  8.10.0.6_86193  up      UPDATE SUCCESSFUL    0                       836        LSR
192.168.81.11  None          aruba-mm01   Building1.floor1  standby    ArubaMM-VA  8.10.0.6_86193  up      UPDATE SUCCESSFUL    10                      836        LSR
192.168.86.12  None          aruba-dmz02  Building1.floor1  MD         ArubaMC-VA  8.10.0.6_86193  up      UPDATE SUCCESSFUL    0                       836        LSR
192.168.86.11  None          aruba-dmz01  Building1.floor1  MD         ArubaMC-VA  8.10.0.6_86193  up      UPDATE SUCCESSFUL    0                       836        LSR
192.168.84.11  None          aruba-ho01   Building1.floor1  MD         ArubaMC-VA  8.10.0.6_86193  up      UPDATE SUCCESSFUL    10                      836        LSR

But our quest continues, we are now booting the mm02.

(airit-mm02) [mynode] (config) #reload
Do you really want to restart the system(y/n): y

System will now restart!
Log infrastructure ended gracefully.

[SSH] INFO: DISCONNECT

We see that the mm01 now became VRRP master and also took over the master role in our L2 redundancy construct.

(aruba-mm01) [mynode] #show conductor-redundancy

Conductor redundancy configuration:
    VRRP Id 81 current state is MASTER
    Peer's IP Address is 192.168.81.12
    Peer's IPSEC Key is ********
(aruba-mm01) [mynode] #show vrrp 81

Virtual Router 81:
    Description MM-VRRP
    Admin State UP, VR State MASTER
    IP Address 192.168.81.10, MAC Address 00:00:5e:00:01:51, vlan 81
    Priority 200, Advertisement 1 sec, Preemption Disable Delay 0
    Auth type PASSWORD, Auth data: ********
    tracking is not enabled
(aruba-mm01) [mynode] # 

But unfortunately the aruba-ho01 is missing, it is no longer displayed, we see only 5 switches instead of 6 :(

(aruba-mm01) [mynode] # show switches

All Switches
------------
IP Address     IPv6 Address  Name         Location          Type       Model       Version         Status  Configuration State  Config Sync Time (sec)  Config ID  Release Type
----------     ------------  ----         --------          ----       -----       -------         ------  -------------------  ----------------------  ---------  ------------
192.168.81.11  None          aruba-mm01   Building1.floor1  conductor  ArubaMM-VA  8.10.0.6_86193  up      UPDATE SUCCESSFUL    0                       836        LSR
192.168.81.12  None          aruba-mm02   Building1.floor1  standby    ArubaMM-VA  8.10.0.6_86193  up      CONFIG PROPAGATION   0                       836        LSR
192.168.84.12  None          aruba-ho02   Building1.floor1  MD         ArubaMC-VA  8.10.0.6_86193  up      UPDATE SUCCESSFUL    10                      836        LSR
192.168.86.11  None          aruba-dmz01  Building1.floor1  MD         ArubaMC-VA  8.10.0.6_86193  up      UPDATE SUCCESSFUL    10                      836        LSR
192.168.86.12  None          aruba-dmz02  Building1.floor1  MD         ArubaMC-VA  8.10.0.6_86193  up      UPDATE SUCCESSFUL    10                      836        LSR

Total Switches:5

We can log in directly on the aruba-ho01 and see what he is doing. 

(aruba-ho01) #show switches

All Switches
------------
IP Address     IPv6 Address  Name        Location          Type  Model       Version         Status  Configuration State                       Config Sync Time (sec)  Config ID  Release Type
----------     ------------  ----        --------          ----  -----       -------         ------  -------------------                       ----------------------  ---------  ------------
192.168.84.11  None          aruba-ho01  Building1.floor1  MD    ArubaMC-VA  8.10.0.6_86193  up      UPDATE SUCCESSFUL(Conductor Unreachable)  10                      836        LSR

Total Switches:1

We see that it is in the State up, Configuration State is UPDATE SUCCESSFUL, but the Conductor is Unreachable.
The aruba-ho01 tries to connect directly to the IP address of the mm02. But the mm02 is now only a backup mobility master, it no longer accepts connections from mobility controllers.

Now we fix everything and use the VRRP IP address again, maybe tomorrow I have to take someone else spontaneously on the trip :)
First we change the config in the mobility master.

(aruba-mm01) [mynode] 
conf t
cd aruba-ho01
  conductorip 192.168.81.10 ipsec aruba123 interface vlan 84
Change in the conductorip configuration requires device to reload. Make sure the modified configuration ensures connectivity to the Conductor. Do you want to continue [y/n]: y
write mem

Normally the aruba-ho01 would boot now, but it won't, because it has no connection to our mobility master.

In the next step, we directly fix the aruba-ho01 by enabling the disaster-recovery mode.

(airit-ho01) #disaster-recovery on

*******************************
Entering disaster recovery mode
*******************************
(DR-Mode) [mm] # 

cd mynode
conf t
  conductorip 192.168.81.10 ipsec aruba123 interface vlan 84
Change in the conductorip configuration requires device to reload. Make sure the modified configuration ensures connectivity to the Conductor. Do you want to continue [y/n]: y 
exit
wr mem
disaster-recovery off
(aruba-ho01) #

[SSH] INFO: DISCONNECT

Now the aruba-ho01 boots and connects to the VRRP IP address again.

After booting we can observe it going through different statuses and finally reaching the Configuration State UPDATE SUCCESSFUL.

(aruba-ho01) #show switches

All Switches
------------
IP Address     IPv6 Address  Name        Location          Type  Model       Version         Status  Configuration State  Config Sync Time (sec)  Config ID  Release Type
----------     ------------  ----        --------          ----  -----       -------         ------  -------------------  ----------------------  ---------  ------------
192.168.84.11  None          aruba-ho01  Building1.floor1  MD    ArubaMC-VA  8.10.0.6_86193  up      LAST SNAPSHOT        0                       0          LSR

Total Switches:1
(aruba-ho01) #show switches

All Switches
------------
IP Address     IPv6 Address  Name        Location          Type  Model       Version         Status  Configuration State  Config Sync Time (sec)  Config ID  Release Type
----------     ------------  ----        --------          ----  -----       -------         ------  -------------------  ----------------------  ---------  ------------
192.168.84.11  None          aruba-ho01  Building1.floor1  MD    ArubaMC-VA  8.10.0.6_86193  up      UPDATE REQUIRED      0                       0          LSR

Total Switches:1
(aruba-ho01) #show switches

All Switches
------------
IP Address     IPv6 Address  Name        Location          Type  Model       Version         Status  Configuration State  Config Sync Time (sec)  Config ID  Release Type
----------     ------------  ----        --------          ----  -----       -------         ------  -------------------  ----------------------  ---------  ------------
192.168.84.11  None          aruba-ho01  Building1.floor1  MD    ArubaMC-VA  8.10.0.6_86193  up      CONFIG PROPAGATION   0                       -1         LSR

Total Switches:1

(aruba-ho01) #show switches

All Switches
------------
IP Address     IPv6 Address  Name        Location          Type  Model       Version         Status  Configuration State  Config Sync Time (sec)  Config ID  Release Type
----------     ------------  ----        --------          ----  -----       -------         ------  -------------------  ----------------------  ---------  ------------
192.168.84.11  None          aruba-ho01  Building1.floor1  MD    ArubaMC-VA  8.10.0.6_86193  up      UPDATE SUCCESSFUL    10                      837        LSR

Total Switches:1
(aruba-ho01) # 

On the aruba-mm01 see aruba-ho01 as 6th switch, which is now also in the Configuration State UPDATE SUCCESSFUL.

(aruba-mm01) [mynode] (config) #show switches

All Switches
------------
IP Address     IPv6 Address  Name         Location          Type       Model       Version         Status  Configuration State  Config Sync Time (sec)  Config ID  Release Type
----------     ------------  ----         --------          ----       -----       -------         ------  -------------------  ----------------------  ---------  ------------
192.168.81.11  None          aruba-mm01   Building1.floor1  conductor  ArubaMM-VA  8.10.0.6_86193  up      UPDATE SUCCESSFUL    0                       837        LSR
192.168.81.12  None          aruba-mm02   Building1.floor1  standby    ArubaMM-VA  8.10.0.6_86193  up      UPDATE SUCCESSFUL    10                      837        LSR
192.168.84.12  None          aruba-ho02   Building1.floor1  MD         ArubaMC-VA  8.10.0.6_86193  up      UPDATE SUCCESSFUL    0                       837        LSR
192.168.86.11  None          aruba-dmz01  Building1.floor1  MD         ArubaMC-VA  8.10.0.6_86193  up      UPDATE SUCCESSFUL    0                       837        LSR
192.168.86.12  None          aruba-dmz02  Building1.floor1  MD         ArubaMC-VA  8.10.0.6_86193  up      UPDATE SUCCESSFUL    0                       837        LSR
192.168.84.11  None          aruba-ho01   Building1.floor1  MD         ArubaMC-VA  8.10.0.6_86193  up      UPDATE REQUIRED      0                       -1         LSR

Total Switches:6
(aruba-mm01) [mynode] (config) #show switches

All Switches
------------
IP Address     IPv6 Address  Name         Location          Type       Model       Version         Status  Configuration State  Config Sync Time (sec)  Config ID  Release Type
----------     ------------  ----         --------          ----       -----       -------         ------  -------------------  ----------------------  ---------  ------------
192.168.81.11  None          aruba-mm01   Building1.floor1  conductor  ArubaMM-VA  8.10.0.6_86193  up      UPDATE SUCCESSFUL    0                       837        LSR
192.168.81.12  None          aruba-mm02   Building1.floor1  standby    ArubaMM-VA  8.10.0.6_86193  up      UPDATE SUCCESSFUL    10                      837        LSR
192.168.84.12  None          aruba-ho02   Building1.floor1  MD         ArubaMC-VA  8.10.0.6_86193  up      UPDATE SUCCESSFUL    0                       837        LSR
192.168.86.11  None          aruba-dmz01  Building1.floor1  MD         ArubaMC-VA  8.10.0.6_86193  up      UPDATE SUCCESSFUL    0                       837        LSR
192.168.86.12  None          aruba-dmz02  Building1.floor1  MD         ArubaMC-VA  8.10.0.6_86193  up      UPDATE SUCCESSFUL    0                       837        LSR
192.168.84.11  None          aruba-ho01   Building1.floor1  MD         ArubaMC-VA  8.10.0.6_86193  up      CONFIG PROPAGATION   0                       837        LSR

Total Switches:6
(aruba-mm01) [mynode] (config) #show switches

All Switches
------------
IP Address     IPv6 Address  Name         Location          Type       Model       Version         Status  Configuration State  Config Sync Time (sec)  Config ID  Release Type
----------     ------------  ----         --------          ----       -----       -------         ------  -------------------  ----------------------  ---------  ------------
192.168.81.11  None          aruba-mm01   Building1.floor1  conductor  ArubaMM-VA  8.10.0.6_86193  up      UPDATE SUCCESSFUL    0                       837        LSR
192.168.81.12  None          aruba-mm02   Building1.floor1  standby    ArubaMM-VA  8.10.0.6_86193  up      UPDATE SUCCESSFUL    10                      837        LSR
192.168.84.12  None          aruba-ho02   Building1.floor1  MD         ArubaMC-VA  8.10.0.6_86193  up      UPDATE SUCCESSFUL    0                       837        LSR
192.168.86.11  None          aruba-dmz01  Building1.floor1  MD         ArubaMC-VA  8.10.0.6_86193  up      UPDATE SUCCESSFUL    0                       837        LSR
192.168.86.12  None          aruba-dmz02  Building1.floor1  MD         ArubaMC-VA  8.10.0.6_86193  up      UPDATE SUCCESSFUL    0                       837        LSR
192.168.84.11  None          aruba-ho01   Building1.floor1  MD         ArubaMC-VA  8.10.0.6_86193  up      UPDATE SUCCESSFUL    10                      837        LSR

Total Switches:6

At this point our journey is unfortunately over, I hope it was not too boring :)

In your case the VRRP preemption made sure that the first mobility master became master again in the VRRP instance after the reboot. But while it was booting, the second mobility master was in the master role, only no mobility controller could connect to it. From the mobility controller's point of view, there was no mobility master available at that moment.

Many customers use VRRP preemption because they want a dedicated mobility master to get the master role after booting or software updates. But for the function itself the VRRP preemption is not necessary. You only have to use the VRRP IP as mobility master in the mobility controllers.

------------------------------
Regards,

Waldemar
ACCX # 1377, ACEP, ACA - Network Security
If you find my answer useful, consider giving kudos and/or mark as solution
------------------------------

Original Message:
Sent: May 16, 2023 02:27 PM
From: Peter Kafkas
Subject: What does router pre-emption do and is it required for Aruba

Hello Lord,

Forgive; but but unless I am not understanding you correctly, you are saying that the Mobility Conductors in a layer-2 cluster that have a VRRP do not require Pre-Emption.  I have found that to be untrue.  I needed to enable Pre-Emption in roder for the Mobility Masters (Conductors) to be able to view the local controllers.

My question is why.

I updated other local hardware controllers that also have a cluster configured and Pre-Emption was not required to function and update.

------------------------------
Stavros K

Original Message:
Sent: May 13, 2023 12:19 PM
From: lord
Subject: What does router pre-emption do and is it required for Aruba

Hi Stavros,

Router pre-emption is a feature vim VRRP protocol.

As Herman wrote, the VRRP protocol is often used in active-standby systems. The master from the VRRP instance is active, the backup from the VRRP instance is passive. In L2 conductor-redundancy the mobility conductors check who is VRRP master and who is VRRP backup. This results in the role in the conductor-redundancy context. If the VRRP role changes, then the conductor-redundancy role also changes. With router pre-emption you achieve that the VRRP master becomes the master again after a failure or reboot. 

With L2 conductor-redundancy you can activate pre-emption, but you do not have to. Check which IP is configured as conductor IP on the mobiliti controllers, the VRRP IP or the IP of the primary mobility conductor. If you configured IP from primary mobility conductor, but it is currently VRRP backup and therefore conductor-redundancy backup - mobility controllers will not be able to tunnel to it.

VRRP protocol is implemented in controller OS, it doesn't matter if you are using hardware controller or VM, in both variants controllers behave the same.

If your mobility controllers are configured in the cluster, VRRP is not required for operation. If you use COA, VRRPs must also be configured, but this is a special case.

If you use a VRRP instance on the mobility controllers for L3 controller discovery, you can enable pre-emption if you want the IP to always connect to the same controller for L3 discovery.

------------------------------
Regards,

Waldemar
ACCX # 1377, ACEP, ACA - Network Security
If you find my answer useful, consider giving kudos and/or mark as solution

Original Message:
Sent: May 12, 2023 02:54 PM
From: StavrosK
Subject: What does router pre-emption do and is it required for Aruba

thanks yout response answered the 1st ofmy 3 questions.

I have 3 questions.

1).  What benefits does having router pre-emption bring for the Mobility masters?   

2).  Does anyone know why it is necessary to have router pre-emption on the Mobility Masters at least for version 8.7?

3).  Is router pre-emption needed for the hardware controllers as well?

------------------------------
Stavros K

Original Message:
Sent: May 12, 2023 09:04 AM
From: Herman Robers
Subject: What does router pre-emption do and is it required for Aruba

Router pre-emption is something that is used in many active-standby systems. If you have a redundancy system, in case of a failure you can move the shared IP address/Virtual IP to the other node/controller to make that one active. Then when the original system returns you basically have two choices: leave everything as it is, or move the Virtual IP back to the system that was holding the IP in the first place. Benefit of moving back is that you know that if there are no special conditions, it's always the same node that is active. Drawbacks are that moving back may introduce a brief interruption while the IP transfers over, and the risk that if the same problem triggers again on the 'primary node' that you will get in an bounce up-down situation where the primary node stops, secondary takes over, primary returns and becomes active, stops again, secondary takes over, and so on. For the mobility conductor, it's not only the IP that moves over, but it's also the software function. A secondary MCR sits there and becomes active only when the primary fails, so that means that where the IP lives must correspond to where the software is running. For many routers it does not really matter as each node is active (and supposed to have the same configuration). Same applies for controllers.

Hope that asnwers your 3 questions.

------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.

In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.

Original Message:
Sent: May 12, 2023 06:30 AM
From: StavrosK
Subject: What does router pre-emption do and is it required for Aruba

I originally designed the Aruba Controllers to have a High Availability (H.A.) Cluster for the Mobility Masters and then again for the Managed Devices (Local Hardware Controllers).   The local Controllers are managed by the MM and each office has 2 local controllers.

I did not setup router pre-emption on the Mobility Masters or the local controllers; but now since I am updating the version of the MM I learned that router pre-emption was required for the Mobility master. Otherwise both MM's were not able to out as the 'stand-by mode and not able to communicate with the local controllers.   After I set the router pre-emption and made 1 MM a priority over the other Mobility master then the MM's were able to see the local controllers as I would expect them to.

I have 3 questions.

1).  What benefits does having router pre-emption bring for the Mobility masters?   

2).  Does anyone know why it is necessary to have router pre-emption on the Mobility Masters at least for version 8.7?

3).  Is router pre-emption needed for the hardware controllers as well?

I was told by Aruba Support that it is not required for the local controllers; but, I will be updating the local controllers in the middle of the night and I would prefer not to have any surprises.  I am planning on updating 2 controllers that are not used in production yet, so I will see what will happen to those controllers; but, I do want to discuss the 3 questions above.

------------------------------
Stavros K
------------------------------

As I tried to explain earlier, for MM/MCR the application is active-standby, which means that the active VRRP IP must be on the node where the application is active.
The hardware controllers that you used are probably active-active, in which case it does not matter where the VRRP IP is active.

------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.

In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.
------------------------------

Original Message:
Sent: May 16, 2023 02:27 PM
From: StavrosK
Subject: What does router pre-emption do and is it required for Aruba

Hello Lord,

Forgive; but but unless I am not understanding you correctly, you are saying that the Mobility Conductors in a layer-2 cluster that have a VRRP do not require Pre-Emption.  I have found that to be untrue.  I needed to enable Pre-Emption in roder for the Mobility Masters (Conductors) to be able to view the local controllers.

My question is why.

I updated other local hardware controllers that also have a cluster configured and Pre-Emption was not required to function and update.

------------------------------
Stavros K

Original Message:
Sent: May 13, 2023 12:19 PM
From: lord
Subject: What does router pre-emption do and is it required for Aruba

Hi Stavros,

Router pre-emption is a feature vim VRRP protocol.

As Herman wrote, the VRRP protocol is often used in active-standby systems. The master from the VRRP instance is active, the backup from the VRRP instance is passive. In L2 conductor-redundancy the mobility conductors check who is VRRP master and who is VRRP backup. This results in the role in the conductor-redundancy context. If the VRRP role changes, then the conductor-redundancy role also changes. With router pre-emption you achieve that the VRRP master becomes the master again after a failure or reboot. 

With L2 conductor-redundancy you can activate pre-emption, but you do not have to. Check which IP is configured as conductor IP on the mobiliti controllers, the VRRP IP or the IP of the primary mobility conductor. If you configured IP from primary mobility conductor, but it is currently VRRP backup and therefore conductor-redundancy backup - mobility controllers will not be able to tunnel to it.

VRRP protocol is implemented in controller OS, it doesn't matter if you are using hardware controller or VM, in both variants controllers behave the same.

If your mobility controllers are configured in the cluster, VRRP is not required for operation. If you use COA, VRRPs must also be configured, but this is a special case.

If you use a VRRP instance on the mobility controllers for L3 controller discovery, you can enable pre-emption if you want the IP to always connect to the same controller for L3 discovery.

------------------------------
Regards,

Waldemar
ACCX # 1377, ACEP, ACA - Network Security
If you find my answer useful, consider giving kudos and/or mark as solution

Original Message:
Sent: May 12, 2023 02:54 PM
From: StavrosK
Subject: What does router pre-emption do and is it required for Aruba

thanks yout response answered the 1st ofmy 3 questions.

I have 3 questions.

1).  What benefits does having router pre-emption bring for the Mobility masters?   

2).  Does anyone know why it is necessary to have router pre-emption on the Mobility Masters at least for version 8.7?

3).  Is router pre-emption needed for the hardware controllers as well?

------------------------------
Stavros K

Original Message:
Sent: May 12, 2023 09:04 AM
From: Herman Robers
Subject: What does router pre-emption do and is it required for Aruba

Router pre-emption is something that is used in many active-standby systems. If you have a redundancy system, in case of a failure you can move the shared IP address/Virtual IP to the other node/controller to make that one active. Then when the original system returns you basically have two choices: leave everything as it is, or move the Virtual IP back to the system that was holding the IP in the first place. Benefit of moving back is that you know that if there are no special conditions, it's always the same node that is active. Drawbacks are that moving back may introduce a brief interruption while the IP transfers over, and the risk that if the same problem triggers again on the 'primary node' that you will get in an bounce up-down situation where the primary node stops, secondary takes over, primary returns and becomes active, stops again, secondary takes over, and so on. For the mobility conductor, it's not only the IP that moves over, but it's also the software function. A secondary MCR sits there and becomes active only when the primary fails, so that means that where the IP lives must correspond to where the software is running. For many routers it does not really matter as each node is active (and supposed to have the same configuration). Same applies for controllers.

Hope that asnwers your 3 questions.

------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.

In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.

Original Message:
Sent: May 12, 2023 06:30 AM
From: StavrosK
Subject: What does router pre-emption do and is it required for Aruba

I originally designed the Aruba Controllers to have a High Availability (H.A.) Cluster for the Mobility Masters and then again for the Managed Devices (Local Hardware Controllers).   The local Controllers are managed by the MM and each office has 2 local controllers.

I did not setup router pre-emption on the Mobility Masters or the local controllers; but now since I am updating the version of the MM I learned that router pre-emption was required for the Mobility master. Otherwise both MM's were not able to out as the 'stand-by mode and not able to communicate with the local controllers.   After I set the router pre-emption and made 1 MM a priority over the other Mobility master then the MM's were able to see the local controllers as I would expect them to.

I have 3 questions.

1).  What benefits does having router pre-emption bring for the Mobility masters?   

2).  Does anyone know why it is necessary to have router pre-emption on the Mobility Masters at least for version 8.7?

3).  Is router pre-emption needed for the hardware controllers as well?

I was told by Aruba Support that it is not required for the local controllers; but, I will be updating the local controllers in the middle of the night and I would prefer not to have any surprises.  I am planning on updating 2 controllers that are not used in production yet, so I will see what will happen to those controllers; but, I do want to discuss the 3 questions above.

------------------------------
Stavros K
------------------------------