- ripe-atlas - mailman.ripe.net

Request to test TCP and UDP to the root servers separately.
by Leo Bicknell 23 Mar '12

23 Mar '12

My day job has had some interesting discussions lately about TCP to the root servers based on a few odd behaviors we've had reported to us over the past few years. There aren't any surprises in this data, it's been known for a long time some people think DNS is UDP only for instance, some firewalls are broken, and so on. What we realized though is that there is no wide-spread measurement of how often TCP is a problem. Immediately my thought went to the Atlas probe network. It's distributed enough it could give an interesting indication of how often TCP DNS fails compared to UDP DNS. Perhaps the rates are so similar it's a non-issue, perhaps TCP fails much more often. Would it be of interest to the Atlas community to have the probes try and query "." via both UDP and TDP from each of the 13 root servers (perhaps v4 and v6 separately), report back that data, and then generate a report on the results? I would be happy to assist in preparing or presenting a report on the results! -- Leo Bicknell - bicknell(a)ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/

4 7

Fwd: Probe 2317 is down
by Colin Johnston 19 Mar '12

19 Mar '12

hey no idea why probe is down, powered it on and off. defo has comms and dynamic ip also connectivity seems good as well ? Any ideas ? Col Begin forwarded message: > From: RIPE Atlas <atlas(a)ripe.net> > Date: 18 March 2012 14:00:01 GMT > To: colin johnston <colinj(a)mx5.org.uk> > Subject: Probe 2317 is down > > Dear colin, > > Your probe 2317 is down since 2012-03-18 13:11:17 UTC > > This is an automatically generated email from RIPE Atlas. It was sent to you because you asked to be notified if your probe goes is down for more than 30 minutes. > > If you want to change this, or disable this notification altogether, please go to https://atlas.ripe.net/atlas/myprobes.html, click on probe 2317, in the opened tab select Probe's Settings -> Notifications and change your settings. > > Atlas team

2 2

Small changes deployed on this Wednesday
by Robert Kisteleki 16 Mar '12

16 Mar '12

Dear Atlas Users, On Wednesday we've deployed some changes to the UI. The most notable change is that from now on the download format of your probe's measurement data is JSON. The actual syntax is pretty much self-explanatory. The DNS anycast map now visualises server versions and SOA serials too. We made further changes to the way we show static network configuration of a probe on the "probe status" page. We also did some preparations to include Atlas in RIPE NCC Access, the RIPE NCC Single Sign On system. Regards, Robert, for the RIPE Atlas team

1 0

ghostgraz.com
by Simon Josefsson 14 Mar '12

14 Mar '12

