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