Lessons (6, study in order)

What EIGRP is: a distance-vector protocol that "cheats"

Beginner · about 10 min

Goal: Pin down where it sits between distance-vector and link-state, and how it gets to keep the best of both.

First, recall the pain points of each family

Distance-vector (RIP): only listens to a neighbor saying "here's how far it is to reach that place," with no idea what the whole network looks like.
· Upside: simple, light on memory, light on CPU
· Downside: prone to loops, prevented only by blunt tools like a "15-hop limit," "30-second periodic updates," and "hold-down timers" — convergence is extremely slow (minutes)

Link-state (OSPF): every device holds a full topology map and runs Dijkstra itself.
· Upside: loop-free by nature, fast convergence
· Downside: the LSDB eats memory, any topology change means rerunning SPF for the whole area which costs CPU, areas are needed to control scale, and configuration is relatively complex

Where EIGRP cuts corners

EIGRP is still a distance-vector protocol — each router only knows "the distance its neighbors reported," with no full topology map and no Dijkstra run.

But it adds a mathematical test (the feasibility condition) that can, using nothing but the distances neighbors report, decide on the spot whether "using this path as a backup could create a loop."

So it ends up with:
· distance-vector's lightness (no need to store a full topology)
· link-state's loop-freedom + fast convergence

That's why it's called an advanced distance-vector, or a "hybrid" protocol.

What's the cost

· Cisco proprietary. The basic spec was published in 2013, but in practice only Cisco gear runs it well — a multi-vendor environment can only choose OSPF, which is often the decisive factor in protocol selection
· Query propagation in a large network is a risk unique to it (OSPF has no such issue); poor planning can lead to SIA

So in reality the usual choice is: EIGRP is fine in a pure-Cisco environment (simple config, fast convergence), but multi-vendor or external interconnects always go with OSPF.

Hands-on: take a look at what the topology table looks like

The topology table is EIGRP's core data structure, corresponding to show ip eigrp topology.
How it differs from the routing table: the topology table stores every candidate path (including backups), while the routing table only stores the one actually in use.
OSPF's counterpart is the LSDB, but the LSDB stores "topology," while the topology table stores "distance" — that difference is the dividing line between the two families.

Key takeaways

• EIGRP is still a distance-vector protocol: it only knows the distances its neighbors report, has no full topology map, and doesn't run Dijkstra
• It relies on the feasibility condition to prove loop-freedom locally, getting both lightness and fast convergence
• Cisco proprietary — a multi-vendor environment can only use OSPF, which is the decisive factor in protocol selection
• The topology table stores every candidate path (including backups); the routing table only stores the one actually in use

The composite metric: really just two variables

Beginner · about 12 min

Goal: Correct the common "five parameters" misconception, and learn to tune routing with delay.

The most common misconception

A lot of material says "EIGRP computes its metric from five parameters: bandwidth, delay, load, reliability, and MTU."
That statement is wrong, or at least highly misleading:

· MTU never participates in the calculation at all — it's just information carried along with the route
· Load and reliability don't participate by default (K2=K4=K5=0)

So by default there are only two variables: bandwidth and delay.

The formula and its two aggregation rules

With the default K values:

metric = 256 × ( 10^7 / minimum bandwidth(Kbps) + cumulative delay(μs) / 10 )

You only need to remember that the two fields aggregate differently:

· Bandwidth takes the minimum along the path (the bottleneck decides it — the barrel-stave effect)
· Delay is the sum of every segment along the path (cumulative)

This difference matters: if a path picks up an extra, very fast link, the bandwidth term doesn't change (the bottleneck is unchanged), but the delay term goes up — so taking one extra hop always makes the metric larger, even if that hop is very fast.

Why integer division causes trouble

10^7 / bandwidth is integer division:
· 1 Gbps → 10^7/1000000 = 10
· 10 Gbps → 10^7/10000000 = 1
· 40 Gbps → 1
· 100 Gbps → 1

Everything above 10 Gbps becomes indistinguishable — EIGRP thinks they're all equally fast.

The fix is the wide metric used in named mode (64-bit, with the numerator changed to 10^13), which stays distinguishable all the way up to 655 Tbps. New configurations should use named mode.

Tuning: change delay, not bandwidth

When you want traffic to take a different path, either parameter can get you there, but changing delay is the preferred choice:

· Changing bandwidth also drags along QoS reservations, the default parameters of certain features, and the baseline used by show interface statistics — lots of side effects
· Changing delay only affects the routing metric — the fewest side effects

