The "network unreachable" error message clearly indicates a routing problem. If the problem is in the local host's routing table, it is easy to detect and resolve. First, use netstat -nr and grep to see whether or not a valid route to your destination is installed in the routing table. This example checks for a specific route to network 184.108.40.206:
This same test, run on a system that did not have this route in its routing table, would return no response at all. For example, a user reports that the "network is down" because he cannot ftp to sunsite.unc.edu , and a ping test returns the following results:
Based on the "network unreachable" error message, check the user's routing table. In our example, we're looking for a route to sunsite.unc.edu . The IP address  of sunsite.unc.edu is 220.127.116.11, which is a class B address. Remember that routes are network-oriented. So we check for a route to network 18.104.22.168:
This test shows that there is no specific route to 22.214.171.124. If a route was found, grep would display it. Since there's no specific route to the destination, remember to look for a default route. This example shows a successful check for a default route:
If netstat shows the correct specific route, or a valid default route, the problem is not in the routing table. In that case, use traceroute , as described later in this chapter, to trace the route all the way to its destination.
If netstat doesn't return the expected route, it's a local routing problem. There are two ways to approach local routing problems, depending on whether the system uses static or dynamic routing. If you're using static routing, install the missing route using the route add command. Remember, most systems that use static routing rely on a default route, so the missing route could be the default route. Make sure that the startup files add the needed route to the table whenever the system reboots. See Chapter 7, Configuring Routing , for details about the route add command.
If you're using dynamic routing, make sure that the routing program is running. For example, the command below makes sure that gated is running:
If the correct routing daemon is not running, restart it and specify tracing. Tracing allows you to check for problems that might be causing the daemon to terminate abnormally.
If the routing daemon is running and the local system receives routing updates via Routing Information Protocol (RIP), use ripquery to check the updates received from your RIP suppliers. For example, to check the RIP updates being received from almond and pecan , the peanut administrator enters the following command:
After an initial line identifying the gateway, ripquery shows the contents of the incoming RIP packets, one line per route. The first line of the report above indicates that ripquery received a response from almond . That line is followed by two lines for the two routes advertised by almond . almond advertises the default route (destination 0.0.0.0) with a metric of 3, and its direct route to Milnet (destination 10.0.0.0) with a metric of 0. Next, ripquery shows the routes advertised by pecan . These are the routes to the other nuts-net subnets.
The three ripquery options used in this example are:
The routes returned in these updates should be the routes you expect. If they are not, or if no routes are returned, check the configuration of the RIP suppliers. Routing configuration problems cause RIP suppliers to advertise routes that they shouldn't, or to fail to advertise the routes that they should. You can detect these problems only by applying your knowledge of your network configuration. You must know what is right to detect what is wrong. Don't expect to see error messages or strange garbled routes. For example, assume that in the previous test pecan returned the following update:
264 bytes from pecan.nuts.com(172.16.12.3): 0.0.0.0, metric 2 172.16.3.0, metric 2 . . . 172.16.12.0, metric 2 172.16.13.0, metric 2
This update shows that pecan is advertising itself as a default gateway with a lower cost (2 versus 3) than almond . This would cause every host on this subnet to use pecan as its default gateway. If this is not what you wanted, the routing configuration of pecan should be corrected. 
If the local routing table and RIP suppliers are correct, the problem may be occurring some distance away from the local host. Remote routing problems can cause the "no answer" error message, as well as the "network unreachable" error message. But the "network unreachable" message does not always signify a routing problem. It can mean that the remote network cannot be reached because something is down between the local host and the remote destination. traceroute is the program that can help you locate these problems.
traceroute traces the route of UDP packets from the local host to a remote host. It prints the name (if it can be determined) and IP address of each gateway along the route to the remote host.
traceroute uses two techniques, small ttl (time-to-live) values and an invalid port number, to trace packets to their destination. traceroute sends out UDP packets with small ttl values to detect the intermediate gateways. The ttl values start at 1 and increase in increments of 1 for each group of three UDP packets sent. When a gateway receives a packet, it decrements the ttl. If the ttl is then 0, the packet is not forwarded and an ICMP "Time Exceeded" message is returned to the source of the packet. traceroute displays one line of output for each gateway from which it receives a "Time Exceeded" message. Figure 11.2 shows a sample of the single line of output that is displayed for a gateway, and it shows the meaning of each field in the line.
When the destination host receives a packet from
returns an ICMP "Unreachable Port" message. This happens because
intentionally uses an invalid port number (33434) to
force this error. When
receives the "Unreachable
Port" message, it knows that it has reached the destination host, and
it terminates the trace. So,
is able to
develop a list of the gateways, starting at one hop away and
increasing one hop at a time until the remote host is reached.
illustrates the flow of packets tracing to a host three hops away. The following shows
from a Linux system hanging off
sends out three packets at
each ttl value. If no response is received to a packet,
prints an asterisk (
Variations and bugs in the implementation of ICMP on different types of gateways, and the unpredictable nature of the path a datagram can take through a network, can cause some odd displays. For this reason, you shouldn't examine the output of traceroute too closely. The most important things in the traceroute output are:
In the code below we show another trace of the path to ds.internic.net . This time the trace does not go all the way through to the InterNIC.
When traceroute fails to get packets through to the remote end system, the trace trails off, displaying a series of three asterisks at each hop count until the count reaches 30. If this happens, contact the administrator of the remote host you're trying to reach, and the administrator of the last gateway displayed in the trace. Describe the problem to them; they may be able to help.  In our example, the last gateway that responded to our packets was cambridge1-br1.bbnplanet.net . We would contact this system administrator, and the administrator of ds.internic.net .