I recently was asked to do some analysis of a trace file, it was only 161 seconds in duration and contained a little more than 2.6 million frames. I was amazed to discover that approximately 75% of those frames where either ping requests or ping replies. If I hadn’t recognized the source IP address I would have jumped to the conclusion that the target was under a denial of service attack. Instead I learned that they were using the “run_forever” argument on STCP’s ping command to monitor the reachability of the target.

 

Unlike the ping command on most UNIX or Linux systems, STCP’s ping command does not pause between receiving a ping reply and the next ping request. Since the default number of pings is only 4 this is not a significant issue. But when the number of requests is increased by using the count argument or the run_forever argument is used this can create a significant load on the system, the Ethernet adapter and the network. This makes the default behavior of STCP’s ping command totally unsuited for long term monitoring of a target host.

 

But, just because the default behavior is unsuitable doesn’t mean that you cannot use the ping command for long term monitoring. The trick is to repeatedly execute the command sending one ping request at a time instead of executing the command once and sending a continuous stream of ping requests. The following macro will do that.
ping_forever command macro
& ping_forever begins here
&
& Version 1.0 09-08-30
& noah.davids@stratus.com
&
&begin_parameters
TARGET   target:string,required
SECONDS  seconds:number=1
TIMEOUT  timeout:number=1
TIMESTAMP switch(-timestamp),=1
&end_parameters
&
&label again
display_line
&if &TIMESTAMP& &then display_line *** (date).(time) ***
ping &TARGET& -count 1 -timeout &TIMEOUT&
sleep -seconds &SECONDS&
&goto again
&
& ping_forever ends here

 

As you can see the first two arguments are passed directly to the ping command and correspond to ping’s host and timeout arguments. Ping’s default timeout is 15 seconds but I think that is too long and in the macro I have changed that to 1 second. You of course can adjust it either in the macro or by providing a value as an argument. The third argument is the number of seconds to pause between pings, the default is 1 second. Because it takes time to run the macro and load and execute the ping command the actual time between pings is a little longer. Packet_monitor showed the times between 1.05 and 1.1 seconds. The final argument is something that UNIX or Linux ping will not give you – a timestamp for each ping so you can tell when the target stops responding and when it started again. If you do not want the timestamps you can turn them off with the -no_timestamp argument.

 

ping_forever example output
ping_forever 164.152.77.6
*** 09-08-30.11:45:38 ***
Pinging host 164.152.77.6 : 164.152.77.6
ICMP Echo Reply:TTL 60 time = 2 ms
Host 164.152.77.6 replied to the ping
*** 09-08-30.11:45:40 ***
Pinging host 164.152.77.6 : 164.152.77.6
ICMP Echo Reply:TTL 60 time = 2 ms
Host 164.152.77.6 replied to the ping
*** 09-08-30.11:45:41 ***
Pinging host 164.152.77.6 : 164.152.77.6
ping: No reply. Time Out !!
Host 164.152.77.6 didn't reply to the ping
*** 09-08-30.11:45:44 ***
Pinging host 164.152.77.6 : 164.152.77.6
ping: No reply. Time Out !!
Host 164.152.77.6 didn't reply to the ping
*** 09-08-30.11:45:47 ***
Pinging host 164.152.77.6 : 164.152.77.6
ICMP Echo Reply:TTL 60 time = 4 ms
Host 164.152.77.6 replied to the ping
*** 09-08-30.11:45:48 ***
Pinging host 164.152.77.6 : 164.152.77.6
ICMP Echo Reply:TTL 60 time = 3 ms
Host 164.152.77.6 replied to the ping