I have a large network with thousands of static GRE/IPSec tunnels across an MPLS WAN. I have to tune the EIGRP hello and hold-down timers on the tunnels due to some problems we are having. When I tune these timers, should I take into account the GRE keepalive times at the same time? Is there a relationship or best practice regarding these two sets of timers (EIGRP and GRE keeps) and their relationships to each other?
Keepalives of GRE is independent of Eigrp Hello and Hold down timers.Thus, the traffic sent from the tunnel is black-holed, and it cannot follow alternative paths because the tunnel always stays up.Refer the following URL
I saw your post when it first came out and I thought it was interesting. I have done lots of GRE tunnels with EIGRP as the routing protocol but I did not respond because I do not have much factual data about the relationship between the timers. But I must respond given the two other postings which seem to have mostly missed the point.
There was a weakness in the traditional implementation of GRE tunnels in which the router would mark the tunel as up/up if the router had a viable route to the tunnel destination. And this seems to be what both of the other responses are emphasizing.
Cisco introduced a recent feature of GRE keepalive to specifically address this weakness. With GRE keepalive the router does actually test for end to end connectivity and if the GRE keepalive does fail the router will mark the interface as up/down.
In my implementations I have not chosen to use GRE keepalive because I believe that I get much the same functionality with EIGRP. The EIGRP hellos also test for end to end connectivity and if that connectivity is lost the EIGRP neighbor relationship is lost. And that is usually enough for me.
But if you have reason to use both GRE keepalive and EIGRP hello (keepalive) my opinion is that the EIGRP timers are shorter than the GRE timers by default and if I were going to tune the timers I would keep the EIGRP timers shorter than the GRE timers.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...