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.

EIGRP is a distance vector routing protocol. Not bad, but not completely true either. Wikipedia has a nice wording: “EIGRP is not a na├»ve DV routing protocol”. EIGRP differs from other DV routing protocols in the way it handles lost routes (or routes with increased metric). All other DV routing protocols passively wait to get potentially better information from their neighbors (some of them, including RIP, even lock down the path to prevent loops), while EIGRP takes a more active approach (now you see why a temporarily-lost route is active) and starts querying its neighbors.

EIGRP is complex in implementation and maintenance. Totally bogus. EIGRP in large networks with low-speed links was somewhat harder to design properly in the good old days before the stub routers were introduced. With stub routers (and numerous fixes to the DUAL algorithm), it’s no worse than OSPF (not to mention BGP or IS-IS).

Like a Link State protocol, EIGRP keeps a topology table of advertised routes. It’s amazing how totally wrong this is. EIGRP has no clue what’s beyond the immediate neighbors, while LS protocols know the exact topology of the whole area in which they are.

The only thing an EIGRP router does is to keep track of what the neighbors told it (RIP forgets everything that’s not immediately applicable). In that aspect, it’s very similar to BGP that also stores everything in the BGP table and then selects the best path from the BGP table. The topology table (stored past information from EIGRP neighbors) gives EIGRP an edge over RIP (but not BGP) – the topology table might already have an alternate (but currently not used) route to the destination.

EIGRP is a Distance Vector protocol that acts like a Link State protocol. Nice try, but still totally wrong. A Link State routing protocol builds the routing table using these steps:

  • Every router describes its local view of the network (links, subnets, neighbors) in a packet (or more of them) called LSA (in OSPF) or LSP (in IS-IS).
  • LSAs are flooded unmodified across the whole area, ensuring every router receives all LSAs generated within the area. Each router stores all received LSAs in its topology database.
  • Each router independently analyses its copy of the topology database and runs the SPF algorithm to compute its own best paths to every other router in the area.

EIGRP doesn't come even close to using a single one of these steps, so it’s hard to understand why exactly it “acts like a Link State protocol”.

EIGRP is an Advanced Distance Vector protocol because of addition of several Link State features such as dynamic neighbor discovery. This is grasping at straws. A protocol that is smarter than RIP (and can actually figure out who the neighbors are) is still infinitely far away from being a Link State protocol. Dynamic neighbor discovery is not a Link State feature (or we could start claiming that BGP with anonymous neighbors also has LS features). Every decent network-related protocol designed in the last decades has some dynamic neighbor discovery and/or verification of neighbor presence.

What’s your take on EIGRP myths? Have I missed any of them? Share your opinions in the comments.

15 comments:

  1. Stuart Howlette03 August, 2010 10:06

    Very interesting, I've been trying to tell people about EIGRP not being "hybrid" for a long time, but only had a couple of reasons under my belt to say. I shall be referring back to this one a lot!

    ReplyDelete
  2. I agree with you Ivan,

    EIGRP it's not a Link State, let me add that it relies on split horizon, that's unnecessary on links state protocols...

    thanks as usual for the interesting arguments

    Marco

    ReplyDelete
  3. Correct me if I m wrong but like a LS routing protocol, EIGRP forms adjacencies with his neighbors and some parameters in the hello have to match.

    For me this is why ppl say that EIGRP has some LS routing protocol feature.

    What do you think ?

    twitter.com/mcl_nicolas

    ReplyDelete
  4. When I say some parameters must match I would correct myself and say that only the K values must match :))

    ReplyDelete
  5. Like Ivan states in the last point, dynamic adjacency formation, while nice, isn't related to maintaining a link state database.

    ReplyDelete
  6. Pavel Skovajsa03 August, 2010 16:36

    or in other words - it is possible to design a LS protocol without having dynamic adjacency formation

    ReplyDelete
  7. Ivan Pepelnjak03 August, 2010 19:08

    Just to put our debate into a historical perspective: dynamic neighbor discovery, adjacency formation and fast neighbor loss discovery are considered common sense today.

    These mechanisms were not part of any of the early DV routing protocols, including RIP, IPX RIP, AppleTalk, DECnet, XNS ... so having that functionality in EIGRP was something quite novel (as was the idea of having the same routing protocol for three address families).

    However, that has been 15 years ago and it's irresponsible to cut-and-paste from the ancient lore and resell those fragments as absolute truth.

    ReplyDelete
  8. ... and vice versa. A protocol doesn't have to be link-state to feature dynamic neighbor discovery.

    ReplyDelete
  9. K values + AS number

    ReplyDelete
  10. OSPF relies on split horizon for LSA flodding
    EIGRP for NBMA needs to turn off SH

    ReplyDelete
  11. Hi! I have a question.
    First. Routers configured with eigrp with same parameters. Then they form the neighbor table.
    Second, they send updates. What are these updates? Where do they come from? From topology table or the routing table?

    ReplyDelete
  12. Ivan Pepelnjak14 April, 2011 08:19

    Topoogy table. BTW, if you're interested in EIGRP details, my EIGRP book still covers most of them.

    http://my.safaribooksonline.com/book/networking/cisco/1578701651

    ReplyDelete
  13. Thank you Ivan!!! I'll get your book.

    ReplyDelete
  14. I think at a more basic "ccna guy on the street" level (that would be me), the issue of whether eigrp can be thought of as either LS or DV revolves around what aspect of those two types you are specifically talking about. If you stand up and scream "distance vector protocol", most ccna level guys will immediately think "hop count for metric". The first thing you ever learned about DV. If i then say "eigrp is a distance vector protocol", again, I think, most ccna level guys will immediately think hop count - in other words they are thinking about the metric aspect of eigrp simply because you said "distance vector". But eigrp does not use hop count to make its path selection, rather bandwidth and delay. So for me, I always felt it strange to hear eigrp described as DV (still do), when the most prominant feature, metric, is not hop count, hence, not (from my perspective) what most people think of FIRST when they they think of DV. Does any of that sound coherent?

    ReplyDelete
  15. You sound perfectly coherent ... and obviously we're doing a very bad job explaining the fundamentals of the routing protocols @ CCNA level. As you know, hop count is just one possible metric.

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.