tcpdump visar 64 KB-paket: offload och fångstpunkt

En fångst på en värd kan visa ett paket på 64 KB på ett gränssnitt med MTU 1420, och den uppenbara slutsatsen är att tunneln ignorerade sin storleksgräns. Den slutsatsen är oftast fel. Fångstpunkter på värden ligger inne i bearbetningsvägen, där segmentering, aggregering och kontrollsummearbete kanske ännu inte har skett. Läs observatörens position innan du läser paketets storlek.

Var du fångar ändrar vad du ser

Sändnings-offload låter stacken lämna över en stor enhet till nätverksenheten, som senare skär den i bitar av trådstorlek. Mottagningsaggregering gör det motsatta på vägen in och slår ihop segment innan en observatör på värdsidan ser dem. En fångst registrerar därför värdens interna bild vid den punkten, inte nödvändigtvis ramarna på länken. Båda mekanismerna beror på enheten och vägen.

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

Fånga på en andra punkt, helst en oberoende mottagare eller en spegel, innan du behandlar storleken som ett fel. Om den stora enheten bara visas på den sändande värden har länken kanske aldrig burit den. Två observationspunkter är starkare än en enda fil, särskilt när frågan är vad som faktiskt lämnade maskinen.

Skilj på det inre och det yttre gränssnittet

En tunnel lägger till sitt eget gränssnitt, och den yttre och den inre bilden skiljer sig i inkapsling och i bearbetning. En fångst på tunnelenheten visar det inre paketet; en fångst på det fysiska adaptern visar det yttre. Storlek, adresser och kontrollsummetillstånd kan skilja sig mellan dem av skäl som inte har något med ett fel att göra.

Notera vilket gränssnitt som producerade varje fil. En storlek som ses på tunnelenheten beskriver det inre paketet, inte ramen som adaptern till slut skickade. Att blanda dem i en analys är hur en normal inkapslingsskillnad blir ett mysterium.

En kontrollsummevarning är också positionell

En fångst på sändningssidan kan visa ett kontrollsummefält innan hårdvaran fyller i det, vilket ger en varning som ingen mottagare någonsin skulle se. Det är ett annat slags bevis än en fjärrvärd som avvisar ett skadat paket. Riktningen och fångstpunkten avgör vilken av de två du har.

När en faktisk överföring misslyckas, jämför observationer hos en mottagare eller på en annan punkt i vägen. Behåll riktning, gränssnitt och inkapslingslager tillsammans med fångsten, för en skärmbild utan dem kan inte tolkas senare.

Stäng bara av offload som ett kontrollerat test

Att stänga av offload ändrar prestanda och paketbearbetning, så det är inte den första reaktionen på en märklig storleksvisning. Om du testar det, ändra en inställning och anteckna utgångsläget först. En körning som också ändrar MTU, brandväggsregler och klientprofilen kan inte tillskriva resultatet offload. Återställ inställningen efteråt.

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

Ett verkligt stopp i en stor överföring är en separat fråga om banans MTU och den återkoppling som programmet får. En aggregerad enhet på värden varken bevisar eller motbevisar en storleksgräns längre fram, och en låg CPU-andel identifierar inte offload som orsak.

Det användbara resultatet är en förklarad fångstpunkt plus en reproducerbar programobservation. När dessa är åtskilda kan en MTU-ändring träffa en verklig begränsning i stället för formen på en intern buffert.