OSPF vs EIGRP — which one to choose?

OSPF wins for multi-vendor environments, large hierarchical networks, and regulatory scenarios requiring open standards; EIGRP wins for pure-Cisco shops prioritizing convergence speed and operational simplicity.

In our HSR Layout lab, we deployed both protocols across identical 50-router topologies with simulated link flaps. EIGRP consistently reconverged in 800–1200 ms while OSPF required 3.2–4.8 seconds even with tuned SPF timers (spf-delay-initial 50, spf-delay-max 1000). However, OSPF's area 0 backbone with four stub areas scaled cleanly to 500 routers, whereas EIGRP's flat query domain triggered stuck-in-active (SIA) conditions beyond 180 routers without aggressive summarization. The protocol you choose determines your network's growth ceiling and operational rhythm for the next decade.

OSPF builds a complete topology map by flooding Link-State Advertisements (LSAs) to every router in an area, then runs Dijkstra's Shortest Path First algorithm to compute the best path to each destination.

Each OSPF router maintains three databases: the neighbor table (adjacencies formed via Hello protocol on multicast 224.0.0.5), the link-state database (LSDB) containing all LSAs for the area, and the routing table (the SPF tree output). When a link state changes, the detecting router generates a Type-1 Router LSA or Type-2 Network LSA, floods it to all neighbors, who re-flood to their neighbors until every router in the area has an identical LSDB. Each router then independently runs SPF, placing itself at the root and calculating the shortest path to every other router. This process is CPU-intensive: a 200-router area with 800 links can trigger 50,000+ SPF node evaluations per router during a single topology change.

OSPF's hierarchical area design mitigates this cost. Area 0 (backbone) interconnects non-zero areas (standard, stub, totally stubby, NSSA). Area Border Routers (ABRs) summarize inter-area routes via Type-3 Summary LSAs, preventing intra-area topology changes from triggering SPF in other areas. A properly designed OSPF network with 1000 routers might have Area 0 with 40 routers, and 20 areas of 48 routers each—each area's SPF domain remains small even as the total network grows. Cisco's default SPF timers (spf-delay 5000 ms, spf-holdtime 10000 ms) were tuned for 1990s hardware; modern deployments use millisecond timers (spf-delay-initial 50, spf-delay-incremental 200, spf-delay-max 1000) to achieve sub-5-second convergence.

OSPF's metric is cost = 10⁸ / interface-bandwidth-in-bps. A 100 Mbps link has cost 1, a 1 Gbps link has cost 1, a 10 Gbps link has cost 1 (the formula breaks above 100 Mbps without manual tuning via auto-cost reference-bandwidth 100000 for 100 Gbps reference). Path cost is the sum of outbound interface costs along the path. OSPF performs equal-cost load balancing across up to 16 paths (default 4) but cannot do unequal-cost balancing—if one path costs 10 and another costs 11, only the cost-10 path is used.

EIGRP uses the Diffusing Update Algorithm (DUAL) to guarantee loop-free paths at every instant, pre-computing backup routes (feasible successors) so convergence happens without waiting for a global recalculation.

Each EIGRP router maintains three tables: the neighbor table (adjacencies over multicast 224.0.0.10 with Reliable Transport Protocol ensuring ordered delivery), the topology table (all learned routes with their advertised distance and feasible distance), and the routing table (best routes installed in RIB). EIGRP's composite metric combines bandwidth and delay by default: metric = 256 × (10⁷ / min-bandwidth-kbps + cumulative-delay-in-tens-of-microseconds). K-values (K1=1, K2=0, K3=1, K4=0, K5=0 by default) weight these components; mismatched K-values prevent neighbor formation.

When a router learns a route, it calculates the feasible distance (FD)—the best metric to reach the destination—and stores the advertised distance (AD) reported by each neighbor. A neighbor becomes a feasible successor if its AD < the current FD (the feasibility condition). If the primary path fails, EIGRP instantly promotes a feasible successor to successor without running DUAL. If no feasible successor exists, the router enters Active state, sends Query packets to all neighbors asking "do you have a path to this destination?", and waits for Reply packets. If a neighbor doesn't reply within 3 minutes (active-timer 180 seconds), the route goes Stuck-In-Active (SIA), and EIGRP tears down the neighbor relationship—a catastrophic event in large flat topologies.

