- ripe-atlas - mailman.ripe.net

High inbound traffic causing packet loss?
by Tibor Djurica Potpara 23 Jul '12

23 Jul '12

Hello! I have just received an Atlas probe and I have been observing some weird readouts on the Atlas portal. Especially, occasional packet loss and considerable jitter, even to first and second hop destinations. I am surprised because even though I am a home user, I have a very stable connection (FTTH, 100/10 Mbps) and I've never experienced such connectivity issues. I've attached the probe directly to the ISP-provided switch that doesn't do IGMP snooping and since IP multicast is used for IPTV, high traffic (up to 50 Mbps) is occasionally flooded to all the switch ports. Taking into account that the probe is underpowered in terms of CPU, is it possible that it cannot handle such traffic and thus reports packet loss? If such is the case, I will move the probe behind a router to filter the multicast streams out. Best regards, Tibor Djurica Potpara

2 1

Flood-ping to measure packet loss?
by Bartsch, Rene 18 Jul '12

18 Jul '12

Hi, I've just started hosting a probe and I'm new to the list, so a "Hello" to all! :) Does the probe send simple pings or does it send flood pings (e.g. ping -f -c 1000 <destination>) for detection of packet loss? Best regards, Renne -- Sent with love from the new tine 2.0 email client ... Please visit http://tine20.org

3 3

Firmware 4470 to be released soon
by Ann Barcomb 11 Jul '12

11 Jul '12

Hello, Probe firmware version 4470 will be released soon. This version includes a small data structure change from 4460 which only affects DNS measurements: the addition of the optional field 'src_addr'. We have also published a correction for version 4460, which mistakenly listed a field 'src' for DNS measurements. This field does not exist in 4460. http://weir-dev.atlas.ripe.net/doc/data_struct#v4460_dns Kind Regards, Ann -- Ann Barcomb RIPE NCC Community Builder http://www.ripe.net Measurements Community Building +31 20 535 4444

2 1

Atlas infrastructure issues on Friday, 2012-06-29
by Robert Kisteleki 03 Jul '12

03 Jul '12

Dear Atlas users, As part of regular maintenance, last Thursday (2012-06-28) afternoon we upgraded the OS on a subset of our controlling infrastructure. During this work, some Atlas probes were told to hold back result reporting. A consequence of this was that when reconnecting, these probes sent in way more (and bigger) results than usual. Unfortunately, not all of the upgraded components ("controllers") had enough disk space to deal with the sudden increased data inflow. The combination of these events means that part of our infrastructure could not buffer results submitted from the probes, and as a result these results have been discarded. The event lasted approximately between 22h Thursday and 05h Friday (UTC), and affected about 30% of the probes. These probes will have a gap in their downloadable data sets and on their graphs. Since the event we increased the capacity of the involved infrastructure components. This will help us avoiding the same event occurring again. We apologise for the inconvenience this may cause. Regards, Robert Kisteleki RIPE NCC R&D

1 0

probe resolution, overhead, or ...?
by Randy Bush 20 Jun '12

20 Jun '12

we want to use atlas probes in an experiment. being prudent (you can tell it was not i), we decided to try to get some basic calibration. one run was just on a local LAN. three hosts on the same gige switch o probe 2285 o psg.com, a not very fancy or fast freebsd 9 box with intel/pro1000 gige ports o bbgp.psg.com, a funky older freebsd 9 box with bge gige probe 2285 pinging bbgp.psg.com, average RTT: 1.5606994382 [0], number of pings: 356*3 psg.com pinging bbgp.psg.com, average RTT: 0.253424332344 [0], number of pings: 674 has anyone done similar probe calibration experiments? does anyone have any clue as to why the difference? randy [0] - my favorite precision joke A gentleman accosts a guard in the museum and asks, "How old is that mummy?" The guard responds, "I believe it is 2005 years old." The gentleman asks "Why that particular age, 2005?" The guard responds "Well, I was told it was 2000 years old when I started work here five years ago."

4 7

Changes to RIPE Atlas raw data structures
by Ann Barcomb 20 Jun '12

20 Jun '12

