- ripe-atlas - mailman.ripe.net

Update Wikipedia Article?
by Paul Theodoropoulos 03 Feb '22

03 Feb '22

I was curious what Wikipedia has to say about the project so had a look. The article is...adequate, but could use some updating and expansion. Unfortunately, I am merely a helpful little Probe, without as much insight into the true dynamics of the Atlas unlike many others here. For one thing, there's no mention of the ability to run software probes as I do. I made a few "WikiGnome" fixes on the article, but other than that, I'm not really the person to update it... Just tossing that out there! -- Paul Theodoropoulos www.anastrophe.com

2 1

Location of probe controllers
by Malte Appel 01 Feb '22

01 Feb '22

Hi, I was looking at the built-in traceroute measurements and noticed additional targets (ctr-*.atlas.ripe.net) apart from the DNS root servers. As I understand it, these are the controllers for the probes. However, I was wondering where they are physically located and could not find any clear information about that. My guesses from the DNS names are based on IATA airport codes: ctr-ams02.atlas.ripe.net (Amsterdam, NL) ctr-ams03.atlas.ripe.net (Amsterdam, NL) ctr-ewr01.atlas.ripe.net (Newark, NJ, US) ctr-fnc01.atlas.ripe.net (Funchal, PT) ctr-nue13.atlas.ripe.net (Nürnberg, DE) ctr-nue17.atlas.ripe.net (Nürnberg, DE) ctr-sin02.atlas.ripe.net (Singapore, SG) Can anyone confirm or correct these locations? Best, Malte

6 7

Is there a procedure to move a software probe to a new device
by Peter Garner (iPad) 01 Feb '22

01 Feb '22

Noob question. I set up my software probe on a Debian 10 box which has quite a few small servers on it. However, I intend to move it onto a Raspberry Pi, so I was wondering if there's a specific procedure to follow to preserve existing settings? Only the internal IP address will change; the external remains the same.

6 7

Can't access the serial in SOA records from the API
by Nathan Larsen 26 Jan '22

26 Jan '22

Hi, Does anyone know a way to access the serials from SOA records with the Ripe Atlas API? I have been running a variety of DNS measurements with the query type being SOA, but have not been able to determine how to get serial numbers over the course of the measurement. Any guidance would be appreciated, Nate Larsen

1 0

daily income zero ripe probe 32256 credits com338.934.911
by kiran.gunana＠colruytgroup.com 21 Jan '22

21 Jan '22

Dears, Any reason why my daily income in credits is zero even though my probe is almost online everyday ? My probe ID : 32256 Also I would appreciate few donations ( 4 million credits) on credits as I need to initiate new measurements ? Kind Regards, Kiran Gunana Dit bericht is onderworpen aan de voorwaarden beschikbaar op onze website Ce message est soumis aux conditions disponibles sur notre site web This message is subject to the terms and conditions available on our website

4 3

probe V2 status lights
by Jaap Akkerhuis 18 Jan '22

18 Jan '22

There used to be information telleing what the lights mean. It seems to be gone. After a lot of searching around one finds some information about blinking orage lights but all leds in version 2 are green colored so I guess this cvers V3 (or V1?) probes. have probes V2 been abandoned by Ripe-Ncc? jaap

4 4

Re: [atlas] Possible paging bug on RIPE Atlas Probes page with iltered results
by T 14 Jan '22

14 Jan '22

