- ripe-atlas - mailman.ripe.net

Credits Available
by Daryl Morse 06 Feb '25

06 Feb '25

Hello, I have credits available. Let me know who you are, how many you need and what you will do with them. Regards.

1 0

Re: Ask For Credit for Traceroute Measurements
by Ernst J. Oud 06 Feb '25

06 Feb '25

Semebia, Just transferred 10 million credits to your e-mail address. Let me know if you need more. Wishing you success with your research. Regards, Ernst J. Oud > On 5 Feb 2025, at 23:59, Semebia Wurah <swurah(a)andrew.cmu.edu> wrote: > > > Thank you, Ernst! Kindly send it to swurah(a)andrew.cmu.edu > >> On Thu, Feb 6, 2025 at 12:57 AM Ernst J. Oud <ernstoud(a)gmail.com> wrote: >> Semebia, >> >> Nice! No problem. To what email address should I transfer 10 million credits? >> >> Regards, >> >> Ernst J. Oud >> >>>> On 5 Feb 2025, at 23:48, Semebia Wurah <swurah(a)andrew.cmu.edu> wrote: >>>> >>> >>> Hello everyone, >>> I hope this finds you well. My name is Semebia Wurah, and I am a Research Associate at Carnegie Mellon University Africa, working under the supervision of Prof. Theophilus Benson. >>> >>> We are conducting traceroute measurements using RIPE Atlas to analyze the Internet ecosystem in Africa, focusing on the growth of AS peering and IXP utilization. Our research aims to provide insights into the region’s interconnection landscape and help identify opportunities for improving local traffic exchange. >>> >>> We would greatly appreciate any credits you can share to continue our measurements. These credits will enable us to perform additional traceroutes and expand our analysis. >>> >>> Please let me know if you need any further information. Thank you in advance for your time and support! >>> >>> Best regards, >>> Semebia Wurah >>> >>> -- >>> Semebia Yaa Wurah >>> Research Associate >>> Pronouns: she/her/hers >>> Carnegie Mellon University Africa >>> >>> Regional ICT Center of Excellence Bldg >>> Plot No A8, Kigali Special Economic Zone Phase, Rwanda >>> Phone: +250 798945462 | Email: swurah(a)andrew.cmu.edu >>> >>> ----- >>> To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/ >>> As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. >>> More details at: https://www.ripe.net/membership/mail/mailman-3-migration/ > > > > -- > Semebia Yaa Wurah > MSc Electrical and Computer Science > Pronouns: she/her/hers > Carnegie Mellon University Africa > > Regional ICT Center of Excellence Bldg > Plot No A8, Kigali Special Economic Zone Phase, Rwanda > Phone: +250 798945462 | Email: swurah(a)andrew.cmu.edu >

1 0

Open postdoc position at HPI, Potsdam
by Vaibhav Bajpai 04 Feb '25

04 Feb '25

Dear colleagues, I am currently seeking a full-time postdoctoral researcher to join my chair (Data- intensive Internet Computing) at the Hasso Plattner Institute, Germany. We do systems research, and publish papers at the intersection of Internet measurements, security and privacy. We actively use RIPE atlas in our measurement projects. The work place is in Potsdam (near Berlin), Germany. Interested candidates, please apply here: https://jobs.plattnerfoundation.org/HPI/job/Potsdam-Postdoctoral-Researcher… Kind regards, -- Vaibhav ------------------------ Prof. Dr. Vaibhav Bajpai, www.vaibhavbajpai.com

1 0

Credits for an assignment
by Stuhrberg, Florian 03 Feb '25

03 Feb '25

Dear all, I hope you are doing well. My name is Florian Stuhrberg, and I am a master's student at Hasso-Plattner-Institut in Germany. As part of an assignment, I am currently investigating in DNS over UDP and DNS over TLS response times, using the RIPE Atlas and the corresponding API. However, after my measurements for DNS over UDP, I do not have sufficient credits to conduct the measurements for DNS over TLS. Is it possible that you could kindly share some RIPE Atlas credits, so that I can finish the assignment? Please feel free to let me know if you need any more information. Thank you in advance. Kind regards, Florian Stuhrberg

