- ripe-atlas - mailman.ripe.net

Proposal: Measure well-known CDNs,[CDN-HTTP]
by Robert Kisteleki 30 Dec '22

30 Dec '22

Dear RIPE Atlas users, We recently published a RIPE Labs article containing a few proposals: https://labs.ripe.net/author/kistel/five-proposals-for-a-better-ripe-atlas/. We'd like to encourage you to express your comments about this proposal (if you'd like to share them) here. Regards, Robert Kisteleki For the RIPE Atlas team

8 9

Re: [atlas] DNS issue
by Mezgani Ali 30 Dec '22

30 Dec '22

> Hello, > > > I set my probe and I got a problem with DNS. > > Please what figure out on my probe ? Maybe I have to set other DNS address into my ADSL Router. > > Any query are welcome. Regards, > > > > Mezgani Ali's home > General > <https://atlas.ripe.net/frames/probes/63005/#tab-general>Network > <https://atlas.ripe.net/frames/probes/63005/#tab-network>Built-ins > <https://atlas.ripe.net/frames/probes/63005/#tab-builtins>UDMs > <https://atlas.ripe.net/frames/probes/63005/#tab-udms>Status (beta) > <https://atlas.ripe.net/frames/probes/63005/#tab-status> > General InformationEdit <https://atlas.ripe.net/frames/probes/63005/form-fragment/general/> > Id 63005 > MAC Address D8:58:D7:03:02:C0 > Architecture atlas-mox > Firmware Version None > Router Type > Bandwidth Limit Not set > DNS Entry Simple: > p63005.probes.atlas.ripe.net <http://p63005.probes.atlas.ripe.net/> > Shared Publicly Yes > User Tags <https://atlas.ripe.net/docs/getting-started/probe-tags.html#user-tags> Mobile Datacentre IPv6 Tunnel IPv66to4 ADSL VPN Native IPv4 IPv6-onlyDocker > System Tags <https://atlas.ripe.net/docs/getting-started/probe-tags.html#system-tags> V5 DNS problem suspected > <https://atlas.ripe.net/frames/probes/63005/ripestat/9002/> > Connection & Traffic > > > Connected Time 3 months > > Management SharingEdit <https://atlas.ripe.net/frames/probes/63005/form-fragment/sharing/> > Currently you're not sharing this probe within your LIR. > > The management of this probe is not allowed for any other individuals. > > NotificationsEdit <https://atlas.ripe.net/frames/probes/63005/form-fragment/notifications/> > There aren't any downtime notifications configured for this probe. > There aren't any uptime reports sent for this probe. > Transfer OwnershipEdit <https://atlas.ripe.net/frames/probes/63005/form-fragment/transfer/> > You can transfer ownership of the probe to someone else by submitting this form. Note that this change cannot be undone. > > 3 months > #63005 > Firmware > None > Architecture > atlas-mox > MAC Address > D8:58:D7:03:02:C0 > Update Location <https://atlas.ripe.net/frames/probes/63005/location/> > <3939.jpeg><3940.jpeg><3939.jpeg><3940.jpeg><3939.jpeg><3940.jpeg> > <a51052730657106d6f160440dd590bec.png> > + > <https://atlas.ripe.net/probes/63005/#>- > <https://atlas.ripe.net/probes/63005/#>Leaflet <http://leafletjs.com/> | Tiles © Esri > Kind regards, > > Mezgani Ali > ali.mezgani(a)nativelabs.ma <mailto:ali.mezgani@nativelabs.ma> > https://wiki.debian.org/mezgani <https://wiki.debian.org/mezgani> > > ⢀⣴⠾⠻⢶⣦⠀ Active member of IETF, GNU, Debian, FreeBSD and Kernel. > ⣾⠁⢠⠒⠀⣿⡁ > ⢿⡄⠘⠷⠚⠋⠀ > ⠈⠳⣄⠀ > > > >> On 30/12/2022, at 17:54, Gert Doering <gert(a)space.net <mailto:gert@space.net>> wrote: >> >> Hi, >> >> On Fri, Dec 30, 2022 at 08:42:18AM -0800, Randy Bush wrote: >>> i asked this quietly before, but let me be more direct. >>> >>> how much private data is there actually? what percentage of the stored >>> data is private? >> >> Indeed, this is a good question. If it turns out that there is a lone >> private measurement from me, or "in the sub-percent range", I'm willing >> to let myself be convinced in the name of "make the measurement backend >> more simple = robust"... >> >> Gert Doering >> -- NetMaster >> -- >> have you enabled IPv6 on something today...? >> >> SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer >> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann >> D-80807 Muenchen HRB: 136055 (AG Muenchen) >> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 >> -- >> ripe-atlas mailing list >> ripe-atlas(a)ripe.net <mailto:ripe-atlas@ripe.net> >> https://lists.ripe.net/mailman/listinfo/ripe-atlas >