⚠️ Note the delay command's unit is tens of microseconds: to set 2000 μs you write delay 200.
And you must change it on both ends — changing only one end makes the outbound and return paths diverge.

Hands-on: increase one link's delay and watch whether the successor changes

Go to the topology page and change the delay on R1-R3, then check back on the topology table to see whether the successor switched. This is the most direct way to verify that "the metric determines the chosen path."

Key takeaways

• By default there are only two variables, bandwidth and delay; MTU never participates, and load/reliability don't by default
• Bandwidth takes the min (the bottleneck), delay takes the sum (cumulative) — remembering these two aggregation rules is enough
• 10^7/bandwidth is integer division → everything above 10 Gbps becomes indistinguishable → use the wide metric from named mode
• For tuning, prefer changing delay (fewest side effects); its unit is tens of microseconds, and you must change it on both ends
• Don't turn on K2 (load) / K5 (reliability): a metric that shifts with traffic causes the route to keep flapping

The feasibility condition: this one rule is all of EIGRP

Intermediate · about 15 min

Goal: Fully nail down FD / RD / FC. Once this lesson clicks, you've learned 80% of EIGRP.

Three numbers

· FD (Feasible Distance) = my best metric to the destination
· RD (Reported Distance) = the distance my neighbor tells me it needs to reach the destination
· total metric = RD + the metric of my one hop to that neighbor

Every path in show ip eigrp topology is shown as (total metric/RD) — that's exactly where the two numbers in the parentheses come from.

The feasibility condition: RD < FD

A neighbor can serve as a backup if and only if the distance it reports is strictly less than my current best distance.

RD < FD

One that satisfies this is called a feasible successor, and the one with the smallest metric is called the successor.

★ Why this one rule guarantees loop-freedom

This is the core of the lesson, worth thinking through slowly:

Suppose neighbor N reports a distance smaller than mine (RD < FD). Question: could N possibly be routing back through me?

If N really did route through me, then N's distance = my distance + the segment from me to N > my distance.
That is, RD > FD, which contradicts the premise.

So: RD < FD ⟹ N does not route through me ⟹ using N as a backup cannot create a loop.

The entirety of DUAL rests on this one simple inequality. And notice this check is entirely local — it needs no knowledge of the whole topology, only a single number reported by a neighbor. This is exactly why EIGRP can achieve loop-freedom within a distance-vector framework.

The converse doesn't hold: infeasible ≠ looped

RD ≥ FD does not mean this path definitely has a loop — it only means loop-freedom cannot be proven.

In reality that path might well be perfectly fine and genuinely loop-free; it's just that it can't be verified from where I stand.
EIGRP chooses to be conservative: if it can't be proven, it won't be used, even at the cost of a round of Query/Reply to confirm.

"Better slow than looped" — that's the trade-off DUAL makes, and it's also the premise for understanding "why a route goes Active."

A counterintuitive detail: FD never gets raised

FD records "the best distance seen so far." It only ever gets lowered while the route is stable, and is never raised just because a path got worse, until the route goes Active again and gets recomputed.

Why design it this way? Because if FD could be raised freely, a path that was previously infeasible would suddenly become "feasible" — and the loop-free guarantee would collapse.

So sometimes on real hardware you'll see "the successor's metric is larger than FD," and that's not a bug.

Hands-on: compare two scenarios

First look at the "triangle" scenario: R1 has a feasible successor.
Then load the "no feasible successor" scenario: there are still two paths, but the backup one doesn't satisfy the FC.
Put the topology tables of the two scenarios side by side, and the role of the FC becomes clear.

Key takeaways

• FC: RD < FD, in other words "the neighbor is closer to the destination than I am"
• "Closer than me" ⟺ "it doesn't route through me" ⟺ "using it as a backup can't create a loop" — that's the entire proof
• This check is entirely local, needing no knowledge of the whole topology — this is why EIGRP can get both properties at once
• Infeasible ≠ looped — it just can't be proven loop-free on the spot. EIGRP would rather be conservative
• FD never gets raised just because a path got worse, or the FC would stop being valid

Convergence: zero packets versus a Query storm

Intermediate · about 14 min

Goal: See just how enormous the cost difference is between "having a feasible successor" and "not having one."

With a feasible successor: switch locally

When the successor fails, if the topology table has a feasible successor:

just promote it and use it — done.

· Not a single Query is sent
· No neighbor is asked anything
· The route stays Passive from start to finish
· Convergence time is bounded only by "how fast the interface notices it's down" → sub-second

Why is it safe to do this? Because the feasible successor was already filtered by the FC when it was recorded — loop-freedom was already proven the moment it was recorded.

