An EIGRP Overview:
Are you like me? Are you intrigued by the Cisco invention of EIGRP? Here is an excellent text you should consider for your Holiday Reading List:
EIGRP for IP: Basic Operation and Configuration by Russ White and Alvaro Retana
It is always great to visit with Russ White each Cisco Live, and I have read many of his works. His text does a fine job clearing many of the misconceptions regarding the composite metric of EIGRP. Having taught this subject for decades now, I have seen so many students willing to argue on many of these points. Let’s review some of these here in this post.
The Merry Metric:
- While we are taught since CCNA days that the EIGRP metric consists of 5 possible components – BW, Delay, Load, Reliability, and MTU; we realize when we look at the actual formula for the metric computation, MTU is actually NOT part of the metric. Why have we been taught this then? Cisco indicates that MTU is used as a tie-breaker in a situation that might require it. To review the actual formula that is used to compute the metric as well as other great information, click here.
- Here is the basic formula – EIGRP Metric = 256*((K1*BW) + (K2*BW)/(256-Load) + (K3*Delay)*(K5/(Reliability + K4)))
- Notice from the formula that the K (constant values) impact which components of the metric are actually considered. By default K1 is set to 1 and K3 is set to 1 to ensure that Bandwidth and Delay are utilized in the calculation. For example, if you wanted to make Bandwidth twice as significant in the calculation, you could set K1 to 2. The metric weights command is used for this manipulation. You should note that the metric weights command starts with a TOS parameter that should always be set to 0. Cisco never did fully implement this functionality.
- The Bandwidth that affects the metric is taken from the bandwidth command used in interface configuration mode. Obviously, if you do not provide this value – the Cisco router will select a default based on the interface type.
- The Delay value that affects the metric is taken from the delay command used in interface configuration mode. This value depends on the interface hardware type, e.g. it is lower for Ethernet but higher for Serial interfaces. Note how the Delay parameter allows you to influence EIGRP path selection decisions without the manipulation of the Bandwidth value. This is nice since other mechanisms could be relying heavily on the bandwidth setting. For example, EIGRP bandwidth pacing or absolute QoS reservation values for CBWFQ.
- The actual metric value for a prefix is derived from the SUM of the delay values in the path, and the LOWEST bandwidth value along the path. This is yet another reason to use more predictive Delay manipulations to change EIGRP path preference.
Thanks for the recommendation. Quality books on EIGRP are rare, indeed. I picked this up, and got a bonus chuckle out of Kindle stating the estimated time to read at 2 hours and 16 minutes. This ain’t no 50 Shades of Grey!
Thank you for the awesome laugh. I read the cliff notes for 50 shades…
I have just about finished reading this book, and one of the most interesting points made was what happens when a router learns about a route from different directions with the same administrative distance. In this case, a redistributed RIP route which is advertised to an EIGRP router by two other EIGRP routers–each with D-EX 170.
I had just assumed in that circumstance, that if the AD is tied, then the tie breaker is the metric. Not so! According to the author, it is completely random (whichever route it happened to learn about first wins). I may have to lab this one up!
Yet another example of why it is best to lab rather than take something on authority. Either the author is wrong, or EIGRP behavior has changed in later code since the book was written.
In my testing, the router will chose the D-EX route with the lowest metric consistently. If I change the RIP to EIGRP redistribution for the path not taken such that the EIGRP assigned metrics are lower, that new redistributed route will always usurp what was previously the preferred route.
One thing I still don’t understand is what EIGRP does in the case of a tie breaker for external routes. With internal routes, equal metric routes will be installed (up to 4?) as load balancing (ignoring variance for now). This does not appear to be the case with D-EX routes, as only one is ever put into the routing table. So in the case of a tie with both AD and Metric for D-EX, what’s the tie breaker?
FYI: I finally figured out what is going on. I realize my description is not very good without being to upload a diagram, but what I have discovered (and proved via labbing) is this:
EIGRP prefers external router (D-EX) in the following order:
1) Lowest Administrative Distance
2) Lowest Metric
3) Lowest Originating Autonomous System Number
It was #3 that was news to me. If you have a router that is in two different EIGRP ASes and it is presented with an external route that has equal AD and equal metrics from each of its ASes, it will not install both in the routing table. Instead it picks the D-EX from the lowest AS number as the best route. A debug ip routing in this circumstance renders the following:
RT: closer admin distance for 10.10.10.10, flushing 1 routes
Interesting it says that even though the admin distance is, in fact, the same for both routes.
Incredible work here – thank you so much for contributing!!!!