Over at the Cisco Blog in the Architect & DE discussions (where some serious content exists), Donne Savage writes about the perennial debate. “EIGRP vs OSPF”
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.
Yes, EIGRP is self configuring and this is a good thing.
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.
This is why you learn OSPF and how it works. 🙂
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.
Ok, so the last time I saw an network in SIA was 2005 but I take his point. EIGRP fixed the SIA problem with protocol modifications a long time ago.
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.
I’m comfortable with OSPF. But only because the future of the network is multivendor – not at the network level but when interoperating with firewalls, mainframes, Linux-based appliances. performing route redistribution just to support EIGRP doesn’t make sense to me.
Go and read the article.