I was debugging my local DNS resolver when I noticed peculiar lookups from the Atlas probe for 'ghostgraz.com'. It seems to happen once in a while. Does anyone have any idea what this is? I don't see it in the list of built-in measurements, and I don't recall configuring anything related to that site myself. /Simon 14-Mar-2012 08:55:36.732 client 192.168.1.48#58740: query: ghostgraz.com IN AAAA + (192.168.1.47) 14-Mar-2012 08:55:36.734 client 192.168.1.48#40389: query: ghostgraz.com.lan IN AAAA + (192.168.1.47) 14-Mar-2012 08:55:36.737 client 192.168.1.48#44142: query: ghostgraz.com IN AAAA + (192.168.1.47) 14-Mar-2012 08:55:36.740 client 192.168.1.48#59254: query: ghostgraz.com.lan IN AAAA + (192.168.1.47) 14-Mar-2012 08:55:36.742 client 192.168.1.48#56991: query: ghostgraz.com IN AAAA + (192.168.1.47) 14-Mar-2012 08:55:36.745 client 192.168.1.48#59319: query: ghostgraz.com.lan IN AAAA + (192.168.1.47) 14-Mar-2012 08:55:36.769 client 192.168.1.48#55435: query: ghostgraz.com IN A + (192.168.1.47) 14-Mar-2012 08:55:56.001 client 192.168.1.48#49742: query: caldwell.atlas.ripe.net IN AAAA + (192.168.1.47) 14-Mar-2012 08:55:56.146 client 192.168.1.48#34211: query: caldwell.atlas.ripe.net IN A + (192.168.1.47) 14-Mar-2012 08:58:38.199 client 192.168.1.48#42327: query: ghostgraz.com IN AAAA + (192.168.1.47) 14-Mar-2012 08:58:38.202 client 192.168.1.48#53097: query: ghostgraz.com.lan IN AAAA + (192.168.1.47) 14-Mar-2012 08:58:38.204 client 192.168.1.48#54101: query: ghostgraz.com IN AAAA + (192.168.1.47) 14-Mar-2012 08:58:38.207 client 192.168.1.48#52439: query: ghostgraz.com.lan IN AAAA + (192.168.1.47) 14-Mar-2012 08:58:38.210 client 192.168.1.48#37104: query: ghostgraz.com IN AAAA + (192.168.1.47) 14-Mar-2012 08:58:38.212 client 192.168.1.48#59275: query: ghostgraz.com.lan IN AAAA + (192.168.1.47) 14-Mar-2012 08:58:38.216 client 192.168.1.48#49299: query: ghostgraz.com IN A + (192.168.1.47) 14-Mar-2012 09:01:28.778 client 192.168.1.48#58887: query: ghostgraz.com IN AAAA + (192.168.1.47) 14-Mar-2012 09:01:28.781 client 192.168.1.48#52689: query: ghostgraz.com.lan IN AAAA + (192.168.1.47) 14-Mar-2012 09:01:28.784 client 192.168.1.48#40593: query: ghostgraz.com IN AAAA + (192.168.1.47) 14-Mar-2012 09:01:28.787 client 192.168.1.48#51568: query: ghostgraz.com.lan IN AAAA + (192.168.1.47) 14-Mar-2012 09:01:28.790 client 192.168.1.48#36493: query: ghostgraz.com IN AAAA + (192.168.1.47) 14-Mar-2012 09:01:28.792 client 192.168.1.48#33057: query: ghostgraz.com.lan IN AAAA + (192.168.1.47) 14-Mar-2012 09:01:28.796 client 192.168.1.48#49588: query: ghostgraz.com IN A + (192.168.1.47) 14-Mar-2012 09:01:34.977 client 192.168.1.48#35392: query: www.ripe.net IN A + (192.168.1.47)

4 6

probe 466 running unattended
by Wilfried Woeber, UniVie/ACOnet 05 Mar '12

05 Mar '12

Dear Atlas-Team! I am almost on my way to Costa Rica for the next ICANN meeting, and taking some time off before, and - more extensively :-) - after. Thus my probe at home, #466, may go offline if there's an environmental or ISP-upstream problem, that prevents its automatic recovery. I am scheduled to be back home around the Easter weekend, probably on Sunday, April 8th. Also, the probe in my office, #414, runs unattended during that period, but you are welcome to contact <noc(a)aco.net> for hands and eyes to get it back up, just in case. Best regards, Wilfried.

2 1

Proble rebooting several times a day.
by Lukasz Trabinski 23 Feb '12

23 Feb '12