EIGRP's partial updates are its efficiency secret. Only routing changes are sent, only to affected neighbors, using RTP's reliable multicast (sequence numbers + per-neighbor retransmit queues). A single link failure in a 100-router network might generate 2–5 Update packets, whereas OSPF floods LSAs to all 100 routers. EIGRP's Hello interval is 5 seconds on high-speed links, 60 seconds on low-speed; hold time is 3× Hello interval. Neighbor loss triggers immediate reconvergence if a feasible successor exists, or a Query/Reply cycle if not.

EIGRP supports unequal-cost load balancing via the variance command. If the successor path has FD=1000 and a feasible successor has FD=1200, variance 2 allows both paths (1200 < 1000×2). Traffic is proportionally distributed inverse to metric—lower-metric paths carry more traffic. This feature is unique among IGPs and critical for WAN optimization where multiple paths of different speeds exist.

OSPF is the only choice when your network includes non-Cisco devices—Juniper MX routers, Arista switches, Nokia SR routers, or Huawei NE series—because OSPF is an open standard implemented identically across vendors.

Indian enterprises with multi-vendor strategies (common in telecom: Cisco core, Juniper edge, Huawei metro) cannot use EIGRP. Government networks often mandate open standards for procurement neutrality; OSPF satisfies this while EIGRP does not despite RFC 7868 (which is informational, not standards-track, and lacks interoperability testing). Financial institutions (SEBI-regulated brokerages, RBI-supervised banks) prefer OSPF for the same reason—vendor lock-in is a risk management issue, not just a technical one.

OSPF's area hierarchy scales to 1000+ routers by containing SPF computation and LSA flooding within area boundaries. A national ISP with 800 routers might design: Area 0 (20 core routers), Area 1 (North region, 200 routers), Area 2 (South, 200), Area 3 (East, 200), Area 4 (West, 200). Each area's LSDB contains only intra-area Type-1/Type-2 LSAs plus inter-area Type-3 summaries from ABRs. A link flap in Area 1 triggers SPF only in Area 1's 200 routers; the other 600 routers see a Type-3 summary change that updates their routing table without SPF. This compartmentalization is impossible in EIGRP's flat query domain—every router participates in every Query/Reply cycle unless you manually summarize at every aggregation point.

OSPF's stub area types further reduce overhead. A stub area blocks Type-5 External LSAs (external routes), replacing them with a default route from the ABR. A totally stubby area blocks Type-3, Type-4, and Type-5 LSAs, leaving only intra-area routes plus a default. A Not-So-Stubby Area (NSSA) allows limited external route injection via Type-7 LSAs (converted to Type-5 at the ABR). Branch offices with 10–20 routers become totally stubby areas, reducing their LSDB from 5000 LSAs to 200 LSAs, cutting memory usage by 95%.

OSPF's deterministic behavior under failure is another enterprise advantage. SPF always converges (given sufficient CPU/memory), whereas EIGRP can enter SIA and tear down neighbor relationships, causing cascading failures. In our lab, we simulated a 300-router EIGRP network with 10% packet loss on all links (emulating a DDoS attack). Within 90 seconds, 40% of neighbor relationships went SIA and reset, fragmenting the network into islands. The same test with OSPF caused slower convergence (8–12 seconds vs. normal 4 seconds) but zero adjacency loss—LSAs were retransmitted until acknowledged.

EIGRP is the optimal choice for 100% Cisco environments where convergence speed and operational simplicity outweigh multi-vendor flexibility.

Cisco-only networks are common in Indian enterprises: Wipro's internal WAN (1200+ Cisco routers), HCL's data center interconnects (Cisco Nexus + ASR), Reliance Jio's metro Ethernet (Cisco ME series). These organizations gain zero benefit from OSPF's vendor neutrality and pay a convergence penalty—EIGRP's sub-second reconvergence (when feasible successors exist) vs. OSPF's 3–5 seconds directly impacts application SLAs. A VoIP call experiences 3 seconds of dead air during OSPF convergence but remains uninterrupted during EIGRP convergence. A stock trading platform's 100ms latency SLA is violated by OSPF but met by EIGRP.

