- ripe-atlas - mailman.ripe.net

New on RIPE Labs: Internet Tools BoF Discovers Common Challenges for Network Operators
by Michela Galante 09 Jul '19

09 Jul '19

Dear colleagues, Here is a great summary provided by Sofia Silva Berenguer (APNIC) of the outcomes of the Internet Tools BoF organised at the recent LACNIC 31 meeting: https://labs.ripe.net/Members/sofia_silva_berenguer/internet-tools-bof-disc… Kind regards, Michela Galante RIPE NCC

1 0

DNS RTT over TCP: twice as long than UDP?
by Giovane Moura 05 Jul '19

05 Jul '19

Folks, This page at Atlas provides a great visualization on the RTT of DNS queries over TCP/UDP to the Root DNS servers: https://atlas.ripe.net/results/maps/root-server-performance/ We can see that the RTT of TCP queries is at least twice as long than UDP ones (which, according to the page " TCP is expected to be 2-3 times " longer. I cannot replicate these results in my setup, even in large scale from various vantage points: I always get very similar results for either TCP or UDP. Example: UDP: * $ dig example.nl @ns1.dns.nl Query time: 8 msec TCP: * $dig +tcp example.nl @ns1.dns.nl Query time: 9 msec I think there might be something with the definition of RTT. My hypothesis is that the field *rtt* on DNS queries on Atlas[1], for TCP, is, in fact, measuring 2 RTTs: the RTT of the TCP handshake, and the RTT of query/response itself. By definition, however, RTT is "the length of time it takes for a signal to be sent plus the length of time it takes for an acknowledgement of that signal to be received."[2]. So if DNS TCP measurements starts measuring from the SYN packet, that', in fact, be two RTTs. Is this the case with Atlas? I know it may sound a bit like nitpicking, but I just want to be sure of what's exactly being measured. thanks a lot, /giovane [1] https://atlas.ripe.net/docs/data_struct/#v4750_dns [2] https://en.wikipedia.org/wiki/Round-trip_delay_time

3 2

Atlas problems this morning?
by Stephane Bortzmeyer 01 Jul '19

01 Jul '19

#22170557, #22171022 and #22171068 terminate but no results are available. Is there some problem going on?

2 1

Search for Probe
by Sascha Groetzner 01 Jul '19

01 Jul '19

Hello, I would like to take part at the ripe atlas grip. I applied already for a probe and still waiting for delivery since a long time. Does anyone have a probe which isn`t in use or would like to transfer? best regards Sascha Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

2 1

Streaming API Losses
by Marcel Flores 28 Jun '19

28 Jun '19

Hi all, We've been exploring the use of the Streaming API to collect result stream data for a set of user defined measurements, in particular using the interface available in Cousteau. However, we've found that the Streaming API seems to be "lossy", with only a fraction of the results reported through the usual system making their way into the stream. I've not been able to find any sort of pattern on what does and doesn't make it through. Does anyone else have experience with this? Are there known limitations with the Streaming API? If so, has anyone worked out any clever workflows to accommodate? Thanks very much! -- *Marcel Flores, PhD* | Sr. Research Scientist research.verizondigitalmedia.com | AS15133 <https://www.peeringdb.com/asn/15133> p: +1 310.593.6880 e: marcel.flores(a)verizondigitalmedia.com 13031 W Jefferson Blvd. Building 900, Los Angeles, CA 90094

1 0

Filter for all results of a probe within a given timeintervall
by Lars Prehn 28 Jun '19

28 Jun '19

Hi everyone, I'm currently trying to retrieve ping and/or traceroute results for a specific probe in a given time interval via cousteau and/or the measurement API directly. It seems like I'm not clever enough to get it done. Is there a possibility to achieve this goal without iterating over each and every measurement to check whether or not the probes and the time match? Best regards, Lars

1 0

raspbian.net/raspbian.org ipv6 peering problems
by Thomas Schäfer 25 Jun '19

25 Jun '19

Hello, I am not sure if I am right here with my question. Does someone measurements to the server of "raspbian"? Their hoster (bytemark, iomart, zayo?) seems not to be able to establish correct peerings. At least the peering to AS3320 is broken. I already contacted 3320. They say zayo doesn't fulfill the minimum security requirements. Are more peerings broken? Regards, Thomas

4 5

When to consider a measurement finished
by Wouter de Vries 25 Jun '19

25 Jun '19

Hi all, I am currently trying to do some measurements according to the following steps: 1. create a one-off measurement 2. wait for it to finish, by periodically polling the msmid and checking the status. 3. fetch the results However, the system takes a pretty long time to set the status to finished, even when all results are already in (maybe 10 minutes?). What heuristics/method do you recommend to determine whether to consider a measurement as finished? One option I consider is to periodically fetch all results for a given msmid and checking if the number of results matches the number of probes assigned to the measurement. However, I suspect that causes a much higher load on the infrastructure. Best regards, Wouter de Vries

3 2

Probe off-line for 6 days due to bad firmware signature
by Novak Jirka 25 Jun '19

25 Jun '19

Hello, my probe 22424 is off-line due to bad firmware signature error. I try to boot it without USB stick many times, then i change the USB stick (replace the old one with new one), but it doesnt solve my problem. Could you help me? This is the information from my status page: Bad Firmware Signature What does this mean? The probe's firmware signature is wrong. How can I fix this? Power-cycle the probe and wait for a couple of hours. If probe doesn't come online you should try to reinitialise or even replace your flash drive. Please use the following procedure: 1. Unplug the probe from its power source 2. Remove the USB stick from the probe 3. Plug in the probe WITHOUT the USB stick 4. Wait for ten minutes 5. Insert the USB stick If it didn't help repeat these steps using another working USB stick that is at least 4GB in size. NOTE: This must be done on a network with working DHCP! It will NOT work if you have configured your probe to use a static IP address, because this mini-operating system does not have access to any statically configure IP addresses or DNS resolvers. If you have configured your probe to use a static IP address, the only thing you can do is move it to a network with working DHCP. When the probe is listed as "connected" again, it is safe to move the probe back to its original location. However, please note that we advise configuring your probe to use a static IP address only if you feel it is truly necessary to do so. Thx, Jiri

3 5

any clue rtt unreachable packet loss 100% com234.476.249
by kiran.gunana＠colruytgroup.com 25 Jun '19

25 Jun '19

Hello, Can some one help me with the reason behind me always getting RTT unreachable and packet loss 100% for every probe I choose to monitor one our service from internet in belgium. Is there something I am not doing right or can guid me a better way of doing it. Even though there is 100% packet loss , my credit balance is still being consumed. Kiran Gunana Network Engineer kiran.gunana(a)colruytgroup.com T +32 2 363 55 45 (Ext : 55711) Colruyt Group Edingensesteenweg 196 - 1500 Halle www.colruytgroup.com LinkedIn Twitter 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