Wireless Access

Hello All

I've been running my environment using VRRP Active/Standby MM Architecture and now on the 8.2 release there is an option to use Layer-3 Redundancy so I want to test this scenario moving my standby MM to a different location. can someone guide me how can I change the implementation smoothly ? 

Thanks,

Antonio

I would just shut it down, wipe it, reconfigure from startup as the new L3 device in the new location. No sense in making it difficult tryingto change IPs, and not lose anything when the config will be pushed over anyway. 

Thank you for the quick answer. I will shut down my standby MM VM and re-create the new one of my different DC for Layer 3 testing for the propose of validation before I abandoned the Layer-2 VRRP design

Please let us know how the experiment goes.

I’ve just completed the migration following this process

1) Don't remove the VRRP con figuration so all MD will still be pointing to the VRRP ip and you will be able to configure them

2) Shutdown the backup MM VM

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

4) Push L3. redundancy Config to all MD from my MM master

   (MM01) ^[mynode] (config) #secondary masterip 10.30.40.123 ipsec aruba123

5) Remove the VRRP configuration from MM master

6) Power-off MM master VM

After 15 minutes all my MD were pointing to the backup MM except the MD connected through my VPNC cluster so basically the command pushed on the step # 4 also included my VPN branches controller so all of them took the secondary MM IP as secondary master controller instead of  a secondary VPNC cluster so none of them where able to create an IPSec tunnel.

After awhile, I've recovered all of them powering up my MM Master again

I've removed this configuration for the VPN Branch to test it again.

Thanks,

Antonio

If ok highjacking this thread.

We are in the process of standing up mobility masters using 8.2. Since we have L2 between our datacenters we were planning on using VRRP between the active and standby MM.

Other than not having to deal with L2 between datacenters are there any advantages to going to L3? Since we are still in pre-production should we re-configure for L3?

I'll preface by saying that I'm a network engineer so I think routing first, and then slowly remember switching ;)

L2 with VRRP seems easy, but is it giving you any other benefit?

L3 should provide the same redundnacy, but gives you more flexibility - you can move the L3-peers to another location and not have to worry about maintaining long-distance L2 fabrics - for instance we are contemplating disaster recovery in a cloud provider's IAAS offering and won't be able to maintain L2 to systems which get moved there in an emergency.

Note that L3 MM redundancy is Active/Standby and if the Active goes down, while the controllers have IPSec to both MMs, the controllers will pin up their tunnel to the standby only after 15min. Then, upon that occurring, the standby MM is ONLY there to service the MM features. There will not be any configuration abaility (ability to manage configurations of the MCs) *unless* you manually promote the Standby MM to Primary. This is to prevent split brain issues and you would only promote the standby if you know the primary MM is down for good or for awhile. 

Hi Jerrod. Thanks for the response.

Making sure I understand this correctly, L3 redundancy has a 15 minute timer before the MDs fail over to the standby. In addition, you can not push configurations using the standby.

My next question then, is this the same behavior when using L2 redundancy and VRRP?

Back to my tests. In other to migrate from Layer2 to Layer3 there are another important steps to consider if you have VPNC clusters to terminate MD.

In my case, I have 2 VPNC in a cluster so I have to update the following:

1) Update both VPNC controllers configuration

masterip x.x.x.x ipsec ****** peer-mac-1 00:xx:xx:xx:xx:x peer-mac-2 00:xx:xx:xx:xx:xx interface vlan 1

2) Update, all MD connected to the VPNC Clusters to point to the new MM master

masterip x.x.x.x vpn-ip x.x.x.x ipsec-factory-cert vpn-mac-1 00:xx:xx:xx:xx:18 vpn-mac-2 00:xx:xx:xx:xx:f8 interface vlan 4094

Due all MD won't be disconnected from the MM, I had to access to each controller and make the change using the disaster recovery feature.

I will test again the entire migration 

Thanks

For L2 VRRP, that is not the case, the Primary Fails and the Backup will take over immediately with full config.

When you say the backup mobility master (L3 backup) will only manage MM features unless you promote it I assume "features" includes licensing, client match, rf mangement, etc.  Can you confirm?  Is there a list of features and exclusions documented anywhere?

Hi,

It terms of licensing, if i have L3-redundency configured between a Primary MM and Secondary MM, do I apply all the AP, PEF ..etc licenses to the Primary MM?

In L3 setup do i still have to apply a Aruba MM-VA-X Mob Mstr license to the standby MM, or do i apply Aruba MM-VA-x Mob Mstr licenses to the primary and let the standby MM fetch the Aruba MM-VA-500 Mob Mstr  license from the primary.

Lets assume I started with MM1 are primary L3 MM and MM2 as backup L3 MM.

so if I promoted the standby L3 MM (MM2) to primary manually and after some time the previous primary MM (MM1) came up again, I'll end up with two primary mobility master in my network.

1- will MCs point to previous primary MM (MM1) automatically? as it is still configured as primary MM in MCs.

2- what if I did changes on the other MM (MM2)? they are not synced to MM1. Will they be lost? 

This thread is 2.5 years old.  Please open a new thread