Myths and Truths about EIGRP

1. Myths and Truthsabout EIGRP Peter Palúch, CCIE #23527, CCIP, CCAICisco CSC Designated VIP 2011-2012 Networking Academy WebinarFebruary 29th, 2012

2. Rationale behind this session • EIGRP has been supported since 1992 in IOS 9.21 • Despite its long existence, EIGRP still proves to be little known and poorly understood when it comes to details • There are many materials about EIGRP published • Sadly, many of them are superficial • Even more sadly, quite a few of them contain incomplete, inaccurate or outright misleading and incorrect information • Certain topics are notorious for this  • Not even official materials have been spared • This session would like to dispel some of the most common myths and superstitions about EIGRP

3. About EIGRP’s Nature (1) • EIGRP was described in the past as “balanced hybrid” • Combining Distance-Vector (DV) and Link-State (LS) properties • To decide what EIGRP really is, we need to look at what classifies the protocol as either DV or LS • What defines a LS protocol? • LS works by routers exchanging topological elements, i.e. exact information about routers themselves and their adjacencies • Addresses, networks and metrics are merely attributes of routers and their interconnections • Each router knows all other routers and their connections precisely; all routers have identical link-state database • Using the link-state database of any single router, administrator can draw the diagram of the entire network

4. About EIGRP’s Nature (2) • What defines a DV protocol? • DV works by routers exchanging vectors, i.e. arrays, of distances to individual known networks • The CCNA-level explanation of the DV as exchanging “metrics and directions” is perhaps illustrative but imprecise • No topological information (i.e. what are the individual routers, how are they interconnected) is ever exchanged or known • What does not influence the routing protocol’s type? • Type of metrics used • Full vs. incremental updates • Periodic vs. event-based updates • Usage of a Hello mechanism and establishing neighborships • Usage of a reliable transport mechanism

5. A Network Topology Example R2 A D B E R3 R5 R1 G C F R4

6. What would Router A see in LS and DV? A D R2 R1 A C B B E R3 R5 R1 D, E, F, G D, E, F, G D, E, F, G C G F R4 R2 R3 R4 In Link-State Protocol In Distance-Vector Protocol

7. What information does EIGRP carry? • In EIGRP, routing information is carried inside Update packets • In an Update, after header, an array of records follows: • Type and size of the record in the array (IP internal, IP external, …) • Next Hop • Metric Values (Delay, Bandwidth, MTU, Hop Count, Reliability, Load) • Address information (prefix, netmask) • This is a vector of distances!

8. About EIGRP’s Nature (3) • EIGRP carries detailed information about a particular path’s properties but there is no topological information • No matter how diverse the component metrics are, they are only metrics and do not reveal the complete picture of the network • Addition of mechanisms formerly typical for LS protocols does not make EIGRP a hybrid protocol • A hybrid protocol would need to maintain a LS database for a limited part of network, describing the rest using a DV approach • This is the principle of areas in LS protocols • Hello mechanism, neighborships, event-driven incremental updates etc. – all these only increase the effectivity of EIGRP communication • They do not change the nature of routing information itself • The conclusion about EIGRP’s nature: • Advanced Distance-Vector – absolutely! • Hybrid? No way 

9. About EIGRP’s Metrics (1) • EIGRP’s metric system includes six components • Bandwidth (static, min along path) • Delay (static, cumulative) • Reliability (dynamic, min along path) • Load (dynamic, max along path) • MTU (dynamic, min along path) • Hop Count (dynamic, cumulative) • EIGRP uses a weighted formula to compute a single composite metric using the first four components • MTU and Hop Count are not used in this formula • All metrics are always advertised in their individual form • Delay and Hop Count are added to • Bandwidth, Reliability, MTU are minimized, Load is maximized

10. About EIGRP’s Metrics (2) • A couple of misconceptions exists about the K-values • The K-values are sometimes confused with metrics themselves • The K-values are thought to control the individual metrics, in particular, K5 is thought to control the MTU usage • The K-values are simply weights applying to diverse metric components • MTU is not included in the formula • Regardless of K-values settings, Update packets always contain all metric components • K-values are carried in Hello packets and must match neighbor’s

