Comparing EIGRP and OSPF for CCNP ENCOR: Path Selection, Load Balancing, Convergence, and Metrics

Comparing EIGRP and OSPF for CCNP ENCOR: Path Selection, Load Balancing, Convergence, and Metrics

1. Introduction: Why EIGRP vs OSPF Matters for ENCOR

For CCNP 350-401 ENCOR, Cisco expects more than protocol definitions.

You’ve really gotta understand how they form neighbors, store control-plane state, pick paths, recover after a failure, and scale when the design gets messy in the real world.

That is the difference between recognizing a term on the exam and correctly diagnosing why a route was or was not installed.

This topic maps directly to the ENCOR blueprint areas around routing concepts: advanced distance vector vs. link-state behavior, metrics, path selection, path operations, and load balancing.

In production, both EIGRP and OSPF are absolutely solid IGPs, but they don’t think about the network the same way. They use different control-plane models, and that difference really starts to matter when you’re troubleshooting something ugly at 2 a.m.

If you can explain what each protocol learns, where it stores that information, and what happens after a topology change, you are thinking at the right level for both the exam and real operations.

2. EIGRP vs OSPF at a Glance

EIGRP is an advanced distance vector protocol that uses DUAL, the Diffusing Update Algorithm, to select loop-free paths.

Historically, it showed up mostly in Cisco-only networks, and even though the protocol’s been documented more openly over time, you’ll still run into it most often in Cisco-centric environments.

OSPF, on the other hand, is an open-standard link-state protocol. It floods LSAs, builds a link-state database, and then runs SPF with Dijkstra’s algorithm. So yeah, it’s a very different operating model.

That difference drives nearly every operational distinction between them.

CategoryEIGRPOSPF
Protocol modelAdvanced distance vectorLink-state
Decision algorithmDUALSPF/Dijkstra
Primary metricComposite metric; by default uses minimum bandwidth and cumulative delayCost; cumulative outbound interface cost along the SPF path
Load balancingEqual-cost and unequal-cost with varianceEqual-cost only
Scalability mechanismSummarization, stubs, query containmentAreas, ABRs, LSDB scoping, summarization at ABR/ASBR boundaries
Typical fitPredominantly Cisco environments, branch/WAN designsMulti-vendor enterprise, campus, core/distribution

As a teaching shortcut, you can think of EIGRP as more neighbor-centric and OSPF as more topology-centric, but that is an analogy, not formal protocol terminology.

3. Control-Plane Data Structures and Architecture

EIGRP maintains three key structures: a neighbor table, a topology table, and the routing table.

The neighbor table is pretty much what it sounds like: it tracks the EIGRP peers the router has actually formed adjacencies with.

The topology table holds all the EIGRP-learned paths, including the current successor and any possible backup paths.

The routing table only holds the best routes the router has chosen to install.

This distinction matters because a route can exist in the topology table but not be installed in the RIB.

OSPF has a similar high-level flow but different content.

OSPF keeps a neighbor table, an LSDB, and the routing table.

The LSDB isn’t just a list of routes learned from neighbors. It’s the synchronized link-state picture for an area, which is a pretty big difference operationally.

Each router runs SPF against that database and installs the resulting best routes into the routing table.

For ENCOR, keep the terminology straight:

FunctionEIGRPOSPF
Neighbors tracked inNeighbor tableNeighbor table
Control-plane topology info stored inTopology tableLSDB
Installed forwarding choices stored inRouting tableRouting table

Named EIGRP is not a different routing protocol. It’s just the modern Cisco IOS and IOS XE configuration model for EIGRP, using address-family style configuration. On ENCOR, you should recognize both classic and named syntax.

4. Neighbor Formation, Packet Types, and Adjacency Requirements

EIGRP discovers neighbors with Hello packets.

It uses RTP, the Reliable Transport Protocol, to send certain EIGRP packets reliably when needed.

The packet types you need to know are Hello, Update, Query, Reply, and ACK.

Updates are bounded rather than flooded everywhere. Queries and replies appear when DUAL needs to search for an alternate path.

EIGRP neighbors typically require these conditions to match or be valid: same autonomous system number, matching K-values, matching authentication if configured, and working Layer 3 reachability over the shared link. A mismatch in AS number or K-values prevents adjacency formation.

OSPF uses five packet types: Hello, Database Description (DBD), Link-State Request (LSR), Link-State Update (LSU), and Link-State Acknowledgment (LSAck).

