track shows GRE tunnel flapped but there are no logs for tunnel interfaces going down

[sarah.moh]

Is it possible to have no logs for tunnel flap?

one end of the tunnel is a voice gateway so the logs are overwritten, however the track on that router changed state.

On the other end I can only see the BGP flap logged but nothing about the tunnel itself

the track is configured to an IP SLA icmp-echo with target address/destination address: source address of tunnel/destination address of the tunnel.

that track change of state is the thing that points me that this is a tunnel flap that induced BGP flap not just a BGP flap.

so am I wrong about the tunnel flap? and if not why can't I see logs for it (provided that logging is enabled and there are already logs for other tunnel flaps)

Any help is greatly appreciated :D

[Vasilii Mikhailovskii]

Hello.

If you are running GRE tunnel, there are a couple of reasons when it goes down:

• not valid source (if physical interface goes down);
• destination is not in routing table;
• keepalive didn't go through.

So, if you do not have keepalives configured and destination do not disappear from RIB, tunnel should not flap.

Could you please provide running configuration of the tunnel?

[Richard Burts · Accepted solution]

The original poster did not tell us how the tunnel is configured and without knowing that it is difficult to give really good advice. There are quite a few things that might be in the configuration which would impact tunnel up or down, such as whether tunnel keepalives are configured (they are not enabled by default), or whether the tunnel has encryption on it (like VTI).

But let me offer this observation. The original poster seems to assume that if the source address of the tunnel becomes unreachable that the tunnel should go down. That behavior might be right for point to point serial interfaces but that is not how multipoint interfaces (like Ethernet) work and it frequently is not how tunnel interfaces work. If this is a normal GRE tunnel then the router will keep the tunnel in the up state as long as it believes that it has a route to the tunnel destination. The tunnel source address may not be reachable from the remote peer but that does not necessarily mean that the tunnel will go down.

To say it in a slightly different way - if the IP SLA track changes state and if the BGP records a flap then there was certainly loss of connectivity. But it is not necessarily a reason why the tunnel would have gone down. If it is important that the tunnel go down when there is loss of connectivity then the original poster needs to configure tunnel keepalives on both peers.

HTH

Rick 

[Richard Burts]

I am glad that my explanation and suggestion were helpful. Thank you for using the rating system to mark this question as answered. This will help other readers of the forum to recognize discussions that have helpful information. I hope you will continue to be active in the forum.

HTH

Rick