Hello, It's not you, it's not your browser. It is indeed a bug that exists since the new design of the RIPE Atlas website (Quite a few months ago), I reported it in the survey of usability and improvement of the site, but apparently it still exists to this day. You can use these urls as a workaround: Pages: public=1, public=2, public=3, etc. Status=0: Never Connected Status=1: Connected Status=2: Disconnected country=US: Country code https://atlas.ripe.net/frames/probes/?public=1&search=&status=0&af=&country… https://atlas.ripe.net/frames/probes/?public=1&search=&status=1&af=&country… https://atlas.ripe.net/frames/probes/?public=1&search=&status=2&af=&country… At least it's a little more usable this way. Apparently the menus of the old design are still standing in the new design, so it does not recognize the filters. Regards, Spiroku On Sun, Jan 9, 2022 at 8:00 AM <ripe-atlas-request(a)ripe.net> wrote: > Send ripe-atlas mailing list submissions to > ripe-atlas(a)ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.ripe.net/mailman/listinfo/ripe-atlas > or, via email, send a message with subject or body 'help' to > ripe-atlas-request(a)ripe.net > > You can reach the person managing the list at > ripe-atlas-owner(a)ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ripe-atlas digest..." > > > Today's Topics: > > 1. Possible paging bug on RIPE Atlas Probes page with iltered > results (Kristijonas Lukas Bukauskas) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 08 Jan 2022 21:31:16 +0200 > From: Kristijonas Lukas Bukauskas <kb(a)tsig.nl> > To: ripe-atlas(a)ripe.net > Subject: [atlas] Possible paging bug on RIPE Atlas Probes page with > iltered results > Message-ID: <3b2f50c2f2d09b3bed26285510e5c80d(a)tsig.nl> > Content-Type: text/plain; charset=US-ASCII; format=flowed > > Hello, > > I hope bugs can be reported to this mailing since it is followed and > answered by RIPE Atlas developers. > > On Probes page (https://atlas.ripe.net/probes/) when filtering results > (by any criterion), navigating to the next page (with >) results in > resetting the filter. > > Expected behavior: filtered results not only on the first, but any other > following page when navigating through pages. > > Tested with Firefox 78.15.0esr (64-bit) and Google Chrome 95.0.4638.69 > (Official Build) (64-bit). > > Is it just me or a bug? > > -- > Regards > Kristijonas Lukas Bukauskas > > > > End of ripe-atlas Digest, Vol 125, Issue 2 > ****************************************** >

3 2

Incorrect location of a probe
by Hugo Salgado 11 Jan '22

11 Jan '22

Hi RIPE Atlas. Have a happy new year! I'd like to know how you can report a probe that has a bad geolocation. It's #29811 that appears in southern Chile, but its AS and traceroutes appear to be in Canada. Unfortunately it affects all measurements that try to group geographically by country :( If the host does not cooperate, could a system tag be added indicating "suspicious location"? Thanks a lot! Hugo

3 2

Possible paging bug on RIPE Atlas Probes page with iltered results
by Kristijonas Lukas Bukauskas 08 Jan '22

08 Jan '22

Hello, I hope bugs can be reported to this mailing since it is followed and answered by RIPE Atlas developers. On Probes page (https://atlas.ripe.net/probes/) when filtering results (by any criterion), navigating to the next page (with >) results in resetting the filter. Expected behavior: filtered results not only on the first, but any other following page when navigating through pages. Tested with Firefox 78.15.0esr (64-bit) and Google Chrome 95.0.4638.69 (Official Build) (64-bit). Is it just me or a bug? -- Regards Kristijonas Lukas Bukauskas

1 0

Notification for probes going down for extended period??
by Geert Jan de Groot 04 Jan '22

04 Jan '22

Hi, I have been hosting probes for many years and, judging by the traffic seen, they have seen a fair amount of use, which is good. Despite being on a "home network", I was able to get a small subnet so the probes could run without NAT state nastyness and all. Unfortunately, the ISP providing home connectivity is changing. They used to be innovative, offering IPv6, subnet and lots of features. However the mother telco decided that innovation was bad and is changing the service offering, killing innovative services one by one. Today I received notification that the subnet the probes live on, will be de-activated on Jan 11. I've cancelled my subscription with said ISP on Jan 13 and the house will be on a different ISP then, unfortunately the new ISP is planning to provide subnet service but is in the process of setting things up and cannot provide subnet service today. What is the protocol for signalling "this probe is down and that may be for quite a bit"? And what is the protocol for signalling "this probe is now on a different topology, is no longer on AS3265 and network performance is different"? (I guess several others will have this question, answers on list please) Geert Jan

3 2

v1 Prove #266 gone offline
by Andreas S. Kerber 04 Jan '22

04 Jan '22

Hi, our v1 probe #266 has gone into a boot loop, loosing/reconnecting network link every few seconds. Is there troubleshooting advice for a v1 probe doing that? Already tried on a number other USB feeds and different switches. Andreas

2 1

NanoPi NEO Plus2 won't connect
by Marty Strong 28 Dec '21

28 Dec '21

Hi all! I moved house at the end of June and only recently got round to plugging my NanoPi NEO Plus2 probe #50010 in. It doesn't seem to connect, not even getting a DHCP lease. Is there any way to debug what's wrong with it? https://atlas.ripe.net/probes/50010/ Thanks, Marty

2 1

Announcement regarding the recently discovered log4j vulnerabilities
by Johan ter Beest 22 Dec '21

22 Dec '21

Dear RIPE Atlas probe and anchor hosts, We would like to share some information in light of the log4j issues that were recently made public. After an extensive investigation of our systems, we have determined that both the RIPE Atlas probes and the RIPE Atlas anchors are not vulnerable to the recently discovered log4j vulnerability. More information can be found in the official announcement: https://www.ripe.net/publications/news/announcements/log4j-zero-day-vulnera… We wish you happy holidays and happy measuring :) Kind regards, Johan ter Beest RIPE Atlas Team

1 0

v3 probe has gone offline and can't be revived
by Peter Gutmann 21 Dec '21

21 Dec '21

My v3 probe took itself offline earlier today and attempts to get it back online again haven't worked, after booting it settles into a state where there's no ethernet connection to the router it's attached to, the Power LED is on (obviously), Internet is off, WiFi is blinking slowly, Ethernet is blinking quickly, and WPS is on. Trying to factory reset it has no effect. Does anyone have any ideas on where to go from here?

1 1

swapping a v1 for a v3
by Randy Bush 14 Dec '21

14 Dec '21

a sweet old v1 probe, 2285, in a hard to access (due to covid) place died 19 months ago. i want to swap in a v3, 25898, this weekend. i know i could create a new entry, but how do i delete the old; or better yet, move the data from old to new? stop laughing. :) randy