Neighbor relationships move through Down, Init, 2-Way, ExStart, Exchange, Loading, and Full.

On broadcast multiaccess networks, routers discover each other with Hellos, but full adjacency is normally built only with the DR and BDR. That’s a detail people forget after a while, and then they wonder why every router isn’t fully adjacent to every other router.

DROTHER routers remain in 2-Way with each other.

OSPF adjacency prerequisites are more extensive than many candidates remember: area ID match, hello/dead timer match, authentication match, compatible network type, correct MTU handling during database exchange, and matching subnet or common-segment expectations on broadcast and nonbroadcast media. Stub flag consistency also matters. Router IDs do not need to match, but each must be unique within the OSPF domain.

OSPF network type affects behavior heavily. Broadcast networks elect a DR and BDR.

Point-to-point links don’t use DR/BDR election.

Nonbroadcast networks may need manual neighbor configuration depending on the design and platform behavior.

This is why network type mismatches can create confusing adjacency symptoms.

OSPFv3 was introduced for IPv6, but modern implementations can also carry IPv4 address families. Operationally, it still follows the same link-state model, with notable differences such as per-link behavior and use of link-local addresses for neighbor formation.

5. Metric Calculation Walkthrough

EIGRP and OSPF both rank paths, but they do it very differently.

EIGRP metric: by default, classic EIGRP uses minimum bandwidth and cumulative delay.

K1 and K3 are enabled by default. K2, K4, and K5 are disabled.

MTU is carried as a route attribute, but it doesn’t participate in the metric calculation. A common simplified formula for default classic metric is:

metric = 256 x ((10^7 / minimum bandwidth in kbps) + cumulative delay in tens of microseconds)

Example: if path A has a minimum bandwidth of 100000 kbps and total delay of 2000 tens of microseconds, then metric = 256 x (100 + 2000) = 537600.

If path B has a minimum bandwidth of 10000 kbps and a delay of 1000, then the metric becomes 256 x (1000 + 1000) = 512000.

Even though path B has lower delay, path A may still lose or win depending on the combined values. That is why changing interface delay can influence path choice dramatically.

OSPF metric: cost is cumulative and based on outbound interface costs along the path. On Cisco devices, the common formula is:

cost = reference bandwidth / interface bandwidth

If the reference bandwidth is left at an old default, high-speed links may all calculate to cost 1, masking real differences.

For example, with a reference bandwidth of 100000 Mbps, a 1 Gbps interface has cost 100, a 10 Gbps interface has cost 10, and a 100 Gbps interface has cost 1.

If one router is still using an older reference value while the rest of the domain has been updated, path selection can get inconsistent fast, and that’s where people start chasing phantom problems.

Manual interface cost overrides the derived value.

Exam trap: administrative distance is not the same as metric.

Also, don’t mix up the order of decisions: longest prefix match happens first, then administrative distance chooses between protocols, and then the protocol metric chooses the winner inside that protocol.

Default AD values worth memorizing: EIGRP internal 90, OSPF 110, EIGRP external 170.

6. Path Selection and Route Preference

In EIGRP, the best path is the successor. A backup path may become a feasible successor if it satisfies the feasibility condition: the neighbor’s reported distance must be less than the local router’s feasible distance for the current successor. Terms matter here:

TermMeaning
Feasible Distance (FD)Local router’s best known metric to the destination
Reported Distance (RD)Neighbor’s advertised metric to the destination
SuccessorCurrent best loop-free path installed in the routing table
Feasible SuccessorPrequalified loop-free backup path in the topology table
PassiveStable route state; no active recomputation in progress
ActiveRoute is being recomputed because no feasible successor exists

Not every alternate path becomes a feasible successor. That is a classic ENCOR distractor. EIGRP may know about multiple paths, but if the feasibility condition is not met, the route has no prequalified backup and may need to go active after a failure.

OSPF does not use neighbor-reported distance in that way. It calculates shortest paths from the LSDB. OSPF route preference also includes route type.

In normal Cisco behavior, intra-area routes are preferred over inter-area routes, and inter-area routes are preferred over external routes.

Among external routes, E1 and E2 behave differently in an important way: E1 includes the internal cost to reach the ASBR plus the external metric, while E2 treats the external metric as the main value and gets compared after route-type logic.

That route-type hierarchy matters on ENCOR questions.

7. Load Balancing and Route Installation

