Basic Layer 3 Routing Concepts
Date: Oct 6, 2015
Overview
One of the most fundamental skills that a network engineer must master is packet forwarding/routing. The process might seem simple, but there are a number of different systems, and network engineers need to understand the lower levels of network routing that support all of these systems. Becoming a well-rounded network engineer requires a thorough understanding of these concepts. This article and the next few in this series will focus on these basics.
Packet Forwarding Basics
At its most basic level, networking is very simple: Take a message that needs to get from point A to point B, and perform the necessary steps to make it happen. This is true whether you're performing network switching with devices using a Media Access Control (MAC) address, or network routing using either an IPv4 or IPv6 address; the principle difference is geography.
Routers are typically used at the intersections between point A and point B, and the router must give adequate directions to make the message exchange possible. It's important to note that these don't need to be good directions—just correct enough to get the message to its destination. Often the path that a message takes to a destination is based on the individual routing plans of Internet Service providers (ISPs), which aren't always the most efficient overall for the sender.
Once configured, a router will contain a table with entries for all of the networks that it knows how to reach. This routing table is much like a highway traffic sign, in that it gives directions to a destination from the perspective of that point in the journey. It doesn't provide a complete map of how to get to a destination, only a simple table indicating that a specific destination can be reached by going out x interface and/or via a specific next-hop router. In some circumstances, a router will also be configured with a default rule that it uses when a specific path to a destination is unknown. This would be the equivalent of travelers making the decision to go to the nearest location where they might be able to find a path to the destination (ask for directions).
Packet Forwarding Influencers
Figure 1 shows three major American cities, with multiple ways to get from one to the other. If you wanted to drive from New York to San Francisco, there are a number of roads you could take to make the journey, all with their own qualities. Some routes might go close to Chicago, and others wouldn't. The best path for the trip would depend on a number of factors (traffic, road quality, construction work, speed limit, and so on), and whether a driving assistant (GPS, traffic monitor) would provide additional information.
Figure 1 Source and/or destination cities.
As Figure 2 shows, the same principle applies to network routing. Often there are multiple paths to a specific destination; the network engineer's job is to configure the devices with the best path to each of the known destinations.
Figure 2 Routing distribution points.
As in the previous example, the determination of which path is "best" depends on a number of factors, such as network link speed, congestion, link provider routing policies, link failures, and so on.
Many of these factors are not known and/or are not checked at each point along the path. For example, when leaving New York, a driver might know that the shortest path to Chicago is via a specific interstate, but probably wouldn't know that halfway between New York and Chicago is a massive traffic accident that will delay the journey by hours. The same is true when routing a message from New York to Chicago. Maybe a link between two intermediate nodes is having intermittent problems that the message won't experience until it's transferred along that link; possibly some device along the path has failed since its status was last checked. The point is that each routing device along a path is restricted by the amount of information provided to it and the type of routing mechanism in use.
Populating the Routing Table
Let's look at an example of how a routing table is populated. For this example we'll use the locations and links shown in Figure 3.
Figure 3 Example of a routing table topology.
In Figure 3, each location has a number next to each of the paths connecting it to a neighboring location. The next step is to develop a reachability table for each of these locations, as shown in tables 1–4.
Table 1
New York Reachability Table (Raw)
|
Destination |
Link |
|
Chicago |
1 |
|
Chicago |
2 |
|
Dallas |
1 |
|
Dallas |
2 |
|
San Francisco |
1 |
|
San Francisco |
2 |
Table 2
Chicago Reachability Table (Raw)
|
Destination |
Link |
|
New York |
1 |
|
New York |
2 |
|
New York |
3 |
|
Dallas |
1 |
|
Dallas |
2 |
|
Dallas |
3 |
|
San Francisco |
1 |
|
San Francisco |
2 |
|
San Francisco |
3 |
Table 3
Dallas Reachability Table (Raw)
|
Destination |
Link |
|
New York |
1 |
|
New York |
2 |
|
New York |
3 |
|
Chicago |
1 |
|
Chicago |
2 |
|
Chicago |
3 |
|
San Francisco |
1 |
|
San Francisco |
2 |
|
San Francisco |
3 |
Table 4
San Francisco Reachability Table (Raw)
|
Destination |
Link |
|
New York |
1 |
|
New York |
2 |
|
Dallas |
1 |
|
Dallas |
2 |
|
Chicago |
1 |
|
Chicago |
2 |
Each of the reachability tables indicates the destinations that a device can reach and all of the possible paths that a message can take. Since all of the devices and links are operational, all of the paths can be used to reach all other destinations. A routing table is a little different; it provides a device with a list of the best available paths to each specific destination. As the reachability tables show, there are a number of paths that will go through multiple devices to reach the eventual destination. This is similar to most well-connected highway systems. There are multiple ways to get between destinations; many would be out of the way and initially might go in the opposite direction, but eventually each would reach the destination.
What gets placed into the routing table is typically intended to be the best paths to a specific destination. With this in mind, tables 5–8 show the routing tables for the locations shown in Figure 3. (The metric used for this example is hop count.)
Table 5
New York Routing Table
|
Destination |
Link |
|
Chicago |
1 |
|
Dallas |
2 |
|
San Francisco |
1 |
|
San Francisco |
2 |
Table 6
Chicago Routing Table
|
Destination |
Link |
|
New York |
1 |
|
Dallas |
2 |
|
San Francisco |
3 |
Table 7
Dallas Routing Table
|
Destination |
Link |
|
New York |
1 |
|
Chicago |
2 |
|
San Francisco |
3 |
Table 8
San Francisco Routing Table
|
Destination |
Link |
|
New York |
1 |
|
New York |
2 |
|
Dallas |
1 |
|
Chicago |
2 |
As you can see, each device's routing table is much smaller than its reachability table, and in some cases more than one best path has the same cost. The lookup process for each destination is simple; when a device needs to send a message to a specific destination, it performs a lookup on its routing table. If the destination that it's attempting to reach has an entry, the device will send the message along the path indicated.
Summary
This article just scratches the surface of how packet routing works. The next few articles will step deeper into the routing methods and protocols that are used on real networks. It's important to note that, regardless of the method used, they all have the same basic mission: routing a message from point A to point B.