Re: [atlas] Ability to traceroute to 240/4 - software vs. hardware probes
Hi! I noticed that Phillip Homburg merged a RIPE Atlas client patch in November of last year, based on our request, that removes the Atlas probe's inability to test addresses in 0/8 and 240/4. https://github.com/RIPE-NCC/ripe-atlas-probe-measurements/commit/59475f848b2... So, I just tried a couple of measurements to 240.1.2.3 to see how Atlas would handle them: https://atlas.ripe.net/measurements/48100582/ https://atlas.ripe.net/measurements/48100585/ (I don't expect these to succeed, as no part of 240/4 is publicly announced in BGP; the interesting information to be garnered from this isn't whether the probes succeed, but how they fail.) For the first measurement, with ping, 6 hardware probes and 4 software probes all gave the same result: "Unreachable" (which is what you would get if you ran this on any ordinary Internet host with command-line ping). For the second measurement, with traceroute, 6 hardware probes all actually attempted the traceroute (getting failures after some small number of network hops), while 3 software probes all reported back "!address not allowed". What could account for the difference in how hardware and software probes handle this task? I would have thought that the change from last November would make software probes willing to attempt these.
What could account for the difference in how hardware and software probes handle this task? I would have thought that the change from last November would make software probes willing to attempt these.
I'd believe it's the combination of what versions these probe run (i.e.. is it at least 5060?) plus the properties of the network they are in. The code is otherwise the same. Cheers, Robert
Robert Kisteleki writes:
What could account for the difference in how hardware and software probes handle this task? I would have thought that the change from last November would make software probes willing to attempt these.
I'd believe it's the combination of what versions these probe run (i.e.. is it at least 5060?) plus the properties of the network they are in. The code is otherwise the same.
Thank you. This is now confirmed: after I upgraded my own software probe to the most recent release, its behavior matches what I expect.
participants (2)
-
Robert Kisteleki
-
Seth David Schoen