OSPF supports equal-cost multipath only, subject to platform limits and maximum-paths settings. EIGRP supports equal-cost load balancing and can also install unequal-cost paths with variance, again subject to platform support and maximum-paths limits.

The precise EIGRP idea is this: an alternate path can be considered for unequal-cost load sharing when it is loop-free and its metric is less than or equal to variance multiplied by the feasible distance of the successor. In the common ENCOR treatment, feasible successors are the key loop-free alternates to focus on. Traffic sharing is also influenced by metric ratios and traffic-share behavior, not just by the fact that two routes are installed.

Example: if the successor metric is 1000 and variance is 2, an alternate path with metric 1800 may qualify if it is loop-free and eligible for installation. A path with metric 2500 will not. If the alternate fails loop-free qualification, it still will not be used simply because variance exists.

Also separate route installation from forwarding behavior.

The control plane decides which routes get into the RIB.

The data plane, usually CEF, handles the actual forwarding and load sharing across the installed paths.

That distinction shows up in exam questions that try to blur RIB decisions with packet-forwarding behavior.

8. Failure and Reconvergence Sequence

EIGRP convergence depends heavily on whether a feasible successor already exists.

If a feasible successor exists: the successor fails, DUAL promotes the feasible successor, the route remains loop-free, and traffic can switch very quickly with minimal query activity.

If no feasible successor exists: the route goes active, the router sends queries to neighbors, and waits for replies.

The route doesn’t go back to passive until DUAL finishes figuring out the new best path.

If replies are not received before the active timer expires, the route can enter a stuck-in-active condition. SIA is not just “slow convergence”; it is a specific failure to receive required replies in time, often caused by poor query scoping, unstable neighbors, or packet loss.

OSPF reacts differently.

With OSPF, a topology change triggers LSA flooding within the area scope, routers update the LSDB, and SPF is rerun as needed.

Area boundaries do limit LSDB flooding and SPF scope inside an area, but they don’t magically stop all wider routing effects, because ABRs still calculate and advertise inter-area information.

Modern implementations may use incremental SPF, SPF throttling, BFD, or fast hello mechanisms to improve convergence, so do not assume every event means a full heavyweight recalculation in exactly the same way.

BFD is worth knowing for both protocols. It is not part of EIGRP or OSPF themselves, but it is commonly used to accelerate failure detection beyond protocol hello/dead or hello/hold timers.

9. Scalability, Area Types, and Design Tradeoffs

EIGRP scales best when queries are contained. The main tools are summarization, stub routing, and sensible topology boundaries.

Modern EIGRP supports manual summarization on interfaces, and automatic classful summarization is disabled by default and usually avoided in modern enterprise designs.

EIGRP stub routers reduce unnecessary query propagation and are especially useful at branch edges.

OSPF scales through hierarchy. Area 0 is the backbone. ABRs connect areas, and ASBRs inject external routes. OSPF summarization is not arbitrary everywhere: inter-area summarization is done on ABRs, and external route summarization is done on ASBRs. Inside an area, routers still maintain the full LSDB for that area’s topology.

Area types matter. Stub areas block Type 5 external LSAs and typically receive a default route instead. Totally stubby areas, a Cisco extension, further suppress inter-area summary routes. NSSA allows limited external redistribution inside the area using Type 7 LSAs, which are translated at the ABR. These area types reduce specific categories of route information; they do not remove the need for routers to maintain the area’s internal topology database.

In design terms, OSPF is usually the better fit for multi-vendor enterprise environments. EIGRP remains attractive in predominantly Cisco deployments, especially branch and WAN designs where DUAL behavior, stubs, and summarization can be used deliberately.

10. Redistribution, Security, and Mixed Deployments

Redistributing between EIGRP and OSPF is where many clean designs become messy.

EIGRP needs an explicit seed metric when you redistribute from another protocol.

OSPF external routes show up as E1 or E2, and route tagging should be used so mutual redistribution doesn’t just feed routes back into itself.

If you are redistributing both ways, define clear boundaries, summarize where appropriate, and tag routes so the receiving protocol can identify and block re-entry.

Security deserves more attention than a passing mention of authentication mismatches.

Unauthorized adjacencies can inject bad routes or destabilize the control plane, and that’s definitely not something you want in production.

For EIGRP, use the supported authentication methods on your platform, like MD5 or HMAC-based key chains where available, and make sure key-chain rollover lines up on both ends.

For OSPF, match the authentication type and keys at the area or interface level, depending on how the design is built.

