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

Routing vs Forwarding, and the Network as a Graph

Forwarding is the split-second local reflex of moving one packet out the right door; routing is the slow, network-wide planning that fills in the directions. This guide separates the two cleanly, then turns the whole network into a weighted graph so we can talk about least-cost paths and the two great families of routing algorithms.

Two jobs that are easy to confuse

When you arrived at the network layer you met a phrase that sounded almost like one idea split by a slash: forwarding vs routing. It is worth slowing down on it now, because the whole of this rung lives on the routing side of that slash. Picture a busy mail sorting office. Forwarding is the clerk who glances at the address on a parcel, reads the chart pinned to the wall, and drops it into the correct outgoing chute, all in under a second. Routing is the planning team that, over hours and days, decides what that wall chart should say in the first place.

In a router these two jobs run at wildly different speeds and in different places. Forwarding is the data plane: for every single packet that arrives, the router pulls the destination IP out of the header, looks it up, and shoves the packet out one of its interfaces. This must happen millions of times a second, so it is built into fast hardware and uses a precomputed table. Routing is the control plane: a slower background process, running in software, that talks to other routers, learns the shape of the network, and (re)builds that table. The table is the bridge between them.

Drawing the network as a weighted graph

To plan good paths, routing first needs a model of the network it can reason about. The model is wonderfully simple: a graph. Draw every router as a dot (a node) and every direct link between two routers as a line connecting their dots (an edge). A packet travelling across the network is just a token hopping from dot to dot along the lines. This is the network graph model, and once you see it, routing stops being mysterious and becomes a clean question about dots and lines.

But not all links are equal, so each edge carries a number called its cost (or weight). A cost might stand for the link's delay, the inverse of its bandwidth (so a 1 Gbps link is cheaper than a 100 Mbps one), a money price, or simply 1-per-hop if you only care about how many routers a packet touches. The operator chooses what cost means; the algorithm just treats it as a number to add up along a path. Crucially, low cost is good, like a low price, and routing's job becomes: find the cheapest route from here to everywhere.

A small network as a weighted graph (numbers = link cost)

        2          5
   (A)------(B)----------(C)
    |        |            |
  1 |      3 |          1 |
    |        |            |
   (D)------(E)----------(F)
        1          2

  Cost of A -> B -> C        = 2 + 5     = 7
  Cost of A -> D -> E -> F -> C = 1+1+2+1 = 5   (cheaper!)
Routers are nodes, links are edges, each edge has a cost. Adding costs along a path gives the path's total cost; the least-cost path here is not the one with the fewest hops.

What we are really computing: least-cost paths

With the graph in hand, the goal of any routing algorithm is now precise: for each destination, find the least-cost path, the route from this router to that destination whose costs sum to the smallest total. Notice this is not the same as the fewest hops. In the picture above, A reaches C in two hops for a cost of 7, but in four hops for a cost of only 5. If cost means delay, the longer-looking detour is genuinely faster. The least-cost path is what the algorithm hunts for, and the first hop along it is exactly what gets written into the forwarding table.

One subtle but lovely fact makes all of this tractable, and the algorithms in the next two guides lean on it heavily. If the cheapest route from A to C happens to pass through E, then the piece of that route from E onward must itself be the cheapest route from E to C. (If there were a cheaper way from E to C, A would have used it too.) In plain words: a best path is built out of best sub-paths. This is why a router can learn good full routes just by combining good routes its neighbours already found, instead of recomputing the whole world from scratch.

Two ways to solve it, two whole families

There are two fundamentally different ways for the routers to work out these least-cost paths, and each one anchors a whole family of real protocols. They differ in one decisive question: how much does each router get to know about the network? Either every router learns the entire map and computes paths alone, or no router ever sees the full map and they instead gossip distances to their neighbours until the answers settle. That single choice ripples through everything: speed, message size, what goes wrong, and how badly.

The first family is link-state routing. Every router shouts a description of just its own directly attached links and their costs to all other routers, so that eventually every router holds an identical copy of the complete map. Holding the whole graph, a router then runs a shortest-path algorithm by itself, the famous Dijkstra's algorithm, to compute least-cost paths to everywhere. It is the 'everyone gets the full map, then thinks alone' approach. Link-state routing is the engine inside OSPF, the workhorse protocol of large enterprise and provider networks, and guide 2 of this rung is devoted to it.

The second family is distance-vector routing. No router ever sees the whole map. Instead each router keeps a little table of its best-known cost to every destination (a vector of distances) and periodically tells only its direct neighbours, 'here is how far I think each place is from me.' Each router then updates its own estimates from what its neighbours report, using the Bellman-Ford idea: my cost to a destination is the cheapest of (cost to a neighbour + that neighbour's reported cost onward). Distance-vector routing is the engine inside RIP, it is simpler to run but prone to the count-to-infinity bug, and guide 3 unpacks it.

Where this rung is taking you

Everything here lives inside a single administrative domain, one organisation's network, run by one operator who controls all the costs. A protocol that routes within such a domain is called an interior gateway protocol, and RIP and OSPF are the two famous ones. Routing between different organisations, across the open Internet, is a different game with politics and money baked in; that is the next rung's BGP, and we are deliberately not there yet. For now, keep the boundary firmly in mind: one domain, one set of costs, cooperating routers.

  1. Guide 2 builds the link-state world: how routers flood their local link info to everyone, then run Dijkstra's algorithm on the assembled map to compute shortest paths.
  2. Guide 3 builds the distance-vector world via the Bellman-Ford idea, then meets the count-to-infinity problem (bad news travels slowly) and its partial cures like split horizon.
  3. Guide 4 grounds both ideas in the real interior protocols: RIP as the simple distance-vector veteran and OSPF as the scalable link-state standard.
  4. Guide 5 asks how this scales: hierarchical routing into areas, plus the default route and route aggregation that keep forwarding tables small.

Hold on to the two anchors from this guide and the rest of the rung will feel like variations on a theme. First, forwarding is the per-packet local reflex reading a table, and routing is the slower, network-wide work of computing that table. Second, the network is a weighted graph, and routing is the search for least-cost paths through it, solved either by everyone-knows-the-map (link-state) or everyone-gossips-distances (distance-vector). Those two sentences are the spine of everything that follows.