Wireless Access

last person joined: yesterday 

Access network design for branch, remote, outdoor, and campus locations with HPE Aruba Networking access points and mobility controllers.
Expand all | Collapse all

Aruba MM and VMC Redundancy

This thread has been viewed 8 times
  • 1.  Aruba MM and VMC Redundancy

    Posted Jan 16, 2018 08:15 PM

    I'm trying to figure out, reading the documentation, how to setup redundacncy for the MM and VMC. I was told that I don't need to setup VRRP for both. Essentially, we have a MM and VMC in one DC and another MM and VMC in another. We want to put the MM in a group and the VMC's in a group via L3 (not l2 or VRRP...we can if needed, but dont' want to). There appears to be "clusters", "redundancy" options, but documentation doesn't go into detail as far as what's what. 


    Any help would be appreciated. Thanks.



  • 2.  RE: Aruba MM and VMC Redundancy

    EMPLOYEE
    Posted Jan 16, 2018 08:51 PM

    You could cluster the VMCs but with the MMs I believe one would have to be a backup basically in standby mode. 

     

    What are you trying to accomplish?

    What code version are you using?

     

    Here is the Documentation Suite for 8.2



  • 3.  RE: Aruba MM and VMC Redundancy

    EMPLOYEE
    Posted Jan 16, 2018 09:04 PM

    From the 8.2 User Guide

     ______________________________________

    Configuring Layer-3 Redundancy For MM

     

    The Layer-3 redundancy feature will support Active-Standby Model. The Layer-3 redundancy role is driven by user configuration at both the primary and secondary Mobility Master. Once the systems are setup for Layer-3 redundancy, the switchover event will take place when the primary Mobility Master goes down. The secondary Mobility Master will provide the Mobility Master functionality without any user intervention. Layer-3 redundancy determines if the user can make configuration changes and if the sync will be initiated. Managed devices will have the management tunnel with only one Mobility Master at any given time. The managed device will try to connect to the secondary Mobility Master if it looses connectivity with the primary Mobility Master. The secondary Mobility Master will accept the management tunnel connections from a managed device only if its tunnel with primary Mobility Master is down. This will ensure that the Layer-3 switchover event is processed only if the primary Mobility Master is down and not due to flaky connectivity between the managed device and primary Mobility Master.

     

    Listed below are the salient features of Layer-3 Redundancy:

    • Configuration and database events are synced automatically from the primary to secondary Mobility Master.
    • Managed devices detect a failure in the primaryMobility Master and automatically switch to the secondary Mobility Master.
    • The switchover event in the managed device will have minimal service impact if any.
    • Centralized licensing, a single license for both primary and secondary Mobility Masters.
    • Layer-2 and Layer-3 redundancy will work together.
    • When the primary Mobility Master comes back

    Configuration changes cannot be made on the secondary Mobility Master. In a scenario where the primary Mobility Master is down and configuration changes need to be made on the secondary Mobility Master the user must change the sync state of the secondary Mobility Master to the primary Mobility Master. To preserve these configuration changes, a Layer-3 synchronization between the new primary Mobility Master and the old primary Mobility Master should take place. For the synchronization to take place the sync state of the old primary Mobility Master should be changed from primary to secondary state. When the L3 sync state of a Mobility Master is changed from primary to secondary, the Mobility Master reboots to ensure a proper cleanup of the Mobility Master before new configurations/data is pushed from the new primary Mobility Master. Once the roles of Mobility Masters are reversed, the user should ensure the managed devices point to the correct primary Mobility Master and secondary Mobility Master by changing the respective master IP address addresses. The change of master IP and secondary master IP adrdress that takes place on the primary Mobility Master from the managed device node should be done in the same write memory cycle. If this procedure is not done in same write memory cycle, the managed devices may point to the same IP as their primary and secondary Mobility Masters. If this happens reconfiguring the correct secondary masterip when the managed devices are up will fix the issue.



  • 4.  RE: Aruba MM and VMC Redundancy

    Posted Jan 16, 2018 09:19 PM

    Thanks for hte response. So, what I'm trying to do is Active/Standby between the MM and VMC. We have license for one each in our Primary site. I want to setup a standby of each at our DR site for failover. I was told that this was possible for each using L3. I think more than anything, I'm having trouble with the documentation. It uses terminology of the MM and "controller" interchangably and confusing me on what setting to use for the VMCs and which for hte MM's and exaclty how to set them up. 


    Right now I have the VMC setup for a cluster, and hte MM setup in the "Redundancy" settings. I'm thinking now I need to setup both in the "Redundancy" settings/portion of the configurations. But the documentation doesn't say how to add another to the redundancy? Or do we just setup the same configs on each device and configs aren't pushed to the standby...configs are manual and devices just there for failover? Not sure what to expect from the configs. 



  • 5.  RE: Aruba MM and VMC Redundancy

    EMPLOYEE
    Posted Jan 16, 2018 09:28 PM

    From the 8.2 User Guide

     

    Configuring Layer-3 Redundancy The Layer-3 redundancy feature will support Active-Standby Model. The Layer-3 redundancy role is driven by user configuration at both the primary and secondary Mobility Master. Once the systems are setup for Layer-3 redundancy, the switchover event will take place when the primary Mobility Master goes down. The secondary Mobility Master will provide the Mobility Master functionality without any user intervention. Layer-3 redundancy determines if the user can make configuration changes and if the sync will be initiated.

    Managed devices will have the management tunnel with only one Mobility Master at any given time. The managed device will try to connect to the secondary Mobility Master if it looses connectivity with the primary Mobility Master. The secondary Mobility Master will accept the management tunnel connections from a managed device only if its tunnel with primary Mobility Master is down. This will ensure that the Layer-3 switchover event is processed only if the primary Mobility Master is down and not due to flaky connectivity between the managed device and primary Mobility Master.

     

    Listed below are the salient features of Layer-3 Redundancy:

    • Configuration and database events are synced automatically from the primary to secondary Mobility Master.
    • Managed devices detect a failure in the primary Mobility Master and automatically switch to the secondary Mobility Master.
    • The switchover event in the managed device will have minimal service impact if any.
    • Centralized licensing, a single license for both primary and secondary Mobility Masters.
    • Layer-2 and Layer-3 redundancy will work together.
    • When the primary Mobility Master comes back

    Configuration changes cannot be made on the secondary Mobility Master. In a scenario where the primary Mobility Master is down and configuration changes need to be made on the secondary Mobility Master the user must change the sync state of the secondary Mobility Master to the primary Mobility Master. To preserve these configuration changes, a Layer-3 synchronization between the new primary Mobility Master and the old primary Mobility Master should take place. For the synchronization to take place the sync state of the old primary Mobility Master should be changed from primary to secondary state. When the L3 sync state of a Mobility Master is changed from primary to secondary, the Mobility Master reboots to ensure a proper cleanup of the Mobility Master before new configurations/data is pushed from the new primary Mobility Master. Once the roles of Mobility Masters are reversed, the user should ensure the managed devices point to the correct primary Mobility Master and secondary Mobility Master by changing the respective master IP address addresses. The change of master IP and secondary master IP adrdress that takes place on the primary Mobility Master from the managed device node should be done in the same write memory cycle. If this procedure is not done in same write memory cycle, the managed devices may point to the same IP as their primary and secondary Mobility Masters. If this happens reconfiguring the correct secondary masterip when the managed devices are up will fix the issue.

     

     

     



  • 6.  RE: Aruba MM and VMC Redundancy

    Posted Jan 17, 2018 01:15 PM

    So, did some researching online, and found the following commands from the thread below it:

     

    3) Apply L3-Configuration

    Example: DC1 MM Config

    #DC1 MM: L3 Redundancy Configuration
    no paging
    configure terminal
    cd mynode
    master-l3redundancy
    l3-sync-state primary
    l3-sync-time 2
    l3-peer-ip-address 10.30.156.33 ipsec aruba123
    !
    write memory

    DC2 MM Config

    #DC2 MM: L3 Redundancy Configuration
    no paging
    configure terminal
    cd mynode
    master-l3redundancy
    l3-sync-state secondary
    l3-sync-time 2
    l3-peer-ip-address 10.30.40.123 ipsec aruba123
    !
    write memory

     

    https://community.arubanetworks.com/t5/Wireless-Access/Layer-3-Redundancy-for-Mobility-Master-on-8-2/td-p/310581

     

    After doing the configs in the CLI, I synced the database and the MM's at both sites have the same configs. However, in the GUI, there are no corresponding configs and the documentation doesn't go into the specifics on how to set this up. Anyone have any idea why? Or am I seeing a bug or missing the big picture here? I want to nail HA down so I can put this thing into production and document it, but want to correlate commands in the CLI to the GUI for future reference. 


    Thanks.



  • 7.  RE: Aruba MM and VMC Redundancy

    Posted Jan 17, 2018 04:11 PM

    Sorry, forgot to mention I'm running 8.2.0.2. 


    I think this is a bigger problem than just the subject. I also am not able to find anywhere in the GUI the config to apply the AP-system-profile to the AP-group. However, in the CLI, the commands are there to do so. I can create the profiles and ap-groups, but can't link them/apply them to the ap-group. 



  • 8.  RE: Aruba MM and VMC Redundancy

    Posted Jan 17, 2018 04:22 PM
    Make sure you go to the right-hand side of the GUI / Mobility Master under the login > Admin and click on preferences > Click to show advanced profiles

    This will allow you to see all the profiles the AP-Group > Right-hand side


  • 9.  RE: Aruba MM and VMC Redundancy

    Posted Jan 17, 2018 04:27 PM

    Holy cow man! Nice work! I was going nuts trying to find where to attach the ap-system-profile. Thanks