tcpdump pokazuje pakiety 64 KB: offload i punkt przechwytywania

Przechwytywanie na hoście może pokazać pakiet 64 KB na interfejsie o MTU 1420, a oczywisty wniosek jest taki, że tunel zignorował swój limit rozmiaru. Ten wniosek jest zwykle błędny. Punkty przechwytywania na hoście znajdują się wewnątrz ścieżki przetwarzania, gdzie segmentacja, agregacja i praca sumy kontrolnej mogą jeszcze nie mieć miejsca. Przeczytaj położenie obserwatora, zanim przeczytasz rozmiar pakietu.

Gdzie przechwytujesz, zmienia to, co widzisz

Offload transmisji pozwala stosowi przekazać dużą jednostkę urządzeniu sieciowemu, które później tnie ją na kawałki rozmiaru przewodu. Agregacja odbioru robi odwrotnie na wejściu i łączy segmenty, zanim obserwator po stronie hosta je zobaczy. Przechwycenie zapisuje więc wewnętrzny obraz hosta w tym punkcie, a niekoniecznie ramki na łączu. Oba mechanizmy zależą od urządzenia i ścieżki.

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

Przechwyć w drugim punkcie, najlepiej na niezależnym odbiorniku lub lustrze, zanim uznasz rozmiar za usterkę. Jeśli duża jednostka pojawia się tylko na hoście wysyłającym, przewód może nigdy jej nie przeniósł. Dwa punkty obserwacji są silniejsze niż jeden plik, zwłaszcza gdy pytanie brzmi, co naprawdę opuściło maszynę.

Oddziel interfejs wewnętrzny od zewnętrznego

Tunel dodaje własny interfejs, a widok zewnętrzny i wewnętrzny różnią się enkapsulacją i przetwarzaniem. Przechwycenie na urządzeniu tunelu pokazuje pakiet wewnętrzny; przechwycenie na karcie fizycznej pokazuje zewnętrzny. Rozmiar, adresy i stan sumy kontrolnej mogą się między nimi różnić z powodów niemających nic wspólnego z usterką.

Zapisz, który interfejs utworzył każdy plik. Rozmiar widziany na urządzeniu tunelu opisuje pakiet wewnętrzny, a nie ramkę, którą karta ostatecznie wysłała. Mieszanie ich w jednej analizie to sposób, w jaki zwykła różnica enkapsulacji staje się zagadką.

Ostrzeżenie o sumie kontrolnej też jest pozycyjne

Przechwycenie po stronie wysyłania może pokazać pole sumy kontrolnej, zanim wypełni je sprzęt, co daje ostrzeżenie, którego żaden odbiornik nigdy by nie zobaczył. To inny dowód niż odrzucenie uszkodzonego pakietu przez zdalny host. Kierunek i punkt przechwytywania decydują, który z dwóch masz.

Gdy rzeczywiste przesyłanie zawiedzie, porównaj obserwacje u odbiorcy lub w innym punkcie ścieżki. Zachowaj kierunek, interfejs i warstwę enkapsulacji wraz z zapisem, bo zrzut ekranu bez nich nie da się później zinterpretować.

Wyłączaj offload tylko jako kontrolowany test

Wyłączenie offloadu zmienia wydajność i przetwarzanie pakietów, więc nie jest pierwszą reakcją na dziwny wyświetlany rozmiar. Jeśli testujesz, zmień jedno ustawienie i najpierw zapisz stan wyjściowy. Uruchomienie, które zmienia też MTU, reguły zapory i profil klienta, nie może przypisać wyniku offloadowi. Potem przywróć ustawienie.

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

Prawdziwe zatrzymanie dużego przesyłania to osobne pytanie o MTU ścieżki i informację zwrotną, którą otrzymuje aplikacja. Zagregowana jednostka hosta ani nie dowodzi, ani nie zaprzecza limitowi rozmiaru dalej, a niski procent CPU nie wskazuje offloadu jako przyczyny.

Pożytecznym wynikiem jest wyjaśniony punkt przechwytywania plus powtarzalna obserwacja aplikacji. Gdy te dwie rzeczy są rozdzielone, zmiana MTU może trafić w rzeczywiste ograniczenie zamiast w kształt wewnętrznego bufora.