4 3

Why measurements using api are apt to fail while those using web interface can usually succeed?
by 孙乐童 02 Feb '25

02 Feb '25

Dear all, I have been attempting to use Atlas to launch traceroute measurements recently. Initially, I used ripe.atlas.cousteau to run the measurements in batches, keeping the total number under 10,000 to avoid exceeding the measurement limit. However, only 10% of the measurements returned successful results, while the other 90% showed the status "scheduling denied." Next, I tried launching only 12 measurements in batch, where each measurement contained one traceroute from a specific probe to a designated IPv4 destination. Out of these, 4 succeeded and the other 8 showed the status "specified". Following that, I launched the 12 measurements one by one with 2-second intervals, resulting in a success rate of 6 out of 12. However, when I increased the interval to 3 seconds, the success rate dropped to 4 out of 12. Interestingly, when I created the same measurements for the designated probes and destinations through the web interface, all of them were successful. Below is the Python code I used to launch the measurements: fromripe.atlas.cousteauimport ( Traceroute, AtlasSource, AtlasRequest, AtlasCreateRequest, AtlasResultsRequest, AtlasLatestRequest, ProbeRequest ) traceroute=Traceroute(af=4, target=dstip, description="traceroute subpref ip {} from {}{}".format(dstip, probe_type, probe_value), protocol='ICMP') if probe_type =='asn': probe_value =int(probe_value) source = AtlasSource(type=probe_type, value=probe_value, requested=1, tags={"include": ["system-ipv4-capable"]}) _key = ATLAS_API_KEY_2 for _ inrange(2): atlas_request = AtlasCreateRequest( start_time=datetime.utcnow() + timedelta(random.randint(0, 1)), key=_key, measurements=[traceroute], sources=[source], is_oneoff=True ) (is_success, response) = atlas_request.create() if is_success: print('create_task', dstip, is_success, response) msm_id = response['measurements'][0] return Could you kindly let me know if there might be an issue with my approach or provide any advice on how to improve this process? I would greatly appreciate any guidance. Thank you very much! Best regards, Sun Letong

4 7

Ripe Atlas Measurement Results and API Usage
by Huseyn Gambarov 30 Jan '25

30 Jan '25

Hello. I was implementing a mechanism to read the measurement results from the Ripe Atlas for many asynchronous measurements. In this process, I have faced multiple questions regarding the internal mechanisms of Ripe Atlas, and I would be thankful if you could help me clarify them. First, in the Ripe Atlas, I sometimes get “-1” in the result indicating 100% packet loss and sometimes very long RTTs. Can you tell me please what is the condition when Ripe gives up on a target and marks it as "-1”? Second, I have implemented asynchronous reading using web sockets and faced a rate limit on several concurrent web socket connections. The error message said: 'There are too many connections from this IP address. Try making multiple subscriptions on the same connection.’ Can you tell me please, if there is a limit on the number of subscriptions on the same connection? To solve the issue in the second question, I implemented a polling mechanism that periodically checks if the measurement is finished. In order to not overload the API, I attempted to retrieve multiple measurement results in a single call using the following API endpoint: GET /api/v2/measurements/{pk}/latest/ The documentation of that API endpoint states: "Get the most recent results from one or more measurements”. However, I need help understanding how to specify multiple measurement IDs in this endpoint, because all options I tried failed with HTTP status code 405 (Method Not Allowed). Could you please show me the correct way of using this API endpoint? Thank you! With regards, Huseyn Gambarov

3 2

Atlas UI: Redesigned Probe Detail Pages in Beta
by Stephen Suess 29 Jan '25

29 Jan '25

