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
&if &TIMESTAMP& &then display_line *** (date).(time) ***
ping &TARGET& -count 1 -timeout &TIMEOUT&
sleep -seconds &SECONDS&
& 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.