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:
- Enhanced Interior Gateway Routing Protocol (EIGRP)
- Open Shortest Path First (OSPF)
- Intermediate System-to-Intermediate System (IS-IS)
So tell me what you think! Is there a specific feature of EIGRP or OSPF that leads you to pick one over the other?