Hallo Dorothea,

vielen Dank für die schnelle Antwort! Der Mikrotik war vorher hinter der Vodafone Station (im Bridge Mode) geschaltet und erhielt Adresskonfiguration über DHCP/v6, die Leitung lief auch mit der Standard MTU 1500. Traceroute oder ping brachten auch keine Ergebnisse, ich gehe davon aus, dass die Seite (oder schon etwas davor?) ICMP blockiert:

traceroute wcpstatic.microsoft.com

traceroute to wcpstatic.microsoft.com (2620:1ec:bdf::45), 30 hops max, 80 byte packets

1  p200300f98f1bbe000000000000000001.dip0.t-ipconnect.de (2003:f9:8f1b:be00::1)  0.363 ms  1.136 ms  1.120 ms

2  2003:0:8203:6000::1 (2003:0:8203:6000::1)  2.490 ms  2.467 ms  2.487 ms

3  * * *

4  2a01:111:2000:1::26a2 (2a01:111:2000:1::26a2)  2.837 ms  2.794 ms  2.816 ms

5  2a01:111:2000:2:8000::e3a (2a01:111:2000:2:8000::e3a)  5.680 ms  5.662 ms 2a01:111:2000:2:8000::daa (2a01:111:2000:2:8000::daa)  14.437 ms

6  2603:10a0:30f:8104::12 (2603:10a0:30f:8104::12)  5.730 ms 2603:10a0:30f:8104::1e (2603:10a0:30f:8104::1e)  5.157 ms 2603:10a0:30f:8102::a (2603:10a0:30f:8102::a)  5.186 ms

7  2603:10a0:30f:8000::2a6 (2603:10a0:30f:8000::2a6)  5.329 ms 2603:10a0:30f:8000::66 (2603:10a0:30f:8000::66)  4.215 ms 2603:10a0:30f:8003::2a6 (2603:10a0:30f:8003::2a6)  4.817 ms

8  2603:10a0:30f:8300::256 (2603:10a0:30f:8300::256)  5.070 ms 2603:10a0:30f:8201::356 (2603:10a0:30f:8201::356)  5.274 ms 2603:10a0:30f:8303::33a (2603:10a0:30f:8303::33a)  5.216 ms

9  2603:10a0:325:f0a:: (2603:10a0:325:f0a::)  5.474 ms  5.818 ms 2603:10a0:325:f0d:: (2603:10a0:325:f0d::)  5.945 ms

10  * * *

11  * * *

12  * * *

13  * * *

14  * * *

15  * * *

16  * * *

17  * * *

18  * * *

19  * * *

20  * * *

21  * * *

22  * * *

23  * * *

24  * * *

25  * * *

26  * * *

27  * * *

28  * * *

29  * * *

30  * * *

Hier ist die Ausgabe von curl -vvv wcpstatic.microsoft.com:

* Host wcpstatic.microsoft.com:80 was resolved.

* IPv6: 2620:1ec:46::60, 2620:1ec:bdf::60

* IPv4: 13.107.213.60, 13.107.246.60

*   Trying [2620:1ec:46::60]:80...

* Connected to wcpstatic.microsoft.com (2620:1ec:46::60) port 80

> GET / HTTP/1.1

> Host: wcpstatic.microsoft.com

> User-Agent: curl/8.7.1

> Accept: */*

>

* Request completely sent off

* Recv failure: Connection reset by peer

* Closing connection

curl: (56) Recv failure: Connection reset by peer

Anbei noch ein Screenshot von Wireshark, der den Verbindungsversuch aufgezeichnet hat:

Potenziell interessant ist, dass beim SYN eine MSS von 1440 als Option weitergegeben wird, beim SYN/ACK setzt das andere Ende einen Wert von 1400. Die Verbindung schlägt trotzdem fehl, wie man hier sehen kann. Anscheinend bekommt der Server den HTTP Request nicht richtig.

Edit: Erster Absatz, Standard MTU 1500, 1600 war ein Tippfehler :)

Hallo,

wir haben den Fall einmal durch die entsprechende Abteilung prüfen lassen.

Die Kolleginnen und Kollegen konnten keine Auffälligkeiten feststellen.

Im Backbone selbst gibt es keine Probleme - die MTU am genutzten Link zu Microsoft ist korrekt auf 1514 Byte gesetzt und am Interface sehen wir für die Rückrichtung keine Drops aufgrund von Giants.

Wir können nicht ausschließen, dass hier Microsoft selbst auf gewisse IPv6 Adressbereiche aufgrund irgendwelcher Threat Detection filtert oder ICMPv6 blackholed.

Auch bei einem Test über Mobilfunk traten keine Probleme auf - curl (curl -vvv wcpstatic.microsoft.com) löst ohne Probleme auf und der Transfer ist erfolgreich.

Gruß ^Carsten

Hallo Carsten,

vielen Dank für die gründliche Diagnose und ausführliche Antwort!

Aktuell läuft alles in unserem Netzwerk mit MTU 1492 und MSS Clamping, aber in der Schnittstellenbeschreibung (https://www.telekom.de/hilfe/geraete/service/umwelt/schnittstellenbeschreibung-downloads?samChecked=true, unter xDSL und GPON) habe ich gesehen, dass ein Frame-MTU von 1522 zugelassen wird. Weiter unten wird diese Frame Size so definiert, dass PPPoE-Overhead auch in den 22 Bytes einberechnet werden können, sodass (wie ich es verstanden habe) ein L3 MTU von 1500 möglich ist.

Wie setzen sich diese 22 Bytes zusammen? Ist der Ethernet-Header mit Empfänger- und Sender-MAC-Adressen auch drin, oder ist das ähnlich wie die L2-MTU-Definition von Mikrotik (https://help.mikrotik.com/docs/spaces/ROS/pages/21725296/MTU+in+RouterOS#MTUinRouterOS-MaximumTransmissionUnit)? Unterstützt die Telekom also Jumbo Frames per RFC 4638? Auf meinem Mikrotik bleibt der PPPoE-Client-MTU auf 1492, egal wie ich den Ethernet-/VLAN-Interface-MTU einstelle. Die 8 Bytes weniger machen zwar keinen gigantischen Leistungsunterschied, aber vielleicht ist ein Standard-MTU von 1500 doch recht hilfreich, um einige Probleme zu vermeiden. :)

Danke im Voraus!

Ist Präfix der Mail-Adressmaske. Keine Sorge ;)

Moin,

die MTU auf unserem Access ist grundsätzlich 1514 Bytes.

Durch diverse weitere Protokolle bzw. "Verschachtelungen" gehen aber nochmal einige Bytes verloren (z.B. PPPoE = 8 Byte).

Am Ende bleiben für den einfachen Endkundenanschluss eine MTU von 1492 Byte übrig.

Jumbo Frames werden auf unseren normalen Endkundenanschlüssen nicht unterstützt.

Gruß ^Carsten

Sonst hätte ich es wohl kaum hier gepostet! Was soll die Frage?

gdampf

Was soll die Frage?

Weil es die Lösung des Threads ist (wurde leider nie markiert) und es eventuell nicht gelesen wurde.

Jumpignon

Weil es die Lösung des Threads ist (wurde leider nie markiert) und es eventuell nicht gelesen wurde.

MSS Clamping ist hier nicht die Lösung sondern bestenfalls ein fauler Workaround, das ist doch genau das worum es @gdampf  geht.