Section 13.5. Checking Routing

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.[5]

[5] netstat -nr works on most systems, but Linux administrators prefer route -n.

This example checks for a specific route to network

% netstat -nr | grep '^128\.8\.'     UG     0    37    dnet0

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, and a ping test returns the following results:

% ping -s 56 2 

PING 56 data bytes 

sendto: Network is unreachable 

ping: wrote 64 chars, ret=-1 

sendto: Network is unreachable 

ping: wrote 64 chars, ret=-1 PING Statistics----

2 packets transmitted, 0 packets received, 100% packet loss

Based on the "network unreachable" error message, check the user's routing table. In our example, we're looking for a route to The IP address[6] of is So we check for any route to a destination that begins with 152.2:

[6] Use nslookup to find the IP address if you don't know it. nslookup is discussed later in this chapter.

% netstat -nr | grep '^152\.2\.'


This test shows that there is no specific route to a destination that begins with 152.2. 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 on a Solaris system:[7]

[7] On a Linux system, grep for network, which Linux uses instead of the word "default" to indicate the default route.

% netstat -nr | grep def

default     UG    0   101277   dnet0

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 in the next section, to trace the route all the way to its destination.

If the routing table doesn't contain 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 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:

% ps 'cat /etc/' 


27711 ?  S   304:59 gated -tep /etc/log/gated.log

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.

13.5.1 Tracing Routes

If the local routing table is 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 13-2 presents a sample of the single line of output that is displayed for a gateway, and shows the meaning of each field in the line.

Figure 13-2. traceroute output

When the destination host receives a packet from traceroute, it returns an ICMP "Unreachable Port" message. This happens because traceroute intentionally uses an invalid port number (33434) to force this error. When traceroute receives the "Unreachable Port" message, it knows that it has reached the destination host, and it terminates the trace. So, traceroute 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. Figure 13-3 illustrates the flow of packets tracing to a host three hops away. The following shows a traceroute to from a Solaris system hanging off the Comcast network. traceroute sends out three packets at each TTL value. If no response is received to a packet, traceroute prints an asterisk (*). If a response is received, traceroute displays the name and address of the gateway that responded and the packet's round trip time in milliseconds.

Figure 13-3. Flow of traceroute packets
$ traceroute

traceroute to (, 30 hops max, 40 byte packets

 1 ani (  1.712 ms  1.40 ms  1.34 ms

 2 (  52.01 ms  34.38 ms  118.97 ms

 3 ( 13.30 ms 100.92 ms 31.99 ms

 4 ( 118.63 ms 94.92 ms 121.10 ms

 5 ( 127.63 ms  26.29 ms  132.07 ms

 6 ( 186.02 ms 164.81 ms 156.44 ms

 7 ( 86.59 ms 130.28 ms 121.09 ms

 8 ( 84.594 ms 117.42 ms 174.59 ms

 9 ( 123.87 ms 91.39 ms 119.79 ms

10 ( 142.38 ms 166.11 ms 95.32 ms

11 ( 137.59 ms 98.28 ms 256.11 ms

12 ( 98.64 ms 125.03 ms 231.11 ms

13 ( 192.06 ms 164.52 ms 103.30 ms

14 ( 113.33 ms 145.72 ms 107.39 ms

15 * ( 99.67 ms 178.72 ms

This trace shows that 15 intermediate gateways are involved, that packets are making the trip, and that round trip travel time for packets from this host to is about 140 ms.

Variations and bugs in the implementation of ICMP on different types of gateways, as well as 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:

  • Did the packet get to its remote destination?

  • If not, where did it stop?

In the code below we show another trace of the path to This time the trace does not go all the way through to the InterNIC.

$ traceroute

traceroute to (, 30 hops max, 40 byte packets

 1 ani (  1.712 ms  1.40 ms  1.34 ms

 2 (  52.01 ms  34.38 ms  118.97 ms

 3 ( 13.30 ms 100.92 ms 31.99 ms

 4 ( 118.63 ms 94.92 ms 121.10 ms

 5 ( 127.63 ms  26.29 ms  132.07 ms

 6 ( 186.02 ms 164.81 ms 156.44 ms

 7 ( 86.59 ms 130.28 ms 121.09 ms

 8 ( 84.594 ms 117.42 ms 174.59 ms

 9  * * * 

10  * * * 




29  * * *

30  * * *

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 We would therefore contact this system administrator and the administrator of

13.5.2 Locating an Administrator

To contact a remote administrator, you must know who to contact. whois helps you locate important people. One of the most important pieces of information in a network is who is in charge at the other end. When troubleshooting a network problem, whois is a tool that helps you find this out.

whois obtains the requested information from the Internet white pages. The white pages is a database of information about responsible people that is maintained by the Internet registrars. When you request an official network number or domain name, you are asked to provide contact information, which becomes your personal record in the white pages database. Because of this, everyone who is responsible for an official network or domain is supposed to have an entry in the white pages, and that entry can be retrieved by anyone who needs to contact them.

Many Unix systems provide a whois command to query the white pages. The general form of this command is:

% whois [-h server] name

The name field is the information to be searched for in the white pages database. The server field is the name of a system containing the white pages.

In the following example, we search for contact information for the domain, which is the domain where the remote router from the traceroute example is located.

$ whois


Whois Server Version 1.3

Domain names in the .com, .net, and .org domains can now be registered

with many different competing registrars. Go to

for detailed information.

   Domain Name: VERIO.NET


   Whois Server:

   Referral URL:

   Name Server: NS0.VERIO.NET

   Name Server: NS1.VERIO.NET

   Name Server: NS2.VERIO.NET

   Updated Date: 13-jun-2001

>>> Last update of whois database: Tue, 17 Jul 2001 02:04:28 EDT <<<

The Registry database contains ONLY .COM, .NET, .ORG, .EDU domains and



Domain Name..........

  Creation Date........ 1996-12-07

  Registration Date.... 2000-05-10

  Expiry Date.......... 2001-12-06

  Organisation Name.... Verio, Inc.

  Organisation Address. 8005 South Chester Street

  Organisation Address. Suite 200

  Organisation Address. Englewood

  Organisation Address. CO

  Organisation Address. 80112

  Organisation Address. UNITED STATES

Admin Name........... Hostmaster Verio

  Admin Address........ 8005 South Chester Street

  Admin Address........ Suite 200

  Admin Address........ Englewood

  Admin Address........ 80112

  Admin Address........ CO

  Admin Address........ UNITED STATES

  Admin Email..........

  Admin Phone.......... 214 290 8620

  Admin Fax............ .

Tech Name............ Hostmaster Verio

  Tech Address......... 8005 South Chester Street

  Tech Address......... Suite 200

  Tech Address......... Englewood

  Tech Address......... CO

  Tech Address......... 80112

  Tech Address......... UNITED STATES

  Tech Email...........

  Tech Phone........... 214 290 8620

  Tech Fax............. .

  Name Server.......... NS0.VERIO.NET

  Name Server.......... NS1.VERIO.NET

  Name Server.......... NS2.VERIO.NET

The query displays the name, address, and telephone number of the contacts for the domain, as well as a list of hosts providing authoritative name service for the domain. This example shows how it is supposed to work, and for substantial, well-run networks such as, it usually does. Unfortunately, many whois queries return no useful information because the white pages database is poorly maintained. If whois provides no information, try checking DNS name service. The DNS SOA record should contain a mailing address for a domain contact who may be able to point you to the right system administrator.