Using ping, tracert, and system debugging· 1

Ping· 1

Using a ping command to test network connectivity· 1

Ping example· 1

Tracert 3

Prerequisites 4

Using a tracert command to identify failed or all nodes in a path· 5

System debugging· 5

Debugging information control switches 5

Debugging a feature module· 6

Ping and tracert example· 7

Use the ping, tracert, and system debugging utilities to test network connectivity and identify network problems.

Ping

The ping utility sends ICMP echo requests (ECHO-REQUEST) to the destination device. Upon receiving the requests, the destination device responds with ICMP echo replies (ECHO-REPLY) to the source device. The source device outputs statistics about the ping operation, including the number of packets sent, number of echo replies received, and the round-trip time. You can measure the network performance by analyzing these statistics.

Using a ping command to test network connectivity

Task	Command	Remarks
Test the network connectivity to an IP address.	·     For IPv4 networks: ping [ ip ] [ -a source-ip | -c count | -f | -h ttl | -i interface-type interface-number | -m interval | -n | -p pad | -q | -r | -s packet-size | -t timeout | -tos tos | -v | -vpn-instance vpn-instance-name ] * host ·     For IPv6 networks: ping ipv6 [ -a source-ipv6 | -c count | -m interval | -s packet-size | -t timeout | -vpn-instance vpn-instance-name ] * host [ -i interface-type interface-number ]	Use either method. Available in any view.

 

NOTE: ·     When you configure the ping command for a low-speed network, H3C recommends that you set a larger value for the timeout timer (indicated by the -t parameter in the command). ·     Only the directly connected segment address can be pinged if the outgoing interface is specified with the -i keyword.

 

For more information about the ping lsp command, see MPLS Command Reference.

Ping example

Network requirements

Test the network connectivity between Device A and Device C in Figure 1. If they can reach each other, get detailed information about routes from Device A to Device C.

Figure 1 Network diagram

 

Test procedure

# Use the ping command on Device A to test connectivity to Device C.

<DeviceA> ping 1.1.2.2

  PING 1.1.2.2: 56  data bytes, press CTRL_C to break

    Reply from 1.1.2.2: bytes=56 Sequence=1 ttl=254 time=205 ms

    Reply from 1.1.2.2: bytes=56 Sequence=2 ttl=254 time=1 ms

    Reply from 1.1.2.2: bytes=56 Sequence=3 ttl=254 time=1 ms

    Reply from 1.1.2.2: bytes=56 Sequence=4 ttl=254 time=1 ms

    Reply from 1.1.2.2: bytes=56 Sequence=5 ttl=254 time=1 ms

 

  --- 1.1.2.2 ping statistics ---

    5 packet(s) transmitted

    5 packet(s) received

    0.00% packet loss

round-trip min/avg/max = 1/41/205 ms

The output shows that Device A sends five ICMP packets to Device C and Device A receives five ICMP packets. The route is reachable.

# Get detailed information about routes from Device A to Device C.

<DeviceA> ping -r 1.1.2.2

  PING 1.1.2.2: 56  data bytes, press CTRL_C to break

    Reply from 1.1.2.2: bytes=56 Sequence=1 ttl=254 time=53 ms

      Record Route:

         1.1.2.1

         1.1.2.2

         1.1.1.2

         1.1.1.1

    Reply from 1.1.2.2: bytes=56 Sequence=2 ttl=254 time=1 ms

      Record Route:

         1.1.2.1

         1.1.2.2

         1.1.1.2

         1.1.1.1

    Reply from 1.1.2.2: bytes=56 Sequence=3 ttl=254 time=1 ms

      Record Route:

         1.1.2.1

         1.1.2.2

         1.1.1.2

         1.1.1.1

    Reply from 1.1.2.2: bytes=56 Sequence=4 ttl=254 time=1 ms

      Record Route:

         1.1.2.1

         1.1.2.2

         1.1.1.2

         1.1.1.1

    Reply from 1.1.2.2: bytes=56 Sequence=5 ttl=254 time=1 ms

      Record Route:

         1.1.2.1

         1.1.2.2

         1.1.1.2

         1.1.1.1

  --- 1.1.2.2 ping statistics ---

    5 packet(s) transmitted

    5 packet(s) received

    0.00% packet loss

