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 <bortzme...@nic.fr> wrote:
>>
>> On Sun, Sep 18, 2016 at 10:19:52AM -0500,
>> Yang Yu <yang.yu.l...@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.
>>
> 
> 
> 

Reply via email to