mlevel Опубликовано 12 августа, 2017 (изменено) · Жалоба Хотелось бы прояснить несколько моментов по поводу 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). Где же правда? Изменено 12 августа, 2017 пользователем mlevel Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
polmax Опубликовано 13 августа, 2017 · Жалоба Тоже интересует этот вопрос, с 2009 года уже много воды утекло и драйвера переписаны и версия уже 11. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mlevel Опубликовано 13 августа, 2017 · Жалоба Тоже интересует этот вопрос, с 2009 года уже много воды утекло и драйвера переписаны и версия уже 11. Да, но судя по коду libalias остался нетронутым, и проблема именно в нём. Я просто не хочу отключать всё подряд на сетевой, так как она неплохо справляется и снижает нагрузку на CPU. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vlad11 Опубликовано 14 августа, 2017 · Жалоба перейдите на pf nat Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 16 августа, 2017 · Жалоба Где же правда? В исходниках! Значит отключать нужно только TSO и то, насколько я понимаю, только на том интерфейсе, где у нас NAT. Нигде не сказано что есть проблема с LRO. Или это подразумевается само собой? LRO, GSO, TSO рекомендуется отключать и в линухе. Всё потому, что нам нахрен не упёрлась аппаратная дефрагментация пакетов и аппаратная их фрагментация обратно. В цитате из исходника всё вполне расжёвано: есть проблема с тем, как либалиас взаимодействует с ядром: интерфейс не позволяет определять необходимость расчёта КС своими силами либы и либе указывать как либо чтобы это сделало железо/ядро, либа тупо ждёт корректные КС, чекает их, патчит их и отсылает обратно. В ядерном варианте скорее всего проблем с интерфейсом передачи инфы о КС нет, но видимо у самой либы тоже нет никаких механизмов/интерфейсов для этого. И я бы на роутерах вообще не заморачивался и отключал TSO/LRO не думая, потому что это фичи типа фрагментации/дефрагментации больших пакетов и это актуально только для трафика адресованного именно этому хосту или исходящего от него (я подразумеваю что скажем через nginx файл кто то качает, но никак транзитный трафик который роутится/натится и дальше L3 в стёке не рассматривается). По хорошему в сетевухах должны быть фильтры ещё и для L3 адресов, чтобы они знали какие пакеты транзитные и не делали для них лишней работы по оффлоаду. Возможно когда то такое появится или уже есть. Но в общем фича не востребованная потому что или это сервер и там ~100% трафика не транзитного или это роутер и там 99,99999% трафика транзитного, остальное манагемент и дос, притом дос до L4 не доходит и на то что фича выключена пофик, в основном. Так же, в NetworkPerformanceTuning наоборот рекомендуют включать аппаратные чексуммы Так ты не путай рассчёт чексумм и остальное, никакого противоречия нет. Чексуммы выключать смысла нет, если только ты не подозреваешь что у тебя сетевуха сошла с ума и не начала их криво считать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 22 августа, 2017 · Жалоба LRO, GSO, TSO рекомендуется отключать и в линухе. только на шейперах. т.к. может не совсем корректно шейпиться. и только tso/lro, gso/gro остаются включенными. В цитате из исходника всё вполне расжёвано: есть проблема с тем, как либалиас взаимодействует с ядром: интерфейс не позволяет определять необходимость расчёта КС своими силами либы и либе указывать как либо чтобы это сделало железо/ядро, либа тупо ждёт корректные КС, чекает их, патчит их и отсылает обратно. ну и причем тут КС к аппаратной сегментации? checksum offloading - отдельная крутилка тащемта. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 22 августа, 2017 · Жалоба ну и причем тут КС к аппаратной сегментации? checksum offloading - отдельная крутилка тащемта. Это было к особенностям работы самой либы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...