[atlas] "Invalid target" error for RFC 1918 space
- Previous message (by thread): [atlas] "Invalid target" error for RFC 1918 space
- Next message (by thread): [atlas] "Invalid target" error for RFC 1918 space
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Robert Kisteleki
robert at ripe.net
Sun Sep 18 17:47:49 CEST 2016
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. >> > > >
- Previous message (by thread): [atlas] "Invalid target" error for RFC 1918 space
- Next message (by thread): [atlas] "Invalid target" error for RFC 1918 space
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]