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