October 2014 - ripe-atlas - mailman.ripe.net

RIPE atlas probe network configuration
by James A. T. Rice 21 Oct '14

21 Oct '14

Hi RIPE, We've just obtained our final /22 of IPv4 PA space, and we're looking at doing things a little differently with regards to trying to maximise the efficiency of usage within that block. While 100% utilisation of IP addresses by customers is not difficult in e.g. broadband networks (with a /32 being routed over a point to point link to each user), it is difficult in ethernet networks (with 2^n size subnets, network and broadcast and router addresses). Essentially we're going to try to have each customer device (for this purpose, the RIPE atlas probe is a customer device) consume exactly the number of globally unique IP addresses that it needs. Because for isolation each customer gets their own VLAN, and because "ethernet" traditionally means subnets with 2^n size and network and broadcast addresses and physical router addresses and VRRP addresses needing to be on that subnet, we end up with a subnet of 8 IP addresses used for a customer device that only will have 1 IP address exposed to the outside world: globally unique range: 0 - network 1 - default gateway vrrp 2 - router-a physical 3 - router-b physical 4 - customer device .. .. 7 - broadcast What I'd like to do, in order to only consume 1 globally unique IP address for the whole setup is as follows: private range, e.g. 10.a.b.c/24 0 - network 1 - default gateway vrrp 2 - router-a physical 3 - router-b physical 4 - customer device .. .. 255 - broadcast with a single globally unique IPv4 /32 (let's say) p.q.r.s routed to 10.a.b.4 in the above example. This means that you'd need to configure on your device, something like (assuming linux): network: 10.a.b.0/24 gateway: 10.a.b.1 alias: p.q.r.s/32 with it configured that p.q.r.s is the default source IP address to use for any outbound packets. This is a relatively 'clean' way of doing things, as it doesn't involve proxy-arp or similar trickery. It should be possible to do this for linux based systems. What do you think? Will the atlas probe support it, or would you consider making that a feature? Thanks James Rice Jump Networks Ltd.

2 3

Afilias (NL) has joined RIPE Atlas anchors
by Michela Galante 20 Oct '14

20 Oct '14

Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called nl-ams-as12041 and it is hosted by Afilias in Amsterdam, Netherlands. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb(a)ripe.net

1 0

Fwd: Your RIPE Atlas Probe (ID: 11513) is now connected to our network
by Rusty Dekema 20 Oct '14

20 Oct '14

Good evening, In case you track these sorts of things, the ~2 week disconnection of this probe was caused by network trouble on my end (combined with an extended vacation), and not by the probe itself or any other part of the RIPE Atlas system. Cheers, Rusty Dekema ---------- Forwarded message ---------- From: RIPE Atlas <atlas(a)ripe.net> Date: Sun, Oct 19, 2014 at 9:40 PM Subject: Your RIPE Atlas Probe (ID: 11513) is now connected to our network To: rdekema(a)gmail.com Dear RIPE Atlas probe host, Thank you for participating in RIPE Atlas! We're just letting you know that your probe (#11513 with description Comcast Business 50/10 (with IPv6 trial).) has re-established its link to our network and we are again receiving data from it. For your own records, it appears that the reconnection took place at 2014-10-20 01:39 UTC. If you have any questions, please contact us at atlas(a)ripe.net Best regards, RIPE Atlas Team ********** You are receiving this message because you applied for or were given a RIPE Atlas probe. We will only send messages when your probe becomes disconnected for an extended period of time.

1 0

Http Measurements
by Robert Vojcik 10 Oct '14

10 Oct '14

Hi, I'm preparing some measurements for our project because we plan to migrate one big site from CDN. I saw in documentation that Atlas support HTTP measurements but not for all users by default. How can I request this feature ? We will have ping and traceroute measurements but HTTP reponses would be great to compare what impact migration will have. Thank you for help -- Robert

2 1

teamix (DE) has joined RIPE Atlas anchors
by Michela Galante 08 Oct '14

08 Oct '14

Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called de-nue-as33988 and it is hosted by teamix GmbH in Nuremberg, Germany. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb(a)ripe.net

1 0

Comcast (US) has joined RIPE Atlas anchors
by Michela Galante 07 Oct '14

07 Oct '14

Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called us-den-as7922 and it is hosted by Comcast in Denver, United States. Congratulations to Comcast for their second anchor online! Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb(a)ripe.net

1 0

RIPE Atlas vs. bash/shellshock vulnerability
by Robert Kisteleki 03 Oct '14

03 Oct '14

Dear RIPE Atlas users, The RIPE NCC made a public announcement earlier about this issue (see https://www.ripe.net/internet-coordination/news/announcements/ripe-ncc-secu…). Still, since we have received some questions in email and Twitter about RIPE Atlas vs. this vulnerability so we'd like to respond to these with some more detail. The RIPE Atlas v1-v2-v3 probes are/were not affected by this issue at all since they don't run bash (or even have it installed) and also not providing any accessible services. The anchors have bash installed, but it is not used for any of the services provided. Besides, these servers have been patched right away. The infrastructure components (ie. controllers) were affected and as the RIPE NCC announcement explains, they have been patched as soon as the patch came out; basically within the day. Regards, Robert Kisteleki for the Atlas team

3 3

out of office
by jiri.prochazka＠superhosting.cz 01 Oct '14

01 Oct '14

Dear sender, I am currently out of office returning October 6th. I have limited access to my email, in urgent case you can reach me on my mobile phone + 420 777 87 37 67. Regards, -- Jiri Prochazka network administrator (AS39392) SuperNetwork s.r.o. m: +420 777 87 37 67 w: http://www.superhosting.cz e: jiri.prochazka(a)superhosting.cz

1 0

Wrong uptime information in monthly report
by Rene Bartsch 01 Oct '14

01 Oct '14

Hi, I got the following report of a drone: -------------------------------------------------------------------------------------------------------------- This is your monthly availability report for probe 3146 (T-Online Call & Surf Comfort IP Speed 50/10 MBit/s ). Calculation interval : 2014-09-01 00:00:00 - 2014-10-01 00:00:00 Total Connected Time : 15d 16:46 Total Disconnected Time : 14d 07:13 Total Availability : 52.33% +---------------------+---------------------+------------+--------------+ | Connected (UTC) | Disconnected (UTC) | Connected | Disconnected | |---------------------+---------------------+------------+--------------+ | 2014-08-14 11:37:26 | 2014-09-02 02:22:27 | 1d 02:22 | 0d 00:00 | | 2014-09-02 02:36:21 | 2014-09-04 23:40:28 | 2d 21:04 | 0d 00:13 | | 2014-09-05 00:03:58 | 2014-09-16 17:23:55 | 11d 17:19 | 0d 00:23 | +---------------------+---------------------+------------+--------------+ ---------------------------------------------------------------------------------------------------------------- https://atlas.ripe.net/probes/3146/#!tab-network shows an uptime of 99.83%. Please fix this! -- Best regards, Renne

2 1