tcpdump toont 64 KB-pakketten: offload en opnamemoment

Een opname op een host kan een pakket van 64 KB tonen op een interface met MTU 1420, en de voor de hand liggende conclusie is dat de tunnel zijn groottelimiet negeerde. Die conclusie is meestal onjuist. Opnamepunten op de host liggen binnen het verwerkingspad, waar segmentatie, aggregatie en checksumwerk mogelijk nog niet hebben plaatsgevonden. Lees de positie van de waarnemer voordat u de pakketgrootte leest.

Waar u opneemt, verandert wat u ziet

Transmit-offload laat de stack een grote eenheid aan het netwerkapparaat overhandigen, dat die later in stukken van draadformaat knipt. Ontvangstaggregatie doet het omgekeerde op de inkomende weg en voegt segmenten samen voordat een waarnemer aan de hostkant ze ziet. Een opname legt dus het interne beeld van de host op dat punt vast, niet noodzakelijk de frames op de link. Beide mechanismen hangen af van het apparaat en het pad.

ethtool -k eth0 | grep -E 'tso|gso|gro'

Neem op een tweede punt op, idealiter een onafhankelijke ontvanger of een spiegel, voordat u de grootte als fout behandelt. Als de grote eenheid alleen op de verzendende host verschijnt, heeft de draad hem misschien nooit gedragen. Twee observatiepunten zijn sterker dan één bestand, vooral wanneer de vraag is wat de machine werkelijk heeft verlaten.

Scheid de binnenste en buitenste interface

Een tunnel voegt zijn eigen interface toe, en de buitenste en binnenste beelden verschillen in inkapseling en in verwerking. Een opname op het tunnelapparaat toont het binnenste pakket; een opname op de fysieke adapter toont het buitenste. Grootte, adressen en checksumstatus kunnen tussen beide verschillen om redenen die niets met een fout te maken hebben.

Noteer welke interface elk bestand heeft geproduceerd. Een grootte die op het tunnelapparaat te zien is, beschrijft het binnenste pakket, niet het frame dat de adapter uiteindelijk verstuurde. Ze in één analyse door elkaar halen is hoe een normaal inkapselingsverschil een raadsel wordt.

Een checksumwaarschuwing is ook positioneel

Een opname aan de verzendkant kan een checksumveld tonen voordat de hardware het vult, wat een waarschuwing oplevert die geen enkele ontvanger ooit zou zien. Dat is ander bewijs dan een externe host die een beschadigd pakket weigert. De richting en het opnamepunt bepalen welke van de twee u heeft.

Wanneer een werkelijke overdracht mislukt, vergelijk waarnemingen bij een ontvanger of op een ander punt van het pad. Bewaar richting, interface en inkapsellaag bij de opname, want een schermafbeelding zonder die gegevens is later niet te interpreteren.

Schakel offload alleen als gecontroleerde test uit

Offload uitschakelen verandert prestaties en pakketverwerking, dus het is niet de eerste reactie op een vreemde weergave van de grootte. Als u het test, wijzig één instelling en leg eerst de basislijn vast. Een run die ook MTU, firewallregels en het clientprofiel wijzigt, kan het resultaat niet aan offload toeschrijven. Herstel de instelling daarna.

ethtool -K eth0 tso off gro off
ping -M do -s 1400 example.com

Een echte stagnatie bij een grote overdracht is een aparte vraag over de pad-MTU en de terugkoppeling die de toepassing krijgt. Een geaggregeerde eenheid van een host bewijst noch weerlegt een groottelimiet verderop, en een laag CPU-percentage wijst offload niet als oorzaak aan.

Het nuttige resultaat is een verklaard opnamepunt plus een reproduceerbare observatie van de toepassing. Met die twee gescheiden kan een MTU-wijziging een echte beperking aanpakken in plaats van de vorm van een interne buffer.