tcpdump viser 64 KB-pakker: offload og opptakspunkt

Et opptak på en vert kan vise en pakke på 64 KB på et grensesnitt med MTU 1420, og den åpenbare konklusjonen er at tunnelen ignorerte størrelsesgrensen sin. Den konklusjonen er som regel feil. Opptakspunkter på verten ligger inne i behandlingsbanen, der segmentering, aggregering og kontrollsumarbeid kanskje ennå ikke har skjedd. Les observatørens posisjon før du leser pakkestørrelsen.

Hvor du tar opp, endrer hva du ser

Send-offload lar stakken overlevere en stor enhet til nettverksenheten, som senere skjærer den i biter på ledningsstørrelse. Mottaksaggregering gjør det motsatte på vei inn og slår sammen segmenter før en observatør på vertssiden ser dem. Et opptak registrerer derfor vertens interne bilde på det punktet, ikke nødvendigvis rammene på lenken. Begge mekanismene avhenger av enheten og banen.

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

Ta opp på et andre punkt, ideelt en uavhengig mottaker eller et speil, før du behandler størrelsen som en feil. Hvis den store enheten bare vises på den sendende verten, har ledningen kanskje aldri båret den. To observasjonspunkter er sterkere enn én fil, særlig når spørsmålet er hva som faktisk forlot maskinen.

Skill det indre og det ytre grensesnittet

En tunnel legger til sitt eget grensesnitt, og det ytre og det indre bildet er forskjellige i innkapsling og i behandling. Et opptak på tunnelenheten viser den indre pakken; et opptak på den fysiske adapteren viser den ytre. Størrelse, adresser og kontrollsumtilstand kan avvike mellom dem av grunner som ikke har noe med en feil å gjøre.

Noter hvilket grensesnitt som produserte hver fil. En størrelse sett på tunnelenheten beskriver den indre pakken, ikke rammen adapteren til slutt sendte. Å blande dem i én analyse er hvordan en normal innkapslingsforskjell blir til et mysterium.

En kontrollsumadvarsel er også posisjonell

Et opptak på sendesiden kan vise et kontrollsumfelt før maskinvaren fyller det ut, noe som gir en advarsel som ingen mottaker noen gang ville se. Det er en annen type bevis enn en ekstern vert som avviser en skadet pakke. Retningen og opptakspunktet avgjør hvilken av de to du har.

Når en faktisk overføring mislykkes, sammenlign observasjoner hos en mottaker eller på et annet punkt i banen. Ta vare på retning, grensesnitt og innkapslingslag sammen med opptaket, for et skjermbilde uten dem kan ikke tolkes senere.

Slå av offload bare som en kontrollert test

Å slå av offload endrer ytelse og pakkebehandling, så det er ikke den første responsen på en merkelig størrelsesvisning. Hvis du tester det, endre én innstilling og noter utgangspunktet først. En kjøring som også endrer MTU, brannmurregler og klientprofilen kan ikke tilskrive resultatet offload. Gjenopprett innstillingen etterpå.

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

En reell stopp i en stor overføring er et eget spørsmål om banens MTU og tilbakemeldingen applikasjonen får. En aggregert enhet på verten verken beviser eller motbeviser en størrelsesgrense lenger ned, og en lav CPU-andel identifiserer ikke offload som årsak.

Det nyttige resultatet er et forklart opptakspunkt pluss en reproduserbar applikasjonsobservasjon. Når de er skilt, kan en MTU-endring treffe en reell begrensning i stedet for formen på en intern buffer.