IPv6 Routing probleme zu Microsoft Azure

Hallo ​@almightyloaf,

bitte entschuldige die späte Rückmeldung!

Ich kenne mich leider nicht so gut aus, und kann hier leider auch nur mutmaßen. Schade, dass dir unsere Mitarbeiter von der Störungshotline nicht weiterhelfen konnten. 

Die Adresse wird ja offenbar richtig erkannt und ein klassisches Routing-Problem scheint es nicht zu sein, oder? Allerdings gehen hier wohl größere Pakete verloren oder werden verworfen oder es gibt hier Lücken, das sollte nicht so sein. 

Toll wäre es, wenn du uns ein Traceroute erstellen könntest, das wir dann ggf. weiterleiten können. 

Viele Grüße

Giulia

Hi ​@o2_Giulia,

kein Thema, ich weiss dass viel los ist und dass ihr primär zum Moderieren da seit :) (und das Problem habe ich ja seit (mutmasslich) 2 Jahre, also ein paar Wochen mehr oder weniger macht auch nicht viel)

Ich kenne mich leider nicht so gut aus, und kann hier leider auch nur mutmaßen. Schade, dass dir unsere Mitarbeiter von der Störungshotline nicht weiterhelfen konnten.

Auch das ist nicht wild, mir ist schon bewusst dass die Störungsart jetzt nicht besonders leicht zu vermitteln ist und nicht zu den üblichen zählt. Alles können muss man auch nicht, sonst kann man nichts richtig.

Wobei ein Freitextfeld für solche komische Meldungen sicherlich nicht verkehrt wäre.

Die Adresse wird ja offenbar richtig erkannt und ein klassisches Routing-Problem scheint es nicht zu sein, oder?

Das wäre eher DNS, also Namensauflösung (z.B. www.michelin.de → 2603:1061:14:137::1). Routing wäre dann eben nachgelagert, also wenn mein Client (den PC) dann zu dieser IP(v6) Adresse bzw. den Server den diese Adresse hat kommunizieren möchte. Ich habe auch www.pitstop.de als weiteren Ziel entdeckt der auch betroffen ist (und auch bei Microsoft Azure gehosted zu sein scheint).

Allerdings gehen hier wohl größere Pakete verloren oder werden verworfen oder es gibt hier Lücken, das sollte nicht so sein.

Genau. Ob es jetzt nur Pakete einer bestimmten Grösse betrifft oder was genau passiert ist mir jetzt nicht klar, ich habe das auch nicht so genau getestet (wollte ich ursprünglich, aber diesen Schritt habe ich nun erstmal geskippt zugunsten einen rohen Output mit TCPdump und cURL, den ich im Eingangspost im Spoiler versteckt hatte zur Übersichtlichkeit).

Das Thema mit den fragmentierten Pakete lässt sich leider nicht mehr so einfach testen, da wohl die Webseite die den Test ermöglichte nun offline ist, so muss ich zuerst eine neue Testmethode finden, bevor ich hier meckern kann :) (aber der Fachbereich darf trotzdem natürlich auch ohne mein “Meckern” im dazugehörigen Thema darüber schauen)

Toll wäre es, wenn du uns ein Traceroute erstellen könntest, das wir dann ggf. weiterleiten können.

Selbstverständlich, da hätte ich eigentlich auch selbst dran denken sollen, statt nur TCPdump und cURL. Macht auch Sinn. Das witzige ist ja, man sieht im TCPdump dass die Kommunikation zumindest beginnt, aber irgendwie dann nur beginnt und nicht endet und nicht (genügend) Daten transmittiert werden damit die genannten Webseiten (und weitere Dienste, OSI Schichtenmodell ist hier einen guten Punkt zu Verständnis falls das Thema dich interessiert). Ich vermute auch dass es bei dem Thema (daher hatte ich das auch als Test vorgeschlagen, auch wenn es nicht dazu kam und nun wohl über Teredo IPv6 verwendet wird so wie ich das interpretiere) die selbe Problematik gibt:

Nun, lange Rede kurzer Sinn, anbei ein paar Traceroutes zu den Webseiten die betroffen sind (Microsoft Store Server IP und so könnte ich auch noch versuchen rauszufischen, aber ich denke das muss jetzt nicht unbedingt sein :D )

www.michelin.de

C:\Users\AnonUser>tracert www.michelin.de

Détermination de l’itinéraire vers mr-a03.tm-azurefd.net [2603:1061:14:135::1]
avec un maximum de 30 sauts :

  1    <1 ms    <1 ms    <1 ms  dynamic-2a02-3100-6547-c207-021e-c9ff-feb8-e7a9.310.pool.telefonica.de [2a02:3100:6547:c207:21e:c9ff:feb8:e7a9]
  2     7 ms     6 ms     6 ms  2a02:3001::23c
  3     *        *        *     Timeout.
  4     *        *        *     Timeout.
  5     8 ms    15 ms    28 ms  ae22-0.mil30-96cbe-1a.ntwk.msn.net [2a01:111:2000:2:8000::130e]
  6     *        *        *     Timeout.
  7     *        *        *     Timeout.
  8    13 ms    13 ms    14 ms  2a01:111:2000:6::54bd
  9    12 ms    12 ms    12 ms  2603:10a0:c02:2200::2e
 10    12 ms    12 ms    12 ms  2603:10a0:c02:2105::a6
 11    12 ms    12 ms    12 ms  2603:10a0:c0d:ba::
 12    12 ms    12 ms    12 ms  2603:10a0:c0d:ba::52
 13     *        *        *     Timeout.
 14     *        *        *     Timeout.
 15     *        *        *     Timeout.
 16     *        *        *     Timeout.
 17     *        *        *     Timeout.
 18     *        *        *     Timeout.
 19     *        *        *     Timeout.
 20     *        *        *     Timeout.
 21     *        *        *     Timeout.
 22     *        *        *     Timeout.
 23     *        *        *     Timeout.
 24     *        *        *     Timeout.
 25     *        *        *     Timeout.

login.schwaebisch-hall.de 

C:\Users\AnonUser>tracert login.schwaebisch-hall.de

Détermination de l’itinéraire vers mr-a03.tm-azurefd.net [2603:1061:14:135::1]
avec un maximum de 30 sauts :

  1    <1 ms    <1 ms    <1 ms  dynamic-2a02-3100-6547-c207-021e-c9ff-feb8-e7a9.310.pool.telefonica.de [2a02:3100:6547:c207:21e:c9ff:feb8:e7a9]
  2     6 ms     6 ms     6 ms  2a02:3001::23c
  3     *        *        *     Timeout.
  4     *        *        *     Timeout.
  5    10 ms    55 ms     7 ms  ae22-0.mil30-96cbe-1a.ntwk.msn.net [2a01:111:2000:2:8000::130e]
  6     *        *        *     Timeout.
  7     *        *        *     Timeout.
  8    14 ms    13 ms    14 ms  2a01:111:2000:6::54bd
  9    12 ms    12 ms    12 ms  2603:10a0:c02:2200::2e
 10    12 ms    12 ms    12 ms  2603:10a0:c02:2105::a6
 11    12 ms    16 ms    12 ms  2603:10a0:c0d:ba::
 12    12 ms    12 ms    12 ms  2603:10a0:c0d:ba::52
 13     *        *        *     Timeout.
 14     *        *        *     Timeout.
 15     *        *        *     Timeout.
 16     *        *        *     Timeout.
 17     *        *        *     Timeout.
 18     *        *        *     Timeout.
 19     *        *        *     Timeout.
 20     *        *        *     Timeout.
 21     *        *        *     Timeout.
 22     *        *        *     Timeout.
 23     *        *        *     Timeout.
 24     *        *        *     Timeout.
 25     *        *        *     Timeout.

amundiprodcdn2.azureedge.net (liefert den Content der Webseite www.amundietf.de)

C:\Users\AnonUser>tracert amundiprodcdn2.azureedge.net

