Page History

...

• Remote hosts for which the DNS lookup fails;
• Wiki Markup Remote hosts that do respond to queries to one of a set of well-known ports  Remote hosts that do respond to queries to one of a set of well-known ports (80,7,53,23,25,21,37,79 \[Reference\]). Such hosts are probably blocking pings.

In addition we note the following in the sortable table:

...

After the script getdata.pl is run from a trscrontab on pinger@pinger.slac.stanford.edu to gather data from the monitoring hosts, the data is inspected by checkdata_gif.pl for non responding monitoring hosts, unusual responses from monitoring hosts, invalid data such as missing tokens, inability to send 10 packets etc. In addition a table is constructed showing the state (no response from the monitor, no data from monitor, partial data from the monitor, success) of gathering the data for each monitor node. Besides showing the gathering status going back many months, the table also provides easy links to dynamically test the monitoring host for its ping reachability and the response of its response to the web gather request. Emails are sent daily to the central administrators indicating which monitoring hosts were not successful. The typical follow up after a few days is to email the contact(s) at the monitoring node to request help in fixing the problem. At any given time we are uanble to gather data from about 10% of the monitoring nodes.

Other Validations

Rate limiting is much harder to discover this simple blocking. In some cases it will result in  sudden increase in losses. For example ICTP turned on rate limiting at their bordeer in May-Jun 2008. This affected  the losses measured from ICTP to almost all its remote hosts. On the left in the table below an example plot of losses and RTT from ICTP to a host in Brazil shows the increase in hourly ping losses starting early in June 2008. On the right is the median loss from ICTP to 93 sites worldwide in June 2008 showing a steep increase on June 6th and 7th.