tcpdump показывает пакеты 64 КБ: offload и точка захвата

Захват на хосте может показать пакет размером 64 КБ на интерфейсе с 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 может нацелиться на реальное ограничение, а не на форму внутреннего буфера.