Détermination de l’itinéraire vers mr-afd-azuredge.tm-azurefd.net [2603:1061:14:133::1]
avec un maximum de 30 sauts :

  1    <1 ms    <1 ms    <1 ms  dynamic-2a02-3100-6547-c207-021e-c9ff-feb8-e7a9.310.pool.telefonica.de [2a02:3100:6547:c207:21e:c9ff:feb8:e7a9]
  2     6 ms     7 ms     7 ms  2a02:3001::23c
  3     *        *        *     Timeout.
  4     *        *        *     Timeout.
  5     7 ms     7 ms     7 ms  ae22-0.mil30-96cbe-1a.ntwk.msn.net [2a01:111:2000:2:8000::130e]
  6    26 ms    26 ms    26 ms  ae123-0.icr02.ams21.ntwk.msn.net [2603:1060:1:12::f231]
  7    26 ms    26 ms    26 ms  2603:1060:1:10::f7e1
  8    26 ms    26 ms    27 ms  po12.yto20-0100-0001-01sw.ntwk.msn.net [2a01:111:201:f200::8da]
  9    27 ms    26 ms    26 ms  po8.dub08-0100-0002-01sw.ntwk.msn.net [2a01:111:201:f200::be]
 10    27 ms    26 ms    27 ms  2a01:111:201:f200::1d41
 11    26 ms    26 ms    26 ms  2a01:111:2000:6::4671
 12    25 ms    25 ms    25 ms  2a01:111:2000:2:8000::291d
 13    25 ms    25 ms    25 ms  2a01:111:223:1cf::6e
 14     *        *        *     Timeout.
 15     *        *        *     Timeout.
 16     *        *        *     Timeout.
 17     *        *        *     Timeout.
 18     *        *        *     Timeout.
 19     *        *        *     Timeout.
 20     *        *        *     Timeout.
 21     *        *        *     Timeout.
 22     *        *        *     Timeout.
 23     *        *        *     Timeout.
 24     *        *        *     Timeout.
 25     *        *        *     Timeout.

www.pitstop.de

C:\Users\AnonUser>tracert www.pitstop.de

Détermination de l’itinéraire vers mr-a03.tm-azurefd.net [2603:1061:14:133::1]
avec un maximum de 30 sauts :

  1    <1 ms    <1 ms    <1 ms  dynamic-2a02-3100-6547-c207-021e-c9ff-feb8-e7a9.310.pool.telefonica.de [2a02:3100:6547:c207:21e:c9ff:feb8:e7a9]
  2     7 ms     7 ms     9 ms  2a02:3001::23c
  3     *        *        *     Timeout.
  4     *        *        *     Timeout.
  5     6 ms     7 ms     7 ms  ae22-0.mil30-96cbe-1a.ntwk.msn.net [2a01:111:2000:2:8000::130e]
  6    26 ms    26 ms    26 ms  ae123-0.icr02.ams21.ntwk.msn.net [2603:1060:1:12::f231]
  7    26 ms    27 ms    27 ms  2603:1060:1:10::f7e1
  8    28 ms    26 ms    26 ms  po12.yto20-0100-0001-01sw.ntwk.msn.net [2a01:111:201:f200::8da]
  9    27 ms    26 ms    26 ms  po8.dub08-0100-0002-01sw.ntwk.msn.net [2a01:111:201:f200::be]
 10    26 ms    26 ms    26 ms  2a01:111:201:f200::1d41
 11    26 ms    26 ms    26 ms  2a01:111:2000:6::4671
 12    25 ms    25 ms    25 ms  2a01:111:2000:2:8000::291d
 13    25 ms    25 ms    25 ms  2a01:111:223:1cf::6e
 14     *        *        *     Timeout.
 15     *        *        *     Timeout.
 16     *        *        *     Timeout.
 17     *        *        *     Timeout.
 18     *        *        *     Timeout.
 19     *        *        *     Timeout.
 20     *        *        *     Timeout.
 21     *        *        *     Timeout.
 22     *        *        *     Timeout.
 23     *        *        *     Timeout.
 24     *        *        *     Timeout.
 25     *        *        *     Timeout.

wcpstatic.microsoft.com (liefert den Content der Webseite learn.microsoft.com)

C:\Users\AnonUser>tracert wcpstatic.microsoft.com

Détermination de l’itinéraire vers mr-azurefd.tm-azurefd.net [2603:1061:14:174::1]
avec un maximum de 30 sauts :

  1    <1 ms    <1 ms    <1 ms  dynamic-2a02-3100-6547-c207-021e-c9ff-feb8-e7a9.310.pool.telefonica.de [2a02:3100:6547:c207:21e:c9ff:feb8:e7a9]
  2     6 ms     7 ms     6 ms  2a02:3001::23c
  3     *        *        *     Timeout.
  4     *        *        *     Timeout.
  5    11 ms    14 ms    10 ms  ae22-0.mil30-96cbe-1a.ntwk.msn.net [2a01:111:2000:2:8000::130e]
  6    15 ms    15 ms    15 ms  ae101-0.icr01.ams30.ntwk.msn.net [2603:1060:1:12::f235]
  7    15 ms     *       15 ms  2603:1060:1:10::f669
  8    15 ms    16 ms    16 ms  2603:1060:1:10::f815
  9    97 ms    15 ms    15 ms  be1.ibr02.par30.ntwk.msn.net [2603:1060:1:10::f00e]
 10    16 ms    19 ms    14 ms  ae120-0.icr01.par30.ntwk.msn.net [2603:1060:1:12::f029]
 11    14 ms    14 ms    14 ms  2603:10a0:700:8100::6
 12    15 ms    14 ms    14 ms  2603:10a0:700:8000::216
 13    14 ms    14 ms    14 ms  2603:10a0:700:8203::1b2
 14    14 ms    15 ms    14 ms  2603:10a0:715:472::
 15    14 ms    14 ms    14 ms  2603:10a0:715:472::2a
 16     *        *        *     Timeout.
 17     *        *        *     Timeout.
 18     *        *        *     Timeout.
 19     *        *        *     Timeout.
 20     *        *        *     Timeout.
 21     *        *        *     Timeout.
 22     *        *        *     Timeout.
 23     *        *        *     Timeout.
 24     *        *        *     Timeout.
 25     *        *        *     Timeout.

Man erkennt auch gut, alle 5 getesteten Ziele haben in deren DNS Namen (und deren IPv6 Adresse) einen Bezug zu Microsoft Azure.

Ah ja, was ich auch getestet habe, ist diese Ziele über Mobilfunk (mit aktivem und funktionalem IPv6, sonst wäre das ja Quatsch) und über einen o2 Cable Anschluss im Bekanntenkreis (natürlich auch mit aktivem und funktionalem IPv6) zu testen, dort funktionierte es problemlos, also eben wie es halt sein sollte.

Zufällig fiel auch ein weiterer Ziel auf, der diesmal keinen (für mich erkennbaren) Bezug auf Microsoft Azure hat.

www.kfz-werkstatt-ernst.de

C:\Users\AnonUser>tracert www.kfz-werkstatt-ernst.de

Détermination de l’itinéraire vers www.kfz-werkstatt-ernst.de [2a02:2350:5:10a:807b:fed1:eb40:6aba]
avec un maximum de 30 sauts :

  1    <1 ms    <1 ms    <1 ms  dynamic-2a02-3100-5dc8-5907-021e-c9ff-feb8-e7a9.310.pool.telefonica.de [2a02:3100:5dc8:5907:21e:c9ff:feb8:e7a9]
  2     6 ms     6 ms     6 ms  2a02:3001::23c
  3     7 ms     *        *     80.81.193.89xp.decix.fra.de.net.telefonica.de [2001:7f8::1a95:0:2]
  4     7 ms     6 ms     6 ms  decix.cr1-fra1.net.one.com [2001:7f8::c90c:0:1]
  5     *        *        *     Timeout.
  6    19 ms    19 ms    19 ms  lo0-1.cr2-cph3.pub.network.one.com [2a02:2350:1::16]
  7    19 ms    19 ms    19 ms  et-0-0-48-200.dr6-cph3.pub.network.g1i.one [2a02:2350:4:72::1]
  8    19 ms    19 ms    19 ms  xe-1-0-47-200.ar1-webpod12-cph3.pub.network.g1i.one [2a02:2350:4:56::1]
  9    19 ms    19 ms    19 ms  2a02:2350:5:10a:807b:fed1:eb40:6aba

