‎PMTUD Blackhole auf Telekom-Netz? | Telekom hilft Community

Telekom hilft Community

Telekom Business Community

Privatkunden

Telekom Shops

Kontakt

PMTUD Blackhole auf Telekom-Netz?

vor einem Monat

Abend allerseits,

haben seit zwei Wochen einen FTTH -Anschluss. Betreibe meinen eigenen Mikrotik RB750Gr3 hinter der offiziellen Glasfaser Modem 2. Über diese zwei Wochen ist mir aufgefallen, dass einige Microsoft-Seiten extremst langsam laden. Nach weiterer Untersuchung erfahren einige Domains ständig einen Timeout, u.a. wcpstatic.microsoft.com und js.monitor.azure.com, von der viele Microsoft-Seiten JavaScript-Assets laden. Scheinbar ist ironischerweise auch dieses Forum, telekomhilft.telekom.de, betroffen, aber auch nur ein paar CDN -Assets, die auf der Seite eingebunden sind.

Habe sowohl die vom PPPoE-Server erteilten DNS-Server, als auch Cloudflare DoH getestet. Das Timeout liegt wohl nicht an DNS, denn keine der beiden konnte das Problem beheben.

Bei manueller Verringerung der MTU auf Client-Geräten auf 1400 (Werte dazwischen noch nicht getestet) ist das Problem gelöst. Nach etwas Recherche über MTU gehe ich von einem PMTUD Blackhole aus, das sich irgendwo auf der Route zwischen meinem Netzwerk und die von Microsoft befindet.

Vorher waren wir im Netz von Vodafone (Kabel) und das Problem gab es nicht.

Habt ihr das Problem auch? Ich wollte hier kurz fragen, bevor ich den Support aufsuche, was evtl. doch etwas mehr Zeit in Anspruch nehmen wird.

Falls ich meinerseits noch etwas tun oder nachsehen kann, gebt gerne Bescheid!

Besten Dank im Voraus!

122

vor einem Monat

Hallo @2242502897 und herzlich willkommen in unserer Community.

Hast du den Router zuvor auch schon genutzt? Kannst du uns einen Tracert zu einer der Seiten schicken? Natürlich ohne kundenbezogene Daten.

Viele Grüße

Dorothea

von

vor einem Monat

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 :)

Uneingeloggter Nutzer

von

vor einem Monat
Update: Das Problem ließ sich scheinbar vorrübergehend beheben, nachdem MSS Clamping (für mich hat die Mikrotik-Option clamp-to-pmtu gereicht) sowohl für IPv4 als auch IPv6 eingerichtet ist, was auf allen eingehenden und ausgehenden Paketen angewandt wird - was mich etwas überrascht. Denn eigentlich sollte ICMP, vor allen ICMPv6 aus funktionellen Gründen nie blind blockiert werden sollten :)

Mich würde es aber trotzdem freuen, wenn sich jemand seitens Telekom die Route diagnosieren könnte. MSS Clamping funktioniert, ist aber angesichts der theoretischen Leistung doch eher suboptimal. Damit einen schönen Abend und danke für die Bemühungen!
0
2
von
vor 20 Tagen
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
von
vor 20 Tagen
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!
0
Uneingeloggter Nutzer
von
vor 20 Tagen
@2242502897

Unabhängig von der beschriebenen Problematik:

Kann es sein, dass Du Deine Telekom-Kundennummer als "Nickname" verwendest?

Wenn ja, ist das sehr riskant - und öffnet Internet-Betrügern Tür u. Tor....
2
von
vor 20 Tagen
Ist Präfix der Mail-Adressmaske. Keine Sorge ;)
0
von
vor 9 Tagen
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
Uneingeloggter Nutzer
von