7 11

RIPE Atlas VM Anchors IPv6 only support?
by Chriztoffer Hansen 13 Dec '21

13 Dec '21

Hello, On Thu, 8 Nov 2018 at 15:35, Alun Davies <adavies(a)ripe.net> wrote: > We just this morning published an article announcing that, as of today, we are accepting applications for anyone interested in hosting RIPE Atlas VM anchors. The article points you to all the information you’ll need to apply for and install a virtual anchor: > > https://labs.ripe.net/Members/alun_davies/announcing-ripe-atlas-vm-anchors I was reading through the list of requirements for hosting RIPE Atlas VM Anchors as of Nov 2021. • https://atlas.ripe.net/docs/anchor-installation-vm/ • https://atlas.ripe.net/legal/anchors/memorandum/ > Network-wise, RIPE Atlas VM anchors have the following requirements: > • The anchor must have native IPv4 and IPv6 (if IPv6 is announced in the host ASN) > • Static IPv4 and IPv6 addresses need to be unfiltered (not firewalled) > • The VM anchor may require up to 10 Mbit bandwidth (it currently requires much less) >From the requirements, I glean if a network is not able to provide an unfiltered/non-firewalled IPv6 address to the VM. IPv6 is not a requirement if not used within the applying host ASN. Only an unfiltered public IPv4 address is. What about the reverse situation? ↪ I.e. the host ASN applying for hosting a VM Anchor is an IPv6-only ASN. Not utilizing IPv4 in the ASN. Therefore not able to provide an unfiltered IPv4 address to the VM? To my current understanding, the latter example is an instant disqualification if applying for hosting a RIPE Atlas VM Anchor? /Chriztoffer

2 3

Inconsistencies in anchor API and measurements
by Malte Appel 18 Nov '21

18 Nov '21

