Wireless Access

Reply
Contributor II

Master Redundancy across data centers over GRE tunnel

I had a customer of mine ask me about master redundancy with the masters in two different data centers. I had always been under the impression that the the masters need to be on the same layer 2 domain for the master redundancy model, so my initial thought was that the only way to accomplish redundancy across data centers was with some sort of layer 2 VPN. Then the idea of using a GRE tunnel between the two controllers came to mind.

 

After a few hours a trial and error, I think I finally figured it out. I am posting my solution here for both reference and critique - if you think that there may be some "gotchas" with this, or you can think of a better way to configure it without a layer 2 VPN, please let me know.

 

**I am also interested in what you think about my use of the line "tunnel mode gre 4". As far as I can tell, it didn't matter what protocol number I specified (I tried 1, 4, and 47), as they all worked fine - just as long as I didn't use "tunnel mode gre ip". Should a different protocol number be used? For reference, ICMP is protocol 1, IPv4 is protocol 4, and GRE is protocol 47.**

 

(controller 1)

version 6.4

!

vlan 2
vlan 4
!
interface vlan 2
ip address 192.168.2.2 255.255.255.0
!
interface vlan 4
ip address 192.168.4.2 255.255.255.0
!
ip default-gateway 192.168.2.1
!
controller-ip vlan 2
!

interface tunnel 1
description "Tunnel Interface"
tunnel mode gre 4
tunnel source vlan 2
tunnel destination 192.168.3.2
trusted
tunnel vlan 4
!

vrrp 4
ip address 192.168.4.1
vlan 4
no shutdown
!

master-redundancy
master-vrrp 4
peer-ip-address 192.168.3.2 ipsec aruba123
!

 

(controller 2)

version 6.4

!

vlan 3
vlan 4
!
interface vlan 3
ip address 192.168.3.2 255.255.255.0
!
interface vlan 4
ip address 192.168.4.3 255.255.255.0
!

ip default-gateway 192.168.3.1

!

controller-ip vlan 3

interface tunnel 1

description "Tunnel Interface"
tunnel mode gre 4
tunnel source vlan 3
tunnel destination 192.168.2.2
trusted
tunnel vlan 4
!
vrrp 4
ip address 192.168.4.1
vlan 4
no shutdown
!

master-redundancy
master-vrrp 4
peer-ip-address 192.168.2.2 ipsec aruba123
!

 

 

How to handle routing:

IMHO the cleanest way to handle routing is to configure a static route to your tunnel VLAN at both of your default gateway's pointing to each controller's IP address, and redistribute those static routes into your dynamic routing.

 

In the above case, we would implement and redistribute the following static routes:
(on 192.168.2.1) ip route 192.168.4.1 255.255.255.0 192.168.2.2
(on 192.168.3.1) ip route 192.168.4.1 255.255.255.0 192.168.3.2

 

You can even get fancy and do some sort of tracking to decide which route to install into global routing table.

 

The alternative is that you run OSPF on your controllers, but this introduces some complications.

 

First, the two controllers must exist in the same OSPF area. This is because it is a violation of OSPF rules to have traffic leak between two areas without first transitting through area 0.

 

Second, you have to be careful to configure OSPF so that you don't accidentally start routing any traffic through the tunnel.

Tim Haynie, ACMX #508, ACDX #384, ACCP, CWSP, CWAP, CWDP, CCNP R/S, CCNP Wireless, CCNA Security, CCDA
MVP

Re: Master Redundancy across data centers over GRE tunnel

We're just moving from No-Data-Center to One-Data-Center this year, but we're planning a second data-center shortly, so I'm watching this conversation with interest.

--Matthew

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

Re: Master Redundancy across data centers over GRE tunnel

I keep getting this question from my customers, but no one wants to deal with the routing issues that are introduced with the GRE tunnel workaround. Thus, I've added a feature request on the Ideas Portal to remove VRRP as a requirement for Master Redundancy.

 

https://arubanetworkskb.secure.force.com/prm/ideas/viewIdea.apexp?id=08733000000PTwr

 

Please promote this idea on that portal if you would find this feature useful.

Tim Haynie, ACMX #508, ACDX #384, ACCP, CWSP, CWAP, CWDP, CCNP R/S, CCNP Wireless, CCNA Security, CCDA
Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: