tcpdump показва пакети от 64 KB: offload и точка на прихващане

Прихващане на хост може да покаже пакет от 64 KB на интерфейс с MTU 1420, а очевидният извод е, че тунелът е игнорирал ограничението си за размер. Този извод обикновено е грешен. Точките на прихващане на хоста са вътре в пътя на обработка, където сегментирането, агрегирането и работата с контролната сума може още да не са се случили. Прочетете позицията на наблюдателя, преди да четете размера на пакета.

Където прихващате, променя какво виждате

Предавателният offload позволява на стека да предаде голяма единица на мрежовото устройство, което по-късно я нарязва на парчета с размер за кабела. Агрегирането при приемане прави обратното по пътя на входа, съединявайки сегменти, преди наблюдател от страната на хоста да ги види. Затова прихващането записва вътрешния изглед на хоста в тази точка, а не непременно кадрите по връзката. И двата механизма зависят от устройството и пътя.

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

Прихванете във втора точка, в идеалния случай независим приемник или огледало, преди да приемете размера за дефект. Ако голямата единица се появява само на изпращащия хост, кабелът може никога да не я е пренасял. Две точки на наблюдение са по-силни от един файл, особено когато въпросът е какво действително е напуснало машината.

Разделете вътрешния и външния интерфейс

Тунелът добавя свой собствен интерфейс, и външният и вътрешният изглед се различават по инкапсулация и по обработка. Прихващането на устройството на тунела показва вътрешния пакет; прихващането на физическия адаптер показва външния. Размерът, адресите и състоянието на контролната сума могат да се различават между тях по причини, които нямат нищо общо с дефект.

Записвайте кой интерфейс е създал всеки файл. Размер, видян на устройството на тунела, описва вътрешния пакет, а не кадъра, който адаптерът в крайна сметка е изпратил. Смесването им в един анализ е начинът, по който нормална разлика в инкапсулацията се превръща в мистерия.

Предупреждението за контролна сума също е позиционно

Прихващане от страната на предаването може да покаже поле за контролна сума, преди хардуерът да го попълни, което създава предупреждение, което никой приемник не би видял. Това са различни доказателства от отхвърлянето на повреден пакет от отдалечен хост. Посоката и точката на прихващане решават кое от двете имате.

Когато реално предаване се провали, сравнете наблюденията при приемник или в друга точка от пътя. Пазете посоката, интерфейса и слоя на инкапсулация заедно със записа, защото екранна снимка без тях не може да бъде тълкувана по-късно.

Изключвайте offload само като контролиран тест

Изключването на offload променя производителността и обработката на пакети, така че не е първата реакция на странно показване на размер. Ако го тествате, променете една настройка и първо запишете базовото състояние. Пуск, който също променя MTU, правилата на защитната стена и профила на клиента, не може да отдаде резултата на offload. Възстановете настройката след това.

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

Истинско задържане при голямо предаване е отделен въпрос за MTU на пътя и обратната връзка, която приложението получава. Агрегираната единица на хоста нито доказва, нито опровергава ограничение за размер по-надолу по пътя, а нисък процент на CPU не идентифицира offload като причина.

Полезният резултат е обяснена точка на прихващане плюс възпроизводимо наблюдение на приложението. Когато те са разделени, промяна на MTU може да насочи към реално ограничение, вместо към формата на вътрешен буфер.