Hello Why my probe (id 2598, Firmware Version: 4280) rebooting several times a day? My routers and uplinks connections works correctly and stable. Internet Address: Connect at: Disconnect at: Up time: Down time (until next connection): 2001:1a68:a::56 2012-02-22 08:56:46 UTC (still connected) 0d, 3h, 59m (still connected) 2001:1a68:a::56 2012-02-22 07:48:06 UTC 2012-02-22 08:53:05 UTC 0d, 1h, 4m 0d, 0h, 3m 2001:1a68:a::56 2012-02-22 03:50:31 UTC 2012-02-22 07:44:41 UTC 0d, 3h, 54m 0d, 0h, 3m 2001:1a68:a::56 2012-02-21 17:04:30 UTC 2012-02-22 03:47:02 UTC 0d, 10h, 42m 0d, 0h, 3m 2001:1a68:a::56 2012-02-21 07:33:19 UTC 2012-02-21 16:57:49 UTC 0d, 9h, 24m 0d, 0h, 6m 2001:1a68:a::56 2012-02-21 04:42:18 UTC 2012-02-21 07:29:42 UTC 0d, 2h, 47m 0d, 0h, 3m 2001:1a68:a::56 2012-02-20 10:35:17 UTC 2012-02-21 04:35:13 UTC 0d, 17h, 59m 0d, 0h, 7m 2001:1a68:a::56 2012-02-19 14:55:21 UTC 2012-02-20 10:31:40 UTC 0d, 19h, 36m 0d, 0h, 3m 2001:1a68:a::56 2012-02-19 10:34:47 UTC 2012-02-19 14:51:58 UTC 0d, 4h, 17m 0d, 0h, 3m 2001:1a68:a::56 2012-02-19 04:35:15 UTC 2012-02-19 10:31:17 UTC 0d, 5h, 56m 0d, 0h, 3m 2001:1a68:a::56 2012-02-19 01:05:26 UTC 2012-02-19 04:31:43 UTC 0d, 3h, 26m 0d, 0h, 3m 2001:1a68:a::56 2012-02-18 23:54:45 UTC 2012-02-19 01:01:59 UTC 0d, 1h, 7m 0d, 0h, 3m 2001:1a68:a::56 2012-02-18 23:02:20 UTC 2012-02-18 23:51:06 UTC 0d, 0h, 48m 0d, 0h, 3m 2001:1a68:a::56 2012-02-18 22:23:42 UTC 2012-02-18 22:52:58 UTC 0d, 0h, 29m 0d, 0h, 9m 2001:1a68:a::56 2012-02-18 18:55:25 UTC 2012-02-18 22:13:36 UTC 0d, 3h, 18m 0d, 0h, 10m 2001:1a68:a::56 2012-02-18 02:50:04 UTC 2012-02-18 18:51:44 UTC 0d, 16h, 1m 0d, 0h, 3m 2001:1a68:a::56 2012-02-18 01:02:47 UTC 2012-02-18 02:46:09 UTC 0d, 1h, 43m 0d, 0h, 3m 2001:1a68:a::56 2012-02-17 19:34:11 UTC 2012-02-18 00:59:04 UTC 0d, 5h, 24m 0d, 0h, 3m 2001:1a68:a::56 2012-02-17 14:08:25 UTC 2012-02-17 19:30:28 UTC 0d, 5h, 22m 0d, 0h, 3m 2001:1a68:a::56 2012-02-17 13:14:37 UTC 2012-02-17 14:04:52 UTC 0d, 0h, 50m 0d, 0h, 3m

10 17

Port 21
by xs 22 Feb '12

22 Feb '12

Why probe have port 21 opened? -- Ta wiadomość zawiera poufne informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę, prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. Odmienne zachowanie jest niezgodne z interesem (xs, 1993-2011) i może naruszać prawo.

4 4

OT(?) SamKnows/EC Test Project
by Wilfried Woeber, UniVie/ACOnet 21 Feb '12

21 Feb '12

Maybe this is a tad off-topic, but maybe not... Has anyone been able to get in touch with a human being (over eMail) regarding the participation in their measurement project? Any and all of my attempts till now failed miserably, they just keep sending me reminders to accept their fine print; and I am just about to pull out/unsubscribe. Any input or advice gratefully accepted. Best regards, Wilfried.

7 9

Re: [atlas] OT(?) SamKnows/EC Test Project
by Stephane Bortzmeyer 17 Feb '12

17 Feb '12

On Wed, Feb 15, 2012 at 04:24:25PM +0100, Stephane Bortzmeyer <bortzmeyer(a)nic.fr> wrote a message of 13 lines which said: > > Did you receive your SamKnows box already btw? > > No. Two hours after, it arrived :-) http://www.bortzmeyer.org/samknows.html

2 1

Protocol/Technology testing?
by Daniel AJ Sokolov 15 Feb '12

15 Feb '12

Hello, Are there any plans to extend the Atlas probe's functionality from simple Pings to more sophisticated testing? For example: Can actual payloads be transferred (http, ftp, SMTP, NNTP etc.) and with which parameters? Is encryption available (https, ssh, starttls, etc.)? Some countries and/or ISPs restrict what users can do. Currently, Iran is inhibiting all encrypted international connection. For the users on the ground this is horrible - no gmail, no yahoo, no online banking, no Tor network - no proivacy! Yet on the Atlas network everything seems to be fine, as pings still work. (However, only one of the six probes is online, the rest has been offline for weeks. And the one that is online was offline for weeks until a few days ago. I'm not sure what the issue is there.) It would be good to know if some protocols are not available in a certain jurisdiction. Of course, such tests could be done at a much lower rate than Pings - some maybe every hour, others every couple of hours. Then again, the probes might not be mighty enough? BR Daniel AJ -- Follow me on twitter @newstik http://twitter.com/newstik

