Basics of Network Monitoring Tools: ping and traceroute

Basic network tools like ping and traceroute are probably the most commonly used tools by network administrators. These two simple, yet powerful, tools can determine network parameters like connectivity, latency, hop count, round-trip delay, TimeToLive (TTL), and others. Netadmins can, then, use the results from these tools to isolate the root cause of a network issue.

Verifying Network Connectivity Using ping

Ping is arguably the most popular tool used to verify the following parameters:

• Network connectivity between two endpoints

• Round-trip delay in communicating with the host

• Packet loss

These parameters can be applied to diagnose network problems. Ping works by sending an Internet Control Message Protocol (ICMP) Echo Request message and waiting for the ICMP Echo Reply packets. Successful receipt of an Echo Reply message verifies that the connection is working. The round-trip time is calculated as the total time taken to successfully send and receive a packet. The value of round-trip time helps a network administrator to recognize a problem, even though the packets might be getting through.

Note

According to its author, Mike Muuss, the ping tool is analogous to the sonar system, and hence he named it after the sound made by the sonar system. This is contrary to the popular myth of ping being an acronym of packet internet groper. The acronym was later coined by Dr. Dave Mills, who had previously done similar work.

Ping is a client-based tool for which no installation is required on the target node. It is pre-installed in most operating systems, and it requires no configuration to use. The following sections discuss the three main environments in which you can use ping:

• MS-Windows-based ping command

• Linux-based ping command

• IOS-based ping command

Using the MS-Windows-Based ping Command

You can use ping to verify network connectivity from a Windows machine. The ping command is preinstalled in MS-Windows (Windows 95 and higher). The command, which is command-line interface (CLI)-based, can be used through the MS-Windows command prompt. To verify network connectivity from an MS-Windows 95/98/Me/NT/2000/XP- based machine to a target host, follow these steps:

Step 1.	Open a command-line session. In most versions of Windows, you do this by choosing Start > Run. In the Run window, enter command and click the OK button.
Step 2.	In the command-line session, enter the ping hostname-or-IP-address command and press Enter.

Example 2-1 shows the use of a ping command in Windows XP. Depending on your version of Windows, the output can be slightly different. However, the functions discussed throughout this chapter are applicable to all versions of Windows.

Example 2-1. Output of the ping Command in Windows XP

 C:\WINDOWS\system32>ping /? Usage: ping [-t] [-a] [-n count] [-l size] [-f] [-i TTL] [-v TOS]             [-r count] [-s count] [[-j host-list] | [-k host-list]]             [-w timeout] target_name Options:     -t             Ping the specified host until stopped.                    To see statistics and continue - type Control-Break;                    To stop - type Control-C.     -a             Resolve addresses to hostnames.     -n count       Number of echo requests to send.     -l size        Send buffer size.     -f             Set Don't Fragment flag in packet.     -i TTL         Time To Live.     -v TOS         Type Of Service.     -r count       Record route for count hops.     -s count       Timestamp for count hops.     -j host-list   Loose source route along host-list.     -k host-list   Strict source route along host-list. -w timeout     Timeout in milliseconds to wait for each reply. 

In Example 2-1, the -t, -a, and -w options are available in all versions of Windows. These options are discussed in greater detail in the following sections.

Note

Before verifying network connectivity to remote machines, it is good practice to verify that the Transmission Control Protocol/Internet Protocol (TCP/IP) stack on the Windows machine works correctly. To verify the IP address of the local Windows machine, open a command prompt and enter ipconfig. This command shows the configured IP address for each of the network interfaces, along with their subnet mask and default gateway. Try using the ipconfig /all command for detailed information.

For Linux/UNIX-based machines, use the ifconfig command.

Verifying Basic Network Connectivity with the ping Command

The scenario in Figure 2-1 shows a Windows computer connected to its default gateway through an Ethernet network.

Figure 2-1. MS-Windows-Based ping Command

To verify the connectivity between the Windows host and its default gateway, the administrator enters the ping 192.168.0.10 command on the Windows XP computer.

Example 2-2 shows the output of the ping session.

Example 2-2. Using the ping Command to Verify Connectivity

 C:\WINDOWS\system32>ping 192.168.0.10 Pinging 192.168.0.10 with 32 bytes of data: Reply from 192.168.0.10: bytes=32 time=30ms TTL=255 Reply from 192.168.0.10: bytes=32 time=15ms TTL=255 Reply from 192.168.0.10: bytes=32 time=15ms TTL=255 Reply from 192.168.0.10: bytes=32 time=10ms TTL=255 Ping statistics for 192.168.0.10:     Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 10ms, Maximum = 30ms, Average = 17ms 

The first line of the ping command output shows that the ping command is using 32 bytes of data in the payload.

Lines 2-5 of the command output show the details of each packet as follows:

• 192.168.0.10 is the IP address of the target.

• 32 is the size of each transmitted packet.

• The round-trip time is measured in milliseconds (ms).

• The TimeToLive (TTL) field is set to 255.

If the connection is of bad quality or the host is down, the output shows a Request timed out message instead of the message shown in Example 2-2.

Lines 6-9 show the summary of the result. Because the 4 packets were sent and received, there is 0 percent loss. Also, the minimum, average, and maximum values of the round-trip time are calculated based on the round-trip time of each packet. Depending on the speed of the link, the round-trip times and TTL values can differ.

Tip

Use the ping command to determine the round-trip time for a network segment. Round-trip time is important for proper functioning of some real-time applications. For example, Voice over IP (VoIP) has a maximum of 300 ms, whereas Citrix has a maximum of 250 ms for acceptable performance.

Inaccurate Results of the ping Command

Ping uses ICMP traffic, whereas most of the user traffic consists of TCP or User Datagram Protocol (UDP). If ICMP traffic is blocked on a network, the web traffic can still pass but ping will fail. Thus, ping can potentially produce inaccurate results. This section discusses inaccurate results because of the following issues:

• Timeout value of the ping command

• Maximum transmission unit (MTU) value of the link

Timeout Value of the Windows ping Command

The default timeout value for the Windows ping command is 1000 milliseconds (1 second). If the Echo Reply message fails to reach the sender before the end of 1000 milliseconds, the packet is considered lost. The output of the ping command shows the Request timed out message (see Example 2-3). This can cause inaccurate results on slower links such as satellite-based connections. You should use the w milli-seconds option of the ping command to change the default timeout value. For example, using the ping -w 5000 192.168.0.10 command sets the timeout value to 5000 milliseconds (5 seconds).

Example 2-3 shows the output of the ping command. The destination address 172.16.10.99 is a web server, as previously shown in Figure 2-1.

Example 2-3. Ping Command with Increased Timeout

 C:\WINDOWS\system32>ping  172.16.10.99 Pinging 172.16.10.99 with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Ping statistics for 172.16.10.99:     Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), C:\WINDOWS\system32>ping 172.16.10.99 -w 5000 Pinging 172.16.10.99 with 32 bytes of data: Reply from 172.16.10.99: bytes=32 time=1032ms TTL=103 Reply from 172.16.10.99: bytes=32 time=1055ms TTL=103 Reply from 172.16.10.99: bytes=32 time=1059ms TTL=103 Reply from 172.16.10.99: bytes=32 time=1096ms TTL=103 Ping statistics for 172.16.10.99:     Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds:     Minimum = 1055ms, Maximum = 1032ms, Average = 1010ms 

Example 2-3 shows that changing the timeout value to 5000 ms by using the w 5000 option results in no timeouts.

MTU Value of the Link

The maximum IP datagram size, also known as the MTU, depends on the type of network. On an Ethernet network, the MTU is 1500 bytes. When a host transmits an IP datagram larger than the MTU size, the router fragments the datagram into smaller chunks. The receiving station reassembles the smaller chunks to recover the original IP datagram. If the Don't Fragment (DF) bit in the IP header of the datagram is set, the router cannot fragment the datagram. But at the same time, larger packets cannot be transmitted on links with lower MTU values. Hence, the router drops the bigger packets and sends an ICMP Destination Unreachable, fragmentation needed and DF set message to the source. On receiving the ICMP message, the source host lowers the datagram size.

