EIGRP vs OSPF: Which to Run and Why

EIGRP vs OSPF comes down to one question: is every router in the routing domain a Cisco box, and will it stay that way? If yes, EIGRP is simpler to run and usually reconverges faster. If there’s a firewall, a cloud edge or any other vendor in the mix, run OSPF. That’s the short answer, and it’s right most of the time.

The longer answer is more interesting. Put both protocols on the same three-router topology and they’ll pick different paths to the same subnet. OSPF, on its defaults, sends your traffic over the slower link.

This guide shows you why with real numbers. You’ll get the EIGRP metric worked by hand, OSPF cost on the same links, the feasible successor that makes EIGRP fast, what the 2026 exams actually test, and a decision table you can use tomorrow.

EIGRP vs OSPF: what’s the short answer?

Both are interior gateway protocols. Both run inside one organisation’s network, both support IPv4 and IPv6, and both converge fast enough for any campus or branch. Where they differ is how they learn the network and how they pick a path.

	EIGRP	OSPF
Type	Advanced distance vector	Link-state
Algorithm	DUAL	Dijkstra SPF
Standard	Cisco, published as Informational RFC 7868 (2016)	Open standard, RFC 2328 (OSPFv2)
Metric	Composite: bandwidth + delay by default	Cost: reference bandwidth / interface bandwidth
Administrative distance	90 internal, 170 external	110
Backup path	Pre-computed (feasible successor)	Recomputed by SPF after a change
Load balancing	Equal and unequal cost (variance)	Equal cost only
Design	Flat, summarise on any interface	Hierarchical areas, summarise at ABR/ASBR
Hello / hold (fast links)	5 s / 15 s	10 s / 40 s
Multicast	224.0.0.10	224.0.0.5 and 224.0.0.6
Vendor support	Cisco, plus a few open-source stacks	Everyone

Keep that table handy. The rest of this post explains the three rows that actually matter: metric, backup path and vendor support.

How do EIGRP and OSPF find a path differently?

What does “advanced distance vector” actually mean?

An EIGRP router never sees the whole map. Each neighbour tells it, “I can reach 192.168.30.0/24 at this cost.” The router adds the cost of the link to that neighbour, and the lowest total wins.

Plain distance vector (think RIP) stops there, which is why it converges slowly and leans on hold-down timers to avoid loops. EIGRP adds two things. It keeps every neighbour’s advertised cost in a topology table, not just the best one. And it runs DUAL, the Diffusing Update Algorithm, which uses those stored costs to prove a backup path is loop-free before it ever needs it.

That proof is the feasible successor. We’ll get there.

What does link-state mean in practice?

An OSPF router does see the whole map, at least for its own area. Every router floods link-state advertisements describing its links and their costs. Every router in the area ends up with an identical database, then runs Dijkstra’s shortest path first on it, with itself as the root.

So OSPF routers don’t trust their neighbours’ opinions. They trust the shared map and do their own maths. Which LSA carries what, and why areas stop the map from growing forever, is its own topic. Our guide to OSPF LSA types walks through all of them.

Here’s the practical difference. Ask an OSPF router why it picked a path and the answer is in show ip ospf database. Ask an EIGRP router and the answer is in show ip eigrp topology. Different tables, different troubleshooting habits.

How is the EIGRP metric calculated?

The full formula looks scary. Cisco documents it as:

metric = [K1 × BW + (K2 × BW) / (256 - load) + K3 × delay] × [K5 / (reliability + K4)] × 256

Relax. The default K values are K1 = 1, K3 = 1, and K2 = K4 = K5 = 0, so load and reliability drop out and the whole thing collapses to this (Cisco, Understand and Use EIGRP):

EIGRP metric = 256 × (10,000,000 / slowest bandwidth in Kbps + total delay in µs / 10)

Two inputs. The slowest link on the path, and the sum of every outgoing interface’s delay.

On default K values, the EIGRP metric weighs just two things: the slowest bandwidth on the path and the total delay.

Now let’s use it. Here’s the topology for the rest of this post.

• R1 wants to reach 192.168.30.0/24, a LAN behind R3’s Gi0/2.
• Path A: R1 → R2 → R3, all GigabitEthernet (1,000,000 Kbps, 10 µs delay each).
• Path B: R1 → R3 direct, over a FastEthernet link (100,000 Kbps, 100 µs delay).

