- ripe-atlas - mailman.ripe.net

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

[atlas]Mail list archives
by Ahmed Abu-Abed 21 Oct '11

21 Oct '11

Hello, I just subscribed to the Atlas mail list and I am looking for the mail list archives, can anyone point me to it ? Cheers, -Ahmed

5 8

(no subject)
by Олеся О. 17 Oct '11

17 Oct '11

1 0

Probes, static network configuration and upcoming firmware
by Robert Kisteleki 10 Oct '11

10 Oct '11

Dear Atlas hosts, We're about to release a new firmware version that supports more built-in measurements as well as prepares the probes for the User Defined Measurements feature. We have recently discovered that there's a compatibility issue with the upcoming firmware and (non-DHCP) static network configuration. In order to avoid problems that would come up in this case, we have temporarily disabled the static network configuration panel. We are in the process of releasing a corrected firmware, and enable static configuration for this version automatically. For the probes that already have static configuration up and running: there's nothing you need to do, we'll make sure that during the upgrade these probes keep their static network configuration. We apologise for the inconvenience this may cause. Regards, Robert

1 0