Traceroute

Similar to the record route option of the ping command, the traceroute command is used to
determine the path that the packet is taking through the network. However, traceroute uses a
different approach than the ping command. Specifically, the traceroute command starts by
sending out a packet with a time to live (TTL) of 1. The TTL of this packet will expire at the
first router, and therefore this device will send back a TTL expiration message. The address
from which the TTL expiration comes is then recorded, and a second packet is sent out with a
TTL of 2. The second-hop router then replies back with a TTL expiration message. This process
continues until the destination is reached.
The traceroute command operates in the Unix and Windows environment in the same manner
as the trace command in the Cisco router.
Though the functionality is the same, it is worthy of note that in the Cisco and
the Unix versions of traceroute, a UDP packet on port 33434 is used for the tracing,
whereas Windows stations use an ICMP echo instead.
In Windows, the syntax for the traceroute command is tracert. The options for the command
are shown in the following output, which is followed by a sample trace:
C:\>tracert /?
Usage: tracert [-d] [-h maximum_hops] [-j host-list] [-w timeout] target_name
Options:
-d Do not resolve addresses to hostnames.
-h maximum_hops Maximum number of hops to search for target.
-j host-list Loose source route along host-list.
-w timeout Wait timeout milliseconds for each reply.
C:\>tracert 10.5.5.5
Tracing route to 10.5.5.5 over a maximum of 30 hops
1 7 ms 1 ms 1 ms 10.21.2.1
2 84 ms 83 ms 84 ms 10.45.45.3
3 88 ms 85 ms 83 ms 10.10.10.67
4 87 ms 86 ms 88 ms 10.5.5.5
Trace complete.
When looking at the preceding trace, there are a couple things to note. First, Windows by
default sends out three traces for each TTL value. The times listed to the left of the IP address
are the times for each of the TTL expiration messages from these packets to return.
Also, when comparing the output from a recorded ping to the output of the traceroute command,
be aware of a couple of noteworthy differences. Ping records the exiting interface on the
router, whereas traceroute in general records the interface on which you enter. Another difference
is that when using a traceroute, you only get the path taken to the end device; you do not
see the return path.
As is the case with many of the commands discussed here, there are some subtle differences
between Unix and Windows in terms of both syntax and output. Here are the Unix command
options and a sample output:
unix1% traceroute
Usage: traceroute [-dFInvx] [-f first_ttl] [-g gateway | -r] [-i iface]
[-m max_ttl] [-p port] [-q nqueries] [-s src_addr] [-t tos]
[-w waittime] host [packetlen]
unix1% traceroute 10.5.5.5
traceroute to 10.5.5.5 (10.5.5.5), 30 hops max, 40 byte packets
1 10.21.2.1 (10.21.2.1) 1.046 ms 1.878 ms 1.880 ms
2 10.45.45.3 (10.45.45.3) 82.487 ms 84.850 ms 83.378 ms
3 10.10.10.67 (10.10.10.67) 84.196 ms 86.057 ms 84.105 ms
4 10.5.5.5 (10.5.5.5) 89.133 ms 88.664 ms 88.597 ms
unix1% 1081

Ping

The ping command was covered in some detail earlier in this chapter, so you can refer back to
the section “Creating an End-System Network Configuration Table” for the ping basics. Here
we will focus on some of the options available under the ping command that are helpful in your
troubleshooting activities.
One of the most common ping options is the continuous ping. These pings send a continuous
stream of packets to the destination address. Setting up a continuous ping to an end system that
is having connectivity problems is a good way to see when the end system is once again reachable
over the network. In Windows systems, the flag to send a continuous ping is -t, and in the
Unix environment the flag is -s.
Another frequently used ping option used for troubleshooting is the record route option.
This records the path the packet is taking through the network and stores this information in
the IP header of the ping packet.
The record route option does require that the intervening routers and the
end station retain this information in the packet, and the hop count is limited
to nine.