Hi everyone, sorry in advance for the long mail. tl;dr: Anchor API and UI give inconsistent results. Some anchor mesh measurements could be fixed, some might target non-anchors. Not sure what to do about it. I am currently working a lot with RIPE Atlas and recently wanted to use the anchors and their mesh measurements in particular. I wanted to answer two simple queries: 1. Get a list of all active anchors 2. Get a list of all active anchor mesh and probe measurements (traceroute, for my particular use case) However, while trying to answer these queries, I stumbled upon quite some inconsistencies, depending on which interface / API is used. As far as I can tell there are four ways in which one could technically answer query 1: 1. Look at the website: https://atlas.ripe.net/anchors/list/ -> 840 results 2. Query the /anchors API with attribute is_disabled = false: https://atlas.ripe.net/api/v2/anchors/?is_disabled=false -> 844 results 3. Query the /probes API with attributes is_anchor = true and status = 1 (Connected): https://atlas.ripe.net/api/v2/probes/?is_anchor=True&status=1 -> 729 results 4. Query the /probes API with attributes tags = system-anchor and status = 1 (Connected): https://atlas.ripe.net/api/v2/probes/?tags=system-anchor&status=1 -> 729 results Methods 3 and 4 are actually consistent! The main discrepancy is between the /anchors and /probes API: 116 anchors that are listed on the webpage and/or /anchors API as ‘active’ are inactive (97 abandoned; 19 disconnected at time of writing) according to their respective /probes entry. I understand that disconnects might be temporary, but some anchors seem to be inactive for years (at least according to their status) and are still listed as active. I have attached a text file with some notes that go deeper into the differences, but might be hard to read. For query 2, I faced a similar situation: 1. Look at the website: https://atlas.ripe.net/anchors/list/full/ Anchoring Mesh IPv4: 840 Anchoring Mesh IPv6: 739 Anchoring Probes IPv4: 840 Anchoring Probes IPv6: 705 Total: 3124 2. Query the /anchor-measurements API Anchoring Mesh IPv4: 849 Anchoring Mesh IPv6: 743 Anchoring Probes IPv4: 902 Anchoring Probes IPv6: 753 Total: 3247 3. Query the /measurements API with attributes status = 2 (Ongoing), type = traceroute and corresponding attributes: Anchoring Mesh IPv4: af = 4; tags=anchoring,mesh Anchoring Mesh IPv6: af = 6; tags=anchoring,mesh Anchoring Probes IPv4: af = 4; tags=anchoring,probes Anchoring Probes IPv6: af = 6; tags=anchoring,probes For example: https://atlas.ripe.net/api/v2/measurements/?status=2&type=traceroute&af=6&t… Anchoring Mesh IPv4: 1026 Anchoring Mesh IPv6: 902 Anchoring Probes IPv4: 668 Anchoring Probes IPv6: 619 Total: 3215 These results are even more mixed: - Tags can be inconsistent: Some measurements have none, some have the ‘probes’ or ’mesh’ tag, but miss the ’anchoring’ tag. - Some anchors have multiple measurements (especially probes measurements), of which most actually are run by the same set of probes, i.e., they are duplicates. - Which measurements are contained in which of the three result sets is very mixed, maybe I should draw a Venn diagram :) Finally, I looked at the consistency of the IP addresses of the /anchors API (ip_v4 and ip_v6), the /probes API (address_v4, address_v6), the DNS result for the FQDN of the anchors, and the target IP of the mesh/probes measurements. I noticed some problems, since our lab (IIJ) also operates an anchor (probe 6425 [0]) and we updated the IP address some time ago, but are actually not reached by the mesh measurement, because the measurement still targets the old IP. I attached a CSV that includes the raw data (of measurements with some form of problem), but basically there are 93 measurements from connected anchors that fail, and out of which 68 (from 29 anchors) could work, if the measurement would target the correct IP. These measurements have matching anchor/probe IPs and DNS records, so I do not know why the measurement target is stale. There are some additional measurements that could work, but it is unclear what the intended ‘correct’ IP is. On that note, there are 48 measurements that ‘work‘, i.e., they get a response from the target, but it is not clear if the target is the intended receiver: - 8 target abandoned anchors - 18 have different probe and anchor IPs and target one of them - 21 have the same probe and anchor IP but target something else Again, I am sorry for this long mail. I understand that RIPE Atlas is a huge project that has grown over time so it might be hard to keep some things synchronized, and some other things might not be easily decidable (e.g., when to mark an anchor is inactive). However, I think especially the IP address of an anchor in the /anchors and /probes APIs, in the DNS entry, and the target of the mesh/probes measurements need to be consistent. Currently some mesh measurements might target an entirely different machine. I wanted to bring some attention to this, but not sure what else I can do as a user. I don‘t want to complain too much :) For now I will just use all data sources as input and apply some sanity checks. Best, Malte P.S.: Some feedback on how we can bring the measurement of our anchor to target our anchor would be nice though. [0] https://atlas.ripe.net/probes/6425

2 2

RIPE measurement Credits required
by Mccherry, Paul (Student) 02 Nov '21

02 Nov '21

