When choosing between EIGRP and OSPF as an enterprise IGP, what design trade-offs separate the two protocols?
answer
- backup path ready or recomputed
- where a summary may sit
- equal versus unequal cost
- areas as forced hierarchy
- one vendor or many
basics
~20 sEIGRP gives precomputed feasible-successor failover, summarisation on any interface and implementation-provided unequal-cost load balancing, but is essentially single-vendor; OSPF is an open standard whose shared area database and area hierarchy demand more design but give visibility and interoperability.
solid answer
~50 sEIGRP keeps a precomputed loop-free backup, the **feasible successor**, so a failure often needs no recomputation at all; OSPF floods the change and every router in the area reruns SPF. EIGRP can summarise on **any interface**, while OSPF summarises only at **area border routers** (and at the redistribution point for external routes), so OSPF needs an area plan up front. EIGRP implementations can load-balance over **unequal-cost** feasible successors; OSPF as specified uses only equal-cost multipath. Against that, OSPF is an open Standards Track protocol (RFC 2328, RFC 5340) that every router in an area sees the same topology through, which helps troubleshooting and traffic engineering, while EIGRP is described only by Informational RFC 7868 and is effectively one vendor's protocol. Pick EIGRP for a single-vendor estate that values simple, fast failover; pick OSPF where interoperability and a standard matter.
go deeper
Recall the headline pairs: feasible successor versus SPF rerun, summarise anywhere versus at area borders, and an open standard versus one vendor's protocol.
Explain why each difference exists: the feasibility condition makes backups loop-free, an identical area database forbids summaries inside an area, and SPF uses only shortest paths.
Tie each trade-off to a failure: unbounded EIGRP queries, an OSPF area too large to summarise, or a second vendor arriving in an EIGRP estate.
Weigh operational simplicity and fast local failover against interoperability and visibility for a specific estate, including the cost of changing course later.
## The comparison at a glance Both protocols are **interior gateway protocols (IGPs)**: they distribute reachability inside one organisation. The interview question is not which is "better" but what each design costs and buys. (The general theory of distance-vector and link-state protocols is a separate topic; this answer stays on the two concrete protocols.) | Dimension | EIGRP | OSPF | |---|---|---| | Specification | RFC 7868, Informational (2016) | RFC 2328 (STD 54), RFC 5340 for IPv6 | | Failure with a backup | Switches to a **feasible successor** locally | Floods an LSA; routers in the area rerun **SPF** | | Failure without a backup | **Diffusing computation**: queries and replies | Same flood-and-recompute as always | | Summarisation | On **any interface** | At **area border routers** (ABRs); externals where redistributed | | Load balancing | Equal-cost, and unequal-cost as an implementation feature | **Equal-cost multipath** only (RFC 2328 §16.8) | | Topology knowledge | Neighbours' reported distances | Full map of each attached area | | Hierarchy | Optional, built from summaries | Enforced: backbone area plus other areas | | Multivendor | Few implementations | Widely implemented | ## Failover An EIGRP router keeps, for each destination, the neighbours that satisfy the **feasibility condition** — their reported distance is strictly lower than the router's feasible distance — which proves they are loop-free. When the best neighbour (the **successor**) fails and a **feasible successor** exists, the router installs it at once and the route stays **passive**; nobody else has to compute anything. Without one, the route goes **active** and the router queries its neighbours, which can take long in a large unbounded network. An OSPF router detects the failure, originates a new LSA, floods it through the area, and every router in that area runs the SPF calculation again. Routers in other areas see only changed summary-LSAs, which RFC 2328 §16.5 processes incrementally. Modern OSPF converges fast, but the work is network-wide within the area rather than local. ## Summarisation and hierarchy Every router in an OSPF area must hold an identical link-state database, so nothing inside an area can be summarised. RFC 2328 §3.5 lets **ABRs** advertise configured **area address ranges** into other areas, and redistributed routes can be aggregated where they enter OSPF (an implementation feature, or Type-7 address ranges in an NSSA under RFC 3101). The result is a design discipline: you must plan areas and an addressing scheme that fits them before summarisation pays off. EIGRP has no areas. A summary can be configured on **any interface** of any router, which makes it easy to retrofit; and because a router that knows a destination only through a summary need not join the search for it, summaries also **bound the query scope** (RFC 7868 §3.1). ## Load balancing - OSPF installs only shortest paths; several of them with equal cost give **ECMP**. A longer path carries no loop-freedom proof in OSPF, so it is never used. - An EIGRP feasible successor is loop-free by the feasibility condition even though its metric is higher, and RFC 7868 notes it may carry traffic when **unequal-cost load sharing** is active. The knob that turns this on (a variance multiplier) is an **implementation feature**, not part of the RFC. ## Visibility and operations - In OSPF every router in an area can show the area's full topology, which helps troubleshooting and is the basis for traffic-engineering extensions such as RFC 3630. - An EIGRP router knows only what its neighbours report, so finding where a route came from means following it hop by hop. - OSPF's areas force a hierarchy that scales predictably; EIGRP scales well only when summaries and query boundaries are designed in deliberately. ## How to decide 1. **Is the estate multivendor, now or likely?** If yes, OSPF. 2. **Is sub-second local failover without tuning worth a supplier dependency?** If yes and single-vendor, EIGRP is defensible. 3. **Can the addressing be laid out by area?** If not, OSPF summarisation will be weak until it is. 4. **Do paths of unequal capacity need to share load?** EIGRP implementations can; with OSPF you equalise costs or accept ECMP only. A good answer names both sides and ties the choice to the network in front of it, rather than declaring a winner.
- Why can OSPF not use a longer path for load sharing the way EIGRP implementations can?SPF yields the shortest paths, and only those are known to be loop-free in OSPF; a longer next hop might route traffic back through this router. EIGRP's feasibility condition proves that a feasible successor's path does not loop back, so even a higher-metric path is safe to share load across.
- Does EIGRP's lack of areas mean it cannot scale to a large network?No, but its scaling must be designed. Without summaries or query boundaries, a lost route with no feasible successor can trigger queries across the whole network. With summaries at aggregation points, and the implementation's stub feature at the edge, query scope stays small and large EIGRP networks run well.
saying these in an interview costs you the question
- OSPF also keeps feasible successors as precomputed backup routes.
- OSPF can summarise routes on any router, just like EIGRP.
- Unequal-cost load balancing is defined in RFC 7868 as a protocol rule.
- EIGRP failover is always faster than OSPF, whatever the topology.
- EIGRP must be split into areas to scale, the same way OSPF is.