Episode 5 – All You Ever Wanted To Know About EIGRP

In episode 5 the Network Collective panel dives deep into the inner-workings of EIGRP and how to tune the protocol to work best for you. This isn’t your run of the mill EIGRP training session though, so buckle up and dig in to learn a lot about a protocol which appears pretty straight forward on the surface.

On-Premise IT Roundtable

On another note… If you like the technical and community aspects of Network Collective, we wanted to tell you about a podcast that our friends over at Gestalt IT have just started up that you’ll probably enjoy as well.  The name of their podcast is the On-Premise IT Roundtable and in addition to networking they will be covering topics like system architecture, storage, big data, virtualization, hyper-converged, and a slew of other topics.  You should check them out.


Outro Music:
Danger Storm Kevin MacLeod (incompetech.com)
Licensed under Creative Commons: By Attribution 3.0 License


Russ White
Nicholas Russo
Jordan Martin
Eyvonne Sharp
Phil Gervasi


Audio Only Podcast Feed:



  1. Sreekanth
    June 14, 2017

    It was a nice discussion and I got to learn the pitfalls of SIA Query scope . Can anyone elaborate on Microloops you were talking about . I couldn’t understand how EIGRP is different in avoiding Microloops when compared with Link State Algorithms

    • Network Collective
      June 14, 2017

      This is a good question, and probably more detailed than I can address adequately in a blog comment, but I’ll give it a try.

      In link-state routing protocols, every device keeps a copy of the entire topology in a local database, and chooses the best path by running a computation algorithm against that information. Since this database is identical in every router, every router should come to the same conclusions about which paths are shortest and loop free.

      Now when a link fails, the notification of that link failure needs to be propagated to the rest of the network by the router(s) attached to it. Those connected routers are the first to know of the link failure, but it takes some time for that information to be passed along to the other routers in the topology, and for the other routers to run their SPF calculations with this new information factored in. It’s in this interim state, where the trouble can happen.

      Routers not connected to the impacted link still believe the failed path is best, while those routers directly connected to the failed link have already worked out an alternative path around the failed link. This can lead to microloops in the topology, where packets are forwarded back and forth between two different routers, until they all have had a chance to process the fact that the link has failed.

      Distance-vector protocols, and especially EIGRP in this case, treat this problem differently using the concept of Feasible Successor (FS). A route can only be identified as a FS if the advertised metric (advertised distance) of the route is less than the metric (feasible distance) of the primary route installed into the routing table. A FS route guarantees that the alternative path, from end to end, would never pass through this specific router again. Unless that can be verified in advance (which is what the FS route by nature is), the router will not rapidly converge on an alternative path, opting instead to drop traffic until a suitable path can be found.

      To make a very long story short… link-state protocols prefer rapid convergence, even if that convergence can possibly cause a loop in the topology during the process. EIGRP prefers to guarantee a loop free path, even if that means traffic is dropped while the convergence process happens.

      Hopefully that answers the question.


  2. Sreekanth
    June 16, 2017

    Thanks for the detailed explanation. That make sense to me . I will try to lab it out and see that happening in real time.

  3. June 16, 2017

    I’ve played with EIGRP for years and didn’t know about the query leaking issue that Nick mentioned, definitely a good episode, keep them coming!

  4. Carlos
    September 27, 2017

    Keep them coming! great page.

Leave a Reply

Your email address will not be published. Required fields are marked *