GRE terminiation at 7600 using loopback as source

[ar]

Hi.

I am terminating GRE vrf-lite on my 7600 and using loopback as source for each client.

I found one problem where 7600 seems to be not forwarding traffic until I delete create the tunnel interface.

Worked fine for a week. Then stopped again. I had to delete,create again tunnel interface.

Any know issue here?

[Kevin P Sheahan]

Hi,

Can you please post config for loopback interface, vrf, and tunnel interface.

Did this stop working during non-business hours or down time where there was little/no traffic traversing the tunnel?

Have you interrogated 'show interface tunnel x' output to see if any errors exist?

Thank you,

Kevin

[ar]

Hi.

Here's the config.

It's basically using an existing vrf to establish GRE for a new VRF (VRF-B) at the PE.

CPE is pure global.

7600 PE:

interface Tunnel2

ip vrf forwarding VRF-B

ip address 10.12.25.25 255.255.255.252

ip tcp adjust-mss 1436

tunnel source Loopback132

tunnel destination 10.12.28.166

tunnel vrf VRF-A

interface Loopback132

ip vrf forwarding VRF-A

ip address 10.12.0.132 255.255.255.255

CE:

interface Tunnel2

ip vrf forwarding VRF-B

ip address 10.12.25.26 255.255.255.252

ip tcp adjust-mss 1436

tunnel source FastEthernet4

tunnel destination 10.12.0.132

interface FastEthernet4

ip address 10.12.28.166 255.255.255.252

Problem occured during start of business hours.

Actually I noticed this also during initial configuration.

Tunnel will go up but can't ping the 2nd hop router after the PE GRE termination.

Delete/create resovled this.

I havent tried chekcing the show inter tunnel since tunnel is up and can ping point-to-point.

Will try the next time I encounter this.

[Kevin P Sheahan]

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

interface Tunn2

keepalive 5 3

!

!CREATE NEW TUNNEL TO FORWARD KEEPALIVES TO GLOBAL VRF

!

int tunn12

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.

Kind Regards,

Kevin

[ar]

Thanks for this Kevin.

Is this the same case with tunnel is up, but I cant ping any next hop router other than the PE/GRE terminiation itself?

Regarding the additional config above;

1. What is this bug to avoid that I need to create static route? what should be the gateway? null0?

2. The static route for 10.12.28.166 over the new tunn12 should be under VRF-A right? Tunnel vrf of tunnel2 is VRF-A.

nterface Tunnel2

ip vrf forwarding VRF-B

ip address 10.12.25.25 255.255.255.252

ip tcp adjust-mss 1436

tunnel source Loopback132

tunnel destination 10.12.28.166

tunnel vrf VRF-A

is there any article explaining this trick on to why we need to forward to GLOBAL?

[Kevin P Sheahan]

Hi Allan,

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.

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

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:

-----------------------------------------------------------------

int tunn2

ip hello-interval eigrp 2 5

ip hold-time eigrp 2 15

-----------------------------------------------------------------

!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...

http://www.pro-bono-publico.de/misc/vrf-aware-gre-tunnel-keepalives/

Kind Regards,

Kevin

[ar]

Hi Kevin.

Yes you understand the issue correctly.

To add with this, sometimes even on brand new start configuration, I wont be able to ping next hop routers until I reconfigure the tunnel.

I wasnt able to try shut/no shut. I'll do it next time I encounter this problem.

Good infor on the links.

I'll check and review this. Will check if will resolve the issue.

I'll update this thread.

Many thanks