11. About EIGRP’s Metrics (3) • The Hop Count is not used in best path selection • It is used as a safety net against count-to-infinity situations • Hop Count Limit can be configured in EIGRP configuration using the metric maximum-hops command • Prefixes with a higher Hop Count will not be accepted • Information about MTU usage is conflicting • Some materials maintain that MTU is unused • Some other suggest that the MTU is used in cases where multiple equal-cost paths are available • In discussions with four independent Cisco employees, it has been confirmed that using the MTU was an idea considered but ultimately never actually implemented

12. About EIGRP’s Metrics (4) • Reliability and Load metrics are unused by default • By tweaking the K-values, they can be utilized • However, Reliability and Load metrics in EIGRP do not behave as intuitively expected • Reliability and Load counters on interfaces are updated steadily • Simply taking them into EIGRP would necessitate sending Updates every moment these counters change • This could create extensive churn in routing tables, possibly leading to ever increasing swings in these metrics values • In reality, advertised values of Reliability and Load always correspond to their state in the moment of sending the update • They are set when advertising a route • Updates are not sent as a result of Reliability and Load changes

13. About EIGRP’s Metrics (5) • Thus, Reliability and Load are largely useless in EIGRP • Why are they even included, then? • The reason is backward compatibility and seamless interoperability with IGRP that originally introduced them • If both IGRP and EIGRP were configured on a router in the same AS, automatic redistribution between IGRP and EIGRP took place • Out of all EIGRP’s metrics, only Bandwidth and Delay are usable in a reasonable way • Bandwidth should never be used to influence routing decisions • It behaves non-linearly • Various IOS mechanisms depend on correct bandwidth setting • If EIGRP metric is to be influenced, the Delay should be modified

14. About EIGRP’s Terminology (1) • EIGRP uses an arcane terminology that is sometimes troublesome to be used or understood in a proper way • Autonomous System: really a process number • Topology Table: does not contain any topological information • Successor and Feasible Successor: these are routers, not routes • Advertised Distance: its acronym of AD often gets confused with Administrative Distance, a totally unrelated concept • Feasible Distance: it is not the current best distance, neither a total distance through a particular neighbor • The Feasible Distance (FD) is one of the most misunderstood concepts in EIGRP • Before diving into details about FD, let’s make a small experiment in the network topology

15. Network Topology with Addressing • Assume that, initially, all links are configured with the same Delay=10 and K-values are 0, 0, 1, 0, 0 (on R5, the stub network’s Delay=1) • Now, assume that the Delay on links from R1 to R2-R4 gets increased to 20, resulting in the metric growup • What happens to FD? R2 10.0.25.0/24 10.0.12.0/24 10.0.35.0/24 10.0.13.0/24 R3 R5 R1 192.0.2.0/24 10.0.45.0/24 10.0.14.0/24 R4

16. About EIGRP’s Terminology (2) • FD is not the current best path metric • FD is not the total distance via a particular neighbor • Rather, FD is a record of the smallest distance to the destination since the last time the route went Passive • In other words, the FD is the historical minimum of the distance to the particular destination • The history here ends and starts anew with the route transitioning from Active to Passive state • During Passive state, the FD may only decrease • The only way to increase FD is to engage in a diffusing computation and reset the FD after finishing it • FD is a local variable associated with each known prefix and is never sent to any other EIGRP router

17. About EIGRP’s Terminology (3) • Using this notion of the FD, the Feasibility Condition can be rewritten as: • “If a neighbor is closer to the destination than I have ever been, it is guaranteedly not on a routing loop that would eventually lead back to me.”

18. About EIGRP’s Feasible Successors (1) • To recall: • A successor must meet two constraints: pass the FC check and provide the least total distance to the destination • A feasible successor must only pass the FC check • A FS provides a convenient back-up next hop in case the current successor fails • It is widely believed that if the successor fails and at least one feasible successor is known, it will always be used • However, there are situations in which a feasible successor is known – and yet, when successor fails, router will enter Active mode instead of using the FS

19. Network Topology with Modified Metrics • Let’s focus on the route from R1 to the network behind R5 • FD = 21 • R4: successor, Total Distance = 21*256 = 5376, RD = 11*256 = 2816 • R3: feasible successor, Total Distance = 36*256 = 9216, RD = 11*256 = 2816 • R2: fails FC check, Total Distance = 28*256 = 7168, RD = 23*256 = 5888 R2 5 22 25 10 R3 R5 R1 1 10 10 R4

