Any way to select the probes from upstream AS (not origin AS)?
Is there an easy way to select probes, not on the origin AS, but on an AS upstream? Example: probe 23865, IP prefix announced by AS 56339 which currently has only one provider, AS 16080. Currently, Atlas tells me there are no probes in AS 16080...
On 2015-11-11 16:32, Stephane Bortzmeyer wrote:
Is there an easy way to select probes, not on the origin AS, but on an AS upstream? Example: probe 23865, IP prefix announced by AS 56339 which currently has only one provider, AS 16080. Currently, Atlas tells me there are no probes in AS 16080...
Hi, No, we don't have direct support for this. I guess one could download latest traceroute results for a (random) built-in measurement, map IPs to ASNs and use that -- but I have to admit it's not easy. Regards, Robert
On Wed, Nov 11, 2015 at 04:43:49PM +0100, Robert Kisteleki <robert@ripe.net> wrote a message of 14 lines which said:
No, we don't have direct support for this. I guess one could download latest traceroute results for a (random) built-in measurement, map IPs to ASNs and use that -- but I have to admit it's not easy.
I understand. Also, a probe has one origin AS but may have several upstream AS and you don't know which one will be used when the probe fires a packet to the target.
On 11.11.2015 16:32, Stephane Bortzmeyer wrote:
Is there an easy way to select probes, not on the origin AS, but on an AS upstream? Example: probe 23865, IP prefix announced by AS 56339 which currently has only one provider, AS 16080. Currently, Atlas tells me there are no probes in AS 16080...
I have the same problem quite often. For several important Backbone providers there aren't any probes. But there would be a lot of probes which are "behind" these ASes. Choosing this probes is of course not a guarantee that the targeted transit ISP is really used for routing (multihoming, peering) but I think in many cases this would work. You RIPE guys build so cool systems, I think it would be easy for you to integrate RIS data into Atlas. So, if somebody searches for probes in an AS, you could also suggest probes from neighboring ASes (especially the ones which have only one neighbor AS). So for above case: https://stat.ripe.net/data/asn-neighbours/data.json?resource=56339 If you do this lookup once a day and add the info to the probe information (maybe only using "left" neighbors), it could be used for probe selection. regards Klaus
Wouldn't it be easier to simply convince said transit ASes to host a probe? for most part, you'd now be dealing with networking professionals rather than end-users, so they have an incentive to host a probe (for their own routing needs) and technical capacity to do so, whereas for non-transit ASes you are sometimes dependant on a user being a good samaritan or otherwise having a need to access measurements. Regards, Gil Bahat, DevOps Engineer, Magisto Ltd. On Mon, Nov 16, 2015 at 4:15 PM, Klaus Darilion < klaus.mailinglists@pernau.at> wrote:
On 11.11.2015 16:32, Stephane Bortzmeyer wrote:
Is there an easy way to select probes, not on the origin AS, but on an AS upstream? Example: probe 23865, IP prefix announced by AS 56339 which currently has only one provider, AS 16080. Currently, Atlas tells me there are no probes in AS 16080...
I have the same problem quite often. For several important Backbone providers there aren't any probes. But there would be a lot of probes which are "behind" these ASes. Choosing this probes is of course not a guarantee that the targeted transit ISP is really used for routing (multihoming, peering) but I think in many cases this would work.
You RIPE guys build so cool systems, I think it would be easy for you to integrate RIS data into Atlas. So, if somebody searches for probes in an AS, you could also suggest probes from neighboring ASes (especially the ones which have only one neighbor AS). So for above case:
https://stat.ripe.net/data/asn-neighbours/data.json?resource=56339
If you do this lookup once a day and add the info to the probe information (maybe only using "left" neighbors), it could be used for probe selection.
regards Klaus
participants (4)
-
Gil Bahat -
Klaus Darilion -
Robert Kisteleki -
Stephane Bortzmeyer