1 0

Probe 24434 down but pingable
by Dave 30 Dec '22

30 Dec '22

Hi, One of my probes is pingable but the status is disconnected for over a day. Could it be that it has troubles with DNS over IPv6 and that it is not smart enough to fall back to IPv4? https://atlas.ripe.net/probes/24434/#tab-general Thanks, Dave

3 4

Re: [atlas] A number of built-ins stopped?
by Ernst J. Oud 23 Dec '22

23 Dec '22

L.S. All the probes in NL that I had a look at, in a variety of different ASN’s, have no data available via the Atlas web of via the api (JSON, Magellan) for a.o. built-in measurement 1009 (ping to a.root-servers.net) and several others after December 22nd, around 18:00 hrs. UTC. When I have a look at German probes there is data available. This thus appears to be a problem with all and only Dutch probes’ data. A normal ping via a Windows command line works fine, i.e. a.root-servers.net is reachable. Creating a ping measurement via Magellan to a.root-servers.net using Dutch probes generates results, i.e. the probe infrastructure works but data storage does not, for data from probes in NL. Rather serious problem I guess. No mentioning on status.ripe.net though. Had an email conversation with Robert from the Atlas team today. No solution yet. Regards, Ernst J. Oud Met vriendelijke groet, Ernst J. Oud

2 1

Apologies for OOO reply
by Guy Meyer 23 Dec '22

23 Dec '22

Hi all, As some of you might have seen, something went wrong with my out-of-office email settings, and I'm sorry that you received the email multiple times. We're cleaning up the mailing list, and I wish you all happy holidays and a great year ahead. Kind regards, Guy Meyer

1 0

A number of built-ins stopped?
by Ernst J. Oud 23 Dec '22

23 Dec '22

Hi, Both on the atlas webpages as via the api, data for a number of built-ins stop at December 22th, at around 18:00 UTC for all my probes in 4 different ISP’s, all in NL. For instance measurement 1009, ping to a.root-servers.net stopped at that time while measurement 1010, ping to b.root-servers.net continues normally. Also stopped are: #1017 Ping to ctr-nue13.atlas.ripe.net #1012 Ping to d.root-servers.net #1013 Ping to e.root-servers.net #1015 Ping to h.root-servers.net #1005 Ping to i.root-servers.net Any idea what is causing this? Regards, Ernst J. Oud

1 0

Proposal: Generic HTTP measurements [GENERIC-HTTP]
by Robert Kisteleki 22 Dec '22

22 Dec '22

Dear RIPE Atlas users, We recently published a RIPE Labs article containing a few proposals: https://labs.ripe.net/author/kistel/five-proposals-for-a-better-ripe-atlas/. We'd like to encourage you to express your comments about this proposal (if you'd like to share them) here. Regards, Robert Kisteleki For the RIPE Atlas team

3 2

Low cost, low energy consumption probe
by Ernst J. Oud 21 Dec '22

21 Dec '22

