 | Chapter 7 Configuring Routing |  |
| Chapter 7 Configuring Routing | |
As we have seen, the minimal routing table works to reach hosts only on the directly connected physical networks. To reach remote hosts, routes through external gateways must be added to the routing table. One way to do this is by constructing a static routing table with route commands.
Use the UNIX route command to add or delete entries manually in the routing table. For example, to add the route 207.25.98.0 to a Solaris system's routing table, enter:
#route add 207.25.98.0 172.16.12.1 1add net 207.25.98.0: gateway almond
The first argument after the route command in this sample is the keyword add. The first keyword on a route command line is either add or delete, telling route either to add a new route or delete an existing one. There is no default; if neither keyword is used, route displays the routing table.
The next value is the destination address, which is the address reached via this route. The destination address can be specified as an IP address, a network name from the /etc/networks file, a host name from the /etc/hosts file, or the keyword default. Because most routes are added early in the startup process, numeric IP addresses are used more than names. This is done so that the routing configuration is not dependent on the state of the name server software. Always use the complete numeric address (all four bytes). route expands the address if it contains less than four bytes, and the expanded address may not be what you intended. [4]
[4] Some implementations of route expand "26" to 0.0.0.26, even though "26" could mean Milnet (26.0.0.0).
If the keyword default is used for the destination address, route creates a default route. [5] The default route is used whenever there is no specific route to a destination, and it is often the only route you need. If your network has only one gateway, use a default route to direct all traffic bound for remote networks through that gateway.
[5] The network address associated with the default route is 0.0.0.0.
Next on the route command line is the gateway address. [6] This is the IP address of the external gateway through which data is sent to the destination address. The address must be the address of a gateway on a directly connected network. TCP/IP routes specify the next-hop in the path to a remote destination. That next-hop must be directly accessible to the local host; therefore, it must be on a directly connected network.
[6] The syntax varies slightly between systems. Linux precedes the gateway address with the keyword
gw. Check your system's documentation for the details.
The last argument on the command line is the routing metric. The metric argument is not used when routes are deleted, but many systems require it when a route is added. Despite being required, route only uses the metric to decide if this is a route through a directly attached interface or a route through an external gateway. If the metric is 0, the route is installed as a route through a local interface, and the G flag, which we saw in the netstat -i display, is not set. If the metric value is greater than 0, the route is installed with the G flag set, and the gateway address is assumed to be the address of an external gateway. Static routing makes no other use of the metric. Dynamic routing is required to make real use of varying metric values.
As an example, let's configure static routing on the imaginary workstation peanut. Figure 7.1 shows the subnet 172.16.12.0. There are two gateways on this subnet, almond and pecan. almond is the gateway to thousands of networks on the Internet; pecan provides access to the other subnets on nuts-net. We'll use almond as our default gateway because it is used by thousands of routes. The smaller number of routes through pecan can easily be entered individually. The number of routes through a gateway, not the amount of traffic it handles, decides which gateway to select as the default. Even if most of peanut's network traffic goes through pecan to other hosts on nuts-net, the default gateway should be almond.
To install the default route on peanut, we enter:
#route -n add default 172.16.12.1 1add net default: gateway 172.16.12.1
The destination is default, and the gateway address (172.16.12.1) is almond's address. Now almond is peanut's default gateway. The -n option is not required. It just tells route to display numeric addresses in its informational messages. When you add route commands to a startup file, use the -n option to prevent route from wasting time querying name server software that may not be running.
After installing the default route, examine the routing table to make sure the route has been added:
%netstat -rnRouting tables Destination Gateway Flags Refcnt Use Interface 127.0.0.1 127.0.0.1 UH 1 132 lo0 default 172.16.12.1 UG 0 0 le0 172.16.12.0 172.16.12.2 U 26 49041 le0
Try ping again to see whether peanut can now communicate with remote hosts. If we're lucky, [7] the remote host responds and we see:
[7] It is possible that the remote host is down. If it is, ping receives no answer. Don't give up; try another host.
%ping 207.25.98.2PING 207.25.98.2: 56 data bytes 64 bytes from ruby.ora.com (207.25.98.2): icmp_seq=0. time=110. ms 64 bytes from ruby.ora.com (207.25.98.2): icmp_seq=1. time=100. ms ^C ----207.25.98.2 PING Statistics---- 2 packets transmitted, 2 packets received, 0% packet loss round-trip (ms) min/avg/max = 100/105/110
This display indicates successful communication with the remote host, which means that we now have a good route to hosts on the Internet.
However, we still haven't installed routes to the rest of nuts-net. If we ping a host on another subnet, something interesting happens:
%ping 172.16.1.2PING 172.16.1.2: 56 data bytes ICMP Host redirect from gateway almond.nuts.com (172.16.12.1) to pecan.nuts.com (172.16.12.3) for filbert.nuts.com (172.16.1.2) 64 bytes from filbert.nuts.com (172.16.1.2): icmp_seq=1. time=30. ms ^C ----172.16.1.2 PING Statistics---- 1 packets transmitted, 1 packets received, 0% packet loss round-trip (ms) min/avg/max = 30/30/30
peanut believes that all destinations are reachable through its default route. Therefore, even data destined for the other subnets is sent to almond. If peanut sends data to almond that should go through pecan, almond sends an ICMP Redirect to peanut telling it to use pecan. (See Chapter 1, Overview of TCP/IP, for a description of the ICMP Redirect Message.) ping shows the ICMP Redirect in action. netstat shows the effect the redirect has on the routing table:
%netstat -nrRouting tables Destination Gateway Flags Refcnt Use Interface 127.0.0.1 127.0.0.1 UH 1 1604 lo0 172.16.1.2 172.16.12.3 UGHD 0 514 le0 default 172.16.12.1 UG 3 373964 le0 172.16.12.0 172.16.12.1 U 31 686547 le0
The route with the D flag set was installed by the ICMP Redirect.
Some network managers take advantage of ICMP Redirects when designing a network. All hosts are configured with a default route, even those on networks with more than one gateway. The gateways exchange routing information through routing protocols and redirect hosts to the best gateway for a specific route. This type of routing, which is dependent on ICMP Redirects, became popular because of personal computers (PCs). Many PCs cannot run a routing protocol; some do not have a route command and are limited to a single default route. Clearly, ICMP Redirects are needed to support these clients. Also, this type of routing is simple to configure and well suited for implementation through a configuration server, as the same default route is used on every host. For these reasons, some network managers encourage repeated ICMP Redirects.
Other network administrators prefer to avoid ICMP Redirects and to maintain direct control over the contents of the routing table. To avoid redirects, specific routes can be installed for each subnet, using individual route statements:
#route -n add 172.16.1.0 172.16.12.3 1add net 172.16.1.0: gateway 172.16.12.3 #route -n add 172.16.6.0 172.16.12.3 1add net 172.16.6.0: gateway 172.16.12.3 #route -n add 172.16.3.0 172.16.12.3 1add net 172.16.3.0: gateway 172.16.12.3 #route -n add 172.16.9.0 172.16.12.3 1add net 172.16.9.0: gateway 172.16.12.3
netstat shows what the completed routing table looks like. peanut is directly connected only to 172.16.12.0, so all gateways in its routing table have addresses that begin with 172.16.12. The finished routing table is shown below.
%netstat -rnRouting tables Destination Gateway Flags Refcnt Use Interface 127.0.0.1 127.0.0.1 UH 1 132 lo0 172.16.12.0 172.16.12.2 U 26 49041 le0 172.16.1.3 172.16.12.3 UGHD 1 514 le0 default 172.16.12.1 UG 0 0 le0 172.16.1.0 172.16.12.3 UG 1 4904 le0 172.16.6.0 172.16.12.3 UG 0 0 le0 172.16.3.0 172.16.12.3 UG 0 0 le0 172.16.9.0 172.16.12.3 UG 0 0 le0
The routing table we have constructed uses the default route (through almond) to reach external networks, and specific routes (through pecan) to reach other subnets within nuts-net. Rerunning the ping tests produces consistently successful results. However, if any subnets are added to the network, the routes to these new subnets must be manually added to the routing table. Additionally, if the system is rebooted, all static routing table entries are lost. Therefore, to use static routing, you must ensure that the routes are re-installed each time your system boots.
If you decide to use static routing, you need to make two modifications to your startup files:
Add the desired route statements to a startup file.
Remove any statements from the startup file that run a routing protocol.
Linux provides an interesting example, because it requires static routes to build the minimal routing table. The Linux implementation of ifconfig doesn't modify the routing table when a new interface is configured. The route for a new interface is explicitly added with a route command. These "interface routes" are stored in a startup script. On our sample Slackware Linux system, the routes are found in /etc/rc.d/rc.inet1: [8]
[8] The actual route statements in rc.inet1 use script variables. We changed these to addresses for the sake of clarity.
/sbin/route add -net 127.0.0.0 /sbin/route add -net 172.16.5.0 netmask 255.255.255.0
The first statement installs the route for the loopback interface. Note the abbreviated syntax of this command: it specifies a destination but no gateway. This is because Linux has a special syntax just for assigning a route to an interface. We could have written the command as:
/sbin/route add -net 127.0.0.0 dev lo0
If dev is not specified on the command line, the route command determines the correct interface from the destination address.
The second statement from the /etc/rc.d/rc.inet1 script installs the route for the Ethernet interface. This statement includes a subnet mask. If none was provided, it would default to 255.255.0.0, which is the standard for the class B address 172.16.0.0.
Installing routes for directly connected interfaces is specific to Linux. As another more general example, let's see how to add static routing to the startup script on a Solaris system. Before making changes to your real system, check your system's documentation. You may need to modify a different boot script, and the execution path of the routing daemon may be different. Only the documentation can provide the exact details you need.
On a Solaris system, edit /etc/init.d/inetinit to add the route statements:
route -n add default 172.16.12.1 1 > /dev/console route -n add 172.16.1.0 172.16.12.3 1 > /dev/console route -n add 172.16.6.0 172.16.12.3 1 > /dev/console route -n add 172.16.3.0 172.16.12.3 1 > /dev/console route -n add 172.16.9.0 172.16.12.3 1 > /dev/console
Next, check whether or not the script starts a routing protocol. If it does, comment out the lines that start it. You don't want a routing protocol running when you are using static routing. On our Solaris sample system, the routing software is only started if the system has more than one network interface (i.e., is a router) or the /etc/gateways file has been created. (More on this file later.) Neither of these things is true. Therefore the routing daemon won't be run by the startup process and we don't have to do anything except add the route statements.
Although the startup filename may be different on your system, the procedure should be basically the same. These simple steps are all you need to set up static routing. The problem with static routing is not setting it up, but maintaining it, if you have a changeable networking environment. Routing protocols are flexible enough to handle simple and complex routing environments. That is why some startup procedures run routing protocols by default. However, most UNIX systems need only a static default route. Routing protocals are usually needed only by routers.
|  | |
| 7.2 The Minimal Routing Table |  | 7.4 Interior Routing Protocols |