From astrikos at ripe.net Wed Feb 9 12:59:35 2011 From: astrikos at ripe.net (Andreas Strikos) Date: Wed, 9 Feb 2011 12:59:35 +0100 Subject: [atlas]Atlas website upgrades Message-ID: <475C75FC-1FA8-4AB6-B7A2-5E4B838879DA@ripe.net> Hi, Today, in sync with the new Ripe NCC website we are upgrading Ripe Atlas website. You might encounter strange behaviors on some pages but we believe until the end of the day they will be fixed. Except from the template, there are some other changes in UI like a new tab for public probes and a bigger settings button. Also, from now on there will be an announcement page where you can read the latest information about Atlas. Regards, Andreas From rbarnes at bbn.com Wed Feb 16 07:44:59 2011 From: rbarnes at bbn.com (Richard L. Barnes) Date: Wed, 16 Feb 2011 01:44:59 -0500 Subject: [atlas]Down/Up fail Message-ID: <38811C60-E3F8-471A-B1DE-E89D58318EBA@bbn.com> 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 From robert at ripe.net Wed Feb 16 09:50:10 2011 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 16 Feb 2011 09:50:10 +0100 Subject: [atlas]Down/Up fail In-Reply-To: <38811C60-E3F8-471A-B1DE-E89D58318EBA@bbn.com> References: <38811C60-E3F8-471A-B1DE-E89D58318EBA@bbn.com> Message-ID: <4D5B8FC2.3040308@ripe.net> 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 From rbarnes at bbn.com Wed Feb 16 14:24:59 2011 From: rbarnes at bbn.com (Richard L. Barnes) Date: Wed, 16 Feb 2011 08:24:59 -0500 Subject: [atlas]Down/Up fail In-Reply-To: <4D5B8FC2.3040308@ripe.net> References: <38811C60-E3F8-471A-B1DE-E89D58318EBA@bbn.com> <4D5B8FC2.3040308@ripe.net> Message-ID: It appears to be back up now, so perhaps it's just a lag issue. --Richard On Feb 16, 2011, at 3:50 AM, Robert Kisteleki wrote: > 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 >