8 11

Probe DNS entry A more useful than AAAA for dynamic IP hosts
by Software Registrations 14 Feb '12

14 Feb '12

Hello everybody, I have just received and put in service my probe. This is my first post to the list (I have been monitoring the traffic for a while: none). I wish to take the chance to admire the design and compact packaging ! Great work! Back on topic, for us low-lies with dynamic IP addresses using the probe DNS entry (maybe with a CNAME entry) could be a great way to ensure our Dynamic DNS entries are up to date and our network could be reached from remote. I am running a full IPv6 network receiving a /48 from Hurricane Electric and the probe tend to select (at least in my short experience) the autoconfigure (from MAC) IPv6 address as its Internet Address to use in the DNS record: fabio@atlantic:~$ host -t A pdxxxxx.probes.atlas.ripe.net pd456a699.probes.atlas.ripe.net has no A record fabio@atlantic:~$ host -t AAAA pdxxxxx.probes.atlas.ripe.net pd456a699.probes.atlas.ripe.net has IPv6 address 2001:470:xxxx:2:220:4aff:fee0:xxxx fabio@atlantic:~$ I saw that there are plans (in the FAQ) to add support both for AAAA and A records at the same time but I believe it would be beneficial for users to be able to select which record is generated or have the A record as default while waiting for the support for both to be implemented. Thanks for listening. Fabio

2 4

Re: [atlas] New measurement target suggestion: 6to4 anycast
by Konstantin V Bekreyev 06 Feb '12

06 Feb '12

Hello, Please inform me your decision about this interesting matter: >> I'd like to suggest adding to the list of monitored addresses a new one: >> >> 192.88.99.1 - 6to4 anycast IPv4 to IPv6 gateway; >> >> This could provide interesting data on what percentage of networks >> have this address blocked/inaccessible (resulting in broken >> operation of 6to4), and also what is the average latency to the >> closest 6to4 gateway across various countries/regions. >> >> The next step would possibly be the collection of statistics which >> ASes 'see' whose 6to4 gateways, this can be inferred from the AS of >> the traceroute hop that is right before the 192.88.99.1 on the trace. > It seems that there is interest for doing this measurement, so we'll add it to the list -- most likely in January, after the holiday break. Maybe we'll see some interesting results before June 6. Could you add it, please? -- With best regards, Konstantin V Bekreyev (CVB-RIPE) DARS Telecom (AS43782), Ulyanovsk, Russia

1 0

Tweaking RRDs for built-in measurements UPDATE
by Pavel V. Veselovskiy 06 Feb '12

06 Feb '12

Hello, For our purposes, we use RRD image generator and get plots from the different probes. We used the recommendations that described on this page: http://atlas.ripe.net/doc/api . We found, that this information is not actual. So we would like to suggest you to update it: • probe ID < 500: zpm01.atlas.ripe.net. • probe ID >= 500 and probe ID < 1000: zpm02.atlas.ripe.net. • probe ID >= 1000 and probe ID < 2000: zpm03.atlas.ripe.net. • probe ID >= 2000 and probe ID < 3000: zpm04.atlas.ripe.net. In addition, it would be nice if the page with the documentation will contain more extensive and detailed information about the API. -- Thanks in advance & Best Regards -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- Pavel Veselovskiy Email: pavelveselovskiy(a)gmail.com Phone: +7 927 686 12 32

3 2

Minor spelling error on probe settings popup
by Richard Craven 05 Feb '12

05 Feb '12

Hello Looking at http://atlas.ripe.net/atlas/myprobes.html and going to Probe's settings | notifications, it says "if downtime longer then (minutes):" but it should say "if downtime longer than (minutes):" "than", instead of "then". Best wishes

1 0

Transfer graphs
by Roman Mamedov 03 Feb '12

