Building network automation solutions

9 module online course

Start now!

Category: EIGRP

GRE Keepalives or EIGRP Hellos?

It looks like everyone who’s not using DMVPN is running IPSec over GRE these days, resulting in interesting questions like »should IP use EIGRP hellos or GRE keepalives to detect path loss?«

Any dedicated link/path loss detection protocol should be preferred over tweaking routing protocol timers (at least in theory), so the politically correct answer is »use GRE keepalives and keep EIGRP hellos at their default values«.

Update 2020-12-29: In the meantime Cisco IOS started supporting BFD over GRE tunnels, making this argument moot. Please use BFD instead of a hodgepodge of point technologies.
read more see 2 comments

EIGRP load and reliability metrics

Everyone studying the EIGRP details knows the “famous” composite metric formula, but the recommendation to keep the K values intact (or at least leaving K2 and K5 at zero) or the inability of EIGRP to adapt to changing load conditions is rarely understood.

IGRP, the EIGRP’s predecessor, had the same vector metric and very similar composite metric formula, but it was a true distance vector protocol (like RIP), advertising its routing information at regular intervals. The interface load and reliability was thus regularly propagated throughout the network and so it made sense to include them in the composite metric calculation (although this practice could lead to unstable or oscillating networks).

EIGRP routing updates are triggered only by a change in network topology (interface up/down event, IP addressing change or configured bandwidth/delay change) and not by change in interface load or reliability. The load/reliability numbers are thus a snapshot taken at the moment of the topology change and should be ignored.

Sending EIGRP updates whenever there’s a significant change in load or reliability would be technically feasible, but would diminish the benefits of replacing distance vector behavior with DUAL.

You might be wondering why Cisco decided to include the load and reliability into the EIGRP vector metric. The total compatibility of IGRP and EIGRP vector metrics allowed them to implement smooth IGRP-to-EIGRP migration strategy with automatic propagation of vector metrics in redistribution points, including the IGRP-EIGRP-IGRP redistribution scenario used in IGRP-to-EIGRP core-to-edge migrations.

see 8 comments

VRF Routing Process Limitations

Cisco IOS allows up to 32 routing protocols contributing routes into a routing table (two of them are always connected and static). The limitation applies to the global routing table as well as to each individual VRF; the architectural reason for the limit is a 32-bit mask that’s used in Cisco IOS to mark individual routing protocols. The routing protocol ID (as displayed by the show ip protocol summary command) is thus limited to values 0 to 31. With value 0 being reserved for connected routes and value 1 for static routes, 30 values are left to number the routing protocols.

Due to the implementation details of Cisco IOS, the BGP, RIP and each EIGRP routing process consume routing protocol ID in all VRFs (regardless of whether they are used or not). You can view the IDs of individual routing protocols with the show ip protocol [vrf name] summary command.

read more see 7 comments

EIGRP neighbor loss detection

Vijay sent me an interesting EIGRP query:

I know EIGRP hello packets are used to discover and maintain EIGRP neighborship and when an EIGRP router doesn't receive a hello packet from its neighbor within the Hold timer, that router will be declared dead. But when would EIGRP declare a neighbor dead after sending 16 unicast packets?

The primary mechanism to detect EIGRP neighbor loss is the hello protocol. It's a bit unreliable as it does not detect unidirectional communication, but has an interesting advantage that you can use asymmetrical hello/hold timers (each router can specify what hold timer its neighbors should use for its hello packets).

read more add comment

Leak Map Confusion

A short question I've got from Shahid Rox:

Today I read your article about scaling EIGRP using stub routers. I was wondering whether you can use the leak map only for routes learned from other EIGRP neighbors? Is it also usable to filter connected routes?

Leak-map controls what its name implies: the leakage of routes received from EIGRP neighbors to other EIGRP neighbors. To filter connected prefixes redistributed into EIGRP, use the route-map on redistribute connected command. The only way I've figured out to filter announcements of directly connected networks that are part of the EIGRP process is the distribute-list out command.

