This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/ripe-atlas@ripe.net/
[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 ]
Colin Johnston
colinj at mx5.org.uk
Sun Sep 18 17:27:34 CEST 2016
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 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. 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 ]