<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang="en-IT" link="#0563C1" vlink="#954F72" style="word-wrap:break-word;overflow-wrap: break-word;-webkit-nbsp-mode: space;line-break:after-white-space"> <div class="WordSection1"> Hi Michael,<o:p></o:p> thank you very much for the explanation. I made another measure using UDP and now the collected routes make more sense. I was not aware of the 5 hops without response.<o:p></o:p> <o:p> </o:p> Glad we spot out a particular case 😊<o:p></o:p> <o:p> </o:p> Regards,<o:p></o:p> Roberto<o:p></o:p> <o:p> </o:p> <o:p> </o:p> <div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm"> From: Michel Stam <mstam@ripe.net> Date: Wednesday, 8 February 2023 at 14:08 To: roberto.lucignani@caleidos.it <roberto.lucignani@caleidos.it> Cc: Qasim Lone <qlone@ripe.net>, Emile Aben <eaben@ripe.net>, Alexander Burke via ripe-atlas <ripe-atlas@ripe.net> Subject: Re: [atlas] Measurement question<o:p></o:p> </div> Hello Roberto, I’ve done the exact same measurement too, using the 3 types of traceroute available (ICMP, UDP and TCP). UDP: (https://atlas.ripe.net/measurements/49826077/#general) <img width="492" height="603" style="width:5.125in;height:6.2812in" id="_x0000_i1029" src="cid:image001.png@01D93BD2.0F829F90"> TCP: (https://atlas.ripe.net/measurements/49826078/#general) <img width="399" height="231" style="width:4.1562in;height:2.4062in" id="_x0000_i1028" src="cid:image002.png@01D93BD2.0F829F90"> ICMP: (https://atlas.ripe.net/measurements/49826076/#general) <img width="501" height="273" style="width:5.2187in;height:2.8437in" id="_x0000_i1027" src="cid:image003.png@01D93BD2.0F829F90"> The way the traceroute works in Atlas is that if 5 hops have been received without response, the trace skips over to TTL 255 and ends the traceroute. This is what you see with TCP and ICMP. The traceroute stops for lack of response. To prove that, I’ve run the trace again, skipping hops 1-7, for both ICMP and TCP:<o:p></o:p> <div> https://atlas.ripe.net/measurements/49826868/#general <img width="399" height="449" style="width:4.1562in;height:4.677in" id="_x0000_i1026" src="cid:image004.png@01D93BD2.0F829F90"> https://atlas.ripe.net/measurements/49826959/#general <img width="399" height="336" style="width:4.1562in;height:3.5in" id="_x0000_i1025" src="cid:image005.png@01D93BD2.0F829F90"> <o:p></o:p> <div> <ul type="disc"> <li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1"> 100.64.0.0/10 is CGN (Carrier Grade NAT), RFC 6598.<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1"> Looking at the traceroute differently:<o:p></o:p></li></ul> <ul type="disc"> <ul type="circle"> <li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level2 lfo1"> Hop 1 (AS16509, Amazon EU West, Amazon-02)<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level2 lfo1"> Hop 2-7 CGN<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level2 lfo1"> Hop 8-9 (AS unknown, but between UK and US, IPROU3-ARIN, so Amazon IP routing 3)<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level2 lfo1"> Hop 10 (AS unknown, but between UK and US, IPROU3-ARIN/ARMP-ARIN, Amazon IP routing)<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level2 lfo1"> Hop 11-15 CGN<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level2 lfo1"> Hop 16 (AS unknown, presumably US, IPROU3-ARIN/ARMP-ARIN, I presume Amazon IP routing still)<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level2 lfo1"> Hop 17-19 CGN<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level2 lfo1"> Hop 20 (AS13335, Cloudflare US)<o:p></o:p></li></ul> </ul> <div> <o:p> </o:p> </div> </div> So it seems like every cloud zone interconnect (amazon Europe west, US, then Cloudflare) transitted goes through a CGN setup. Not sure but I can understand if this confuses some types of traffic. I don’t think there’s anything wrong with your setup, but the results are interesting. I’ve copied a couple of our researchers onto the mail as they may be interested in this as well.<o:p></o:p> </div> <div> <o:p> </o:p> </div> <div> Regards,<o:p></o:p> </div> <div> <o:p> </o:p> </div> <div> Michel <o:p></o:p> <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt"> On 8 Feb 2023, at 11:33, roberto.lucignani@caleidos.it wrote: Hi Michael, for example, one measure ID is this one: 49813750 The result says there are 7 HOPS. The result of the traceroute made directly on the host is the following one traceroute to www.madghigno.tech (172.67.221.209), 30 hops max, 60 byte packets 1 52.56.0.19 24.303 ms 52.56.0.31 9.067 ms 52.56.0.17 29.663 ms 2 * 100.65.18.192 7.843 ms 100.65.19.176 6.252 ms 3 100.66.8.254 1.563 ms 100.66.8.146 0.697 ms 100.66.8.168 1.449 ms 4 100.66.10.138 8.469 ms 100.66.10.14 5.713 ms 100.66.10.6 8.127 ms 5 100.66.7.77 1.653 ms 100.66.6.173 2.658 ms * 6 100.66.4.75 2.726 ms 100.66.4.87 2.327 ms 100.66.4.89 1.550 ms 7 100.65.10.65 0.533 ms 100.65.11.1 0.857 ms 100.65.10.161 8.616 ms 8 15.230.158.29 2.062 ms 15.230.158.171 5.998 ms 15.230.158.27 1.617 ms 9 15.230.158.164 1.315 ms 52.94.33.120 2.089 ms 15.230.158.40 1.484 ms 10 54.239.101.83 1.440 ms 150.222.65.23 1.358 ms 54.239.101.87 1.897 ms 11 100.91.211.7 1.368 ms 100.91.13.66 1.956 ms 100.91.13.100 5.077 ms 12 100.91.210.16 1.837 ms 100.100.6.119 1.848 ms 52.93.134.81 2.178 ms 13 100.100.73.70 2.434 ms 100.91.203.106 4.546 ms 100.100.85.70 1.139 ms 14 100.91.207.15 1.289 ms * 100.100.72.67 1.767 ms 15 100.100.2.76 3.616 ms 100.91.201.140 1.955 ms 100.91.205.18 1.744 ms 16 99.83.89.19 6.820 ms 100.91.201.1 2.454 ms 100.91.201.97 2.415 ms 17 100.91.211.89 17.823 ms 172.71.176.2 3.200 ms 172.70.160.2 4.450 ms 18 100.100.6.77 1.805 ms 100.100.6.3 1.943 ms 100.100.6.111 2.005 ms 19 100.100.80.70 1.980 ms 100.100.76.134 2.679 ms 100.100.69.134 2.081 ms 20 172.67.221.209 2.799 ms 100.100.89.209 7.318 ms 100.100.89.17 6.869 ms Since the website is served by cloudflare the route may vary between requests but the are always around 18/20 HOPS I don’t understand if I0m missing something here. Let me know if you need further details Regards, Roberto From: Michel Stam <mstam@ripe.net> Date: Wednesday, 8 February 2023 at 10:13 To: roberto.lucignani@caleidos.it <roberto.lucignani@caleidos.it> Subject: Re: [atlas] Measurement question Hello Roberto, Would you be able to share screenshots/measurement ids so we can have a look? Regards, Michel On 8 Feb 2023, at 09:04, roberto.lucignani@caleidos.it wrote: I’m doing some measurement from one of my software probes, the measure is a traceroute to a destination. The results I get are completely different from what I see doing the same traceroute directly on host where the probe is installed. I configured the measure to sue the DNS resolution on the probe.. From the Atlas portal I get a traceroute with 7 hops, doing it directly on the host returns 28 hops, for the same destination. Why this difference ? Regards, Roberto -- Mail sent with Outlook for Mac This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this message by mistake and delete this message from your system. E-mail transmission cannot be guaranteed to be secure or error-free, because information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message that arise as a result of e-mail transmission. -- ripe-atlas mailing list ripe-atlas@ripe.net https://mailman.ripe.net/<o:p></o:p> </blockquote> <o:p> </o:p> </div> </div> </body> </html>