Why Is Cisco Bothering with “Open” EIGRP?

My first taste of networking came via the Cisco Learning Academy. I did my CCNA and the old school ROUTE, and it did a pretty good job of praising the joys of EIGRP. You learned EIGRP early on, and it was always made to sound superior. The skills tests and all the labs revolved around EIGRP. It seemed awesome at the time. OSPF was referred to like “that Uncle” that everyone has and is scared to have around their partner.

I came across an article earlier that stated EIGRP was to be made an open standard. Cisco finally must be getting a bit sweaty under the collar if they are doing this. They know most of their customer base uses OSPF. Juniper, their fiercest opponent, have proliferated OSPF users due to a high number of router sales. This has tipped the scales WELL in favor of OSPF.

Upon seeing the article title, I got excited. EIGRP would be open. A draft is released to the IETF, EIGRP becomes ratified, and some vendors may pick it up. Most arguments against EIGRP recommend avoiding it due to vendor lock-in. No one wants to be stuck with a proprietary protocol. This is compounded by the fact that financially viable, sound alternatives exist to Cisco these days. Back when EIGRP was the best thing since sliced bread, there wasn’t much competition. Like Cisco licensing, a big stumble occurred in the second paragraph.

What Cisco should have said in its announcement was that, “Cisco EIGRP is now an open standard, but…” The article goes on to list three things that irked me right away, and gave me the notion to rename their article.

  1. Advanced features of EIGRP (namely stub areas) will not be released to the IETF.
  2. Informational RFC allows Cisco to retain control of the EIGRP protocol.
  3. EIGRP is still technically proprietary.

So, the advanced features of EIGRP are not being released – no stub areas, no way to control propagation or logically define areas. No DMVPN topologies that will scale. This is one of the primary reasons you would use EIGRP. In a past life I did a deployment, and I’ve labbed many since. It works and works well, but you can learn to rearchitect around it. Why do that? Because other vendors offer such a better price point that it is cheaper to migrate than pay to be locked in, a giant area to be sad about. Sure, you could run different processes and redistribute between but you shouldn’t have to just because Cisco wants to hold the keys.

Cisco’s best interests will always guide the EIGRP protocol. This could potentially lead to stifled innovation from the outside, as they have final say. On the one hand, they ask vendors to develop, but still tightly control the best features. I do understand protecting customers who’ve invested in it, but why bother with this?

Which really leads to number three. The best features are tightly controlled. That’s not really open source, now is it? I expected it to be rather open, but there are caveats. I have nothing against protecting interests, but wouldn’t you just not bother if you’re imposing these limitations? Has Cisco not learned from its previous endeavors – namely ISL and PAgP, but many more that others can point out – that proprietary means lock in? Lock in equals no-no. NO means NO.

Maybe I am being a bit too harsh. I have reached out to Donnie Savage with a hope to chat more about the draft. I believe my thoughts will remain much the same, but I’m always looking for another perspective. I appreciate Cisco giving this a go, this open standard thing with EIGRP. I could be missing something, but it seems this one, so far, is a misstep.


