Hi Viktor,
Thanks, I have learnt something, I didn't know about that Sanatorium
controller. Still I am amazed that these probes are doing that at the
exact same time, are all the probes tagged "Resolves AAAA/A Correctly"
at the same time?
Thanks,
Romain
On 3/11/20 8:50 PM, Viktor Naumov wrote:
Hi Romain,
I was wrong, the probe diagnostics works correctly. The probes seem
facing local DNS misconfiguration (cannot resolve controller) or not
allowed to connect to other controllers but Sanatorium. Such probes
connect to Sanatorium controller by IP address. When a probe is
connected to Sanatorium controller and tagged as "Resolves AAAA/A
Correctly" it gets kicked from Sanatorium to a normal controller which
it cannot connect due to mentioned reasons it gets into loop of
disconnects.
I also cannot exclude the probe USB flash corruption since it can lead
to weird probe behavior.
wbr
/vty
On 3/11/20 9:32 AM, Viktor Naumov wrote:
Hi Romain,
I'm checking what the problem can be. Art first glance it looks like a
false positive in the probe diagnostics system. It causes probe
redirect to the "Sanatorium" controller and connection flips.
I will be back to you.
wbr
/vty
On 3/11/20 6:04 AM, Romain Fontugne wrote:
Hi,
I found that the following probes are reported disconnected for
several hours a day, more or less at the same time, but all their
built-in measurements are there and seem normal:
https://atlas.ripe.net/probes/32639/#!tab-network
https://atlas.ripe.net/probes/28818/#!tab-network
https://atlas.ripe.net/probes/19107/#!tab-network
https://atlas.ripe.net/probes/14831/#!tab-network
https://atlas.ripe.net/probes/11982/#!tab-network
These probes are in different ISPs and locations in Japan.
Any idea why this is happening? something funky on the controllers side?
Thanks,
Romain
