November 2011 - ripe-atlas - mailman.ripe.net

problems with (links to) stat.ripe.net
by Wilfried Woeber, UniVie/ACOnet 28 Nov '11

28 Nov '11

Just wanted to double-check... Are you aware of problems - or do others see similar effects - with the display of pages that are linked to from the Atlas panels? IE7 (on XP) complains with "error on page" and Iceweasel on Debian does not complain, but doesn't display any useful information either. As an aside, with Iceweasel the "Result Boxes" rectangle seems to be pinned to a fixed place on the screen and obstructs the information when the page is scrolled underneath. Just wanted to raise a small flag before doing screenshots and other investigations. Thanks for listening, Wilfried.

2 1

no gateway for IPv6
by Wilfried Woeber, UniVie/ACOnet 24 Nov '11

24 Nov '11

Hi folks, just noticed that for an IPv6-capable probe no gateway info/address is given. Curiousity - is there an "good reason" for that behaviour or is it just not implemented yet? Lowest prio, of course :-) Wilfried.

2 1

More maps available
by Robert Kisteleki 22 Nov '11

22 Nov '11

Dear Atlas Users, Today we've enabled the "DNS root anycast instance map" that was announced at the RIPE meeting and in the RIPE Labs article here: https://labs.ripe.net/Members/kistel/new-ripe-atlas-features-in-the-making Clicking on the "Maps" link in the menu bar (top right) leads you to a page that lists all maps we have available at the moment, including the anycast map. As a small enhancement we also begun to link AS and prefix information to RIPEstat, to facilitate looking up more information about these resources. This is visible on the "my probes" page as well as on various maps (when clicking on individual probes). Regards, Robert (for the whole team)

1 0

Outage on one UI server
by Robert Kisteleki 11 Nov '11

11 Nov '11

Dear All, One of our UI servers is down at the moment. We've been trying hard to restore it for some hours now, but there's a chance that we'll not succeed before next week. The result is that for a subset of the probes we're currently not generating RRD graphs. The affected probes are ID<=500 and ID>=2000. We do not expect data loss, as all results are stored on intermediary nodes, however you'll not see these results until the issue is fixed. Please accept our apologies for the inconvenience this may cause. Regards, Robert Kisteleki

1 0

packet loss seen by probes to labs.ripe.net?
by Wilfried Woeber, UniVie/ACOnet 06 Nov '11

06 Nov '11

Dear Atlas Team, it looks like many (or even most/all?) of the probes seem to "seen" an increasing rate of packet loss to destination labs.ripe.net (on IPv4). The problem(?) seems to have started around Week 41 and gets worse since. Could the Atlas Team have a look at that? Thanks, Wilfried.

6 10

[atlas]Feature request: tag downtime
by Bengt Gördén 03 Nov '11

03 Nov '11

Hi, Would it be possible to make some tagging functionality on the web page due to reasons as downtime etc.? For me it would be nice due to maintenance or similar. It would also be a courtesy to the upstream network in the future event that the statistics would be public (or at least semi public). /bengan

3 3

j.root-servers.net ICMP?
by Marco Davids 03 Nov '11

03 Nov '11

Hi, Can anyone elaborate on why my Atlas probe is still trying to ping j.root-servers.net, while this seems futile since a few weeks?

4 4

follow-up on private discussion regarding management of access to probe measurement data
by Wilfried Woeber, UniVie/ACOnet 02 Nov '11

02 Nov '11

Hi Vesna, Team, here is my reminder regarding the suggested "better" granularity to manage the access to measurement data per probe. As I see it right now (please feel free to correct me!): - right now there is an "individual" guardianship per probe(s), this guardianship includes configuration access. - regarding access to the measurement data, the guardian only has two option to manage the access privileges - private and public, or simply put: white or black. Now, given that different persons are managing different probes, if I want to grant access for them, or apply for access to the data of probes under their control, the only way to accommodate this is to declare the probe(s) involved "public". That is not necessarily what we want. Thus I am asking for a sort of "intermediate" or "group" access category. I can see a couple of ways to help with this, for example by providing a way to add other user identities to be authorized for (non-config, i.e. read-only) access. An alternate approach could be to allow creation of Groups, into which some probes could be put and which user identities could be added to for access to the probes in the group. Of course any other approach would be equally fine with me, I just tried to come up with a least one idea instead of only asking for added functionality :-) Btw, my feeling is that such a facility would be even more useful in support for the upcoming UDM stuff! Thanks for reading as far, Wilfried.

1 0

3d downtime reported - why?
by Daniel AJ Sokolov (lists) 02 Nov '11

02 Nov '11

Hello, I have noticed that my probe data on the atlas.ripe.net-website reports at downtime of over 3 days: 2011-10-25 04:17:20 UTC to 2011-10-28 08:04:53 UTC. In fact, my connection was not down - maybe a few minutes (that seems to happen regularly), but everythin longer we would have noticed. We use this internet connection most of the day. My probe ID is not unter 500 but over 1000. Is this an error in the database, a problem with the reporting system or any other known bug? Did anyone else experience something like this? Or is there some issue I can resolve locally? Thank you Daniel AJ -- My twitter feed: @newstik http://twitter.com/newstik

4 4