Without a feasible successor: diffusing computation

① The route is set to Active (shown as A in show ip eigrp topology)
② A Query is sent to every neighbor (except the one the failure came from)
③ If a neighbor also has no feasible successor of its own, it keeps sending Query to its own neighbors ← "diffusion"
④ Only once every Reply has come back does it dare recompute FD and pick a new successor

The key point: convergence time depends on the slowest neighbor, not on the local device itself.
And while a route is Active, that destination is unreachable.

SIA: the worst case

If a neighbor is slow to reply (link congestion, CPU pegged, a one-way failure...), the route stays stuck in Active indefinitely.

After 3 minutes it triggers SIA (Stuck In Active), and EIGRP's response is brutal: it simply resets the neighbor that didn't reply, clearing out every route associated with it.

In a large network this can trigger a cascading storm — this is the failure mode EIGRP most needs to guard against, and OSPF has no equivalent problem at all.

Three ways to contain it (ranked by effectiveness)

① Set stub sites as stub routers — the most effective. A stub doesn't answer Query and doesn't take part in diffusion, directly cutting off most branches of the Query tree
② Do proper summarization — a summarization point "absorbs" Query traffic: upstream only knows the summary route, so changes in downstream specifics never propagate up
③ Make sure a feasible successor exists (sensible topology and metrics) — this avoids going Active in the first place

⚠️ Increasing the Active timer is not a real fix — it only delays the symptom; the actual problem is that the Query scope is too large.

Hands-on: run the same action in both scenarios

In the "no feasible successor" scenario, break R1-R3 and count how many Query/Reply messages get sent.
Then switch to the "triangle" scenario and break the same link — zero.

Once you've made this comparison, the claim "EIGRP converges fast" finally comes with its precise precondition.

Key takeaways

• With a feasible successor → 0 Query messages, Passive throughout, sub-second
• Without a feasible successor → goes Active, Query diffuses, convergence time depends on the slowest neighbor
• "EIGRP converges fast" is only true when a feasible successor exists
• SIA is a risk unique to EIGRP: after 3 minutes it simply resets the neighbor that didn't reply
• To contain SIA: stub is the most effective > summarization > ensuring a feasible successor exists; adjusting the timer doesn't help

Neighbors won't come up: a perfect mirror image of OSPF

Troubleshooting · about 12 min

Goal: Memorize one comparison table and you can localize neighbor problems in either protocol.

★ A comparison table

| Parameter | EIGRP | OSPF |
| --- | --- | --- |
| Process / AS number | must match | locally significant, can differ |
| Hello / Hold interval | can differ | must match |
| K values | must match | no such thing |
| MTU | not checked | must match (stalls at ExStart) |
| Authentication | must match | must match |
| Same subnet | required | required |

The first two rows are exact mirror images of each other — this is the easiest thing for someone coming over from OSPF to trip on.

AS number mismatch: the most frequent cause

The 100 in router eigrp 100 is the autonomous system number, and it's carried in every EIGRP packet — both ends must match exactly.

Contrast with OSPF: the 1 in router ospf 1 is only a local process ID; one end can use 1 and the other 65535 and they'll still form an adjacency.

Symptom: show ip eigrp neighbors is completely empty — not even a "forming" entry, because a mismatched Hello gets dropped at the very first step of processing it.

So: neighbor table empty, interface up, subnet correct → check the AS number first.

K-value mismatch: unique to EIGRP

K values determine how the metric is computed. If the two ends don't match → the computed metrics aren't comparable → "A thinks going through B is cheaper" and "B thinks going through A is cheaper" can both be true at once → an outright loop.

EIGRP's choice is to simply refuse to let such neighbors come up at all — better unreachable than looped.

Symptom is easy to recognize: the log repeatedly prints "K-value mismatch", and the neighbor bounces up and down.

The interface isn't participating in EIGRP at all

The network command is used to select local interfaces, not to "advertise this subnet."
If an interface's IP doesn't fall inside any network statement's range → that interface doesn't participate in EIGRP at all: it sends no Hello, and doesn't advertise its subnet either.

How to check: show ip eigrp interfaces — if the interface isn't listed, it wasn't selected.
Note EIGRP's network command uses a wildcard mask; if you omit it, it defaults to the classful A/B/C mask, which makes it very easy to select too much or too little.

passive-interface: not a fault

A passive interface neither sends nor receives Hello (so there will never be a neighbor there), but the subnet is still advertised as usual.