Dear All I have applied and been granted to install an Anchor at my University to generate credits to make measurements, this is taking some time to prepare the equipment etc. In the meantime I need to carry out some measurement tests for a paper I am working on. Would anybody be able to kindly send me some RIPE credits which I will hopefully pay back once I have the anchor up and running ? Regards Paul McCherry Phd Student From: ripe-atlas-request(a)ripe.net<mailto:ripe-atlas-request@ripe.net> Sent: 25 October 2021 23:07 To: ripe-atlas(a)ripe.net<mailto:ripe-atlas@ripe.net> Subject: [External] ripe-atlas Digest, Vol 122, Issue 6 This email originated outside the University. Check before clicking links or attachments. Send ripe-atlas mailing list submissions to ripe-atlas(a)ripe.net To subscribe or unsubscribe via the World Wide Web, visit https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.rip… or, via email, send a message with subject or body 'help' to ripe-atlas-request(a)ripe.net You can reach the person managing the list at ripe-atlas-owner(a)ripe.net When replying, please edit your Subject line so it is more specific than "Re: Contents of ripe-atlas digest..." Today's Topics: 1. RIPE Atlas Virtual Anchor Application (TNaumann(a)telekom.de) ---------------------------------------------------------------------- Message: 1 Date: Mon, 25 Oct 2021 22:06:40 +0000 From: <TNaumann(a)telekom.de> To: <ripe-atlas(a)ripe.net> Subject: [atlas] RIPE Atlas Virtual Anchor Application Message-ID: <FR2P281MB0775F27CBE4C9FAC283EC010A6839(a)FR2P281MB0775.DEUP281.PROD.OUTLOOK.COM> Content-Type: text/plain; charset="iso-8859-1" Dear Ripe Atlas Team, Could we have any estimation about our application for the first virtual anchor in New York? We would like to have a physical and virtual probe at the same time and recycle/reuse the physical later this Year somewhere else in U.S. [cid:image001.png@01D7C9FD.22665680] Kind Regards Thomas Naumann Deutsche Telekom Technik GmbH Network Infrastructure (T-NWI) Thomas Naumann Ginnheimer Stadtweg 88, 60431 Frankfurt am Main +49 69 20060 4042 (Phone) +49 170 3374602 (Mobil) E-Mail: TNaumann(a)telekom.de<mailto:TNaumann@telekom.de> https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.teleko…<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.teleko…><https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.teleko…> Erleben, was verbindet. Die gesetzlichen Pflichtangaben finden Sie unter: https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.teleko…<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.teleko…><https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.teleko…> Gro?e Ver?nderungen fangen klein an - Ressourcen schonen und nicht jede E-Mail drucken.

10 15

Re: [atlas] [External] ripe-atlas Digest, Vol 122, Issue 8
by Mccherry, Paul (Student) 27 Oct '21

27 Oct '21