Because of growing security concerns, ICMP traffic is often blocked by firewalls and routers. Netadmins selectively allow ICMP Echo Request and Echo Reply messages (which are legitimate ping traffic) through the firewalls. In such cases, the source host never receives the ICMP Unreachable messages and continues to send the larger packets. The network connection between the source and destination hosts is effectively down, because the intermediate router drops the packets.

When a Netadmin uses ping to troubleshoot MTU-related connectivity issues, the ping traffic always succeeds. This is because Windows uses a default ping packet size of 56 bytes, which is smaller than the typical MTU size of the network. This leads to inaccurate conclusions. Ping packets with the DF bit set and with larger IP datagram sizes produce accurate results. The same applies to MTU tests using Linux- or IOS-based ping. Linux uses a default packet size of 56 bytes, whereas IOS uses 100 bytes.

To elaborate further, consider the network scenario shown in Figure 2-1. The Netadmin is facing connectivity issues to the web server 172.16.10.99. All the users in the 192.168.0.0/ 24 LAN can access the remote web server but cannot download large files from the server.

The Netadmin pings from the Windows machine (192.168.0.100) to the web server (172.16.10.99) using the ping 172.16.10.99 command. The results are successful, as shown in Example 2-4. Suspecting the culprit to be MTU size, the Netadmin sends larger ping packets with the DF bit set. As mentioned in Example 2-1, the -f option sets the DF bit, and the -l buffer-size option specifies the data payload size. The ping -f -l 1500 172.16.10.99 command sets the DF bit and specifies the packet size of 1500 bytes. The output in Example 2-4 shows that the replies were not received. Instead, the output displays the Request timed out message. The system might also display the Packet needs to be fragmented but DF set message.

On lowering the payload size to 1273 bytes, the replies are still failing. After reducing the payload size to 1272, the replies are received.

The actual MTU of the link is the sum of payload size and the IP header size. Because Windows uses 28 bytes for the IP header of the ping packet, the MTU in this example is 1272 + 28 = 1300 bytes. Hence, the MTU for successful data transfer from the web server is 1300 bytes. The webmaster should reduce the MTU size on the web server to 1300 to solve the issue.

Example 2-4. Using the ping Command to Determine MTU Size

 # Regular ping succeeds                                         c:\windows\system32>ping 172.16.10.99 Pinging 172.16.10.99 with 32 bytes of data: Reply from 172.16.10.99: bytes=32 time=17ms TTL=254 Reply from 172.16.10.99: bytes=32 time=18ms TTL=254 Reply from 172.16.10.99: bytes=32 time=18ms TTL=254 Reply from 172.16.10.99: bytes=32 time=21ms TTL=254 Ping statistics for 172.16.10.99:     Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds:     Minimum = 17ms, Maximum = 21ms, Average = 18ms # ping packet with DF bit set and payload size 1500 fails       c:\windows\system32>ping -f -l 1500 172.16.10.99 Pinging 172.16.10.99 with 1273 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Ping statistics for 172.16.10.99:    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), # ping packet with DF bit set and payload size 1273 still fails c:\windows\system32>ping -f -l 1273 172.16.10.99 Pinging 172.16.10.99 with 1273 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Ping statistics for 172.16.10.99:     Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), # ping packet with DF bit set and payload size 1272 succeeds    c:\windows\system32>ping -f -l 1272 172.16.10.99 Pinging 172.16.10.99 with 1272 bytes of data: Reply from 172.16.10.99: bytes=1272 time=25ms TTL=254 Reply from 172.16.10.99: bytes=1272 time=24ms TTL=254 Reply from 172.16.10.99: bytes=1272 time=26ms TTL=254 Reply from 172.16.10.99: bytes=1272 time=23ms TTL=254 Ping statistics for 172.16.10.99:     Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 23ms, Maximum = 26ms, Average = 24ms 

Note

MTU-related issues are common in IP Security (IPSec)-based virtual private networks (VPN). IPSec encapsulates the original IP datagram with an IPSec header, thus making the packet larger. The following two documents, which you can find on Cisco.com, provide more information on the MTU issue:

