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
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?
>> 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.