Hi, I have probes running on VMware (CentOS), Ubuntu (native) and on Docker for Windows. These small PC’s consume a lot more than the Ripe supplied HW probes. So I looked for a cheap and *very* low energy alternative. TP-Link sells the WR802N mini travel router for around USD 20 (o.a. on Amazon) that runs the latest version of OpenWRT fine and the Atlas probe SW has been ported to it. With some acrobatics I managed to turn it into an excellent alternative. Runs fine, energy consumption 700 mW (!). The device is as small as the Ripe supplied probe. Since the flash memory of this device is too small for some of the required libraries, the acrobatics involved copying them to RAM and putting links to them in flash. This means that with FTP after a power outage a couple of files need to be copied to the device and that one command must be given after that. There is a more expensive version with a USB port so that a USB stick can be used to store those files. Will investigate that option. If someone here wants a detailed write-up let me know and I will invest the time to write it. Regards, Ernst J. Oud

3 4

Enable/Disable software probe
by Ernst J. Oud 21 Dec '22

21 Dec '22

Hi, Two questions: 1. What would be the best way to temporarily disable (and enable again) a software probe? Is there some command for this besides killing all processes and run the ATLAS script again? Running a probe on CentOS, OpenWRT and Ubuntu 18.04 (all on separate ISP’s). I am currently logging the latency differences between HW and SW probes (both natively and under VMware emulation). Differences appear to be in the 1.5 ms. range. Negligible for my 4G networks but on my fiber line such a difference is more than 30% of the average latency. Will post more results soon. 2. Why can’t Magellan report on the first ping latency to ping.ripe.net? It always reports “No packets found”. All other reports work fine. TIA. Regards, Ernst J. Oud

2 1

Proposal: Measure well-known CDNs,[CDN-HTTP]
by Dirk-Jan van Helmond 20 Dec '22

20 Dec '22

Hi RIPE Atlas users, I stumbled upon this thread and I wanted to chime in. I work for Cloudflare and we of course use a wide set of external visibility and performance management tools to track our visibility. But on occasions I also use the RIPE Atlas network to perform some specific reachability tests. I believe the distribution of probes and the fact that they're als in eyeball ASN is a really valuable factor that RIPE Atlas has. At the moment I'm running into a limitation around HTTP tests. I would like to use the RIPE Atlas network to curl some pages to retrieve and evaluate the HTTP headers. This is currently not possible with Atlas as it is only allowed to probe Anchors for safety reasons, which I fully understand and support (you don't want to turn Atlas into a botnet). The HTTP targets that I would like to probe would be all on our IP space, so I don't see a direct risk from the outbound part of the request. I can see there is some risk with the return part, where the content from an "unknown" system gets returned to a probe in someone's private network, with possible ramifications. So I was pondering about two possible options that can potentially help me, but not risk the Atlas project or demonstrate favoritism towards particular companies. 1) One of the options would be to open up some of our IP space to the probes for HTTP probes. 2) The other option would be for us to host an Anchor and put our CDN in front of it. That way RIPE has complete control over the returned data. I would love to hear the general consensus on such approach and the viability of it Best Regards, -- Dirk-Jan van Helmond On 17/12/2022 00:19, Barry Raveendran Greene wrote: > > >> On Dec 16, 2022, at 23:29, Stephane Bortzmeyer <bortzmeyer at nic.fr> wrote: >> >> There is a larger problem here, a more strategic one: such a feature >> would contribute to the centralisation of the Internet, which is >> already too important. Tagging some targets are "important" and >> "worthy of measurements" would mean that we consider some HTTP servers >> to be more useful than others. That would be a bad message from RIPE. > > We’ve come full circle - we started with centralized PTTs - moved to a decentralized ASN/Paul Baran model - now Re-centralized based on marketing domination. > > +1 with Stephane’s observation. The selection of who to measure is a statement. +1 Also, while the data would be useful, I don't think the role of the ripe ncc is to grade commercial services. Let other companies or individual researchers do that. -- Dirk-Jan van Helmond Leader Solutions Engineering EMEA mobile: +31611645622 email: dirkjan(a)cloudflare.com www.cloudflare.com <https://www.cloudflare.com/>

1 0