03 Feb '12

Hello, Is there any logic in the placement of the upper two graphs? http://ompldr.org/vY2xhZQ/2012-02-02T155731Z-atlas.png Looks like they were dropped randomly somewhere onto the page, without any concern of how they would fit with the rest of the content. -- With respect, Roman ~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Stallman had a printer, with code he could not see. So he began to tinker, and set the software free."

4 4

Possible issue with DNS/tests getting stuck?
by Kyriacos Sakkas 27 Jan '12

27 Jan '12

Dear all, I have a statically configured probe, FW version 4270. If the internet connection goes down/flaps the probe seems to get confused and stops communicating (is shown as Down) even when the connection is back up and stable, but can actually be pinged etc from inside and outside my network fine. I have a second probe that is on DHCP (FW 4280) on a different network, this one seems not to have the same issue, don't know which is the important differentiator. Wondering if anyone has similar issues and a solution other than switch it off and on again. Thanks to All, Kyriacos

2 2

Survey results on Atlas open-sourcing
by Richard L. Barnes 05 Jan '12

05 Jan '12

The brief survey I put out a couple weeks ago has gotten 34 responses. The response rate seems to be tailing off, so I've closed the survey. Here's a summary of results. First, the simple things: -- All but one respondent is an Atlas probe host. -- Respondents preferred source to binary release 26:4 (4 abstentions) The responses as to reasons for wanting the Atlas platform opened up are a little more challenging to read. There were four options that respondents, from which respondents could choose as many as they wanted. 0 - I'm not interested in RIPE NCC releasing the Atlas firmware 1 - So that parties other than RIPE to build probes that can feed into the Atlas system 2 - So that I can easily build Atlas-like probes for my own, independent measurement network 3 - So that I can re-use some Atlas features for a non-measurement-related purpose The response patterns, ordered by frequency Pattern Frequency 1 8 2+3 6 0 5 1+2 3 1+2+3 3 2 3 3 1 (who noted: "I don't care too much") Respondents could also fill in an "other" response for their reason. There were two major themes to these responses: -- Security, in the sense both of making the device more secure, and of assuring probe hosts of what the device is doing -- Contributions, i.e., that the community could contribute to probe development One respondent also noted in an "other" response that responses 1 and 2 are not necessarily mutually exclusive; a modified probe could feed both the RIPE system and a private system. Analyze as you will :) --Richard

8 14

Probe location
by Rodolfo kix Garcia 29 Dec '11

29 Dec '11

Hi, what's the method to set the probe location? When I set up my probe, I locate it in the nearest subway station (of course, is not there), but now in the map the probe is too near of my home. The probe location is moved about 300 meters. Are you using other method to locate the probe (IP addresses, Google wifi map,...)? Cheers. kix -- ||// //\\// Rodolfo "kix" Garcia ||\\// //\\ http://www.kix.es/

2 1

Reasons to celebrate - passed 1K active probes :)
by Vesna Manojlovic 28 Dec '11

28 Dec '11

Hi everyone, *you* are part of our big success: more then 1024 probes before the end of this year! We've published an article on Labs about that yesterday: https://labs.ripe.net/Members/becha/ripe-atlas-has-reasons-to-celebrate Thank you very much for participating in this exciting project, and Happy New Year! Vesna

8 19

Happy UDM & Happy New Year :)
by Vesna Manojlovic 23 Dec '11

23 Dec '11

Dear all, One more article on RIPE Labs: about User Defined Measurements: https://labs.ripe.net/Members/becha/happy-beta-testers-of-atlas-udm Thank you for your feedback and contribution! Regards, Vesna

1 0

New measurement target suggestion: 6to4 anycast
by Roman Mamedov 21 Dec '11

21 Dec '11

Hello, I'd like to suggest adding to the list of monitored addresses a new one: 192.88.99.1 - 6to4 anycast IPv4 to IPv6 gateway; https://en.wikipedia.org/wiki/6to4 https://tools.ietf.org/html/rfc3068 This could provide interesting data on what percentage of networks have this address blocked/inaccessible (resulting in broken operation of 6to4), and also what is the average latency to the closest 6to4 gateway across various countries/regions. The next step would possibly be the collection of statistics which ASes 'see' whose 6to4 gateways, this can be inferred from the AS of the traceroute hop that is right before the 192.88.99.1 on the trace. -- With respect, Roman ~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Stallman had a printer, with code he could not see. So he began to tinker, and set the software free."

