tcpdump viser 64 KB-pakkar: offload og opptakspunkt

Eit opptak på ein vert kan vise ein pakke på 64 KB på eit grensesnitt med MTU 1420, og den openberre konklusjonen er at tunnelen ignorerte storleiksgrensa si. Den konklusjonen er som regel feil. Opptakspunkt på verten ligg inne i handsamingsbanen, der segmentering, aggregering og kontrollsumarbeid kanskje enno ikkje har skjedd. Les posisjonen til observatøren før du les pakkestorleiken.

Kvar du tar opp, endrar kva du ser

Send-offload lèt stakken overlevere ei stor eining til nettverksininga, som seinare skjer ho i bitar på leidningsstorleik. Mottaksaggregering gjer det motsette på veg inn og slår saman segment før ein observatør på vertssida ser dei. Eit opptak registrerer difor det interne bildet av verten på det punktet, ikkje nødvendigvis rammene på lenkja. Begge mekanismane er avhengige av eininga og banen.

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

Ta opp på eit andre punkt, ideelt ein uavhengig mottakar eller eit spegel, før du handsamar storleiken som ein feil. Viss den store eininga berre dukkar opp på den sendande verten, har leidningen kanskje aldri bore ho. To observasjonspunkt er sterkare enn éi fil, særleg når spørsmålet er kva som faktisk forlét maskinen.

Skil det indre og det ytre grensesnittet

Ein tunnel legg til sitt eige grensesnitt, og det ytre og det indre bildet skil seg i innkapsling og i handsaming. Eit opptak på tunneleininga viser den indre pakken; eit opptak på den fysiske adapteren viser den ytre. Storleik, adresser og kontrollsumtilstand kan avvike mellom dei av grunnar som ikkje har noko med ein feil å gjere.

Noter kva grensesnitt som produserte kvar fil. Ein storleik sett på tunneleininga skildrar den indre pakken, ikkje ramma adapteren til slutt sende. Å blande dei i éi analyse er korleis ein normal innkapslingsskilnad blir eit mysterium.

Ei kontrollsumåtvaring er også posisjonell

Eit opptak på sendesida kan vise eit kontrollsumfelt før maskinvara fyller det ut, noko som gjev ei åtvaring som ingen mottakar nokon gong ville sjå. Det er ei anna form for prov enn ein ekstern vert som avviser ein skadd pakke. Retninga og opptakspunktet avgjer kva av dei to du har.

Når ein faktisk overføring mislukkast, samanlikn observasjonar hos ein mottakar eller på eit anna punkt i banen. Ta vare på retning, grensesnitt og innkapslingslag saman med opptaket, for eit skjermbilde utan dei kan ikkje tolkast seinare.

Slå av offload berre som ein kontrollert test

Å slå av offload endrar yting og pakkehandsaming, så det er ikkje den første responsen på ei merkeleg storleiksvisning. Viss du testar det, endre éi innstilling og noter utgangspunktet først. Ein køyring som også endrar MTU, brannmurreglar og klientprofilen kan ikkje tilskrive resultatet offload. Gjenopprett innstillinga etterpå.

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

Ein reell stopp i ei stor overføring er eit eige spørsmål om MTU-en til banen og tilbakemeldinga applikasjonen får. Ei aggregert eining på verten korkje provar eller motprovar ei storleiksgrense lenger nede, og ein låg CPU-del identifiserer ikkje offload som årsak.

Det nyttige resultatet er eit forklart opptakspunkt pluss ein reproduserbar applikasjonsobservasjon. Når dei er skilde, kan ei MTU-endring treffe ei reell avgrensing i staden for forma på ein intern buffer.