Lessons (6, study in order)

How RIP works: the whole story in one sentence

Beginner · about 8 min

Goal: Explain how distance-vector routing works, and see exactly where it parts ways with link-state routing.

One sentence: read your whole routing table aloud to your neighbors

RIP's entire way of working is this:

Every 30 seconds, recite your whole routing table to every neighbor.
Each neighbor that hears it does one thing: add 1 to the metric, and if it's smaller than what I have now, switch to it.

No neighbor state machine, no topology map, no SPF — just those two sentences.
That's also why it became popular in the first place: simple enough that it's almost impossible to misconfigure.

The metric is just hop count

Passing through one router counts as 1 hop. A connected network is 0 hops.

· Maximum 15 hops
· 16 = infinity = unreachable (not "far away", but cannot be reached at all)

⚠️ The metric only looks at hop count, never at bandwidth. A 64K serial link and a 10-gigabit Ethernet link look exactly the same to RIP (both 1 hop).
This is its most criticized flaw, and the direct reason EIGRP/OSPF introduced bandwidth-based metrics.

Where it parts ways with link-state routing

| | RIP (distance-vector) | OSPF (link-state) |
| --- | --- | --- |
| What it knows | only the distance reported by neighbors | the whole network's topology map |
| How it computes | neighbor's value + 1, take the minimum | runs Dijkstra itself |
| What it sends | the entire routing table, every 30 seconds | only the LSAs that changed |
| Loop prevention | a pile of band-aids | loop-free by nature (the graph is complete) |

"Only knowing the distance reported by neighbors" is the single fact that produces every single one of RIP's problems — the next lesson shows exactly what goes wrong.

Hands-on: watch hop count grow along a chain

The current scenario is a chain R1 - R2 - R3. See how many hops it takes R1 to reach the subnet behind R3, and how many hops it takes R3 to reach the subnet behind R1.
Also notice: every router keeps only one route per destination — unlike EIGRP, it doesn't keep the distances reported by every neighbor. This becomes very important in Lesson 3.

Key takeaways

• RIP = recite the whole routing table to your neighbors every 30 seconds; whoever receives it adds 1 and switches if it's smaller than what they have
• The metric is hop count, maximum 15, 16 = unreachable
• The metric completely ignores bandwidth — a 64K serial link and a 10-gigabit link are both just 1 hop
• Only one route is kept per destination (compare EIGRP, which keeps the distance reported by every neighbor)

★ Counting to infinity: the original sin of distance-vector routing

Intermediate · about 15 min

Goal: See exactly how a loop forms. This lesson is the core of the entire module.

First, a rule you can't get around: bad news from the current next hop must be accepted

Distance-vector routing has a rule it has no choice but to obey:

If my current next hop tells me things got "farther away", I must accept it.

Why must I? Because it is the authority for this route — I've been forwarding to that subnet through it all along, so if it says the distance grew, it really did grow.

This rule is perfectly reasonable. But it's exactly where the loop comes from.

How an echo forms

R1 —— R2 —— destination subnet. R1 learned "1 hop" from R2.

The destination subnet goes down, and R2 just silently deletes the route (no route poisoning):

① R2 deleted it, but R1 still remembers "reach it via R2, 1 hop"
② On its regular cycle, R1 tells R2 about this — R2 hears "R1 says it can reach it in 1 hop"
③ R2 thinks "then I can go via R1, 2 hops" → learns it
④ R2 tells R1 "I'm 2 hops" → R1's next hop for this route is R2 → must accept it → 3 hops
⑤ R1 tells R2 → 4 hops → …

Each round adds 1, all the way up to 16 before it stops.

And during every one of these rounds, both R1 and R2 believe "I can reach it via the other one" — traffic is genuinely bouncing back and forth between the two devices, a real loop, not just an ugly-looking table entry.

Hands-on: watch it count all the way to 16 with your own eyes

Go to the simulation page, turn off every loop-prevention mechanism, take the destination subnet down, and click through round by round.
Watch the metric go 1 → 2 → 3 → … → 16, and how many seconds it took in total.

16 is damage control, not a fix

"16 = infinity" serves exactly one purpose: if a loop does form, give it somewhere to stop.

It doesn't prevent a loop from forming, it only limits the damage. The price is that RIP's network diameter is capped at 15 hops — the direct reason it can't be used in medium-to-large networks.

