IGP selection - OSPF vs IS-IS vs EIGRP

The interior routing protocol choice. Usually decided by multivendor needs, scale, SR/TE direction, and operational familiarity - rarely by raw performance, since all three converge fast when tuned.

Requirement / business driver

A stable, scalable interior routing foundation that fits the customer's vendor mix, growth, and operations team - and supports whatever overlay/TE strategy comes next.

Constraints

• Technical: scale and area/level design; convergence targets; SR/SRv6 underlay plans.
• Operational: which protocol does the team actually run well?
• Business: multivendor procurement vs single-vendor lock-in.
• Dual-stack: how each handles IPv4 + IPv6 (separate vs single process).

Options

• OSPF - link-state, area-based, broadly multivendor; separate OSPFv2 (v4) and OSPFv3 (v6).
• IS-IS - link-state, level-based, SP-favoured, single protocol with multi-topology for v4+v6; the usual choice for SR/SRv6 underlays.
• EIGRP - advanced distance-vector (DUAL) with feasible successors; simplest to run, fast, but effectively Cisco-only; named mode carries v4+v6.

Comparison

Tradeoffs

• OSPF wins as the safe multivendor default; cost is rigid area design and dual processes for dual-stack.
• IS-IS wins at large scale and for SR: flexible level/summarization design, less flooding, single multi-topology instance; cost is lower team familiarity.
• EIGRP wins only in all-Cisco shops that prize simplicity and fast convergence and accept lock-in; it is a dead end for SR and multivendor.

Recommendation

Default OSPF for a multivendor enterprise; choose IS-IS for large-scale or SR/SRv6 underlays; use EIGRP only in committed all-Cisco environments valuing operational simplicity.

Justification

Convergence is near-parity (LFA/TI-LFA, feasible successors), so the decision rides on openness, scale, SR direction, and operations - and on those axes the recommendation follows directly from the stated requirements rather than from a benchmark.

Decision tree

IGP design over topologies (and OSPF area types)

IGP behaviour and the right tuning depend heavily on the topology:

• Hub-and-spoke (e.g., DMVPN): set the correct OSPF interface network type (point-to-multipoint avoids DR/BDR problems over NBMA); for EIGRP make spokes stub (with stub route leaking only where a spoke must transit) so the hub stops querying spokes and query scope stays bounded.
• Full-mesh: watch adjacency and flooding scale; summarise and segment into flooding domains.

OSPF area types control which LSAs flood - which is how you bound a flooding domain and hide topology (Network hierarchy and topologies, Route aggregation and summarization):

A totally NSSA border area (campus/DC -> WAN/Internet edge) is a common simplification when no requirement dictates the external path. Caveat: with multiple ABRs, OSPF elects one ABR (highest RID) to translate type-7 -> type-5, which can force a suboptimal path - so misaligned area design causes black-holing or suboptimal routing.

EIGRP's flooding-domain analog is the query domain. When a route loses its successor and no feasible successor exists, the route goes active and the router queries its neighbors; the diffusing computation then waits on the slowest replier. A reply lost or delayed - a congested WAN circuit, an overloaded neighbor, a long query chain - holds convergence hostage until the stuck-in-active (SIA) machinery intervenes: an active timer of roughly three minutes, an SIA-query at half-time demanding proof the neighbor is still working the problem, and on expiry the drastic remedy - the unresponsive neighbor's routes are flushed (older implementations reset the adjacency outright), turning one remote hiccup into a wide reconvergence event. The design defense is to bound how far queries travel, and there are exactly two boundaries: the stub role above, and summarization - a router that knows only the summary answers "no more-specific route" immediately instead of propagating the query onward, so every summarization point shrinks the query domain and with it the SIA blast radius. In EIGRP, summarization placement is therefore query scoping, not just table-size hygiene (Route aggregation and summarization).

Where the boundary lives - ABR/level placement and the parallel-link trap

Area types decide what floods; where you put the border decides who does the hiding. With ABRs at the core edge, area 0 is the core itself: small, stable, easy to plan, with crisp aggregation points, and the distribution layer's redundancy mesh stays invisible to the backbone - at the cost of pushing complexity into the outlying areas and leaving the distribution layer with little to do (the design quietly collapses toward two layers). With ABRs in the distribution layer, each leaf area becomes small and simple and summarization sits exactly where that layer's job description says it should - at the cost of an area 0 that now spans core plus distribution and grows and churns with the network. Mixing both per region is legitimate; what matters is choosing deliberately, because the border placement fixes where aggregation, policy, and blast-radius control live. IS-IS asks the same question with a kinder default: a small network can run one flat routing domain, and it should be L1/L2 everywhere rather than pure L1 - because an L1 pocket can be pushed into an existing L2 domain later without disruption, while retrofitting an L2 core into an L1-only network cannot; the core-as-L2 design then mirrors OSPF's core-as-area-0.