Many thanks Nick, I will pay them back as soon as possible. Regards Paul Get Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: ripe-atlas <ripe-atlas-bounces(a)ripe.net> on behalf of ripe-atlas-request(a)ripe.net <ripe-atlas-request(a)ripe.net> Sent: Wednesday, October 27, 2021 9:20:42 PM To: ripe-atlas(a)ripe.net <ripe-atlas(a)ripe.net> Subject: [External] ripe-atlas Digest, Vol 122, Issue 8 This email originated outside the University. Check before clicking links or attachments. Send ripe-atlas mailing list submissions to ripe-atlas(a)ripe.net To subscribe or unsubscribe via the World Wide Web, visit https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.rip… or, via email, send a message with subject or body 'help' to ripe-atlas-request(a)ripe.net You can reach the person managing the list at ripe-atlas-owner(a)ripe.net When replying, please edit your Subject line so it is more specific than "Re: Contents of ripe-atlas digest..." Today's Topics: 1. Re: RIPE measurement Credits required (Nick Hilliard) 2. Re: RIPE measurement Credits required (Carsten Schiefner) 3. Re: RIPE measurement Credits required (Dario Ciccarone) ---------------------------------------------------------------------- Message: 1 Date: Wed, 27 Oct 2021 21:06:27 +0100 From: Nick Hilliard <nick(a)foobar.org> To: "Mccherry, Paul (Student)" <p.mccherry(a)lancaster.ac.uk> Cc: "ripe-atlas(a)ripe.net" <ripe-atlas(a)ripe.net> Subject: Re: [atlas] RIPE measurement Credits required Message-ID: <d1cb2c10-5361-cc7e-37b8-67c3183be7eb(a)foobar.org> Content-Type: text/plain; charset=windows-1252; format=flowed Mccherry, Paul (Student) wrote on 27/10/2021 21:02: > I have applied and been granted to install an Anchor at my University to > generate credits to make measurements, this is taking some time to > prepare the equipment etc. ?In the meantime I need to carry out some > measurement tests for a paper I am working on. Would anybody be able to > kindly send me some RIPE credits which I will hopefully pay back once I > have the anchor up and running ? just sent you 50m. Nick ------------------------------ Message: 2 Date: Wed, 27 Oct 2021 22:09:56 +0200 From: Carsten Schiefner <carsten(a)schiefner.de> To: "ripe-atlas(a)ripe.net" <ripe-atlas(a)ripe.net> Subject: Re: [atlas] RIPE measurement Credits required Message-ID: <44a5f3d1-6be8-4c59-8c4b-9ce706c4578e.maildroid@localhost> Content-Type: text/plain; charset=utf-8 Your user id? -- Von meiner H?ngematte aus gesendet. -----Original Message----- From: "Mccherry, Paul (Student)" <p.mccherry(a)lancaster.ac.uk> To: "ripe-atlas(a)ripe.net" <ripe-atlas(a)ripe.net> Sent: Mi., 27 Okt. 2021 22:02 Subject: [atlas] RIPE measurement Credits required Dear All I have applied and been granted to install an Anchor at my University to generate credits to make measurements, this is taking some time to prepare the equipment etc. In the meantime I need to carry out some measurement tests for a paper I am working on. Would anybody be able to kindly send me some RIPE credits which I will hopefully pay back once I have the anchor up and running ? Regards Paul McCherry Phd Student From: ripe-atlas-request(a)ripe.net<mailto:ripe-atlas-request@ripe.net> Sent: 25 October 2021 23:07 To: ripe-atlas(a)ripe.net<mailto:ripe-atlas@ripe.net> Subject: [External] ripe-atlas Digest, Vol 122, Issue 6 This email originated outside the University. Check before clicking links or attachments. Send ripe-atlas mailing list submissions to ripe-atlas(a)ripe.net To subscribe or unsubscribe via the World Wide Web, visit https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.rip… or, via email, send a message with subject or body 'help' to ripe-atlas-request(a)ripe.net You can reach the person managing the list at ripe-atlas-owner(a)ripe.net When replying, please edit your Subject line so it is more specific than "Re: Contents of ripe-atlas digest..." Today's Topics: 1. RIPE Atlas Virtual Anchor Application (TNaumann(a)telekom.de) ---------------------------------------------------------------------- Message: 1 Date: Mon, 25 Oct 2021 22:06:40 +0000 From: <TNaumann(a)telekom.de> To: <ripe-atlas(a)ripe.net> Subject: [atlas] RIPE Atlas Virtual Anchor Application Message-ID: <FR2P281MB0775F27CBE4C9FAC283EC010A6839(a)FR2P281MB0775.DEUP281.PROD.OUTLOOK.COM> Content-Type: text/plain; charset="iso-8859-1" Dear Ripe Atlas Team, Could we have any estimation about our application for the first virtual anchor in New York? We would like to have a physical and virtual probe at the same time and recycle/reuse the physical later this Year somewhere else in U.S. [cid:image001.png@01D7C9FD.22665680] Kind Regards Thomas Naumann Deutsche Telekom Technik GmbH Network Infrastructure (T-NWI) Thomas Naumann Ginnheimer Stadtweg 88, 60431 Frankfurt am Main +49 69 20060 4042 (Phone) +49 170 3374602 (Mobil) E-Mail: TNaumann(a)telekom.de<mailto:TNaumann@telekom.de> https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.teleko…<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.teleko…><https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.teleko…> Erleben, was verbindet. Die gesetzlichen Pflichtangaben finden Sie unter: https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.teleko…<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.teleko…><https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.teleko…> Gro?e Ver?nderungen fangen klein an - Ressourcen schonen und nicht jede E-Mail drucken.

1 0

RIPE Atlas Virtual Anchor Application
by TNaumann＠telekom.de 26 Oct '21

26 Oct '21

