Using Diagnostic Utilities
Given output from a diagnostic utility (e.g., tracert, ping, ipconfig), identify the utility and interpret the output.
You can use many different tools to monitor and troubleshoot TCP/IP networks. Chapter 13 discusses how to use these tools; this chapter looks at the output from the various utilities and what you can learn in each case.
EXAM TIP
Know the Command Output On the Network+ exam, you will be asked to identify the output from a command, and you should be able to interpret the information provided by the command.
ping
ping is perhaps the most widely used of all network tools; it is primarily used to verify connectivity between two network devices. On a good day, the results from the ping command will be successful, and the sending device will receive a reply from the remote device. Not all ping results are that successful, and to be able to effectively use ping, you must be able to interpret the results of a failed ping command.
When you're troubleshooting with the ping command, four key error messages can be returned: two of the error messages are quite common, and two are a little less common. The following sections describe these results of a ping command.
The Destination Host Unreachable Message
The Destination Host Unreachable error message means that a route to the destination computer system cannot be found. To remedy this problem, you might need to examine the routing information on the local host to confirm that the local host is correctly configured, or you might need to make sure the default gateway information is correct. Listing 14.1 shows an example of a ping failure that gives the Destination Host Unreachable message.
Listing 14.1. A ping Failure with the Destination Host Unreachable
The Request Timed Out Message
The Request Timed Out error message is very common when you use the ping command. Essentially, this error message indicates that your host did not receive the ping message within the designated time period. This is typically an indicator that the destination device is not connected to the network, is powered off, or is not configured correctly. It could also mean that some intermediate device is not operating correctly. In some rare cases, it can also indicate that there is so much congestion on the network that timely delivery of the ping message could not be completed. It might also mean that the ping is being sent to an invalid IP address or that the system is not on the same network as the remote host, and an intermediary device is not configured correctly. In any of these cases, the failed ping should initiate a troubleshooting process that may involve other tools, manual inspection, and possibly reconfiguration. Listing 14.2 shows the output from a ping to an invalid IP address.
Listing 14.2. The Output for a ping to an Invalid IP Address
Refer to Chapter 13 for information on troubleshooting procedures using ping.
During the ping request, you might receive some replies from the remote host that are intermixed with Request Timed Out errors. This is often a result of a congested network. An example follows; notice that the example in Listing 14.3, which was run on a Windows Me system, uses the -t switch to generate continuous pings.
Listing 14.3. The -t Switch Generating Continuous pings
C:>ping -t 24.67.184.65
Pinging 24.67.184.65 with 32 bytes of data:
Reply from 24.67.184.65: bytes=32 time=55ms TTL=127
Reply from 24.67.184.65: bytes=32 time=54ms TTL=127
Reply from 24.67.184.65: bytes=32 time=27ms TTL=127
Request timed out.
Request timed out.
Request timed out.
Reply from 24.67.184.65: bytes=32 time=69ms TTL=127
Reply from 24.67.184.65: bytes=32 time=28ms TTL=127
Reply from 24.67.184.65: bytes=32 time=28ms TTL=127
Reply from 24.67.184.65: bytes=32 time=68ms TTL=127
Reply from 24.67.184.65: bytes=32 time=41ms TTL=127
Ping statistics for 24.67.184.65:
Packets: Sent = 11, Received = 8, Lost = 3 (27% loss),
Approximate round trip times in milli-seconds:
Minimum = 27ms, Maximum = 69ms, Average = 33ms
|
In this example, three packets were lost. If this continued on your network, you would need to troubleshoot to find out why packets were being dropped.
The Unknown Host Message
The Unknown Host error message is generated when the hostname of the destination computer cannot be resolved. This error usually occurs when you ping an incorrect hostname, as shown in the following example, or try to use ping with a hostname when hostname resolution (via DNS or a HOSTS text file) is not configured:
C:>ping www.comptia.ca Unknown host www.comptia.ca
NOTE
Security Settings and Connection Errors A remote host connection error can sometimes be caused by your server's security settings. For instance, the IPSec policies might restrict access to certain hosts. You might need to shut down security when you're troubleshooting errors.
If the ping fails, you need to verify that the ping is being sent to the correct remote host. If it is, and if name resolution is configured, you have to dig a little more to find the problem. This error might indicate a problem with the name resolution process, and you might need to verify that the DNS or WINS server is available. Other commands, such as nslookup, can help in this process.
The Expired TTL Message
The Time to Live (TTL) is an important consideration in understanding the ping command. The function of the TTL is to prevent circular routing, which occurs when a ping request keeps looping through a series of hosts. The TTL counts each hop along the way toward its destination device. Each time it counts one hop, the hop is subtracted from the TTL. If the TTL reaches 0, the TTL has expired, and you get a message like the following:
Reply from 24.67.180.1: TTL expired in transit
EXAM TIP
More on ping As you can see from each of the ping examples, a common set of information is provided each time you run ping. This summary can be useful for getting an overall picture of the ping information.
If the TTL is exceeded with ping, you might have a routing problem on the network. You can modify the TTL for ping on a Windows system by using the ping -i command.
The tracert Command
The tracert command, which is short for trace route, does exactly what its name implies—it traces the route between two hosts by using Internet Control Message Protocol (ICMP) echo packets to report back at every step in the journey. The tracert command provides a lot of useful information, including the IP address of every router connection it passes through, and in many cases the name of the router (although this depends on the router's configuration). tracert also reports the length, in milliseconds, of the round trip the packet made from the source location to the router and back. This information can tell you a lot about where network bottlenecks or breakdowns may be. Listing 14.4 shows an example of a successful tracert command on a Windows 2000 system.
Listing 14.4. A tracert Command
C:>tracert 24.7.70.37 Tracing route to c1-p4.sttlwa1.home.net [24.7.70.37] over a maximum of 30 hops: 1 30 ms 20 ms 20 ms 24.67.184.1 2 20 ms 20 ms 30 ms rd1ht-ge3-0.ok.shawcable.net [24.67.224.7] 3 50 ms 30 ms 30 ms rc1wh-atm0-2-1.vc.shawcable.net [204.209.214.193] 4 50 ms 30 ms 30 ms rc2wh-pos15-0.vc.shawcable.net [204.209.214.90] 5 30 ms 40 ms 30 ms rc2wt-pos2-0.wa.shawcable.net [66.163.76.37] 6 30 ms 40 ms 30 ms c1-pos6-3.sttlwa1.home.net [24.7.70.37] Trace complete. |
The tracert display on a Windows-based system includes several columns of information. The first column represents the hop number. The next three columns indicate the round-trip time, in milliseconds, that a packet takes in its attempts to reach the destination. The last column is the hostname and the IP address of the responding device.
Of course, not all tracert commands are successful. Listing 14.5 shows the output from a tracert command that doesn't manage to get to the remote host.
Listing 14.5. A tracert Command That Doesn't Get to the Remote Host
In this example, the tracert only gets to the seventh hop, at which point it fails; this failure indicates that the problem lies on the far side of the device in step 7 or on the near side of the device in step 8. In other words, the device at step 7 is functioning but might not be able to make the next hop. The cause of the problem could be a range of things, such as an error in the routing table or a faulty connection. Alternatively, the seventh device might be operating 100%, but Device 8 might not be functioning at all. In any case, you can isolate the problem to just one or two devices.
EXAM TIP
Trace Route Names The CompTIA objectives refer to the tracert utility by name. However, the trace route functionality has different names on other platforms. The output is much the same across all platforms.
The tracert command can also help you isolate a heavily congested network. In the following example, the trace route packets fail in the midst of the tracert but subsequently are able to continue. This behavior can be an indicator of network congestion, as shown in Listing 14.6.
Listing 14.6. A Trace Route Packet Failure During the tracert
NOTE
route Interpretation This section explores the results from the Windows tracert command, but interpreting route command results is similar throughout the various other operating system platforms.
Generally speaking, tracert allows you to identify the location of a problem in the connectivity between two devices. After you have determined this location, you might need to use a utility such as ping to continue troubleshooting. In many cases, as in the examples provided in this chapter, the routers might be on a network such as the Internet and so not be within your control. In that case, there is little you can do except inform your ISP of the problem.
The netstat Command
As discussed in Chapter 13, the netstat command displays the protocol statistics and current TCP/IP connections. Used without any switches, the netstat command shows the active connections for all outbound TCP/IP connections. In addition, several switches are available that change the type of information netstat displays.
The following sections show the output from several netstat switches and identify and interpret the output from each command.
netstat –e
The netstat -e command shows the activity for the NIC and displays the number of packets that have been both sent and received. An example of the netstat -e command is shown in Listing 14.7.
Listing 14.7. An example of the nestat –e Command
C:WINDOWSDesktop>netstat -e
Interface Statistics
Received Sent
Bytes 17412385 40237510
Unicast packets 79129 85055
Non-unicast packets 693 254
Discards 0 0
Errors 0 0
Unknown protocols 306
|
As you can see, the netstat -e command shows more than just the packets that have been sent and received. The following list briefly explains the information provided in the netstat -e command:
Bytes— The number of bytes that have been sent or received by the NIC since the computer was turned on.
Unicast packets— Packets sent and received directly to this interface.
Non-unicast packets— Broadcast or multicast packets that were picked up by the NIC.
Discards— The number of packets rejected by the NIC, perhaps because they were damaged.
Errors— The errors that occurred during either the sending or receiving process. As you would expect, this column should be a low number. If it is not, it could indicate a problem with the NIC.
Unknown protocols— The number of packets that were not recognizable by the system.
netstat -a
The netstat -a command displays statistics for both the TCP and User Datagram Protocol (UDP). Listing 14.8 shows an example of the netstat -a command.
Listing 14.8. An example of the netstat –a Command
As you can see, the output includes four columns, which show the protocol, the local address, the foreign address, and the state of the port. The TCP connections show the local and foreign destination address and the current state of the connection. UDP, however, is a little different; it does not list a state status because as mentioned throughout this book, UDP is a connectionless protocol and does not establish connections. The following list briefly explains the information provided by the netstat -a command:
Local Address— The IP address of the local computer system and the port number it is using. If the entry in the local address field is an asterisk (*), it indicates that the port has not yet been established.
Foreign Address— The IP address of a remote computer system and the associated port. When a port has not been established, as with the UDP connections, *:* appears in the column.
State— The current state of the TCP connection. Possible states include established, listening, closed, and waiting.
netstat -r
The netstat -r command is often used to view the routing table for a system. A system uses a routing table to determine routing information for TCP/IP traffic. Listing 14.9 shows an example of the netstat -r command from a Windows Me system.
NOTE
Getting Routing Information The routing information provided by the netstat -r command on a Windows system is the same as that produced by the route print command.
Listing 14.9. An example of the netstat –r Command
NOTE
TCP Information in Windows In some versions of Windows, the TCP connection information section at the bottom of the screen is not shown.
netstat -s
The netstat -s command displays a number of different statistics related to the TCP/IP protocol suite. Understanding the purpose of every field in the output is beyond the scope of the Network+ exam, but for your reference, sample output from the netstat -s command is shown in Listing 14.10.
Listing 14.10. An example of the netstat –s Command
The ipconfig Command
The ipconfig command is a technician's best friend when it comes to viewing the TCP/IP configuration of a Windows system—at least most Windows-based systems. The ipconfig command cannot be used on Windows 95 and Windows 98 systems. Used on its own, the ipconfig command shows basic information such as the name of the network interface, the IP address, the subnet mask, and the default gateway. Combined with the /all switch, it shows a detailed set of information, as you can see in Listing 14.11.
Listing 14.11. An example of the ipconfig /all Command
As you can imagine, you can use the output from an ipconfig /all command in a massive range of troubleshooting scenarios. Table 14.2 lists some of the most common troubleshooting symptoms, along with where to look for clues about solving them in the ipconfig /all output.
EXAM TIP
Check the ipconfig Information When looking at ipconfig information, you should be sure that all information is present and correct. For example, a missing or incorrect default gateway parameter would limit communication to the local segment. Be sure to know this for the exam.
EXAM TIP
Identify the ipconfig Output You should be prepared to identify the output from an ipconfig command in relationship to a troubleshooting scenario for the Network+ exam.
The winipcfg Command
On a Windows 95, Windows 98, or Windows Me system, the winipcfg command is used instead of the ipconfig command. The difference between the two utilities is that winipcfg is a graphical utility. Figure 14.9 shows the winipcfg graphical screen.
Figure 14.9. The basic winipcfg screen.
As you can see, in basic mode, winipcfg shows information including the Media Access Control (MAC) address and IP address of the interface, the subnet mask, and the default gateway. For detailed information, similar to that produced with ipconfig /all, a More Info button allows you to switch into a much more detailed screen (see Figure 14.10).
Figure 14.10. A detailed winipcfg screen.
The same troubleshooting scenarios, with the same solutions, apply to winipcfg as to ipconfig. Refer to Table 14.2 to see some explanations of common problems and solutions.