Path A, via R2:

• Bandwidth term: 10,000,000 / 1,000,000 = 10
• Delay term: (10 + 10 + 10) / 10 = 3 (R1’s Gi0/0, R2’s Gi0/1, R3’s Gi0/2)
• Metric: 256 × (10 + 3) = 3,328

Path B, direct to R3:

• Bandwidth term: 10,000,000 / 100,000 = 100
• Delay term: (100 + 10) / 10 = 11
• Metric: 256 × (100 + 11) = 28,416

EIGRP picks Path A. Its metric is more than eight times lower. That’s what you’d want, too. Two gigabit hops beat one 100 Mbps hop for almost any traffic.

The lowest metric to a destination is called the feasible distance (FD). Here, FD = 3,328. The neighbour on that path, R2, is the successor.

One honest caveat. These are classic metrics, what you get with router eigrp 100. Classic metrics run out of resolution on very fast links, since 10,000,000 divided by anything above 10 Gbps rounds toward zero.

That’s why EIGRP named mode (router eigrp NAME) uses wide metrics, defined in RFC 7868, with much finer bandwidth and delay units. The numbers get far bigger in named mode. The path choice on this topology doesn’t change.

Want the formulas, K values and show commands on one page? Grab our free 18-page EIGRP cheat sheet. It’s the thing to keep open while you do this maths yourself.

How does OSPF cost compare on the same topology?

OSPF’s metric is simpler. Each interface gets a cost:

OSPF cost = reference bandwidth / interface bandwidth

The path cost is the sum of the outgoing interface costs. And here’s the catch. On Cisco IOS the default reference bandwidth is 100 Mbps (Cisco OSPF FAQ). Anything at 100 Mbps or faster gets a cost of 1, because OSPF cost can’t go below 1.

Run the same topology through that:

	EIGRP metric	OSPF cost (default ref BW)	OSPF cost (ref BW 100 Gbps)
Path A (1 Gbps, 3 interfaces)	3,328	1 + 1 + 1 = 3	100 + 100 + 100 = 300
Path B (100 Mbps, 2 interfaces)	28,416	1 + 1 = 2	1,000 + 100 = 1,100
Winner	Path A	Path B (the slow link)	Path A

Read the middle column again. With defaults, OSPF can’t tell a gigabit link from a 100 Mbps link. Both cost 1. So it just counts hops, and the direct 100 Mbps link wins.

Is that a bug? No. RFC 2328 was written when 100 Mbps was fast. It’s a default you’re meant to change. One line under router ospf on every router fixes it:

router ospf 1
 auto-cost reference-bandwidth 100000

That sets the reference to 100 Gbps (the value is in Mbps). Now a 1 Gbps link costs 100, 100 Mbps costs 1,000, and OSPF picks Path A like EIGRP did. Set it the same on every OSPF router, or you’ll get paths nobody can explain.

This is the single most useful thing to take from any EIGRP vs OSPF comparison. EIGRP’s metric looks at bandwidth and delay out of the box. OSPF’s looks at bandwidth, but only if you tell it what “fast” means.

Same three routers, two answers. EIGRP takes the gigabit path via R2 (metric 3,328). Default OSPF takes the direct 100 Mbps link (cost 2 vs 3).

What is a feasible successor, and why does it make EIGRP fast?

Back to the EIGRP side. R1 has Path A as its successor route. What about Path B?

EIGRP keeps it as a backup, but only if it can prove Path B won’t loop back through R1. The proof is the feasibility condition:

A neighbour’s reported distance (RD) must be lower than your current feasible distance (FD).

The reported distance is the neighbour’s own metric to the destination, what it tells you before you add your link to it. Cisco puts it simply: “A feasible successor is a path whose reported distance is less than the feasible distance (current best path)” (Cisco).

Work it out for R3:

• R3 reaches 192.168.30.0/24 over one gigabit interface: 256 × (10 + 1) = 2,816. That’s its RD.
• R1’s FD is 3,328.
• 2,816 < 3,328. Condition met.