4 3

Algortithm for probe detecting its offline
by Greg B - NANOG 21 Dec '11

21 Dec '11

Hi, I wanted to ask what is the algorithm / methodology used for a probe detecting / reporting it is offline? I ask, because this morning I intentionally rebooted my cable modem on the network the probe is attached to, which brought my internet down for about 1-2 minutes (I was using the internet immediately after the cable modem re-synched), but the probe is reporting that outage as a 29 minute outage rather than a few minutes. Any comments on why there should be such a large variance from my actual experience versus what the probe saw? -Greg

2 1

New: Atlas resource coverage (and more maps!) beta
by Robert Kisteleki 16 Dec '11

16 Dec '11

Dear Atlas Users, Today we enabled another interesting feature (in beta mode, for now): details about what networks Atlas covers at the moment. This feature lists IPv4/IPv6 prefixes, ASNs and countries. This information will also be used for User Defined Measurements, in order to filter vantage points to specific networks or locations. You can access this at https://atlas.ripe.net/atlas/coverage.html Background information: * the prefixes and ASNs are looked up in RIS, based on the address of the probe * the country code is looked up in OpenStreetMaps based on the probe geolocation We are aware that in some cases the lookup has a surprising result. One example is 6to4: for IPv6 related ASNs the prefix is 2002::/16 but the ASN can be misleading. We'll most likely stop looking up ASNs for 6to4 (and Teredo) prefixes. If you see anomalies *not* related to this, you can let us know at atlas-dev(a)ripe.net Regards, Robert, for the whole team

2 2

Re: [atlas] Email or SMS alert when probe goes offline/online
by Greg B - NANOG 15 Dec '11

15 Dec '11

Hi, I see there was a thread started back on September 7, 2011 with subject: Email or SMS alert when probe goes offline/online this was prior to me joining the mailing list. I'd like to voice my support for a user-configurable amount of time for the Atlas system to send out an email notification that your probe is down (and returned to service). My probe which I run on my home internet connection was apparently down for 3.5 days before I just happened to login to look at the stats. Considering I was at home for much of these 3.5 days, and my Internet connection was working, I assume the probe crashed because simply power-cycling it "fixed" the problem. I know that if I got an email ~15 minutes after the probe was down, my probes downtime would probably have been closer to about 30 minutes rather than 3.5 days. Thanks. -Greg

4 4

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

