tcp checksum offload что это

Tcp checksum offload что это

Столкнулся с такой проблемой, после установки системы и пересборки ядра, перестала в полной мере работать сеть. Система стартует, сетевой интерфейс инициализируется без ошибок, пингуются различные узлы Internet, работает ICQ, но ни WWW, ни FTP не работает. Браузер в строке состояния пишет «Узел найден ожидается ответ» или что-то в этом роде и ВСЁ! Wireshark показал, что с МОЕГО хоста отправляются неправильные пакеты, как UDP, так и TCP. В общем на запросе «GET HTTP 1/1» снифер показывает ошибку «Checksum: 0xf59e [incorrect, should be 0xc500 (maybe caused by «TCP checksum offload»?)]», после чего генерятся пакеты c флагами F и P и соединение зависает. Как бороться с этой хренью. Из ядра повыкидывал всё, оставил только сетевую поддержку и поддержку TCP/IP, избавился там от всяких айписеков, нетфильтров, маршрутизации и т. д.

Система: Gentoo 2007.0
Kernel: 2.6.20-r8
NIC: D-Link 10/100 на чипе RTL8139

Заранее благодарен за помощ.

>пингуются различные узлы Internet, работает ICQ, но ни WWW, ни FTP
>не работает.
>Браузер в строке состояния пишет «Узел найден ожидается ответ»
DNS значит тоже работает ))

Это часто бывает когда большие пакеты(MTU 1500) не пролазят. Входящие, исходящие, или все. Проиходит это обычно из-за дешёвой платы воткнутой в VLAN или pppoe/pptp

а было больше или меньше? у меня аналогичная проблема на сусе 🙁

последнее значение было гораздо больше (сколько не помню), установил именно эти значения.

>снифер показывает ошибку «Checksum: 0xf59e
>[incorrect, should be 0xc500 (maybe caused by «TCP checksum offload»?)]»,

Источник

Hardware Only (HO) features and technologies

Applies to: Windows Server 2022, Windows Server 2019, Azure Stack HCI, versions 21H2 and 20H2

These hardware accelerations improve networking performance in conjunction with the software but are not intimately part of any software feature. Examples of these include Interrupt Moderation, Flow Control, and Receive-side IPv4 Checksum Offload. To learn more, see Host network requirements for Azure Stack HCI.

SH and HO features are available if the installed NIC supports it. The feature descriptions below will cover how to tell if your NIC supports the feature.

Address Checksum Offload

Address checksum offloads are a NIC feature that offloads the calculation of address checksums (IP, TCP, UDP) to the NIC hardware for both send and receive.

On the receive path, the checksum offload calculates the checksums in the IP, TCP, and UDP headers (as appropriate) and indicates to the OS whether the checksums passed, failed, or not checked. If the NIC asserts that the checksums are valid, the OS accepts the packet unchallenged. If the NIC asserts the checksums are invalid or not checked, the IP/TCP/UDP stack internally calculates the checksums again. If the computed checksum fails, the packet gets discarded.

On the send path, the checksum offload calculates and inserts the checksums into the IP, TCP, or UDP header as appropriate.

Disabling checksum offloads on the send path does not disable checksum calculation and insertion for packets sent to the miniport driver using the Large Send Offload (LSO) feature.В To disable all checksum offload calculations, the user must also disable LSO.

Manage Address Checksum Offloads

In the Advanced Properties there are several distinct properties:

IPv4 Checksum Offload

TCP Checksum Offload (IPv4)

TCP Checksum Offload (IPv6)

UDP Checksum Offload (IPv4)

UDP Checksum Offload (IPv6)

By default, these are all always enabled. We recommend always enabling all of these offloads.

The Checksum Offloads can be managed using the Enable-NetAdapterChecksumOffload and Disable-NetAdapterChecksumOffload cmdlets. For example, the following cmdlet enables the TCP (IPv4) and UDP (IPv4) checksum calculations:

Tips on using Address Checksum Offloads

