Hi Romain, Yep. There is a */4 hour job that tags probes. The job kicks healed probes away from the Sanatorium. Then the probes get assigned to a less loaded "normal" controller. You're welcome! wbr /vty On 3/11/20 2:31 PM, Romain Fontugne wrote:
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