round-trip min/avg/max = 1/11/53 ms

The test procedure with the ping –r command (see Figure 1) is as follows:

1.     The source device (Device A) sends an ICMP echo request with the RR option being empty to the destination (Device C).

2.     The intermediate device (Device B) adds the IP address of its outbound interface (1.1.2.1) to the RR option of the ICMP echo request, and forwards the packet.

3.     Upon receiving the request, the destination device copies the RR option in the request and adds the IP address of its outbound interface (1.1.2.2) to the RR option. Then the destination device sends an ICMP echo reply.

4.     The intermediate device adds the IP address of its outbound interface (1.1.1.2) to the RR option in the ICMP echo reply, and then forwards the reply.

5.     Upon receiving the reply, the source device adds the IP address of its inbound interface (1.1.1.1) to the RR option. Finally, you can get detailed information about routes from Device A to Device C: 1.1.1.1 <-> {1.1.1.2; 1.1.2.1} <-> 1.1.2.2.

Tracert

Tracert (also called "Traceroute") enables you to get the IP addresses of Layer 3 devices in the path to a specific destination. You can use tracert to test network connectivity and identify failed nodes.

Figure 2 Network diagram

 

Tracert uses received ICMP error messages to get the IP addresses of devices. As shown in Figure 2, tracert works as follows:

1.     The source device (Device A) sends a UDP packet with a TTL value of 1 to the destination device (Device D). The destination UDP port is not used by any application on the destination device.

2.     The first hop (Device B, the first Layer 3 device that receives the packet) responds by sending a TTL-expired ICMP error message to the source device, with its IP address encapsulated. In this way, the source device can get the address of the first Layer 3 device (1.1.1.2).

3.     The source device sends a packet with a TTL value of 2 to the destination device.

4.     The second hop (Device C) responds with a TTL-expired ICMP error message, which gives the source device the address of the second Layer 3 device (1.1.2.2).

5.     This process continues until a packet sent by the source device reaches the ultimate destination device. Because no application uses the destination port specified in the packet, the destination device responds with a port unreachable ICMP to the source device, with its IP address encapsulated. This way, the source device gets the IP address of the destination device (1.1.3.2).

6.     The source device thinks that the packet has reached the destination device after receiving the port-unreachable ICMP message, and the path to the destination device is 1.1.1.2 to 1.1.2.2 to 1.1.3.2.

Prerequisites

Before you use a tracert command, perform the tasks in this section.

For an IPv4 network:

·     Enable sending of ICMP timeout packets on the intermediate devices (devices between the source and destination devices). If the intermediate devices are H3C devices, execute the ip ttl-expires enable command on the device. For more information about this command, see Layer 3—IP Services Command Reference.

·     Enable sending of ICMP destination unreachable packets on the destination device. If the destination device is an H3C device, execute the ip unreachables enable command. For more information about this command, see Layer 3—IP Services Command Reference.

·     If there is an MPLS network between the source and destination devices and you need to display the MPLS information during the tracert process, enable support for ICMP extensions on the source and intermediate devices. If the source and intermediate devises are H3C devices, execute the ip icmp-extensions compliant command on the devices. For more information about this command, see Layer 3—IP Services Command Reference.

For an IPv6 network:

·     Enable sending of ICMPv6 timeout packets on the intermediate devices (devices between the source and destination devices). If the intermediate devices are H3C devices, execute the ipv6 hoplimit-expires enable command on the device. For more information about this command, see Layer 3—IP Services Command Reference.

·     Enable sending of ICMPv6 destination unreachable packets on the destination device. If the destination device is an H3C device, execute the ipv6 unreachables enable command. For more information about this command, see Layer 3—IP Services Command Reference.

Using a tracert command to identify failed or all nodes in a path

