The Example Network
It’s easier to follow a theoretical discussion if there is a real world example thrown into the mix. For this purpose, I have added a sample network that you can refer back to throughout Linux Routing.
The Internet is one huge IP network. As you probably already know, every machine on such a network has its own IP address in the format, xxx.xxx.xxx.xxx, except in cases where private addressing schemes are used, such as 192.168.xxx.xxx and 10.xxx.xxx.xxx. However, the entire Internet is a bit large to use in the discussion here. Instead, I’ll define a smaller network set to work with while learning how specific routing protocols work. I will then use this same example network in the chapters where things are actually set up. The starting point will be the Linux machine,“Red,” which has the private range IP address, 192.168.15.10.
A lone machine, of course, is not in and of itself a useful or interesting network. Perhaps this Linux box is on the mixed-operating system LAN presented in Figure 1.1, having the private class C address space 192.168.15.0 all to itself. Which operating systems these machines are running doesn’t matter at this point. Many people don’t realize that any operating system that natively speaks TCP/IP (most modern operating systems) can share a TCP/IP Ethernet connection with any other operating system without a problem. It’s sharing data and files that causes the headache.
Figure 1.1. The Linux box, Red, within the network 192.168.15.0.
When an application tries to send or retrieve data within the network, for example when sending data from our starting point at Red to Teal (both Linux machines), a routing protocol is unnecessary. Machines within the same subnetwork or unsubnetted network use other techniques to find each other. It’s when you pass outside of that subnet or unsubnetted network that routing becomes an issue.
Now, to connect this network to a larger set of networks you add a new network card with the address 192.168.15.1 to the machine, Orange, as shown in Figure 1.2. These two separate network interfaces are absolutely necessary when you start spanning from one subnet or unsubnetted network to another, whether the interfaces are physical or virtual. In this case, one (192.168.15.1) connects to the Internet. The other (192.168.15.2) connects to the internal network.
Figure 1.2. The network 192.168.15.0 connected to the other networks in the office.
These simpler structures will be needed later for setup discussions, but this book is about routing with Linux, therefore a larger example is required—something that actually requires routers. Next, this LAN will be connected to the machine, Emerald, in another part of the building as shown in Figure 1.3.
Figure 1.3. The main LAN connecting to Emerald elsewhere.
Now we’re starting to get somewhere! Emerald is on an entirely different network than Red—192.168.90.x instead of 192.168.15.x. Routers become necessary as you start crossing network boundaries.The data has to know how to get to each network and subnetwork.
An overall network at any location may consist of a single LAN with an internal class C, such as our 192.168.90, or it may be a collection of smaller networks and subnetworks. If the network is connected to the Internet, as most seem to be these days, it connects somewhere along the way to an Internet Service Provider (ISP). An ISP may have tens, dozens, hundreds, or even thousands of networks and machines directly attached to it. Many of these networks also might have their own subnetworks and lead to yet more networks, perhaps even through a backup link to another ISP with its own collection of thousands of networks.
Imagine that you have a packet that needs to get from “here” to “there.” How fast or slow this data travels does not matter. How geographically far it needs to go does not matter. The only thing that matters is network boundaries. At the moment that a packet must cross from one subnetwork or unsubnetted network to another, it needs help knowing where to go.
Let’s take a look at how this works. One day you send data from Red to a machine named Abacus out on another of your networks. A name lookup tells TCP/IP that the packets need to go from 192.168.15.10 (Red) to 192.169.13.9 (Abacus). Your packet reaches 192.168.90.26 (Emerald), and the only information this packet has associated with it is that it needs to go to 192.168.13.9. The packet itself has no idea whether the network 192.168.13 is in your collection of networks, attached to someone else on the same ISP, on another ISP, where it is physically in the world, or where it is in the overall structure of all of the networks in the world. That is not a packet’s job in TCP/IP. Other machines, protocols, and tools handle how to make the trip.
Fortunately, Emerald is one of these special tools—a router. The routing protocol(s) it uses are not important at the moment and will change throughout the discussion of routing protocols in this chapter and the next. Regardless of the protocol used, each one decides how to give this packet a customized roadmap. Figure 1.4 rounds out the structure needed for the examples, adding a few routers in the middle along with the end destination. This example is set on a fictitious campus with Emerald as a department router within the Chem building and Abacus as a departmental router in the Math building.
Figure 1.4. The path from Emerald to Abacus, with the main building routers in between.
The physical connections between each of these routers, as outlined in Table 1.1, are going to become important as we discuss how the protocols work.