One trap follows any border you draw: OSPF prefers an intra-area path over an inter-area path regardless of cost, so a link between two ABRs that runs parallel to the boundary drags traffic the long way around through whichever area the link is not in - a one-hop backbone link loses to a multi-hop 512k detour purely on route type. Static routes around it do not scale and a virtual link is a last resort, not a design; the clean resolutions are structural - a parallel link per area, or boundaries drawn so no single link parallels them (Route aggregation and summarization).

Protocol-specific design levers

A few behaviours are unique to one protocol and shape the design:

• EIGRP variance is the only IGP unequal-cost load-balancing mechanism: set a multiplier and EIGRP installs feasible paths whose metric is within (variance x best metric), so a slower second path carries traffic proportionally. OSPF and IS-IS load-balance equal-cost only, so unequal links there mean tuning metrics or accepting one path.
• OSPF virtual links stitch a discontiguous area to area 0 (or repair a partitioned backbone) by tunnelling through a transit area. Treat the need for one as a smell of broken area design - fix the hierarchy rather than rely on virtual links permanently.
• IS-IS elects a DIS on a LAN with no backup DIS and pre-emptive election (highest priority wins immediately), and every router forms a full adjacency via the DIS pseudonode - unlike OSPF's DR/BDR where non-DR routers peer only with the DR/BDR. IS-IS DIS churn is cheap, so the design rarely needs DR-style tuning.

• Split horizon is the distance-vector ground rule: never advertise a route out the interface it was learned on (a reverse route is either a waste or, after a failure, a loop-in-waiting); the poisoned reverse variant advertises reverse routes as unreachable instead - stronger, faster loop breaking bought with larger updates - and even then split horizon only breaks two-router loops, not loops around a wider ring. The design consequence lands exactly on the hub-and-spoke overlays above: a hub learns every spoke's routes on the one multipoint (mGRE/NBMA) interface it must re-advertise them out of, so split horizon silently blocks spoke <-> spoke reachability via the hub - relax it on the hub interface, or better, advertise a hub summary/default to the spokes, which solves reachability and query scope in one move (Tunneling technology selection).
• Graceful transit removal: setting the IS-IS overload bit tells the domain to stop using this router as transit while its directly connected destinations stay reachable - set on-startup so a rebooting core node does not attract traffic before BGP/LDP have converged, and set manually to drain a node for maintenance; OSPFv3's R flag (router not active for transit) provides the same capability. This is the link-state cousin of the forward-through family in Fast convergence techniques: not surviving a failure, but making planned events non-events. In OSPFv2 the same drain is max-metric router-LSA - advertise transit links at infinite cost, optionally on-startup, so neighbours route around while stub reachability holds. The companion guardrail is database overload protection (max-lsa): cap how many LSAs the process accepts, so a runaway redistribution flood (a full BGP table leaked by accident) isolates the offending router instead of melting every LSDB - the volume-side complement to the tag-and-filter loop discipline in Redistribution and route manipulation.

IS-IS hierarchy mechanics - the attached bit and L2->L1 leaking

In IS-IS the router, not the interface, belongs to an area - so area borders fall on links between routers, never inside one: an L1-L2 router simply holds both LSDBs and stitches them, where OSPF makes the ABR itself the border. Identity comes from the NET: a variable area address (1-13 bytes) that keys L2 (inter-area) routing, a fixed 6-byte system ID that keys L1 (intra-area) routing and must be unique within the area, and a selector byte of 00. The protocol's famous flexibility is the TLV discipline underneath: capabilities travel as typed containers, and an implementation that does not recognise one skips it and keeps parsing - which is how IS-IS absorbed IPv6, wide metrics and multi-topology without a new protocol version.

Route flow through the hierarchy is asymmetric by design: L1 routes are injected upward into L2 automatically, but nothing flows down. An L1 area is effectively OSPF's totally stubby area out of the box - L1 routers see no inter-area prefixes at all. They find the exit because the L1-L2 border sets the attached (ATT) bit in its L1 LSP once it holds LSPs from another area, and every L1 router installs a default route toward its closest attached router. "Closest attached" is not "best exit": with two borders, traffic that should leave on the metric-40 path exits via metric-60 because that border is nearer - and when the nearest attached exit has no onward route to the destination, the pathology escalates from suboptimal to blackhole or loop. The lever is L2->L1 route leaking at the border - conditional and policy-scoped, so the L1 area receives exactly the specifics that fix its exit choice and nothing more.

