[atlas] Any way to select the probes from upstream AS (not origin AS)?

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 at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ripe.net/ripe/mail/archives/ripe-atlas/attachments/20151116/f922480b/attachment.html>