add comment

Multihomed EIGRP Sites in MPLS VPN Network

Deploying EIGRP as the PE-CE routing protocol in MPLS VPN networks is easy if all sites have a single PE-CE link and there are no backdoor links between the sites. Real life is never as simple as that; you have to cope with various (sometimes undocumented) network topologies. Even that would be manageable if the customer networks would have a clean addressing scheme that would allow good summarization (that happens once in a blue moon) or if the MPLS VPN core could announce the default route into the EIGRP sites (wishful thinking; the customer probably has one or more Internet exit points).

In the end, you’re left with two-way route redistribution between core MP-BGP and edge EIGRP, resulting in nightmarish scenarios (probably a good half of the blog posts of the CCIE candidates talk about redistribution horrors). Fortunately, Cisco implemented two extra features supporting EIGRP-to-MP-BGP redistribution: BGP cost community and BGP Site-of-Origin. I described them both in an article that is long gone; its shadow has been preserved on

Would you like me to migrate that article to Send me a message and I just might do it...

add comment

Using EIGRP in MPLS VPN Networks

We described EIGRP-in-VRF in MPLS and VPN Architectures, Volume II. A few details have changed in the meantime; you have to configure the following features to get EIGRP running within MPLS/VPN environment:

  • The autonomous-system command within the VRF address family is mandatory, even if the VRF AS number matches the EIGRP process number.
  • The default BGP-to-EIGRP redistribution metric has to be configured, otherwise remote EIGRP routes will not be redistributed even though they have EIGRP metric encoded in extended BGP communities.
  • Things work best if you disable auto-summary on PE-routers.
read more add comment

Changes in EIGRP summary address are no longer disruptive

Earlier IOS versions treated changes in EIGRP summary address configuration (configured with the ip summary-address eigrp interface configuration command) very disruptively: all EIGRP sessions across the affected interface were cleared, sometimes resulting in a large number of routes entering active state, potentially leading to a stuck-in-active condition.

Recent IOS releases are more lenient: router with a change in summary address requests a resync (logged as graceful-restart on adjacent routers). A lot of updates and queries are still sent, but the adjacencies themselves are preserved:
  • When configuring a summary route, all more specific prefixes on downstream routers enter active state.
  • When a summary is removed, only the summary prefix itself enters active state and the affected router sends queries to all its neighbors, while the more specific prefixes are sent as regular EIGRP updates to the neighbors across the affected interface.
read more see 1 comments

EIGRP load balancing based on interface load

EIGRP computes its composite metric from five parameters, one of them being interface load, therefore raising the theoretical possibility of having route metrics that include interface load. However, tweaking EIGRP K-values with the metric weights command to include interface load in metric calculations is highly discouraged - every change in interface load could lead to network instability. Even worse, whenever an interface load would increase, the increased composite metric of the afftected routes in EIGRP topology table would cause them to enter active state (and the router to start the DUAL algorithm trying to find more optimum paths toward the destination).

To make the whole idea even more impractical, EIGRP does not scan the interface load (and other parameters influencing the metric) on periodical basis, but only when triggered by a change in network topology (for example, interface or neighbor up/down even).

Note: this article is part of You've asked for it series.
see 2 comments

EIGRP goodbye message

In IOS release 12.3(1.4), Cisco has added Goodbye message to EIGRP protocol. Previously, whenever the router would need to tear down EIGRP adjacency (for example, due to changed summary addresses), it would simply erase the neighbor from its EIGRP neighbor table and pretend the it's just encountered a new neighbor on the next hello message. As the adjacent device does not participate in this charade, it becomes confused resulting in delayed adjacency establishment. The whole process is described in details in my EIGRP book, which is unfortunately out-of-print for a few years and is available only as an on-line book on Safari.

With the Goodbye message, both neighbors tear down the adjacency in an orderly fashion and reestablish it immediately after receiving the EIGRP HELLO message.
read more see 3 comments