• IP Fragmentation and MTU Path Discovery with VPN (http://www.cisco.com/en/US/products/hw/routers/ps4081/products_tech_note09186a0080094268.shtml)

• Adjusting IP MTU, TCP MSS, and PMTUD on Windows and Sun Systems (http://www.cisco.com/en/US/tech/tk870/tk472/tk473/technologies_tech_note09186a008011a218.shtml)

Because of misuse of ICMP for network reconnaissance by malicious users, Netadmins often block ICMP on the router or firewalls. The unwanted side effect of this action is blocking the legitimate ping traffic.

The ping process is assigned a lower priority on the routers. If the router CPU utilization is high, the ping process might not respond, although the legitimate traffic is flowing. Additionally, the ICMP traffic is often assigned a lower priority.

Quite often, as a security measure, firewalls block traffic originating from the outside network into the inside (protected) network. In such cases, only the ping initiated from the inside network succeeds. The ping from outside the network fails.

All these factors can also lead to inaccurate and misleading results from the ping command.

Using Continuous ping for Extended Monitoring

In a real network, successful receipt of four ping packets does not guarantee a perfect connection. The result merely indicates that the connection was working during the test interval. However, certain network conditions, such as routing or switching reconvergence, can cause a periodic drop in the connection. For example, the drops might only occur once every 5 minutes but cause the user sessions to reset. The administrator might need to run the ping command for an extended period of time to detect such conditions. Refer to the output of the ping /? command in Example 2-1 for the option available for running the ping command for an extended period of time. This option, also shown in Example 2-1, is as follows:

   Options:       -t           Ping the specified host until stopped.                    To see statistics and continue - type Control-Break;                    To stop - type Control-C. 

To run a continuous ping command, use the t switch.

Press Ctrl-C to stop the command as needed and view the summary. Alternately, press Ctrl-Break to view the summary without stopping.

Example 2-5 shows the output of an extended ping command.

Example 2-5. Extended ping Command

 C:\WINDOWS\system32>ping -t 192.168.0.10 Pinging 192.168.0.10 with 32 bytes of data: Reply from 192.168.0.10: bytes=32 time=87ms TTL=255 Reply from 192.168.0.10: bytes=32 time=9ms TTL=255 Reply from 192.168.0.10: bytes=32 time=61ms TTL=255 Reply from 192.168.0.10: bytes=32 time=32ms TTL=255 Reply from 192.168.0.10: bytes=32 time=104ms TTL=255 Reply from 192.168.0.10: bytes=32 time=11ms TTL=255 Reply from 192.168.0.10: bytes=32 time=27ms TTL=255 Reply from 192.168.0.10: bytes=32 time=14ms TTL=255 Request timed out. Reply from 192.168.0.10: bytes=32 time=11ms TTL=255 Reply from 192.168.0.10: bytes=32 time=11ms TTL=255 Reply from 192.168.0.10: bytes=32 time=16ms TTL=255 Ping statistics for 192.168.0.10:     Packets: Sent = 12, Received = 11, Lost = 1 (8% loss), Approximate round trip times in milli-seconds:     Minimum = 9ms, Maximum = 104ms, Average = 34ms Control-Break (the user entered CNTRL-Break for summary)   Reply from 192.168.0.10: bytes=32 time=95ms TTL=255 Reply from 192.168.0.10: bytes=32 time=9ms TTL=255 Reply from 192.168.0.10: bytes=32 time=15ms TTL=255 Ping statistics for 192.168.0.10:     Packets: Sent = 15, Received = 14, Lost = 1 (6% loss), Approximate round trip times in milli-seconds:     Minimum = 9ms, Maximum = 104ms, Average = 35ms Control-C (the user entered CNTRL-C to stop)               ^C                                                         

As shown on line 10 of Example 2-5, the packet loss results in the Request timed out message. Also, lines 15-18 show the summary of the results with 1 packet lost [or 8 percent (100 * 1/12)]. The command output continues until the user presses Ctrl-C, which is shown in the highlighted text as ^C.

Using the ping Command for Name Resolution

On many occasions, an administrator needs to investigate a network issue to isolate a troublemaker's IP address when the administrator doesn't know the Domain Name System (DNS) name. For example, a host might be infected by a virus, or music files can be illegally shared by a host. The network traffic or syslog can indicate the IP address of the offending host, but not the DNS name.

The DNS name of a device can be resolved by pinging the IP address of the target host in conjunction with the a option, as shown in Example 2-6.

Example 2-6. Using the ping Command to Resolve Host Name

 C:\WINDOWS\system32>ping -a 192.168.0.10 Pinging Router-Dallas [192.168.0.10] with 32 bytes of data: Reply from 192.168.0.10: bytes=32 time=9ms TTL=255 Reply from 192.168.0.10: bytes=32 time=149ms TTL=255 Reply from 192.168.0.10: bytes=32 time=6ms TTL=255 Reply from 192.168.0.10: bytes=32 time=123ms TTL=255 Ping statistics for 192.168.0.10:     Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds:     Minimum = 6ms, Maximum = 149ms, Average = 71ms 

The first line of the output shows the host name of the device 192.168.0.10 as Router-Dallas.

Both the source and destination should be configured with valid DNS information for successful resolution of the host name to the IP address. If you can ping the device by its IP address but not by its host name, the problem is usually a missing or incorrect DNS entry.

Note

Only the MS-Windows-based ping command features the IP address-to-name resolution mechanism. On most other platforms, such as Linux, this feature is not included. Use the nslookup command in Windows or dig command in Linux to resolve the name of a remote device, given its IP address.

Using the Linux-Based ping Command

Almost all Linux distributions (various distributions of GNU/Linux using Linux kernels) come with a ping command. The command is similar to its Windows counterpart. To verify network connectivity from a Linux-based machine to a target host, follow these steps:

Step 1.	Start a command-line session.
Step 2.	Type the command ping hostname-or-IP-address and then press Enter.

Note

Unlike MS-Windows, commands in Linux are case-sensitive. PING is not the same as ping in Linux.

Example 2-7 shows the output of the ping command in Linux.

Example 2-7. Output of the ping Command in Linux

 netadmin@linuxbox:/$ ping usage: ping [-LRdfnqrv] [-c count] [-i wait] [-l preload]         [-p pattern] [-s packetsize] [-t ttl] [-I interface address] host 

Although the exact command output can vary according to the Linux distribution and version, Table 2-1 lists some of the options available for Debian Linux 3.0 and higher.

Table 2-1. Linux ping Options

Option	Description
-b	Allows pinging to a broadcast address.
-c number-of-packets	Specifies the number of ping packets to be sent.
-i seconds	Specifies the interval in seconds between sending each ping packet; the default is 1 second.
-I interface address	In the case of multiple interface addresses, specifies the source address used by the ping packet.
-M hint	Specifies Path MTU discovery; possible values are do (set DF bit) and dont (do not set DF bit). Useful when used in conjunction with -s options for isolating MTU issues.
-q	Suppresses output details and only displays summary.
-s data-bytes	Specifies the number of bytes of data; default is 56 bytes. Useful in conjunction with -M options in troubleshooting MTU-related issues.
-t ttl	Specifies the TTL.
-v	Displays details. Useful for overriding the default ping behavior to suppress output when replies are not being received.
-V	Only displays the version of the ping command; additional options are ignored.
-w seconds	Specifies the maximum interval in seconds, after which the ping command stops.
-W timeout-seconds	Specifies the timeout interval for each packet. If the reply is not received within the timeout period, the packet is assumed to be lost.

A Continuous ping Command for Basic Connectivity

The scenario in Figure 2-2 shows a Linux-based computer connected to the default gateway through an Ethernet network.

Figure 2-2. Network Setup for a Linux Computer

To verify the connectivity between these two machines, the administrator enters the following command on the Linux computer:

   ping router-dallas 

Example 2-8 shows the output of the session.

Example 2-8. Using the ping Command to Verify Connectivity

 netadmin@linuxbox:/$ ping router-dallas ping router-dallas (192.168.0.10): 56 data bytes 64 bytes from 192.168.0.10: icmp_seq=0 ttl=255 time=2.3 ms 64 bytes from 192.168.0.10: icmp_seq=5 ttl=255 time=2.3 ms 64 bytes from 192.168.0.10: icmp_seq=6 ttl=255 time=2.3 ms --- router-dallas192.168.0.10 ping statistics --- 7 packets transmitted, 3 packets received, 57% packet loss round-trip min/avg/max = 2.3/2.3/2.3 ms 

The first line shows that the IP address of the target Router-Dallas is 192.168.0.10.

The next three lines of the command output show the details of each packet as follows:

• 192.168.0.10 is the IP address of the target.

• The sequence number of each packet is denoted by icmp_seq, followed by an integer. The sequence number is useful for quickly identifying missing reply packets. With every instance of the ping command, the sequence number starts with 0 and is incremented for each packet.

• The round-trip time of the packets is measured in milliseconds (ms).

• The TimeToLive field is 255.

The output of the ping command shows that only the packets with sequence numbers 0, 5, and 6 were received. The packets with sequence numbers 1, 2, 3, and 4 are missing or lost. This is confirmed in the last two lines, which show the summary statistics. Of the 7 packets transmitted, only 3 were received. Also, the minimum, average, and maximum round-trip values are calculated based on the round-trip times of the received packets.

Using Limited ping for Basic Connectivity Testing

Unlike the Windows ping command, the default ping command in Linux continuously sends packets until it is interrupted by the administrator by pressing Ctrl-C. To avoid the default behavior and limit the maximum number of packets sent by ping command, you can use the -c option.

Example 2-9 shows the ping command using the -c 2 option for sending 2 packets to the target Router-Dallas.

Example 2-9. Using the ping Command to Verify Connectivity

 netadmin@linuxbox:/$ ping -c 2 router-dallas PING router-dallas192.168.0.10 (192.168.0.10): 56 data bytes 64 bytes from 192.168.0.10: icmp_seq=0 ttl=255 time=4.4 ms 64 bytes from 192.168.0.10: icmp_seq=1 ttl=255 time=2.2 ms --- router-dallas192.168.0.10 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 2.2/3.3/4.4 ms 

Using ping for MTU Testing

As discussed in the Windows-based ping section, ping can also determine the MTU of the network path between two nodes. To determine the MTU using the Linux-based ping command, use the -M option to set the DF bit and use the -s option to specify the data size.

Consider the scenario shown in Figure 2-2. The Netadmin is trying to determine the MTU between the 192.168.0.0/24 LAN and the web server 172.16.10.99. To determine the MTU, the Netadmin uses the ping -c 4 -M do -s 1273 172.16.10.99 command. The -c 4 option limits the count to only 4 ping packets. The -s 1273 option specifies 1273 bytes of data, while the -M do option sets the DF bit. As shown in Example 2-10, 0 packets were received. After reducing the data byte size to 1272, the replies are successfully received.

The actual MTU of the link is the sum of the payload size and the IP header size. Because Linux uses 28 bytes for the IP header of the ping packet, the MTU in this example is 1272 + 28 = 1300 bytes. Unlike the Windows ping command, which only shows the size of the data payload, the Linux version also shows the actual packet size.

Example 2-10. MTU Testing Using the Linux ping Command

 netadmin@linuxbox:/$ ping -c 4 -M do -s 1273 172.16.10.99 # Linux ping command also shows the actual size of IP packet             # The data payload is 1273 bytes, the total IP packet is 1301 bytes long PING 172.16.10.99 (172.16.10.99) 1273(1301) bytes of data. --- 172.16.10.99 ping statistics --- 4 packets transmitted, 0 received, 100% packet loss, time 3018ms  netadmin@linuxbox:/$ ping -c 4 -M do -s 1272 172.16.10.99  PING 172.16.10.99 (172.16.10.99) 1272(1300) bytes of data. 1280 bytes from 172.16.10.99: icmp_seq=1 ttl=124 time=32.9 ms 1280 bytes from 172.16.10.99: icmp_seq=2 ttl=124 time=24.5 ms 1280 bytes from 172.16.10.99: icmp_seq=3 ttl=124 time=25.6 ms 1280 bytes from 172.16.10.99: icmp_seq=4 ttl=124 time=29.5 ms --- 172.16.10.99 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss rtt min/avg/max = 24.592/28.189/32.940 ms 

Using the IOS-Based ping Command

The IOS ping command enables an Netadmin to quickly diagnose network issues from within the IOS shell. As a result, IOS-based ping is one of the most commonly used utilities. In addition to IP protocol, the Cisco IOS Software-based ping command also supports Apollo, AppleTalk, Clns, Decnet, IP, IPX, Vines, XNS, and so on. Cisco IOS offers the following two modes of the ping command:

• User mode

• Privileged mode

User Mode ping Command

The user mode ping command has the basic feature for users who do not have system privileges. This feature allows the Cisco IOS Software to perform the simple default ping functionality for a number of protocols, including IP, IPX, AppleTalk, and so on.

Note

Throughout this chapter and the book, the term IOS-based devices refers to the Cisco routers and switches that are loaded with Cisco IOS Software. Unless specified otherwise, the features and commands discussed should be available on Cisco IOS Release 12.0 and later.

To verify network connectivity from an IOS-based device to a target host, follow these steps:

Step 1.	Start a console or Telnet session to the IOS-based device and log in to the user mode using the username and password, if they are required.
Step 2.	Type the ping [protocol] {host | address} command and press Enter.

Table 2-2 lists the options available with the IOS ping command.

Table 2-2. IOS ping Options

Option	Description
protocol	(Optional) Specifies the protocol; possible keywords are apollo, appletalk, clns, decnet, ip, ipx, vines, and xns. The default is IP.
host	Host name of the target.
address	IP address of the target.

The scenario in Figure 2-3 depicts a regular user trying to verify the connectivity from the IOS device Router-Dallas to a website http://www.testwebsite.com.

Figure 2-3. Using the ping Command from an IOS Device

The user first initiates a Telnet session from the machine LINUXBOX to Router-Dallas to log in to the user EXEC mode.

From the user EXEC prompt (Router-Dallas>), the user issues a ping command from the router to the target host. The host name gets resolved to the IP address through the DNS server 192.168.0.15.

The captured session in Example 2-11 details the steps involved and the output of the IOS ping command.

Example 2-11. IOS ping Command

 spope@linuxbox:/$ telnet 192.168.0.10 Trying 192.168.0.10... Connected to 192.168.0.10. Escape character is '^]'. User Access Verification Password: Router-Dallas>ping www.testwebsite.com Translating "www.testwebsite.com"...domain server (192.168.0.15) [OK] Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.11.25, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 16/22/28 ms 

The last three lines of the output summarize the results of the IOS ping command. These lines show that the router sent 5 ICMP Echo packets of 100 bytes each to the IP address (172.16.11.25) of the target host. The timeout value for each packet was set to 2 seconds.

In other words, the packet would be treated as lost if no replies were received within 2 seconds.

In the summary line that shows five exclamation marks, each exclamation mark signifies a successful reply from the target. Depending on the state of the message received, the output can contain other test characters, as shown is Table 2-3. Recall that the output of the Windows/Linux ping command shows details of each packet. In contrast, the IOS shows only a single character for the result of the ICMP reply messages.

Table 2-3. Ping Test Characters

Character	Description
!	Each exclamation point indicates receipt of a reply.
. .	Each period indicates that the network server timed out while waiting for a reply.
U	Indicates a destination unreachable error.
C	Indicates that a congestion experienced packet was received.
I	Indicates that the user interrupted the test.
?	Indicates an unknown packet type.
&	Indicates that the packet lifetime was exceeded.

The last output line summarizes the success rate based on the total packets sent and received. Based on the round-trip times of the received packets, the minimum, average, and maximum round-trip times are also calculated.

Tip

The output of the ping command can be interrupted by pressing Ctrl-Shift-6 followed by pressing X.

Privileged Mode ping Command

As seen in the preceding section, the basic IOS ping command is limited in terms of available options. Some of the default parameters used by the ping command are as follows:

• Packet count of 5

• Packet size of 100 bytes

• Timeout value of 2 seconds

• Outgoing interface as the source address of the packets

The IOS ping command in privileged EXEC mode provides customizable options, as shown in Table 2-4.

Table 2-4. Enhanced ping Options

Field	Description
Protocol [ip]:	Specifies one of the supported protocols; choices are appletalk, clns, ip, novell, apollo, vines, decnet, and xns. Default: ip.
Target IP address:	Prompts for the IP address or host name of the destination node that you plan to ping. If you have specified a supported protocol other than IP, enter an appropriate address for that protocol here. Default: none.
Repeat count [5]:	Number of ping packets that are to be sent to the destination address. Useful for pinging with large numbers of packets. Default: 5.
Datagram size [100]:	Size of the ping packet (in bytes). Useful in diagnosing slower link issues by specifying a larger packet size. Also handy in isolating MTU-related issues when used in conjunction with the DF option. Default: 100. In contrast, the Windows and Linux counterparts only let you specify the size of the payload.
Timeout in seconds [2]:	Timeout interval (in seconds). The ping is declared successful only if the Echo Reply packet is received before this time interval. Useful in diagnosing slower links. Default: 2.
Extended commands [n]:	Specifies whether a series of additional commands appears. Default: no.
Source address or interface:	The interface or IP address of the router to use as a source address for the probes. The router normally picks the IP address of the outbound interface to use. The interface might also be mentioned, but with the correct syntax, as follows: Source address or interface: ethernet 0 Useful for diagnosing connectivity issues related to routing misconfiguration on hosts and routers.
Type of service [0]:	Specifies the type of service (ToS). The requested ToS is placed in each probe, but there is no guarantee that all routers can process the ToS. Default: 0.
Set DF bit in IP header? [no]:	Specifies setting the Don't Fragment (DF) bit on the ping packet. If set to yes, the DF option prevents fragmentation when the packet has to go through a segment with a smaller maximum transmission unit (MTU); you receive an error message from the device that wanted to fragment the packet. This is useful for determining the smallest MTU in the path to a destination. Handy in isolating MTU-related issues through VPN tunnels. Default: no.
Validate reply data? [no]:	Specifies whether to validate the reply data. Default: no.
Data pattern [0xABCD]	Specifies the data pattern. Different data patterns can troubleshoot line coding such as AMI or B8ZS, framing errors, and clocking problems on serial lines. Default: 0xABCD.
Loose, Strict, Record, Timestamp, Verbose[none]:	IP header options. This prompt offers the following options: Verbose Automatically selected along with any other option. Record Displays the addresses of the hops (up to nine) that the packet goes through. Loose Allows you to influence the path by specifying the addresses of the hops that you want the packet to go through. Strict Specifies the hops that you want the packet to go through, but no other hops are allowed to be visited. Timestamp Measures the round-trip time to particular hosts. The difference between using the Record option of this command and using the traceroute command is that the Record option not only informs you of the hops that the Echo Request (ping) went through to get to the destination, but it also informs you of the hops it visited on the return path. With the traceroute command, you do not get information about the path that the Echo Reply takes. The traceroute command issues prompts for the required fields. Note that the traceroute command places the requested options in each probe; however, there is no guarantee that all routers (or end nodes) can process the options. Default: none.
Sweep range of sizes [n]:	Allows you to vary the sizes of the Echo packets being sent. This determines the minimum sizes of the MTUs configured on the nodes along the path to the destination address. Performance problems caused by packet fragmentation are thus reduced. Default: no.

The steps involved in initiating a privileged EXEC mode ping command are as follows:

Step 1.	Start a console or Telnet session to the IOS-based device and log in to the privileged EXEC mode using the appropriate username and password. (Privileged EXEC mode can be identified by the pound sign (#) in the prompt. Router# indicates privileged EXEC mode, while Router> indicates user EXEC mode.)
Step 2.	Type the ping command and press Enter. Follow the prompts and enter suitable information for each field. For an explanation of each field, refer to Table 2-2.

Consider the scenario in Figure 2-4 in which all the users in the subnet 192.168.0.0/24 are not able to connect to server 172.16.11.50.

Figure 2-4. Ping from IOS Device

Console (or Telnet) into Router-Dallas for troubleshooting. The steps involved in identifying and solving the network issue are as follows:

Step 1.	Ping to the other end of serial link Check the serial link between routers, using the ping 10.1.1.1 command. As shown in Example 2-12, the ping replies are received successfully, thus eliminating serial line issues.
Step 2.	Ping the remote server Check the Ethernet connectivity of the remote server using the ping 172.16.11.50 command. Again, as shown in Example 2-12, the successful receipt of ping replies eliminates Ethernet connectivity issues between the remote server and the remote router.
Step 3.	Extended ping to the remote server Ping the remote server (172.16.11.50) using the source address (192.168.0.10) of the Ethernet interface of Router-Dallas. By default the router will use the source address of the outgoing interface for the ping packet. To specify the use of a source address other than the default, use the extended version of the ping command, as shown in Example 2-12. The extended ping can verify the connectivity and reveal routing issues between the 172.16.11.0/24 and 192.168.0.0/24 LANs. As shown in the last part of Example 2-12, no packets are being received, indicating connectivity failure between the two LANs. Also note that the extended ping in this example is using 10 packets instead of the default. Using a larger number of packets provides monitoring over a longer period of time.

Failure of the extended ping in Step 3 indicates that Router-NewYork is not aware of the route to the 192.168.0.0/24 LAN. This is confirmed by the output of the show ip route 192.168.0.0 command on Router-NewYork. After adding the static route for the 192.168.0.0/24 network on Router-NewYork, the extended ping, from the Ethernet interface of Router-Dallas to the remote server, succeeds. The users from the 192.168.0.0/24 LAN can now access the 172.16.11.50 server, and the issue is resolved.

Example 2-12. Enhanced ping Session

 !Ping to the other end of serial link                                                Route-dallas#ping 10.1.1.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms !Ping to the remote server                                                            Route-dallas#ping 172.16.11.50 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 172.16.11.50, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms ! Extended ping to the remote server using the IP address of ethernet interface      ! as the source address for the ping packets                                          Route-dallas#ping Protocol [ip]: Target IP address: 172.16.11.50 ! Specify 10 packets instead of default 5                                            Repeat count [5]: 10 Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y ! You can also enter name of the interface "ethernet0"                               Source address or interface: 192.168.0.10 Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 10, 100-byte ICMP Echos to 172.16.11.50, timeout is 2 seconds: .......... Success rate is 0 percent (0/10) !Check the route to the 192.168.0.0/24 network on the remote router - Router-newyork Router-newyork#show ip route 192.168.0.0 % Network not in table !Add the route for 192.168.0.0/24 network on Router-newyork                          Router-newyork#config terminal Enter configuration commands, one per line. End with CNTL/Z. Router-newyork(config)#ip route 192.168.0.0 255.255.255.0 10.1.1.2 Router-newyork(config)#end !Check the added route on Router-newyork                                             Router-newyork#show ip route 192.168.0.0 Routing entry for 192.168.0.0/24   Known via "static", distance 1, metric 0   Routing Descriptor Blocks:   * 10.1.1.2       Route metric is 0, traffic share count is 1 ! Extended ping to check again, this time the replies are received successfully     Router-Dallas# ping Protocol [ip]: Target IP address: 172.16.11.50 Repeat count [5]: 10 Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: y Source address or interface: 192.168.0.10 Type of service [0]: Set DF bit in IP header? [no]: Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 10, 1600-byte ICMP Echos to 172.16.11.50, timeout is 2 seconds: !!!!!!!!!! Success rate is 100 percent (10/10), round-trip min/avg/max = 8/8/12 ms 

Continuous ping

As observed in the preceding examples, a continuous ping is handy for network administrators, but the IOS-based ping lacks this feature. A suggested workaround is to use a high value for the Repeat count parameter. Example 2-13 shows an IOS ping with a Repeat count of 9999999. (The output in Example 2-13 has been truncated for illustration purposes.)

Example 2-13. Continuous ping Session

 Router-Dallas#ping Protocol [ip]: Target IP address: 192.168.0.1 Repeat count [5]: 9999999 Datagram size [100]: Timeout in seconds [2]: Extended commands [n]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 9999999, 100-byte ICMP Echos to 192.168.0.1, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! ------ Truncated output ----- 

Using ping for MTU Testing

The extended ping command in IOS also provides the ability to set the DF bit and use a larger packet size. As discussed in the Windows and Linux ping sections, these features are handy when determining the MTU for a network link.

Example 2-14 shows the capture of an extended ping command on Router-Dallas. The first half of the example shows an extended ping command using the packet size of 1301 bytes. The command fails because 0 packets are received. The second half of the example uses the packet size of 1300 bytes. The replies are received successfully. Hence, the MTU value for the link between Router-Dallas and the web server 172.16.10.99 is 1300 bytes.

Example 2-14. IOS Extended ping Command MTU Testing

 ! Extended ping with the IP packet size of 1301 bytes                  Router-Dallas# ping Protocol [ip]: Target IP address: 172.16.10.99 Repeat count [5]: Datagram size [100]: 1301 Timeout in seconds [2]: Extended commands [n]: y Source address or interface: Type of service [0]: Set DF bit in IP header? [no]: yes Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5, 1301-byte ICMP Echos to 172.16.10.99, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) ! Extended ping with the IP packet size of 1300 bytes                  Router-Dallas# ping Protocol [ip]: Target IP address: 172.16.10.99 Repeat count [5]: Datagram size [100]: 1300 Timeout in seconds [2]: Extended commands [n]: y Source address or interface: Type of service [0]: Set DF bit in IP header? [no]: yes Validate reply data? [no]: Data pattern [0xABCD]: Loose, Strict, Record, Timestamp, Verbose[none]: Sweep range of sizes [n]: Type escape sequence to abort. Sending 5, 1300-byte ICMP Echos to 172.16.10.99, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 24/28/32 ms Router-Dallas# 

Note

To enable the IOS device to ping by name, use the ip name-server IP-address-of-DNS-Server command.

Use the no ip directed-broadcast command to prevent the ICMP flooding attack that results when a ping is sent to a network address. The DDoS attacks, such as Smurf, use the directed broadcast of ICMP packets to flood the target network with broadcast replies. Cisco.com provides more information in the article "Characterizing and Tracing Packet Floods Using Cisco Routers." The URL is as follows:

http://www.cisco.com/en/US/tech/tk59/technologies_tech_note09186a0080149ad6.shtml

Other Cisco products, including PIX Firewall, VPN concentrators, CatOS-based Catalyst switches, Content switches, and so on, also provide the ping command. However, they do not offer as many options as are provided by IOS.

Other OS-Based Variations of ping

Encouraged by the utility and popularity of the ping tool, many variations and clones of the tool were created. Some are commercial versions with a GUI, whereas others were developed by the hacker community for reconnaissance purposes. Several popular ping variations are as follows:

• fping

• hping

• SmokePing

fping

Whereas the ping tool can only test one host at a time, fping can test multiple hosts simultaneously. The hosts can be either specified through the command line or listed in a text file. This is useful for administrators who want to quickly diagnose network connectivity issues. Fping, which is Linux-based, provides a fast response and is suitable for use in scripts. You can download and install fping from http://www.fping.com.

hping

The original ping tool uses ICMP Echo Requests. Hping provides additional capability to use TCP, UDP, ICMP, and RAW-IP for testing remote host connectivity. The ability to use TCP or UDP is useful in verifying connectivity, even if router and firewall ACLs are blocking ICMP traffic. Hping is a command-line-based Linux tool that provides additional features. You can download and install hping from http://www.hping.org/.

SmokePing

SmokePing provides a continuous output of latency, latency distribution, and packet loss in the network. It can provide detailed graphic records of network performance over extended periods of time. You can download and install SmokePing from http://people.ee.ethz.ch/~oetiker/webtools/smokeping/.

Network Troubleshooting Steps Using ping

Even the most seasoned network engineers often do not use the humble ping command to its full potential. When contacted with a connectivity issue with a target host, the first reaction is to ping it from the source address. This, of course, fails because the network is down. To quickly isolate network issues, follow these steps:

Step 1.	Ping the loopback address, if any, of the source device. A successful reply confirms that the local TCP/IP stack is in good shape. Windows and Linux machines use 127.0.0.1 as the loopback address. If this step fails, the issue is with the local device's operating system or the TCP/IP stack.
Step 2.	Ping the external network interface of the source device. This confirms the working of both the physical link and the TCP/IP protocol on that device. If this step fails, the issue is with the network interface or the connecting cable.
Step 3.	Ping the default gateway of the source device. This confirms that the basic connectivity and routing works between the source device and the default gateway. If this step fails, the issue is either with the IP configuration of the host or the default gateway or the connectivity between the source host and default gateway.
Step 4.	Ping the destination device to confirm network connectivity. If this step fails, the issue is between the default gateway and the target host.

Figure 2-5 depicts the troubleshooting steps using the ping command.

Figure 2-5. Troubleshooting Using the ping Command

Verifying Network Connectivity Using traceroute

Traceroute, as the name suggests, allows you to trace the route or the path traversed by the data packets from the source to the destination. It also records the latency of each intermediate hop. While ping can only report connectivity to a target host, traceroute helps to pinpoint the node, within that path, that is causing network issues. The tool was written by Van Jacobson in 1988 at the Lawrence Berkeley National Laboratory.

IP packets have a TTL field for preventing routing loops. The TTL field limits the life of the IP packet in terms of hops. The TTL value can be an integer between 0 and 255. On receiving an IP packet, the router decrements the TTL value of the packet by 1. The router then uses the modified IP header for routing the packet. However, if the TTL value of the packet is 0, the router discards the IP packet and sends an ICMP type 11 Time exceeded message back to the sender. Traceroute uses this property and sends the first packets with TTL = 1. As soon as the packet reaches the first router, the TTL decrements to 0 and the router sends a Time exceeded message back to the source. Traceroute then sends another packet with TTL = 2, causing the second router in the path to send the Time exceeded message back. This process is repeated until the destination is reached and all the intermediate hops are recorded.

Traceroute is a client-based tool because no installation is required on the target node. It is preinstalled with most operating systems. This section discusses the most common traceroute implementations used by the network administrator, which are as follows:

• MS-Windows-based tracert command

• Linux-based traceroute command

• IOS-based traceroute command

Using the MS-Windows-Based tracert Command

The tracert command is preinstalled with versions Windows 95 and higher of MS-Windows in the form of tracert.exe. Tracert determines the path taken to a destination by sending ICMP Echo Request messages to the destination with incrementally increasing TTL field values.

To use the tracert tool to trace the network path from an MS-Windows 95/98/Me/NT/2000/ XP based machine to a target host, follow these steps:

Step 1.	Open the command-line session by choosing Start > Programs > MS-DOS Prompt.
Step 2.	Type the command tracert <hostname-or-ip-address> and press Enter.

The tracert /? command on Windows machines provides information on the usage of the tracert command. Example 2-15 shows the output of the tracert /? command in Windows XP. The output can be slightly different in other versions of Windows. However, the options discussed in this chapter are applicable to all versions of Windows.

Example 2-15. Output of the tracert Command

 C:\WINDOWS\system32>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. 

Using tracert for Basic Tracing

The scenario in Figure 2-6 shows an Ethernet network connecting a Windows-based computer to a network with host http://www.testwebsite.com (172.16.17.71).

Figure 2-6. MS-Windows Based tracert

To determine the network path between a Windows machine and the target (http://www.testwebsite.com), the administrator enters the following command on the Windows computer:

   tracert 172.16.17.71 

Example 2-16 shows the output of the session.

Example 2-16. Windows-Based traceroute - Using tracert Command

 C:\WINDOWS\system32>tracert 172.16.17.71 Tracing route to www.testwebsite.com [172.16.17.71] over a maximum of 30 hops:   1     2 ms     2 ms     2 ms  192.168.0.1   2    15 ms     9 ms    14 ms  10.10.248.1   3    46 ms    15 ms    15 ms  gw-003.mynet.net [172.16.13.150]   4    235 ms  256 ms   262 ms  www.testwebsite.com [172.16.17.71] Trace complete. 

The first line in Example 2-16 shows the command itself.

The next two lines show that tracert has resolved the DNS name of the target (http://www.testwebsite.com) and is trying to trace the route with a limit set to 30 hops.

The next four lines are the hop-by-hop trace of the path to the destination. Each line has 3-ms entries followed by a host name or IP address. The ms entries are the round-trip time for the three ICMP Echo Request probes sent by the Windows machine. The host name or IP address belongs to the node that replied to these probes.

The round-trip time for each hop is helpful in isolating latency issues. Considering the output in Example 2-16, the first three hops have faster response times. The last hop has an unusually slow round-trip time of 235 ms. This indicates a slower link between the nodes 172.16.13.150 and 172.16.17.71.

Inaccurate Results of the tracert Command

Although the round-trip values provide clues to the latency and network issues, the results might not always be accurate.

The routers are sometimes configured to assign higher priority to the data traffic and lower priority to ICMP packets. Some routers do not return Time exceeded messages. Many Internet service providers (ISP) block ICMP packets. All these factors can result in high round-trip-time values or even timeouts. This can lead to some confusion regarding network connectivity. Exercise caution before jumping to "network unreachable" conclusions.

Using the Linux-Based traceroute Command

Almost all Linux distributions come with the traceroute command. The Linux implementation of traceroute uses UDP datagrams to determine the network path. This is in contrast with the Windows tracert command, which uses ICMP Echo Requests. Most of the Linux and UNIX implementations of traceroute use UDP port 33434 for sending the first packet. Subsequent packets use incrementing port numbers. Using different ports numbers eliminates false results if one particular port is blocked. Higher port numbers are used to minimize possible conflicts with other services or applications.

Figure 2-7 provides packet-by-packet details for a traceroute session from a Linux host with IP address IP-a to a destination host with IP address IP-e. The two hosts are connected through a network consisting of Routers B, C, and D, with the IP addresses as shown. You should assume that routing between the two hosts is working properly.

Figure 2-7. Linux traceroute Mechanism

The command traceroute 2.2.2.2 (assuming that IP-e = 2.2.2.2) is issued on the Linux machine shown in Figure 2-7. As a result, the Linux machine sends three probes to its default gateway. The probe consists of 3 separate UDP packets, each with TTL = 1. Also, note the incrementing destination UDP port number for each packet. The 3 packets reach Router B, which decrements the TTL value by 1, resulting in the new TTL = 0. Router B then sends three replies to the sender (host A) with an ICMP Time exceeded message denoted by ICMP type=11, code=0.

The next probe from host A consists of 3 packets, each with TTL = 2. These packets cross Router B, which decrements the new TTL = 1. After reaching Router C, the TTL = 0. This causes Router C to reply to host A with the ICMP Time exceeded message.

This process continues for each intermediate hop until the probe packets reach their target host E. Host E also decrements the TTL to 0. However, instead of sending the ICMP Time exceeded message, host E sends back the Destination unreachable, Port unreachable message.

To trace the network path from a Linux-based machine to a target host, follow these steps:

Step 1.	Start a command-line session on the Linux machine.
Step 2.	Type the command traceroute hostname-or-IP-address and press Enter.

Table 2-5 lists some of the options offered by the Linux traceroute command. Note that the options can vary slightly with each Linux distribution.

Table 2-5. Linux traceroute Options

Option	Description
-i interface	Specifies a network interface whose source IP address is to be used for outgoing probe packets; useful on a multihomed host.
-f integer	Specifies the initial TTL for the first outgoing probe packet; useful for skipping the first few hops, which are generally part of the internal network.
-I	Uses ICMP Echo Requests instead of UDP datagrams.
-m number-of-hops	Specifies the maximum number of hops; default is 30.
-n	Disables the DNS lookup for the host name; useful for faster output.
-p UDP-port-number	Specifies the base UDP port number; default is 33434.
-s ip-address	Specifies the source IP address for the probe packets; default is that of the outgoing interface; similar to the -i interface option.
-w seconds	Specifies the timeout period, in seconds, for waiting for a reply; default is 5.
-z milliseconds	Specify the time to wait, in milliseconds, between successive probes; default is 0. This option is useful when edge routers or firewalls enforce an ICMP rate limit.

To display the network path between a Linux machine running traceroute and the target (http://www.cisco.com), issue the traceroute www.cisco.com command on the Linux machine.

Example 2-17 shows the output of the traceroute session.

Example 2-17. Linux-Based traceroute Command

 spope@linuxbox:~# traceroute www.cisco.com traceroute to www.cisco.com (198.133.219.25), 30 hops max, 38 byte packets  1  192.168.0.1 (192.168.0.1)  0.711 ms  0.280 ms  0.654 ms  2  10.146.248.1 (10.146.248.1)  11.183 ms  7.978 ms  5.343 ms  3  12.244.97.161 (12.244.97.161)  10.734 ms  8.362 ms  43.133 ms  4  12.244.67.78 (12.244.67.78)  9.967 ms  9.917 ms  7.017 ms  5  12.244.67.82 (12.244.67.82)  12.559 ms  11.380 ms  9.722 ms  6  12.127.32.17 (12.127.32.17)  118.244 ms  *  115.079 ms  7  tbr2-p013701.sffca.ip.att.net (12.123.13.177)  6.574 ms  16.656 ms  16.359 ms  8  gbr5-p20.sffca.ip.att.net (12.122.11.90)  16.435 ms  14.334 ms  14.892 ms  9  gar1-p360.sj2ca.ip.att.net (12.122.2.253)  6.211 ms  10.122 ms  22.096 ms 10  12.127.200.82 (12.127.200.82)  17.115 ms  23.219 ms  15.543 ms 11  sjce-dmzbb-gw1.cisco.com (128.107.239.53)  18.284 ms  24.111 ms  15.808 ms 12  sjck-dmzdc-gw1.cisco.com (128.107.224.69)  15.716 ms  16.968 ms  15.798 ms 13  www.cisco.com (198.133.219.25)  16.133 ms  22.774 ms  15.927 ms 

Interpreting the Output of traceroute

As shown is the first line of Example 2-17, the host name is resolved to the IP address; the maximum number of hops is set to 30, and the packet size is 38 bytes. The next 13 lines (beginning with line 1) represent the response from each intermediate hop. Each row shows the IP addresses with the round-trip time for the 3 probe packets.

As highlighted, the round-trip times in line 6 have an asterisk (*), indicating a timeout. Also, note the high round-trip-time values of 118.244 ms and 115.079 ms. These times indicate congestion or a slower link between hops 12.244.67.82 and 12.127.32.17.

Some of the lines also show the host name along with the IP address. Traceroute responds faster if the name resolution is suppressed by using the n switch. Example 2-18 shows the output of the traceroute -n command. The output shows only the IP addresses with the round-trip time for each hop.

Example 2-18. Traceroute Command with the n Option

 spope@linuxbox:~# traceroute -n www.cisco.com traceroute to www.cisco.com (198.133.219.25), 30 hops max, 38 byte packets  1  192.168.0.1  0.585 ms  0.745 ms  0.490 ms  2  10.146.248.1  19.304 ms  14.632 ms  7.667 ms  3  12.244.97.161  7.553 ms  13.108 ms  9.600 ms  4  12.244.67.78  7.218 ms  7.757 ms  11.274 ms  5  12.244.67.82  8.103 ms  10.044 ms  8.176 ms  6  12.127.32.17  14.589 ms  15.468 ms  23.110 ms  7  12.123.13.177  11.225 ms  22.109 ms  15.973 ms  8  12.122.11.90  11.825 ms  17.520 ms  13.860 ms  9  12.122.2.253  8.550 ms  22.518 ms  14.165 ms 10  12.127.200.82  13.215 ms  19.282 ms  20.061 ms 11  128.107.239.53  10.584 ms  21.665 ms  19.873 ms 12  128.107.224.69  8.385 ms  23.932 ms  18.562 ms 13  198.133.219.25  8.307 ms  24.625 ms  15.269 ms 

traceroute Fails Even If the Host Is Up

By default, the Linux implementation of traceroute sends UDP probe messages. Many devices might not respond to the UDP probe packets causing traceroute to produce inconclusive results. Example 2-19 shows output of traceroute command with the packets timing out (indicated by the *) after the first probe; however, as verified by the ping www.testsite.net command, the target host is not down.

Example 2-19. Failure of traceroute command

 spope@linuxbox:~$ traceroute www.testsite.net traceroute to www.testsite.net (208.36.86.73), 30 hops max, 38 byte packets  1 192.168.0.1  (192.168.0.1)  1.139 ms  0.578 ms  0.716 ms  2 * * *  3 * * * ...output truncated for clarity ... 29 * * * 30 * * * spope@linuxbox:~$ ping www.testsite.net PING www.testsite.net (208.36.86.73): 56 data bytes 64 bytes from 208.36.86.73: icmp_seq=0 ttl=39 time=90.8 ms 64 bytes from 208.36.86.73: icmp_seq=1 ttl=39 time=92.3 ms --- www.testsite.net ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 90.8/91.5/92.3 ms 

In such cases, you can instruct the traceroute command to use ICMP probes. To trace the path to the target host with ICMP probes instead of the default UDP probes, use the traceroute I www.testsite.net command, as shown in Example 2-20. The traceroute succeeds, with replies from all the intermediate hosts.

Example 2-20. Traceroute Command with the I Option

 spope@linuxbox:~$ traceroute -I www.testsite.net traceroute to www.testsite.net (208.36.86.73), 30 hops max, 38 byte packets  1  192.168.0.1 (192.168.0.1)  0.641 ms  0.664 ms  0.669 ms  2  10.146.248.1 (10.146.248.1)  16.911 ms  7.878 ms  8.369 ms  3  12.244.97.161 (12.244.97.161)  11.852 ms  11.654 ms  9.779 ms  4  12.244.67.78 (12.244.67.78)  9.756 ms  9.096 ms  11.050 ms  5  12.244.67.82 (12.244.67.82)  8.736 ms  10.687 ms  9.545 ms  6  12.127.33.73 (12.127.33.73)  13.233 ms  13.154 ms  14.174 ms  7  gbr5-p30.sffca.ip.att.net (12.123.13.158)  14.943 ms  15.044 ms  15.444 ms  8  tbr2-p013501.sffca.ip.att.net (12.122.11.89)  15.591 ms  33.922 ms  15.357 ms  9  ggr2-p390.sffca.ip.att.net (12.123.13.194)  19.458 ms  14.896 ms  14.707 ms 10  att-gw.sfo.qwest.net (192.205.32.82)  14.727 ms  15.670 ms  20.539 ms 11  svx-core-02.inet.qwest.net (205.171.214.137)  15.686 ms  14.283 ms  16.360 ms 12  svl-core-03.inet.qwest.net (205.171.14.81)  18.843 ms  16.833 ms  16.095 ms 13  svl-core-01.inet.qwest.net (205.171.14.121)  16.340 ms  31.363 ms  15.966 ms 14  iah-core-01.inet.qwest.net (205.171.8.130)  55.004 ms  56.289 ms  56.105 ms 15  * tpa-core-02.inet.qwest.net (205.171.5.105)  79.213 ms  77.061 ms 16  nap-edge-01.inet.qwest.net (205.171.27.174)  96.872 ms  106.207 ms  107.447 ms 17  65.124.216.54 (65.124.216.54)  91.313 ms  88.074 ms  86.725 ms 18  ftl-core1a-v6.valueweb.com (216.219.251.33)  85.303 ms  135.629 ms  312.926ms 19  208-36-86-73.www.testsite.net (208.36.86.73)  84.526 ms  84.339 ms  85.381 ms 

Tip

To avoid using copy and paste to record the output of the ping and the traceroute command, use the output redirector >. The format is command > filename. This works for both Linux and Windows operating systems.

For example, the ping 10.10.10.10 > test1.txt command redirects the output of the ping command to the file test1.txt.

To append the output without erasing the original file, use the following code (note the two redirector signs):

      command >> filename 

For example, the ping 10.10.10.10 >> test1.txt command redirects the output of the ping command to test1.txt without overwriting the existing contents of the file.

Using the IOS-Based traceroute Command

While the Linux- and Windows-based traceroute command support IP, the IOS-based traceroute command supports AppleTalk, Clns, IP, and Vines. Traceroute is supported in Cisco IOS Release 10.0 and higher. Cisco IOS offers the following two modes of the traceroute command:

• User mode

• Privileged mode

User Mode traceroute Command

The user mode traceroute command has a basic feature for users who do not have system privileges. This feature allows the Cisco IOS Software to perform the simple default traceroute functionality without knowing privilege-level passwords.

To determine the network path from an IOS-based device to a target host, follow these steps:

Step 1.

Start a console or Telnet session to the IOS-based device and log in to the user mode using applicable authentication information.

Step 2.

Type the command traceroute [protocol] destination and press Enter. Optionally, try using the traceroute ? command to find available options. Table 2-6 explains each of the command options.

Table 2-6. IOS traceroute Options

Option	Description
protocol	(Optional) Protocol keyword; one of the following: apollo, appletalk, clns, ip, vines, novell, decnet, or xns
destination	Host name or IP address of the target

The scenario in Figure 2-8 depicts a regular user trying to determine the network path from the IOS device Router-Dallas to the website http://www.cisco.com.

Figure 2-8. Traceroute from an IOS Device

The user first initiates a Telnet session from the machine LINUXBOX to Router-Dallas to log in to the user EXEC mode. From the user EXEC prompt (Router-Dallas>), the user issues the traceroute www.cisco.com command. The host name gets resolved to the IP address through the DNS server 192.168.0.15. The captured session in Example 2-21 details the steps involved and the output of the IOS traceroute command.

Example 2-21. IOS traceroute Command

 spope@linuxbox:/$ telnet 192.168.0.10 Trying 192.168.0.10... Connected to 192.168.0.10. Escape character is '^]'. User Access Verification Password: Router-Dallas>traceroute www.cisco.com  Translating "www.cisco.com"...domain server (192.168.0.15) [OK]  Type escape sequence to abort.  Tracing the route to www.cisco.com (198.133.219.25)    1 ge5-3-0d4.RR2.-TX.us.wwt.net (65.106.2.49) 0 msec 4 msec 0 msec      2 p1-0.IR1.s2-TX.us.wwt.net (65.106.4.186) 4 msec 0 msec 4 msec        3 206.111.5.26.ptr.us.weo.net (206.11.5.26) 8 msec 4 msec 4 msec       4 tbr1-p01.dlx.ip.asrpt.net (12.23.16.242) 0 msec 4 msec 4 msec        5 tbr1-cl2.l2a.ip.spr.net (12.12.10.50) 36 msec 40 msec 40 msec        6 gar1-p370.sj2ca.ip.swet.net (12.12.2.249) 48 msec 44 msec 44 msec    7 12.12.200.82 44 msec 48 msec 44 msec                                 8 sjck-dm-gw1.cisco.com (128.10.239.9) 44 msec 44 msec 44 msec         9 www.cisco.com (198.133.219.25) 44 msec 44 msec 44 msec            

The output is similar to the output of the Linux traceroute command. The destination website, http://www.cisco.com, is nine hops away from the host. The output lists each of the hops by the IP address. The output also resolves the DNS name of each hop. However, only the IP address of the seventh hop is listed. The host 12.12.200.82 is most likely not configured with a name server. After the IP address of each hop, the command lists numeric values in milliseconds (msec). These are the round-trip reply times for the probe packets sent to each hop. By default, traceroute sends 3 probe packets to each hop. Hence, each output line shows three values in msec. Instead of an integer, the * character indicates no reply or timeout.

Tip

The output of the traceroute command can be interrupted by pressing Ctrl-Shift-6 followed by pressing X.

Privileged Mode traceroute Command

As seen in the preceding section, the basic IOS traceroute command is not very flexible. It also uses default parameters that the user cannot change. These parameters are as follows:

• Probe count of 3

• UDP port number 33434

• Timeout value of 3 seconds

• Outgoing interface as the source address of the packets

The IOS traceroute command in the privileged EXEC mode provides customizable options, as shown is Table 2-7.

Table 2-7. Enhanced traceroute Options

Field	Description
Target IP address	Specifies the IP address of the target host.
Source address	Specifies one of the interface addresses of the router to be used as the source address; by default, the router uses the IP address of the outgoing interface.
Numeric display [n]	The default is to have both a symbolic and a numeric display; however, you can suppress the symbolic display. The default is no.
Timeout in seconds [3]	The number of seconds to wait for a response from a probe packet. The default is 3.
Probe count [3]	The number of probes to be sent at each TTL level. The default is 3.
Minimum Time to Live [1]	The TTL value for the first probe. The default is 1, but it can be set to a higher value to suppress the display of known hops.
Maximum Time to Live [30]	The largest TTL value that can be used. The default is 30. The traceroute command terminates when the destination is reached or when this value is reached.
Port Number [33434]	The destination port used by the UDP probe messages. The default is 33434.
Loose, Strict, Record, Timestamp, Verbose [none]	IP header options. You can specify any combination. The traceroute command issues prompts for the required fields. Note that traceroute places the requested options in each probe; however, there is no guarantee that all routers (or end nodes) can process the options. These options are as follows: Loose Allows you to specify a list of nodes that must be traversed when going to the destination. Strict Allows you to specify a list of nodes that must be the only nodes traversed when going to the destination. Record Specifies the number of hops. Timestamp Specifies the number of time stamps. Verbose If you select any option, the verbose mode is automatically selected and traceroute prints the contents of the option field in incoming packets. Y.ou can prevent verbose mode by selecting it again, toggling its current setting.

The steps involved in initiating a privileged EXEC mode traceroute command are as follows:

Step 1.	Start a console or Telnet session to the IOS-based device and log in to the privileged EXEC mode using the appropriate username and password. (Privileged EXEC mode can be identified by the # [pound sign] in the prompt. Router# indicates privileged EXEC mode, while Router> indicates user EXEC mode.)
Step 2.	Type the command traceroute and press Enter. Follow the prompts and enter suitable information for each field. For an explanation of each field, refer to Table 2-7.

Example 2-22 illustrates the enhanced traceroute command with an Ethernet interface (192.168.0.10) as the source address of the traceroute packets. Also, the command sends 2 packets with a default timeout value of 3 seconds. The probe packets are using UDP port 24 instead of the default 33434.

Example 2-22. Enhanced traceroute Session

 Router-Dallas# traceroute Protocol [ip]: Target IP address: www.cisco.com Source address: 192.168.0.10 Numeric display [n]: n Timeout in seconds [3]: ! Specify only 2 probe packets to be sent to each hop Probe count [3]:2 Minimum Time to Live [1]: Maximum Time to Live [30]: Port Number [33434]:24 Loose, Strict, Record, Timestamp, Verbose[none]: Type escape sequence to abort. Tracing the route to 198.133.219.25    1 ge5-3-0d4.RAR2.dallas-TX.us.xo.net (65.106.2.49) 8 msec 0 msec    2 p1-0.IR1.dallas2-TX.us.xo.net (65.106.4.186) 4 msec 4 msec    3 206.111.5.26.ptr.us.xo.net (206.111.5.26) 4 msec 4 msec    4 tbr1-p012201.dlstx.ip.att.net (12.123.16.242) 4 msec 4 msec    5 tbr1-cl2.la2ca.ip.att.net (12.122.10.50) 40 msec 36 msec    6 gar1-p370.sj2ca.ip.att.net (12.122.2.249) 44 msec 44 msec    7 12.127.200.82 48 msec 48 msec    8 sjck-dmzbb-gw1.cisco.com (128.107.239.9) 44 msec 44 msec    9 www.cisco.com (198.133.219.25) 44 msec 44 msec 

Note that for each hop, the output only indicates two values in milliseconds. This is the desired behavior because only 2 probe packets per hop are specified in the extended traceroute command.