In both protocols, passive interfaces are a simple but very effective control-plane safeguard. You can advertise connected networks without forming unnecessary adjacencies on user-facing segments, which is usually exactly what you want.

Control-plane policing and protocol exposure reduction also matter in larger enterprise networks.

11. Troubleshooting and Verification Workflow

A reliable workflow is: neighbor first, control-plane database second, route installation third, metric explanation fourth.

EIGRP verification: show ip eigrp neighbors confirms adjacency and hold status. show ip eigrp topology or show ip eigrp topology all-links shows successor, feasible successor candidates, and active/passive state. show ip protocols confirms AS, K-values, passive interfaces, and redistribution. show ip route confirms what actually installed.

OSPF verification: show ip ospf neighbor reveals state such as 2-Way, ExStart, Exchange, or Full. show ip ospf interface or show ip ospf interface brief confirms area, timers, cost, network type, and DR/BDR status. show ip ospf database router|network|summary|external validates LSDB contents. show ip ospf border-routers can help with inter-area visibility. show ip route confirms installed routes.

Mini-scenario 1: EIGRP backup path missing. If the route is in the topology table but only one path is installed, check whether the alternate path failed the feasibility condition. If the primary fails and the route goes active, that tells you there was no feasible successor. Then check summarization, stub placement, and query scope.

Mini-scenario 2: OSPF stuck in ExStart/Exchange. Think MTU mismatch first, then network type mismatch, then timer or authentication mismatch. Use show ip ospf neighbor and show ip ospf interface on both sides. ExStart/Exchange is one of the most testable OSPF symptoms.

Debug commands vary by platform and software release, so use context-appropriate syntax and prefer lab environments or conditional debugging. Uncontrolled debugging on production routers can consume CPU and make a bad day worse.

12. Simplified Study Configurations

The following are simplified study examples; exact syntax can vary by IOS/IOS XE release.

Named EIGRP with passive-interface strategy and stub

router eigrp CORP
address-family ipv4 unicast autonomous-system 100
eigrp router-id 1.1.1.1
network 10.10.0.0 0.0.255.255
af-interface default
passive-interface
exit-af-interface
af-interface GigabitEthernet0/0
no passive-interface
exit-af-interface
topology base
variance 2
exit-af-topology
eigrp stub connected summary

OSPF with reference bandwidth and interface tuning

router ospf 10
router-id 2.2.2.2
auto-cost reference-bandwidth 100000
passive-interface default
no passive-interface GigabitEthernet0/1
network 10.10.12.0 0.0.0.255 area 0
interface GigabitEthernet0/1
ip ospf cost 20
ip ospf priority 100

Remember that auto-cost reference-bandwidth 100000 means 100,000 Mbps, or 100 Gbps. That value should be consistent across the OSPF domain.

13. ENCOR Quick Memory Aids and Exam Traps

Most testable differences:

  • Feasible successor, variance, active/passive, query/reply = EIGRP
  • LSDB, LSA, DR/BDR, area, SPF, ExStart/Exchange = OSPF
  • Unequal-cost load balancing = EIGRP, not OSPF
  • Topology table is not the routing table
  • OSPF does not choose paths based on a neighbor’s reported total distance
  • Longest prefix match first, then AD, then metric

Default values worth remembering: EIGRP internal AD 90, OSPF AD 110, EIGRP external AD 170.

Question patterns:

  • If a route goes active, think EIGRP query behavior and missing feasible successor.
  • If adjacency stalls in ExStart/Exchange, think OSPF MTU or network type mismatch.
  • If OSPF picks an odd path after a link upgrade, think reference bandwidth.
  • If an alternate EIGRP path exists but is not installed, think feasibility condition or variance limits.

14. Conclusion

EIGRP and OSPF are both enterprise-grade IGPs, but they operate from different assumptions. EIGRP relies on neighbor relationships, DUAL, and the topology table to maintain loop-free primary and backup paths. OSPF relies on LSAs, an LSDB, and SPF calculations to derive shortest paths from a synchronized topology view.

For ENCOR, the high-yield comparison is straightforward: EIGRP is advanced distance vector; OSPF is link-state. EIGRP can use feasible successors and variance for fast failover and unequal-cost load sharing. OSPF uses cumulative cost, route-type preference, and equal-cost multipath. EIGRP scaling depends on query containment; OSPF scaling depends on area design and LSDB scope. If you can explain those differences clearly, you are well prepared for both the exam and real troubleshooting.