Ist die MTU (maximale Paketgröße pro Sendung) auf einem Abschnitt unterwegs kleiner und wird die Meldung „Paket zu groß“ blockiert, verschwinden ständig nur die großen Pakete.
Warum MTU sinkt auf Tunnel- oder VPN-Strecken → Folge Meldung „Paket zu groß“ (ICMP) wird von einer Firewall blockiert, der Sender erfährt nichts davon → Auf dem Bildschirm Nur beim Öffnen großer Ansichten wie Inventar oder Charakterliste ein Freeze, dann Verbindungsabbruch
Um die Größe serverseitig selbst zu senken, die maximale Segmentgröße des Sockets (TCP_MAXSEG) setzen (Nachrichten im Spielcode klein zu stückeln reicht allein nicht), UDP-Pakete auf höchstens 1.200 Byte begrenzen.
Aufgaben Infrastrukturteam
Netzwerk: TCP-Paketgröße auf Tunnelstrecken verringern (MSS-Clamping), „Paket zu groß“-Meldungen (ICMP) in Firewalls und Netzwerk-ACLs der Cloud erlauben. Server/OS: „Paket zu groß“-Meldungen (ICMP) auch in der Server-Firewall und in Cloud-Security-Groups erlauben, MTU-Probing im Server-Kernel aktivieren (tcp_mtu_probing=1, letztes Sicherheitsnetz, das erst nach einigen Sekunden Stillstand greift).
Größenordnungen
Meist 1.500 Byte, nach einem Tunnel nur noch etwa 1.400.
Im Graphen
Nur einzelne Ausreißer · Verbindungsabbrüche nach Region und Provider, fehlgeschlagene große Antworten
Wo nachsehen
Vom PC des betroffenen Spielers Pings mit gesetztem Don't-Fragment-Bit (DF) und wechselnder Größe an den Server senden. Unter Windows ping /f /l 1472 SERVER_IP, unter Linux ping -M do -s 1472 SERVER_IP (1.472 ist MTU 1.500 minus 20 Byte IP-Header und 8 Byte ICMP-Header). Größe schrittweise verringern, bis die größte durchgehende Größe gefunden ist, und prüfen, ob Security Group und Firewall auf Serverseite die ICMP-Meldung „Paket zu groß“ (Fragmentation Needed) erlauben
Spricht dafür
Kleine Pings gehen durch, DF-Pings mit 1.472 Byte scheitern (keine Antwort oder Fehlermeldung, dass Fragmentierung nötig ist), und die größte durchgehende Größe liegt nur bei etwa 1.400. Spieler derselben Region haben nur beim Öffnen großer Ansichten einen Freeze
Spricht dagegen
Auch DF-Pings mit 1.472 Byte gehen durch: kein Path-MTU-Problem. Auch kleine Pings gehen nicht durch: ICMP ist komplett blockiert, mit dieser Methode nicht beurteilbar
Prüfmittel
Prüfung in der Umgebung des Spielers
Quellen
RFC 2923: TCP Problems with Path MTU DiscoveryIETF Blockiert eine Firewall ICMP (Fragmentation Needed), scheitert die Path-MTU-Discovery, und nur große Pakete verschwinden immer wieder (Blackhole), da Pings und kleine Übertragungen funktionieren, ist die Diagnose schwierig
IP SysctlLinux kernel tcp_mtu_probing=1 ist normalerweise inaktiv und schaltet die TCP-Path-MTU-Discovery ein, sobald ein ICMP-Blackhole erkannt wird
ping(8) — Linux manual pageiputils -M do setzt das DF-Bit und lehnt Pakete ab, die größer als die Path-MTU sind, -s legt die Datengröße fest (Standard 56 Byte plus 8 Byte ICMP-Header)
pingMicrosoft /f setzt das DF-Bit und dient zur Suche nach Path-MTU-Problemen, /l legt die Datengröße fest
Verwandte Ursachen
Gleiche Schicht: L5 Netzwerkgeräte im Rechenzentrum