So R3 is a feasible successor. Why does that prove no loop? If R3’s own distance is already shorter than R1’s best, R3 can’t be relying on R1 to get there. If it were, its distance would have to be longer than R1’s.

The feasible successor is already cabled and proven loop-free. R3’s reported distance, 2,816, is below R1’s feasible distance of 3,328.

Here’s roughly what show ip eigrp topology shows on R1 for this build (representative classic-mode output, trimmed):

P 192.168.30.0/24, 1 successors, FD is 3328
        via 10.0.12.2 (3328/3072), GigabitEthernet0/0
        via 10.0.13.3 (28416/2816), GigabitEthernet0/1

Each line reads (your metric / neighbour’s reported distance). The first line is the successor. The second is the feasible successor.

Now the payoff. Say R1’s Gi0/0 goes down. R1 doesn’t ask anyone anything. It already has a proven loop-free backup, so it installs the path via R3 locally and carries on. No flooding, no recalculation across the network.

What happens when there’s no feasible successor?

Look at a different prefix: a LAN on R2’s Gi0/2 instead of R3’s.

• R1 reaches it straight through R2: 256 × (10 + 2) = 3,072. That’s R1’s FD.
• R3’s best path to it also goes through R2, over its own gigabit link: 256 × (10 + 2) = 3,072. That’s R3’s RD.
• 3,072 isn’t lower than 3,072. Equal fails. R3 is not a feasible successor.

Here’s the subtle part. R3’s path doesn’t actually loop through R1. It’s perfectly safe. But the feasibility condition is deliberately conservative, and EIGRP won’t use a backup it can’t prove. So R3 sits in the topology table, unused.

When the successor dies with no feasible successor waiting, the route goes active. R1 sends a query to every neighbour: “Do you have a path?” Those neighbours may query their neighbours. The route stays active until every reply comes back.

If a reply never comes, you get stuck in active (SIA). Cisco documents the active timer at a little over 3 minutes, after which EIGRP resets the neighbours that didn’t answer (Cisco, Troubleshoot EIGRP Common Issues). On a big flat network, one lost query can bounce adjacencies a long way from the actual failure.

That’s EIGRP’s real weakness. Not the metric. The query.

No feasible successor means the route goes active and queries every neighbour. If a reply never comes, you hit stuck in active after about three minutes.

Can EIGRP use the feasible successor at the same time?

Yes, and OSPF can’t do this. The variance command lets EIGRP load-share across unequal paths. Cisco defines it as a multiplier: traffic goes on any link with a metric less than the best path times the variance.

Path B’s metric is 28,416. That’s about 8.5 times Path A’s 3,328. So:

router eigrp 100
 variance 9

Now 3,328 × 9 = 29,952, which is above 28,416, and R1 installs both paths, sending proportionally more traffic down Path A. One rule applies: only feasible successors qualify. A path that fails the feasibility condition never gets used, however high you set the variance.

OSPF load-shares too, but only across paths with exactly equal cost.

Is OSPF or EIGRP faster to converge?

With a feasible successor in the table, EIGRP usually wins. It swaps paths locally, straight away, without talking to anyone.

OSPF has to do more. The router that detects the failure floods a new LSA. Every router in the area updates its database and reruns SPF. Modern IOS throttles SPF with short initial timers, so this is quick, but it’s still a network-wide event, not a local one.

Without a feasible successor, the story flips. EIGRP goes active and waits on queries, and OSPF’s flood-and-recompute can easily finish first.

In practice? Tuned properly, with BFD detecting link failure fast, both protocols recover quickly enough that convergence rarely decides the choice on its own. Don’t pick EIGRP because a blog said it’s faster. Pick it because your topology gives it feasible successors, or don’t.

OSPF vs EIGRP: which scales better, areas or query boundaries?

Both protocols scale into hundreds of routers. They just scale in different ways, and the difference shapes how you design.

OSPF scales with areas. Router and network LSAs stay inside their area. Area 0 is the backbone, and every other area connects to it through an area border router. Summarise at the ABR and one flapping link in area 5 doesn’t trigger SPF in area 7. The price is rigidity. You design the areas up front, and every area has to touch area 0.

EIGRP scales with query boundaries. There are no areas. You control how far queries travel instead, with two tools:

