- ripe-atlas - mailman.ripe.net

Fwd: Issues encountered with assigning .0 and .255 as usable addresses?
by Tore Anderson 24 Oct '12

24 Oct '12

Here's a suggestion for an Atlas experiment and subsequent RIPE Labs article. Do a ping measurement from all the probes to the .0 and .255 address of the same /24, plus to another control address in the same /24, and compare success rates. It's particularly interesting for me as my own personal home page is accessible at 87.238.60.0 at the moment.., Might also be worth checking it out for IPv6 at the same time (at least the case where the last 64 bits are all zeroes). Tore -------- Opprinnelig melding -------- Emne: Issues encountered with assigning .0 and .255 as usable addresses? Dato: Mon, 22 Oct 2012 22:07:50 +0000 Fra: Paul Zugnoni <paul.zugnoni(a)jivesoftware.com> Til: nanog(a)nanog.org <nanog(a)nanog.org> Curious whether it's commonplace to find systems that automatically regard .0 and .255 IP addresses (ipv4) as src/dst in packets as traffic that should be considered invalid. When you have a pool of assignable addresses, you should expect to see x.x.x.0 and x.x.x.255 in passing traffic (ie. VIP or NAT pool, or subnets larger than /24). Yet I've run into a commercial IP mgmt product and getting reports of M$ ISA proxy that is specifically blocking traffic for an IP ending in .0 or .255. Any experience or recommendations? Besides replace the ISA proxy…. Since it's not mine to replace. Also curious whether there's an RFC recommending against the use of .0 or .255 addresses for this reason.

2 1

New probe firmware released: version 4.480
by Vesna Manojlovic 24 Oct '12

24 Oct '12

