Paketverluste und instabiles BGP-Routing im O2-Backbone (nachgewiesen via Traceroute)

  der sollte standardmäßig bei 1500 liegen

Im LAN definitiv, sobald es das LAN durch dein Router verlässt werden dann aber Pakete ggf. von ihm fragmentiert, damit sie durch die Verbindung mit einer MTU von 1492 gehen können (um es jetzt mal kurz zu halten, wir lassen mal die potenzielle Rolle von ICMP hier unter dem Teppich versteckt)

Aber es kursieren Gerüchte, wonach ein niedrigerer MTU-Wert die Probleme beseitigt.

Genau diese sind auch gemeint.

Sei es, bei speziellen VPN-Verbindungen, oder bei den Einstellungen bei Spielekonsolen, wo man scheinbar häufig aus einer sog. Lobby gekickt wird.

Eben das hat i.d.R. nichts mit der MTU zu tun, bzw. das sollte man dann wengistens analysieren und zeigen dass es daran liegt. Aber auch für solche Sachen gibt es geeignetere Lösungen als “stumpf” die MTU zu reduzieren, nur die sind dann meistens auf Anbieterseite (damit ist hier der Anbieter der Lobby  oder der VPN Verbindung gemeint) oder im Programmcode zu implementieren, oder wenn man die MTU reduziert, dann halt eben nicht “stumpf” sondern indem man genau weisst welchen Overhead man mit der kleineren MTU kompensiert, wenn fragmentierte Pakete derart unakzeptabel sein sollen (hat doch früher funktioniert, why, dabei war IMHO die Wahrscheinlichkeit früher höher, dass ein Router zwischen Quelle und Ziel fragmentieren musste).

Der TE schrieb, dass er sowohl bei DSL als AUCH bei einer Mobilfunkverbindung die Probleme hat

Was gegen ein Problem auf der xDSL als auch gegen ein “MTU Problem” spricht. Wenn es ersteres wäre, würde es ja über Mobilfunk sich normal verhalten, wenn es letzteres wäre genauso, denn die MTU ist bei Mobilfunk eine andere als bei xDSL, da über Mobilfunk kein PPPoE verwendet wird. Jedoch muss ich hier gestehen dass mir die MTU der Mobilfunkanbindungen nicht bekannt ist und ich stand jetzt keinen Weg kenne diese mit wenig Aufwand zu ermitteln. Da es bei Mobilfunk bei IPv4 einen Carrier-Grade NAT Mechanismus gibt, kann ich mir durchaus vorstellen dass hier einen gewissen Overhead existiert, den man kompensieren müsste und auch dass dieser nicht unbedingt auch 8 Byte (siehe unten) beträgt.

Auch ich kann mir nicht vorstellen, dass diese Lösung das Gelbe vom Ei ist

Ich wollte nicht den Eindruck erwecken dass MTU senken keine Lösung ist, oder nicht vielleicht “die” Lösung ist, jedoch sollte man das eben nicht “stumpf” machen sondern eben wissen was man mit der kleineren MTU kompensieren möchte, sei es den PPP Overhead (8 Byte, daher eben die 1492 statt 1500), oder eben etwas anderes.

https://www.google.com/search?client=firefox-b-d&q=vpn+mtu

Ey, ein Firefox user! Vorbildlich. Fehlt nur noch eine bei einem europäischen Hoster gehosteten Suchmaschine :)

Das ist aber wirklich offtopic. Die tracking metadaten in der URL haben dich verraten.

​@almightyloaf 

Ich möchte Dir an keiner Stelle widersprechen, aber um endgültig festzustellen, ob oder ob es nicht am MTU-Wert liegt, kann man ganz einfach testen, indem man ein wenig mit dem Ping spielt. 

Standardwert der MTU ist 1500. Wie findet man diesen optimalen Wert? Indem man einen Wert von 1500 zum Pingen nutzt, wobei man berechnen muss, dass ein Header (glaube ich) in Größe von 8 Byte gesendet wird, sowie weitere 20 Byte für etwas weiteres (müsste ich googlen!).

Um mal gleich mit dem Gegenbeispiel anzufangen, habe ich mit ping -f -l 1473 google.de angepingt und das kam dabei raus:

 ping -f -l 1473 google.de

Ping wird ausgeführt für google.de [142.250.184.227] mit 1473 Bytes Daten:
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.

Was zu erwarten war. Ein einziges Byte zu viel und alles ist hin. Mit einem Byte weniger sieht das dann so aus:

ping -f -l 1472 google.de

Ping wird ausgeführt für google.de [142.250.184.227] mit 1472 Bytes Daten:
Antwort von 142.250.184.227: Bytes=1472 Zeit=51ms TTL=113
Antwort von 142.250.184.227: Bytes=1472 Zeit=60ms TTL=113
Antwort von 142.250.184.227: Bytes=1472 Zeit=137ms TTL=113
Antwort von 142.250.184.227: Bytes=1472 Zeit=44ms TTL=113

Das ist der optimale MTU-Wert, wobei man dafür die 28 Byte aufaddieren muss.

Der TE könnte nun ganz einfach testen, ohne etwas am Rechner zu verstellen, indem er den Pfad/die IP zum VPN-Server anpingt, und zwar mit 

ping -f -l 1472 PfadZumVPNServer 

Ist der VPN-Server damit überfordert, muss man schrittweise den Wert senken, bis dass der VPN-Server antwortet.

Antwortet der VPN-Server gleich ohne Probleme bei einer Größe von 1472, muss man nichts am MTU-Wert ändern und ich bin einmal mehr der Trottel!

;)

Ich persönlich kenne keinen VPN-Dienst, der Probleme macht, aber das sind auch öffentliche VPN-Server. Hier wird es sich wohl um einen firmeninternen VPN-Dienst handeln. 

kann man ganz einfach testen, indem man ein wenig mit dem Ping spielt.

Jup, das hatte ich auch schon geschrieben :D

Das lässt sich übrigens auch mit ICMP ermitteln, man darf nur nicht vergessen dass der ICMP Overhead 8 Byte sind und nicht 20 wie bei TCP ;)

sowie weitere 20 Byte für etwas weiteres

Für den Internet Protokoll (IP).

Ist der VPN-Server damit überfordert, muss man schrittweise den Wert senken, bis dass der VPN-Server antwortet.

Das ist klein klein meckerei, aber genau genommen ist der VPN Server nicht damit überfordert, sondern ein Router zwischen Quelle und Ziel meldet zurück dass das Paket zu gross ist. Aber der effekt ist vergleichbar. In der Regel wäre es dann den Router den man bei sich im Wohnraum stehen hat, er kann ja “nur” mit einer MTU von 1492 ins Internet, somit sind 1500 zu gross.

Antwortet der VPN-Server gleich ohne Probleme bei einer Größe von 1472, muss man nichts am MTU-Wert ändern und ich bin einmal mehr der Trottel!

Keine Sorge, wie gesagt, ich sage auch nicht dass es nicht die lösung ist, nur eben sollte man schon wissen was man kompensiert, bevor man sich fantasiewerte (und den placeboeffekt) ausdenkt. Womöglich ist eine MTU von 1492 hier schon ausreichend “klein”.

Bei einer payload von 1472 kämst du so oder so auf eine MTU von 1500, das passt dann auch nicht zu einem xDSL oder Glasfaser Anschluss, es sei denn es hat sich hier etwas geändert. Zu einem Kabelanschluss auch nicht, bei IPv4, weil dort ja der Carrier-Grade NAT auch seinen Overhead mit sich bringt.

Also ich würde sagen, möchte man den PPP overhead kompensieren, wäre der ICMP Echo Request erst mit einer Payload von 1464 oder kleiner erfolgreich, wenn der DF-Flag gesetzt ist.

​@almightyloaf 

Und noch einmal kein Widerspruch meinerseits. Aber zur allgemeinen Entwirrung möchte ich auf eines aufmerksam machen:

wäre der ICMP Echo Request erst mit einer Payload von 1464 oder kleiner erfolgreich, wenn der DF-Flag gesetzt ist.

Nur, damit es hier nicht zu Missverständnissen kommt. Wenn der Ping-Test mit 1464 Bytes erfolgreich war, muss man den MTU-Wert auf 1492 statt 1500 setzen. Aber auch den Wert hast Du bereits erwähnrt.

;)

Bleibt die Frage, ob der VPN-Server auf ICMP-Anfragen reagiert...

Tja, da bleiben mir wohl nur folgende Möglichkeiten: wenn unser Systemadmin am 15.11. wieder gesund ist, ihn zu fragen, ob ich das Verbindungsprotokoll von UDP auf TCP ändern kann (soll angeblich stabiler sein),

Hellow ​@Herr Hoeren 😊

Ich wollte mal horchen, ob es schon ein Update gibt? Ist der Sys Admin zurückgekehrt? Und falls ja, konnte er was zur Lösung beitragen? 

VG Matze 

Danke fuer die Aufloesung!

​@Herr Hoeren Danke für das Update und es freut mich doppelt, das wir 1. nicht Schuld waren und 2. du nun endlich wieder entspannt im HO arbeiten kannst 😊

Zusätzlich auch ein großes Dankeschön für die angenehme Kommunikation und den gemeinsamen Austausch und von meiner Seite auch noch mal vielen Dank an alle die hier so tatkräftig unterstützt und mit Tipps und Trick supportet haben \o/ 

VG Matze