curl -v -s https://www.kfz-werkstatt-ernst.de/ -o /dev/null
* Host www.kfz-werkstatt-ernst.de:443 was resolved.
* IPv6: 2a02:2350:5:10a:807b:fed1:eb40:6aba
* IPv4: 46.30.213.47
*   Trying [2a02:2350:5:10a:807b:fed1:eb40:6aba]:443...
* Connected to www.kfz-werkstatt-ernst.de (2a02:2350:5:10a:807b:fed1:eb40:6aba) port 443
* ALPN: curl offers h2,http/1.1
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* Recv failure: Connection reset by peer
* OpenSSL SSL_connect: Connection reset by peer in connection to www.kfz-werkstatt-ernst.de:443
* Closing connection

sudo tcpdump ip6
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp3s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
20:46:14.407899 IP6 dynamic-2a02-3100-IPv6-53b3.310.pool.telefonica.de.59876 > 2a02:2350:5:10a:807b:fed1:eb40:6aba.https: Flags [S], seq 3825016501, win 64800, options [mss 1440,sackOK,TS val 2388477852 ecr 0,nop,wscale 7], length 0
20:46:14.426767 IP6 2a02:2350:5:10a:807b:fed1:eb40:6aba.https > dynamic-2a02-3100-IPv6-53b3.310.pool.telefonica.de.59876: Flags [S.], seq 2916494635, ack 3825016502, win 64260, options [mss 1440,sackOK,TS val 188601682 ecr 2388477852,nop,wscale 7], length 0
20:46:14.426793 IP6 dynamic-2a02-3100-IPv6-53b3.310.pool.telefonica.de.59876 > 2a02:2350:5:10a:807b:fed1:eb40:6aba.https: Flags [.], ack 1, win 507, options [nop,nop,TS val 2388477871 ecr 188601682], length 0
20:46:14.432792 IP6 dynamic-2a02-3100-IPv6-53b3.310.pool.telefonica.de.59876 > 2a02:2350:5:10a:807b:fed1:eb40:6aba.https: Flags [P.], seq 1:518, ack 1, win 507, options [nop,nop,TS val 2388477877 ecr 188601682], length 517
20:46:14.451734 IP6 2a02:2350:5:10a:807b:fed1:eb40:6aba.https > dynamic-2a02-3100-IPv6-53b3.310.pool.telefonica.de.59876: Flags [.], ack 518, win 501, options [nop,nop,TS val 188601706 ecr 2388477877], length 0
20:46:14.454424 IP6 2a02:2350:5:10a:807b:fed1:eb40:6aba.https > dynamic-2a02-3100-IPv6-53b3.310.pool.telefonica.de.59876: Flags [P.], seq 2857:4097, ack 518, win 501, options [nop,nop,TS val 188601709 ecr 2388477877], length 1240
20:46:14.454433 IP6 dynamic-2a02-3100-IPv6-53b3.310.pool.telefonica.de.59876 > 2a02:2350:5:10a:807b:fed1:eb40:6aba.https: Flags [.], ack 1, win 530, options [nop,nop,TS val 2388477899 ecr 188601706,nop,nop,sack 1 {2857:4097}], length 0
20:46:14.454653 IP6 2a02:2350:5:10a:807b:fed1:eb40:6aba.https > dynamic-2a02-3100-IPv6-53b3.310.pool.telefonica.de.59876: Flags [P.], seq 4097:5229, ack 518, win 501, options [nop,nop,TS val 188601709 ecr 2388477877], length 1132
20:46:14.454658 IP6 dynamic-2a02-3100-IPv6-53b3.310.pool.telefonica.de.59876 > 2a02:2350:5:10a:807b:fed1:eb40:6aba.https: Flags [.], ack 1, win 549, options [nop,nop,TS val 2388477899 ecr 188601706,nop,nop,sack 1 {2857:5229}], length 0
20:48:14.801971 IP6 dynamic-2a02-3100-IPv6-53b3.310.pool.telefonica.de.59876 > 2a02:2350:5:10a:807b:fed1:eb40:6aba.https: Flags [.], ack 2916494636, win 571, options [nop,nop,TS val 2388598247 ecr 188601706,nop,nop,sack 1 {2857:5230}], length 0
20:48:14.820940 IP6 2a02:2350:5:10a:807b:fed1:eb40:6aba.https > dynamic-2a02-3100-IPv6-53b3.310.pool.telefonica.de.59876: Flags [R], seq 2916494636, win 0, length 0
^C
^C
11 packets captured
11 packets received by filter
0 packets dropped by kernel

Selbstverständlich gegengeprüft mit anderen Anschlüssen (beinhaltet auch Mobilfunk, mit funktionalem IPv6).

Bei diesem Ziel kann man sehen, dass ICMP durchgeht, ein Echo Request wird (über IPv6) beantwortet (ICMP ist aber nur bedingt aussagekräftig).

Da es wohl augenscheinlich doch ein wenig weiter geht als “nur” Microsoft Azure, habe ich die Befürchtung dass ich nun eventuell nicht alle Probleme dieser Art im Zusammenhang mit IPv6 erfasst habe. Aber eins nach dem anderen. Ggf. ist das problematische Netzelement sowohl für die Einschränkungen bei Azure als auch bei “one.com” (laut ipinfo.io) verantwortlich. Naja und wenn alles funktionieren würde wäre es ja auch langweilig ;) (wobei mir langweilig recht wäre...)

​@almightyloaf Kurzes Update: Wir haben deinen Beitrag weiter auf dem Plan, aktuell ist es aber sehr herausfordernd, für dieses doch sehr ungewöhnliche Fehlerbild an die entsprechenden Kollegen zu kommen (Ferienzeit etc), die ganz tief im Serverkellern nach falsch abgebogenen Datenpakten forschen können. Wir bleiben da weiter am Ball. 

VG Matze 

entsprechenden Kollegen zu kommen (Ferienzeit etc), die ganz tief im Serverkellern

​@o2_Matze hoffentlich tut den Kollegen Sonne gut wenn sie sonst dauerhaft im Keller kein Tageslicht abbekommen. 😆

Hi ​@o2_Matze,

danke für das Update. Kein Ding, die paar wenigen Experten in diesem Bereich den ihr habt sollen sich ausruhen und erstmal ihr Urlaub geniessen. Ihr braucht sie schliesslich fit, ausgeruht und zufrieden (und ein paar mehr Hände und Köpfe täten sicherlich auch nicht schaden ;) ).

Dazu wie gesagt, das Problem besteht im Prinzip (mutmasslich) seit Vertragsbeginn, also die paar Wochen mehr oder weniger machen nicht mehr viel aus. Hauptsache es ist mal eingetütet.

Ich denke mir nur, gut dass es z.B. den MedUX programm gibt, damit auch solche Probleme nicht auffallen (oder auffallen und jahrelang nicht angegangen werden) ;) (Ich habe natürlich darauf geachtet, dass in der VLAN wo dieses Teil sich austobt IPv6 auch funktional bereitliegt)

Moin ​@o2_Matze,

ich fürchte fast, mich beim Titel und in meine ursprüngliche Annahme geirrt zu haben, denn das Problem kann ich auch bei manche AWS Ziele (neben den bereits oben genannten anderen nicht Azure ausreisser) messen...

telekom.de (nicht www.telekom.de, das ist dann der Redirect auf dem korrekten Host www.telekom.de)

tracert 2a05:d014:73f:ec05:c4bd:6cb4:3a9e:327b

Détermination de l’itinéraire vers 2a05:d014:73f:ec05:c4bd:6cb4:3a9e:327b avec un maximum de 30 sauts.

  1    <1 ms    <1 ms    <1 ms  dynamic-2a02-3100-IPv6-eff0.310.pool.telefonica.de [2a02:3100:IPv6:eff0]
  2     6 ms     6 ms     6 ms  2a02:3001::248
  3     *        *        *     Timeout.
  4     6 ms     6 ms     6 ms  2620:107:4000:a554::f000:5c85
  5     6 ms    24 ms    22 ms  2620:107:4000:cfff::f208:8c91
  6     6 ms     6 ms     6 ms  2620:107:4000:a550::f000:5c0f
  7     7 ms     7 ms     6 ms  2620:107:4000:cfff::f201:5fd1
  8     *        *        *     Timeout.
  9     *        *        *     Timeout.
 10     *        *        *     Timeout.
 11     *        *        *     Timeout.
 12     *        *        *     Timeout.
 13     *        *        *     Timeout.
 14     *        *        *     Timeout.
 15     *        *        *     Timeout.
 16     *        *        *     Timeout.
 17     *        *        *     Timeout.
 18     *        *        *     Timeout.
 19     *        *        *     Timeout.
 20     *        *        *     Timeout.

