Thank you for the configs. I suspect the problem to be caused by tunnel traffic not being heavy enough at times and the tunnel dies. You could try to send keepalives through the tunnel to keep it up even during 'down' time. This is a little tricky when using VRFs...
!ADD KEEPALIVE TO EXISTING TUNNEL
keepalive 5 3
!CREATE NEW TUNNEL TO FORWARD KEEPALIVES TO GLOBAL VRF
ip unnumbered lo123
tunn source lo123
tunn dest 10.12.0.132
!ADD STATIC ROUTE TO AVOID KNOWN BUG
ip route 10.12.25.24 255.255.255.252
!ADD STATIC ROUTE FOR DISTANT END DEST TO GO OVER NEW TUNN12
ip route vrf VRF-B 10.12.28.166 255.255.255.255 tunn12
Please update on whether this works well for you. This will have to be additionally setup on the other end in order for it to function properly.
Re: GRE terminiation at 7600 using loopback as source
Let me make sure that I understand your problem correctly. When your tunnel is first created it functions properly for some time period (varies) and then it randomly stops functioning. When this happens the tunnel is still up/up but you cannot ping anything but the distant end tunnel interface. So you delete and re-create the tunnel and it comes back up again to work fine for another small time period. Is this correct?
If the above is correct than I think your tunnel may be 'dying' when traffic stalls. In that case the information below may help to resolve your issue. I also have another quick question.. Does flapping the tunnel interface (shut -- no shut) bring the tunnel back up as well or do you absolutely have to delete it and re-create it for traffic to pass again?
I'm not sure of a bug ID or even if it is classified as a bug. Basically, even when the keepalive is sent on the tunnel interface in a specific vrf when the receiver gets the keepalive they attempt to respond with information from the global table. This response will not reach the original sender as they expect it and therefore will be ignored. The following link calls the static route a 'leaking static route' because once the receiver gets the keepalive they'll hopefully respond on the VRF instead of responding on the global table. The static route that I have mistyped in the previous post should have read: ip route 10.12.25.24 255.255.255.252 tunn2.
Tunnel 12 is a NEW tunnel that you do not currently have, sorry for the confusion I should've named it something else that doesn't so closely resemble 'Tunnel2'. Basically, you create Tunnel12 and do not specify a vrf so that it will use the global table to send the keepalive.
If this method does not work well for you, you can utilize a dynamic routing protocol with altered hello-intervals to keep the tunnel busy. Such as:
!This assumes that you have configured EIGRP (Autonomous-System 2) in your VRF
This does not act in the same way as a keepalive in regards to wanting to respond via the global table, so it may be simpler to implement. I would just make sure to document in the description of the tunnel interface the reason for which EIGRP is running and the timers are so aggresive... this way another administrator doesn't remove or alter your configuration for another reason.
This article is pretty vague on the reasoning but shows a sound configuration of what I am talking about...
DocumentationCode download linksGoalRequirementLimitationsSupported ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in HA
DocumentationCode download linksGoalRequirementLimitationsSupported ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and UCS-E Blades:Step by Step ConfigurationCo...
I am currently unable to specify "crypto keyring" command when configuring VPN connection on my cisco 2901 router.
The following licenses have been activated on my router :