Hello Atlas friends, We’re excited to announce the early beta release of our redesigned probe detail pages in the Atlas UI. Over the past few months, we’ve been rethinking the structure and usability of these pages, and we’re sharing this early version to gather your feedback as we continue to develop and refine the design and features. Here’s how they are organised: - Overview: Probe information, map, traffic chart, links to measurements, and well-known target stats. - Network: IPv4/IPv6 overview and history. - Results: Grouped time-series charts for well-known targets and built-in measurements. - Manage: Tools for Sharing, Notifications, Transfer, SSH Key management, and Write-off. This release is very much a work in progress, and you can expect further changes and improvements as we iterate on the design and features. You can try it out by enabling the beta toggle in your preferences (https://atlas.ripe.net/prefs). We’d love for you to explore the new design and share your thoughts—your feedback will be instrumental in shaping the final version. For the full release notes you can go here: https://atlas.ripe.net/docs/releases/website/2025-01-28.html Thanks for being part of the community, and we look forward to hearing from you. Kind regards, Stephen Atlas UI

3 2

weird probe "outage"
by Sulev-Madis Silber 28 Jan '25

28 Jan '25

i just recently got message that my 65133 mox probe is offline according to status logs, it was offline for a ~week before this notice was sent out. notices are sent after 30min offline i didn't touch probe nor network nor do i know why that report was late or whether it even was really offline this is some recent issue maybe? or brand new issue? sos shows probe itself is up since i got it, 3+ months

1 0

Schroedinger's AAAA?
by Peter Eckel 28 Jan '25

28 Jan '25

I have a strane effect with probe 10293. Under "System Tags" I have both "Resolves AAAA Correctly" and "Resolves AAAA Incorrectly" listed. Apparently only one of the tags can be correct - or am I missing something? Best regards and seasonal wishes, Peter.

5 4

Oddity in "atlas-probe-traffic" measurement data/graph
by ripe＠nurfuerspam.de 28 Jan '25

28 Jan '25

Hi, Probes report the traffic volume they see on the device's/machine's interfaces in built-in measurement #9002 (on software probes, this needs to be enabled manually for privacy reasons). I use that to keep an eye on the behavior/health of the probe's host machine via the graphs generated by RIPEstat, which works well most of the time. Sometimes, however, there is an oddity in the data, namely extreme outliers. See attached graph, showing a peak of greater than 6.6 Gbps, when the "normal" traffic rarely exceeds 2Mbit/s. The underlying data shows an unusual high amount of bytes/packets sent/received for one instant that is pretty much impossible, here the data points around the anomaly (from [1]): [...] { "timestamp": 1736330734, "bytes_recv": 70881.58333333333, "bytes_sent": 63566.92222222222, "packets_recv": 737.8166666666667, "packets_sent": 700.6, "interfaces": [ "eth0" ] }, { "timestamp": 1736330921, "bytes_recv": 925866981.9732621, "bytes_sent": 820879052.6524065, "packets_recv": 8351935.347593583, "packets_sent": 8177239.866310161, "interfaces": [ "eth0" ] }, { "timestamp": 1736331101, "bytes_recv": 106008.85555555555, "bytes_sent": 88055.43333333333, "packets_recv": 1100.5944444444444, "packets_sent": 971.6666666666666, "interfaces": [ "eth0", "he-ipv6" ] }, [...] I think I've seen similar behavior on all of my software probes at one time or another, don't recall whether this also previously occured with my HW probe. So far, I have not been able to manually reproduce this, but it seems this is typically related to issues in communication with the controller, be it something on the controller side, like was more frequent/pronounced during the migration to the new controller infrastructure. Be it something on the probe side, e.g., temporary issue in network stack configuration. My current hypothesis is that when the probe cannot send off the measurement data, the accumulated data _for this particular measurement type_ is somehow getting corrupted, and the corrupted data is then sent once the communication issues are resolved, and data upload resumes. E.g., in this case, from the logs, it looks as if a reregistration with the controller was being done during minute 10:08, with the measurement data for #9002 taken just when the re-registration started. Not sure whether that is just coincidence, or whether there is a causal relation between the two. Anyone else seeing something similar, occasionally at least? Any idea what might be going on? (Have not gotten too far yet scouring through the probe/measurement code to see whether that yields any hints.) Thanks! R. [1] https://stat.ripe.net/data/atlas-probe-traffic/data.json?probe_id=1008486&m…

2 2