[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

Re: [atlas] The letter from the student of Samara State Aerospace University
by Егоров Павел 05 Oct '11

05 Oct '11

On 28-30 November 2011 the ENOG 2/RIPE NCC Regional Meeting will take place. Registration is free and I think you'll get all required information about Atlas there. -- Pavel Yegorov

1 0

Re: [atlas] The letter from the student of Samara State Aerospace University
by Artem Onoprienko 03 Oct '11

03 Oct '11

I haven't received the answer, so I duplicate this letter I am interested in project RIPE ATLAS http://meeting.afrinic.net/afrinic-13/images/stories/af13_presentation/AF-1… Sukhov Andrey Mihailovich is the supervisor of my diploma project (his mail: amskh(a)yandex.ru). He has recommended to me to write to you that letter. I want to understand how ripe atlas probe works 23 september 2011, 13:58 from "Wilfried Woeber, UniVie/ACOnet" <Woeber(a)CC.UniVie.ac.at>: > Artem Onoprienko wrote: > [...] > > But I found no technical documentation about RIPE’s construction, > > and it’s electrical components. > > I would be grateful if you would give a link to documentation about > > hardware and software construction of the Ripe TestBox. > > I am slightly confused - is this referring to the (traditional) TTM Boxes > or the newer Atlas thumb-probes? > > > It will be great help for me. > > With best regards Artem Onoprienko > > And last but not least, what are the subscribers of this list expected to > do with this request? > > Regards, > Wilfried. >

1 0

The letter from the student Samara State Aerospace University
by Artem Onoprienko 23 Sep '11

23 Sep '11

Hello, I’m a student of Samara State Aerospace University. My name is Artem Onoprienko. I study at electronis engineering faculty with specialization in network technologies. I'm going to write a thesis project. I would like to be engaged in monitoring mechanisms of the Internet, and both hardware, and software part. In my work I would like to consider the possibility of additional quality criteria according to the IETF RFC 2544, and the work being done in the Samara State Aerospace University ( http://arxiv.org/abs/0907.3710 This work was presented at the conference in Lisbon. In this work, to measure the bandwidth using network testing packages of various sizes) As a first step I would like to see the ability to add these features to the RIPE Test Box. But I found no technical documentation about RIPE’s construction, and it’s electrical components. I would be grateful if you would give a link to documentation about hardware and software construction of the Ripe TestBox. It will be great help for me. With best regards Artem Onoprienko

2 1

Atlas infrastructure upgrades
by Robert Kisteleki 12 Sep '11

12 Sep '11

Dear Atlas users, During the course of this week, we'll be busy with a major upgrade to virtually all components of the Atlas infrastructure. This affects the UI, the backend database, and the probe controllers as well. Please don't be alarmed when your probe disconnects, or if you cannot reach the web interface. We apologize the inconvenience this may cause. Regards, Robert

1 0

Re: [atlas] Email or SMS alert when probe goes offline/online
by Roman Mamedov 08 Sep '11

08 Sep '11

On Wed, 7 Sep 2011 12:35:42 +1000 "Robert" <robert(a)robert.id.au> wrote: > What do other participants think about having email alerts when a probe goes > offline or online? Wasn't something like this implemented just recently? --------------------------------------------------------------------------------------------------------- From: Robert Kisteleki <robert(a)ripe.net> To: ripe-atlas(a)ripe.net Subject: [atlas]Atlas current news Date: Thu, 14 Jul 2011 14:46:26 +0200 Sender: ripe-atlas-admin(a)ripe.net User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 Organization: RIPE NCC Dear Atlas users, We've added two new features to RIPE Atlas recently: 1. Automatic notification about down probes: if your probe has been down for some time, you'll get a one-time automatic notification. This happens after five consecutive days of downtime. 2. Static network configuration: after the testing round with volunteers, we decided to make this feature publicly available, thus released the 4.030 firmware version. You can read more about this feature at https://atlas.ripe.net/doc/static-config Regards, Robert Kisteleki, for the RIPE Atlas Team -- With respect, Roman

6 5

R: Email or SMS alert when probe goes offline/online
by Simone Nulchis 07 Sep '11

07 Sep '11

Hi all, >What do other participants think about having email alerts when a probe goes offline or online? I think it could be a nice feature; in my opinion it should be implemented in "my probe" section of Ripe ATLAS under "Probe's Settings" a specific section that permits to enable such feature and customize the threshold and contact addresses. Simone Nulchis Lucense SCpA

1 0

New Face(s) in the Measurements and Tools Area
by Daniel Karrenberg 07 Sep '11

07 Sep '11

Gentlepeople, I am very happy to announce that we have a new community builder for measuremnts and tools: Vesna Manjolovic. Many of you will know Vesna already as a trainer and through her very enthousiastic work on our IPv6 promotion and IPv6 related measurements. Vesna has been with the RIPE NCC for more than 10 years; it gives me great pleasure to promote her to a position that makes optimal use of her capabilities and ambitions. Vesna's first priorities will be to establish relationships with current and potential sponsors of RIPE Atlas and to help develop a plan for the evoloution of RIPE TTM. RIPE Atlas sponsors and RIPE TTM customers will hear from her soon. The decision to hire internally not only affirms that initiative and effort are rewarded at the RIPE NCC; it also provides the budgetary room to engage another person to help with the community building for measurements: Ann Barcomb will therefore join Vesna in October. >From that time both Vesna and Ann will start to work on additional goals such as building a strong community around RIPEstat. Please join me in welcoming Vesna and help her to achieve her goals, which are also our common goals. Daniel

4 3

Re: [atlas] Email or SMS alert when probe goes offline/online
by Bert Wijnen 07 Sep '11

07 Sep '11

On 9/7/11 4:35 AM, Robert wrote: > What do other participants think about having email alerts when a probe goes offline or online? > > I’d like this is at will alert me to any network issue as soon as it happens allowing for that issue to be investigated and rectified. > > This means that the alert could serve a dual purpose: > > ·Increased network uptime > > ·Greater availability of the RIPE Atlas Probe (and thus increased data gathering). > > Anyway, this is something that I’d like to see – email alerts at a minimum. > Email alerts for sure. And pretty quick after the probe is detected to be offline. SMS might be nice, but I certainly would like to have a way to turn it off at times. Bert > Robert >

2 1

Re: [atlas] Email or SMS alert when probe goes offline/online
by Dennis Kögel 07 Sep '11

07 Sep '11

Am 07.09.2011 um 05:53 schrieb Robert: > What do other participants think about having email alerts when a probe goes offline or online? Doing this monitoring-style is not a job for the NCC, IMHO, as this certainly involves way more work that one might think at first. This is a case for your local monitoring solution, which does that job much better. That being said, it might make sense to e-mail hosts if a probe has been down for a *long* time (something like "one e-mail per week of downtime"), just to catch dead hosts and unnoticed configuration fails. - D.

1 0

Re: [atlas] Email or SMS alert when probe goes offline/online
by Daniel AJ Sokolov 07 Sep '11

07 Sep '11

On 07.09.2011 00:53 wrote Robert: > What do other participants think about having email alerts when a probe > goes offline or online? I generally like the idea. There should be a threshold though - for example the e-mail could be triggered once the probe is offline for 5 minutes. BR Daniel AJ

1 0

Email or SMS alert when probe goes offline/online
by Robert 07 Sep '11

07 Sep '11

What do other participants think about having email alerts when a probe goes offline or online? I'd like this is at will alert me to any network issue as soon as it happens allowing for that issue to be investigated and rectified. This means that the alert could serve a dual purpose: . Increased network uptime . Greater availability of the RIPE Atlas Probe (and thus increased data gathering). Anyway, this is something that I'd like to see - email alerts at a minimum. Robert

1 0

Re: [atlas] Email or SMS alert when probe goes offline/online
by Richard L. Barnes 07 Sep '11

07 Sep '11

This might not actually be desirable until the probes stop crashing so often :) It might be more useful to have alarms that trigger on things like sudden or sustained increases in latency or loss, configurable by the probe host. --Richard On Sep 6, 2011, at 10:35 PM, Robert wrote: > What do other participants think about having email alerts when a probe goes offline or online? > > I’d like this is at will alert me to any network issue as soon as it happens allowing for that issue to be investigated and rectified. > > This means that the alert could serve a dual purpose: > > · Increased network uptime > · Greater availability of the RIPE Atlas Probe (and thus increased data gathering). > > Anyway, this is something that I’d like to see – email alerts at a minimum. > > > Robert >