Hi everyone, few days ago we have released a new version of the probe firmware: 4.480. It introduces few bug fixes, and improvements that enable us to work on new features, but that still require work on the User Interface to make it visible to users. Until now, about 1.500 probes have been upgraded to new firmware. Below are the technical details. Regards, Vesna * Fixed bug in traceroute when it has to deal with rfc4884 objects (mpls) that have a wrong size. * Delayed DNS name resolution in ping and traceroute. This feature will soon be enabled through the UI. * Fixed bug in HTTP GET where some characters where not properly escaped in generating the result JSON. * Fixed bugs in the libevent stub resolver to better handle DNS errors and timeouts (affects mostly httpget) * Limit the amount of measurement data that is sent as one unit. This prevents probes that have not connected to a controller for some time from overloading the controller. * The probe uptime is now in the DNS SOS messages that are sent by probes before they try to connect. This will allow making a distinction between various reasons for disconnects: e.g. probe reboot vs. network problems. (also published on https://atlas.ripe.net/announce )

1 0

Convert json traceroute output to normal traceroutes.
by Jan Hugo Prins 17 Oct '12

17 Oct '12

Hi, Because I'm a little more used to reading regular traceroute output instead of JSON files, I created a little python script to convert the ATLAS traceroute output to readable traceroutes. Comments are always welcome ofcourse. The whois information is gathered from Cymru using: https://github.com/JustinAzoff/python-cymruwhois -- Met vriendelijke groet / Best regards, Jan Hugo Prins Infra consultant E: jprins(a)betterbe.com T: +31-53-4800694 M: +31-6-26358951 S: jhaprins W: www.betterbe.com

4 5

Forcing https in Atlas
by Robert Kisteleki 16 Oct '12

16 Oct '12

Dear Atlas users, At the moment the Atlas UI servers allow regular, unsecured (http) connections from clients. For particular features, most notably anything that requires authenticated users, we're using secure (https) connections. Unfortunately, the potential mixing of the two schemes causes glitches and inconsistencies for some users. Therefore on 15 October we will start enforcing secure connections towards the Atlas UI servers (atlas.ripe.net and *.atlas.ripe.net). We'll do this by automatically redirecting all http queries to their https equivalents. This should not cause any changes to those of you who already use https by default, and should not cause any notable changes to anyone else. However, some clients (especially CLI based ones) may need some extra flags to deal with https connections. Regards, Robert Kisteleki

2 2

A Case Study of AAAA Filtering
by Vesna Manojlovic 15 Oct '12

15 Oct '12

Hi all, at RIPE 65, Lorenzo Colitti from Google raised the question whether Internet users would see significant filtering of AAAA DNS queries or replies, either by their ISP or by their Customer Premise Equipment (CPE). Emile & Philip used RIPE Atlas to provide an answer to this question. https://labs.ripe.net/Members/emileaben/ripe-atlas-a-case-study-of-aaaa-fil… Regards, Vesna

4 5

Atlas main database maintenance
by Andreas Strikos 15 Oct '12

15 Oct '12

Dear Atlas users, Tomorrow around 09:30 CEST we will bring down our main database for maintenance. Hopefully, the whole process will not take more than 2 hours. The majority of the web site functionalities and user interaction with the system will not be available but we don't expect any loss of data flowing in from the probes. We are sorry for any inconvenience this might cause. Regards, Andreas Strikos

1 0

traceroute via ICMP?
by Jens Weibler 10 Oct '12

10 Oct '12

Hi, how is the development of traceroute via ICMP going? My central firewall team doesn't like opening many udp-ports for traceroute :( -- 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 3

Ping does no longer visualize?
by Sebastian Wiesinger 05 Oct '12

05 Oct '12

Hi, I just noticed that the Ping probe has changed, I can now enter more options but I'm unable to visualize the results. Even if I uncheck "do not visualize" I get no graphs. Regards Sebastian -- noris network AG - Thomas-Mann-Straße 16-20 - D-90471 Nürnberg Tel +49-911-9352-0 - Fax +49-911-9352-100 http://www.noris.de - The IT-Outsourcing Company Vorstand: Ingo Kraupa (Vorsitzender), Joachim Astel, Hansjochen Klenk - Vorsitzender des Aufsichtsrats: Stefan Schnabel - AG Nürnberg HRB 17689

2 2

RIPE Atlas roadmap, September 2012 version
by Vesna Manojlovic 05 Oct '12

05 Oct '12

[apologies for duplicates] Dear colleagues, we just published a RIPE Labs article with the RIPE Atlas roadmap update for September: https://labs.ripe.net/Members/becha/ripe-atlas-roadmap-september-2012-update (the fact that is already October today is a bit confusing, but we presented this version during the RIPE 65 meeting last week...) This is the invitation to look at our plans, and let us know what you think, so that we can take that into account when making new plans, next month. Thanks, Vesna

1 0

Cannot change network configuration
by Tibor Djurica Potpara 04 Oct '12

04 Oct '12

Hello, I have recently changed the router that my Atlas probe is connected to. Since it is now in a separate subnet from my home LAN, with dedicated DHCP/RA configuration, there is no longer need for static address configuration, so I would like to revert its settings back to autoconfiguration for both IPv4 and IPv6. However, in the web interface,//"Change Probe's Network Configuration" menu is greyed out, so I cannot do anything even though the probe is up. What am I to do? Thank you, Tibor

4 3

Strange IPv6 problem with Atlas
by Max Grobecker 02 Oct '12

02 Oct '12

Hello, I got my new Atlas a few days ago and connected it to my network (in a separated VLAN). In this VLAN I'm announcing routing advertisements with autonomous IPv6 addressing enabled. Appearently the probe heard this advertisement and have chosen to communicate over IPv6 - but with a link-local IPv6 address only...?! This leads to "Beyond scope"-Messages from my router which I captured with tcpdump: fe80::280:a3ff:fe91:4070.58730 > 2a01:4f8:161:3281::43:148.443: Flags [S], seq 2585125851, win 5360, options [mss 1340,sackOK,TS val 4294950236 ecr 0,nop,wscale 1] fe80::225:90ff:fe92:2478 > fe80::280:a3ff:fe91:4070: ICMP6, destination unreachable, beyond scope 2a01:4f8:161:3281::43:148, source address fe80::280:a3ff:fe91:4070 My routing advertisements are currently looking like that: fe80::225:90ff:fe92:2478 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 64 hop limit 64, Flags [none], pref medium, router lifetime 1800s, reachable time 0s, retrans time 0s prefix info option (3), length 32 (4): 2a02:a00:e000:b:e6::/96, Flags [onlink, auto, router], valid time 86400s, pref. time 14400s mtu option (5), length 8 (1): 1400 source link-address option (1), length 8 (1): 00:25:90:92:24:78 Is there anything I can do to make the probe communicate over IPv6? Manual IP configuration is not possible since the menu item is greyed out (althrough my probe runs on FW 4470). I disabled RA at the moment so the Atlas cube can talk to the RIPEs Atlas servers. Thank you in advance! -- Greetings from Wuppertal, Germany Max Grobecker

3 3

10/8
by Randy Bush 01 Oct '12

01 Oct '12

an external border, where an atlas probe is on the soft gooey inside, logged packets sourced from 10/8? could this have been the atlas probe? randy Sep 29 08:36:44 r0.sea.rg.net 390: Sep 29 08:36:43.966: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(53649) -> 23.63.172.166(443), 1 packet Sep 29 08:36:49 r0.sea.rg.net 391: Sep 29 08:36:48.466: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(46959) -> 23.63.205.115(443), 1 packet Sep 29 08:42:32 r0.sea.rg.net 392: Sep 29 08:42:31.363: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(53649) -> 23.63.172.166(443), 1 packet Sep 29 11:24:45 r0.sea.rg.net 393: Sep 29 11:24:44.826: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(32986) -> 64.12.235.15(443), 1 packet Sep 29 11:31:35 r0.sea.rg.net 394: Sep 29 11:31:34.644: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(53512) -> 143.225.229.137(554), 1 packet Sep 29 11:37:32 r0.sea.rg.net 395: Sep 29 11:37:31.453: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(53512) -> 143.225.229.137(554), 8 packets Sep 29 11:43:21 r0.sea.rg.net 396: Sep 29 11:43:20.339: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(59262) -> 38.102.136.104(80), 1 packet Sep 29 11:43:33 r0.sea.rg.net 397: Sep 29 11:43:32.151: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(60780) -> 69.171.228.74(443), 1 packet Sep 29 11:45:23 r0.sea.rg.net 398: Sep 29 11:45:22.013: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(60761) -> 69.171.228.74(443), 1 packet Sep 29 11:45:26 r0.sea.rg.net 399: Sep 29 11:45:25.017: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(60759) -> 69.171.228.74(443), 1 packet Sep 29 11:48:57 r0.sea.rg.net 400: Sep 29 11:48:56.480: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(46352) -> 174.37.29.147(80), 1 packet Sep 29 11:49:32 r0.sea.rg.net 401: Sep 29 11:49:31.465: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(60780) -> 69.171.228.74(443), 1 packet Sep 29 11:49:32 r0.sea.rg.net 402: Sep 29 11:49:31.465: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(60781) -> 69.171.228.74(443), 2 packets Sep 29 11:50:32 r0.sea.rg.net 403: Sep 29 11:50:31.466: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(60761) -> 69.171.228.74(443), 1 packet Sep 29 11:50:32 r0.sea.rg.net 404: Sep 29 11:50:31.466: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(60759) -> 69.171.228.74(443), 1 packet Sep 29 11:54:32 r0.sea.rg.net 405: Sep 29 11:54:31.469: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(46352) -> 174.37.29.147(80), 1 packet Sep 29 12:10:05 r0.sea.rg.net 406: Sep 29 12:10:04.260: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(60333) -> 193.0.6.139(443), 1 packet Sep 29 12:10:11 r0.sea.rg.net 407: Sep 29 12:10:10.292: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(60348) -> 193.0.6.139(443), 1 packet Sep 29 12:10:24 r0.sea.rg.net 408: Sep 29 12:10:22.640: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(60363) -> 193.0.6.139(443), 1 packet Sep 29 12:13:30 r0.sea.rg.net 409: Sep 29 12:13:29.535: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(33721) -> 193.0.6.133(443), 1 packet Sep 29 12:14:10 r0.sea.rg.net 410: Sep 29 12:14:09.435: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(37936) -> 178.63.78.16(80), 1 packet Sep 29 12:14:29 r0.sea.rg.net 411: Sep 29 12:14:28.256: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(33754) -> 193.0.6.133(443), 1 packet Sep 29 12:15:32 r0.sea.rg.net 412: Sep 29 12:15:31.489: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(60348) -> 193.0.6.139(443), 2 packets Sep 29 12:15:32 r0.sea.rg.net 413: Sep 29 12:15:31.489: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(60363) -> 193.0.6.139(443), 1 packet Sep 29 12:15:32 r0.sea.rg.net 414: Sep 29 12:15:31.489: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(60364) -> 193.0.6.139(443), 2 packets Sep 29 12:15:32 r0.sea.rg.net 415: Sep 29 12:15:31.489: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(60366) -> 193.0.6.139(443), 2 packets Sep 29 12:19:32 r0.sea.rg.net 416: Sep 29 12:19:31.492: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(37936) -> 178.63.78.16(80), 2 packets Sep 29 12:19:32 r0.sea.rg.net 417: Sep 29 12:19:31.492: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(33754) -> 193.0.6.133(443), 2 packets Sep 29 12:21:00 r0.sea.rg.net 418: Sep 29 12:20:59.386: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(39687) -> 206.219.196.114(443), 1 packet Sep 29 12:21:42 r0.sea.rg.net 419: Sep 29 12:21:41.318: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(39683) -> 206.219.196.114(443), 1 packet Sep 29 12:23:57 r0.sea.rg.net 420: Sep 29 12:23:56.533: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(56161) -> 88.221.216.66(80), 1 packet Sep 29 12:24:20 r0.sea.rg.net 421: Sep 29 12:24:19.673: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(39741) -> 206.219.196.114(443), 1 packet Sep 29 12:26:32 r0.sea.rg.net 422: Sep 29 12:26:31.499: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(39687) -> 206.219.196.114(443), 2 packets Sep 29 12:27:32 r0.sea.rg.net 423: Sep 29 12:27:31.500: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(39683) -> 206.219.196.114(443), 10 packets Sep 29 12:28:53 r0.sea.rg.net 424: Sep 29 12:28:52.193: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(44361) -> 64.12.104.224(443), 1 packet Sep 29 12:29:32 r0.sea.rg.net 425: Sep 29 12:29:31.502: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(56162) -> 88.221.216.66(80), 7 packets Sep 29 12:29:32 r0.sea.rg.net 426: Sep 29 12:29:31.502: %SEC-6-IPACCESSLOGP: list serial-out4 denied tcp 10.13.0.6(56161) -> 88.221.216.66(80), 6 packets

3 4

RIPE Atlas at RIPE65
by Vesna Manojlovic 21 Sep '12

21 Sep '12

[apologies for duplicates] Dear community, we are happy to invite you to the "Atlas Bash" at the RIPE65: Tuesday, 25 September, 18:00 – 19:00 (plenary room). This has just been added to the meeting agenda, in one of the BoF slots (Birds of Feathers): https://ripe65.ripe.net/programme/meeting-plan/birds-of-a-feather/ We would like to make this an interactive session, in order to bring RIPE Atlas UDM users and beta-testers together in one room with RIPE Atlas developers and the Measurements Community Builder to discuss developments, exchange ideas and best practices, suggest improvements, etc. This is also a great opportunity to learn more about the RIPE Atlas Anchors pilot project, how to get involved, to discuss host requirements, which features do you want, and more. We will be giving various presentations at many working groups, too, about the measurements results from RIPE Atlas, and plans for the future: MAT-wg, NCC-services-wg, plenary... Detailed information will follow next week, when all agendas are finalized. Hope to see you there! If you can not take part, there will be webcasts and jabber, and we will report back on these mailing lists. Regards, Vesna

1 1

Announcing RIPE Atlas Anchors, Pilot Phase
by Vesna Manojlovic 31 Aug '12

31 Aug '12

Dear Atlas community, Please find a new article on RIPE Labs describing the details of RIPE Atlas Anchors: https://labs.ripe.net/Members/dfk/ripe-atlas-anchors Right now, we are looking for a small number of pilot hosts from the RIPE NCC membership for deployment to begin in October 2012. If you are interested, please contact me or Daniel Karrenberg before the RIPE65. We will be discussing further details at the RIPE meeting. Regards, Vesna Manojlovic -- Vesna Manojlovic BECHA(a)ripe.net Senior Community Builder +31205354444 for Measurements Tools RIPE NCC http://ripe.net

1 0

Operational issue between ~14h-16h UTC
by Robert Kisteleki 29 Aug '12

29 Aug '12

Dear Atlas users, This afternoon our developers deployed an upgrade to the Atlas controlling infrastructure. Unfortunately, the update contained a bug that we did not catch in the test environment. This bug caused all probes to suspend their running UDMs (User Defined Measurements) between approximately 14h-16h (UTC, different probes were affected at different times). After noticing the error we reverted the changes, and resumed all UDMs. Because of this, your UDMs likely have missing data points for this time frame. Obviously, more frequent measurements will have more missing results while less frequent measurements will have less (or even nothing) missing results. "Built-in" measurements (i.e. non-UDMs) have not been affected. Based on this experience, we'll enhance our testing procedure to lower the chance of these kind of errors happening again. Excuses for the inconvenience this issue may have caused. Regards, Robert Kisteleki RIPE NCC

1 0

Two new measurements types, and a new interface (wizard)
by Vesna Manojlovic 28 Aug '12

28 Aug '12

Dear Atlas community, I am happy to announce DNS & SSL certificate measurements, a new addition to the UDMs, making it in total 4 types of customized measurements you can perform! Please find out the details in the RIPE Labs article: https://labs.ripe.net/Members/becha/dns-user-defined-measurements-in-ripe-a… In order to make more types of measurements possible, we have also introduced the new web interface: so-called wizard. It has been extensively tested by the beta-testers for two months, and we hope that the rest of the Atlas UDM users will find it handy. The old interface has been deprecated, so the usual link now leads to the new wizard: https://atlas.ripe.net/atlas/udm.html Please let us know what you think, and enjoy the measurements :) If you have a success-story to share, consider giving a presentation at the RIPE65, or writing RIPE Labs article. I am willing to work on this together with you, so do let me know if you need any help. Regards, Vesna

3 2

Static configuration feedback
by Jeroen van der Ham 16 Aug '12

16 Aug '12

Hi, I've noticed that the table on the webpage which displays the status of a probe's static configuration is not working right. If the "Static Enabled" setting is ticked, the "Probe Knows" is automatically ticked as well, *even for probes which are offline*. The feedback this gives is wrong and actually counterproductive. Could this be fixed please? Jeroen.

2 1

Traceroute path consistency
by David Lebrun 15 Aug '12

15 Aug '12

Hi all, I have a suggestion regarding the udp traceroute feature: allowing the user to specify the source port. The motivation for this suggestion is to keep consistent paths between two traceroutes towards the same destination. I understand that the source port is used to discriminate concurrent traceroutes, so perhaps allocating a range for user-defined source ports would do the trick. There is of course the issue of two users selecting the same source port for the same destination but this is very unlikely. Do you think this is feasible ? David

3 4

RIPE Atlas Roadmap: monthly update: August
by Vesna Manojlovic 08 Aug '12

08 Aug '12

Dear Atlas community, (thanks, Inigo ;-) while developing RIPE Atlas, we wish to keep *you* involved and informed. We are maintaining a roadmap of the features we are working on, and with this update we are asking for feedback, so that we can use it as guidance for making further plans. You can find much more details are in the RIPE Labs article: https://labs.ripe.net/Members/becha/ripe-atlas-roadmap-august-2012-update Here I only want to copy the plans for next 4-6 weeks, and three months after that, and to repeat the questions from the article: Plans for the next month: * Users can get more flavors of customized measurements: DNS & SSL - new wizard for two new types of measurements, currently beta-tested * Making it possible to download measurements results without having to be logged in - by deploying & enabling API Keys * Making it easier to follow the rate of deployment of probes over time - by updating the graphs that show the distribution and status of probes * Atlas hosts and sponsors can meet developers during RIPE65, Amsterdam - exchange experiences, give feedback and requirements - so developers can adjust priorities Plans for Q4 2012: * Installing Atlas Anchors as new targets for pre-defined measurements - this will offer greater topological diversity for measurements - Atlas Anchors will also become powerful probes, capable of performing more measurements then small probes * In order to remind you if the probe is not plugged in or if it is down - we will add more automatic email notifications of events * We will create Internet Traffic Maps based on Atlas data - maps will illustrate the health (e.g. reachability) of measured networks Questions: - About the current functionality: what do you want us to improve? - About additions to the next release: what are the most-wanted features for each one of them? - And finally, from the less-specific planned functionalities that we will work on three-six months from now: - what do you find most important? - to which one of them shall we give most priority? Thank you for your feedback, have a great summer, and see you soon in Amsterdam, Vesna

1 0

Make more measurements
by Vesna Manojlovic 06 Aug '12

06 Aug '12

Dear Atlas users, for few weeks already it is possible to perform *more* UDMs (User Defined Measurements), since we have increased the limits, and allowed you to spend your well-earned "credits": - you can perform up to 5 measurements simultaneously, - from up to 50 probes, - and you can spend 270,000 credits per day. A reminder of documentation location: - to see your measurements, and schedule a new one: https://atlas.ripe.net/atlas/udm.html - to find out more about UDM functionality: https://atlas.ripe.net/doc/udm You can read much more about Atlas on RIPE Labs: https://labs.ripe.net/atlas Have a great summer! Vesna

2 1

HTTP UDM?
by Miles McCredie 03 Aug '12

03 Aug '12

Are there any plans to support an HTTP UDM? Thanks -Miles

2 4

Sharing Stats?
by Dan Luedtke 03 Aug '12

03 Aug '12

Hello everyone, what are your opinions on sharing stats from a probe to the public? My idea: I have a public probe and public UDMs running, and I would like to embed the "last 8 hours" graphs into a website where people can see it, even those that do not have access to RIPE Atlas. Do you think it is a good idea to ask for a feature that splits the "Public" checkbox into two ones saying "Public (ATLAS Community)" and "Public (Internet)"? best regards, Dan -- Dan Luedtke http://www.danrl.de

8 10

Port blocking statistics
by Bartsch, Rene 25 Jul '12

25 Jul '12

Hi, when charting the internet it would be useful to have an oversight about ISPs blocking ports. Especially discussions about network neutrality should be based on hard facts instead of polemic discussions. So I suggest to check the connectivity of the protocols listed in http://www.iana.org/assignments/service-names-port-numbers/service-names-po… once a week as built-in measurement. Best regards, Renne -- Sent with love from the new tine 2.0 email client ... Please visit http://tine20.org

3 3

128.0.0.1 and 128.0.24.1 measurements
by Tuomo Soini 24 Jul '12

24 Jul '12

Should these measurements be discontinued? These networks are no more visible. http://www.ris.ripe.net/dashboard/128.0.24.0/24 http://www.ris.ripe.net/dashboard/128.0.0.0/21 -- Tuomo Soini <tis(a)foobar.fi> Foobar Linux services +358 40 5240030 Foobar Oy <http://foobar.fi/>

2 1

Probe down?
by Yoann Gini 23 Jul '12

23 Jul '12

Hello, My probe is down since a while now. I’ve try to unplug and replug many time, change USB and ethernet slot and it’s still down. The green led is on and the orange is slowly flashing, my swith see the probe, bit Atlas always report it as down. I’ve the Probe ID 2199. What I’m supposed to do ? Best regards, Yoann Gini.

5 5

Fwd: [ipv6-wg] New on RIPE Labs: Test your IPv6 Reachability by Using RIPE Atlas (now visualised)
by kix 23 Jul '12

23 Jul '12

fyi. I think this mail was not sent to this mail list. Cheers, kix -------- Mensaje original -------- Asunto: [ipv6-wg] New on RIPE Labs: Test your IPv6 Reachability by Using RIPE Atlas (now visualised) Fecha: 17/07/2012 14:32 Remitente: Mirjam Kuehne <mir(a)ripe.net> Destinatario: ipv6-wg(a)ripe.net [apologies for duplicate mails] Dear colleagues, As announced in earlier, it is possible for RIPE NCC members to do IPv6-traceroutes from all RIPE Atlas probes to IPv6 destinations. In this new article on RIPE Labs we present a first experimental analysis and a prototype visualisation of the traceroute results: https://labs.ripe.net/Members/emileaben/visualise-your-ipv6-connectivity-us… Kind Regards, Mirjam Kuehne RIPE NCC -- Rodolfo García Peñas (kix) http://www.kix.es

7 7

Concurrent traceroute issues on the probes
by David Lebrun 23 Jul '12

23 Jul '12

Hi all, I was wondering whether the probes can perform multiple concurrent traceroutes toward different destinations, and if so, are they able to differentiate the replies ? I just ran into this problem with paris-traceroute, the path were completely mixed up and stderr output looking like the following messages multiple times (IP addresses redacted): [WARN](TracertImpl.cc, 368)A reply received with bad original destination address A.B.C.D, should be W.X.Y.Z [WARN](TracertImpl.cc, 326)Bad return flow id 0x4d2 from E.F.G.H [WARN](TracertImpl.cc, 331)ICMP reserved words 0 0 0 0 0 As the probes use paris-traceroute, I prefer to be sure that the results are not flawed. David

2 4

Embedd built-in measurement page into website
by Bartsch, Rene 23 Jul '12

23 Jul '12

Hi, is there any way to embedd the "Built-in Measurements"-JQuery-Frame of my probes into a publically accessible website? Thanx for any hint, Renne -- Sent with love from the new tine 2.0 email client ... Please visit http://tine20.org

2 1

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