On Mon, 13 Jan 2025 at 21:20, Lukas Tribus lukas@ltri.eu wrote:

Here some RIPE atlas traceroutes from Switzerland: https://atlas.ripe.net/measurements/86069388/overview

Most of those Cloudfront destinations appear to drop UDP based traceroutes, that's why the first measurement was not that useful.

Here's a new measurement with TCP based traceroutes:

https://atlas.ripe.net/measurements/86069474/

44 probes from Sunrise, 58 probes from Init7, it all looks good.

Lukas

Thanks for the replies, everyone. I was using Quad9 (149.112.112.112). I've read that they have had some issues today. Might be related or not. Either way, thank you for the hint @Fredy

Freundliche Grüsse | Kind regards

Rafael Pfister Senior System Engineer T +41 58 059 43 68tel:+41%2058%20059%2043%2068 mailto:Rafael.Pfister@aveniq.ch

________________________________ Von: Fredy Künzler via swinog swinog@lists.swinog.ch Gesendet: Monday, January 13, 2025 11:35:04 PM An: swinog@lists.swinog.ch swinog@lists.swinog.ch Betreff: [swinog] Re: Peering issues?

Ping works for me (Init7). Seems to be resolved, though I can't check the routing via Sunrise - Cogent. Our traceroute tool is here: https://che01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.as1303...https://www.as13030.net/traceroute.php

I don't consider this a peering issue, as neither Sunrise nor Init7 peers with California based Amazon infrastructure. There are different transit providers in between, and as both options are showing the same result I suppose it was an Amazon problem.

But - question: Why is 20min.ch (Cloudfront client, apparently) resolving to an address which is physically in California? That seems a rather inefficient routing / CDN mapping. I suggest to change your resolver to something more decent which resolves 20min.ch to a Switzerland based Cloudfront cache. It's not uncommon that CDN mapping breaks when using 8.8.8.8 and alike instead of the providers DNS resolver.

-- Fredy Künzler

Init7 (Switzerland) Ltd. Technoparkstrasse 5 CH-8406 Winterthur https://che01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.init7....https://www.init7.net/

On 13.01.25 20:31, Rafael Pfister AVENIQ via swinog wrote:

Hey everyone

Starting from today at 19:30, Sunrise seems to be experiencing issues connecting to Cloudfront/AWS services. Can someone from Sunrise investigate? Has anyone else noticed slow response times?

RESOLVED 20min.ch TO 108.139.10.50 STARTED QUERY AT 2025/01/13 19:20:59 UTC Fetching Measurement: 86068412 Traceroute from 172.17.0.2 to 108.139.10.50 (108.139.10.50): 1 172.17.0.1 0.075ms 0.056ms 0.095ms 2 192.168.1.1 0.456ms * 0.564ms 3 xdsl-188-154-10-1.adslplus.ch (188.154.10.1) 2.368ms 1.901ms 3.253ms 4 zur05pe01.eth- trunk41.bb.sunrise.net (195.141.217.14) 2.461ms 2.803ms 9.844ms 5 oer02lsr01.100ge-9-0-1.bb.sunrise.net (195.141.215.136) 2.627ms 5.823ms 1.903ms 6 be2395.ccr52.zrh02.atlas.cogentco.com (130.117.50.25) 8.263ms 8.217ms 9.805ms 7 be3073.ccr22.muc03.atlas.cogentco.com (130.117.0.62) 17.955ms 18.746ms 20.905ms 8 be7944.ccr42.fra05.atlas.cogentco.com (154.54.75.98) 16.912ms 17.089ms 16.851ms 9 be2950.ccr42.ams03.atlas.cogentco.com (154.54.72.41) 24.289ms 24.86ms 23.311ms 10 be2183.ccr22.lpl01.atlas.cogentco.com (154.54.58.69) 134.45ms 164.259ms 134.418ms 11 be3043.ccr22.ymq01.atlas.cogentco.com (154.54.44.166) 138.134ms 133.711ms 138.456ms 12 be3260.ccr32.yyz02.atlas.cogentco.com (154.54.42.89) 135.28ms 133.366ms 137.568ms 13 be2994.ccr22.cle04.atlas.cogentco.com (154.54.31.233) 134.227ms 134.991ms 140.254ms 14 be2718.ccr42.ord01.atlas.cogentco.com (154.54.7.129) 134.623ms 134.97ms 133.9ms 15 be5068.ccr32.oma02.atlas.cogentco.com (154.54.166.73) 145.19ms 141.644ms 145.105ms 16 be4995.ccr22.den01.atlas.cogentco.com (154.54.165.213) 154.102ms 156.75ms 152.903ms 17 be5456.ccr32.slc01.atlas.cogentco.com (154.54.45.166) 174.593ms 177.368ms 176.57ms 18 be3110.ccr22.sfo01.atlas.cogentco.com (154.54.44.141) 241.622ms 176.059ms 174.992ms 19 be3670.ccr41.sjc03.atlas.cogentco.com (154.54.43.14) 175.015ms 176.262ms 174.053ms 20 38.142.246.130 200.991ms 199.207ms 176.41ms 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 255 server-108-139-10-50.sfo5.r.cloudfront.net (108.139.10.50) 177.981ms 175.763ms 174.853ms