Task	Command	Remarks
Display the routes from source to destination.	·     For IPv4 networks: tracert [ -a source-ip | -f first-ttl | -m max-ttl | -p port | -q packet-number | -vpn-instance vpn-instance-name | -w timeout ] * host ·     For IPv4 networks: tracert ipv6 [ -f first-ttl | -m max-ttl | -p port | -q packet-number | -vpn-instance vpn-instance-name | -w timeout ] * host	Use either method. Available in any view.

 

For more information about the tracert lsp command, see MPLS Command Reference.

System debugging

The switch supports debugging for the majority of protocols and features, and provides debugging information to help users diagnose errors.

Debugging information control switches

The following two switches control the display of debugging information:

·     Protocol debugging switch—Controls protocol-specific debugging information.

·     Screen output switch—Controls whether to display the debugging information on a certain screen.

As shown in Figure 3, assume that the device can provide debugging for the three modules 1, 2, and 3. The debugging information can be output on a terminal only when both the protocol debugging switch and the screen output switch are turned on.

Output of debugging information depends on the configurations of the information center and the debugging commands of each protocol and functional module. Debugging information is typically displayed on a terminal (including console or VTY). You can also send debugging information to other destinations. For more information, see "Configuring the information center."

Figure 3 Relationship between the protocol and screen output switch

 

Debugging a feature module

Output from debugging commands is memory intensive. To guarantee system performance, enable debugging only for modules that are in an exceptional condition. When debugging is complete, use the undo debugging all command to disable all the debugging functions.

To debug a feature module and display the debugging information on a terminal:

 

Step	Command	Remarks
1.     Enable the display of system information on the monitor terminal.	terminal monitor	Optional. By default, the display of system information is enabled on the monitor terminal but disabled on the console. Available in user view.
2.     Enable the terminal display of debugging information.	terminal debugging	By default, the terminal display of debugging information is disabled. Available in user view.
3.     Enable debugging for a specified module.	debugging { all [ timeout time ] | module-name [ option ] }	By default, debugging for a specified module is disabled. Available in user view.
4.     Display the enabled debugging functions.	display debugging [ interface interface-type interface-number ] [ module-name ] [ | { begin | exclude | include } regular-expression ]	Optional. Available in any view.

 

You must configure the debugging, terminal debugging and terminal monitor commands before you can display detailed debugging information on the terminal. For more information about the terminal debugging and terminal monitor commands, see Network Management and Monitoring Command Reference.

Ping and tracert example

NOTE: By default, Ethernet, VLAN, and aggregate interfaces are down. To configure such an interface, bring the interface up by executing the undo shutdown command.

 

Network requirements

As shown in Figure 4, Device A failed to Telnet Device C. Determine whether Device A and Device C can reach each other. If they cannot reach each other, locate the failed nodes in the network.

Figure 4 Network diagram

 

Test procedure

1.     Use the ping command to test whether Device A and Device C can reach each other.

<DeviceA> ping 1.1.2.2

  PING 1.1.2.2: 56  data bytes, press CTRL_C to break

    Request time out

    Request time out

    Request time out

    Request time out

    Request time out

 

  --- 1.1.2.2 ping statistics ---

    5 packet(s) transmitted

    0 packet(s) received

100.00% packet loss

The output shows that Device A and Device C cannot reach each other.

2.     Use the tracert command to identify failed nodes.

# Enable sending of ICMP timeout packets on Device B.

<DeviceB> system-view

[DeviceB] ip ttl-expires enable

# Enable sending of ICMP destination unreachable packets on Device C.

<DeviceC> system-view

[DeviceC] ip unreachables enable

# Execute the tracert command on Device A.

<DeviceA> tracert 1.1.2.2

 traceroute to 1.1.2.2(1.1.2.2) 30 hops max,40 bytes packet, press CTRL_C to break

 1  1.1.1.2 14 ms 10 ms 20 ms

 2  * * *

 3  * * *

 4  * * *

 5

<DeviceA>

The output shows that Device A and Device C cannot reach other, Device A and Device B can reach each other, and an error occurred on the connection between Device B and Device C.

3.     Use the debugging ip icmp command on Device A and Device C to verify that they can send and receive the specific ICMP packets, or use the display ip routing-table command to verify the availability of active routes between Device A and Device C.