Model-based thinking can help engineers understand protocols and networks at a fundamental level. My previous post on network models focused on the Four Things model, an alternative to the OSI model for understanding network transport. I’ll continue with the Four Things, this time with a focus on routing.
In the Four Things model, routing falls under multiplexing, as shown in the following figure.
Source: Russ White
This second level of the Four Things model does not show solutions but rather sub-problems—routing data through a network is a problem that must be solved to provide multiplexing; adjacency, reachability, shortest paths, and reaction are four problems that must be solved to provide routing. Let’s look at these four problems in a little more detail.
Control planes must be able to form adjacencies between devices to ensure data is transmitted throughout the network. You might notice communication between routing devices will need to solve the same four problems as any other communicating pairs of hosts must solve, so the addressing part of the multiplexing problem seems to recurse onto itself. How should we solve this?
For routing systems, discovery and addressing problems are solved in one of two ways, both of which simplify the problem. One, routing protocols may assume all communicating routers will be connected to a shared broadcast domain and use multicast (or broadcast) to discover one another and arrange multiplexing, like OSPF and IS-IS. Two, the alternative is manually configuring peers and relying on some lower-level routing function to carry data between routers, like BGP.
Beyond this simplification, however, routing protocols need to marshal data, handle errors, and ensure the rate of data transmitted over a connection is correctly controlled.
Reachability is discovering reachable destinations—what networks and hosts are connected to the local router, and how does the router send traffic to these destinations? These reachable destinations must also be transmitted through the discovered adjacencies to other routers.
There are two solutions to the reachability problem in routing protocols—a protocol can advertise the destinations it can reach or the destinations it is attached to. These two options relate to how the protocol solves the next problem.
Calculating a shortest path is the third problem routing protocols need to solve. There are four solutions to this problem:
- Distance vector, where each route calculates a loop-free path (presumed to be the shortest path) using an algorithm like Belman-Ford and advertises the destinations it can reach along with their metrics.
- Path-state, where each router calculates a loop-free path by examining the path that the reachability information has traveled and advertises the destinations it can reach after adding the local router to the path.
- Link-state, where each router calculates a loop-free route (presumed to be the shortest path) using an algorithm like Dijkstra and advertises the destinations and neighbors it is connected to.
- Reactive, where each router discovers reachable destinations based on traffic flowing through the network. Reactive methods are almost always combined with some kind of distance-vector solution, as in the case of Spanning Tree.
Finally, every control plane must have some plan to react when a link or node fails. This could be as simple as just not advertising things until they time out, some form of active diffusing mode, or withdrawing information about the reachable destination.
From Models To The Real World
How can we move from this model to real routing protocols? I know when I run off into theory, many people have a hard time connecting this back to the real world. Here’s three short examples.
1. Assume you need to learn a new routing protocol
Most people start from the bottom up, with adjacency formation, and then create a tight mental coupling between the problems the protocol needs to solve. Starting from the adjacency is the long way around learning a protocol, though—instead, ask how it solves these four independent problems. I always ask, “How does this protocol compute loop-free paths,” and work down to adjacencies rather than working up from adjacencies.
Over time, you will notice many patterns in the available solutions and be able to guess how things might be solved—making learning new protocols a lot faster. Over time, you can learn new protocols intuitively, without much study, because you can guess how problems have been solved.
2. Assume you need to troubleshoot a problem with a routed control plane
Asking four simpler questions rather than one complex question can help you find problems faster. Looking at this router, is the reachability information in the local table? If so, the problem is most likely something to do with recursive reachability or the loop-free path calculation. Is the reachability information missing? Then, the problem is probably with an adjacency or discovering the destination in the first place.
These might seem like obvious questions to the experienced engineer—but they are only obvious because you mentally separate these four problems, even if you are doing so subconsciously.
3. Assume you need to know how a network will converge
Breaking the convergence problem into four separate solutions helps you quickly understand what is involved in convergence and how the protocol will work in “this” situation. If you connect these problems and solutions to a time-bound view of how the network converges, you can quickly spot when and where there will be loops, race conditions, and other problems.
Thinking in models like this is a mental habit you will need to learn over time—but as you get better at it, you will be able to understand networks and protocols much more thoroughly and quickly.
In my next post, we’ll talk about a middlebox model.