Init7 seemed to have the same issues:

RESOLVED 20min.ch TO 108.139.10.16 STARTED QUERY AT 2025/01/13 19:25:18 UTC Fetching Measurement: 86068442 Traceroute from 192.168.20.206 to 108.139.10.16 (108.139.10.16): 1 192.168.20.254 0.644ms 0.142ms 0.129ms 2 85-195-253-129.fiber7.init7.net (85.195.253.129) 0.366ms 0.344ms 0.363ms 3 r1stg7.core.init7.net (141.195.83.16) 1.408ms 1.189ms 1.178ms 4 r1stg2.core.init7.net (141.195.82.186) 2.125ms 1.238ms 1.266ms 5 r1wil2.core.init7.net (141.195.83.130) 1.572ms 1.5ms 1.954ms 6 r1win11.core.init7.net (5.180.135.88) 2.123ms 2.031ms 1.977ms 7 r1win12.core.init7.net (5.180.135.87) 2.282ms 2.274ms 2.127ms 8 r1zrh11.core.init7.net (5.180.135.34) 2.63ms 2.533ms 2.342ms 9 5-180-134-166.init7.net (5.180.134.166) 3.114ms 3.047ms 3.028ms 10 r2zrh2.core.init7.net (5.180.135.156) 2.948ms 2.929ms 2.892ms 11 80.157.206.137 3.255ms 2.971ms 2.968ms 12 pao-sb3-i.PAO.US.NET.DTAG.DE (62.154.5.242) 153.927ms 153.928ms 153.934ms 13 80.157.200.202 154.046ms 171.753ms 176.436ms 14 52.93.141.167 154.049ms 153.991ms 154.115ms 15 54.240.243.159 154.763ms 154.914ms 154.643ms 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 255 server-108-139-10-16.sfo5.r.cloudfront.net (108.139.10.16) 154.221ms 154.225ms 154.22ms

Best wishes

Rafael Pfister Aveniq AG Brown Boveri Strasse 7 | 5400 Baden Rafael.Pfister@aveniq.ch mailto:Rafael.Pfister@aveniq.ch| aveniq.ch <https://che01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.aveniq....http://www.aveniq.ch/>

---

swinog mailing list -- swinog@lists.swinog.ch To unsubscribe send an email to swinog-leave@lists.swinog.ch

_______________________________________________ swinog mailing list -- swinog@lists.swinog.ch To unsubscribe send an email to swinog-leave@lists.swinog.ch

On 13/01/2025 23:35, Fredy Künzler via swinog wrote:

Ping works for me (Init7). Seems to be resolved, though I can't check the routing via Sunrise - Cogent. Our traceroute tool is here: https://www.as13030.net/traceroute.php

I don't consider this a peering issue, as neither Sunrise nor Init7 peers with California based Amazon infrastructure. There are different transit providers in between, and as both options are showing the same result I suppose it was an Amazon problem.

But - question: Why is 20min.ch (Cloudfront client, apparently) resolving to an address which is physically in California? That seems a rather inefficient routing / CDN mapping. I suggest to change your resolver to something more decent which resolves 20min.ch to a Switzerland based Cloudfront cache. It's not uncommon that CDN mapping breaks when using 8.8.8.8 and alike instead of the providers DNS resolver.

Quad9 has multiple flavours of DNS and one of them has "EDNS Client-Subnet" enabled, but it's not the default one. So for anyone who cares enough to use Quad9 but still wants to benefit from local CDNs, it would be 9.9.9.11 instead of 9.9.9.9 (ref. https://www.quad9.net/support/faq/#edns).

I assume any other mainstream non-ISP DNS provider also offers this distinction.

Cheers!