Address Checksum Offloads should ALWAYS be enabled no matter what workload or circumstance. This most basic of all offload technologies always improve your network performance. Checksum offloading is also required for other stateless offloads to work including receive side scaling (RSS), receive segment coalescing (RSC), and large send offload (LSO).

Interrupt Moderation (IM)

IM buffers multiple received packets before interrupting the operating system. When a NIC receives a packet, it starts a timer. When the buffer is full, or the timer expires, whichever comes first, the NIC interrupts the operating system.

Many NICs support more than just on/off for Interrupt Moderation. Most NICs support the concepts of a low, medium, and high rate for IM. The different rates represent shorter or longer timers and appropriate buffer size adjustments to reduce latency (low interrupt moderation) or reduce interrupts (high interrupt moderation).

There is a balance to be struck between reducing interrupts and excessively delaying packet delivery. Generally, packet processing is more efficient with Interrupt Moderation enabled. High performance or low latency applications may need to evaluate the impact of disabling or reducing Interrupt Moderation.

Jumbo frames

Jumbo frames is a NIC and network feature that allows an application to send frames that are much larger than the default 1500 bytes. Typically the limit on jumbo frames is about 9000 bytes but may be smaller.

There were no changes to jumbo frame support in Windows Server 2012 R2.

In Windows Server 2016 there is a new offload: MTU_for_HNV. This new offload works with Jumbo Frame settings to ensure encapsulated traffic doesn’t require segmentation between the host and the adjacent switch. This new feature of the SDN stack has the NIC automatically calculate what MTU to advertise and what MTU to use on the wire. These values for MTU are different if any HNV offload is in use. (In the feature compatibility table, Table 1, MTU_for_HNV would have the same interactions as the HNVv2 offloads have since it is directly related to the HNVv2 offloads.)

Large Send Offload (LSO)

LSO allows an application to pass a large block of data to the NIC, and the NIC breaks the data into packets that fit within the Maximum Transfer Unit (MTU) of the network.

Receive Segment Coalescing (RSC)

Receive Segment Coalescing, also known as Large Receive Offload, is a NIC feature that takes packets that are part of the same stream that arrives between network interrupts and coalesces them into a single packet before delivering them to the operating system. RSC is not available on NICs that are bound to the Hyper-V Virtual Switch. For more information, see Receive Segment Coalescing (RSC).

Источник

Как настроить сетевой адаптер на Windows 7: самое важное

Иногда при подключении интернета или использовании ресурсов локальной сети возникают проблемы. Могут вылезать ошибки подключения, получения IP адресов или конфигурации сетевого оборудования. Внутри компьютера или ноутбука, функцией подключения к локальной или глобальной сети, занимается сетевой адаптер. В статье мы как раз и поговорим про настройку сетевого адаптера для улучшения связи в интернете. Инструкция будет ходовая для всех версий Windows 7, 8 и 10.

Более подробная настройка

Мне постоянно приходят письма с вопросами – как более детально настроить сетевой адаптер для меньшего пинга в играх, для лучшего просмотра кино и большей скорости скачивания. Поэтому я решил написать более детальную статью. Ну, поехали! По идее она настраивается автоматически под рациональное использование ресурсов системы и самого устройства. Но конфигурацию можно корректировать под свои нужды.

Переходим во вкладку «Дополнительно». И так смотрите, у нас есть определённые свойства, которые мы можем включать (Enebled) или выключать (Disable). На новых версиях «Виндовс» может быть написано «Вкл» или «Выкл». А теперь разбёрем каждое свойство:

ВНИМАНИЕ! Параметры адаптера могут в какой-то степени улучшить показатели, в каком-то моменте ухудшить. Изменяя установки сетевого адаптера, лучше возьмите листочек и выпишите – что именно вы изменили, чтобы в случаи чего вернуть параметры обратно. Также я рекомендую скачать последнюю версию драйвера для вашей сетевой карты или Wi-Fi модуля и установить его. Только после этого заходим в характеристики

