Wireless Access

Hi,

 

I have a customer on 6.3.1.1 where some of the local controllers have a L2 GRE tunnel setup for the guest traffic, that goes through to the master controller.

 

The setup was typical with the below, and explained in many threads in these forums.

 

Local

Tunnel source - vlan ip

Tunnel destination - master vrrp

 

Master

Tunnel source - vlan ip

Tunnel destination - local controller vlan ip

 

Unfortunately there were many issues with the guest network stopping working from time to time. TAC have said to the customer that this setup is wrong and you cannot set the tunnel destination to be the vrrp address. 

 

I know this is supported since 3.x, so why is TAC saying that it is wrong?  There are so many other examples in here of people doing exactly that above and it works fine on other versions.  Nothing in the UG or release notes says that this is unsupported either.

 

They have also suggested setting up a tunnel to the master-backup as well, in case of failover, which makes no sense to me since there will be two active tunnels for the same vlan.

 

rant over.

 

:smileywink:

 

 

We've got quite a few large (65K+ guest) deployments running with a similar challenge, and we've had to utilize GRE tunnel groups to accomplish this feat, (as VRRP cannot be GRE endpoint).    In fact, I believe this is the exact reason why GRE tunnel redundancy (GRE tunnel groups) were added to the AOS firmware in 6.3.x

 

  (The other option is GRE through an Load Balancer such as F5 LTM, with primary/failover endpoint definition to avoid scattering data).

 

 

This has been an issue for as long as I'm aware:

 

http://community.arubanetworks.com/t5/Unified-Wired-Wireless-Access/VRRP-IP-cannot-be-L2-GRE-tunnel-endpoint/td-p/33572

 

The issue is related to heartbeats that will only be sourced from the physical address, not from VRRP address, thus need to tunnel endpoints to be physical IP addresses.

 

This is not an Aruba only issue, it's related to the VRRP specifications.   JunOS / Vyatta / and others have same restrictions.   Use of the GRE tunnel groups overcomes the limitations, and the "control" can be from the GRE Tunnel initiator.

 

So if you have an internal controller doing GRE to a pair of DMZ/Guest controllers, the control of tunnel priority is on the inside, vs the outside if relying on VRRP. 

 

This is the way this works:

 

 

Local

Tunnel source - vlan ip

Tunnel destination - master vrrp

 

Master

Tunnel source - VRRP IP

Tunnel destination - local controller vlan ip

Ok, TAC are saying that you can't use the vrrp that is used for master-redundancy, but rather need to use a different one that is on another vlan.

 

Tunnel-groups does sound interesting, but that seems to only be for L3 tunnels.

 

---

@cjoseph wrote:

This is the way this works:

 

 

Local

Tunnel source - vlan ip

Tunnel destination - master vrrp

 

Master

Tunnel source - VRRP IP

Tunnel destination - local controller vlan ip

---

Unfortunately, I'm getting conflicting ideas how to do this.  Like what you've said here, http://community.arubanetworks.com/t5/Unified-Wired-Wireless-Access/VRRP-IP-cannot-be-L2-GRE-tunnel-endpoint/m-p/33799/highlight/true#M8323

 

and here also is what someone else did to get it working, http://community.arubanetworks.com/t5/Unified-Wired-Wireless-Access/Terminating-GRE-tunnels-on-VRRP/m-p/40126/highlight/true#M9238

 

For now, it terminates on the vlan ip and hence no failover capability.

---

@Michael_Clarke wrote:

Ok, TAC are saying that you can't use the vrrp that is used for master-redundancy, but rather need to use a different one that is on another vlan.

 

Hi Michael,

 

I would be keen to hear how you go with this. I am facing a design scenario where there will be a Active/Passive Master pair (that also terminate APs) and a DMZ controller acting as a Guest anchor.

 

Therefore my L2GRE tunnel would idealy be sourced from a VRRP address on the master pair, and terminated on the physcial address on the DMZ controller.

 

Chris

 

 

Michael_Clarke,

It only works if it works for you. You at least have multiple avenues to try. The behavior has changed over time. What I posted in this thread was the last thing I did to get it to work. Please let us know what works for you.

That's unfortunate.  I can't have a feature setup that works for one customer, but doesn't for the next, or works one day, then breaks the next after an upgrade.

 

Nevertheless, if we manage to get it sorted, I will post back what we did.

 

:smileyhappy:

---

@cjoseph wrote:
Michael_Clarke,

It only works if it works for you. You at least have multiple avenues to try. The behavior has changed over time. What I posted in this thread was the last thing I did to get it to work. Please let us know what works for you.

---

Had an Aruba SE with me looking at this with the customer.  We tested with a lab controller and got it to work with the following.

 

New vrrp (same vlan as master-vrrp)

 

Local Controller

 

Interface tunnel x

Tunnel source a.b.c.d

Tunnel destination <vrrp-ip>

Tunnel keepalive

no inter-tunnel-flooding

 

Master Controller

 

Interface tunnel x

Tunnel source <vrrp-ip>

Tunnel destination a.b.c.d

Tunnel keepalive

No inter-tunnel-flooding

 

We would prefer to have the vrrp on a different vlan from the master-vrrp (suggested by TAC), but that involves various other changes on the network so haven't tried that for now.