• Summarisation. Summarise on any interface, on any router. A neighbour that only knows the summary replies to a query for a specific prefix straight away, so the query stops there.
• Stub routing. Mark branch routers as stubs (eigrp stub connected summary) and the hub won’t send them queries at all. On a hub-and-spoke WAN with 200 branches, that’s the difference between a query hitting 200 routers and hitting none.

Stub branches never get queried. That single line is how a hub-and-spoke EIGRP WAN keeps one failure from rippling across every branch.

So EIGRP gives you more freedom and fewer rules. OSPF gives you guard rails. For a large network run by several teams, those guard rails are often the feature.

Is EIGRP only for Cisco?

Mostly, yes. Cisco opened EIGRP to other vendors in 2013 and published it as RFC 7868 in May 2016. But that RFC is Informational, not Standards Track, so it describes the protocol rather than making it an open standard in the way OSPF is.

Support outside Cisco is thin. The open-source FRRouting suite ships an eigrpd daemon built against RFC 7868, which is handy for labs with Linux routers. Mainstream firewalls, cloud routers and most other vendors’ switches don’t offer it, so plan on OSPF or BGP there.

Even inside Cisco’s own portfolio, EIGRP isn’t everywhere. Meraki’s MX documentation covers OSPF and BGP for dynamic routing (Cisco Meraki, MX Routing Behavior). So if a Meraki MX or a non-Cisco firewall joins your network next year, an all-EIGRP design gets harder to keep.

That’s the real risk with EIGRP. It’s not a bad protocol. It’s a bet that your network stays Cisco.

EIGRP vs OSPF on the CCNA and ENCOR exams: what’s tested in 2026?

This is where a lot of study time gets wasted. The exams treat these two protocols very differently.

CCNA 200-301. The current CCNA doesn’t ask you to configure EIGRP, and the v2.0 blueprint, live from 2027-02-03, keeps it that way. Domain 3.0, IP Routing (20%), covers reading a routing table (including administrative distance and metric), static routing with floating statics, and single-area OSPFv2 plus OSPFv3 (Cisco, CCNA v2.0 exam topics PDF). So for CCNA you need to recognise a D route and know why AD 90 beats AD 110. That’s it. Our rundown of what changed in CCNA v2.0 covers the rest of the new blueprint.

ENCOR 350-401 v1.2. This is the exam that asks for the comparison directly. Topic 3.2.a reads, word for word: “Compare routing concepts of EIGRP and OSPF (advanced distance vector vs. link state, load balancing, path selection, path operations, metrics, and area types)” (Cisco, ENCOR v1.2 exam topics PDF). Note the verb. ENCOR asks you to compare EIGRP, but configure only OSPF (topic 3.2.b). Expect questions on unequal-cost load balancing, the feasibility condition and metric components, not EIGRP config.

CCIE Enterprise Infrastructure v1.1. EIGRP comes back in full. Section 1.3 lists reported distance, feasible distance, feasibility condition, successor and feasible successor, classic and wide metrics, named mode, and query propagation boundaries with stubs and leak maps (Cisco, CCIE EI v1.1 blueprint). Everything in this post is CCIE lab material. Our CCIE Enterprise Infrastructure lab workbook drills it with topologies that boot, not diagrams.

So here’s the study plan. CCNA: OSPF deep, EIGRP recognition only. ENCOR: be able to do this post’s maths on paper. CCIE: do it on a live router, then break it.

So which should you run?

Here’s the rule. It fits on a sticky note.

Your network	Run	Why
Any non-Cisco router, firewall or cloud edge in the routing domain	OSPF	EIGRP support outside Cisco is thin
Cisco-only campus or data centre, one team	Either. OSPF if you might ever add another vendor	OSPF keeps your options open
Cisco-only hub-and-spoke WAN, many branches, mixed link speeds	EIGRP	Stub routing and variance earn their keep here
You already run EIGRP and it works	Keep it	Migration risk rarely beats “it works”
Large network, several teams, strict change control	OSPF	Areas enforce a structure everyone can read
You’re studying for CCNA	OSPF	It’s what the exam configures

Notice what’s not on that list: speed. Both are fast enough. The deciding factor is almost always vendor mix, then design style, then what’s already there.

