[atlas] Measuring reachability query

Hi,


I took the liberty of setting up a couple of measurements using 6 of the 
probes you used, but with a starting hop of '1' so I could see the paths 
taken.


TCP: https://atlas.ripe.net/measurements/28919237/#probes

ICMP: https://atlas.ripe.net/measurements/28919338/#probes


None of the probes receive a response over ICMP (this is not uncommon), 
and five of the probes receive a response over TCP. Be aware that the UI 
will report the RTT for the last responsive hop in either case, *whether 
it's the target or not*. The actual result data reveals a more.


In the case of probe 17832, it doesn't reach the target in either case 
above; the low RTT is the last responsive hop very close to the probe.


17875 and 27091 take more reasonable paths over ICMP to the target, but 
over TCP appear to receive a response from the target at the second hop. 
In terms of what's handling that traffic, I don't know, but with 
latencies so low it's not very far upstream at all.


S.




On 27/01/2021 14:41, Hank Nussbacher wrote:
>
> I found this presentation:
> https://www.ripe.net/support/training/ripe-ncc-educa/presentations/measuring-reachability-of-your-web-server-using-ripe-atlas.pdf
>
> I ran a test from 40 Israeli probes to see if there are any issues 
> accessing zoom.us:
> https://atlas.ripe.net/measurements/28912347/#probes [1st run]
> https://atlas.ripe.net/measurements/28912916/#probes [2nd run]
>
>
> It shows all in Israel getting to Zoom.us with an average of 150ms.
> But 3 sites –  show under 1ms response time – as if they run some 
> local proxy.   I checked with them and they said they have nothing local.
>
> So how come probe 17832 gets .869ms and probe 17875 gets .610ms and 
> probe 27091 gets .718ms to zoom.us?
>
>
> Thanks,
>
> Hank
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ripe.net/ripe/mail/archives/ripe-atlas/attachments/20210127/0cb53176/attachment.html>