EIGRP vs OSPF – Take 2

September 13, 2012 - 19 Comments

First a bit of disclosure.  I have worked for Cisco over 15 years, much of that time as the lead developer for EIGRP. I think I understand its strengths and weakness’ very well, and have spent a great deal of energy minimizing them.

I often find comparing protocols similar to the old “tab vs spaces” or “emacs vs vi” wars.  There are valid reasons to choose one over the other and in the grand scheme of things it comes down to a wash; often preference or ‘religion’.  EIGRP seems to victim to this .  I mean where are the “ISIS vs OSPF” debates?  With EIGRP, network engineers that love it – love it. Those that don’t, well they don’t. Arguing its merits often results in an equally long list of “yea but” demerits.

For example, most everyone would agree eigrp is “simple to deploy”, but detractors would argue that simplicity leads to sloppy designs and only though complexity can we force network engineers to “do their job” and design the network properly.

Simplicity is a good thing, and I take exception to the idea the tool has to be complex.  I believe “making the “tool” simple to use allows one to focus on what’s important – the network design – and not the “owners manual”. Yes, you can hire consultants to read the owners manual for you, but are they going to be there at 3AM when things go awry?

And what about IPv6?  As you think ahead, how much of the knowledge you have invested in your IPv4 IGP can be applied to the IPv6 IGP?  Do the configs look alike? Act similar? What about available feature parity between IPv4 and IPv6? Do you have a single “router” process for each? With EIGRP the answer is YES!  The same concepts and design decisions you made for EIGRP when you designed your IPv4 network directly applies to IPv6.

When you design, or redesign, your network, you need to plan that growth independent of the routing protocol to be use. EIGRP makes it simple; use proper addressing and proper summarization. Improper addressing schemes can lead to the inability to summarize, resulting in large query domains and topology databases

One might assume OSPF, with its areas, are the key, but the same lack of planning for EIGRP can pelage OSPF in the same way. Setting up areas with lots of  routers, or leaking excessive information across ABRs, impacts the database size, and computational workload. Conversely, the as the number of nodes (routers) grow in a network, the work OSPF has to do increases, forcing more OSPF areas so it can scale to, forcing multiple areas.

Multiple areas then force you to return to the core to make sure its properly design, so that in the event of a failure, you don’t end up with your Area-0 partitioning and stranding other areas.  EIGRP does not have these issues. In and EIGRP network, the number of nodes and routes can grow unbounded. You only need to remember one little thing – plan for summarization and summarize.  Its that simple.

Many large customers have deployed eigrp worldwide, have 10 of thousands of nodes, and 100s of thousands of prefixes, and enjoy sub-second convergence, all with no issue. Also, unlike EIGRP summarization, the creation of OSPF areas can be over done, which could negatively impact your network.

EIGRP is not without its warts. Yes, it once had the “dreaded” Stuck in Active, or “SIA” issue. Everyone has heard of it. Some have seen it, but largely this issue was fixed in 1998.

I often refer it as the “boogie man” of eigrp; lurking to scare the young network engineers, it’s past reputation far exceeding today’s reality.  One could argue they are even “diagnostic” in that it almost always indicated an underlying transport issue, which IS causing your issues, and should be addressed anyway.

Dijkstra? Dual? Which is more or less complex? Guess it boils down to what you understand.  With OSPF you just find the shortest path though your network and use it.  With EIGRP you just find a path that cost less that your cost to the network and use it.

Both are as simple, or as complex, as you want to make them. One thing EIGRP does to NOT have is; 11 route types.  With EIGRP it is routes are either internal or external. OSPF, on the other hand, has 11 LSA types, not counting the vendor propriety ones.

Not only is EIGRP simple, its able to scale in your core, it also has the ability to scale at the edges. Prior to 1999, both EIGRP and OSPF tended to top out around 300 peers.  The EIGRP stub feature moved eigrp to the forefront allowing it to double the peers to 600. Over the years since then, OSPF has moved upwards to the 600’ish range, while EIGRP has moved in excess of 1200. In modern DMVPN designs, EIGRP has managed to move past 3500 peers, and its believed even this is not the best EIGRP can do.

Speaking of propriety. In the enlightened world of 2012, most folks consider it “evil”, and being “open” should improve a solutions reliability and stability.