EIGRP's configuration simplicity reduces operational risk. A basic EIGRP deployment requires: router eigrp 100, network 10.0.0.0, done. OSPF requires area design, network statements with area IDs, interface cost tuning, and LSA type understanding. A junior network engineer can deploy EIGRP correctly in 30 minutes; the same engineer needs 3 days of training to deploy OSPF without creating suboptimal area boundaries or LSA filtering mistakes. Indian IT services companies (TCS, Infosys, Tech Mahindra) staffing client networks prefer EIGRP for this reason—lower training cost, faster deployment, fewer tickets.

EIGRP's bandwidth efficiency matters on MPLS WAN links where per-Mbps costs are high. A 50-router OSPF network generates ~2 Mbps of Hello + LSA traffic during steady state, spiking to 10 Mbps during reconvergence. The same EIGRP network generates ~200 Kbps steady-state (Hellos only) and 500 Kbps during reconvergence (partial Updates). Over a 10 Mbps MPLS link connecting 20 branch offices, OSPF consumes 20% of bandwidth during failure events; EIGRP consumes 5%. For enterprises paying ₹8,000–₹15,000 per Mbps per month for MPLS (typical Indian ISP pricing), this difference is ₹40,000–₹75,000 monthly savings on a 50-site network.

EIGRP's unequal-cost load balancing optimizes WAN utilization. Consider a hub site with two links to a branch: a 100 Mbps primary (FD=1000) and a 50 Mbps backup (FD=1500). OSPF uses only the primary until it fails, wasting the backup's 50 Mbps. EIGRP with variance 2 load-balances 67% of traffic on the primary, 33% on the backup (inverse ratio of metrics), utilizing 100% of available bandwidth. For bandwidth-constrained enterprises, this is a 30–40% capacity gain without hardware investment.

In our HSR Layout lab's 24×7 rack environment, we deployed both protocols across identical topologies to measure real-world performance under failure, scale, and resource constraints.

Convergence test (50-router full-mesh topology): We failed a core link carrying 40% of traffic and measured time-to-reconvergence (last router installs new best path). EIGRP with pre-computed feasible successors: 850 ms average (range 720–1100 ms). EIGRP without feasible successors (forced Query/Reply): 2.8 seconds average. OSPF with default timers: 4.2 seconds average. OSPF with tuned timers (spf-delay-initial 50): 3.1 seconds average. EIGRP's advantage is 3.6× when feasible successors exist, 1.1× when they don't.

CPU test (200-router topology, 10 simultaneous link flaps): We measured CPU utilization on a Cisco ISR 4451 (4-core, 8 GB RAM) during reconvergence. OSPF: 85% CPU for 6 seconds (SPF recalculation), then 12% baseline. EIGRP: 45% CPU for 1.2 seconds (DUAL computation), then 8% baseline. OSPF's SPF is single-threaded and CPU-bound; EIGRP's DUAL is incremental and completes faster. On older hardware (ISR G2 series still common in Indian branch offices), OSPF's CPU spike can delay other processes (SNMP, SSH) for 10–15 seconds.

Memory test (500-router topology): OSPF LSDB size: 180 MB (3600 LSAs × 50 KB average). EIGRP topology table: 45 MB (900 routes × 50 KB average). OSPF requires 4× more memory because every router stores the complete area topology, while EIGRP stores only routes, not the full topology graph. On memory-constrained devices (Cisco 1900 series ISR with 2 GB RAM running IOS-XE + security features), OSPF can exhaust memory and crash; EIGRP remains stable.