Cisco EIGRP Informational RFC FAQ


  1. says

    I’m no Cisco apologist, by any stretch of the imagination, but to be fair to Cisco regarding ISL and PAgP (and HSRP and CDP), there was nothing else on the market at the time. The “open” functional equivalents didn’t come until much later.

    I forget who said it, but “EIGRP allows you to remain clueless longer”. Route filtering is one area (no pun intended) where EIGRP does excel, compared to OSPF.

    I do believe that if one chooses to deploy EIGRP at this point in time, that it will make much more sense to go with the vendor that originated it, rather than what is bound to be a buggy 1.0 implementation. I’d be surprised to see many (if any) vendors pick this up.

    • says

      I agree with the likely bugginess of early code released on the open spec. I’ll further add that if an open source implementation of EIGRP means that you can’t implement stubs, then it’s of limited use from my point of view. Without stub, the ability to scale EIGRP large gets a lot harder.

      That said, not everyone needs to scale an EIGRP domain up to hundreds or thousands of routers, and so keeping the active query domain reined in is less of a concern. Could Vyatta make use of EIGRP? Sure. What about Packet Design, who, IIRC, licensed EIGRP from Cisco to include in their Route Explorer product? You betcha. What about other vendors who could use EIGRP as a foot in the door to help a new customer off of the Cisco teat? I think perhaps.

      I still agree with Anthony’s larger point. If you’re going to open source something, then commit. Cisco didn’t. And while I’m sure there’s a point in the informational RFC, I’m a little fuzzy as to what that point is without some “inside baseball” that could explain it.

      • says

        I’ll try replying again as the first one sent my client in to a fit. Have just spoken to a couple of routing guys at CL and as expected, they state that the stub area feature is primarily used as part of a DMVPN configuration which is Cisco proprietary but that isn’t the point.

        The point is, who cares about this? Even if it was fully open, who would implement it and from those that would, who would be put off by the exclusion of stub areas? It feels like a non-event to me.

      • Alexandra Stanovska says

        I still think Cisco is doing it for the sake of making other vendors appliances compatible with routing protocol. Line of thought: I have EIGRP and Cisco routers. Then I get Other Vendor’s firewall which does not play nice with EIGRP. I have to use redistribution. It gets tiresome after a while so I decide to migrate to OSPF completely. Migration to OSPF opens my network up to considering any other than Cisco deices when next wave of upgrade comes in. Giving other vendors some chance of making their device compatible with my routing solution removes the hurdle of redistributions an migration. Next time I buy Cisco as it will play nicely with all network devices while stying with my simple easy EIGRP.

        • says

          I see the point you are making. I just keep thinking in my head though the pros and cons list of OSPF vs Basic EIGRP. OSPF wins on many fronts. Now if it were OSPF vs Advanced EIGRP (open) then we would be having a very different discussion.

  2. Morgan Humes says

    I have to agree. Either its an open protocol and it is driven by the community or it simply isn’t. Looks like it is still vendor lock in as the other vendors (if they even choose to implement it) will be stuck with the bare minimum instead. Meanwhile, if Cisco had truly open sourced it they still would have the strongest implementation, and the loudest voice at the table when it comes to the direction of the protocol.

    Sounds like Cisco is just using this to convince people to use EIGRP instead of OSPF, at least until those people actually investigate what is going on behind the smoke and mirrors over at Cisco.

    • says

      I like your point Morgan, if Cisco wanted to they could still have the loudest voice. It seems to me like they are sowing the seeds of conversion by not giving EIGRP the full open standards treatment. Oh you like EIGRP? That’s cute. Buy our routers to enjoy it all year long!

  3. Alex Davydov says

    I’m wondering how many Cisco patents it’s carrying. Even VRRP depends on some patents, that’s why OpenBSD people made their own solution for first-hop redundancy. Also, IP SLA was recently released as informational RFC (https://tools.ietf.org/html/rfc6812) and this has gone largely unnoticed, it seems.

  4. Sum Yung Gai says

    Nah, after reading about the particulars, I’ll stick with OSPF. It works, I can build very scalable networks with it, and it’s truly multi-vendor without any hidden “gotchas” that way. I like my network infrastructure protocols and such to be truly open standards, not “pseudo-open” like Cisco’s move here. Matter of fact, given how good OSPF is, I just don’t see the business case for Cisco to not publish the full EIGRP spec without any monkey-business like this.

  5. Rich says

    I imagine they’re releasing it as an RFC because patents are only good for 20 years. Cisco introduced EIGRP in 1993 and vendors will be free to implement it whether Cisco approves of them doing so or not. This way, Cisco can continue to exert some control over EIGRP.

  6. luismg says

    what about the stupid metric calculations? who uses the 5 K’s ? what about the query for the active routes? not any area limitations, well yes the stub areas… not opened. I won’t use eigrp on large deploys

  7. ktokash says

    An update to this would make a great article. I dug a little but it’s a little more work than I can justify out of curiosity to run down and pester various vendor reps to find out what they’re doing with EIGRP, if anything, 2 years later.

Leave a Reply

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