curl -v -s https://telekom.de/ -o /dev/null
* Host telekom.de:443 was resolved.
* IPv6: 2a05:d014:73f:ec05:c4bd:6cb4:3a9e:327b, 2a05:d014:73f:ec03:d255:940:bce5:3d47, 2a05:d014:73f:ec04:23ef:c018:758f:d821
* IPv4: 3.75.123.125, 63.184.16.68, 52.29.103.196
*   Trying [2a05:d014:73f:ec05:c4bd:6cb4:3a9e:327b]:443...
* Connected to telekom.de (2a05:d014:73f:ec05:c4bd:6cb4:3a9e:327b) port 443
* ALPN: curl offers h2,http/1.1
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* Recv failure: Connection reset by peer
* OpenSSL SSL_connect: Connection reset by peer in connection to telekom.de:443
* Closing connection

sudo tcpdump ip6
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp3s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
21:23:23.908708 IP6 dynamic-2a02-3100-IPv6-1ac1.310.pool.telefonica.de.35928 > 2a05:d014:73f:ec05:c4bd:6cb4:3a9e:327b.https: Flags [S], seq 2180533834, win 64800, options [mss 1440,sackOK,TS val 608089287 ecr 0,nop,wscale 7], length 0
21:23:23.914919 IP6 2a05:d014:73f:ec05:c4bd:6cb4:3a9e:327b.https > dynamic-2a02-3100-IPv6-1ac1.310.pool.telefonica.de.35928: Flags [S.], seq 3064500196, ack 2180533835, win 26847, options [mss 1440,sackOK,TS val 4181396097 ecr 608089287,nop,wscale 8], length 0
21:23:23.914943 IP6 dynamic-2a02-3100-IPv6-1ac1.310.pool.telefonica.de.35928 > 2a05:d014:73f:ec05:c4bd:6cb4:3a9e:327b.https: Flags [.], ack 1, win 507, options [nop,nop,TS val 608089293 ecr 4181396097], length 0
21:23:23.934236 IP6 dynamic-2a02-3100-IPv6-1ac1.310.pool.telefonica.de.35928 > 2a05:d014:73f:ec05:c4bd:6cb4:3a9e:327b.https: Flags [P.], seq 1:518, ack 1, win 507, options [nop,nop,TS val 608089312 ecr 4181396097], length 517
21:23:23.940597 IP6 2a05:d014:73f:ec05:c4bd:6cb4:3a9e:327b.https > dynamic-2a02-3100-IPv6-1ac1.310.pool.telefonica.de.35928: Flags [.], ack 518, win 110, options [nop,nop,TS val 4181396123 ecr 608089312], length 0
21:23:23.942293 IP6 2a05:d014:73f:ec05:c4bd:6cb4:3a9e:327b.https > dynamic-2a02-3100-IPv6-1ac1.310.pool.telefonica.de.35928: Flags [P.], seq 2857:3331, ack 518, win 110, options [nop,nop,TS val 4181396125 ecr 608089312], length 474
21:23:23.942309 IP6 dynamic-2a02-3100-IPv6-1ac1.310.pool.telefonica.de.35928 > 2a05:d014:73f:ec05:c4bd:6cb4:3a9e:327b.https: Flags [.], ack 1, win 507, options [nop,nop,TS val 608089320 ecr 4181396123,nop,nop,sack 1 {2857:3331}], length 0
21:24:23.922417 IP6 2a05:d014:73f:ec05:c4bd:6cb4:3a9e:327b.https > dynamic-2a02-3100-IPv6-1ac1.310.pool.telefonica.de.35928: Flags [FP.], seq 3331:3355, ack 518, win 110, options [nop,nop,TS val 4181456105 ecr 608089320], length 24
21:24:23.922440 IP6 dynamic-2a02-3100-IPv6-1ac1.310.pool.telefonica.de.35928 > 2a05:d014:73f:ec05:c4bd:6cb4:3a9e:327b.https: Flags [.], ack 1, win 507, options [nop,nop,TS val 608149301 ecr 4181396123,nop,nop,sack 1 {2857:3356}], length 0
21:25:25.678390 IP6 dynamic-2a02-3100-IPv6-1ac1.310.pool.telefonica.de.35928 > 2a05:d014:73f:ec05:c4bd:6cb4:3a9e:327b.https: Flags [.], ack 3064500197, win 507, options [nop,nop,TS val 608211057 ecr 4181396123,nop,nop,sack 1 {2857:3356}], length 0
21:25:25.684855 IP6 2a05:d014:73f:ec05:c4bd:6cb4:3a9e:327b.https > dynamic-2a02-3100-IPv6-1ac1.310.pool.telefonica.de.35928: Flags [R], seq 3064500197, win 0, length 0
^C
11 packets captured
11 packets received by filter
0 packets dropped by kernel

Hoffentlich lässt sich das klären und vor allem künftig besser vermeiden, das ist ja nicht das erste Mal dass sowas passiert, siehe den ganz oben verlinkten Thema.

Ich bin da ein wenig hin und her gerissen, einerseits ist das schon spassig sich in den Themen reinzufuchsen, auf der anderen Hand, warum muss man es tun? An solche Erlebnisse konnte ich mich bei anderen ISPs nicht erinnern (allerdings auch zu Zeiten, wo IPv6 bei mir noch nicht derart ein Thema war, ist somit auch nur bedingt vergleichbar). Aber was man nicht tut für guten Peering… ;)

Ah ja… und bei golem.de (auch da nicht www.golem.de, ist wohl auch ein Redirect), diesmal aber nur sporadisch (im Prinzip wie beim Cloudflare Thema). Eine vollständige Messnung erspare ich mir diesmal aus Faulheit, ich reiche diese aber bei Bedarf selbstverständlich gerne nach. Auch da sind wir dann weder bei Azure, noch AWS oder One.com, sondern laut ipinfo.io bei SysEleven.

Wie hiess es noch? Je mehr man gräbt, desto mehr findet man? (oder so, wobei mir langweilig bzw. “ich finde nix” auch recht wäre)

user@123-1234567-2 ~ % curl -v -s https://telekom.de/ -o /dev/null

