Different answer on EIGRP and OSPF convergence time:
1. I think you can configure both to converge extremely fast, but if I had all Cisco routers, I would prefer EIGRP because of it’s flexibility regarding the design. OSPF has it’s own rules (area 0, filtering/summarizing only on abrs, etc.)
However, with OSPF ip ospf dead-interval minimal hello-multiplier 4 you can set 4 hellos per second (gives hello interval = 250ms), adjust dead timer to 1 second and you will have a pretty fast convergence. I don’t know whether with EIGRP you can get under 1 second for a neighbor to fall.
2. If EIGRP has a feasible successor route in it’s topology table and the active route in the route table fails then it is almost instantenous in terms of failing over to the new route because EIGRP does not need to query any other routers or do any internal calculations, it simply installs the new route.
3. EIGRP convergence time increases as more routes need to be processed. However, there is a far bigger impact for networks with EIGRP feasible successors than for networks with no feasible successors.
Subsecond timers are not available for EIGRP. Experimentation suggests that setting the EIGRP timer below 2 seconds can lead to instability. The recommended EIGRP minimum timer settings are 2 seconds for hellos and 6 seconds for the dead timer. Subsecond settings are not an option, While OSPF Subsecond hellos are supported DeadInterval-minimum 1 second
Hello multiplier is used to specify how many Hellos to send within 1 second
EIGRP is now an IETF draft so it’s no longer proprietary. See http://tools.ietf.org/html/draft-savage-eigrp-01
If we look at EIGRP with default settings and OSPF with default settings and there are multiple loop free paths to a destination then EIGRP will converge much faster because it keeps what are called feasible successors in it’s topology database. These are basically loop free alternatives to the best path. EIGRP also has summarization at any point in the network. It also has stub feature which is useful when you don’t want to use a router for transit. Commonly deployed in DMVPNS. EIGRP is also less confusing than OSPF because it does not have different network types and EIGRP is easier to deploy in hub and spoke scenarios.
EIGRP uses a flat network without areas, this can both be an advantage and disadvantage.
OSPF is obviously an open standard so it’s the logical choice if you have multiple vendors. It can perform well but it requires that you tweak SPF timers because by default in IOS there is a 5 second wait before running the SPF algorithm. OSPF uses areas which means you can segment the network more logically. OSPF can only summarize between areas. OSPF is link state so it has a better view of the entire network than EIGRP before it runs the SPF algorithm. Network administrators will usually be more comfortable with OSPF because it’s more commonly deployed.
Both protocols have advantages and disadvantages. But the common answer that EIGRP should be discarded because being proprietary is not entirely true any longer.
From a practicle perspective I would say that in the case of EIGRP vs OSPF, OSPF always wins for the following reasons:
Everyone always mentioned that EIGRP is faster than OSPF using default settings. If you deploy either protocol without reading about them and use their default settings, then you clearly don’t know what you are doing in my opinion. Why would you deploy default settings without knowing what they are, and when you do realise what they are you realise that OSPF supports BFD and becomes lightening quick (as does ISIS).
Because OSPF like ISIS is based on TLV values, it has been extended quite a lot. It has support for extensions like MPLS-TE and GMPLS.
As I mentioned above, OSPF and ISIS have been extended quite a lot and extension drafts are being written fairly regularly and will continue to be. EIGRP doesn’t have many of the advanced options these two do.
OSPF scales better than EIGRP with its use of areas however, I don’t think this really matters either (like the convergence time aregument, due to BFD). Not many people are running 10k routes in one area in OSPF. Typically I would use an IGP for fast routing within a given part of a network, but ultimately iBGP carries all the internal routes. Every single router doesn’t need every internal route in its RIB sourced via OSPF if you have hundreds or thousands or routers, some of them are so far away (topologically speaking) it’s worthless knowing about them.
Lastly there is the obviously reason that EIGRP is/was a Cisco proprietary technology. Although this has recently been submitted into a draft for other software vendors to start incorporating, it’s too late (I believe). No currently running network is going to waste huge sums of money switching from some other IGP to EIGRP, and I don’t know why a new network would consider it (if you are going to be mixing Cisco equipment with non-Cisco). Simply because non-Cisco equipment that supports OSPF has been doing so for years. The code is tried and test, many bugs fixed, oodles of information on line etc. It will take years for EIGRP to catch up (if it isn’t too late already!).