GRE tunnel has te be reset after WAN line bounce.

[arvind.kumar]

Hi,

We are facing a strange issue with GRE tunnel. We are using this tunnel from a branch office to Hub office. All other tunnels terminated on Hub router are working fine. Issue with this tunnel is that whenever WAN connection goes down Line protocol on tunnel interface some times comes up and sometimes not (therefore we have to reset the tunnel interface and it comes up). Can anyone suggest if there is any bug or any issue related?

+++++

IOS used on this router : c2900-universalk9-mz.SPA.152-1.T2

Tunnel interface :

interface Tunnel1

description -- IPSec VTI tunnel to VPN Primary

ip address 10.1.0.126 255.255.255.0

ip mtu 1240

ip tcp adjust-mss 1200

delay 30000

tunnel source GigabitEthernet0/1

tunnel mode ipsec ipv4

tunnel destination x.x.x.x

tunnel protection ipsec profile IPSEC-TUNNEL

end

+++++++

Please let me know if more inputs are required?

Regards

Arvind

[Richard Burts]

Arvind

I have seen some situations with tunnels like this which use IPSec to encrypt traffic carried over the tunnel where the tunnel line protocol does not come up and it turned out to be an issue with the crypto negotiation. The next time that it happens try issuing the command clear crypto sa and see if the tunnel line protocol then comes up.

HTH

Rick

[Saurav Lodh]

Please refer to the similiar thread below

https://supportforums.cisco.com/thread/16293

also try and reapply

[Richard Burts]

I appreciate pointing to a thread in which I was a contributor. But that thread is quite old and not such a good reference for this problem. In particular that was for GRE tunnels and crypto maps. And for those tunnels it is sufficient (and necessary) to have a valid route to the destination address. It was not necessary that any traffic actually got to the destination.

The tunnels being discussed here are not using crypto maps but are using tunnel protection profiles, which is a newer and better implementation. The requirement for these tunnels to come to up/up is that the crypto negotiation must have taken place, which requires that packets pass end to end in both directions.

The suggestion of removing the tunnel protection profile and then re-applying it is an interesting and more extreme alternative than my suggestion of using clear crypto sa. Use either one that you may choose.

HTH

Rick

[arvind.kumar]

Hello Burts,

Many thanks for your post. You are right that it comes up after re-applying the protection or clearing crypto map or even doing shut-noshut the tunnel interface. But what we are looking for the reason of doing this. Once after outage is over on WAN line and there is route for destination in the table, why it does not come up automatically? Actually customer is not happy to get it done every time manually whenever there is outage on WAN line. He is looking to a solution where tunnel should re-established itself once outage is over and route is available. Could you help me with this aspect?

Regards

Arvind

[Richard Burts]

Arvind

Each time I have seen this symptom and verified that clear crypto sa would fix the problem we have found that it was caused by a bug in the version of IOS that we were running. An update to a new version of code would fix it.

HTH

Rick

Sent from Cisco Technical Support iPad App