ICMP Ping monitoring 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.
[click below to enlarge]
[click below to enlarge]
An ICMP/Ping check has the following parameters:
- Host - The DNS name or IP address of the computer you want to ping (can even be a WINS name, but only if the name can be resolved by some WINS server in the network);
- Timeout for each reply - Maximum number of milliseconds it may take before a response is received;
- Number of retries - Number of retries to send after an unsuccessfull ping;
- Time to Live - Maximum Time to Live (TTL) value;
- Buffer size - Send buffer size.
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 126.96.36.199 188.8.131.52 184.108.40.206 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 = 220.127.116.11 IP: Destination Address = 18.104.22.168 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 = 22.214.171.124 IP: Gateway = 126.96.36.199 IP: Gateway = 188.8.131.52 IP: End of Options = 0 (0x0) IP: Data: Number of data bytes remaining = 40 (0x0028) + ICMP: Echo Reply, To 184.108.40.206 From 220.127.116.11
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.