Building network automation solutions

9 module online course

Start now!

Category: EIGRP

Beware of the pre-bestpath cost extended BGP community

One of my readers sent me an interesting problem a few days ago: the BGP process running on a PE-router in his MPLS/VPN network preferred an iBGP route received from another PE-router to a locally sourced (but otherwise identical) route. When I looked at the detailed printout, I spotted something “interesting” – the pre-bestpath cost extended BGP community.

read more add comment

EIGRP: an MBA-like perspective

Ahmed was reading my EIGRP book (I know it’s hard to get, but fortunately he found a well-marked copy) and wanted to check his understanding of how EIGRP works. The first question was as good a summary as I’ve ever seen:

Does it just simply boil down to the fact that a router will choose not to have anything to do with a reported distance higher than its own cost to that route (feasible distance) for the (paranoid) fear that it could be a loop?

Next, he started wondering why a router would behave that way:

read more see 10 comments

Solution: EIGRP summarization breaks Phase 2 DMVPN

Last week I posted an interesting challenge: what happens if you configure route summarization in a Phase 2 DMVPN network? The only response came from an anonymous contributor strongly suspected to be a routing/DMVPN expert working for a CCIE-related training company. Everyone else obviously found the question too trivial ... or too obscure, in which case it could be a good idea to join us at the next DMVPN: From Basics to Scalable Networks webinar.

The anonymous responder was somewhat cryptic, so let’s do a step-by-step explanation. We’ll use a simple 3-router network; C1 is hub, R2 and R3 are spokes.

read more see 9 comments

EIGRP summarization in DMVPN Phase 2 networks

Imagine the following scenario: you’ve configured a Phase 2 DMVPN network with a hub and a few spokes. DMVPN is configured properly, IPSec and NHRP are working, you can ping all around the DMVPN cloud.

Next step: configuring EIGRP. You know you have to disable EIGRP split horizon and EIGRP next-hop processing. You even remember to configure interface bandwidth.

Someone told you to minimize the EIGRP routing traffic, so you use EIGRP stub routers on the spokes and route summarization on the hub router. The final EIGRP configuration is shown in the following diagram (click to enlarge).

read more see 3 comments

Multiple EIGRP autonomous systems in a VRF

A while ago Ron sent me an intriguing question: “Is it possible to have two EIGRP AS numbers in the same VRF?” Obviously he’s working on a network with multiple EIGRP processes (not an uncommon pre-MPLS/VPN solution; I did a network design along the same lines almost 20 years ago).

It’s easy to run multiple EIGRP autonomous systems in the global IP routing table; just create more than one EIGRP process. They can even run over the same set of interfaces. EIGRP-in-a-VRF implementation is slightly different; you configure an address family within another EIGRP process and (optionally) specify an AS number that does not have to match the AS number of the EIGRP process.

read more see 1 comments

EIGRP myths debunked

Matthew Norwood performed a really thorough EIGRP research and unearthed a lot of myths around it, some of them coming from official documentation, Cisco Press books (hopefully not mine) and other sources. It’s time to debunk a few of them (read the comments to Matthew’s post to find the sources of the following “wisdoms”).

EIGRP is a hybrid routing protocol. If I remember correctly, this one comes straight from the first EIGRP presentations Dino had @ Networkers years ago and is usually interpreted as “EIGRP has the best features of Distance Vector and Link State routing protocols”. Completely wrong, EIGRP has zero LS features. Correct classification would be “EIGRP is an advanced Distance Vector routing protocol” and the Wikipedia entry on EIGRP is almost spot-on.

read more see 15 comments

EIGRP offset lists

A simplistic explanation of EIGRP offset-list configuration command you might see every now and then is “it adjusts the RD/FD to influence route selection”. If that would be the case, the adjustment would not be propagated to upstream routers (remember: only the EIGRP vector metric is sent in the routing updates, not RD or FD) resulting in potential routing loops (it’s never a good idea to use one set of metrics and propagate another set of metrics to your neighbors).

In reality, the EIGRP offset lists adjust the delay portion of the EIGRP vector metric (which linearly influences the RD/FD value). You can increase or decrease the value of the delay metric for EIGRP updates received or sent through a specific interface (or all interfaces). You can also use an access list in the offset-list command, applying changes only to specific IP prefixes (very similar to what I described in the Scalable policy routing IP corner article). For more details, please read this technology note on Cisco’s web site.

see 2 comments

Interesting BGP/IGP interaction problem

I’ve stumbled across a really interesting BGP/IGP problem described by Jeremy Filliben that nicely illustrates the dangers of using more than one IGP in your network. You should read the original post for details, here’s a short summary:

  • The same IP prefix is received by two BGP border routers (A and D) and sent to a third IBGP-only router (E).
  • E can reach A via OSPF. It can reach D via EIGRP.
  • E receives two BGP paths to the target IP prefix from A and D. They are identical, so the IGP metric (taken from the IP routing table) is used as the tie-breaker.
  • EIGRP and OSPF metrics are totally incomparable and thus A (reachable via OSPF) is always preferred over D (reachable via EIGRP).

Lesson learned: use a single IGP in your AS (or at least in its BGP core).

see 8 comments

Manipulating EIGRP metrics

If you want to influence traffic flow in a network, you might want to tweak routing protocol metrics to shift the traffic between paths of almost-equal cost (I would always prefer MPLS Traffic Engineering as it’s so much better, but sometimes changing a metric is faster than rebuilding your network). OSPF and IS-IS are easy: change the interface metric or interface bandwidth. EIGRP and its composite metric are trickier.

As you know, EIGRP vector metric has five components; two of which are usually ignored and MTU serves only as tie breaker. This leaves us with bandwidth and delay. Every EIGRP reference tells you to adjust interface delay, not bandwidth, and the simplistic explanation is that “bandwidth is used for QoS features, so it’s better left unchanged”. While that’s true, there are other more important reasons to focus on delay:

read more see 3 comments

Recommendations for keepalive/hello timers

The “GRE keepalives or EIGRP hellos” discussion has triggered another interesting question:

Is there a good rule-of-thumb for setting hold-down timers in respect to the bandwidth/delay of a given link? Perhaps something based off of the SRTT?

Routing protocol hello packets or GRE keepalive packets are small compared to the bandwidths we have today and common RTT values are measured in milliseconds while the timers' granularity is usually in seconds.

read more see 3 comments

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 PC answer is »use GRE keepalives and keep EIGRP hellos at their default values«.

BFD would be the perfect solution, but it's not working over GRE tunnels yet ... and based on its past deployment history in Cisco IOS years will pass before we'll have it on the platforms we usually deploy at remote sites.

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
Sidebar