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«.
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.
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.
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).
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.
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 archive.org.
Would you like me to migrate that article to ipSpace.net? Send me a message and I just might do it...
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.
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.
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.
With the Goodbye message, both neighbors tear down the adjacency in an orderly fashion and reestablish it immediately after receiving the EIGRP HELLO message.