Fwd: monitoring RFC1918 IPs
Hi there, I'd like to monitor a couple of internal routes from one of my probes, but I get this error: Ping: Field 'target' : Measurement target "10.23.0.1" is invalid. Is that a limit somewhere? possible to relax that for probes owned/operated by me? Thanks HEndrik
On 3.07.14 21:43 , Hendrik Visage wrote:
Hi there,
I'd like to monitor a couple of internal routes from one of my probes, but I get this error: Ping: Field 'target' : Measurement target "10.23.0.1" is invalid.
Is that a limit somewhere? possible to relax that for probes owned/operated by me?
Hi Hendrik, [Sorry for the latish response. The office was closed for our summer outing on Friday.] We do not allow this because the usefulness and semantics of such measurements is local and we assumed that this can be done with local resources outside of RIPE Atlas. Also we intended to prevent others 'snooping around' in local infrastructure. If allowing this for the probe host themselves is something more people want, we can certainly add it to the road-map. If this is a one-off, we can probably accommodate you with a "one-time special". Daniel
It would for useful for internal network monitoring for backup lans if such networks could be monitored via probes. also satellite networks nat internally in same fashion using internal network address space. Colin On 7 Jul 2014, at 10:18, Daniel Karrenberg <daniel.karrenberg@ripe.net> wrote:
On 3.07.14 21:43 , Hendrik Visage wrote:
Hi there,
I'd like to monitor a couple of internal routes from one of my probes, but I get this error: Ping: Field 'target' : Measurement target "10.23.0.1" is invalid.
Is that a limit somewhere? possible to relax that for probes owned/operated by me?
Hi Hendrik,
[Sorry for the latish response. The office was closed for our summer outing on Friday.]
We do not allow this because the usefulness and semantics of such measurements is local and we assumed that this can be done with local resources outside of RIPE Atlas. Also we intended to prevent others 'snooping around' in local infrastructure.
If allowing this for the probe host themselves is something more people want, we can certainly add it to the road-map.
If this is a one-off, we can probably accommodate you with a "one-time special".
Daniel
On Mon, Jul 7, 2014 at 11:24 AM, Colin Johnston <colinj@mx5.org.uk> wrote:
It would for useful for internal network monitoring for backup lans if such networks could be monitored via probes. also satellite networks nat internally in same fashion using internal network address space.
Same for 3G networks here in ZA that issues RFC1918 IPs, so to check the "speed"/response of your local link with the probe, necessitates a ping to a RFC1918 IP. My use case was for checking a VPN link, but yes, that is a local case, and the only real need I could come up for using my credits :)
On 7 Jul 2014, at 10:18, Daniel Karrenberg <daniel.karrenberg@ripe.net> wrote:
On 3.07.14 21:43 , Hendrik Visage wrote:
Hi there,
I'd like to monitor a couple of internal routes from one of my probes, but I get this error: Ping: Field 'target' : Measurement target "10.23.0.1" is invalid.
Is that a limit somewhere? possible to relax that for probes owned/operated by me?
Hi Hendrik,
[Sorry for the latish response. The office was closed for our summer outing on Friday.]
We do not allow this because the usefulness and semantics of such measurements is local and we assumed that this can be done with local resources outside of RIPE Atlas. Also we intended to prevent others 'snooping around' in local infrastructure.
If allowing this for the probe host themselves is something more people want, we can certainly add it to the road-map.
If this is a one-off, we can probably accommodate you with a "one-time special".
Daniel
On Jul 7, 2014, at 7:27 AM, Hendrik Visage <hvjunk@gmail.com> wrote:
On Mon, Jul 7, 2014 at 11:24 AM, Colin Johnston <colinj@mx5.org.uk> wrote:
It would for useful for internal network monitoring for backup lans if such networks could be monitored via probes. also satellite networks nat internally in same fashion using internal network address space.
Same for 3G networks here in ZA that issues RFC1918 IPs, so to check the "speed"/response of your local link with the probe, necessitates a ping to a RFC1918 IP.
My use case was for checking a VPN link, but yes, that is a local case, and the only real need I could come up for using my credits :)
Seems like they should be numbered with IPv6 addresses instead? :) Then this could work ... or can you work around this by using a DNS name that points to 1918 IP? - Jared
participants (4)
-
Colin Johnston -
Daniel Karrenberg -
Hendrik Visage -
Jared Mauch