GRE tunnel goes down

[andromeda]

Hello everyone,

I have a setup connecting a fw to a 6504 through 2 wan hops, via static routes, no routing protocols. The GRE is established and both  sides can ping each other tunnel IP interfaces. I also have keep alives configured on 6504 side (5 4).

Here is what happens:

-When I bring down the outside interface of the fw connecting to 1st wan hop, the KA sent by 6504 will eventually stop being received back (normal operation)

-When I bring back up the outside interface of the fw, the KA start being received again (normal operation).

The issue I have is that if I wait a bit longer (>3m from what I see), even after enabling the fw outside interface, the KA won't start working UNLESS I ping the tunnel IP of 6504 from the firewall, basically after putting traffic through the GRE tunnel. 

Could someone please explain this behaviour?

Thanks!

[jpl861]

I cannot fully understand your design but check your firewall if it's hair-pinning the GRE traffic back to the same interface and creating a GRE session. It happened to us multiple times when the outbound interface went down and the firewall created a conduit back to the same interface as it entered.

[andromeda]

Thanks but don't quite get what you say...

The design is pretty simplistic:

FW (outside int)----> WAN RTR1---->WAN RTR2----->6504

                                     GRE tunnel

         ^--------------------------------------------^

[jpl861]

Ah so your GRE tunnel is between 6504 and the firewall?

[jpl861]

Try to check if the GRE session on your FW has cleared out when it was more than 3 mins. I suspect that the keepalives are being evaluated post encapsulation so the real IP of the source and the real IP of the destination needs to be allowed. If you do not have an active GRE conduit/session on your ASA then it might fail. Check your ASA if you are getting any logs pertaining to that source and destination pairs.

[andromeda]

Thanks. The FW is not ASA and has all allowed, no restrictions...

Will the tunnel go down if there is no traffic through it? general GRE question.

[Cristian Matei]

Hi,

    Te problem can be that either the 6k stops sending keepalives after a certain period of time when it was not working (bug, not expected behaviour), or the firewall fails to mirror back the keepalives when it comes back up (most probably bug as well, unless depending on the vendor this is documented as expected behaviour, though i doubt, as GRE keepailves are standard). 

   When you shutdown the link on the FW, enable "debug tunnel keepalive", leave the firewall down for a while, bring it back up, and see if the 6K still sends the keepalives or not, so you know which device is actually faulty.

Regards,

Cristian Matei.

[andromeda]

Thank you Cristian. The FW is not ASA and it doesn't have any debug commands.

Was thinking that teh GRE tunnel will go down if there is no traffic through it, but that snot per design is it?

[andromeda]

To be clear Cristian, yes I do run debug tunnel keepalive on the 6504 and that is how I see the KA being sent and received. But then when I keep the other side FW outside interface disabled for > 3m, even after re-enabling it, the 6504 does SEND KA , however NONE are received anymore and its end (6504) tunnel remains down (per design).

To make it work again, I need to ping the 6504 tunnel IP and then boom, it starts working again.

To me this is an issue with the fw, thoughts?

[Cristian Matei]

Hi,

    1. By default, without tunnel keepalives, a P2P GRE Tunnel stays forever in the UP/UP state, as long as the following conditions are met:

        - tunnel source and tunnel destination configured

        - tunnel source and tunnel destination are of the same type (IPv4 or IPv6) as the tunnel configured underlay via "tunnel mode gre ip" or "tunnel mode gre ipv6"

       - tunnel source is in the UP/UP state

       - there is a route in the RIB for the tunnel destination, specific or default route, so that tunnel destination is routable

   2. When you add GRE tunnel keepalives (which work only in P2P GRE tunnels and by design you can enable it on one-side or both-sides), there is one more condition for the tunnel to stay UP/UP: within the configured keepalive interval and retry count, at least one sent keepalive is mirrored back by the remote side, so it is successful.

As long as you say that GRE traffic is allowed both ways on the firewall, this should work and it just means that there is a bug on the remote end of the GRE tunnel, which stops mirroring GRE keepalives. The 6k constantly sends GRE keepalives, even after the interface goes in the UP/DOWN state, in order to be able to bring it back up when when the remote peer is responsive again.

Regards,

Cristian Matei.