После изменения, следует перезагрузить компьютер или ноутбук, чтобы некоторые изменения вступили в силу. Установки сетевого адаптера всегда можно откатить обратно, самое главное не потеряйте тот листок с настройками.

ПРОСЬБА! Если я что-то не указал, или написал что-то не так – пишите смело в комментариях свои исправления или замечания, буду рад поучиться чему-то у своих читателей.

Источник

CaptureSetup / Offloading

Offloading

Most modern operating systems support some form of network offloading, where some network processing happens on the NIC instead of the CPU. Normally this is a great thing. It can free up resources on the rest of the system and let it handle more connections. If you’re trying to capture traffic it can result in false errors and strange or even missing traffic.

Checksum Offload

On systems that support checksum offloading, IP, TCP, and UDP checksums are calculated on the NIC just before they’re transmitted on the wire. In Wireshark these show up as outgoing packets marked black with red Text and the note [incorrect, should be xxxx (maybe caused by «TCP checksum offload»?)].

Wireshark captures packets before they are sent to the network adapter. It won’t see the correct checksum because it has not been calculated yet. Even worse, most OSes don’t bother initialize this data so you’re probably seeing little chunks of memory that you shouldn’t.

New installations of Wireshark 1.2 and above disable IP, TCP, and UDP checksum validation by default. You can disable checksum validation in each of those dissectors by hand if needed.

If you are experiencing network problems and while trying to figure it out with Wireshark you found these checksum errors, you may have a network card with TCP checksum offload enabled and for some reason the packet is not being fixed by the adapter (NAT, bridge or route redirection is sending the packet to another interface). In this case, you may want to check and disable checksum offload for the adapter, if possible.

Linux

Checksum offloading can be enabled and disabled with the ethtool command.

Or, with some 3Com cards (see 3c59x vortex docs):

Windows

In Windows, go to Control Panel->Network and Internet Connections->Network Connections, right click the connection to change and choose ‘Properties’. Press the ‘Configure. ‘ button, choose the ‘Advanced’ tab to see or modify the «Offload Transmit TCP Checksum» and «Offload Receive TCP Checksum» values.

Segmentation Offload

Some cards can reassemble traffic. This will manifest itself in Wireshark as packets that are larger than expected, such as a 2900-byte packet on a network with a 1500-byte MTU. You can check and change offloading behavior on Linux and Windows using the methods described in the previous section.

This article has a nice explanation on what to do.

TCP Chimney

Chimney offloading lets the NIC handle processing for established TCP connections. On Windows offloaded connections bypass WinPcap, which means that you won’t capture TCP conversations.

Оптимизация и offloading сети

Тут мы поговорим о различных техниках и механизмах, призванных оптимизировать или улучшить использование сети виртуальными машинами.

TCP Segmentation Offload (TSO, LSO)

Когда хосту ESXi или виртуальной машине необходимо передать большой пакет данных в сеть, пакет должен быть разбит на более мелкие сегменты, которые могут пройти через все физические коммутаторы и возможные маршрутизаторы в сети на пути к месту назначения пакета. TSO позволяет стеку TCP/IP передавать кадры большего размера, даже до 64 КБ, если максимальный размер передаваемого блока (MTU) интерфейса настроен для меньших кадров. Затем сетевая карта делит большой кадр на кадры размером MTU и добавляет скорректированную копию начальных заголовков TCP / IP. То есть дробление на сегменты происходит средствами NIC, а не CPU, тем самым экономя его ресурсы. Обычно TSO включено по умолчанию на физических сетевых адаптерах. Стоит включить TSO на vNIC внутри гостевой системы, по-другому называется еще Large Send Offload. Так же стоит использовать TCO и на уровне VMKERNEL для нужд гипервизора:

Large Receive Offload (LRO)

