Wireless Access

Reply
Frequent Contributor II

Layer-3 Redundancy for Mobility Master on 8.2

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

Re: Layer-3 Redundancy for Mobility Master on 8.2

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. 

 

Jerrod Howard
Sr. Technical Marketing Engineer
Frequent Contributor II

Re: Layer-3 Redundancy for Mobility Master on 8.2

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

MVP

Re: Layer-3 Redundancy for Mobility Master on 8.2

Please let us know how the experiment goes.

--Matthew

if I've helped, please give kudos
if I've provided a solution, please mark the solution so others can find it
Frequent Contributor II

Re: Layer-3 Redundancy for Mobility Master on 8.2

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

Contributor I

Re: Layer-3 Redundancy for Mobility Master on 8.2

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?

MVP

Re: Layer-3 Redundancy for Mobility Master on 8.2

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.

--Matthew

if I've helped, please give kudos
if I've provided a solution, please mark the solution so others can find it

Re: Layer-3 Redundancy for Mobility Master on 8.2

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. 

Jerrod Howard
Sr. Technical Marketing Engineer
Contributor I

Re: Layer-3 Redundancy for Mobility Master on 8.2

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?

Frequent Contributor II

Re: Layer-3 Redundancy for Mobility Master on 8.2

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

Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: