- ripe-atlas - mailman.ripe.net

Credit Consumption
by Jens Weibler 10 May '12

10 May '12

Hi, I just noticed that I can't create new measurements anymore: "Your current daily credit consumption (62496) is higher than you allowed (15000)." But I've got enough credits on my balance and I don't want to stop my measurements. Why can't I just change the probe count or the measurement interval? ;) -- Jens Weibler IT-Services Hochschule Darmstadt www.h-da.de University of Applied Sciences Fachbereich Informatik www.fbi.h-da.de Schöfferstr. 8b D-64295 Darmstadt Tel +49 6151 16-8425 Fax +49 6151 16-8935 jens.weibler(a)h-da.de

2 2

New on RIPE Labs: Test your IPv6 Reachability by Using RIPE Atlas
by Ann Barcomb 09 May '12

09 May '12

[apologies for duplicate mails] Dear colleagues, RIPE Atlas can now be used to test your IPv6 reachability, even if you do not host a RIPE Atlas probe - provided you are a RIPE NCC member. More details can be found on RIPE Labs: https://labs.ripe.net/Members/becha/test-your-ipv6-reachability-using-ripe-… If you have any comments or questions, please let us know. Kind Regards, Ann Barcomb

1 0

Routing glitch between BSNL and F Root
by Anurag Bhatia 26 Apr '12

26 Apr '12

Hello, There has been some routing glitch in the F root server instance running in Chennai, India by niXi AS 24049. Govt. owned BSNL AS9829 routers are not hearing any BGP announcements and thus F root does not works at all on BSNL. anurag@laptop ~ $ traceroute f.root-servers.net -A traceroute to f.root-servers.net (192.5.5.241), 30 hops max, 60 byte packets 1 192.168.1.1 (192.168.1.1) [AS8151/AS28513] 1.552 ms 2.040 ms * 2 117.207.48.1 (117.207.48.1) [AS9829] 26.010 ms 28.433 ms 31.136 ms 3 218.248.173.42 (218.248.173.42) [AS9829] 34.497 ms 35.968 ms 38.372 ms 4 218.248.250.86 (218.248.250.86) [AS9829] 91.784 ms 94.430 ms 96.794 ms 5 * * * 6 * * * 7 * * * 8 * * * I have been hosting RIPE Probe #1032 and here is F Root connectivity data from proble: [image: Inline image 1] As we can see root server is not accessible at all from Jan and even in Nov, Dec last year it was available with over 300ms latency which indicates network was not using Chennai anycast node since latency between this test probe placed in Haryana (North India) and Chennai (South India) should be around 70ms. Thanks. -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia <https://twitter.com/#!/anurag_bhatia> Linkedin: http://linkedin.anuragbhatia.com -- This message has been scanned by Kaspersky Anti-Virus. For more information about data security please visit http://www.kaspersky.com and http://www.viruslist.com

3 4

Request for RIPE Atlas probe DHCP change.
by Leo Bicknell 23 Apr '12

23 Apr '12

Could the RIPE Atlas probe DHCP client please be configured to send a ClientID, perhaps "RIPEAtlasProbe"? Many home gateways show a list of DHCP clients and list the client ID. It would make it much easier to identify which device is which using these tools. -- Leo Bicknell - bicknell(a)ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/

4 5

ATLAS as mechanism for route policy discovery
by Alexander Asimov 23 Apr '12

23 Apr '12

Hello. During last decade much attention was paid to topology discovery at inter-domain routing level. But most of these projects are only targeted on physical links discovery; at the same time there was little opportunity to check the real use of links by single AS. The knowledge of Autonomous System relationships from single AS view could be used in many cases. For example it could be used during designing AS or for traffic flow engineering purposes. In case to solve this problem we have invented several active probing algorithms for discovering real routing policy map from single AS view. One of them is based on using spoofed source IP. We send an echo request with record route option and source IP from our address space and as the result we can see the part of reverse trace from destination. This helps to understand which links are used by our AS. It is a kind of snapshot. This information is used in iteration process and the all data results in model of AS relationships which could be reversed to single view for every AS. At the current moment we cover with help of our nodes about 40% of transit AS, but with help of RIPE Atlas we will be able to cover more than 90%, and give back to community a tool for traffic flow prediction at interdomain routing level. Spoofing is obviously bad in most of cases, but not this time. We need opportunity to strictly spoof only one IP from our address space. The list technical requirements of our proposal: 1. 178.248.239.238 always will be used as spoofed address; 2. There will be about 15 experiments every day; 3. Each experiment will last not more than 10 minutes; 4. The total approximate packet generation activity from all nodes will be about 500 packets per second; 5. We need opportunity to have different measurement plans (list of destinations) on different nodes. We work with Planet Lab nodes in the same way: every day there is a new .gz archive with list of targets for all nodes, every node unpacks it and use then only a sublist of destinations, but the packet generation script is same on all nodes. We're open to discussion on procedures described above. Best regards, Alexader Asimov

1 0

Measure DNS resolve times
by Daniel AJ Sokolov 10 Apr '12

10 Apr '12

Hello, My ISP has changed something and as a result DNS lookups have slowed down considerably. How would I set up a User Defined Measurements to perform certain lookups on a nameserver and measure the response times? Thank you Daniel AJ -- Follow me on twitter @newstik http://twitter.com/newstik

3 2

RIPE Atlas User-Defined Measurements Are Here!
by Ann Barcomb 04 Apr '12

04 Apr '12

Dear Atlas Hosts and Sponsors, We are pleased to announce our first roll-out of user-defined measurements (UDM) for RIPE Atlas. As of today, all hosts and sponsors on this mailing list are invited to run custom measurements. Over the coming weeks we will continue to roll out UDM to a wider audience. To access UDM, either click on the link at the top right when you are logged in to the RIPE Atlas website, or go directly to: https://atlas.ripe.net/atlas/udm.html For the time being, we have created a fairly low rate limit, which we expect to increase over time. More information about limits and other aspects of the UDM system can be found in the documentation: https://atlas.ripe.net/doc/udm Discussion and questions about UDM can be directed to this mailing list (ripe-atlas(a)ripe.net) or to atlas-dev(a)ripe.net. You may also be interested in joining us at the UDM "Birds of a Feather" (BoF) session at RIPE 64 in Ljubljana, on Thursday, 19 April after the Measurements, Analysis and Tools (MAT) Working Group session. https://ripe64.ripe.net/programme/meeting-plan/bof/ Happy measuring! - The RIPE Atlas team

9 18

labs.ripe.net dead?
by damkol＠gmail.com 04 Apr '12

04 Apr '12

Hello. 29.03.2012 labs.ripe.net stopped respond to icmp. https://zpm02.atlas.ripe.net/atlas/rrd.png?prb_id=741&msm_id=1007&type=week… >From other places with other internet connections also not respond to icmp. -- damkol(a)gmail.com

3 2

Re: [atlas] Probe 2317 is down
by Colin Johnston 02 Apr '12

02 Apr '12

fixed internal network :) Can a request for enhancement be made for notification of probe goes up to the owner email ? Colin On 31 Mar 2012, at 08:30, RIPE Atlas wrote: > Dear colin, > > Your probe 2317 is down since 2012-03-31 06:56:49 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 1

change ownership of probe
by Thanos Tsakalos 02 Apr '12

02 Apr '12

Hello to all, Is there a way to change the ownership of a probe? Will it be ok if the probe is re-registered under the new email address (mac and pin are known) ? Or is there any other method to do it properly? Thank you, Triantafyllos

2 1

Altas switching to "RIPE NCC Access"
by Vesna Manojlovic 27 Mar '12

27 Mar '12

Dear Atlas people, Tomorrow during the day we'll switch RIPE Atlas to use RIPE NCC Access, our Single-Sing-On mechanism. Maintenance will happen during our working hours (9-5, Amsterdam time), and it will last between 1 and 3 hours. During this, Atlas login will be disabled. The Atlas web site will have limited functionality. After the completed maintenance, the "log in" link on Atlas web site will be re-directed to the RIPE NCC Access log-in page. For other possible outcomes on this migration, please read Robert's article: https://labs.ripe.net/Members/kistel/preparing-ripe-atlas-for-ripe-ncc-acce… Single-Sign-On functionality will enable us to share Atlas with the users of other RIPE NCC services; it will make the user-experience smoother for everyone who is accessing multiple services from the RIPE NCC (such as LIR Portal, RIPE Labs or RIPEstat), and will enable many new personalized features in the future. If you have any questions, please let us know. Thank you, Vesna

4 4

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 06 Feb '12

06 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 29 Dec '11

29 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 Олеся О. 18 Oct '11

18 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