Well DUAL is not proprietary; the spec is out there for any-and-all to read. The EIGRP packet definitions are in Wireshark.  If improved “reliability and security” comes with access to the protocol specifications then I would say EIGRP and OSPF are on par here.

Also, being “open” only helps you *IF* you have open code.  Have you seen the source code for OSPF running in your router? Yes, the IETF draft is out there for all to see, but you can’t see the implementation of that draft. You can’t, for example, spoke the venders source code looking for security exploits. So where is the improved reliability? or the improved security?

But lets also be honest and admit, this openness also comes at a cost. Back when I was the manager for EIGRP Development, I use to tell customers at Cisco Live “If you need something implemented in EIGRP you only need to convince Cisco and we do it”.

Proof in point. In 1998, I went to Networkers Philadelphia and attend a BOF (Birds of a Feather session). There I talked to some customers about some issues. By 1999, Cisco shipped the EIGRP Stub feature.  Had this been OSPF, I can’t say how long it would have taken the idea to make it thought the IETF, but I am certain it would not have been accomplished in less than a year.

Other innovations in EIGRP have also lead OSPF, as well as innovations in OSPF that have not made its way into EIGRP. Which protocol you use depends greatly on which one has the feature you need, and which one you like.

In the EIGRP vs OSPF debate, remember, both are great protocols, each with its strengths and its weaknesses; neither are the end-all-be-all protocols. Lets face it, if it were; the other protocol would not exist. Look at your network design, determine which of the protocols, EIGRP,  OSPF, or ISIS, you are comfortable with, and deploy it.

For more information see:

