Which shift is a ping

PING and the limits of ICMP

A request in a newsgroup inspired me to this page. Besides, it's a nice example where monitoring can also deliver incorrect data.

If I set a permanent ping in my network, then I have 0% loss. But if I set a ping on my public IP of my mail server, then I always have a loss of 2%.

Now you might be unsure that a 2% "loss" could mean a problem with the server or the line, which must be investigated. But let's take a closer look at the analysis


PING uses the ICMP protocol, which is located on the same level in the OSI layer model as TCP and UDP. TCP is used e.g. by HTTP, SMTP, FTP etc. UDP is used e.g. by DNS queries or WINS. Like UDP, ICMP is completely without handshake. If a packet is lost, the IP stack does not ensure that it is retransmitted. But that is exactly what PING wanted, otherwise the system cannot detect any losses.

However, due to a high load on the line, the ping may take 1.5 seconds to respond. The package that is "too late" is therefore not counted.

The packet that is sent at time 3 no longer arrives before time 4 and therefore PING already outputs a "timeout" at time 4 and sends the next packet on its way. The packet at time 5 is really lost (red) and so PING also indicates a "timeout" at time 6.

PING sends its packets with a sequence number, i.e. ping could recognize a delayed response as well as a wrong sequence, only the screen output with "timeout" is of course already written.

So you have to find out whether the packets are really "missing" or just arriving "after closing time". A few "losses" are usually okay when they are actually only due to "delayed parcels". You should monitor the availability with a higher protocol. So in order to "test" a web server you should also ask the web server, e.g. with WGET or other tools.

PING with options

To clarify the behavior, let's look at four different PING calls.

ping -t servername

This call now sends a PING to the specified server every second and therefore waits up to one second for the response. This works quite well in a LAN, but pinging over a WAN connection can lead to dropouts. However, this does not immediately mean that the remote station cannot be reached, but simply that the path may be very long or that a section of the route is so busy that our package and the answer have to be included.

So we change the call so that PING waits longer:

ping -t -w 5000 servername

PING now sends a packet every 5 seconds. But it is more important that PING waits up to 5 seconds for the answer. With these settings, the error rate will be much lower with otherwise the same benchmarks because the time is simply longer.

However, you should of course be prudish if the round trip time is generally very long. That is an indication of a partially overloaded connection between you and the server

If you don't have a "slow" line, but want to observe the behavior of missing packets, you can simply control the size of the packet with the following line

ping -t -l10000 server

PING now sends a 10Kbyte packet to the remote station, which also replies with a 10KByte packet. The upper limit is 64Kbytes or more precisely 65535 bytes. Earlier IP stacks were vulnerable here (ping of death) by simply sending an even larger packet and the other side then overwriting its neighbor when reserving the receiving memory. Many firewalls therefore block excessively long PING packets as a possible attack. Some routers are also not able to process such packets correctly, as a packet on the cable may only have a certain maximum length (MTU size), which differs from medium to medium. A router has to split the packet accordingly and put it back together again on the other side.

  • 314825 How to Troubleshoot Black Hole Router Issues

If your large PING packet is actually being transmitted, you should rather miss packets. With 64Bit and even with DSL with 192kbit upstream, there is simply no longer enough time to transmit the packet and the answer in 1 seconds. It looks like no more packages can get through.

To make this "error" clearer, PING is instructed again to simply wait longer.

ping -t -l10000 -w 5000 server

A 10KByte packet should also have been transferred back and forth in 5 seconds. The ping now reports results again.

PING improved and alternatives

Even if you want permanent monitoring, it is not really helpful to address the server with a ping every second. The results aren't really better whether you ping every second or every 10 seconds. With a 10-second PING, however, you have the option of recognizing runtimes over 1 second up to 10 seconds.

At the same time, you relieve the line, the server and their volume. The following little calculation should clarify this:

1 ping = 64bytes (rounded) * 86400 seconds * 2 = 5.4Mbytes / day or 162 megabytes per month

But if you still have dropouts even after long waiting times, then you should check your Windows server to see whether higher protocols such as TCP are also performing so-called "retransmissions". You can determine this relatively easily with the Windows Performance Monitor.

This counter reports the rate at which the TCP / IP stack retransmits packets. It should be as low as possible, but don't expect it to always contain a 0.

However, you can see that a PING can only be used for monitoring up to a certain limit. It is a first test that ensures the general availability of the other system before software then addresses the higher protocols. However, if you still want to check availability with "ping", you could use QoS, for example: to prioritize these packets, so that losses then rather allow conclusions to be drawn about the reachability of the remote station.

Ping with VBScript

Unfortunately there is no direct "COM object" that you can address with VBScript or even a VBScript command. You can therefore use two options via VBScript

  • Start PING.EXE
    You simply start the command line version and evaluate the output.
    You use the WMI function to send a PING. Since WMI is "remote" -capable, you can start a ping remotely with at least a Windows server as host
Function wmiping (strComputer) Dim PingResults, Pingresult Set PingResults = GetObject ("winmgmts: // localhost / root / cimv2"). ExecQuery ("SELECT * FROM Win32_PingStatus WHERE Address = '" + strComputer + "'") for Each PingResult In PingResults If PingResult.StatusCode = 0 Then wmiping = True Else wmiping = False End If Next End Function

Ping with PowerShell

With PowerShell you have two native options for starting a PING. Of course, you can still call "PING.EXE" or do a WMI ping, but the following two methods are more elegant:

  • PING via commandlet
    With "Test-Connection" you can simply ping the system and receive the answer directly
  • PING via .NET class
[string] $ target = "$ result = (new-object System.Net.NetworkInformation.Ping) .Send ($ target)

Test-Connection is definitely the easiest way if no extended functions are required:

Test-Connection `-ComputerName] ` -BufferSize 160 `-Count 1` -TimeToLive xx

more links