Large Receive Offload (LRO) можно рассматривать как функцию, прямо противоположную TSO / LSO. Это метод, который объединяет несколько входящих сетевых пакетов из одного потока в более крупные пакеты и передает полученные в результате более крупные, но меньшее количество пакетов в сетевой стек TCP-стека гостевой ОС хоста или виртуальной машины. Этот процесс приводит к меньшей нагрузке на ЦП, поскольку ЦП имеет меньше пакетов для обработки по сравнению с отключенным LRO. Но эта функция увеличивает задержку сетевых пакетов, так как они находятся некоторое время в буфере NIC. Данная функция противопоказана чувствительным к задержке приложениям и системам. Как и в случае с TSO / LSO, чтобы полностью использовать функциональность LRO, она должна быть включена на всем пути данных, то есть на физическом адаптере, ESXi хосте и на vNIC. Узнаем включена ли она в ESXi:

Так же можно корректировать размер буфера с помощь настройки:

(максимально 65535 байт или 64 KB)

Уменьшение размера буфера может уменьшить сетевые задержки. Функция LRO работает для гостевых систем только на VMXNET3 адаптере и может быть включена настройкой Receive Side Coalescing (RSC).

TCP Checksum Offloading (TCO)

Checksum Offload (CSO) or TCP Checksum Offloading (TCO). Проверка 16-ти битного заголовка у сетевого пакета выполняется на NIC вместо CPU, тем самым разгружая последний. Бывает RX и TX разгрузка. В зависимости от потока трафика, возможностей CSO и конфигурации всех задействованных компонентов расчет контрольной суммы будет выполняться на разных уровнях в цепочке связи. Компонент может быть гостевой ОС, vNIC или pNIC. Например, если виртуальная машина взаимодействует с другой виртуальной машиной на другом хосте ESXi, вычисление контрольной суммы передачи (Tx) выполняется как на pNIC, так и на vNIC, при условии, что у обоих включен CSO. Если CSO не включен на vNIC, расчет контрольной суммы всегда будет выполняться гостевой ОС. Однако, если у pNIC отключен CSO, но он включен на vNIC, вычисление контрольной суммы будет выполнено в ядре виртуальной машины. Контрольная сумма приема (Rx) в идеале будет обрабатываться pNIC на хосте ESXi, где находится принимающая виртуальная машина, если она включена. Поскольку это освободит циклы центрального процессора ESXi, имеет смысл всегда включать CSO на pNIC, если он поддерживается.

Receive Side Scaling

Или RSS, если кратко. RSS имеет те же базовые функции, что и (Dynamic) NetQueue, оно обеспечивает балансировку нагрузки при обработке полученных сетевых пакетов. RSS устраняет узкое место в одном потоке, позволяя получать сетевые пакеты от pNIC совместно с несколькими ядрами ЦП. Если простыми словами, то, входящий траффик в сетевой интерфейс по умолчанию обрабатывается одним потоком (Netpoll), который конечно может исполняться в пределах только одного ядра CPU и соответственно ограничен его ресурсами, что влечет за собой падение производительности NIC при большом объеме траффика и, если сам NIС имеет большую пропускную способность, например, 40GE. Настраивается RRS в драйвере NIC ESXi хоста. И чтобы иметь полную выгоду от RSS, стоит настроить его на всем пути следования сетевого траффика в ESXi, то есть и в гостевой системе тоже. RSS доступен на VMXNET3 и HW не ниже 7 версии.

Netpoll Thread Scaling

Какждый физический NIC (pNIC) экипирован по умолчанию одним процессом Netpoll. Процесс Netpoll занимается приемом входящего в pNIC траффика или I/O и «пропихиванием» его в виртуальную машину. По умолчанию такой процесс один для каждого pNIC, но использование таких функций как NetQueue или RSS увеличивает количество Netpoll процессов, для каждой очереди свой Netpoll процесс, что положительно сказывается на пропускной способности сетевой подсистемы ESXi и сетевых задержках.

NetWorld Thread Scaling

