JOVANA
Explore Library Glossary Getting Started Three Levels Fields How it works Mission
Join the mission
All guides

The Real Protocols: RIP and OSPF

You have met both great families of routing algorithms in the abstract; now meet the two protocols that actually run inside real networks. RIP is distance-vector wearing work clothes, OSPF is link-state at industrial scale, and seeing the textbook ideas turn into shipping software is where everything clicks.

From algorithms to protocols

In the last three guides you built the machinery from scratch. You learned that forwarding is the fast, local act of pushing a packet out the right interface using a table, while routing is the slower, distributed job of building that table in the first place. You modeled the network as a weighted graph and asked for least-cost paths. Then you saw the two great families: link-state, where every router learns the whole map and runs Dijkstra's algorithm locally, and distance-vector, where routers only swap distance tables with neighbors and never see the full map. What you have NOT yet seen is either idea wearing real clothes. This guide fixes that.

Both RIP and OSPF belong to a category called an interior gateway protocol, or IGP. The word interior matters: these protocols run inside a single administrative domain, one organization's network, where everyone trusts everyone and shares a common goal of finding good paths. That is a very different world from the messy, distrustful routing BETWEEN organizations across the whole Internet, which needs a different protocol entirely and gets its own guide later. For now, picture one campus or one company's network: dozens of routers, all cooperating, all run by the same team.

RIP: distance-vector in work clothes

RIP, the Routing Information Protocol, is just distance-vector routing made concrete, and it is delightfully simple. Its cost metric is the crudest thing imaginable: hop count, the number of routers a packet must cross. Every link costs exactly 1, whether it is a sluggish old line or a blazing fiber. So RIP's idea of the best path is simply the fewest hops, which is honest but naive: a two-hop path over slow links can be far worse than a three-hop path over fast ones, and RIP cannot tell the difference. That simplicity was the whole point in the 1980s, and it is why RIP still turns up in small, simple networks today.

RIP works exactly the way your distance-vector guide described. Every router keeps a table of destinations and the distance to each, and roughly every 30 seconds it broadcasts that whole table to its directly connected neighbors. A neighbor that hears 'I can reach network X at distance 4' considers using that router as its next hop to X at distance 5. Tables ripple outward, distances settle, and after a while everyone agrees on the shortest hop count to everywhere. No router ever sees the full map; each just trusts what its neighbors keep telling it, like office gossip that eventually reaches a stable version of the truth.

Two RIP details are pure consequences of the dangers you already studied. First, RIP defines infinity as 16. A path of 16 hops is treated as unreachable. That tiny ceiling is a deliberate cure for count-to-infinity: by capping how high a distance can climb, RIP guarantees that a bad route falls apart quickly instead of counting upward forever. The price is brutal honesty about scale: RIP simply cannot describe a network wider than 15 hops, which is one big reason it stays in small deployments. Second, RIP leans on the cures you met, especially split horizon (never advertise a route back to the neighbor you learned it from) and poison reverse, to keep loops from forming in the first place.

OSPF: link-state at industrial scale

OSPF, Open Shortest Path First, is link-state routing grown up and put to serious work, and it is what large real networks actually run. The 'Open' means it is a public, vendor-neutral standard; the 'Shortest Path First' is just the name for Dijkstra's algorithm. The core promise is exactly what you learned: every router ends up with an identical map of the whole domain, then each independently runs Dijkstra's algorithm over that map to compute its own shortest-path tree to every destination. Because everyone computes from the same map, their results are consistent, and consistent results mean no loops.

How does everyone get the same map? Each router floods small advertisements describing its own links, called Link-State Advertisements (LSAs), to every other router in the domain. 'Flooding' is the deliberate, controlled spread you met before: when a router receives an LSA it has not seen, it copies it out every other interface, so the news reaches the whole domain fast and reliably. Each router collects all the LSAs into a link-state database, which is the shared map. Crucially, LSAs are sent only when something changes, plus a slow periodic refresh, not the constant chatter of RIP. So OSPF reacts to a failed link in well under a second, where RIP might dawdle for tens of seconds waiting for its next broadcast.

