A tcpdump 64 KB-os csomagokat mutat: offload és rögzítési pont

Egy gazdagépen végzett rögzítés 64 KB-os csomagot mutathat egy 1420-as MTU-jú interfészen, és a kézenfekvő következtetés az, hogy az alagút figyelmen kívül hagyta a mérethatárát. Ez a következtetés általában téves. A gazdagépen lévő rögzítési pontok a feldolgozási útvonalon belül vannak, ahol a szegmentálás, az aggregálás és az ellenőrzőösszeg-munka még nem feltétlenül történt meg. A csomagméret olvasása előtt olvassa el a megfigyelő helyzetét.

A rögzítés helye megváltoztatja, mit lát

A küldési offload lehetővé teszi, hogy a verem egy nagy egységet adjon át a hálózati eszköznek, amely később drótméretű darabokra vágja. A fogadási aggregálás a bejövő úton az ellenkezőjét teszi, és összevonja a szegmenseket, mielőtt a gazdagép oldali megfigyelő látná őket. A rögzítés ezért a gazdagép belső nézetét rögzíti az adott ponton, nem feltétlenül a kapcsolat kereteit. Mindkét mechanizmus az eszköztől és az útvonaltól függ.

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

Rögzítsen egy második ponton, ideális esetben független vevőn vagy tükörön, mielőtt a méretet hibának tekinti. Ha a nagy egység csak a küldő gazdagépen jelenik meg, előfordulhat, hogy a drót soha nem vitte. Két megfigyelési pont erősebb egyetlen fájlnál, különösen amikor a kérdés az, mi hagyta el valóban a gépet.

Válassza szét a belső és a külső interfészt

Az alagút saját interfészt ad hozzá, és a külső és a belső nézet eltér a beágyazásban és a feldolgozásban. Az alagút eszközén végzett rögzítés a belső csomagot mutatja; a fizikai adapteren végzett rögzítés a külsőt. A méret, a címek és az ellenőrzőösszeg állapota eltérhet közöttük olyan okokból, amelyeknek semmi közük a hibához.

Jegyezze fel, melyik interfész állította elő az egyes fájlokat. Az alagút eszközén látott méret a belső csomagot írja le, nem azt a keretet, amelyet az adapter végül elküldött. Ezek összekeverése egyetlen elemzésben az, ahogy egy normál beágyazási különbség rejtéllyé válik.

Az ellenőrzőösszeg-figyelmeztetés is pozicionális

A küldési oldalon végzett rögzítés mutathatja az ellenőrzőösszeg mezőt, mielőtt a hardver kitöltené, ami olyan figyelmeztetést eredményez, amelyet egyetlen vevő sem látna soha. Ez más bizonyíték, mint amikor egy távoli gazdagép elutasít egy sérült csomagot. Az irány és a rögzítési pont dönti el, melyikük van Önnél.

Amikor egy tényleges átvitel meghiúsul, hasonlítsa össze a megfigyeléseket egy vevőnél vagy az útvonal egy másik pontján. Tartsa a rekord mellett az irányt, az interfészt és a beágyazási réteget, mert ezek nélkül egy képernyőkép később nem értelmezhető.

Az offloadot csak ellenőrzött tesztként kapcsolja ki

Az offload kikapcsolása megváltoztatja a teljesítményt és a csomagfeldolgozást, ezért nem ez az első válasz egy furcsa méretmegjelenítésre. Ha teszteli, változtasson meg egy beállítást, és először rögzítse a kiindulási állapotot. Egy olyan futás, amely az MTU-t, a tűzfal-szabályokat és az ügyfélprofilt is módosítja, nem tulajdoníthatja az eredményt az offloadnak. Utána állítsa vissza a beállítást.

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

Egy valódi nagy átviteli elakadás külön kérdés a hálózati útvonal MTU-járól és arról a visszajelzésről, amelyet az alkalmazás kap. A gazdagép aggregált egysége sem nem bizonyít, sem nem cáfol egy további mérethatárt, és az alacsony CPU-arány nem azonosítja az offloadot okként.

A hasznos eredmény egy megmagyarázott rögzítési pont és egy megismételhető alkalmazásmegfigyelés. Ha ezeket szétválasztjuk, az MTU módosítása valódi korlátot célozhat a belső puffer alakja helyett.