Two interior gateway protocols, one decision that shapes every redesign, merger, and multi-vendor negotiation that follows.
Pick the wrong IGP for a greenfield network and you don’t find out for eighteen months — right around the time you’re acquiring a company that runs the other one, or onboarding a non-Cisco vendor into what was supposed to be a single-vendor fabric. OSPF and EIGRP both converge fast, both scale to thousands of routes, and both show up constantly in job descriptions and certification blueprints for OSPF vs EIGRP design decisions. The choice between them is rarely about which protocol is objectively “better.” It’s about which constraint you’re willing to live with: EIGRP’s dependence on Cisco gear, or OSPF’s stricter area discipline and heavier link-state overhead on constrained links.
Get this wrong at the design stage and you inherit years of redistribution boundaries, summarization filters, and two engineers who each insist their protocol is the sane one. Get it right, and the interview question “walk me through how you chose an IGP for a 200-site network” stops being theoretical.
The Concept, From First Principles
Both protocols solve the same problem — build a loop-free view of the network and pick the best path to every destination — but they solve it with different algorithms and different amounts of information sharing.
OSPF is a link-state protocol (RFC 2328 for OSPFv2/IPv4, RFC 5340 for OSPFv3/IPv6). Every router floods Link State Advertisements (LSAs — small packets describing a router’s directly connected links) to every other router in the same area. Each router ends up with an identical link-state database for that area and independently runs Dijkstra’s Shortest Path First (SPF) algorithm against it. Nobody trusts a neighbor’s routing table — everybody builds their own map from the same raw data.
EIGRP is what Cisco documentation calls an advanced distance-vector protocol, though the field has long treated it as a hybrid. Routers exchange topology information about known routes and their computed metrics via the Diffusing Update Algorithm (DUAL — the loop-avoidance algorithm at EIGRP’s core), documented in RFC 7868. Unlike classic distance-vector protocols, EIGRP routers keep a topology table with not just the best path (successor) but pre-computed backup paths (feasible successors) that satisfy a mathematical loop-avoidance test called the feasibility condition — meaning DUAL can fail over to them without a recomputation cycle.
The practical difference: OSPF routers know the entire topology of their area and calculate paths themselves. EIGRP routers know the best and feasible-backup paths their neighbors have advertised, and trust DUAL’s math to keep the result loop-free without needing the full topology.
RFC 7868 was published in 2016 as Informational, not Standards Track — it documents EIGRP’s behavior for interoperability purposes, but Cisco still controls the protocol’s evolution. If a vendor RFP requires an IETF Standards Track IGP, EIGRP does not qualify; OSPF does.
How It Actually Works — Mechanics, Metrics, and the Decisions That Matter
Path selection: SPF versus composite metric
OSPF’s cost is simple by design: reference bandwidth divided by interface bandwidth, summed hop by hop. The default reference bandwidth is 100 Mbps on both Cisco IOS and Juniper Junos, which means every interface at or above 100 Mbps computes to a cost of 1 unless you raise the reference bandwidth — a step most production 10G/40G/100G networks require and frequently forget.
router ospf 1
auto-cost reference-bandwidth 100000
Sets reference bandwidth to 100,000 Mbps (100 Gbps) so cost differentiates correctly at higher interface speeds.
EIGRP’s metric is a composite formula using bandwidth and delay by default (load and reliability are configurable but rarely used in modern deployments because they introduce metric instability). Classic EIGRP metrics used 32-bit values; “wide metrics,” introduced with EIGRP named mode, extended this to 64-bit to accommodate today’s high-bandwidth interfaces without integer overflow. If you have routers running both classic and wide metrics in the same autonomous system, verify metric compatibility explicitly — this is a documented gap, not a theoretical one.
Convergence behavior
This is where the two protocols genuinely diverge in character. OSPF convergence on link failure depends on how fast the LSA floods and how large the area’s SPF run is — larger areas mean bigger SPF trees and more churn per event. EIGRP’s DUAL, when a feasible successor already exists in the topology table, fails over to it near-instantly with no query process at all. When no feasible successor exists, the route goes Active and DUAL sends queries to all neighbors — and this is EIGRP’s most infamous failure mode.
The SIA (Stuck-in-Active) problem
If a neighbor is slow to reply to a query — because it’s overloaded, because the query has to propagate several hops away, or because of a WAN link with asymmetric delay — the route can sit in Active state past the SIA timer (3 minutes by default) and EIGRP will reset the neighbor relationship entirely, which can cascade into more queries and more resets. This is the single most-cited operational complaint about EIGRP in large or WAN-heavy topologies, and it is the direct motivation behind EIGRP stub configuration and summarization at aggregation points — both of which exist specifically to keep queries from propagating into parts of the network that can’t answer them fast enough.
router eigrp NETDAEMONS
address-family ipv4 unicast autonomous-system 100
af-interface default
summary-address 10.10.0.0 255.255.0.0
exit-af-interface
topology base
exit-af-topology
exit-address-family
Named-mode EIGRP summarization at a branch aggregation point — reduces the query fan-out that leads to SIA.
Area design versus autonomous-system boundaries
OSPF’s area hierarchy is architectural, not optional at scale. Area 0 (the backbone) is mandatory, every non-backbone area must connect to it (directly or via a virtual link, which you should treat as a last resort, not a design tool), and LSA types 3/4/5/7 exist specifically to control what information crosses area boundaries. Stub, totally stubby, and NSSA (Not-So-Stubby Area — a stub area that still permits limited external route injection) area types trade external route visibility for smaller link-state databases and faster SPF runs on lower-end hardware at the edge.
EIGRP has no equivalent mandatory hierarchy. It scales through summarization and stub declarations at the network’s discretion, which is more flexible for organic, non-hierarchical topologies but also easier to get wrong — nothing forces the discipline the way OSPF’s area 0 requirement does.
Where Engineers Get This Wrong
- Treating EIGRP stub as a security feature. It isn’t. eigrp stub tells a router to advertise only connected and summary routes and to never act as a transit path — its purpose is to stop unnecessary queries reaching spoke sites, not to enforce a trust boundary. Route filtering and authentication are separate concerns and need separate configuration.
- Leaving OSPF reference bandwidth at the default in a 10G+ core. Any two links at or above 100 Mbps look identical to SPF unless reference bandwidth is raised. This produces suboptimal or unpredictable path selection that looks like a routing bug but is actually a config default nobody revisited since the network was 1G.
- Forgetting that EIGRP’s feasibility condition, not just “having a backup path,” determines instant failover. A route only qualifies as a feasible successor if its reported distance from the neighbor is strictly less than the local router’s feasible distance. Plenty of topologically obvious backup paths fail this test and end up going Active anyway — engineers who assume “there’s another path, so it’ll be instant” get blindsided by a query storm on exactly the failure they thought was covered.
- Multi-area OSPF without matching LSA type discipline at the boundary. A stub area with an ASBR (Autonomous System Boundary Router — the router that injects external routes) redistributing external routes into it is a contradiction — stub areas explicitly block type-5 LSAs. This shows up as “redistribution isn’t working” tickets that are actually area-type misconfigurations.
- Redistributing between OSPF and EIGRP without seniority and loop control. Mutual redistribution without route tagging and filtering is one of the most reliable ways to create a routing loop in a dual-IGP network — and dual-IGP networks are common after acquisitions. Tag routes at the redistribution point and filter on those tags going back the other direction, every time.
- Assuming EIGRP metric compatibility across classic and wide-metric routers without checking. Named-mode EIGRP defaults to wide metrics; classic (autonomous-system) mode config uses 32-bit metrics. Mixed environments — common mid-migration — need explicit verification, not an assumption that “it’s still EIGRP so it’ll just work.”
Design Considerations for Production Networks
For a single-vendor Cisco enterprise network with a straightforward hub-and-spoke or reasonably flat topology, EIGRP’s simpler configuration model and faster convergence via feasible successors are a legitimate advantage — this is precisely why it persists in so many campus and branch designs that predate the multi-vendor push of the last decade.
For anything crossing vendor boundaries — and increasingly, that’s every network that touches a cloud provider’s virtual router, a Juniper-based service provider handoff, or a security appliance from a non-Cisco vendor — OSPF’s status as an open, Standards Track protocol is not a preference, it’s a requirement. You cannot run EIGRP between a Cisco router and a Juniper MX; you can run OSPF between almost anything.
At WAN scale, the calculus shifts again. EIGRP’s query-based convergence model was designed for LAN-speed neighbor responses; low-bandwidth, high-latency WAN links (satellite backhaul, certain SD-WAN overlay tunnels, some MPLS L3VPN CE-PE links) are exactly where SIA events cluster. Aggressive summarization at every WAN aggregation point and EIGRP stub on every spoke are not optional hardening — they are the baseline configuration for any hub-and-spoke WAN running EIGRP.
Vendor-specific behavior worth naming explicitly: Juniper’s OSPF implementation is fully RFC 2328/5340-compliant but its CLI and default timers differ from Cisco IOS-XE in ways that matter during a multi-vendor OSPF adjacency negotiation — hello/dead interval mismatches are the most common first-time adjacency failure between the two platforms, and both sides must match explicitly rather than relying on defaults being the same. EIGRP interoperability outside Cisco is limited in practice; while RFC 7868 permits third-party implementation, production-grade EIGRP support on non-Cisco platforms is not something to assume without testing against the specific vendor and software version in question.
A Real-World Scenario
A 40-site retail chain runs EIGRP across a hub-and-spoke WAN — one regional data center as the hub, each store as a spoke over a mix of MPLS and broadband SD-WAN transport. Growth adds fifteen more stores in eighteen months, and the network team starts seeing intermittent neighbor resets during business hours, worse on the broadband-backed sites.
The root cause: no route summarization was configured at the hub, so every spoke has full visibility into every other spoke’s routes, and a single flapping broadband circuit at any spoke triggers queries that fan out to all forty-plus neighbors. Some of those neighbors — particularly ones on slower SD-WAN tunnels — don’t reply inside the SIA window, and DUAL starts tearing down and rebuilding adjacencies that had nothing to do with the original flap.
The fix has two parts. First, eigrp stub on every spoke router, since spokes never need to be a transit path for other spokes’ traffic — this alone stops query propagation from reaching sites that can’t answer fast enough. Second, summarization at the hub toward the spokes and from each spoke’s local subnets going upstream, shrinking the topology table every router has to hold and query.
This is also the point where a design review should ask a harder question: does this network’s continued growth trajectory make a redesign around OSPF areas, or a shift to a proper SD-WAN control plane with its own routing abstraction, worth the migration cost? EIGRP wasn’t wrong for forty sites. Whether it’s still the right choice past a hundred, with an increasingly heterogeneous transport mix, is a legitimate design conversation — not a protocol failure, a scale-and-transport-mix question.
The Certification Angle
OSPF vs EIGRP sits squarely inside CCNP Enterprise Core (ENCOR 350-401) domain 3.2, which explicitly asks candidates to compare EIGRP and OSPF routing concepts — distance-vector versus link-state behavior, load balancing, path selection, metrics, and area types — and separately to configure OSPFv2/v3 in multi-area environments. It’s also foundational to CCIE Enterprise Infrastructure, where the lab exam expects fluent, fast configuration of both under time pressure, often combined with redistribution between them.
Here’s the gap that catches people who’ve only studied for the exam: the blueprint tests whether you can compare the two protocols and configure a clean multi-area OSPF topology or a straightforward EIGRP autonomous system. It does not — and cannot, in an exam format — test what happens when your feasible successor calculation doesn’t behave the way the textbook example suggested because your actual topology has asymmetric bandwidth, or when a stub area’s LSA restrictions block a redistribution point nobody flagged during design. Production networks accumulate exceptions that certification labs are deliberately built to avoid, because a repeatable exam needs a clean, generalizable scenario.
If you’re studying this topic specifically: don’t stop at “OSPF is link-state, EIGRP is distance-vector.” Be able to explain why a specific route did or didn’t become a feasible successor, calculate OSPF cost with a non-default reference bandwidth, and identify from a topology diagram where LSA type restrictions will block redistribution. Those are the questions that separate someone who memorized the comparison table from someone who can debug a production topology table at 2 a.m.
Recommended Study and Lab Resources
Cisco Modeling Labs (CML) Personal — roughly $199/year for 20 concurrent nodes, running genuine Cisco IOS-XE/NX-OS images. This is the resource that actually matters for this topic: you cannot develop real intuition for DUAL’s feasible-successor logic or OSPF’s LSA propagation by reading about it — you need to build a multi-router topology, break a link, and watch show ip eigrp topology or show ip ospf database change in real time. The free CML-Free tier (5 nodes) is enough for the core OSPF/EIGRP scenarios in this article; Personal is worth it once you want multi-area or larger redistribution topologies.
Boson ExSim-Max for CCNP ENCOR — a paid practice-exam product (subscription pricing; confirm current rates directly with Boson) widely regarded as one of the closest third-party simulations to Cisco’s actual exam question style, including scenario-based routing questions. Useful specifically because generic practice-question banks tend to test recall of the OSPF/EIGRP comparison table; ExSim-Max tests whether you can apply it to a topology you haven’t seen before, which is closer to the real exam experience.
INE or CBT Nuggets for structured video instruction — both are legitimate options serving slightly different needs. INE (subscription-based, roughly $700+/year) goes deeper technically and is the stronger choice heading toward CCIE Enterprise Infrastructure, with scenario-heavy labs beyond CCNP scope. CBT Nuggets (subscription-based, roughly $500+/year) is generally the more approachable, better-paced option for consolidating CCNP-level OSPF/EIGRP fundamentals before moving on. Either is worth a free trial before committing to a full year.
If your target is the vendor-neutral end of the spectrum rather than a Cisco-specific track, the core concepts here — link-state versus distance-vector behavior, metric design, area/hierarchy trade-offs — carry directly into CompTIA Network+ and into JNCIA/JNCIS-level OSPF coverage on the Juniper track, even though EIGRP itself is out of scope there.
A Note on This Article
This article reflects research and hands-on engineering experience current as of the publish date. Protocol behavior, exam blueprints, and vendor documentation can change — verify anything decision-critical against current RFCs and vendor documentation before acting on it.
Any pricing mentioned for certification or lab-tool resources is indicative and can vary by subscription tier, regional pricing, promotional offers, or changes made by the vendor after publication.
Availability of specific training platforms, lab tools, or certification programs is indicative and subject to change by the respective vendors.
Verdicts and recommendations in this article are the independent opinion of the NetDaemons team, formed from professional experience and available public information. Readers should evaluate their own network’s requirements before making design or purchasing decisions.
netdaemons.com — Network Engineering Deep Dives
Team NetDaemons Verdict
The following reflects the independent assessment of the NetDaemons team.
If your network is staying single-vendor Cisco and reasonably flat, EIGRP’s simpler operational model is a defensible choice — but only with stub and summarization designed in from day one, not retrofitted after your first SIA-driven outage. If there’s any realistic chance of multi-vendor growth, acquisition, or cloud interconnects on the horizon, default to OSPF and get the area design right the first time — it is far cheaper to build correctly than to migrate out of later.
