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?
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.
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?
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
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.
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.
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.
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?
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
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?
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
and look for messages that can be related to the issue.
Hope to help
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.
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...
1- Yes u are correct, I beleive he should apply (Path MTU Discovery) in order to prevent any Packet fragmentation which could cause a High latency an inconssistency performance.
2- If the Tunnel dies, then a possible cause would be a ( Recursive Tunneling ) issue. Make sure the Tunnel Source is not the same as the Tunnel destination.
Pls Have a look at the bellow link, If u search google u will also get the same: