One gotcha today (March 1999) is that it only runs under VMS. The author (John MacAllister) is actively looking at porting to Perl with the intention of running it on Unix, Linux or Windows NT. Thus in March 1999 we ran a survey of the ESnet & HENP monitoring sites to see how many of the PingER monitoring sites would be willing/able to run traceping on a VMS platform. Traceping Contacts provides a list of the contacts for each of the sites contacted. We followed up the above survey with another to see how many sites would be willing to run traceping if it were ported to Perl and could run on Unix, Linux or Windows NT. The table below shows the results of the surveys.
Site | State | VMS | Perl Platform Choice | Site | State | VMS | Perl Platform Choice |
---|---|---|---|---|---|---|---|
ARM | Willing | No | Solaris | BNL | Willing | No | Solaris |
CERN | Running analyzer B | Yes | ? | Carleton | Willing | No | HPUX, Solaris, Linux |
CMU | Willing | No | Linux, Digital | DESY | Running probe | Yes | ? |
DOE | Willing | No | Solaris, Linux, WNT | FNAL | Willing | ? | Solaris or WNT |
Gran Sasso | Running probe | Yes | ? | INFN | No answer | ? | ? |
KEK | No answer | ? | ? | KFKI | Responded | No | ? |
Munich | Running probe | Yes | ? | NBI | Willing | Yes | Digital, Linux |
Oxford | Running analyzer B | Yes | ? | PNL | Willing | No | Solaris, Linux |
RAL/DL | No answer | ? | ? | SLAC | Running analyzer B | Yes | Solaris, Linux, AIX |
Taiwan | Willing | No | Linux | TRIUMF | Running analyzer B | Yes | ? |
Toronto | Willing | Yes | ? | UMD | No answer | ? | ? |
Willing | Indicates the site is willing to run traceping |
Running probe | Indicates the site is already running the traceping probe task. |
Running analyzer | Indicates the site is running a probe and also collecting and analyzing data for itself and possibly other sites. |
B | Indicates that the site is running a test version of traceping that probes all Beacon sites. |
Responded | Indicates the site responded to the first survey, we await a response to the second survey. |
No answer | Indicates there has been no response from the site to either survey. |
Perl Platform Choice | This column indicates on what platforms, in order of preference, the site would deploy a perl version of traceping. |
The standard mode of running traceping is to aim for three shots
per hour to avoid having strange looking plots. However the number, size and
frequency of sending packets are all configurable parameters and so can be
adjusted with experience or to suit specific requirements.
The normal setup is to send 9 packets of 100 bytes each approximately every
20 minutes. If the average route has 20 hops that would give (per hour):
As a possibility to minimize the traceping impact, each traceping monitoring site should determine what sites it needs to keep traceroutes for (e.g. the Beacon sites, but if the monitoring site is already a Surveyor site, then don't traceroute to beacon sites already covered by Surveyor).
We also posted a request to the IETF/IPPM news group asking for "comments, advice, measurements of the traceroute impact (e.g. how many traceroutes/second can a core router handle as a function of its typical load), is there any other way to learn the routing information history etc."
The responses indicated that people did not feel our level of traceroute activity would impact the network. A suggestion was made that rather than sending the default 3 probes for each TTL, to stop sending probes once success is achieved. This should reduce the impact of traceroute, by up to a factor of 3.
The effect of pinging can be reduced if by default traceping uses 0 pings for the routers along the route, except to sites where it is critical to understand the congestion and there is deemed to be adequate bandwidth. John will provide an option to support setting the number of pings to 0.
This impact could be reduced if traceping does its own address-to-name caching.
The main requirement for cpu cycles is for the analysis. The design allows the monitoring to be done on a separate machine to the analysis. The communication (i.e. the data is sent from the monitoring machine(s) to the analysis/collection machine(s)) is via email. On a DEC Alpha 3400 each remote site requires about 1-2% of the cpu for the analysis.
The storage space required is about 1.5Mbytes/day (or 45Mbytes/month) for each site that is monitoring about 50 Beacon sites. The storage space difference between traceping with routes only and traceping with the pings is only about 5%.