tcpdump viser 64 KB-pakker: offload og opsamlingspunkt

Optagelse på en vært kan vise en pakke på 64 KB på et interface med MTU 1420, og den oplagte konklusion er, at tunnelen ignorerede sin størrelsesgrænse. Den konklusion er som regel forkert. Optagelsespunkter på værten ligger inde i behandlingsvejen, hvor segmentering, aggregering og checksum-arbejde måske endnu ikke er sket. Læs observatørens placering, før du læser pakkestørrelsen.

Hvor du optager, ændrer hvad du ser

Transmit offload lader stakken overlevere en stor enhed til netværksenheden, som senere skærer den i stykker på ledningsstørrelse. Modtageaggregering gør det modsatte på vej ind og samler segmenter, før en observatør på værtsiden ser dem. En optagelse registrerer derfor værtens interne billede på det punkt, ikke nødvendigvis rammerne på linket. Begge mekanismer afhænger af enheden og vejen.

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

Optag på et andet punkt, ideelt en uafhængig modtager eller et spejl, før du behandler størrelsen som en fejl. Hvis den store enhed kun vises på afsenderværten, har ledningen måske aldrig båret den. To observationspunkter er stærkere end én fil, især når spørgsmålet er, hvad der faktisk forlod maskinen.

Adskil det indre og det ydre interface

En tunnel tilføjer sit eget interface, og det ydre og det indre billede adskiller sig i indkapsling og i behandling. En optagelse på tunneleenheden viser den indre pakke; en optagelse på den fysiske adapter viser den ydre. Størrelse, adresser og checksum-tilstand kan afvige mellem dem af grunde, der intet har med en fejl at gøre.

Notér, hvilket interface der producerede hver fil. En størrelse set på tunneleenheden beskriver den indre pakke, ikke den ramme adapteren til sidst sendte. At blande dem i én analyse er, hvordan en normal indkapslingsforskel bliver til et mysterium.

En checksum-advarsel er også positionsbestemt

En optagelse på sendesiden kan vise et checksum-felt, før hardwaren udfylder det, hvilket giver en advarsel, som ingen modtager nogensinde ville se. Det er en anden form for bevis end en fjern vært, der afviser en beskadiget pakke. Retningen og optagelsespunktet afgør, hvilken af de to du har.

Når en faktisk overførsel fejler, sammenlign observationer hos en modtager eller på et andet punkt på vejen. Gem retning, interface og indkapslingslag sammen med optagelsen, for et skærmbillede uden dem kan ikke fortolkes senere.

Slå kun offload fra som en kontrolleret test

At slå offload fra ændrer ydeevne og pakkebehandling, så det er ikke den første reaktion på en mærkelig størrelsesvisning. Hvis du tester det, ændr én indstilling og notér baseline først. Et kør, der også ændrer MTU, firewallregler og klientprofilen, kan ikke tilskrive resultatet offload. Gendan indstillingen bagefter.

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

Et ægte stop i en stor overførsel er et separat spørgsmål om vejens MTU og den feedback, applikationen får. En aggregeret enhed på værten hverken beviser eller modbeviser en størrelsesgrænse længere fremme, og en lav CPU-procent udpeger ikke offload som årsagen.

Det nyttige resultat er et forklaret optagelsespunkt plus en reproducerbar applikationsobservation. Når de er adskilt, kan en MTU-ændring ramme en reel begrænsning i stedet for formen på en intern buffer.