GRE tunnel issue

[vikramfonseca]

Hello team,

I've got a bit of a troublesome issue with the GRE tunnel here, and any help will certainly be appreciated.

I have a GRE tunnel initiating from a Cisco 3845, thro' a Cisco ASA 7.2(4) and terminating on a Cisco 2811.

Thing is, every now and then, the tunnel hangs up and we have to shutdown both ends (interfaces), wait for 5 mins and then bring them back up. This is Cisco's recommendation.

However, this is happening on a more frequent basis and shut , no shut is not a workable option.

Any suggestions on how I can keep the tunnel from hanging up?

Thanks,

[mlitka]

Are keepalives enabled? This will keep the tunnel up and running even when there is no interesting traffic.

[Richard Burts]

Vikram

At the time that the tunnel hangs, can you do an extended ping on each router and in the extended ping specify the ping destination as the tunnel destination address and specify the source of the ping as the tunnel source address? This would help to determine whether there is some IP connectivity issue that may be associated with the problem.

HTH

Rick

[vikramfonseca]

Hi RBurts and Thank You for replying. In fact, I've received so many replies in so short a span of time...it really feels great. Thanks to all you guys out there.

The things is the tunnel is configured as the backup and all the traffic is coming in and going out thro' the primary WAN.

Although the tunnel is used as a backup, it still hangs from time to time. So in either case, if I did run a ping....it would reach the endpoint successfully, thro' the WAN. Also, since this device is in production, I can't disable the WAN and run the tests.

I don't believe keep-alives could be an issue because the keep-alives are sent intervals irrespective of if the tunnel is up or down right?

Thanks,

[mlitka]

Vikram -

I believe what Rick is suggesting is pinging the ip address of the B side of the tunnel interface from the A side using the A side tunnel's IP address as the source. This would determine if IP connectivity is available during this 'outages'.

MTU could definately been an issue was well if you are having problems with application latency. I have seen MTU issues cause major issues with applications like Outlook and RDP in a Windows environment. Basically any application that sets the Don't Fragment bit and sends large packets will have problems if MTU isn't set correctly.

Can you confirm that keepalives are set on the tunnel inteface? If you do a short interface tunnel you will see how keep alives are configured.

[Richard Burts]

What I was suggesting was that routerA do an extended ping to routerB and in the extended ping the destinatino address is the address specified in the tunnel configuration as tunnel destination. Also the extended ping should specify the source address for the ping as the address specified in the tunnel configuration as tunnel source.

If the tunnel is supposed to act as a backup to the WAN I would hope that there is a valid path from the tunnel source to the tunnel destination that does not go accross that WAN. And I did not ask you to take down any links, but suggested that you do this at a time when the tunnel hangs.

The suggestion by Giuseppe that it might be a recursive routing issue is an interesting idea. At the point where the tunnel hangs are there any log messagges on either router that indicate that there is some issue?

Perhaps it would help us get to a solution if you would post the config of the tunnels on both routers, and the associated routing information from both routers.

HTH

Rick

[mlitka]

Rick -

Didn't mean to put words in your mouth. Good point.

[Richard Burts]

Michael

No problem. I appreciate your effort to explain my suggestion. People do frequently help fill in explanations for each other on these forums - and I believe that it generally leads to better discussions and better outcomes.

HTH

Rick

[Mohamed Sobair]

Hello,

The Best Solution for this case is to have (Path MTU discovery) configured On both Tunnel Interfaces.

GRE Tunnel adds 4Byte GRE header To the Original IP Header Packet, So whether manually adjusting the Tunnel MTU besides the Interface MTUs or having (Path MTU Discovery) configured.

HTH

Mohamed

[lamav]

Mo:

Im not sure the MTU is the problem. He claims that the tunnel dies and that the only way to reactivate it is to wait 5 minutes and try.

I would think that an MTU problem would manifest itself as slow data transfer, slow connections to a web-based application, latency in loading a database. etc. Basically, latency, not a dead tunnel.

What do you think?

Victor

[Giuseppe Larosa]

Hello Victor,

I agree with your consideration.

One possible problem could be a wrong routing information that for example advertises the tunnel ip endpoints over the tunnel itself.

This can cause the tunnel to die by resetting the tunnel interfaces all routing information is cleared and this allows for a new start.

ASA in the middle should play no role in this scenario until it is configured to allow GRE traffic between the two endpoints

I would investigate the routing activity over the tunnel to see if something unexpected happens.

Hope to help

Giuseppe

[vikramfonseca]

I'm using a MTU of 1436...which I don't think would be an issue.

It's true that an MTU issue would cause latency and occasionally, a freeze possibly?

[Giuseppe Larosa]

Hello Vikram,

if when the GRE tunnel is up you can perform a LAN to LAN extended ping with size IP=1500 byte and it is successful you haven't MTU problems.

about the MTU size:

if only GRE without any IPSec you are fine

The first test to do is what Rick suggests:

when the tunnel dies verifies if an extended ping using GRE endpoints is successful or unsuccessful.

give also a look at the router log with

sh log

and look for messages that can be related to the issue.

Hope to help

Giuseppe

[vikramfonseca]

Hi Guislar,

When the tunnel is up, I can ping a LAN IP sourcing from the tunnel (initiating) interface. I tried this with 1000 MTU and 1500 MTU and both came clean.

I remember that I was able to ping the tunnel endpoint (sourcing from the initiating end) ONLY...but I couldnt ping the LAN when the tunnel hung up.

A 5 min reset of the tunnel solved this issue.

Thanks,

[vikramfonseca]

And one more thing...keepalives are not enabled on any of the 100 or so tunnels however, it's just this one site that's causing an issue. I checked the IOS versions of 7 sites and they're all the same thus possibly eliminating IOS bugs.

The other sites haven't had an issue till date...

Thanks,