Firewalls und das Linux-Connection-Tracking (conntrack, eine Funktion, die durchlaufende Verbindungen in einer Tabelle vermerkt) verwerfen Pakete, wenn die Tabelle voll ist oder der Verbindungszustand nicht zu passen scheint.
Warum Connection-Tracking-Tabelle voll (table full), oder Hin- und Rückweg verlaufen verschieden und nur eine Richtung passiert die Firewall (asymmetrische Route) → Folge Firewall wertet Pakete als „unbekannte Verbindung“ oder „Sequenznummer außerhalb des Windows“ und verwirft sie → Auf dem Bildschirm Ist die Tabelle voll, scheitern neue Verbindungen. Weicht die Route ab, trifft es nur die Spieler auf dieser Route: wiederholte Retransmissions, am Ende Verbindungsabbruch
Server: für den Fall einer vollen Tabelle den Login-Andrang über ein Login-Warteschlangensystem steuern, Verbindungen wiederverwenden, damit nicht ständig kurze Verbindungen entstehen (auch bei Aufrufen zwischen Servern), Verbindungen ohne Heartbeat selbst aufräumen. Client: bei gescheitertem Login oder Verbindungsabbruch mit wachsenden Abständen und zufälliger Streuung neu versuchen (damit bei voller Tabelle nicht alle gleichzeitig zurückkommen).
Aufgaben Infrastrukturteam
Netzwerk: Connection-Tracking-Tabelle der Firewall vergrößern, Spielports vom Connection Tracking ausnehmen, Routing so anpassen, dass Hin- und Rückweg dieselbe Firewall passieren, Einstellung der TCP-Window-Prüfung der Firewall kontrollieren. Server/OS: Linux-Tabelle vergrößern (nf_conntrack_max), Spielports vom Connection Tracking ausnehmen (NOTRACK), Einstellung der TCP-Window-Prüfung kontrollieren (nf_conntrack_tcp_be_liberal), bei AWS auch conntrack_allowance_exceeded prüfen.
Größenordnungen
Das Standardlimit von Linux-conntrack (nf_conntrack_max) liegt je nach Arbeitsspeicher bei einigen Zehntausend bis einigen Hunderttausend Einträgen. Erreicht die aktuelle Zahl (nf_conntrack_count) das Limit, steht im Log „nf_conntrack: table full, dropping packet“.
Im Graphen
Plateau am Limit · Zahl der conntrack-Einträge (nf_conntrack_count), gescheiterte neue Verbindungen
Wo nachsehen
Auf Linux-Servern nf_conntrack_count und nf_conntrack_max, „nf_conntrack: table full, dropping packet“ in dmesg sowie drop und invalid in /proc/net/stat/nf_conntrack (eine Zeile pro Kern, hexadezimal) prüfen. An der Firewall Auslastung der Session-Tabelle und Drop-Logs prüfen, bei AWS conntrack_allowance_exceeded in ethtool -S
Spricht dafür
Zahl der Einträge verläuft flach am Limit, gleichzeitig steigen table-full-Logs und drop oder conntrack_allowance_exceeded. Bei asymmetrischer Route ist am Limit noch Luft, aber invalid und Drop-Logs der Firewall steigen bei Verbindungen über eine bestimmte Route
Spricht dagegen
Zahl der Einträge weit unter dem Limit, invalid und Drop-Logs unverändert: andere Ursache. Tabelle hat Luft, aber CPU oder PPS der Firewall sind am Anschlag: „Überschrittenes Verarbeitungslimit von Zwischengeräten“
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen
Netfilter Conntrack Sysfs variablesLinux kernel Standardwert von nf_conntrack_max ist die Zahl der Hash-Buckets (Arbeitsspeicher ÷ 16384, 1024–262144), aktuelle Zahl in nf_conntrack_count, nf_conntrack_tcp_be_liberal stuft nur RSTs außerhalb des Windows als INVALID ein
net/netfilter/nf_conntrack_core.cLinux kernel Bei voller Tabelle wird „nf_conntrack: table full, dropping packet“ geloggt und das Paket verworfen (drop-Statistik steigt), bei Paketen, die nicht zum Verbindungszustand passen, steigt die invalid-Statistik
Amazon EC2 security group connection trackingAWS Wird das Limit verfolgter Verbindungen pro Instanz überschritten, werden Pakete verworfen, Prüfung über conntrack_allowance_exceeded, Empfehlung, asymmetrische Routen zu vermeiden
net/netfilter/nf_conntrack_standalone.cLinux kernel /proc/net/stat/nf_conntrack hat eine Zeile pro Kern in Hexadezimal mit Spalten wie entries, invalid, insert_failed, drop und early_drop
Verwandte Ursachen
Gleiche Schicht: Grundursachen von TCP-Retransmissions