skip to content

Why do network designers usually pick OSPF over EIGRP when an enterprise network runs routers from more than one vendor?

level: juniorimportance: should knowfreq 35%

answer

  1. who wrote each specification
  2. Standards Track versus Informational
  3. published only in 2016
  4. few independent implementations

basics

~20 s

OSPF is an open IETF Standards Track protocol (RFC 2328 for IPv4, RFC 5340 for IPv6) implemented across router vendors, while EIGRP was one vendor's protocol until Informational RFC 7868 in 2016 and still has few other implementations.

solid answer

~40 s

OSPFv2 is an Internet Standard (RFC 2328, STD 54) and OSPFv3 for IPv6 is on the Standards Track (RFC 5340), so a mixed estate can rely on every router speaking the same protocol and interoperating. EIGRP began as one vendor's protocol; its design was only published in 2016 as RFC 7868, an *Informational* independent submission that makes no claim to be a standard. Few other implementations exist, and several features people think of as "EIGRP" — stub routing, the variance knob for unequal-cost load balancing — are that vendor's implementation features, not in the RFC. So in a multivendor network, or one that may become multivendor, OSPF avoids lock-in and interoperability risk; EIGRP stays reasonable in an estate that is, and will stay, single-vendor.

go deeper

for a junior

Recall that OSPF is an open IETF standard, while EIGRP started as one vendor's protocol and was only published as an Informational RFC in 2016.

for a middle

Explain what Informational status means in practice: a published design that anyone may implement, no standards process behind it, and few implementations beyond the originating vendor.

for a senior

Show how the standards gap shapes real estates: border redistribution where an EIGRP island must remain, platform choice for new routers, and separating RFC behaviour from vendor features.

for a principal

Frame the IGP choice as supplier risk against technical convenience, and decide whether an estate's EIGRP dependency is worth a migration programme.

## Two protocols, two very different documents An **interior gateway protocol (IGP)** is the routing protocol that routers inside one organisation's network run to learn each other's prefixes. The two that enterprise interviews compare most often are **OSPF** (Open Shortest Path First) and **EIGRP** (Enhanced Interior Gateway Routing Protocol). Their technical designs differ, but the first question a designer of a mixed network asks is simpler: *who defines the protocol, and who implements it?* | | OSPF | EIGRP | |---|---|---| | Specification | RFC 2328 (OSPFv2, IPv4); RFC 5340 (OSPFv3, IPv6) | RFC 7868 | | Status | RFC 2328 is an Internet Standard (STD 54); RFC 5340 is Standards Track | Informational, an independent submission | | Published | 1998 (RFC 2328), 2008 (RFC 5340) | May 2016 | | Origin | Designed in the IETF as an open protocol | One vendor's protocol for many years before publication | | Implementations | Widely implemented across router, Layer 3 switch and firewall vendors | Few beyond the originating vendor | The name says it: the "O" in OSPF is **Open**. RFC 2328 obsoletes RFC 2178 and is the IETF's standard for OSPF over IPv4; RFC 5340 obsoletes RFC 2740 and defines OSPF for IPv6. ## What "Informational" means for EIGRP RFC 7868 opens with a status note: it is *not* an Internet Standards Track specification and is published for informational purposes, through the independent stream, with the RFC Editor making no statement about its value for implementation. In practice: - **The document describes a design; it does not create an interoperability regime.** There is no IETF working group evolving it and no standards process behind it. - **Anyone may implement it**, but few have, so a second vendor's EIGRP is the exception rather than the norm. - **The RFC records implementation choices too.** Several passages note what the originating implementation does, for example which of two permitted actions it takes when a neighbour is stuck in active — a reminder that the text documents one product's behaviour as much as a protocol. - **Not everything called "EIGRP" is in the RFC.** Stub routing, the variance multiplier used for unequal-cost load balancing, and the vendor's configuration styles are implementation features. RFC 7868 describes DUAL, the packet types, the composite and wide metrics and the TLV encodings. ## Why it matters in a mixed estate A routing protocol is only useful if every router in a routing domain runs it. In an estate with more than one vendor: 1. **Interoperability.** Two OSPF implementations are expected to form adjacencies and agree on routes because both follow RFC 2328. With EIGRP, the second vendor's platform may simply not support it. 2. **Lock-in.** Choosing EIGRP effectively commits the routed core to one supplier, which weakens procurement and makes replacing a platform a routing migration as well. 3. **New kinds of router.** Virtual routers, firewalls and Layer 3 switches that join the domain are far more likely to speak OSPF. 4. **Skills and tooling.** OSPF knowledge transfers between platforms; EIGRP knowledge is tied to one vendor's documentation. 5. **Operations and audit.** Monitoring, automation and compliance checks that understand OSPF's standard structures work across platforms, while EIGRP support in such tooling is narrower. The usual compromise when one part of the network must stay on EIGRP is a boundary: EIGRP inside the single-vendor part, OSPF (or BGP) elsewhere, and redistribution between them at a few border routers. That works, but every redistribution point is a place where routes can loop and where tags and filters must be maintained. ## When EIGRP is still a defensible answer Standards are not the only criterion. EIGRP's **feasible-successor failover** switches to a precomputed loop-free backup without any network-wide recalculation, EIGRP can **summarise on any interface** rather than only at area borders, and it needs no area design. An estate that is single-vendor today and will stay so, or one that already runs EIGRP well, may reasonably keep it. The honest interview answer names the trade: technical conveniences versus a dependency on one supplier. ## How a strong answer is framed - Lead with **standardisation and implementations**, then the technical differences. - Say **Informational** and **2016** precisely: RFC 7868 exists, so "EIGRP is proprietary and unpublished" is out of date, but "EIGRP is now an open standard" is wrong too. - Label vendor features as such rather than presenting them as protocol rules. - Keep the distance-vector versus link-state theory as a separate topic; the multivendor question is answered without it.

  • Since RFC 7868 is public, why not just ask every vendor to implement EIGRP?
    Publication lets vendors implement EIGRP but obliges none to. RFC 7868 is Informational, outside the Standards Track, with no working group maintaining it, and several widely used features live only in the original vendor's implementation. A designer cannot plan a network around support that may never ship, while OSPF is already implemented everywhere.
  • If a single-vendor site running EIGRP is acquired into an OSPF estate, what are the realistic options?
    Either keep EIGRP inside the acquired site and redistribute at a small number of border routers, with route tags and filters to stop feedback loops, or migrate the site to OSPF. Redistribution is quicker to set up but is a permanent maintenance cost; migration costs effort once and removes the dependency.

saying these in an interview costs you the question

  • EIGRP is still completely proprietary and has no published specification.
  • RFC 7868 made EIGRP an IETF Internet Standard like OSPF.
  • Stub routing and variance are defined in RFC 7868 itself.
  • Every router vendor supports EIGRP, so multivendor support is not a concern.
  • The choice between them is only about distance-vector versus link-state theory.