OSPF also fixes RIP's crudest weakness: its link costs are configurable, not just 1. By convention cost is set inversely to bandwidth, so a 1 Gbps link is cheaper than a 100 Mbps link, and Dijkstra naturally prefers the fatter pipe even if it takes an extra hop. This is the difference between counting doors and actually measuring corridors. The result is a protocol that scales to large networks, converges fast, and routes by real link quality rather than a blunt hop count. The cost is complexity: OSPF has more moving parts, more packet types, and more configuration than RIP, which is exactly the trade you make to move from a toy to a workhorse.

Two protocols, side by side

It helps to lay the two protocols against each other on the points that matter. Notice that almost every difference traces straight back to the algorithm family underneath: RIP inherits distance-vector's simplicity and its loop dangers, while OSPF inherits link-state's richer map and its faster, loop-free convergence. The protocol does not invent new behavior so much as commit the algorithm to a real schedule, a real message format, and a real failure policy.

                        RIP                       OSPF
  ----------------------------------------------------------------------
  algorithm family      distance-vector           link-state
  cost metric           hop count (every link=1)  configurable (~1/bandwidth)
  what's exchanged      whole distance table      link-state ads (LSAs)
  to whom               only direct neighbors     flooded to all routers
  how often             every ~30 s (periodic)    on change + slow refresh
  sees full map?        no                         yes (link-state database)
  path computation      Bellman-Ford idea         Dijkstra (shortest path)
  'infinity'            16 hops (caps loops)       n/a (loop-free by design)
  max network size      ~15 hops (small)           large
  convergence speed     slow (tens of seconds)     fast (sub-second)
The same comparison you would draw between distance-vector and link-state in the abstract, now grounded in two shipping protocols. Read it as: RIP trades capability for simplicity; OSPF trades simplicity for capability.

What a failure really looks like

The clearest way to feel the difference is to break a link and watch each protocol cope. Imagine a router that was the only path to some network suddenly loses that link. The whole point of a routing protocol is to detect the break, spread the bad news, recompute, and settle on a new working path. The time that takes is called convergence time, and during it packets may be dropped or even briefly loop. Here is how OSPF handles it.

  1. Detect: the router notices the link is down, often within milliseconds, because OSPF neighbors exchange tiny 'Hello' packets and a missed run of them means the neighbor or link has died.
  2. Announce: it generates a fresh LSA saying 'this link of mine is gone' and floods it out every interface, so the news races across the whole domain.
  3. Update the map: every router receives the LSA and edits its link-state database, deleting that edge from the shared graph. Everyone now holds the same, corrected map.
  4. Recompute: each router independently re-runs Dijkstra over the new map and finds the new shortest path. Because all maps match, all new paths are consistent, so no loops form.
  5. Converged: forwarding tables are rewritten and packets flow along the new path, typically in well under a second from the moment the link failed.

Run the same failure through RIP and the contrast is stark. There is no instant flood of bad news, just routers slowly broadcasting their tables every 30 seconds, so the change crawls outward one neighbor at a time. Worse, this is exactly the situation that risks count-to-infinity: a neighbor that still believes in the dead path can feed a stale, slightly-longer route back, and the distance creeps upward until it finally hits RIP's ceiling of 16 and the route is declared dead. The cures, split horizon and poison reverse, limit this but cannot abolish it. This is not RIP being badly written; it is the unavoidable cost of routers that never see the full map and must reason only from neighbor gossip.

Where this leaves you

You now hold the abstract algorithms AND their real-world embodiments in the same hand, which is exactly the point of this rung. The two great families are no longer just chalkboard ideas: distance-vector is RIP, gossiping its tables and capping distances at 16; link-state is OSPF, flooding LSAs, building a shared map, and running Dijkstra fast and loop-free. Every choice each protocol makes is traceable to the algorithm beneath it and to the dangers, especially count-to-infinity, you studied in the previous guide.

There is one honest limit to flag before the last guide. Both RIP and OSPF are interior gateway protocols: they assume one cooperative domain where everybody shares a map or trusts the gossip. That assumption simply does not hold across the whole Internet, where independent companies that may compete, distrust, and keep secrets must still exchange traffic. Routing between domains is a different game with different rules, and it gets its own protocol. The final guide of this rung steps up to that larger scale, asking how routing stays manageable when the network is not one campus but the entire planet.