[atlas] "Invalid target" error for RFC 1918 space

would be useful if VM probes could built for private networks to be scanned on a per user basis, would make is so much easier and cheaper to monitor internal vm clouds.
vm functionality as said before would be great for cost saving over physical hardware and also useful to test end probe user projects to add functionality for different types of service monitoring.

glad this thread prompted more debate :)

Colin

> On 18 Sep 2016, at 16:47, Robert Kisteleki <robert at ripe.net> wrote:
> 
> Hi,
> 
> On 2016-09-18 17:27, Colin Johnston wrote:
>> would be great to know how this is done, i assume blocked at controller
>> end and not at probe end as i could not see rfc 1918 blocks in probe
>> code
> 
> It's enforced in the UI/API as well as in the probe code. The probe part is
> in libbb/atlas_check_addr.c, available in the published source code.
> 
>> This would be so much easier to have vm code for probes so that
>> functionality like this could be enabled for private/vpn  network
>> monitoring with custom controller ends.
> 
> What would be the reason to make the VMs work differently? And if you had a
> VM, would you fiddle with the code running on it to make this possible?
> 
> Regards,
> Robert
> 
>> 
>> Colin
>> 
>>> On 18 Sep 2016, at 16:22, Stephane Bortzmeyer <bortzmeyer at nic.fr> wrote:
>>> 
>>> On Sun, Sep 18, 2016 at 10:19:52AM -0500,
>>> Yang Yu <yang.yu.list at gmail.com> wrote 
>>> a message of 9 lines which said:
>>> 
>>>> I got "Invalid target" error when I tried to create a measurement to
>>>> see how far some RFC 1918 prefixes got propagated (carrier not
>>>> properly filtering customer announcement). What is considered
>>>> invalid for each measurement type?
>>> 
>>> Security/privacy reasons: without this rule, people could scan private
>>> networks where a probe is hosted.
>>> 
>> 
>> 
>> 
>