Dear Ripe Atlas Team, Could we have any estimation about our application for the first virtual anchor in New York? We would like to have a physical and virtual probe at the same time and recycle/reuse the physical later this Year somewhere else in U.S. [cid:image001.png@01D7C9FD.22665680] Kind Regards Thomas Naumann Deutsche Telekom Technik GmbH Network Infrastructure (T-NWI) Thomas Naumann Ginnheimer Stadtweg 88, 60431 Frankfurt am Main +49 69 20060 4042 (Phone) +49 170 3374602 (Mobil) E-Mail: TNaumann(a)telekom.de<mailto:TNaumann@telekom.de> www.telekom.de<http://www.telekom.de/> Erleben, was verbindet. Die gesetzlichen Pflichtangaben finden Sie unter: www.telekom.de/pflichtangaben-dttechnik<http://www.telekom.de/pflichtangaben-dttechnik> Große Veränderungen fangen klein an - Ressourcen schonen und nicht jede E-Mail drucken.

1 0

New on RIPE Labs: Latency Into Your Network - As Seen From RIPE Atlas
by Alun Davies 14 Oct '21

14 Oct '21

Dear colleagues, New prototype visualisations - put together by Emile Aben and Agustin Formoso using the ObservableHQ platform - allow you to visualise network deployment. Drawing on latency data available from RIPE Atlas, each visualisation aims at helping reveal insights about structural latency into given networks. Read more and try it out on RIPE Labs: https://labs.ripe.net/author/emileaben/latency-into-your-network-as-seen-fr… Kind regards, Alun Davies RIPE Labs Editor RIPE NCC

1 0

Training material
by Hank Nussbacher 12 Oct '21

12 Oct '21

I know of: https://www.ripe.net/support/training/material/measurements-and-tools-train… which from slide 79-176 is dedicated to explaining RIPE Atlas. Problem is that it is from July 2019. Is there a later more up to date RIPE Atlas PPT? Thanks, Hank

2 1

ripe atlas Probe 32256 is disconnected firm ware upgrade com326.193.612
by kiran.gunana＠colruytgroup.com 12 Oct '21

12 Oct '21

Dear Ripe Community, Noticed our probe's firmware got upgraded and from there on our measurements stopped working. 2021-10-10 03:31:00 UTC Probe firmware upgraded Your probe #32256 upgraded its firmware from version 5020 to version 5030 Any clue on how we can fix this, current measurements does not work and tried creating new measurements which also does not work. Old Measurement : Ping measurement to www.hln.be: ID23382497 Last successfull measurment was at 2021-10-10 02:46 New Measurement : Ping measurement to www.f5.com from probe 32256 : ID32499756 Recevied following email from ripe: Your probe 32256 has been disconnected from the RIPE Atlas infrastructure since 2021-10-10 02:39:46 UTC. You may be able to learn more about the possible cause from the "Status" tab on your probe's information page: https://atlas.ripe.net/probes/32256/#!tab-status Current status says connected and no measurement works. Kind Regards, Kiran Gunana Dit bericht is onderworpen aan de voorwaarden beschikbaar op onze website Ce message est soumis aux conditions disponibles sur notre site web This message is subject to the terms and conditions available on our website

2 1

New RIPE Atlas Sponsorship opportunities
by Lia Hestina 11 Oct '21

11 Oct '21

Dear colleagues, Today we launch our new RIPE Atlas sponsorship model, offering more benefits and exposure to our future sponsors. Thanks to the contributions we've received so far, we've been able to keep distributing hardware probes free of charge all over the world, with each new probe helping make RIPE Atlas a more useful tool for measuring and monitoring the state of the Internet. Read our story on RIPE Labs: https://labs.ripe.net/author/lia_hestina/help-build-a-bigger-better-ripe-at… We're now asking you to help us expand the RIPE Atlas network further still. Even the smallest contribution from you will keep our vibrant community going so we can carry on making the Internet a more stable place for all. Check what our new sponsorship opportunities have to offer: https://atlas.ripe.net/get-involved/become-a-sponsor/ Kind regards, Lia Hestina On behalf of the RIPE Atlas team _________ RIPE NCC

2 2

Scheduled work on RIPE Atlas
by Viktor Naumov 28 Sep '21

28 Sep '21

Dear RIPE Atlas users, We have planned maintenance on the main RIPE Atlas backend database Tuesday, 28 September starting at 08:00 UTC, 10:00 Amsterdam local time. We expect some unavailability of the service for a short while. During this time the website (UI and APIs) may not be responding (properly). This also means that requests for new measurements will be denied or delayed. Data from existing measurements will still be collected normally, though access to them can be impacted. Our apologies for the inconvenience. Best Regards, Viktor Naumov

1 1