Can you run EIGRP and OSPF together?

Yes, and plenty of networks do, usually during a migration or where a Cisco core meets a multi-vendor edge. Two things to understand before you try it.

Administrative distance decides who wins. If a router learns the same prefix from both, EIGRP internal routes (AD 90) beat OSPF (AD 110). In our triangle, if you ran both protocols with defaults, the routing table would show EIGRP’s choice, Path A, and OSPF’s opinion would sit unused in its database. Handy for migrations. Confusing if you forgot EIGRP was still running. AD is the same concept that makes a floating static route work as a backup, so if it still feels fuzzy, start there.

Redistribution is where it goes wrong. To pass routes between the two, you redistribute at a boundary router. Redistributed routes show up as EIGRP external (AD 170) or OSPF E2 by default. With two or more boundary routers, a route can leak from OSPF into EIGRP and back into OSPF, and you get a loop or a suboptimal path. Tag routes on the way in and filter on the tag on the way out.

A clean migration usually runs both, lets EIGRP carry the traffic thanks to its lower AD, builds OSPF underneath, checks the OSPF database matches, then removes EIGRP router by router.

Where does BGP fit? (EIGRP vs OSPF vs BGP)

BGP isn’t really in this fight. EIGRP and OSPF are interior protocols, built to find the best path inside one network quickly. BGP is the exterior protocol, built to exchange routes between networks with policy, like which ISP to prefer for which prefixes.

A typical enterprise runs one IGP inside and BGP at the edge. The IGP still matters to BGP, though. BGP uses the IGP’s metric to reach the next hop when it compares paths, which is exactly where attributes like BGP MED come in. Our free 148-page BGP guide picks up where this post stops.

How do you practise EIGRP vs OSPF in a lab?

Build the triangle from this post. Three routers, three links, a LAN on R3 and another on R2. It takes about 20 minutes and teaches you more than any table.

1. Build it. In EVE-NG with IOSv, every port is gigabit, so on both ends of the R1-R3 link set bandwidth 100000 and delay 10 (delay is in tens of microseconds, so 10 = 100 µs). That makes it behave like FastEthernet for both protocols. Need images first? Here’s how to add router images to EVE-NG.
2. Run EIGRP. Check show ip eigrp topology and match the numbers to this post. You should see FD 3,328 and a feasible successor at 2,816.
3. Run OSPF alongside. Check show ip route ospf. On defaults, it picks the direct link with cost 2. Then check show ip route and notice EIGRP still owns the table.
4. Fix OSPF. Set auto-cost reference-bandwidth 100000 on all three routers and watch the cost jump to 300 via R2.
5. Break it. Run debug eigrp fsm on R1 and shut Gi0/0. The route to R3’s LAN swaps to its feasible successor with no queries. The route to R2’s LAN has no feasible successor, so watch it go active and query R3 first.

Packet Tracer can do steps 1 to 4. For real IOS behaviour and debugs, EVE-NG is the better fit. Our Packet Tracer vs EVE-NG comparison covers when the switch is worth it, and the EVE-NG CCNA labs list has more topologies to try once this one’s done. Short on hardware? You can build a home lab in a weekend.

Rather not wire it all up yourself? The SMEnode Labs CCNA workbook ships OSPF labs that boot ready to go, and the Cisco commands cheat sheet keeps every verify command on one page.

Frequently asked questions

Bottom line

• EIGRP vs OSPF is mostly a vendor question. Cisco-only and staying that way: EIGRP is fine. Anything else: OSPF.
• The EIGRP metric uses the slowest bandwidth and the total delay. On default K values, that’s the whole formula.
• OSPF’s default 100 Mbps reference bandwidth makes every fast link cost 1. Raise it on every router, or OSPF can pick the slow path.
• A feasible successor is a backup whose reported distance is below your feasible distance. It’s why EIGRP reconverges without asking anyone.
• No feasible successor means queries, and on a flat network queries are EIGRP’s weak spot. Stubs and summaries contain them.
• For exams: CCNA configures OSPF only, ENCOR compares the two, CCIE Enterprise tests every EIGRP detail in this post.

Build the triangle tonight. Run both protocols. When OSPF picks the slow link, you’ll never forget why.