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.
- Advanced features of EIGRP (namely stub areas) will not be released to the IETF.
- Informational RFC allows Cisco to retain control of the EIGRP protocol.
- 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.
About Anthony Burke
