Re: [atlas] Running a probe behind a NAT66

[Roman Mamedov]

Hello,

Sorry for the noise, it appears the issue was due to a local misconfiguration
after all, the GUA IP used for NAT66 was getting removed and instantly readded
back to its interface every time DHCPv6 client renewed its lease from the ISP,
which was every 30 minutes. Not surprisingly that breaks all NAT66 mappings
made from/to that IP.

As also noted in my private E-Mail to Stephen, one issue highlighted here is
the lack of notification about such issues with the probe. For instance I
didn't notice that anything is wrong until almost a month later (and by then
it was already difficult to pinpoint these issues to the configuration changes
that I made earlier), as there is no E-Mail notification for probe connection
flapping, only for 60+ minutes periods of disconnection. So perhaps it would
be a good idea to consider adding more kinds of E-Mail notifications to Atlas
in the future.

If anyone is curious as to why NAT66 setup in the first place, my ISP only
provides a /64, and that's already "spent" on my main primary VLAN.  I don't
want to subnet the /64 further and have to run DHCPv6 everywhere. For security
reasons I want to place the probe into its own separate VLAN. So that one, as
well as numerous other guest/VM/untrusted VLANs get their own 66::/64s and
are then NAT'ed into the router's own IPv6.

Let me know if you have any better suggestions for these network conditions,
aside from "Get a Different ISP" (only one ISP in my area provides IPv6) or
"Demand More IPs" from the current ISP (very unlikely to be successful, they
even allocate only /64s to business-class connections, and on residential
those are also *dynamic*).

-- 
With respect,
Roman

Re: [atlas] No probes working today?

[Stephane Bortzmeyer]

On Tue, Jun 12, 2018 at 03:50:25PM +0200,
 Robert Kisteleki  wrote 
 a message of 21 lines which said:

> The data storage backend had a few hickups today, meaning results
> were queued and served with a delay around 10:00, 11:30 and
> 13:30-15:00. No results were lost.

I confirm it now works. Thanks.

Re: [atlas] No probes working today?

[Robert Kisteleki]

On 2018-06-12 15:06, Stephane Bortzmeyer wrote:
> DNS measurements don't start today, no probes are selected for a long
> time.
> 
> See for instance  (long
> delay) or
>  (no probes)

Dear Stephane,

The data storage backend had a few hickups today, meaning results were
queued and served with a delay around 10:00, 11:30 and 13:30-15:00. No
results were lost. The backend team is still investigating the cause for
these.

Sorry for the inconvenience this caused!

Regards,
Robert

[atlas] No probes working today?

[Stephane Bortzmeyer]

DNS measurements don't start today, no probes are selected for a long
time.

See for instance  (long
delay) or
 (no probes)

Re: [atlas] Running a probe behind a NAT66

[Philip Homburg]

On 2018/06/11 20:42 , Roman Mamedov wrote:
> I fully expect that you didn't account for such a setup in the controller
> infrastructure or possibly various "local IP is valid" checks and whatnot, but
> why this used to work fine before? Has there been any change on your side in
> April that would break this kind of setup?
> 

I started a TCP traceroute on your probe toward it's controller, but it
consistently fails after hop 2. I have no idea if that is related to
your NAT box.

https://atlas.ripe.net/measurements/14364300/

In general it is worth noting that Atlas has support for IPv4 NAT, such
as keeping track of the public address of a probe. This support in not
implemented for IPv6. So if you put a probe behind some kind of IPv6
NAT, the results may be confusing to other Atlas users.

Philip