Two hard rules attach to that boundary. In an MPLS VPN core, label bindings are exact-FEC, so PE loopbacks (the BGP next-hops) must cross the L1/L2 boundary unsummarized - leak the /32s and summarize only the physical-link space - or LSPs between PEs break end to end (Segment Routing carries the same rule as SRv6's motivation; Route aggregation and summarization). And leaking requires wide metrics (below). On when to draw areas at all: modern IS-IS carries hundreds of routers - 400+ - in one backbone comfortably, so the provider playbook starts flat: a single-area backbone (run L2-only, or L1/L2-everywhere per the doctrine above - either way backbone continuity is guaranteed from day one and L1 pockets are addable later without surgery), L2-only with per-POP area IDs where addressing hygiene wants distinct areas (every router still shares the full LSDB, routing stays optimal, no leaking needed), a deliberate flat L1-only domain where a provider chose one SPF domain precisely to dodge suboptimal inter-area routing, and L1 POPs under an L2 core only where per-POP SPF containment is worth the ATT-bit tax. The rule of thumb: draw an area only where suboptimal routing is acceptable, and prefer single-exit areas, where closest-attached and best-exit coincide by construction.

IS-IS on the wire - CLNS transport and metric styles

IS-IS PDUs ride directly on Layer 2 (CLNS), not on IP - with three design consequences. The protocol cannot be reached or attacked off-link via IP - a genuine hardening property next to IP-borne IGPs (Securing routing protocols). It will not run over IP-based tunnel clouds - DMVPN included - though plain GRE carries it, so an IS-IS-everywhere ambition constrains the overlay choice (Tunneling technology selection). And adjacency formation is strict about the short list it checks: matching MTU, compatible levels (with the area address matching for L1 and the system ID unique within the area), per-topology address-family agreement, matching circuit types and hello authentication.

Metric styles are a domain-wide contract. Narrow metrics are the original 6-bit field - interface cost caps at 63 - carried in the classic neighbor and reachability TLVs; wide metrics move both the routes and the IS-neighbor topology into new 32-bit TLVs. The two are not compatible, and because unknown TLVs are simply skipped, a style mismatch does not error - it silently partitions: a narrow-only router just fails to see topology and routes beyond a wide-only one. Platform defaults differ by operating system (some ship narrow, some wide), which turns this from a lab curiosity into a real multi-OS integration trap. Wide is a prerequisite for multi-topology and for L2->L1 leaking, so the rule for a new design is wide everywhere from day one; a live narrow estate migrates in two stages via the transition style (generate and accept both), flipping to wide only once the whole domain speaks it.

What would change this (mid-scenario twist)

• SR-MPLS / SRv6 underlay mandated -> IS-IS (or OSPF-SR).
• Merger introduces non-Cisco gear -> migrate off EIGRP to OSPF/IS-IS.
• DC fabric underlay -> often eBGP, not an IGP (see BGP in enterprise design).
• Large existing OSPF estate -> keep OSPF, fix area design rather than re-protocol.

Validation checks

• Are areas/levels sized so SPF scope and flooding stay bounded as the network grows?
• Are summarization boundaries aligned to the hierarchy (Route aggregation and summarization)?
• Is the dual-stack story explicit (OSPFv3 vs IS-IS MT vs EIGRP named)?

IPv6 / dual-stack note

OSPF needs a separate OSPFv3 instance/process for v6; IS-IS carries v6 via multi-topology in one instance; EIGRP named mode runs both address families. Factor the operational overhead. (OSPF's own consolidation option exists too: OSPFv3 address families run IPv4 and IPv6 in one OSPFv3 process and LSDB - closing the single-process gap with IS-IS MT and EIGRP named mode.)

The IS-IS-internal choice inside that single instance is single- vs multi-topology. Single topology runs one SPF for both address families, so the IPv4 and IPv6 topologies must be congruent interface-for-interface and level-for-level - an IPv6-only router will not form an adjacency with a dual-stack one (exception: over an L2-only interface). Multi-topology keeps independent databases and SPFs per address family (IPv4 in the base topology, IPv6 in its own), which is what makes an incremental IPv6 rollout possible - enable IPv6 interface by interface without disturbing IPv4 - and tolerates deliberately divergent v4/v6 topologies; a mismatched topology ID still forms an adjacency on broadcast segments but not on point-to-point, and wide metrics are mandatory. Selection rule: congruent and staying congruent -> single topology; incremental rollout or planned divergence -> multi-topology, with a transition mode to bridge a live single-topology domain across.

Related

• BGP in enterprise design
• Fast convergence techniques
• Route aggregation and summarization
• Securing routing protocols
• Network hierarchy and topologies

Spaced repetition

Sources

• Cisco Live BRKRST-2337 OSPF Deployment in Modern Networks (agenda-level closure, batch 66): max-metric router-LSA and max-lsa overload protections added; all other agenda topics verified as already carried.
• Cisco Live BRKENT-2007 (CLUS 2023, B. Edgeworth): attached bit and L2->L1 leaking, PE-loopback rule at the L1/L2 boundary, metric styles, CLNS transport constraints, single- vs multi-topology IPv6, SP area patterns.
• White/Slice/Retana, Optimal Routing Design (full pass) - ABR placement menu, IS-IS L1/L2 doctrine, parallel-link trap.
• Doyle/Carroll, Routing TCP/IP Vol I, 2nd Ed. (full pass) - split horizon and poisoned reverse, IS-IS overload bit, OSPFv3 R flag.
• Rick Graziani, IPv6 Fundamentals, 2nd Ed. - OSPFv3 address families.
• Cisco Press, Optimal Routing Design; Routing TCP/IP Vols I-II.
• Cisco Press, CCNP ENARSI 300-410 OCG (Edgeworth/Lacoste) - EIGRP SIA, query bounding.

domain: Core · blueprint-ref: Core 3.2 Unicast routing protocols (IGP) · type: design-decision · status: complete · tags: