Revisiting Open EIGRP

I have previously blogged here and over at Packet Pushers about EIGRP not really being open. Since then I have changed my mind and albeit EIGRP is not quite there, I would consider it moving forward in a next generation deployment.

I reached out to Donnie not long after the original post. I asked some questions of the motivators behind the change. I firstly appreciated Donnie’s response and it make me ponder about Cisco’s stance. Donnie and his team believe in EIGRP and its ability to really posture EIGRP to be a real next generation routing protocol. IPv6 and large, scale driven networks are great use cases for EIGRP and this is the angle that is approached. An ideal deployment would be an IPv6 green-field deployment which takes full advantage of the power of EIGRP. The feature parity is almost there versus IPv6. What is an important consideration too is the fact that DUAL computes IPv6 without modifications.

In the Packet Pushers EIGRP episode with Donnie and Rus, as a listener all I wanted to do was rush out and get some EIGRP going in my lab. The enthusiasm for the future of the product was heartening. The strong commitment to the development of the product to be competitive in the IGP space was superb. If the energy exuded in the interview comes to fruition then OSPF could have some competition. What also got me also intrigued was the ability to apply network smarts via EIGRP. The notion of costing routes based on the actual power cost was crazy. It is a power, cost aware network, based upon routes. Adding another layer of smarts which as far as I am aware would be the first of its kind.

I have definitely come around to looking at EIGRP again when the time for an upgrade comes. Due to the proprietary argument becoming null it is good to see a viable competitor to OSPF. Donnie did mention on numerous occasion that Stub features and others would be eventually standardised so when this occurs uptake will increase. So don’t quite rush out and replace your production network but a transition to EIGRP could be something worth considering in your 2 year plan. Even with SDN coming, which honestly, seems to be focussing on the DC, we still will need routing protocols no matter the level of software abstraction. SDN isn’t replacing everything.

If you’re interested in more EIGRP goodness then check out the BRKRST-2336. 


6 thoughts on “Revisiting Open EIGRP”

  1. It may be “open” now, but is that any use to me if no other major vendor has yet implemented it? I would want to see implementations from several other large vendors first, before I would begin to consider using it. Will we see that within 2 years? And would you trust those implementations? Lots to think about about before I would reconsider my current position.

    @mbushong’s had some great posts recently about open vs interchangeable

    1. Thanks for the comment. You are right with it being “open”, and I see the gradual release of code and the drafts as a step forward. I see Donnie’s enthusiasm as a good indicator. Would I upgrade based on a magic 8 ball prediction? No. Surely no, but having the man who writes the draft and leads the EIGRP think tank does give clout to round two of discussions.

      There is still a small issue with their best feature, stubs, being under licence still. I wouldn’t go so far as to say, replace everything with EIGRP today. Moving forward, if Cisco stick to their roadmap and look to make EIGRP the best it has ever been, then maybe, it may be to important to not overlook EIGRP.

  2. I doubt we will see it implemented by Juniper or HP. EIGRP will always be seen as a Cisco protocol.

    I do agree a lot with what Donnie is saying that EIGRP does not get considered because it is not open. Like he says, how open is really OSPF? Sure there is a RFC for it but we know nothing about the source code being used.

    People still hold on to old beliefs that there are lots of issues with SIA routes etc. Mostly it was people designing wrong or having underlying issues to begin with but it’s been solved for a long time. EIGRP with feasible successor has been doing for ages what OSPF and ISIS are now doing with Loop Free Alternate (LFA). The difference is that LFA is in the FIB but still the concept is almost the same.

    Anyone choosing a protocol should do so on technical merits and not on FUD. Just like both Windows, Linux, Unix, Solaris or whatever have their use cases.

    It’s great to see that EIGRP is still being developed. EIGRP Over The Top (OTP) seems like a nice feature for enterprises that want to control routing themselves instead of running IGP/BGP with ISP.

    1. I agree on the implementation by other vendors; stained with a history of “it’s theirs”.

      Where EIGRP has technical advantages over other protocols, a strong design may not back it up. Therefore arguments can be used to drive a wedge between the functional use of EIGRP vs another IGP. The FUD factor is high due to years of any thorough argument being muted by “proprietary”

      EIGRP Over The Top looks to be a nice feature where LISP has a nice use case.

      Cheers for the comment Daniel

  3. Why would other vendors even consider to implement EIGRP when there are already proven and implemented alternatives available? The fact that Cisco is now opening up does not make it suddenly a viable alternative. Cisco is 10+ years ahead with development, so unless they are open sourcing their code spreading only the specifications does not ensure interoperability.

    But do we really care? On the user side, companies that are locked in already by EIGRP will stay locked in, while the others won’t even consider using it for the same reason. This will not change until both vendors and users are switching. Since this is a chicken and egg problem I don’t expect it to fly off.

    1. Maybe I am mixing reality versus what I want.

      EIGRP will always be associated with Cisco. I do doubt I will see EIGRP picked up fully or at all by Juniper/HP/. What I do see though is a business argument being dispelled. I am a pure Cisco shop and use OSPF due to this requirement to use Open where possible. From a design perspective EIGRP would suit some functions better.

      I don’t suggest immediately jumping across and throwing all the eggs into one basket either. If the roadmap continues forth as it does, all I see is competitive alternate to existing solutions. The maths of the protocol and features such as EIGRP OTP do provide compelling arguments if the underlying landscape is appropriate.

      Time will tell I suppose. Thanks for commenting Ronny.

Leave a Reply

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