Show 144 – Open EIGRP with Russ White + Cisco’s Donnie Savage

EIGRP is a distance vector routing protocol that for many years was unique to Cisco networking environments. Created and championed by Cisco, it didn’t get any traction in the standards bodies in the early days, because there were already enough interior gateway routing protocols around according to some. EIGRP just didn’t interest enough of the right folks to get it on the standards track.

Fast forward to today, and Cisco has been able to publish EIGRP as an informational IETF draft known popularly as Open EIGRP. Two of the authors of that draft, Donnie Savage with Cisco and Russ White, join Ethan Banks on the Packet Pushers podcast for a discussion of Open EIGRP in this show.

We talk through a number of issues.

  • Why did Cisco open EIGRP up?
  • Why did Cisco hold back on stub?
  • What’s the reaction of the community been?
  • What non-Cisco vendors are interested in EIGRP?
  • Are we going to see an open-source implementation of EIGRP now?
  • And perhaps most cynically of all…what’s in it for Cisco?


Open EIGRP IETF Draft Text (

Cisco Open EIGRP Informational Draft FAQ (

Why is Cisco Bothering with “Open” EIGRP? (Anthony Burke,

Thoughts on Open EIGRP (Russ White,

Ethan Banks
Ethan Banks, CCIE #20655, has been managing networks for higher ed, government, financials and high tech since 1995. Ethan co-hosts the Packet Pushers Podcast, which has seen over 3M downloads and reaches over 10K listeners. With whatever time is left, Ethan writes for fun & profit, studies for certifications, and enjoys science fiction. @ecbanks
Ethan Banks
Ethan Banks
  • Donnie Savage

    Ethan, it was a wonderful experience and a please to work with you! PacketPushers is awesome :-)

  • Michael Adams
    • riw777

      Babel is close, but not the same. I don’t really want to get into a huge discussion about advantages and disadvantages (I’ve actually discussed some with the authors), but I don’t (personally) think Babel is as clean as EIGRP from a protocol level point of view. EIGRP is, at the algorithm level, a very elegant and clean design –something that’s hard to appreciate, perhaps, from the straight, “I just configure and deploy this stuff,” side of things, but I still (somehow) think elegance makes a difference.

      Of course, I’m an old timer at this point, and a “part time coder” in a past life or two, so I’m a little odd, probably. Or maybe I’m just a little odd anyway… :-)

      • Juliusz Chroboczek

        To be fair, Babel is designed so that the very same protocol works both on wireless mesh networks and is efficient on normal, prefix-routed wired networks, so it doesn’t quite play in the same league as EIGRP. EIGRP is certainly a fine protocol, and if you look at the introduction to RFC 6126, Babel’s designer has only nice things to say about it.

        In a wired network, the main differences are (1) that EIGRP has the complex “active” phase which Babel avoids by using its seqno mechanism, and (2) that EIGRP uses a reliable transport while Babel doesn’t. Both of these mechanisms are unlikely to work well in a mesh network.

        • riw777

          I think complexity is in the eye of the beholder… I find Babel’s sequence number system more complex than EIGRP’s query mechanism, and actually a good bit less flexible in the protocol’s ability to limit the scope and range of queries.

          As for reliable transport –I actually think a reliable transport would be better in a mesh network, if it is tuned correctly. There are ways to tune reliable transport so it’s not so chatty that would make it better suited across environments.

          BTW –EIGRP has be deployed without modifications in real live MANET environments without any problems. I don’t know if the MANET environment is actually quite so demanding as we like to make out sometimes… But that’s another discussion. :-)

          • Juliusz Chroboczek

            > EIGRP has be deployed without modifications in real live MANET environments

            Since EIGRP is a very well-designed protocol, I’m quite willing to believe that it can be made to work in a pure MANET. Still, since it doesn’t have any provisions for link-quality estimation or for dealing with single-interface routers, I find it somewhat surprising that an unmodified version of EIGRP “just works” in a MANET. There’s something mysterious going on here that I’d like to understand.

            Do you have any references to that work?

          • riw777

            I can, but I can’t tell you about them, or I’d have to shoot you. :-)

            I suppose it all depends on how stringently you draw your requirements. As I’ve worked on MANET networks over the years, I’ve often found that people draw very stringent requirements, but when you dive in and actually see what’s required, or when you dig into the use cases, you most often find the requirements just aren’t as stringent as they appear at first –and most of the MANET networks I’ve worked on EIGRP would handle, from a scaling perspective, “out of the box.” I can imagine networks where it wouldn’t –OTOH, I can imagine the changes needed to make it work. :-)

            Single interface routers –they might have one physical interface, but they’ll still have multiple logical interfaces if they’re a router at all. If there’s only one logical interface, it’s a host –and even there, EIGRP would work on a host to gather routing information.

            Interface metrics –EIGRP has had the ability to carry different metrics, and use those metrics, from day one. Wide metrics have expanded this capability to the point of being able to carry almost anything. As for interacting with the interface — the interface/rp interfaces I know of aren’t tied to a single control plane, but are specifically designed so any control plane on the box can use the metrics. This was a long, drawn out discussion in the MANET working group, but generic mechanisms won out (though you might note there is some cisco IP in this area –some of which I’m involved with).

            So, yes, I would say that for most MANET networks, EIGRP would work “out of the box.” It’s quite possible to make it work in a much wider swath of MANET environments with some work, most of which probably isn’t major. We might enter the world of higher difficulties when we reach into the sensor world, but that is another problem altogether.



          • Juliusz Chroboczek

            Thanks for the explanation, Russ.

            Please let me know when you can share your raw data and source code without either requiring an NDA or shooting me afterwards. Not that I don’t believe you, but it is my job to repeat other people’s experiments when I find the results puzzling.

            — Juliusz

  • Paul Gear

    I have to admit that i’m one of the skeptics, and came into the show expecting boredom and a waste of my time. I came out thinking much the opposite, and it will be interesting to see how it progresses over the next few months/years. I agree that taking the open/proprietary selection criteria off the table is a positive move, and i’m glad to hear “We’re not finished yet” from Cisco.

    I still maintain some of my cynicism, and maintain that the time for Cisco to have done this was around 2000 as Donnie suggested. (And no offense Donnie, but being in routing and not having heard of Quagga is like being in servers and not having heard of Linux.)

    And (still speaking as the skeptic), what Cisco would need to do to gain my mind share is start with one of their implementations (i suspect IOS XE would make the most sense) and contribute that code to the quagga project so that the university in question starts with a known-viable code base. Otherwise, what i predict will happen is that there’ll be one company with good implementations of EIGRP, and 5 or more with really bad implementations, and EIGRP will remain in exactly the same position it is today: a good choice for Cisco-only shops (which other people assure me actually exist!).

    Interoperability with servers and firewalls is a big deal. I use injection of /32s into OSPF from Intel boxes as a way of implementing anycast in my IGP.

    • Donnie Savage

      LOL – yes well aware of Quagga. I play with it when it was called Zebra (goofed around adding the eigrp code it for fun but could not release it). What I am still unsure of is how to pronounce it – is is it “Cog-ga” “Quag -ga” “Kag-ga” or as is often miss pronounce it “Quag-ma” Either way, i am excited to here there are folks looking to implement EIGRP :-)

      As for the good/bad implementations; This remains one of my personal concerns and I would not want to see “bad” implementations out there. I don’t know we will ever give-away our implementation (not my call), but there are things we can do to help venders make solid implementations and provide interop guidance. Cisco has begun the process of how to address this, and I expect more information will be made available in the future

  • luismg

    Ospf isn’t choose because is open, is the one because it’s multivendor. It has areas, no one network goes away and lets querry all routers in the network.
    OSPF its link state, EIGRP is distance vector.

    • riw777

      I think that’s a crucial difference, actually –and one people don’t often “grock.” If other vendors implement EIGRP (and I think they will), then we could see some serious work back on the distance-vector side –which, IMHO, would be a healthy thing.

  • Mikkel Markussen

    I wasn’t impressed with the creative dance around the subject of not releasing stub functionality. When you’re trying to make the case for a routing protocol, you can’t really answer questions about the lack of important functionality by saying “well, consider all of these other ways we could’ve made the protocol even worse!”

    I also don’t understand the argument posed that OSPF being open isn’t a “technical” part of the considerations involved in selecting an IGP. Vendor interoperability is one of the prime technical considerations in most networks.

    Then there was the song and dance about Cisco not having a profit motive in releasing EIGRP, followed in the same breath by claims that it’s what their customers wanted. It’s obvious that Cisco aren’t releasing a subset of EIGRP out of the goodness of their hearts.

    Sorry to sound so pessimistic and cynical, but I’m really not convinced.

    • riw777

      I’m not certain I would characterize Donnie’s answer that way… It’s more along the lines of, “there’s work going on here, there’s no point in releasing it ’til we’re done.” I do think stubs will be released at some point, though it’s hard to tell just how it will be released (I’m not a part of that decision process at this point! –though I’ve been pushing for this for a long number of years).

    • Donnie Savage

      Hi Mikkel, Obviously you have never heard me sing or seen me dance; trust me its not a pleasant thing to watch :-)

      But humor aside; I agree 100% with you – interop is a consideration within a network and one that has to be look at in the totality of the requirements.

      However I have also personally talked to customers who told me EIGRP was the best solution for them, but they were deploying OSPF as they has a mandate to use only open solutions. I personally think, customers should be able to pick the technology that works for them. Period.

      For me, thats the reason I pushed for Open-EIGRP; Pick what works for you.

  • What Lies Beneath

    Having little to lose or the lack of an obvious direct financial benefit for Cisco does not, by default, make this an altruistic act. Despite that praise to the guys for pushing for this now and in the past. I’m sure most will be happy to have the option of using EIGRP available (if required) in open or closed network platforms like Quagga, Vyatta or ZebOS and possibly also from the larger incumbent vendors. Many will benefit in time I would have thought.

    I have to say listening to the show was a bit like going back in time. On a lighter note, who had all the pets?