This article provides a very brief introduction to routing for Linux computers, designed for understanding simple environments.
Every computer attached to a network requires some type of routing instructions for network TCP/IP packets when they leave the local host. This is usually very straightforward because most network environments are very simple and there are only two options for departing packets. All packets are sent either to a device on the local network or to some other, remote network.
Let's be sure to define the "local" network as the logical and usually also the physical network in which the local host resides. Logically that means the local subnet in which the host is assigned one of the range of the local subnet's IP addresses. Physically that means the host is connected to one or more switches that are also connected to the rest of the local network.
TCP/IP Network Model
Before we get into routing, it helps to understand a little bit about how packets find their way to the correct host on a network. The TCP/IP network model defines a five layer stack that describes the mechanisms necessary to move data packets from one host to another, whether that host is on the local network or halfway around the world. Each of the layers in the following description of this model is numbered and also contain the names of the data units that are handled by that layer.
5. Application layer: Message. This layer consists of the connection protocols required for various network applications to communicate, such as HTTP, DHCP, SSH, FTP, SMTP, IMAP, and others. When you request a web page from a remote web site, a connection request is sent to the web server and the response is sent back to your host at this layer and then your browser displays the web page in its window.
4. Transport layer: TCP segment. The transport layer provides end-to-end data transport and flow management services that are independent of the data and types of protocols being transported. It uses ports such as 80 for HTTP and 25 for SMTP to make connections between the sending host and the remote host.
3. Internet layer: Packet. Packet routing is performed on the Internet layer. This layer is responsible for routing packets across two or more different networks in order to reach their final destination. This layer uses IP Addresses and the routing table to determine which device to send the packets to next. If sent to a router, each router is responsible for sending the data packets only to the next router in the series and not for mapping out the entire route from the local host to the target host. The Internet layer is mostly about routers talking to routers in order to determine the next router in the chain.
2. Data Link layer: Frame. The Link layer manages the direct connections between hardware hosts on a single, local, logical, physical network. This layer uses the Media Access Control (MAC) addresses embedded in the Network Interface Cards (NICs) to identify the physical devices attached to the local network. This layer cannot access hosts that are not on the local network.
1. Physical layer: Bits. This is the hardware layer and consists of the NICs and the physical Ethernet cable as well as the hardware level protocols used to transmit individual bits that make up the data frames between any two hosts or other network nodes that are locally connected.
A Simple Example
So what does that look like when a host is actually sending data on the network using the TCP/IP network model? Here is my own made-up description of how data are moved from one network to another. In this example, my computer is sending a request to a remote server for a web page.
1. On the application layer, the browser initiates an HTTP connection request message to the remote host, www.example.com, to send back the data comprising the contents of a web page. This is the message, and it includes only the IP Address of the remote web server.
2. The transport layer encapsulates the message containing the web page request in a TCP datagram with the IP address of the remote web server as the destination. Along with the original request packet, this packet now includes the source port from which the request will originate, usually a very high number random port, so that the return data knows which port the browser is listening on; and the destination port on the remote host, port 80 in this case.
3. The Internet layer encapsulates the TCP datagram in a packet that also contains both the source and destination IP addresses.
4. The data Link layer uses the Address Resolution Protocol (ARP) to identify the physical MAC address of the default router and encapsulates the Internet packet in a frame that includes both the source and destination MAC addresses.
5. The frame is sent over the wire, usually CAT5 or CAT6, from the NIC on the local host to the NIC on the default router.
6. The default router opens the datagram and determines the destination IP address. The router uses its own routing table to identify the IP address of the next router that will take the frame onto the next step of its journey. The router then re-encapsulates the frame in a new datagram that contains its own MAC as the source and the MAC address of the next router and then sends it on through the appropriate interface. The router performs its routing task at layer 3, the Internet layer.
Note that switches are invisible to all protocols at layers two and above, so they do not affect the transmission of data in any logical manner. The function of switches is merely to provide a simple means to connect multiple hosts into a single physical network via lengths of Ethernet cable.
You can use the arp [-n] command to view all of the MAC addresses that your host has stored in its arp table. These are always hosts on the local network.
The routing table
All network devices, whether they are hosts, routers, or other types of network nodes such as network attached printers, need to make decisions about where to route TCP/IP data packets. The routing table provides the configuration information required to make those decisions.A routing table similar to the very simple one in Figure 1 is used to define the single route available to a typical local host and to determine whether to send packets to the default gateway router. The route -n command lists the routing table; the -n option displays the results as IP addresses only and does not attempt to perform a DNS lookup which would replace the IP address with hostnames if they are available. The netstat -rn command produces very similar results.
Figure 1: A simple routing table.
The default gateway is always shown with the destination 0.0.0.0 when the -n option is used. If -n is not used, the word "Default" appears in the Destination column of the output. The IP address in the Gateway column is that of the outbound gateway router. The netmask of 0.0.0.0 for the default gateway means that any packet not addressed to the local network or another outbound router by additional entries in the routing table are to be sent to the default gateway regardless of the network class.
The Iface (Interface) column in Figure 1 is the name of the outbound NIC, in this case, eno1. For hosts that are acting as routers, there will likely be at least two and sometimes more NICs used. Each NIC used as a route will be connected to a different physical and logical network. The flags in the Flag column indicate that the route is Up (U) and which is the default Gateway (G). Other flags may also be present.
Routing decisions are fairly simple for most hosts:
• If the destination host is on the local network, send the data directly
to the destination host.
• If the destination host is on a remote network that is reachable via a local gateway listed in the routing table, send it to the explicitly defined gateway.
• If the destination host is on a remote network, and there is no other entry that defines a route to that host, send the data to the default gateway.
These rules simply mean that if all else fails because there is no match, send the packet to the default gateway.
The routing table in Figure 2 below is a bit more complex because it belongs to a Linux host acting as a router that connects to three networks, one of which leads to the Internet. The local class C networks, 192.168.0.0/24 on interface eth1, 192.168.25.0/24 on eth2, each have entries in the table, as well as the default route that leads to the rest of the world on eth0.
Figure 2: A more complex routing table with multiple networks.
Note that there is still only one default gateway, and that is on interface eth0. However, in addition to the default route entry that points directly to the LAN side IP address of the router, there is also an entry for the 192.168.1.24/30 network as a whole. That network only contains two usable IP addresses, one, 192.168.1.25/30, for the router LAN side and one, 192.168.1.26/30 for the host itself.
So how does the routing table get configured? For hosts connected to the network using DHCP, the DHCP server provides that configuration information for the default route along with DNS, the hosts IP address, and possibly other information such as the IP address for an NTP server. For static configurations, it is usually simple, but it can be a bit more complicated sometimes.
In most cases, adding the default route to the /etc/sysconfig/network file causes the network to configure the default route in the routing table. That entry looks like the sample in Figure 3.
Figure 3: Gateway entry in the network file.
Only the default gateway can be configured using the network file.
The other method for configuring a default gateway in a statically configured environment is to add it to the appropriate interface configuration file in /etc/sysconfig/network-scripts directory. To add a gateway to the interface configuration file for interface eth0, you would add the same line as in Figure 3, above, to the ifcfg-eth0 file. If you do that, you should remove that entry from the network file.
In a more complex environment, such as when the host computer is connected to multiple networks using multiple NICs, and when there are at least two and perhaps more routes that need to be entered into the routing table, you should consider using a route file in /etc/sysconfig/network-scripts. For NIC enp7s1, that file would be route-enp7s1 and it would contain the entry shown in Figure 4.
default via 192.168.0.1 dev enp7s1
Figure 4: The default route entry for enp7s1.
Default gateway settings in the route-interface files override any that might be listed in the network file.
Of course, you can always add routes from the command line using the route command. That can take some time if you need to do it every time the system boots, so you might want to consider using the methods above, or creating a script that runs at boot time. I have a script for one of my systems that contains the following two lines as shown in Figure 5.
route del default route add default gw 192.168.0.1
Figure 5: Commands to set a default route from the command line.
Note that the device name is optional in all of these commands, and is not used in Figure 5.
There can be a lot more to routing than shown in these fairly simple examples which are quite common. The information here should get you started. For more complex environments, you might wish to refer to Inside TCP/IP, Second Edition or TCP/IP Network Administration (3rd Edition; O'Reilly Networking) by Hunt, Craig Published by O'Reilly Media 3rd (third) edition (2002) Paperback. You might also want to refer to your distribution's documentation for more information; for rpm-based distributions like Fedora and CentOS, a good reference is the Fedora Core 7 & Red Hat Enterprise Linux: The Complete Reference.
About the author
David Both - David Both is an Open Source Software and GNU/Linux advocate, trainer, writer, and speaker who lives in Raleigh North Carolina. He is a strong proponent of and evangelist for the "Linux Philosophy." David has been in the IT industry for nearly 50 years. He has taught RHCE classes for Red Hat and has worked at MCI Worldcom, Cisco, and the State of North Carolina. He has been working with Linux and Open Source Software for over 20 years.
Opensource.com aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. Red Hat and the Red Hat logo are trademarks of Red Hat, Inc., registered in the United States and other countries.
Learn more at amazon.com