Tobias Fiebig findet die Ursache im virtuellen NIC

Zusammenfassung

Tobias Fiebigs RIPE-93-Fall wirkte zunächst wie eine Drosselung im Zugangsnetz. Eine ICMP-Freigabe in der Server-Firewall half nicht; erst Paketmitschnitt und VM-Vergleich zeigten unterschiedliche virtuelle Netzwerkkarten.
Der TCP-Offload der emulierten RTL8139 blieb auf 1.500 Byte eingestellt, obwohl die Route 1.420 Byte gelernt hatte. Eine spezifischere Route mit festem MTU 1.320 brachte den Transfer wieder in Gang.

Analyse

Der Provider stand unter Verdacht. Die Pakete erzählten eine peinlichere Geschichte: In der virtuellen Maschine arbeitete eine alte Netzwerkkarte so, als passten 1.500 Byte durch jeden Pfad.

Tobias Fiebig schilderte den Fall im Closing Plenary von RIPE 93. Ein großer Download brach für Clients auf Pfaden unterhalb von 1.500 Byte ein; von einer benachbarten virtuellen Maschine lief derselbe Dienst. Ein Problem des Zugangsnetzes oder der Firewall war eine plausible erste Erklärung. Das Team änderte die Server-Firewall, damit die ICMP-Meldung „Packet Too Big“ passieren konnte. Die Regel war angepasst. Der Download blieb langsam.

Eine Routenabfrage auf dem betroffenen Client zeigte bereits ein Path MTU von 1.420 Byte. Der Host kannte also die engere Strecke als seine lokale Schnittstelle mit 1.500 Byte. Trotzdem häuften sich TCP-Neuübertragungen. Fiebig setzte eine spezifischere Route mit festem MTU 1.320 Byte; damit funktionierte der Transfer. Die Werte messen nicht dasselbe: 1.420 war das ermittelte Path MTU, 1.320 der erfolgreiche lokale Umweg.

Der erste Nachbau des Fehlers scheiterte. Fiebig startete eine zweite VM mit derselben Software und schickte dasselbe Testpaket. Kein Problem. Beim Vergleich der virtuellen Hardware fiel der Unterschied auf: Im betroffenen Gast steckte eine emulierte Realtek RTL8139, im Testgast ein anderes Modell. Ein gleicher Softwarestand reichte für eine Reproduktion nicht, solange die virtuelle Netzwerkkarte fehlte.

Fiebig verfolgte den Fehler bis zu net/hw/8139.c in QEMU: Der TCP-Offload verwendete ein festes MTU von 1.500 Byte. Das offizielle QEMU-Issue 1312 beschreibt denselben Ablauf: geringe Übertragungsrate hinter Links unter 1.500 Byte, ignoriertes PMTUD, Neuübertragungen und eine niedrigere MTU im Gast als Abhilfe. Fiebig datierte die Annahme im Code auf 2006 zurück und verwies auf eine Diskussion samt Patchvorschlag von 2016. Auch das Abschalten des TCP-Offloads könne helfen; im vorgestellten Fall beseitigte der Wechsel der alten Karte auf VirtIO das Problem.

Path MTU Discovery soll Endpunkte an den engsten Link eines Pfades anpassen. RFC 1191 beschreibt das Verfahren für IPv4; RFC 2923 dokumentiert TCP-Probleme, wenn ICMP-Rückmeldungen fehlen oder falsch behandelt werden. Die Firewall war also ein vernünftiger Anfangsverdacht. Als die Freigabe nichts änderte, musste die Untersuchung bis zur Grenze zwischen Gast und virtueller NIC weitergehen.

Die praktische Reihenfolge: Pakete mitschneiden, das gelernte Routen-MTU ablesen, das NIC-Modell feststellen und den Offload-Zustand vergleichen. Im öffentlichen Bericht fehlen die genaue QEMU-Version und die Offload-Konfiguration des betroffenen Gasts; diese Angaben würden zeigen, wie weit sich der konkrete Fall verallgemeinern lässt.