Key takeaways

• ★ Bad news from the current next hop must be accepted — this perfectly reasonable rule is exactly where the loop comes from
• Echo: I tell a neighbor my own stale information, the neighbor adds 1 and tells it back to me, and as its downstream I must accept it
• During counting-to-infinity, traffic is genuinely looping, not just an ugly table entry
• 16 is damage control, not a fix, at the cost of capping the network diameter at 15 hops

Four band-aids: what each one fixes, and what it doesn't

Intermediate · about 16 min

Goal: Understand each of the four loop-prevention mechanisms one by one, and pin down exactly where each one's limits are.

Band-aid one: split horizon

A route learned from one interface is never advertised back out that same interface.

Back to the previous lesson's example: R1 learned the destination subnet from the interface connected to R2, so it will not advertise it back to R2 through that same interface → the echo is cut off at the very first step.

✅ What it fixes: a direct echo between two devices.
❌ What it doesn't fix: a case where some router learns this route from a direction other than the source.

The limits of split horizon (a point often explained wrong)

A common claim is that "split horizon can't stop a loop among three or more devices" — this claim is inaccurate.

For a symmetric triangle, a four-node ring, or a chain topology, split horizon actually does stop it: because every neighbor of the router that lost the route learned that route from that very router in the first place, so all of them get blocked by split horizon and no echo can form.

For it to actually fail requires an asymmetric condition: some router learned the route from some other direction. Common real-world causes of this asymmetry: a misconfigured passive-interface, asymmetric route filtering, or updates crossing in transit.

So the accurate statement is: split horizon only guarantees blocking a direct echo between two devices — it does not guarantee loop-freedom for arbitrary topologies.

Band-aid two: route poisoning + triggered updates

Route poisoning: when a link goes down, don't silently delete the route — actively advertise it as 16 (unreachable).
Triggered updates: don't wait for the 30-second cycle — send immediately.

Together, bad news spreads across the whole network in a few seconds — instead of every device separately waiting out its own 180-second timeout.

These two have the biggest impact on convergence speed. Go to the comparison page and check the numbers: with them off, convergence takes hundreds of seconds; with them on, tens of seconds.

Band-aid three: poison reverse

A stronger version of split horizon: a route learned from an interface is still advertised back out that same interface, but with its metric written as 16.

How it beats split horizon:
· Split horizon is "say nothing at all"
· Poison reverse is "explicitly say I can't reach it"

An explicit piece of bad news is more reliable than silence — because silence could just as easily be a dropped packet.
The cost is a larger update packet (it has to carry those entries marked 16).

Band-aid four: holddown timer

After a route becomes unreachable, for 180 seconds, don't accept any update with a worse metric, giving the whole network time to learn the bad news.

⚠️ This is a purely "trade time for correctness" band-aid, and the cost is very real:
even if a genuinely good backup path exists, you still have to sit and wait out the holddown period.
This is the main reason RIP converges slowly.

Hands-on: run all four comparisons

The comparison page runs five configurations back to back (everything off / split horizon only / plus poisoning+triggered updates / everything on / using poison reverse), laying "did it count to infinity, how many rounds to converge, how many seconds" side by side.

Run it once each on the two-device scenario and the asymmetric three-device scenario, and the conclusion becomes very clear.

Key takeaways

• Split horizon: don't advertise back out the interface you learned it from — only guarantees blocking a direct echo between two devices
• Route poisoning + triggered updates: the two mechanisms with the biggest impact on convergence speed
• Poison reverse is more reliable than split horizon — an explicit piece of bad news beats silence
• The holddown timer trades time for correctness, at the cost of waiting even when a backup exists
• ★ All four are band-aids, and not one of them is a real fix

Four timers: exactly where the slowness comes from

Intermediate · about 10 min

Goal: Work out the cause-and-effect behind the four numbers 30 / 180 / 180 / 240.

The four timers

| Timer | Default | Purpose |
| --- | --- | --- |
| Update | 30 s | periodically send the whole routing table |
| Invalid | 180 s | how long without an update before the route is declared invalid (= 6 cycles) |
| Holddown | 180 s | how long to refuse worse updates |
| Flush | 240 s | how long before the route is permanently removed from the table |

