Wireless Access

Dear All,

We are trying to build the GRE tunnel between our Master controller 7240 (version 6.4.2.0) and Guest controller 7010 (6.4.1.0). both controllers are in different vlans.

Tunnel is not coming up and showing as below

Tunnel 1 is up line protocol is down
Description: Tunnel Interface
Internet address is X.X.X.X 255.255.255.255
Source Y.Y.Y.Y
Destination X.X.X.X
Tunnel mtu is set to 1100
Tunnel is an IP GRE TUNNEL
Tunnel is Trusted
Inter Tunnel Flooding is enabled
Tunnel keepalive is enabled
Tunnel keepalive interval is 10 seconds, retries 3
Heartbeats sent 177, Heartbeats lost 177
Tunnel is down 0 times

We have allowed the IP 47, IPsec (UDP ports 500 and 4500) and ESP (protocol 50) in firewall.

show datapath session table

x.x.x.x y.y.y.y  10.107.100.227  47   0     0      0/0  0    0   1   local       7    0          0          FC   

Please let me know how to trouble shoot further. Any debug option is available.

Hi,

It seems, configuration correct,

Try to ping each other, tunnel will come up when there is some traffic go through the tunnel.

Try this,

Please feel free for any further help on this.

We tried this but no luck.

Master controllers are in VRRP. 

I configured like this.

Source:Master VIP --- Tunnel 1 (L3 GRE) ----- Destination: Guest Actual IP

Source: Guest Actual IP--- Tunnel 1 (L3 GRE)----Destination: Master VIP

Whether it is correct..?

Hi,

We can not bring up GRE terminating on a Virtual IP. you have to terminate on the literal IP address.

For your ref :

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

Please feel free for any furhter help on this.

Then should i have to create two tunnels seperately for VRRP members of masters?

If a Master vrrp controller is down  & respective tunnel is down, how redundancy will be achieved?

Moreover i am creating L3 tunnel since both are in diff segments. In the link which you have given talks about L2 tunnel only.

Yes My friend,

You have to establish two separate GRE tunnels with both the controllers ( Master- Standby).

Here is how it works,

As there is  VRRP running between controllers, only VRRP master will send the GRE HB hence guest traffic will go through the GRE terminated on the Master.

To provide failover capabilities between the tunnels and to ensure guest user traffic is directed down only one tunnel (primary),

The guest users will be pointed to the VRRP IP as their default gateway by the DHCP server.

In a failure scenario, VRRP hello’s will timeout due to the loss of the tunnel and the backup Controller ( Standby) will take over the VRRP session/IP, thereby restoring user connectivity.

Therefore Idle deployment solution is, bring up two separate GREs terminating on Master and Standby.

Hope , got clarity on this,

Please feel free for any further help on this.

Thanks for the information.

Here's what i found 

If we enable tunnel keepslive the tunnels go down, if  tunnel keepalive is not congfigured the tunnel will be UP.

if we have not enable tunnel keepalive, then we could eastablish tunnel between Master and DMZ with VIP address.

Interesting :)

Let me know if everything works as expected.

Thanks

Finally we followed standard procedure as you mentioned. 

Disabled keepalives and created two tunnels.

Tunnel 1 on VRRP Master---> Master Phy_ip1 ---- GRE L3---- Guest Phy_ip

Tunnel 2 on VRRP Backup----> Master Phy_ip2---- GRE L3----Guest Phy_ip

Now tunnel is Up.

We have also created tunnel group on Guest controller for redundancy (Not sure... Just did)

Thanks

Another Query: What ports need to be allowed on firewall for GUI access of Aruba controller? I allowed 443 but not working.

do i need to allow 4343 also?

Yes My friend,

Aruba GUI uses port # 4343 over HTTPS.

Please feel free for any furhter query on this.

Any idea why tunnel is going down when keepalive is enabled...? Plz

Thanks :)

Any idea why tunnel is going down when keepalive is enabled...? Plz

Hi ,

It is very simple, when you enable GRE keepalive then GRE will be up on only one condition, when both the devices are able hear the HB then the tunnel will be up otherwise it will be down .

in your case, only guest controller is able to send the HB but it is not able to receive the HB from the DMZ. hence your is down.

When you disable the keepalive the tunnel will come up unconditionally.

Got the answer :)

Please feel free for any further query on this.

So do i need to enable any port in firewall to unblock this..?

I want to enable keepalive for creating Tunnel group. Plz tell me how i can accomplish this..?

 not sure why HB is been reached both the sides.

Hi, 

The work around towards the solution is,

1. Upgrade the Image of  70XX controller to 6.4.2.0 ( same as 72XX controller)

2. Ensure the GRE protocol is not 0 ( Zero)

3. Esure the GRE is not terminating on the VRRP IP.

I don't see any other issues in your configuration.

Please feel free for any further help on this.

We have the following scenario in our environment.  Two DMZ controllers vith a VRRP address.  Two local controllers with a VRRP address as well.  When I use the loopback address on the local controller and vrrp address to the dmz controller, the tunnel comes up fine.  If I use the vrrp address on the local controller, the tunnel goes down.  So vrrp to vrrp doesn't work.  I see that the tunnel does come up for a second and then goes down. We are using L3 tunnels.

Does anyone have any guidelines as to what the proper way of configuring tunnels using the vrrp address?  We would like to use the vrrp on both ends to make the configuration cleaner and failover as well.  Using the vrrp address, you could have just one tunnel on the DMZ controllers and both have the same config.  When you have two controllers at each end and not using the vrrp address, you will need two different tunnels on each controller for redundancy.  How would this work when using L3 tunnels that need a route statement to send the data through the proper tunnel?

I disabled Tunnel Keepalives on both ends of the tunnel and the tunnel came up.  This is using the vrrp address on both ends.