That's exactly its purpose: an interface facing end hosts should be set passive — it announces that subnet without wasting resources hunting for a neighbor on it (and it's safer too).
Seeing no neighbor on a passive interface is a sign of correct configuration.

Troubleshooting order

① show ip interface brief — is the interface up, is the IP right
② show ip eigrp interfaces — is this interface actually participating in EIGRP
③ show run | section router eigrp on both ends — is the AS number the same
④ check the log for K-value mismatch
⑤ debug eigrp packets hello — is the peer's Hello being received

Don't skip step ③.

Key takeaways

• EIGRP's AS number must match, its Hello interval doesn't have to; OSPF is exactly the opposite — remember this pairing
• Neighbor table completely empty → suspect the AS number first (a mismatched Hello is dropped at the very first step)
• Log shows K-value mismatch → K values differ; the metric weights need to be identical on both ends
• network is used to select interfaces, not to advertise a subnet; it uses a wildcard mask
• EIGRP doesn't check MTU (OSPF does), and no neighbor on a passive interface is completely normal

The handful of configs in real networks that really bite

Troubleshooting · about 12 min

Goal: Split horizon, auto-summary, variance, and redistribution's seed metric.

Split horizon: the trap every hub-and-spoke topology falls into

The rule: a route learned from an interface is never sent back out that same interface.
Its intent is loop prevention (a traditional distance-vector tool).

But in a hub-and-spoke setup (Frame Relay / DMVPN partial mesh), this backfires: the hub uses a single physical interface for multiple virtual circuits, so a route learned from Spoke1 never gets sent back out that same interface toward Spoke2 → the spokes can never learn routes from each other.

Note the precondition is "the same interface" — if each spoke has its own physical port, this problem doesn't occur.

Two fixes, the second is better

① Run no ip split-horizon eigrp <AS> on the hub's interface
　　This fixes it, but turns off the loop-prevention mechanism entirely

② Give each virtual circuit its own point-to-point subinterface (Se0/0.1, Se0/0.2)
　　Each subinterface is a separate interface, so split horizon naturally never blocks anything — no mechanism needs to be turned off

In production, prefer the second option.

Auto-summary: the killer of discontiguous networks

With auto-summary turned on, a router automatically summarizes at classful boundaries (class A/B/C).

A classic incident: R1 sits behind 10.1.1.0/24, R2 behind 10.2.2.0/24, connected through 172.16 in the middle. Both routers summarize their own side to 10.0.0.0/8 and advertise it → both sides claim "I can reach the whole of 10.0.0.0/8" → they overwrite each other, and traffic takes the wrong path.

Newer IOS defaults to no auto-summary, older IOS defaults to it being on — this is a must-check item when taking over legacy equipment.

variance: only applies to feasible successors

variance N lets paths whose metric is < N×FD also be used for forwarding (unequal-cost load balancing, an ability unique to EIGRP — OSPF can only do equal-cost balancing).

⚠️ Only feasible successors are eligible — an infeasible path is never used no matter how small its metric is, because loop-freedom can't be guaranteed. This is the point people misunderstand most often.

Be careful in production: traffic is split in inverse proportion to the metric, so users on the slower path will notice a clearly worse experience. Often "having a backup but not load-balancing across it" beats "load-balancing onto a bad path."

Redistribution must be given a seed metric

When redistributing a static route or another protocol into EIGRP, you must specify a metric:

redistribute static metric 100000 100 255 1 1500

(in order: bandwidth delay reliability load MTU)

Without it, the metric is infinite, and the route simply never gets advertised at all.
The symptom is "I clearly configured redistribute, but the neighbor still isn't learning the route" — and no error is ever reported, which makes it very hard to track down.

(Contrast: redistributing into OSPF has a default metric of 20, so it works even without specifying one.)

External routes get a different administrative distance

· EIGRP internal routes: administrative distance 90
· EIGRP external routes (brought in via redistribution): administrative distance 170

170 is larger than OSPF's 110, so when the same prefix is learned from both OSPF and EIGRP-external at once, the OSPF route wins. This detail frequently causes unexpected traffic paths during protocol migrations.

Key takeaways

• Split horizon can stop spokes from learning routes from each other in a hub-and-spoke setup over a shared physical interface; prefer point-to-point subinterfaces to fix it
• auto-summary can break a discontiguous network; newer IOS defaults it off, older IOS defaults it on
• variance only applies to feasible successors — an infeasible path is never used no matter how fast it is
• Redistribution must be given a seed metric, or the metric is infinite and the route never gets advertised (with no error at all)
• EIGRP's administrative distance is 90 internal, 170 external (larger than OSPF's 110)