[atlas]IPv4 and IPv6 to the same machine(s)...
How much effort would it be to add a test and the graph to labs.ripe.net on IPv6? Just checked, it still has an IPv6 address. Btw, Mirjam (on bcc:), the new Labs site does no longer show the address for the incoming connection. Could this be re-instated, please? If possible it should go to somewhere in the header, like next to the login-name... On a more general aspect, I am looking for a good idea to present the measurement data for the same machine(s) for v4 and v6 either in the same graph "on top of each other" or "next to each other"... This could easily evolve into a graphical v6-sanity-check vehicle :-) Wilfried.
On 23.11 17:53, Wilfried Woeber, UniVie/ACOnet wrote:
How much effort would it be to add a test and the graph to labs.ripe.net on IPv6? Just checked, it still has an IPv6 address.
The effort is minimal, however the current "design" of the firmware restricts the number of targets we can reliably ping. Bear with us for a few weeks until we have a more reliable design ready to deploy.
On a more general aspect, I am looking for a good idea to present the measurement data for the same machine(s) for v4 and v6 either in the same graph "on top of each other" or "next to each other"...
This could easily evolve into a graphical v6-sanity-check vehicle :-)
Makes absolute sense. We will put that on the 'idea stack'.
Hi all, This is a feature request. I was debugging my dad's home network (well, network, 1 PC with a modem) after he complained that he could not send email anymore. It turned out that he somehow managed to disable the ethernet card on his PC. This was a clear user error. He did call the helpdesk of his ISP. The helpdesk started with the configuration of the mail client... Imagine the confusion that created. Anyway, what I think would be really cool for probe hosts is if the probe could give a little bit more information about the network where it is in and present that in a way understandable to the user. For example: * Probe has local address Yes/No * Probe sees local gateway " * Probe has Internet access * Pings to XX works * DNS query works * IMAP server responds * SMTP server responds * Popular website responds * SIP server responds * ... with the list pre-configured for the ISP of the user (or some way to configure that yourself). On the probe, run a webserver such that http://10.0.0.139 points you to the list showing you a list of "yes"/"no"'s. Advantages: * For the end user: if all items are yes, then that shows that there is nothing wrong on the user side and no action has to be taken. * For the helpdesk when debugging the problem: the answer to a number of routine questions is there, without having to explain how to check things. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.xs4all.nl/~henku P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ I confirm today what I denied yesterday. Anonymous Politician.
Hi,
Anyway, what I think would be really cool for probe hosts is if the probe could give a little bit more information about the network where it is in and present that in a way understandable to the user. For example:
* Probe has local address Yes/No * Probe sees local gateway " * Probe has Internet access * Pings to XX works * DNS query works * IMAP server responds * SMTP server responds * Popular website responds * SIP server responds * ...
Note: there are a bunch of inputs here that would have to be pre-defined by the user. I'm not convinced that a casual user, for whom this would be useful, would ever define these in advance.
with the list pre-configured for the ISP of the user (or some way to configure that yourself).
On the probe, run a webserver such that http://10.0.0.139 points you to the list showing you a list of "yes"/"no"'s.
This would mean that the probe offers some externally accessible services. That doesn't sound too scary for firewalled/NATed ones, but generally enabling this would mean handling permissions, ACLs and such. And a whole lot of probe capacity taken away for something that may never be used. One could drive this through the website, execute the tests on demand, but that wouldn't work while a genuine network problem is happening.
Advantages:
* For the end user: if all items are yes, then that shows that there is nothing wrong on the user side and no action has to be taken.
* For the helpdesk when debugging the problem: the answer to a number of routine questions is there, without having to explain how to check things.
I agree with these advantages. Still, we'll have to see if they outweigh the disadvantages. Cheers, Robert
Henk
Hi,
Anyway, what I think would be really cool for probe hosts is if the probe could give a little bit more information about the network where it is in and present that in a way understandable to the user. For example:
* Probe has local address Yes/No * Probe sees local gateway " * Probe has Internet access * Pings to XX works * DNS query works * IMAP server responds * SMTP server responds * Popular website responds * SIP server responds * ...
Note: there are a bunch of inputs here that would have to be pre-defined by the user. I'm not convinced that a casual user, for whom this would be useful, would ever define these in advance.
The probe data is known for each ISP, so a probe can be pre-configured by an ISP. Lots of ISPs send modems to their users, the probe can be included in this shipment. Also, this particular ISP sends an engineer (for a fee) to the user to configure his connection. In that case, the probe can be configured on the spot.
On the probe, run a webserver such that http://10.0.0.139 points you to the list showing you a list of "yes"/"no"'s.
This would mean that the probe offers some externally accessible services.
That is true.
One could drive this through the website, execute the tests on demand, but that wouldn't work while a genuine network problem is happening.
Well, yes, in this case you limit the test suite, though I still think that the remaining tests would be useful. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.xs4all.nl/~henku P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ I confirm today what I denied yesterday. Anonymous Politician.
participants (5)
-
Daniel Karrenberg -
Henk Uijterwaal -
Henk Uijterwaal -
Robert Kisteleki -
Wilfried Woeber, UniVie/ACOnet