1 0

Email or SMS alert when probe goes offline/online
by Robert 07 Sep '11

07 Sep '11

What do other participants think about having email alerts when a probe goes offline or online? I'd like this is at will alert me to any network issue as soon as it happens allowing for that issue to be investigated and rectified. This means that the alert could serve a dual purpose: . Increased network uptime . Greater availability of the RIPE Atlas Probe (and thus increased data gathering). Anyway, this is something that I'd like to see - email alerts at a minimum. Robert

1 0

[atlas]Apache again....
by Viktor Naoumov 30 Aug '11

30 Aug '11

Back to apache... 'Listen 8080' was a bad solution because it opens apache to the world. Instead we should do now: Listen 127.0.0.1:8080 #Listen localhost:8080 Having Listen localhost:8080 <VirtualHost *:8080> prevents apache from starting with the following message: zelenka-dev:/etc/apache2# /etc/init.d/apache2 restart Restarting web server: apache2 ... waiting (98)Address already in use: make_sock: could not bind to address 127.0.0.1:8080 no listening sockets available, shutting down Unable to open logs Action 'start' failed. The Apache error log may have more information. failed! looks like it because zelenka-dev:/etc/apache2# host localhost localhost has address 127.0.0.1 localhost has IPv6 address ::1 but not sure yet.... didn't have time to figure out what do you think? /vty

1 0