Re: Test boxes
- Date: Mon, 26 Jun 2000 14:56:51 +0200 (CEST)
Yann Adam wrote:
> > 1) do RIPE-NCC Test Traffic Mesurement have a web site showing results to
> > everybody (including non RIPE-NCC members ?), as they do in the Surveyor
> > project ?
No, we don't have a public site, but we do have a private web-site
accessible to the test-box hosts only. As soon as a site joins the
project, he gets the URL, password and username, and then has access to
daily plots, a CGI-interface to our traceroute data-base, graphs and maps,
and more information.
> > 2) what are the metrics measured by the A-serie test boxes and what will be
> > the metrics measured by the B ones ?
A and B are just internal identifiers to distinguish slight differences in
the hardware of the boxes.
The software both series of boxes run is the same, as are the measurements
that they do: 1-way delays, packet-loss rates, and routing vectors. All
derived products (e.g. network alarms) are also available for both series.
> > 3) what type of access do owners have to their test boxes ? I read the paper
> > called "How to access the data on your test-box" where it is said the 2
> > types are by listening on a specific port (available) and copying the datas
> > (not available). Is it still true ?
Yes, except that copying the data is now available.
Listing to a port on the test-box is still available. The host site gives
us an address-range and we enable the port for them. Then a telnet to the
port show you the data as it is being recorded. This method has 2
(intrinsic) limitations:
- If you're not listening, you won't see the data.
- One only has information about packets arrrive on, and traceroutes
originating from the box.
If you want all the data related to the box, just ask us. We have a tool
to extract specific subsets of the data from our data-base and can put
those files on our ftp server. These files have been processed in order
to combine information from the sending and receiving box into 1 file. The
files can be directly read by a (free) analysis package for further
analysis. Typical delay between data-taking and availability on the
webserver is of the order of 2 days (and we can probably speed that up,
but so-far, there has been little need for that).
For troubleshooting, we provide network delay alarms that send email when
delays go above some variable threshold.
> Is there newer types of access ?
No, but we're open to suggestions here. For example, we can interface the
network alarms to SNMP, generate MRTG/RRD/ORCA plots on the box, etc, etc.
However, we don't have unlimited resources in the group, so I like to see
some consensus on what we should do, before actually implementing it. Of
course, we're always happy to help people to set something up.
Henk
------------------------------------------------------------------------------
Henk Uijterwaal Email: henk.uijterwaal@localhost
RIPE Network Coordination Centre WWW: http://www.ripe.net/home/henk
Singel 258 Phone: +31.20.535-4414, Fax -4445
1016 AB Amsterdam Home: +31.20.4195305
The Netherlands Mobile: +31.6.55861746
------------------------------------------------------------------------------
A man can take a train and never reach his destination.
(Kerouac, well before RFC2780).
