- ripe-atlas - mailman.ripe.net

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

Small upcoming change in measurement metadata daily dumps
by Robert Kisteleki 28 Jan '25

28 Jan '25

Hello, We plan to make a small change in the measurement metadata daily dumps available at https://ftp.ripe.net/ripe/atlas/measurements/. Up until now these files contain the "current working set" which is defined as any measurement that runs right now or has been running in the past 14 days. (This also means that there's considerable overlap between today's and yesterday's dump.) We'll shorten this period to 7 days in early February. This has zero effect on the vast majority of our users. Those who periodically download and use these files with lower than 7 day frequency will need to update their scripts accordingly. Regards, Robert Kisteleki for RIPE Atlas team

1 0

Iso installation issue with RIPE Atlas anchor for LACNIC (uy-mvd-as28000)
by Elisa 07 Jan '25

07 Jan '25

Good morning, We received the ISO image to install the anchor but we encountered an issue. When we execute the "Install RIPE NCC Atlas Anchor" (see image) at some point the machine tries to resolve ks.atlas.ripe.net <http://ks.atlas.ripe.net/>, but it isn't connected to the network yet because to connect to the network we have to be inside the operating system, the installation process can't continue. We've been following instructions in: https://atlas.ripe.net/docs/howtos/installing-atlas-anchor.html and the machine has the following characteristics: 1 CPU type x86-64-v2 4 GB ram 50 GB disco Se carga la iso del disco local de Proxmox Can you help us move forward? Kind regards, -- Elisa Peirano *Analista de Datos I+D* R&D Data Analyst /www.lacnic.net <http://www.lacnic.net> Latin American and Caribbean Internet Addresses Registry/

2 2

Re: Ask for credits for my experiment.
by Departamento de Conectividad | Adam 07 Jan '25

07 Jan '25

Hi, Here comes 100 million from Adam. Enjoy them! Greetings. Ferran Pons • Departamento de NOC <Tel:+34> Tel:+34 934 465 000 / +34 911 161 770 email: <mailto:ferran.pons@adam.es> ferran.pons(a)adam.es <http://www.adam.es/> www.adam.es <https://www.linkedin.com/company/adam-tic> <https://twitter.com/adam_tic> <https://adam.es/conectividad/interconexion> <https://adam.es/politica-privacidad> Aviso Legal / Protección de datos No imprimas si no es necesario. Protejamos el Medio Ambiente. On Tue, 7 Jan 2025 at 14:26, YUNPENG XING < <mailto:xingyunp123@gmail.com> xingyunp123(a)gmail.com> wrote: Hello everyone! I hope this message finds you well. My name is Yunpeng Xing, and I am a master's student at Tsinghua University in China. I am currently working on an experiment to test the performance of global DNS Anycast using RIPE Atlas. However, I do not currently have any credits for this purpose. I would greatly appreciate it if you could kindly provide me with some credits to facilitate my research. Please let me know if you need any further information. Thank you for your time and consideration. Best regards, Yunpeng Xing ----- 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/

1 0

Ask for credits for my experiment.
by YUNPENG XING 07 Jan '25

07 Jan '25

Hello everyone! I hope this message finds you well. My name is Yunpeng Xing, and I am a master's student at Tsinghua University in China. I am currently working on an experiment to test the performance of global DNS Anycast using RIPE Atlas. However, I do not currently have any credits for this purpose. I would greatly appreciate it if you could kindly provide me with some credits to facilitate my research. Please let me know if you need any further information. Thank you for your time and consideration. Best regards, Yunpeng Xing

4 3

Probe on ctr-dub-hw01 disconnected
by Ernst J. Oud 25 Dec '24

25 Dec '24

Hi, My probe 55795 disconnected from ctr-dub-hw01. Could it be that this controller has an issue? My other probes on other controllers are fine. Regards, Ernst J. Oud

2 4

Conflicting tags for resolver
by RIPE 22 Dec '24

22 Dec '24

Hi, I just noticed my probe (1008458) shows a strange status: System Resolves A or AAAA Records Incorrectly But looking at the tags I see both the resolves correctly and the resolves incorrectly tags are set for both A and AAAA. That looks like a strange combination of tags. Any idea what’s causing this ? Cheers, Paul

1 0

cannot forward src on fbsd
by Sulev-Madis Silber 21 Dec '24

21 Dec '24

i have fbsd box with pf that routes my traffic i get this endlessly: cannot forward src fe80:24::4e6d:580f:fc89:81ae, dst 2001:7d0:8437:13bf:da58:d7ff:fe 03:1274, nxt 58, rcvif vlan3, outif vlan91 cannot forward src fe80:24::4e6d:580f:fc89:81ae, dst 2001:7d0:8437:13bf:da58:d7ff:fe 03:1274, nxt 58, rcvif vlan3, outif vlan91 cannot forward src fe80:24::4e6d:580f:fc89:81ae, dst 2001:7d0:8437:13bf:da58:d7ff:fe 03:1274, nxt 58, rcvif vlan3, outif vlan91 sometimes androids do this a few times, but probes do it all the time. multiple hw ver probes. for a decade i get few obscure results when i look that up but don't know what this is or why i tried to sniff and iirc i found weird icmp ttl exceeded packets i think kernel is correct on that cannot forward part. i'm unsure what measurements my probes actually run the src is apparently some linklocal, dst is my probe v6, recv if is vlan3, this is my v4/v6 wan to isp, out is vlan91, this is dedivated v5 probe vlan in local network did i misconfigure something or isp or ripe or else or? does it affect measurements? i'm not sure what this issue is. i think you can't forward that traffic indeed, from ll ip to global ip? google doesn't help to even shed some light on this weird behaviour, let alone any fix doesn't bother me, just curious i'm not surprised, as this device sends and receives traffic i don't have any control of. and is specifically ip measuring device so, unsure... about all this!

1 0

Requested and participating probes
by Huseyn Gambarov 13 Dec '24

13 Dec '24

Hello. I am currently working on a project that heavily relies on Ripe Atlas Ping measurements. During the development, I noticed that sometimes when, let’s say, I request 3 probes, only 2 are participating in the measurement. In the Ripe Archive, I found that there was a similar discussion here - https://mailman.ripe.net/archives/list/ripe-atlas@ripe.net/thread/D6QZS4WC5… I have two questions, that I could not find answers to, and I would be very grateful if you could help me with them. First, in the mentioned discussion it is said that there are multiple reasons why fewer probes are participating and there is ongoing work to allow users to obtain information about specific conditions that occurred during the measurement creation. Can you tell, if there is a way to get that information via API? Second, do you know if there is a reasonable timeout to wait before a new attempt to reschedule the probe that failed to participate in the first measurement? Thank you for your help. With regards, Huseyn Gambarov.

2 1