Two relationships are all you need to remember:
· Invalid = 6 × Update — tolerates 5 consecutive missed updates
· Flush = Invalid + 60 — after going invalid, it's kept around another 60 seconds, still being advertised as poisoned

Why Flush is 60 seconds later than Invalid

A detail most people never think about: the route is already invalid, so why not delete it right away?

Because it still needs to keep advertising the "16". Once deleted, there's nothing left to advertise, and neighbors would each have to wait out their own 180-second timeout — which would make convergence far slower.

So those 60 seconds are a deliberately reserved window used to carry out route poisoning.

Three sources of slow convergence

① Slow detection — without route poisoning, you have to wait out the 180-second Invalid timeout before knowing a neighbor is gone
② Slow propagation — every hop has to wait out a 30-second cycle (triggered updates help here)
③ The holddown period — worse updates are refused for 180 seconds, even if a backup exists you still wait

Stack all three together, and RIP's convergence lands in the tens-of-seconds-to-minutes range.
Compare that to EIGRP, which is sub-second when a feasible successor exists, and OSPF, which is a few seconds.

Timers must be changed network-wide together

⚠️ Timers must be consistent across the whole network.
If one end sends every 30 seconds while the other end thinks 90 seconds without an update means invalid → you get a persistent oscillation where "one end has already deleted the route while the other is still advertising it."