* Host telekom.de:443 was resolved.
* IPv6: 2a05:d014:73f:ec04:23ef:c018:758f:d821, 2a05:d014:73f:ec05:c4bd:6cb4:3a9e:327b, 2a05:d014:73f:ec03:d255:940:bce5:3d47
* IPv4: 3.75.123.125, 52.29.103.196, 63.184.16.68
*   Trying [2a05:d014:73f:ec04:23ef:c018:758f:d821]:443...
* Connected to telekom.de (2a05:d014:73f:ec04:23ef:c018:758f:d821) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
} [315 bytes data]
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* (304) (IN), TLS handshake, Unknown (8):
{ [19 bytes data]
* (304) (IN), TLS handshake, Certificate (11):
{ [2943 bytes data]
* (304) (IN), TLS handshake, CERT verify (15):
{ [110 bytes data]
* (304) (IN), TLS handshake, Finished (20):
{ [36 bytes data]
* (304) (OUT), TLS handshake, Finished (20):
} [36 bytes data]
* SSL connection using TLSv1.3 / AEAD-AES128-GCM-SHA256 / [blank] / UNDEF
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=telekom.de
*  start date: Apr 16 00:00:00 2026 GMT
*  expire date: Oct 30 23:59:59 2026 GMT
*  subjectAltName: host "telekom.de" matched cert's "telekom.de"
*  issuer: C=US; O=Amazon; CN=Amazon ECDSA 384 M04
*  SSL certificate verify ok.
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://telekom.de/
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: telekom.de]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [user-agent: curl/8.7.1]
* [HTTP/2] [1] [accept: */*]
> GET / HTTP/2
> Host: telekom.de
> User-Agent: curl/8.7.1
> Accept: */*
> 
* Request completely sent off
< HTTP/2 301 
< date: Sun, 06 Sep 2026 11:22:21 GMT
< content-length: 23
< location: https://www.telekom.de/
< strict-transport-security: max-age=31536000; includeSubDomains; preload
< 
{ [23 bytes data]
* Connection #0 to host telekom.de left intact

Das sieht bei mir aktuell anders aus…
 

user@router:~# mtr -ezbw -c 100 -6 telekom.de
Start: 2026-09-06T13:25:58+0200
HOST: router                                                                 Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS6805   2a02:3001::208 (2a02:3001::208)                                 0.0%   100    9.2  10.9   9.2  33.2   3.5
  2. AS6805   2a02:3001::167 (2a02:3001::167)                                 0.0%   100    9.1   9.2   8.7  18.5   1.0
  3. AS???    2620:107:4008:8e9::1 (2620:107:4008:8e9::1)                     0.0%   100    9.7   9.8   8.9  28.9   1.9
  4. AS???    2620:107:4000:a552::f000:5c4c (2620:107:4000:a552::f000:5c4c)   0.0%   100   16.3  16.5  15.9  19.0   0.4
  5. AS???    2620:107:4000:cfff::f208:8c91 (2620:107:4000:cfff::f208:8c91)   0.0%   100   16.3  18.8  14.8  42.7   5.4
  6. AS???    2620:107:4000:a550::f000:5c0f (2620:107:4000:a550::f000:5c0f)   0.0%   100   16.1  16.1  15.5  31.5   1.6
  7. AS???    2620:107:4000:cfff::f201:5fd1 (2620:107:4000:cfff::f201:5fd1)   0.0%   100   59.7  25.6  15.8 123.2  20.7
  8. AS???    ???                                                            100.0   100    0.0   0.0   0.0   0.0   0.0

Das sieht bei mir aktuell anders aus…

Jup, bei dir funktioniert es auch sauber, und du kriegst den Inhalt (den HTTP 301 mit dem entsprechenden Redirect Ziel) auch geliefert. Bei mir startet die Verbindung und sie scheint ins Nirvana zu verschwinden bzw. endet mit “Connection Reset by Peer” nach einiger Zeit (laut TCPDump hier 2 Minuten).

Danke für das testen und bestätigen dass es auch funktionieren kann. Zugegeben, bei dir hat cURL eine andere der vielen verfügbaren IPs genommen, aber ich denke nicht dass es in dem Kontext einen nennenswerten Unterschied macht, da bei mir bisher 100% der Verbindungsversuche zu diesem Ziel gescheitert sind.

Lass mich wissen wenn Du andere/zusaetzliche Tests von einen O2@Telekom-VDSL Anschluss brauchen kannst.

Danke für das Angebot, den ich auch gerne annehme :)

Es scheint bei www.netcup.com ebenfalls dieses bzw. ähnliches Phänomen aufzutreten.

tracert  www.netcup.com

Détermination de l’itinéraire vers www.netcup.com [2605:380:52:5:144:208:243:2]
avec un maximum de 30 sauts :

  1    <1 ms    <1 ms    <1 ms  dynamic-2a02-3100-IPv6-ff01.310.pool.telefonica.de [2a02:3100:IPv6:ff01]
  2     7 ms     6 ms     7 ms  2a02:3001::238
  3     *        7 ms     *     80.81.192.89xp.decix.fra.de.net.telefonica.de [2001:7f8::1a95:0:1]
  4     8 ms     6 ms     6 ms  ae3-1337.bbr02.anx25.fra.de.anexia-it.net [2001:7f8::a5e9:0:3]
  5     6 ms     6 ms     6 ms  netcup.com [2605:380:52:5:144:208:243:2]

curl -v -s https://www.netcup.com/ -o /dev/null
* Host www.netcup.com:443 was resolved.
* IPv6: 2605:380:52:5:144:208:243:2
* IPv4: 144.208.243.2
*   Trying [2605:380:52:5:144:208:243:2]:443...
* Connected to www.netcup.com (2605:380:52:5:144:208:243:2) port 443
* ALPN: curl offers h2,http/1.1
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* SSL connection timeout
* Closing connection

sudo tcpdump ip6
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp3s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
11:52:59.285462 IP6 dynamic-2a02-3100-IPv6-e04a.310.pool.telefonica.de.37890 > netcup.com.https: Flags [S], seq 881762581, win 64800, options [mss 1440,sackOK,TS val 1576762955 ecr 0,nop,wscale 7], length 0
11:52:59.292147 IP6 netcup.com.https > dynamic-2a02-3100-IPv6-e04a.310.pool.telefonica.de.37890: Flags [S.], seq 2152178280, ack 881762582, win 65535, options [mss 1440,sackOK,TS val 3496276501 ecr 1576762955,nop,wscale 11], length 0
11:52:59.292175 IP6 dynamic-2a02-3100-IPv6-e04a.310.pool.telefonica.de.37890 > netcup.com.https: Flags [.], ack 1, win 507, options [nop,nop,TS val 1576762962 ecr 3496276501], length 0
11:52:59.298204 IP6 dynamic-2a02-3100-IPv6-e04a.310.pool.telefonica.de.37890 > netcup.com.https: Flags [P.], seq 1:518, ack 1, win 507, options [nop,nop,TS val 1576762968 ecr 3496276501], length 517
11:52:59.306087 IP6 netcup.com.https > dynamic-2a02-3100-IPv6-e04a.310.pool.telefonica.de.37890: Flags [P.], seq 2857:3369, ack 518, win 128, options [nop,nop,TS val 3496276514 ecr 1576762968], length 512
11:52:59.306118 IP6 dynamic-2a02-3100-IPv6-e04a.310.pool.telefonica.de.37890 > netcup.com.https: Flags [.], ack 1, win 507, options [nop,nop,TS val 1576762975 ecr 3496276501,nop,nop,sack 1 {2857:3369}], length 0
11:53:03.720133 IP6 dynamic-2a02-3100-IPv6-e04a.310.pool.telefonica.de.40392 > netcup.com.https: Flags [F.], seq 909693036, ack 2746101441, win 507, options [nop,nop,TS val 1576767390 ecr 1792629185,nop,nop,sack 1 {2857:3369}], length 0
11:53:43.656128 IP6 dynamic-2a02-3100-IPv6-e04a.310.pool.telefonica.de.40392 > netcup.com.https: Flags [F.], seq 0, ack 1, win 507, options [nop,nop,TS val 1576807326 ecr 1792629185,nop,nop,sack 1 {2857:3369}], length 0
11:54:01.064125 IP6 dynamic-2a02-3100-IPv6-e04a.310.pool.telefonica.de.37890 > netcup.com.https: Flags [.], ack 1, win 507, options [nop,nop,TS val 1576824734 ecr 3496276501,nop,nop,sack 1 {2857:3369}], length 0
11:54:01.070686 IP6 netcup.com.https > dynamic-2a02-3100-IPv6-e04a.310.pool.telefonica.de.37890: Flags [.], ack 518, win 128, options [nop,nop,TS val 3496338279 ecr 1576762975], length 0
11:56:03.944128 IP6 dynamic-2a02-3100-IPv6-e04a.310.pool.telefonica.de.37890 > netcup.com.https: Flags [.], ack 1, win 507, options [nop,nop,TS val 1576947614 ecr 3496276501,nop,nop,sack 1 {2857:3369}], length 0
11:57:05.384127 IP6 dynamic-2a02-3100-IPv6-e04a.310.pool.telefonica.de.37890 > netcup.com.https: Flags [.], ack 1, win 507, options [nop,nop,TS val 1577009054 ecr 3496276501,nop,nop,sack 1 {2857:3369}], length 0
11:57:59.790954 IP6 dynamic-2a02-3100-IPv6-e04a.310.pool.telefonica.de.37890 > netcup.com.https: Flags [F.], seq 518, ack 1, win 507, options [nop,nop,TS val 1577063460 ecr 3496276501,nop,nop,sack 1 {2857:3369}], length 0
11:58:00.000123 IP6 dynamic-2a02-3100-IPv6-e04a.310.pool.telefonica.de.37890 > netcup.com.https: Flags [F.], seq 518, ack 1, win 507, options [nop,nop,TS val 1577063670 ecr 3496276501,nop,nop,sack 1 {2857:3369}], length 0
11:58:00.208119 IP6 dynamic-2a02-3100-IPv6-e04a.310.pool.telefonica.de.37890 > netcup.com.https: Flags [F.], seq 518, ack 1, win 507, options [nop,nop,TS val 1577063878 ecr 3496276501,nop,nop,sack 1 {2857:3369}], length 0
11:58:00.624113 IP6 dynamic-2a02-3100-IPv6-e04a.310.pool.telefonica.de.37890 > netcup.com.https: Flags [F.], seq 518, ack 1, win 507, options [nop,nop,TS val 1577064294 ecr 3496276501,nop,nop,sack 1 {2857:3369}], length 0
11:58:01.512116 IP6 dynamic-2a02-3100-IPv6-e04a.310.pool.telefonica.de.37890 > netcup.com.https: Flags [F.], seq 518, ack 1, win 507, options [nop,nop,TS val 1577065182 ecr 3496276501,nop,nop,sack 1 {2857:3369}], length 0
11:58:03.176115 IP6 dynamic-2a02-3100-IPv6-e04a.310.pool.telefonica.de.37890 > netcup.com.https: Flags [F.], seq 518, ack 1, win 507, options [nop,nop,TS val 1577066846 ecr 3496276501,nop,nop,sack 1 {2857:3369}], length 0
11:58:06.504125 IP6 dynamic-2a02-3100-IPv6-e04a.310.pool.telefonica.de.37890 > netcup.com.https: Flags [F.], seq 518, ack 1, win 507, options [nop,nop,TS val 1577070174 ecr 3496276501,nop,nop,sack 1 {2857:3369}], length 0
11:58:13.480138 IP6 dynamic-2a02-3100-IPv6-e04a.310.pool.telefonica.de.37890 > netcup.com.https: Flags [F.], seq 518, ack 1, win 507, options [nop,nop,TS val 1577077150 ecr 3496276501,nop,nop,sack 1 {2857:3369}], length 0
^C
20 packets captured
20 packets received by filter
0 packets dropped by kernel

Auch da, kein Azure, auch kein AWS, kein SysEleven, ich habe mich offensichtlich mit meine ursprüngliche Annahme geirrt. Das Verhalten ist doch nicht bzw. nicht nur auf Azure zurückzuführen.

Die Fehlermeldung ist allerdings mit einem Timeout unterschiedlich als bisher.

Wenn du da Zeit und Lust hast und testen könntest (gleiches gilt auch für die oben genannten Ziele, z.B. www.michelin.de oder www.pitstop.de) wäre das grossartig. Ich habe die Ziele zwar selbst auch gegengetestet (sowohl mit einem anderen ISP, in dem Fall Vodafone als auch an einem o2 Kabelanschluss und früher mit o2 Mobilfunk), jedoch keine Daten aufgenommen wie hier (wäre leider auch nicht so trivial, allerdings m.E. auch nicht erforderlich).

Allerdings überrascht mich auch hier wieder die Lokalität (wie auch bei anderen Themen die bis heute nicht vollständig abgeschlossen sind). Man könnte anhand der Fehlerbilder von einem grösseren Impact ausgehen, aber dem scheint bisher nicht so zu sein (und RIPE Probes in der Umgebung sind zurzeit sehr rar geworden, selbst ohne einen Filter auf AS6805, leider). Spürbar unangenehm ist es trotzdem, wenn man oft IPv6 am Endgerät deaktivieren muss um bestimmte Dienste (z.B. den Microsoft Store zu App-Updates in Windows, oder den Updater von Visual Studio Code, um Beispiele zu nennen die keine Webseiten sind) nutzen zu können…

Hoffentlich (auch wenn ich es denen gönne) sind die Kollegen bald aus dem Urlaub zurück.

Netcup, mtr und curl (ich habe zuviel IPv6 Traffic als dass tcpdump ipv6 lesbar bleibt, ich vermute aber, das ist gar nicht notwendig, lass mich wissen wenn ich das falsch sehe und Du tcpdumps sehen willst (ich kann Dir auch pcap files zukommen lassen)):
 

root@turris:~# mtr -ezbw6 -c 100 www.netcup.de ; echo "CURL:" ; curl -v -s https://www.netcup.com/ -o /dev/null
Start: 2026-09-12T12:16:29+0200
HOST: turris                                                   Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS6805   2a02:3001::20a (2a02:3001::20a)                   0.0%   100    9.4  10.0   8.7  20.4   1.9
  2. AS6805   2a02:30ff:ffff::c0 (2a02:30ff:ffff::c0)           3.0%   100   16.6  16.9  16.3  24.7   0.8
  3. AS???    ???                                              100.0   100    0.0   0.0   0.0   0.0   0.0
  4. AS9002   rt.nbg.nue.de.retn.net (2a02:2d8::57f5:e08c)      0.0%   100   23.8  20.7  18.5  72.3   7.4
  5. AS9002   gw-anexia.retn.net (2a02:2d8:0:4818:232a::1)      0.0%   100   19.4  27.3  18.5  66.4  10.4
  6. AS47147  2a00:11c0:47:1:47::243 (2a00:11c0:47:1:47::243)   0.0%   100   19.8  21.7  18.9  52.1   5.6
  7. AS197540 2a03:4000::e01e (2a03:4000::e01e)                 0.0%   100   18.8  19.8  18.5  51.4   4.1
CURL:
curl -v -s https://www.netcup.de/ -o /dev/null
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
{ [41 bytes data]
* TLSv1.3 (IN), TLS handshake, Certificate (11):
{ [2790 bytes data]
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
{ [264 bytes data]
* TLSv1.3 (IN), TLS handshake, Finished (20):
{ [36 bytes data]
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.3 (OUT), TLS handshake, Finished (20):
} [36 bytes data]
> GET / HTTP/2
> Host: www.netcup.com
> User-Agent: curl/8.20.0
> Accept: */*
> 
} [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [57 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [57 bytes data]
< HTTP/2 302 
< date: Sat, 12 Sep 2026 10:18:16 GMT
< content-type: text/html
< content-length: 89
< x-download-options: noopen
< x-permitted-cross-domain-policies: none
< x-xss-protection: 0
< access-control-allow-origin: *
< set-cookie: i18n_redirect=en; Max-Age=31536000; Path=/; Secure; SameSite=Strict
< location: /en
< x-frame-options: DENY
< age: 0
< set-cookie: __Secure-CDNCID=W0IWo94X3eOTYtjo2ls3g8+r1brZb2soWPx3v79fJ9jyS2dAyRbmn9X51st8lw4nn1gdQ+vhzavzawk3Wt1e4kEMrdxm3wieVxoymVHI3MICQPykS09SkEM1+y0WtCKo; Path=/; Max-Age=86400; Secure; HttpOnly; SameSite=Lax
< x-trace-id: bf5189e5-c8f2-4717-bcaf-568fefac57a6
< strict-transport-security: max-age=31536000
< x-content-type-options: nosniff
< referrer-policy: strict-origin-when-cross-origin
< alt-svc: h3=":443"; ma=600
< 
{ [89 bytes data]

ich vermute aber, das ist gar nicht notwendig

Trifft auch zu. Den Output von cURL reicht aus, bei dir erhälst du auch Inhalt vom Server.

(und ich musste auch recht viel Zeit investieren um den ungewollten bzw. nicht relevanten IPv6 Traffic aus dem Dump zu entfernen, das ist aber auch sicherlich für den Fachbereich zur Untersuchung interessant, daher habe ich mir die Mühe gegeben)

Auch da, danke für’s testen. Bleibt nur auf Giulia, Matze oder ein anderer Moderator zu warten  bis es hoffentlich weiter gehen kann. Solange sammle ich hier und da mal die potenziel problematische Ziele wie eben kürzlich Golem (sporadisch) oder Netcup (scheint stabil kaputt zu sein).

Michelin:

root@turris:~# mtr -ezbw6 -c 100 www.michelin.de ; echo "CURL: curl -v -s https://www.michelin.de/ -o /dev/null" ; curl -v -s https:
//www.michelin.de/ -o /dev/null
Start: 2026-09-12T12:31:42+0200
HOST: turris                                                               Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS6805   2a02:3001::20a (2a02:3001::20a)                               0.0%   100    9.7   9.7   8.8  27.5   1.9
  2. AS6805   2a02:30ff:ffff::58 (2a02:30ff:ffff::58)                      48.0%   100   18.5  18.5  17.6  28.3   1.6
  3. AS???    ???                                                          100.0   100    0.0   0.0   0.0   0.0   0.0
  4. AS8075   ae22-0.icr01.hkg20.ntwk.msn.net (2a01:111:2000:2:8000::1ae)   2.0%   100   21.3  21.0  20.5  25.2   0.6
  5. AS???    ???                                                          100.0   100    0.0   0.0   0.0   0.0   0.0
  6. AS8075   2a01:111:201:f200::16aa (2a01:111:201:f200::16aa)             0.0%   100   18.5  19.3  18.0  40.8   3.2
       [MPLS: Lbl 23569 TC 0 S u TTL 1]
  7. AS8075   2a01:111:2000:6::4fd1 (2a01:111:2000:6::4fd1)                 0.0%   100   22.1  22.7  20.8  35.6   1.9
  8. AS???    2603:10a0:1203:1200::2 (2603:10a0:1203:1200::2)               0.0%   100   21.0  21.2  20.5  28.9   1.1
  9. AS???    2603:10a0:1203:1000::42 (2603:10a0:1203:1000::42)             0.0%   100   22.9  23.6  21.4  54.6   5.1
 10. AS???    2603:10a0:120c:393:: (2603:10a0:120c:393::)                   0.0%   100   22.1  21.9  20.8  35.7   1.7
 11. AS???    2603:10a0:120c:393::1a (2603:10a0:120c:393::1a)               0.0%   100   18.8  19.2  18.2  35.9   1.9
 12. AS8075   2603:1061:14:62::1 (2603:1061:14:62::1)                       0.0%   100   21.2  21.2  20.5  29.1   1.1
CURL: curl -v -s https://www.michelin.de/ -o /dev/null
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [88 bytes data]
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [155 bytes data]
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
{ [19 bytes data]
* TLSv1.3 (IN), TLS handshake, Certificate (11):
{ [6489 bytes data]
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
{ [520 bytes data]
* TLSv1.3 (IN), TLS handshake, Finished (20):
{ [52 bytes data]
* TLSv1.3 (OUT), TLS handshake, Finished (20):
} [52 bytes data]
> GET / HTTP/2
> Host: www.michelin.de
> User-Agent: curl/8.20.0
> Accept: */*
> 
} [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [265 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [265 bytes data]
< HTTP/2 200 
< date: Sat, 12 Sep 2026 10:33:30 GMT
< content-type: text/html
< cache-control: max-age=3600
< content-security-policy: default-src *; img-src * blob: data:; style-src 'unsafe-inline' *; script-src 'unsafe-inline' 'unsafe-eval' *; font-src * data:; worker-src 'self' blob: https://via.batch.com; frame-src 'self' *.cxf-public-multisite.prod-we-cxf.michelin.fr *.youtube.com *.google.com *.hcaptcha.com *.qualtrics.com *.googletagmanager.com https://itworks.agency https://mcx0vvrj5ql5kfmyh03-jt9sq6d1.pub.sfmc-content.com https://wiper-blade.webmichelin.com *.iadvize.com
< referrer-policy: strict-origin-when-cross-origin
< x-frame-options: SAMEORIGIN
< strict-transport-security: max-age=31536000; includeSubDomains; preload
< alt-svc: h3=":8443";ma=60;
< x-azure-ref: 20260912T103330Z-16f5d58b787xz98qhC1BERqx3000000011f000000000463c
< x-fd-int-roxy-purgeid: 0
< x-cache-info: L1_T2
< x-cache: TCP_HIT
< 
{ [8192 bytes data]

Pitstop:

root@turris:~# mtr -ezbw6 -c 100 www.pitstop.de ; echo "CURL: curl -v -s https://www.pitstop.de// -o /dev/null" ; curl -v -s https:/
/www.pitstop.de/ -o /dev/null
Start: 2026-09-12T14:29:11+0200
HOST: turris                                                               Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS6805   2a02:3001::20a (2a02:3001::20a)                               0.0%   100   10.2   9.8   8.9  18.8   1.6
  2. AS6805   2a02:30ff:ffff::58 (2a02:30ff:ffff::58)                      50.0%   100   16.6  17.1  16.2  23.0   0.9
  3. AS???    ???                                                          100.0   100    0.0   0.0   0.0   0.0   0.0
  4. AS8075   ae22-0.icr01.hkg20.ntwk.msn.net (2a01:111:2000:2:8000::1ae)   0.0%   100   20.7  20.5  20.1  21.4   0.2
  5. AS8075   2a01:111:2000:6::513a (2a01:111:2000:6::513a)                 0.0%   100   26.7  27.5  25.9  44.9   2.0
       [MPLS: Lbl 24207 TC 0 S u TTL 1]
       [MPLS: Lbl 20638 TC 0 S u TTL 1]
  6. AS8075   2603:1060:1:10::f7f9 (2603:1060:1:10::f7f9)                   1.0%   100   26.4  37.5  26.3 202.4  35.5
       [MPLS: Lbl 98726 TC 0 S u TTL 1]
       [MPLS: Lbl 20638 TC 0 S u TTL 2]
  7. AS8075   be6.ibr01.fra21.ntwk.msn.net (2603:1060:1:10::f276)           0.0%   100  106.9  35.5  23.3 123.4  24.3
       [MPLS: Lbl 20638 TC 0 S u TTL 1]
  8. AS8075   2a01:111:2000:6::5665 (2a01:111:2000:6::5665)                 0.0%   100   24.8  25.5  23.3  46.7   3.1
  9. AS???    2603:10a0:1b0a:1100::1a (2603:10a0:1b0a:1100::1a)             0.0%   100   22.9  23.3  22.8  24.0   0.3
 10. AS???    2603:10a0:1b0a:1203::e (2603:10a0:1b0a:1203::e)               1.0%   100   24.9  25.3  23.9  27.5   0.6
 11. AS???    2603:10a0:1b0c:22:: (2603:10a0:1b0c:22::)                     0.0%   100   23.8  23.9  23.3  33.0   1.3
 12. AS???    2603:10a0:1b0c:22::4e (2603:10a0:1b0c:22::4e)                 2.0%   100   26.0  26.4  25.7  32.4   0.8
 13. AS8075   2603:1061:14:c0::1 (2603:1061:14:c0::1)                       0.0%   100   26.2  26.6  25.8  42.9   2.0
CURL: curl -v -s https://www.pitstop.de// -o /dev/null
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [88 bytes data]
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [155 bytes data]
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
{ [19 bytes data]
* TLSv1.3 (IN), TLS handshake, Certificate (11):
{ [3675 bytes data]
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
{ [264 bytes data]
* TLSv1.3 (IN), TLS handshake, Finished (20):
{ [52 bytes data]
* TLSv1.3 (OUT), TLS handshake, Finished (20):
} [52 bytes data]
> GET / HTTP/2
> Host: www.pitstop.de
> User-Agent: curl/8.20.0
> Accept: */*
> 
} [5 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [265 bytes data]
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
{ [265 bytes data]
< HTTP/2 200 
< date: Sat, 12 Sep 2026 12:30:59 GMT
< content-type: text/html; charset=utf-8
< set-cookie: .AspNetCore.Mvc.CookieTempDataProvider=; expires=Thu, 01 Jan 1970 00:00:00 GMT; path=/; samesite=lax; httponly
< set-cookie: ARRAffinity=3cfe43e121151906f301d84ba09e1280bdfbed94ab77a00eab300271f29564bd;Path=/;HttpOnly;Secure;Domain=www.pitstop.de
< set-cookie: ARRAffinitySameSite=3cfe43e121151906f301d84ba09e1280bdfbed94ab77a00eab300271f29564bd;Path=/;HttpOnly;SameSite=None;Secure;Domain=www.pitstop.de
< strict-transport-security: max-age=2592000
< request-context: appId=cid-v1:f57ea6fc-886d-4f02-8245-7e7015810f22
< x-frame-options: SAMEORIGIN
< x-content-type-options: nosniff
< referrer-policy: strict-origin-when-cross-origin
< permissions-policy: accelerometer=(), camera=(), gyroscope=(), magnetometer=(), microphone=(), usb=()
< content-security-policy: frame-ancestors 'self'
< x-azure-ref: 20260912T123058Z-16f5d58b787t9hrhhC1BERe46n00000002v0000000000x67
< x-cache: CONFIG_NOCACHE
< 
{ [8192 bytes data]

P.S.: Beim curl Aufruf sollte vielleicht ein -6 dazu um IPv6 zu erzwingen, oder -4 fuer IPv4? Wenn ich das mache, funktionieren alle drei URLs mit beiden IP Versionen.

Auch da, danke für’s testen. Bleibt nur auf Giulia, Matze oder ein anderer Moderator zu warten  bis es hoffentlich weiter gehen kann. Solange sammle ich hier und da mal die potenziel problematische Ziele wie eben kürzlich Golem (sporadisch) oder Netcup (scheint stabil kaputt zu sein).

​@almightyloaf gern geschehen, und mein Angebot besteht auch weiterhin. Ich betreibe selber eine Atlas Probe, und kann Dir gerne die ID mitteilen (lieber per DM als hier im oeffentlichen Thread).

Vielen Dank nochmal.

Ich merke gerade, aus irgend einem Grund gibt cURL diesmal nicht an, welche IP nun verwendet wird, trotzdem bleibt die Wahrscheinlichkeit hoch dass es die bzw. eine IPv6 Adresse sein wird.

P.S.: Beim curl Aufruf sollte vielleicht ein -6 dazu um IPv6 zu erzwingen, oder -4 fuer IPv4? Wenn ich das mache, funktionieren alle drei URLs mit beiden IP Versionen.

Ggf. ja, wobei normalerweise cURL angibt, mit welcher IP er sich nun verbindet.

curl -v -s https://telekom.de/ -o /dev/null
* Host telekom.de:443 was resolved.
* IPv6: 2a05:d014:73f:ec04:23ef:c018:758f:d821, 2a05:d014:73f:ec05:c4bd:6cb4:3a9e:327b, 2a05:d014:73f:ec03:d255:940:bce5:3d47
* IPv4: 3.75.123.125, 52.29.103.196, 63.184.16.68
*   Trying [2a05:d014:73f:ec04:23ef:c018:758f:d821]:443...
* Connected to telekom.de (2a05:d014:73f:ec04:23ef:c018:758f:d821) port 443

Zur Atlas Probe, das war auch etwas off-topic, ich bediene mich deren IP Adressen um Packet Loss zu monitoren für Gegen/Kontrolltests, weil das Thema zwar besser wurde aber es dennoch nicht sauber ist. Ich habe auch noch keinen RIPE Account um Probes zu nutzen.

Hier gab es noch vor ca. 2 Jahren eine, quasi in unmittelbarer Nähe (und daher super praktisch weil ja mit hoher Wahscheinlichkeit am selben OLT). Die ist iswischen weg und es gibt nur noch Probes  (egal welcher AS) die mindestens 15-20km Luftlinie weit entfernt sind und definitiv schon über einen anderen BNG zu erreichen sind. So sind meine Kontrolltests weniger aussagekräftig und über AS6805 sind es eh nicht so viele. Aber bei Bedarf melde ich mich :)

Das mag die curl Variante auf meinem OpenWrt-basierten Router sein…

Ja, das ist es, unter Macos ist es informativer:
 

user@123-1234567-2 ~ %  curl -v -s https://www.pitstop.de/ -o /dev/null 
* Host www.pitstop.de:443 was resolved.
* IPv6: 2603:1061:14:67::1
* IPv4: 150.171.109.104
*   Trying [2603:1061:14:67::1]:443...
* Connected to www.pitstop.de (2603:1061:14:67::1) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
} [319 bytes data]
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (IN), TLS handshake, Server hello (2):
{ [88 bytes data]
* (304) (OUT), TLS handshake, Client hello (1):
} [352 bytes data]
* (304) (IN), TLS handshake, Server hello (2):
{ [155 bytes data]
* (304) (IN), TLS handshake, Unknown (8):
{ [19 bytes data]
* (304) (IN), TLS handshake, Certificate (11):
{ [3675 bytes data]
* (304) (IN), TLS handshake, CERT verify (15):
{ [264 bytes data]
* (304) (IN), TLS handshake, Finished (20):
{ [52 bytes data]
* (304) (OUT), TLS handshake, Finished (20):
} [52 bytes data]
* SSL connection using TLSv1.3 / AEAD-AES256-GCM-SHA384 / [blank] / UNDEF
* ALPN: server accepted h2
* Server certificate:
*  subject: CN=www.pitstop.de
*  start date: Jun 12 00:00:00 2026 GMT
*  expire date: Dec 12 23:59:59 2026 GMT
*  subjectAltName: host "www.pitstop.de" matched cert's "www.pitstop.de"
*  issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=GeoTrust TLS RSA CA G1
*  SSL certificate verify ok.
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://www.pitstop.de/
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: www.pitstop.de]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [user-agent: curl/8.7.1]
* [HTTP/2] [1] [accept: */*]
> GET / HTTP/2
> Host: www.pitstop.de
> User-Agent: curl/8.7.1
> Accept: */*
> 
* Request completely sent off
< HTTP/2 200 
< date: Sat, 12 Sep 2026 13:12:00 GMT
< content-type: text/html; charset=utf-8
< set-cookie: .AspNetCore.Mvc.CookieTempDataProvider=; expires=Thu, 01 Jan 1970 00:00:00 GMT; path=/; samesite=lax; httponly
< set-cookie: ARRAffinity=3cfe43e121151906f301d84ba09e1280bdfbed94ab77a00eab300271f29564bd;Path=/;HttpOnly;Secure;Domain=www.pitstop.de
< set-cookie: ARRAffinitySameSite=3cfe43e121151906f301d84ba09e1280bdfbed94ab77a00eab300271f29564bd;Path=/;HttpOnly;SameSite=None;Secure;Domain=www.pitstop.de
< strict-transport-security: max-age=2592000
< request-context: appId=cid-v1:f57ea6fc-886d-4f02-8245-7e7015810f22
< x-frame-options: SAMEORIGIN
< x-content-type-options: nosniff
< referrer-policy: strict-origin-when-cross-origin
< permissions-policy: accelerometer=(), camera=(), gyroscope=(), magnetometer=(), microphone=(), usb=()
< content-security-policy: frame-ancestors 'self'
< x-azure-ref: 20260912T131200Z-15d589cbfbdvhswchC1BERq2xn00000018k0000000002ftk
< x-cache: CONFIG_NOCACHE
< 
{ [8192 bytes data]
* Connection #0 to host www.pitstop.de left intact

Jup, bestätigt auch letztendlich die obige Vermutung (hab die vorherige Antwort editiert und ergänzt).

Danke für die Gegentests

Zur Atlas Probe, das war auch etwas off-topic, ich bediene mich deren IP Adressen um Packet Loss zu monitoren für Gegen/Kontrolltests, weil das Thema zwar besser wurde aber es dennoch nicht sauber ist. Ich habe auch noch keinen RIPE Account um Probes zu nutzen.

Hier gab es noch vor ca. 2 Jahren eine, quasi in unmittelbarer Nähe (und daher super praktisch weil ja mit hoher Wahscheinlichkeit am selben OLT). Die ist iswischen weg und es gibt nur noch Probes  (egal welcher AS) die mindestens 15-20km Luftlinie weit entfernt sind und definitiv schon über einen anderen BNG zu erreichen sind. So sind meine Kontrolltests weniger aussagekräftig und über AS6805 sind es eh nicht so viele. Aber bei Bedarf melde ich mich :)

Ah, OK, wenn Du die ProbeID kennst kannst Du halt deren aktuellen IP Adressen abfragen und dann zumindest fuer’s Monitoring nutzen. Wobei das am selben OLT natuerlich deutlich interessanter ist als irgendwo anders.