По умолчанию каждая виртуальная машина оснащена только одним потоком Tx (NetWorld-VM-XXX). Поскольку сетевые пакеты передаются от виртуальной машины к уровню pNIC через VMkernel, ESXi потребляет циклы ЦП. Эти циклы или время ЦП также будут учитываться самой виртуальной машиной, но не будут учтены как %SYS. Опять же, по умолчанию запускается только один поток Tx. Это коррелирует с одним ядром процессора. Вот почему NetWorld не превысит 100%%USED. Для улучшения этой ситуации существует настройка ethernetX.ctxPerDev. Возможно выставить количество NetWorld процессов для каждого vNIC (Не для машины целиком, а для vNIC). Можно добавить для каждого vNIC свой собственный поток или же добавить на каждый vNIC несколько потоков.

SplitRx Mode

SplitRx Mode — это технология, которая позволяет виртуальной машине использовать несколько ядер ЦП для обработки входящих сетевых пакетов, которые обрабатываются одной очередью. Возможность использовать несколько ядер ЦП позволяет виртуальной машине потреблять больше процессорного времени и, тем самым, значительно улучшать производительность входящей сети. Однако улучшение SplitRx Mode потенциально применимо только к определенным рабочим нагрузкам. Он в основном используется в сценариях, связанных с многоадресным сетевым трафиком, как в примере с несколькими виртуальными машинами, которые работают на одном хосте ESXi и все получают многоадресный трафик из одного источника.

Режим SplitRx был представлен в ESXi 5.0 и включен по умолчанию для требуемого виртуального сетевого адаптера VMXNET3, начиная с ESXi 5.1. Он сработает автоматически, когда ESXi обнаружит, что одна сетевая очередь на pNIC чрезмерно загружена и обрабатывает более 10 000 широковещательных или многоадресных пакетов в секунду (PPS).

У вас есть свобода выбора отключить режим SplitRx для всего хоста ESXi. Вы можете сделать это, настроив следующие расширенные настройки на уровне хоста ESXi; NetSplitRxMode = «0»

Если рабочая нагрузка может выиграть от режима SplitRx, его можно включить для определенных виртуальных сетевых адаптеров внутри виртуальной машины, даже если параметр хоста ESXi для использования режима SplitRx отключен. Все, что вам нужно сделать, это добавить расширенный параметр в конфигурацию виртуальной машины, который включит режим SplitRx для определенного vNIC:

«X» обозначает виртуальный сетевой адаптер. Помните, что этот параметр не вступит в силу до перезапуска виртуальной машины или повторного подключения vNIC.

SplitTx Mode

Режим SplitTx позволяет создать два отдельных потока для одного потока для распараллеливания обработки vNIC и физического NIC:

Режим SplitTx должен быть включен для каждого хоста с помощью следующей команды хоста:

Использование двух потоков значительно увеличивает скорость прохождения трафика через уровень ядра.

Сравнительная таблица

Функция	Влияние на задержки	Влияние на CPU	Уровни настроки	Требуемый vNIC
TSO/LSO	—	Уменьшение нагрузки	pNIC, ESXi, vNIC	VMXNET3
LRO	увеличивает	Уменьшение нагрузки	pNIC, ESXi, vNIC	VMXNET3
TCO	—	Уменьшение нагрузки	pNIC, ESXi, vNIC	VMXNET3
RSS	уменьшает	Увеличение нагрузки	pNIC, ESXi, vNIC
Netpoll scaling	уменьшает	Увеличение нагрузки	pNIC, ESXi (NetQueue или RSS)
NetWorld scaling	уменьшает	Увеличение нагрузки	ESXi
SplitRX	Уменьшает (если много мультикаста/броадкаста)	Увеличение нагрузки	vNIC	VMXNET3

Таблица заполнялась на основе Host Resources Deep Dive.

Об авторе

Какой то инженер по виртуализации. В данном контексте это не особо важно. Вы же не за этим сюда пришли, верно?

Источник

tcp checksum offload что это