So tell me what you think!  Is there a specific feature of EIGRP or OSPF that leads you to pick one over the other?

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.


  1. Well the interesting content! Congratulations, I have a blog and I know how difficult it is to make a quality content!

  2. With reference to people mentioning EIGRP as a design choice with 3560/3750 IPBASE. I note with the -X models at least, the OSPF Routed Access feature is also in IPBASE. It seems comparable so it goes back to the other reasons for choosing!

    • Yes, this is correct. However please keep in mind that OSPF as offered has a licensed limit of 200 routes, no fast hellos, and a single routing process. The route counts also apply for EIGRP, but with EIGRP its easy to filter selected routes ,ensuring your within the software licensee, without have to move the router into a separate AS/Area

  3. Before EIGRP hit our scenes we had IGRP, Interior Gatway Routing Protocol.Cisco developed IGRP in the mid-1980s as an answer to the limitations of RIP, the most significant of which are the hop count metric and the 15-hop network size. IGRP calculated a composite metric from a variety of route variables and provided “knobs” for weighting the variables to reflect the specific characteristics and needs of the network. Although hop count is not one of these variables, IGRP did track hop count, and could be implemented on networks of up to 255 hops in diameter.

    • While EIGRP does not route based on “hops to destination”, EIGRP does keep track of it and can be used to poison a route if it exceed a limit. The default is 100 Hops, but this is configurable up to 255.

  4. I’ll add my voice to Ryan Malayter’s above, I would have a much easier time recommending EIGRP if it were multi vendor. I think this would actually benefit Cisco. I would know it COULD work with other vendors, but would work with Cisco best. So it would incentivise me to recommend it and Cisco, but ensure in those cases where Cisco wasn’t the best choice still be supportable.

    • Same issue facing LISP. The internet drafts are Cisco only as are the implementations. When evaluating protocols at the ‘informational’ and ‘experimental’ draft stage I’d suggest confirming that more than one vendor is contributing and implementing.

  5. “I mean where are the “ISIS vs OSPF” debates?” – Try the NANOG mailing list.

  6. Donnyie,

    I choose EIGRP soely for the “receive-only stub” feature.

  7. “Well DUAL is not proprietary; the spec is out there for any-and-all to read. The EIGRP packet definitions are in Wireshark. If improved “reliability and security” comes with access to the protocol specifications then I would say EIGRP and OSPF are on par here.”

    I really hope you were giggling when you wrote that.

    Wireshark “guesstimate” code for packet formatting and a non-normative algorithm description are NOT the same as an implementable RFC.

    There are ZERO EIGRP implementations available from other vendors. Now, CSCO is still the market bully in route/switch, but that seems to be changing. More imortantly, there are a whole lot of other devices (firewalls, load balancers, even servers!) that should participate in the routing protocol. This is possible with OSPF (and ISIS to a far lesser degree).

    EIGRP is a cool protocol, but at this point EIGRP is not a competitive advantage for Cisco. You’ve lost the lock-in battle, all reasonably-sized networks are multi-vendor. So just hand all the specs over to the OpenBSD guys, RAND or freely license any patents, and let them write an open implementation and an RFC.

    An open EIGRP could turn into an advantage for CSCO again. You can say “We have the best/most featureful EIGRP implenetation, but of course it interoperates with all other vendors EIGRP” versus “we have EIGRP, but it doesn’t matter because you can’t/won’t use it because you’re not dumb enough to lock yourself in to one vendor or be forced into ikcy route-redistribution scenarios.”

    • Thank you for your reply.

      I agree the older wireshark decoder was “gueesstimate”, which is why I coded the current wireshark EIGRP packet decoder. It is commented, and properly handles all EIGRP TLVs. This includes not only the original TLVs, but also the Multi-Topology and the latest Multu-Protocol TLVs (which by the way I designed and coded 🙂 used to support wide metrics and SAF(service-family).

      No, this does not constitute a “formal” specification, but that was not the point. There is lots of information available on EIGRP and how it works, some of it created by Cisco employees, some by independent parties. But reliability and security is not guaranteed simply by having access to information; Reliability and security comes from rigorous peer review, positive testing, as well as negative testing. Over the recent years Cisco has placed a lot of effort in testing and hardening EIGRP to try and ensure EIGRP is both reliable and secure.

      You’re also correct to say there are no other commercial implementations, however it has been licensed to a number of venders, and I know of at least two educational implementations; one of which was published in “ICNS ’10 Proceedings of the 2010 Sixth International Conference on Networking and Services Pages 340-34”. None of that changes your basic point. EIGRP is proprietary. Some customers place multi-vender solutions paramount, and that’s a perfectly valid business decision. One that has to be balanced with the technical realities of network design.

      In the end, chose the protocol that meets YOUR requirements; be that technical, business, or simply personal preference.

  8. I love EIGRP so much

  9. Great article! Always found people arguing over protocols, which one the best, etc…As you pointed out it should begin with design goals, questioning and review, and not with you like best.
    I do catch myself over ways we believe it is best to do, but it pays off thinking of one or two other ways and describe honestly, proving points for all of them. Personally, I like keeping simple and elegant whenever is possible.

    My company runs very large, global deployment, using EIGRP locally at sites and BGP in global links, so each office could be managed by former local teams, so they can announce a larger prefix and reuse smallers as they like locally (this started 15 years ago) and is envolving. Tables were larger in 98 requring 16MB RAM on 2501s of that time, instead of 4MB (around 1000 routes). But even at time, not big issue. OSPF could be used locally but current only to redistribute into non-Cisco gear. No issues so far.

  10. I admit to not having read all of your documents so this may have already been mentioned, but one additional advantage that recently swayed a customer to use EIGRP over OSPF is due the inclusion of EIGRP-stub mode on IP Base (old SMI) software images on 3560/3750 switches. Thank you for sharing your input on the differences between the two, there were certainly a number of facts that I had not thought of and will help with decisions in the future. EIGRP just seems to make the most sense in an all Cisco environment and worst case one can always enable redistribution.

    • Thanks for the kind comments Jason, Yep remember well when we added stub to the ipbase images.
      Something that I was glad to see happen for customers! In the future I am seeing some new and
      exciting things happening with EIGRP – I am sure you will see those topics coming up in future
      presentations I offer (after their release of course)!

      • That’s much welcomed feature, specially for sites that have deployed 3560/3750 with PoE for IP Telephony, so they can have some redudancy with two L3 links and reduce VLANs, maybe some EtherChannels. Sometimes it is just design policy requiring few of them, so pretty much usefull feature on Base feature set.

  11. I found your recent IOS Advantage webinar (A Closer Look: Comparing Benefits of EIGRP and OSPF) very insightful, Donnie! To anyone that missed it, here’s a link to the slides and recording: https://communities.cisco.com/docs/DOC-30498