ICMP Ping test using ActiveXperts

ActiveXperts solution to monitor ICMP Ping availability

ICMP Ping checks a remote host for availability. Local hosts should normally respond to ping requests within milliseconds. However, on a very congested network it may take up to 3 seconds or longer to receive an echo packet from the remote host. If the timeout is set too low under these conditions, it will appear that the remote host is not reachable (which is almost the truth). ActiveXperts Network Monitor checks servers for availability by sending ICMP Echo commands and wait for the responds. An ICMP timeout failure doesn't necessarily mean that the remote host is actually functioning beyond its ability to echo packets. An ICMP/Ping check has the following parameters:

ActiveXperts Network Monitor ICMP check

ActiveXperts Network Monitor ICMP check

TCP/IP Troubleshooting Guidelines

There is no fixed sequence of steps to troubleshoot TCP/IP-related problemseverything 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. Its 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 youre sure the links are functioning properly, you should start testing the local hosts 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 . . . . . . . . : 
        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 
        Physical Address. . . . . . : 0020-AF-AC-3A-76 
        DHCP Enabled. . . . . . . . : No 
        IP Address. . . . . . . . . : 
        Subnet Mask . . . . . . . . : 
        Default Gateway . . . . . . : 
        Primary WINS Server . . . . :

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

Windows NT IP Configuration 
Ethernet adapter Elnk31: 
        IP Address. . . . . . . . . : 
        Subnet Mask . . . . . . . . : 
        Default Gateway . . . . . . :

This listing could indicate that the DHCP server is down or that there are no free IP addresses in the DHCP servers 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:

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 
 -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 Dont 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 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 = 
      IP: Destination Address = 
      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 =
                   IP: Gateway = 
                   IP: Gateway = 
         IP: End of Options = 0 (0x0) 
    IP: Data: Number of data bytes remaining = 40 (0x0028) 
  + ICMP: Echo Reply, To From

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.