20. About EIGRP’s Feasible Successors (2) • Assume that R4 as a successor fails • R1 will determine that while R3 is a FS, R2 has even better total metric towards the destination but it does not pass the FC check • R1 will move the route into Active state and send queries • After receiving all replies and going Passive, R1 will reset the FD and set it to the metric of the newly found route towards the destination • The FS, although identified, will not be used in this case • Satisfying ourselves with the current FS would make us stay with using a worse route than what is objectively available • The true logic regarding the use of FS • After successor fails, find the neighbor providing the next least cost route to the destination • If it is a FS, start using it, otherwise, enter the Active state

21. About EIGRP’s SIA state (1) • The process of diffusing computation in EIGRP depends on correct and timely arrival of Replies to all Queries • Once a router sends a Query, it must wait to receive Replies from all queried neighbors before starting to send Replies itself • Delays in waiting for a single Reply will slow down the entire process of convergence to a new path • One of the most sensitive weak spots in EIGRP • In extreme situation, if a Reply never comes, a route in Active state can never reach the Passive state • EIGRP uses a so-called Active timer to bound the diffusing computation to the duration of max. 3 minutes • If a diffusing computation does not finish in this time, the router declares a so-called Stuck-in-Active state and resets the adjacency with the unresponsive neighbor • Lossy and oversubscribed links, overloaded neighbors, misbehaving EIGRP implementation, overly redundant or deep network topology: all of this contributes to the risk of creating a SIA state

22. About EIGRP’s SIA state (2) Will this circular topology lead to SIAs?

23. About EIGRP’s SIA state (3) • In circular topologies, Queries may be forwarded in a way that they eventually reach back to the router that started the diffusing computation • It is a popular belief that this will cause a deadlock and a SIA • This statement has even made it into Cisco Press CCNP textbooks • In reality, if a router in Active state receives a Query, it just replies immediately with the same information it has already advertised in its own Query • Hence, circular topologies are no more prone to SIA states than any other • In fundamental EIGRP’s algorithms, there are no deadlocks or race conditions

24. Small things to be aware of (1) • EIGRP has a concept of Router ID • Chosen in a similar way to OSPF • By eigrp router-id command • If not, then by the highest active loopback IP address • If not, then by the highest IP address on all active interfaces • Router ID is displayed in the show ip eigrp topology output • Router ID is used as a prevention against routing loops, mostly caused by circular route redistribution • Router ID is attached to redistributed routes • If a router receives a route tagged with its own Router ID, it will ignore it • Formerly, the Router ID has been attached to external (redistributed) routes only • In recent IOS versions, the Router ID is also added to internal routes and evaluated accordingly • See the show ip eigrp topology X.X.X.X output

25. Small things to be aware of (2) • Static routes defined using egress interfaces are considered by EIGRP as directly connected • They can be injected into EIGRP using the network command just like any other directly connected network • This often leads to confusion that static routes do not need to be redistributed using the redistribute command • Especially dangerous when trying to inject a default route using network 0.0.0.0command • This will add all directly connected networks into EIGRP(this is probably not what you want) • Whether the default route will be injected as well depends on how it is defined – it would have to be a static route via egress interface

26. Small things to be aware of (3) • When configuring metrics, it is good to avoid values close to the maximum value • Delay can be defined in the range of 1 – 16,777,215 • The maximum delay value represents infinity and a network with such delay value will be considered unreachable • Remember that delay is cumulative • The variance code in EIGRP has a small glitch • Variance of “V” allows to use all FS routes whose metric is in the interval of <BM, V * BM> where BM is the current best metric • In certain networks, even if the variance seems to be sufficient, FS routes are mysteriously not included into the routing table • It turns out that the EIGRP code suffers from a trivial unsigned integer overflow: the product of V*BM is not capped at 232-1and instead, it overflows, possibly producing a smaller value

27. Conclusions • EIGRP is a unique protocol in many aspects • As a proprietary protocol, its details are understandably less publicly known and understood • Great care must be taken not to propagate incorrect information about its workings • Huge THANK YOU to Donald Slice, Edison Ortiz, Russ White and Riccardo Simoni for clarifying some of the obscure facts

28. Thank you! Peter PalúchPeter.Paluch@fri.uniza.sk