In a Windows station, record route can be enabled with the -r #_of_hops_to_record
option. In the following example, the route will be recorded for up to nine hops, which is the
maximum value allowed:
C:\>ping -r 9 10.5.5.5
Pinging 10.5.5.5 with 32 bytes of data:
Reply from 10.5.5.5: bytes=32 time=86ms TTL=251
Route: 10.45.45.1 ->
10.10.10.66 ->
10.5.5.1 ->
10.5.5.5 ->
10.16.16.18 ->
10.10.9.56 ->
10.10.7.23 ->
10.56.21.3
Reply from 10.5.5.5: bytes=32 time=86ms TTL=251
Route: 10.45.45.1 ->
10.10.10.66 ->
10.5.5.1 ->
10.5.5.5 ->
10.16.16.18 ->
10.10.9.56 ->
10.10.7.23 ->
10.56.21.3
Reply from 10.5.5.5: bytes=32 time=85ms TTL=251
Route: 10.45.45.1 ->
10.10.10.66 ->
10.5.5.1 ->
10.5.5.5 ->
10.16.16.18 ->
10.10.9.56 ->
10.10.7.23 ->
10.56.21.3
Reply from 10.5.5.5: bytes=32 time=83ms TTL=251
Route: 10.45.45.1 ->
10.10.10.66 ->
10.5.5.1 ->
10.5.5.5 ->
10.16.16.18 ->
10.10.9.56 ->
10.10.7.23 ->
10.56.21.3
Ping statistics for 10.5.5.5:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 83ms, Maximum = 86ms, Average = 85ms
In Unix, the similar command option for record route is as follows:
unix1% ping -s -nRv 10.5.5.5
PING 10.5.5.5 (10.5.5.5): 56 data bytes
64 bytes from 10.5.5.5: icmp_seq=0. time=123. ms
IP options: 10.45.45.1, 10.10.10.66, 10.5.5.1,
10.5.5.5, 10.16.16.18, 10.10.9.56, 10.10.7.23,
10.56.21.3

End-System Troubleshooting Commands

As you learned earlier in this chapter in the section “Creating an End-System Network Configuration
Table,” there are many occasions when you need to execute commands on the end system
in order to get a clear picture of what is going on in the network. This is true not only for
the discovery of network information but also for the troubleshooting of network behavior.
Because the basic commands used for discovery were discussed earlier in the chapter, here in this
section we will focus specifically on the troubleshooting commands. You will notice that many
of the same commands are used for both troubleshooting and discovery.
In this section, the Unix versions of the commands are used for the Unix, Linux,
and MacOS X end-system types. There can be slight variations between the
Unix and the Linux/MacOS X versions of the commands. However, most are
very similar and in some cases identical to their Unix counterparts.

Troubleshooting End-System Problems

In a perfect world, network administrators would be free to work solely on the network components
of the system, and the end systems would be taken care of by someone else. The reality
is that we do not live in such a place, so network administrators frequently must help troubleshoot
problems on the end systems. The assistance provided may be simply checking connectivity,
or it may involve the complete rebuilding of the end system! We are not going to get into
the rebuilding of a Windows server from scratch. In this section, you will see how to diagnose
what is happening on an end system, and how to take some simple corrective actions when they
are needed.

In addition to running these commands directly, you can also have the end user run many of
these commands for you and tell you the results. This can be very helpful, especially when the
users are located in a remote location.
Some of the commands examined in this section are variations of the ones used in creating
the end-system documentation; others are new. But before we look at how to identify and correct
problems, we will spend a little more time on how to approach the problem.

Creating an End-System Network Topology Diagram

Now that an end-system network topology diagram has been explained, let’s go through the
steps to create one. Because most end-system network topology diagrams are built on the network
topology diagrams, the standard symbols set that was used in the network diagrams will
also be used here in the end-system network topology diagram. In addition, there will be symbols
to indicate servers, workstations, and other network attached end systems.
The other information added to the end-system network topology diagram is a subset of the
data in the end-system network configuration table. Figure 35.2 shows how this data maps to
the topology diagram.
As you can see in Figure 35.2, the servers entered in the network configuration are shown in
their appropriate place in the network. Only the key information on the servers was transferred
to the topology diagram to keep it from becoming too cluttered. Also, as mentioned earlier in
this discussion, notice in the upper-left of the diagram that a grouping of computers was used
instead of showing all 12 of the Seattle users’ computers. This simplifies the drawing without
sacrificing too much detail. If more detail is needed, specifically on the Seattle office, a new endsystem
network topology diagram could be created specifically for that office.
Well, after what seems like an eternity, you have completed your network configuration
tables, network topology diagrams, end-system network configuration tables, and end-system
network topology diagrams! Now you just have to make sure that you keep them accessible and
update them any time there’s a change in the network. Also, remember to print hardcopies regularly,
so that you will still have your documentation if the network is down.