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