Hi, We are planning on updating RIPE Atlas probe firmware, which will lead to some changes in the raw data structures. An article about this has been posted on Labs: https://labs.ripe.net/Members/emileaben/ripe-atlas-data-structure-changes We don't plan to announce these changes to this list in the future, because this list is for a more general audience and this information may not be of general interest. Instead, we have created an RSS feed for these types of announcements: https://atlas.ripe.net/atlas/feed/ Kind Regards, Ann -- Ann Barcomb RIPE NCC Community Builder http://www.ripe.net Measurements Community Building +31 20 535 4444

7 8

Feature-suggestion: "round-robin" probes
by Alexander Mayrhofer 11 Jun '12

11 Jun '12

Hello, i'm figuring how RIPE atlas could be most useful for assisting in monitoring our Ancast Network, and came up with the following idea: The Atlas network has a big advantage over other monitoring /measurement networks, which is obviously its sheer size (and topological diversity). Rather than using the Atlas network for pure performance measurements, i would love to be able to use Atlas for reachability measurements (and understand which Anycast location attracts traffic from which region, and how this changes over time). These reachability / topology discovery measurements do not need to be nearly as frequent as the performance measurements, but should utilize all available probes. So, instead of being able to use 10 probes to run a continous performance test (say, DNS query every 300 seconds), i would rather like to be able to use a very high number of probes (best case: "all"), but have each of the probe eg. perform just one traceroute per day (or, even once per week would be enough). This would give me an excellent overview about the topology, but is not possible using the current limits of the UDMs. However, instead of allowing users to allocate measurements to a much higher number of probes, this functionality would also be possible be adding some "probe round-robin" feature to the control infrastructure, for example "randomly allocate a new set of probes every xx seconds". If that feature would exist, i could implement the above reachability test with the following parameters: Test: traceroute Number of probes: 10 Measurement interval: 3600 Swap probe-set interval: 10800 (NEW feature) (which would re-allocate new probes every 3 hours, theoretically working through all 1500 probes about every month?). An obvious alternative would be functionality where i could "queue" "single-shot" measurements for the whole network (since chances are low i would get every probe if they are randomly assigned). comments? Suggestions? Alternatives? Alex Mayrhofer Head of R&D nic.at

5 13

Cannot ping 128.0.0.1, 128.0.24.1
by ckeck＠texoma.net 31 May '12

31 May '12

Cheers! Looked at my stats, and it looks as if not only my probe can't ping 128.0.0.1 and 128.0.24.1. The probe is hooked up to a router on a Verizon FIOS (fiberoptic) line. To see if that's a systemic issue, I pinged the same addresses from systems at work, as well as TMobile's (U.S.) wireless broadband, and they respond just fine. Question now is, where is the problem at? THX! -Cornelius -- Cornelius Keck -----------------------------------------> ckeck(a)texoma.net Beware, so long as you live, of judging men by their outward appearance. Jean de La Fontaine

4 4

v6 support
by Randy Bush 29 May '12

29 May '12

i am not understanding why probe 2285 does not seem to even get an ipv6 address on the in-rack lan, while a whole lot of other devices do. and 2283 managed to get a v6 address but no gateway, and of course no v6dns. what do the little puppies want, nd ra ??? randy

4 8

Ping to labs.ripe.net
by Dan Luedtke 16 May '12

16 May '12

Hi probe-admins, I see this on all my probes, do you have the same problem? Ping (IPv4) labs.ripe.net 193.0.6.153 100% packet loss regards Dan -- Dan Luedtke http://www.danrl.de

3 2

baccouche2@yahoo.com t'invite à rejoindre Twoo
by Thomas via Twoo 10 May '12

10 May '12

Je viens de découvrir un nouvel outil pour rencontrer du monde en ligne : Twoo.com. ---------------------------------------------------------------- Hi, ripe-atlas Thomas vient de trouver un nouvel outil pour rencontrer du monde en ligne et aimerait que tu te joignes à la fête : Twoo.com Copie/colle le lien ci-dessous dans ton navigateur : http://twoo.com/m/39jVbXL_ Tu ne veux plus recevoir ces mails? Clique sur ce lien: /unsubscribe/?email=ripe-atlas%40ripe.net&code=37d33a52e2b420b3962ae52bae8ce1cb&typeid=2---------------------------------------------------------------- TWOO NV/SA, UBIDOCA Center 3145, 105 Route Pommiers, F-74370 Bellevue, France info-fr(a)twoo.com BE0834322338.

1 0

Credit Consumption
by Jens Weibler 09 May '12

09 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 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