Monitor ICMP PING | ActiveXperts Network Monitor and Internet Protocols

ActiveXperts Network Monitor ICMP check

TCP/IP Troubleshooting Guidelines

There is no fixed sequence of steps to troubleshoot TCP/IP-related problems'everything depends on the particular scenario. There are, however, some basic guidelines that fit most situations.

The first thing you should do is to ensure the physical connection is functioning. It's useless to employ a host of troubleshooting utilities if the office hub is malfunctioning. When link reliability is in question, for example, when the WAN link is malfunctioning, you may want to ping various remote hosts to check connectivity.

Once you're sure the links are functioning properly, you should start testing the local host's configuration parameters, then examine routing configurations, and finally check name resolution issues.Note that you test the lower layers of the TCP/IP stack first. Once the low-level TCP/IP functions are working correctly, move to the higher levels.

Identifying the TCP/IP Configuration

Checking the TCP/IP configuration is the most basic troubleshooting step. You might want to ensure the TCP/IP parameters have been entered without mistakes or that DHCP has set them correctly. You should begin by checking the TCP/IP configuration on the computer that appears to be experiencing problems. A good starting point is the IPCONFIG command line utility. IPCONFIG displays the IP address, subnet mask, and default gateway, as well as other advanced TCP/IP parameters, such as WINS server, IP address, and node type.

You should use the IPCONFIG utility with the /all switch because it produces a detailed report concerning the current TCP/IP configuration. The following is an example of the output from IPCONFIG:

C:\WINNT>ipconfig /all 
Windows NT IP Configuration 
        Host Name . . . . . . . . . : mcse.traincert.com 
        DNS Servers . . . . . . . . : 172.20.0.10 
        Node Type . . . . . . . . . : Hybrid 
        NetBIOS Scope ID. . . . . . : 
        IP Routing Enabled. . . . . : No 
        WINS Proxy Enabled. . . . . : No 
        NetBIOS Resolution Uses DNS : Yes 
Ethernet adapter Elnk31: 
        Description . . . . . . . . : ELNK3 Ethernet 
                                      Adapter. 
        Physical Address. . . . . . : 00-20-AF-AC-3A-76 
        DHCP Enabled. . . . . . . . : No 
        IP Address. . . . . . . . . : 172.20.0.10 
        Subnet Mask . . . . . . . . : 255.255.255.0 
        Default Gateway . . . . . . : 172.20.0.1 
        Primary WINS Server . . . . : 172.20.0.10

In some cases, just reviewing this report can resolve the problem. For example, if the DHCP client could not obtain the IP address, running IPCONFIG returns the IP address and subnet mask of 0.0.0.0.

C:\WINNT>ipconfig 
Windows NT IP Configuration 
Ethernet adapter Elnk31: 
        IP Address. . . . . . . . . : 0.0.0.0 
        Subnet Mask . . . . . . . . : 0.0.0.0 
        Default Gateway . . . . . . :

This listing could indicate that the DHCP server is down or that there are no free IP addresses in the DHCP server’s scope.

Testing IP Communications

One your computer has obtained an IP address and a subnet mask, you should test the IP communications. PING is the utility that can be used for verifying IP-level connectivity. As you may remember, PING sends the ICMP echo request to the destination host and analyzes ICMP echo replies. The recommended sequence of pings is the following:

• Ping the loopback address. (If you are unable to ping the loopback address, it may indicate the computer has not been restarted after TCP/IP was installed and configured - restart and try again.)
• Ping the IP address of the local computer. (If you cannot ping the local IP address, check to ensure your computer has a valid IP address that is not duplicated elsewhere on the network.)
• Ping the IP address of the default gateway. (If this step is unsuccessful, check the subnet mask on your computer.)
• Ping the IP address of the remote host. (If this step is unsuccessful, check the default gateway address configured on the local computer, the functionality of the link between routers, and the remote computer’s availability.)
• Ping the remote host by name. (If this step fails, check host name resolution.)

The PING utility has many switches that can be used to expand its functionality. To view the available command line options, type PING -?

C:\WINNT>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] destination-list 
Options: 
 -t   Ping the specified host until interrupted. 
 -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. 

For example, you can specify the size of the packets to use, how many packets to send, and how much time to wait for a response. There are some more advanced options of the PING utility such as specifying the type of service (TOS), the initial TTL value, and the source route. These options directly affect the header of the IP packet in which the ICMP message is encapsulated. For example, the command

PING -v 12 -j 194.226.192.33 194.85.165.169 194.85.36.30 www.runnet.ru

will cause the following ICMP packets to be sent (note that by specifying the PING options –v and –j we set the values of some fields in the IP header– printed in bold typeface):

+ FRAME:  Base frame properties 
+ ETHERNET:  ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol 
IP:  ID = 0x2155; Proto = ICMP; Len: 76 
      IP: Version = 4 (0x4) 
      IP: Header Length = 36 (0x24) 
      IP: Service Type = 12 (0xC) 
         IP: Precedence = 0x0C 
          IP: ...0.... = Normal Delay 
          IP: ....1... = High Throughput 
          IP: .....1.. = High Reliability 
      IP: Total Length = 76 (0x4C) 
      IP: Identification = 8533 (0x2155) 
  + IP: Flags Summary = 0 (0x0) 
      IP: Fragment Offset = 0 (0x0) bytes 
  IP: Time to Live = 252 (0xFC) 
      IP: Protocol = ICMP - Internet Control Message 
      IP: Checksum = 0xF92C 
       IP: Source Address = 193.232.80.66 
      IP: Destination Address = 194.226.192.52 
      IP: Option Fields = 131 (0x83) 
         IP: Loose Source Routing Option = 131 (0x83) 
  IP: Option Length = 15 (0xF) 
  IP: Routing Pointer = 16 (0x10) 
  IP: Route Traveled = 194 (0xC2) 
                   IP: Gateway = 194.85.36.30
                   IP: Gateway = 194.85.165.169 
                   IP: Gateway = 194.226.192.33 
         IP: End of Options = 0 (0x0) 
    IP: Data: Number of data bytes remaining = 40 (0x0028) 
  + ICMP: Echo Reply, To 194.226.192.52 From 193.232.80.66

About ICMP

The Internet Protocol (IP) is used to transport datagrams between Internet hosts. It is known as a connectionless datagram service, that is it transports datagrams on a best-effort basis. If an error occurs en route to the destination, the IP does not have the error-handling facilities to report or correct these errors. The ICMP protocol provides a method of sending information to the source host regarding information about a datagram. ICMP is a separate protocol from IP, but every IP implementation must include the ICMP protocol. ICMP makes use of the IP protocol as a transport and like IP, ICMP is best-effort; an ICMP message is not guaranteed to arrive at its destination. The purpose of ICMP is to provide feedback regarding the network and datagrams, it is not to make IP a reliable transport mechanism. ICMP messages use a basic IP datagram header with the IP data being the ICMP message. The IP source address is that of the host or gateway sending the ICMP message with the destination IP address being that of the original source IP address. RFC 792 states that, where applicable, each ICMP message contains the IP header and first 64 bits of the original datagram which is used to match the datagram to a process. RFC 1812 indicates that this is no longer adequate and an ICMP message, where applicable, should contain as much of the original datagram as possible that can fit within a 576 byte message.