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


1079

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.
1076

Windows Name Resolution

When working with Windows systems, it is important to know the process by which names are
associated to IP addresses. In a Unix system, this resolution is relatively straightforward and usually
involves the use of cached entries, a HOSTS file, or DNS. In a Windows environment, however,
there are a few other options available. All the options that are available are as follows:
Internal cache of recently used entries
Broadcast message to the local network
Local LMHOSTS file
Local HOSTS file
WINS server
DNS server
In addition to the local cache, the HOSTS file, and DNS are three other options: broadcast, LMHOSTS,
and WINS. The order in which these items are checked in a Windows system varies based on a
number of factors, but in general, the internal cache and broadcast message are the first items
used to try to resolve a name into an IP address.
Following this, the LMHOSTS and HOSTS files are used. Both these files are usually located in the
%SystemRoot%\System32\Drivers\Etc directory of each Windows end system. They are textbased
files that can be edited to provide static name-to-IP-address translation.
Next in the series is the Windows Internet Name Service (WINS) server, which is Microsoft’s
version of a NetBIOS name server. It dynamically updates the names of other Windows clients
that are on the network. The server can then be queried in much the same manner as a DNS
server for name-to-IP-address resolution.
The final item used by a Windows end system is a DNS server. As is the case with any station
using DNS, a Windows station sends a query to the DNS server, and the server responds with
the IP address or a notification saying it does not know the address.