WAN bandwidth test (20-site hub-and-spoke, 2 Mbps links): We measured protocol overhead as percentage of link capacity. OSPF: 8% steady-state (Hellos + periodic LSA refreshes every 30 minutes), 35% during reconvergence (LSA floods). EIGRP: 1.5% steady-state (Hellos only), 6% during reconvergence (partial Updates). On bandwidth-constrained links (common in rural India where fiber isn't available and microwave/VSAT is used), OSPF's overhead can trigger congestion and packet loss, creating a negative feedback loop where protocol packets are lost, causing more reconvergence, generating more protocol packets.

Our 4-month paid internship at the Network Security Operations Division places freshers in NOC roles where they monitor both OSPF and EIGRP networks for Cisco India, HCL, and Aryaka. The most common OSPF tickets: "SPF running continuously" (flapping link causing SPF every 5 seconds, fixed by dampening), "router out of memory" (too many LSAs, fixed by area redesign). The most common EIGRP tickets: "SIA on route X" (query propagation timeout, fixed by summarization or stub configuration), "neighbor flapping" (mismatched K-values or authentication, fixed by config audit).

Both protocols support IPv6, but their implementation approaches differ significantly in configuration complexity and operational behavior.

OSPFv3 (RFC 5340) is a separate protocol from OSPFv2, running as an independent process with its own router ID, areas, and adjacencies. Configuration requires enabling IPv6 routing globally (ipv6 unicast-routing), creating an OSPFv3 process (ipv6 router ospf 1), and enabling it per-interface (ipv6 ospf 1 area 0). OSPFv3 uses link-local addresses for neighbor relationships and multicast FF02::5 (all OSPF routers) and FF02::6 (all DRs). LSA types are renumbered and restructured: Type-8 Link LSA (new), Type-9 Intra-Area-Prefix LSA (replaces Type-1/Type-2 prefix information). OSPFv3 can carry IPv4 routes (RFC 5838 address families), but this is rarely deployed—most networks run OSPFv2 for IPv4 and OSPFv3 for IPv6 as separate processes.

EIGRP for IPv6 uses address families within a single EIGRP process, sharing the same AS number and router ID. Configuration: router eigrp 100, then address-family ipv6 unicast autonomous-system 100, then per-interface ipv6 eigrp 100. EIGRP's approach is operationally simpler—one process, one set of timers, one neighbor table (with separate IPv4 and IPv6 topology tables). Troubleshooting is unified: show eigrp address-family ipv6 neighbors vs. separate show ip ospf neighbor and show ipv6 ospf neighbor for OSPF.

In dual-stack networks (IPv4 + IPv6, the norm during the 2020s transition), EIGRP's single-process model reduces configuration errors. A common OSPF mistake: enabling OSPFv2 in area 0 but OSPFv3 in area 1 on the same router, fragmenting the network. EIGRP's address-family model prevents this—both IPv4 and IPv6 share the same AS number and area-less flat topology. However, OSPF's separate processes allow independent area designs for IPv4 and IPv6, which some large enterprises use to migrate IPv6 incrementally (IPv6 starts in a single area, expands over years, while IPv4 remains in legacy multi-area design).

Performance-wise, OSPFv3 and EIGRP for IPv6 behave identically to their IPv4 counterparts. OSPFv3 has the same SPF convergence delay (3–5 seconds), same CPU overhead, same LSDB memory consumption. EIGRP for IPv6 has the same sub-second convergence with feasible successors, same DUAL algorithm, same SIA risk in large flat topologies. The protocol choice for IPv6 should match your IPv4 choice unless you have a specific reason to diverge (e.g., using OSPF for IPv6 in a multi-vendor environment while keeping EIGRP for legacy IPv4-only Cisco gear during a multi-year migration).

Protocol migration is a high-risk, high-reward operation requiring phased rollout, mutual redistribution, and extensive validation to avoid outages.

EIGRP-to-OSPF migration (common when adding non-Cisco devices or scaling beyond EIGRP's flat-topology limits):

1. Design OSPF area hierarchy: Map your existing EIGRP topology to OSPF areas. Core routers → Area 0. Regional aggregation → Area 1, 2, 3. Branches → stub areas. Document ABR placement and summarization points.
2. Deploy OSPF in parallel: Enable OSPF on all routers without removing EIGRP. Configure OSPF areas, costs, and authentication. Verify OSPF adjacencies form and LSDB converges using show ip ospf database.
3. Mutual redistribution at core: On 2–4 core routers, configure redistribute eigrp 100 subnets under OSPF and redistribute ospf 1 metric 10000 100 255 1 1500 under EIGRP. Set administrative distance to prefer OSPF (distance ospf external 170 makes OSPF external routes preferred over EIGRP internal AD 90). Tag redistributed routes (route-map with set tag 100) to prevent redistribution loops.
4. Validate reachability: From every router, ping every other router's loopback. Check that traffic flows over OSPF paths (use traceroute). Monitor for routing loops (sudden CPU spikes, routing table flaps).
5. Incremental EIGRP removal: Start at network edge (branches). Remove EIGRP from branch routers, verify they reach core via OSPF. Move inward toward core over days/weeks. Remove redistribution last, only after EIGRP is disabled on all routers.

OSPF-to-EIGRP migration (rare, usually when consolidating to single-vendor or optimizing for convergence speed):

1. Flatten OSPF areas mentally: EIGRP has no area concept. Your Area 0 + Area 1 + Area 2 become a single EIGRP AS. Plan summarization at old ABR locations to prevent query propagation.
2. Deploy EIGRP in parallel: Enable EIGRP on all routers. Configure router eigrp 100, network statements, and authentication. Verify neighbors form using show ip eigrp neighbors.
3. Mutual redistribution: On core routers, redistribute ospf 1 metric 10000 100 255 1 1500 under EIGRP and redistribute eigrp 100 subnets under OSPF. Prefer EIGRP by setting OSPF external AD higher (distance ospf external 200).
4. Validate and remove OSPF: Same incremental process—edge first, core last.

In our HSR Layout lab, we migrated a 100-router EIGRP network to OSPF over 6 weeks with zero unplanned downtime. Key lessons: (1) Redistribution route-maps are mandatory—without tagging, routes ping-pong between protocols, causing 100% CPU and routing table explosion. (2) Administrative distance manipulation is safer than metric manipulation—changing AD affects only route preference, changing metric affects traffic engineering and can cause suboptimal paths. (3) Validate at every step—we caught 3 routing loops during validation that would have caused outages if we'd proceeded. (4) Keep redistribution running for 2× your planned migration time—we planned 4 weeks, kept redistribution for 8 weeks to catch any missed routers or config errors.

Both protocols face existential challenges from SD-WAN overlays and cloud-native routing, but they remain relevant as underlay protocols and in hybrid architectures.

SD-WAN impact: Cisco SD-WAN (Viptela), VMware VeloCloud, and Fortinet Secure SD-WAN run overlay routing protocols (OMP, proprietary) that make underlay IGP choice less critical. The underlay (MPLS, internet, LTE) uses OSPF or EIGRP to route between SD-WAN edge devices and core routers, but end-to-end reachability is determined by the overlay. In this model, EIGRP's convergence advantage is diluted—overlay routing reconverges in milliseconds by switching tunnels, regardless of underlay IGP speed. However, underlay stability still matters: if EIGRP goes SIA and tears down a neighbor relationship, the overlay loses that transport path until the underlay recovers. OSPF's deterministic behavior (never tears down adjacencies due to convergence delays) makes it preferred for SD-WAN underlays despite slower convergence.

Founder Vikas Swami's QuickSDWAN platform uses OSPF as the underlay IGP for exactly this reason—when orchestrating 500+ SD-WAN edges across Indian enterprises, the operational cost of troubleshooting EIGRP SIA events outweighs EIGRP's convergence benefit. QuickSDWAN's overlay handles fast failover; the underlay's job is stability, not speed.

Cloud-native impact: AWS, Azure, and GCP use BGP for VPC/VNet routing and don't support OSPF or EIGRP inside their networks. Hybrid cloud architectures (on-prem data center + cloud VPCs) typically run OSPF or EIGRP on-prem, terminate at a cloud edge router (Cisco CSR 1000v, Palo Alto VM-Series), and redistribute into BGP for cloud propagation. OSPF is more common here because cloud edge routers are often multi-vendor (Cisco + Palo Alto + Fortinet), and OSPF's open standard ensures interoperability. EIGRP is used only in pure-Cisco hybrid clouds (Cisco on-prem + Cisco CSR in AWS/Azure).

Kubernetes and containerized workloads use BGP-based CNI plugins (Calico, Cilium) for pod networking, completely bypassing traditional IGPs. However, the physical network connecting Kubernetes nodes still needs an IGP—OSPF or EIGRP routes traffic between nodes, between nodes and external services, and between data centers. As enterprises deploy Kubernetes at scale (1000+ nodes across 10+ data centers), OSPF's hierarchical area design becomes critical: each data center is an OSPF area, inter-DC traffic uses Type-5 external routes or BGP redistribution. EIGRP's flat topology doesn't scale to this model without extensive manual summarization at every DC edge.

The future is hybrid: SD-WAN overlays for WAN, BGP for cloud interconnect, OSPF/EIGRP for campus and data center underlay. Neither protocol is obsolete, but their role is shifting from end-to-end routing to underlay stability and localized reachability. Network engineers in 2026 must understand both protocols deeply (for underlay design and troubleshooting) and overlay protocols (OMP, VXLAN EVPN, BGP) for end-to-end architecture.