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.

5 thoughts on “EIGRP to be part-open but why bother?

  1. The sad fact is that many engineers and managers simply do not consider vendor lock-in when proposing their designs. The see ‘features’ not ‘lock-in’. Occasionally the proprietary feature is the right design choice.

    I don’t know if this is just PR gimmick, and I’d like to read more about Cisco’s motivations. Had this been done 10 years ago then maybe EIGRP would have a chance to grow market share, but I think that ship has sailed.

    It takes a very long time and a lot of investment for routing protocol implementations to mature, even with well defined standards. Even if EIGRP was fully opened, I can’t see how others could justify the effort in developing an EIGRP implementation.

    1. Indeed. I could see a transition from OSPF to Full EIGRP during a IPv4 to IPv6 migration. Even if you went OSPF to OSPFv3 you still would have dual protocols, so EIGRP could be an alternative. That is, if it was full and open.

      Good point regarding lock in – most people don’t think until it is too late.

      1. John is definitely correct regarding the lock-in issue. However, let me offer an alternative viewpoint.

        What if, several years down the road when SDN is actually viable for the enterprise, the protocol choices matter less? If the network is just some programmable blob that ebbs and flows from a configuration standpoint based on a click here or a CLI command there, will OSPF/IS-IS/EIGRP/RIP really matter? Add to the fact(Not really a “fact”, but this is the case in my experience) that many customer networks are just small islands of limited IGP instances duct-taped together by BGP. By islands, I mean a few dozen devices running an IGP. Well below OSPF/EIGRP/IS-IS scalability issues.

        Will it matter for the larger networks out there like Google, Amazon, Facebook, etc? Of course it will. For the average enterprise network, it really won’t.

        Maybe Cisco is attempting to seed the marketplace with EIGRP, knowing that it takes a few years to gain traction?

        Just my 2 cents. I may be 100% wrong and I reserve the right to take my own comments out of context to defend my own incorrectness. I also love conspiracy theories. Good post though Anthony!

  2. The only positivum I see while cisco maintaining steering wheel is that EIGRP may avoid feature creep, unlike OSPF. EIGRP has always been viewed as the simpler one but doing its job (route enterprise networks, fast). They missed the train though, I do not think it will gain much traction now as main protocol, though, rather other vendors implementing it into appliances just so they work nicely with cisco routers and avoid EIGRP/OSPF redistributions nightmares just because I have different firewall.

Leave a Reply

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