And shrinking the Update interval noticeably increases bandwidth usage (because it's a full send every time) — that's RIP's dilemma: faster means sending more, and sending more costs bandwidth.

Key takeaways

• Invalid = 6 × Update (tolerates 5 misses), Flush = Invalid + 60
• Flush being 60 seconds later is deliberate — it reserves a window to keep advertising the poisoned route
• Slow convergence comes from three places: slow detection (180s) + one cycle per hop + a 180s holddown period
• Timers must be consistent across the whole network; shrinking Update noticeably increases bandwidth (because it's a full send)

v1 vs v2: how one missing field explains every limitation

Intermediate · about 12 min

Goal: Work out just how many consequences flow from the single flaw of "no mask in the packet".

v1's original sin: the packet carries no subnet mask

RIPv1's update packets contain only the network number, no mask.

So the receiver is left to guess:
· If this route falls within the same classful network as the receiving interface → reuse the receiving interface's mask
· Otherwise → fall back to the natural class A/B/C mask

Guess right and nothing goes wrong; guess wrong and the route is simply incorrect.

Consequence one: no VLSM support

If masks aren't uniform within the same classful network (say, a /30 for an interconnect link and a /24 for a user subnet), v1 is guaranteed to guess wrong.

That's exactly the current scenario: 172.16.100.0/30 is the interconnect segment, 172.16.2.0/24 is the user subnet. R1 receives 172.16.2.0 on its /30 interface and reuses /30 → learns it as 172.16.2.0/30, while the real subnet is /24 → more than half of those addresses become unreachable.

Consequences two through four: no CIDR, no discontiguous subnets, no authentication

· No CIDR / no classless summarization — without a mask there's no way to express a prefix of arbitrary length
· No support for discontiguous subnets — it can only advertise by classful network, so two subnets sharing a class inevitably overwrite each other
· Uses broadcast 255.255.255.255 — every device on the subnet is forced to receive the packet, including devices not even running RIP (wasteful + a security concern)
· No authentication — anyone can inject fake routes onto the subnet

What v2 added

v2 put to use fields that v1's packet left filled with zeros:

· Carries the subnet mask → supports VLSM / CIDR / discontiguous subnets
· Multicasts to 224.0.0.9 instead of broadcasting → devices not running RIP are left alone
· Supports plaintext / MD5 authentication
· Carries a next-hop field → can point to something other than the advertiser itself (saves a hop in NBMA scenarios)
· Carries a route tag → marks routes redistributed from elsewhere

⚠️ But there's a catch: auto-summary is still on by default — supporting classless routing does not mean classless behavior is the default; you must explicitly run no auto-summary.

The trickiest part: default behavior creates a one-way path

Cisco's default: send v1, but accept both v1 and v2.

So when "one end is configured with version 2 and the other end forgot to":
· The v1 end sends v1 → the v2 end can receive it (it accepts both v1 and v2)
· The v2 end sends v2 → the v1 end cannot receive it

The result is one-way reachability — much harder to diagnose than a total outage, because "half of it works".

Conclusion: both ends must explicitly configure version 2.

Key takeaways

• v1's original sin is exactly one thing: the packet carries no subnet mask
• From that follows: no VLSM / CIDR / discontiguous subnet support, plus broadcast and no authentication
• v2 adds the mask, multicast, authentication, next hop, and route tag
• ⚠️ v2's auto-summary is still on by default — you must explicitly run no auto-summary
• ★ Both ends must explicitly configure version 2 — configuring only one end creates a one-way path

Looking at all three protocols together: what RIP teaches us

Intermediate · about 12 min

Goal: String RIP / EIGRP / OSPF together into one line of evolution. This is the real payoff of learning RIP.

First, admit it: RIP is basically unused in real networks today

RIP's problems are fundamental flaws, not things you can tune away:

· Network diameter capped at 15 hops
· Convergence in the tens of seconds to minutes
· Metric only looks at hop count — a 64K serial link is just as good as a 10-gigabit link
· A full send every 30 seconds — costly bandwidth once the network gets large

The current scenario is exactly point three: for the subnet behind R3, RIP picks the 64K serial link (1 hop) instead of the two-hop 10-gigabit path.

How EIGRP fixed it

EIGRP is still a distance-vector protocol (it only knows the distances reported by neighbors, with no topology map), but it adds one test:

The feasibility condition: RD < FD (the neighbor is closer to the destination than I am)

Why this one test is enough: if a neighbor is closer to the destination than I am, it cannot possibly be routing back through me (going through me would cost at least "my distance plus the path back") → treating it as a backup is guaranteed loop-free.

As a result:
· The loop-freedom of the backup path is proven in advance → when the successor fails, it switches immediately, with zero packets sent
· There's no need for a "trade time for correctness" band-aid like a holddown timer
· The metric switches to bandwidth + delay, no longer just hop count

EIGRP is essentially "replacing RIP's band-aids with a single mathematical test."

How OSPF fixed it

OSPF takes an entirely different approach: instead of only listening to the distances neighbors report, it gives every device the whole network's topology map, and each device runs Dijkstra itself.

With a complete graph, a loop becomes mathematically impossible — which is exactly why OSPF has no split horizon, no poison reverse, no holddown timer, none of that.

The cost: the LSDB consumes memory, any topology change means rerunning SPF for the whole area, areas have to be carved out to control scale, and configuration is more complex.

Three-way comparison

| | RIP | EIGRP | OSPF |
| --- | --- | --- | --- |
| Type | Distance-vector | Advanced distance-vector | Link-state |
| What it knows | distance reported by neighbors | distance reported by neighbors | the whole network's topology map |
| Routes kept per destination | 1 | all of them (topology table) | the whole network graph |
| Metric | hop count | bandwidth + delay | cost (inverse of bandwidth) |
| Diameter limit | 15 hops | very large | very large |
| Loop prevention | four band-aids | feasibility condition | complete topology |
| Convergence | tens of seconds to minutes | sub-second with an FS | a few seconds |
| Update style | full send every 30 s | only changes | only changes |
| Vendor | standard | Cisco proprietary | standard |

The "routes kept per destination" row is the single most important difference — RIP keeps only 1, so when the successor fails, it has nothing on hand at all and has to slowly relearn everything.

So why bother learning RIP at all

Not in order to configure it, but because:

It's what makes clear exactly why EIGRP and OSPF are needed.

· Without understanding counting to infinity → you won't truly understand what EIGRP's feasibility condition is guarding against
· Without understanding the cost of "keeping only one route" → you won't understand why the topology table keeps the distance from every neighbor
· Without understanding the limits of "only listening to what neighbors say" → you won't understand why OSPF goes to such lengths to synchronize the LSDB

RIP is the starting point of this line of evolution — every one of its flaws corresponds to a design choice made later on.

Key takeaways

• RIP's fundamental flaws: 15-hop cap, tens-of-seconds-to-minutes convergence, hop-count-only metric, full send every 30 s
• EIGRP = replace RIP's band-aids with a single mathematical test (the feasibility condition)
• OSPF = a different approach entirely, giving every device the whole network's topology map → a loop becomes mathematically impossible
• ★ The single most important difference is "how many routes are kept per destination": RIP keeps only 1
• The payoff of learning RIP isn't being able to configure it, but understanding why the other two protocols ended up the way they are