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/[email protected]/
[atlas]Down/Up fail
- Previous message (by thread): [atlas]Down/Up fail
- Next message (by thread): [atlas]Down/Up fail
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Robert Kisteleki
robert at ripe.net
Wed Feb 16 09:50:10 CET 2011
On 2011.02.16. 7:44, Richard L. Barnes wrote: > Hey guys, > > I've just been re-engineering my home network to give probe 394 more > stable access. > > It seems that the ATLAS web site still reports it as "down" even though > it's clearly reporting information to the central system (since the RRD > graphs are updated). > > Huh? > > --Richard Hi, Your probe is/was behind (at least) two levels of NAT, so anything is possible :-) More seriously: our controller in LA, which is responsible for your probe, got disconnected around midnight CET, thus it couldn't report connections from probes; this is why your probe was reported as "down". We reconnected it some minutes ago, so these buffered messages could finally go through. The reason you probe could still report measurement data to the system is entirely different. We are in the middle of an internal structural change, which allows us to report measurement data on a separate, more scalable channel. Our controller in LA was the first one to be switched to this method (just yesterday!). We are migrating other (EU) controllers to this new method in the coming days. Also, we plan to use this method for more messages in the future, making the system more resilient against these disconnection hickups. Hope that clarifies! Robert
- Previous message (by thread): [atlas]Down/Up fail
- Next message (by thread): [atlas]Down/Up fail
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]