[mlevel]

Хотелось бы прояснить несколько моментов по поводу ipfw kernel nat (libalias в FreeBSD) и аппаратного оффлоадинга TSO/LRO а так же контрольних сумм (RXCSUM, TXCSUM и VLAN_HWCSUM).

Часто в конфигах в Интернете люди отключают всё это вместе на ВСЕХ интерфейсах.

 

Но если верить man 8 ipfw, то:

Due to the architecture of libalias(3), ipfw nat is not compatible withthe TCP segmentation offloading (TSO). Thus, to reliably nat your net-work traffic, please disable TSO on your NICs using ifconfig(8).

 

Значит отключать нужно только TSO и то, насколько я понимаю, только на том интерфейсе, где у нас NAT.

Нигде не сказано что есть проблема с LRO. Или это подразумевается само собой?

 

Так же, в NetworkPerformanceTuning наоборот рекомендуют включать аппаратные чексуммы:

• Ensure RXCSUM, TXCSUM and VLAN_HWCSUM is turned on. It is the easiest thing that can be offloaded without any problems.
• Ensure VLAN_HWFILTER is turned on if you're running vlans. card extracts vlan id and sends resulting mbuf directly to vlan interface

 

В свою очередь в коде (файл ipfw/ip_fw_nat.c) есть такой кусок:

/*

* XXX - Libalias checksum offload 'duct tape':

*

* locally generated packets have only pseudo-header checksum

* calculated and libalias will break it[1], so mark them for

* later fix. Moreover there are cases when libalias modifies

* tcp packet data[2], mark them for later fix too.

*

* [1] libalias was never meant to run in kernel, so it does

* not have any knowledge about checksum offloading, and

* expects a packet with a full internet checksum.

* Unfortunately, packets generated locally will have just the

* pseudo header calculated, and when libalias tries to adjust

* the checksum it will actually compute a wrong value.

*

* [2] when libalias modifies tcp's data content, full TCP

* checksum has to be recomputed: the problem is that

* libalias does not have any idea about checksum offloading.

* To work around this, we do not do checksumming in LibAlias,

* but only mark the packets in th_x2 field. If we receive a

* marked packet, we calculate correct checksum for it

* aware of offloading. Why such a terrible hack instead of

* recalculating checksum for each packet?

* Because the previous checksum was not checked!

* Recalculating checksums for EVERY packet will hide ALL

* transmission errors. Yes, marked packets still suffer from

* this problem. But, sigh, natd(8) has this problem, too.

*

* TODO: -make libalias mbuf aware (so

* it can handle delayed checksum and tso)

*/

Но мне не совсем понятно что точно нужно отключить.

 

Тут например в статье от 2009 года есть такое:

Библиотека libalias, на которой основан ipfw nat, плохо дружит с функциями аппаратного ускорения расчета контрольных сумм и управления потоками, которые доступны на некотроых сетевых адаптерах. Рекомендуется выключать tcp segmentation offloading (TSO), а так же rxcsum на том сетевом адаптере где работает нат (ifconfig em0 -rxcsum -tso).

 

Где же правда?

Edited August 12, 2017 by mlevel

[polmax]

Тоже интересует этот вопрос, с 2009 года уже много воды утекло и драйвера переписаны и версия уже 11.

[mlevel]

Тоже интересует этот вопрос, с 2009 года уже много воды утекло и драйвера переписаны и версия уже 11.

 

Да, но судя по коду libalias остался нетронутым, и проблема именно в нём.

Я просто не хочу отключать всё подряд на сетевой, так как она неплохо справляется и снижает нагрузку на CPU.

[vlad11]

перейдите на pf nat

[Ivan_83]

Где же правда?

В исходниках!

 

Значит отключать нужно только TSO и то, насколько я понимаю, только на том интерфейсе, где у нас NAT. Нигде не сказано что есть проблема с LRO. Или это подразумевается само собой?

LRO, GSO, TSO рекомендуется отключать и в линухе.

Всё потому, что нам нахрен не упёрлась аппаратная дефрагментация пакетов и аппаратная их фрагментация обратно.

В цитате из исходника всё вполне расжёвано: есть проблема с тем, как либалиас взаимодействует с ядром: интерфейс не позволяет определять необходимость расчёта КС своими силами либы и либе указывать как либо чтобы это сделало железо/ядро, либа тупо ждёт корректные КС, чекает их, патчит их и отсылает обратно.

В ядерном варианте скорее всего проблем с интерфейсом передачи инфы о КС нет, но видимо у самой либы тоже нет никаких механизмов/интерфейсов для этого.

 

И я бы на роутерах вообще не заморачивался и отключал TSO/LRO не думая, потому что это фичи типа фрагментации/дефрагментации больших пакетов и это актуально только для трафика адресованного именно этому хосту или исходящего от него (я подразумеваю что скажем через nginx файл кто то качает, но никак транзитный трафик который роутится/натится и дальше L3 в стёке не рассматривается).

По хорошему в сетевухах должны быть фильтры ещё и для L3 адресов, чтобы они знали какие пакеты транзитные и не делали для них лишней работы по оффлоаду. Возможно когда то такое появится или уже есть. Но в общем фича не востребованная потому что или это сервер и там ~100% трафика не транзитного или это роутер и там 99,99999% трафика транзитного, остальное манагемент и дос, притом дос до L4 не доходит и на то что фича выключена пофик, в основном.

 

 

Так же, в NetworkPerformanceTuning наоборот рекомендуют включать аппаратные чексуммы

Так ты не путай рассчёт чексумм и остальное, никакого противоречия нет.

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

[NiTr0]

LRO, GSO, TSO рекомендуется отключать и в линухе.

 

только на шейперах. т.к. может не совсем корректно шейпиться. и только tso/lro, gso/gro остаются включенными.

 

В цитате из исходника всё вполне расжёвано: есть проблема с тем, как либалиас взаимодействует с ядром: интерфейс не позволяет определять необходимость расчёта КС своими силами либы и либе указывать как либо чтобы это сделало железо/ядро, либа тупо ждёт корректные КС, чекает их, патчит их и отсылает обратно.

ну и причем тут КС к аппаратной сегментации? checksum offloading - отдельная крутилка тащемта.

[Ivan_83]

ну и причем тут КС к аппаратной сегментации? checksum offloading - отдельная крутилка тащемта.

Это было к особенностям работы самой либы.