Опубликован перевод (http://www.bsdportal.ru/viewtopic.php?t=3322) руководства по уменьшению вредного воздействия от атак вида "отказ в обслуживании" (DoS) и диагностике источника проблем. Рекомендации применимы как для 4-ой, так и для 5-ой ветки FreeBSD.Кратко:
- "sysctl -w net.inet.tcp.msl=7500" - максимальное количество времени ожидания ACK в ответ на SYN-ACK или FIN-ACK в миллисекундах;
- "sysctl -w net.inet.tcp.blackhole=2" - все пакеты на закрытый порт отбрасываются без отсылки RST;
- "sysctl -w net.inet.udp.blackhole=1" - отбрасывать пакеты для закрытых портов;
- "sysctl -w net.inet.icmp.icmplim=50" - защита от генерирование потока ответных пакетов, максимальное количество ICMP Unreachable и TCP RST пакетов в секунду;
- "sysctl -w kern.ipc.somaxconn=32768" - увеличение числа одновременно открытых сокетов;
- Сборка ядра с опцией DEVICE_POLLING.URL: http://www.bsdportal.ru/viewtopic.php?t=3322
Новость: http://www.opennet.me/opennews/art.shtml?num=4600
> Сборка ядра с опцией DEVICE_POLLINGСпорная рекомендация.
Поллинг начинает оправдывать себя при перманентно высокой нагрузке на сеть. Если это высокоскоростной маршрутизатор, к примеру. А так... ну, не знаю. Cомневаюсь, что это оправдано.
Очень даже оправданно, переменноя sysctl kern.polling.user_frac задает процент загрузки сети при котором карта переключается в polling (по умолчанию 50), другое дело, что по умолчанию subj деактивирован и нужно задавать kern.polling.enable=1 иначе проку от сборки его в ядре 0
Дополнение: и options HZ= рекомендуется от 1000 и выше
Не знаю как сейчас, но во времена 5.2, если карточка не поддерживала POLLING, то карточка просто не работала...
приходилось убирать этот параметр из ядра...
Поэтому в статье fxp и рекомендуют :-)
Проверял кто это дело на SMP???
The DEVICE_POLLING option by default does not work with SMP enabled kernels. When the author of the DEVICE_POLLING code initially commited it he admits he was unsure of the benefits of the feature in a multiple-CPU environment, as only one CPU would be doing the polling. Since that time many administrators have found that there is a significant advantage to DEVICE_POLLING even in SMP enabled kernels and that it works with no problems at all. If you are compiling an SMP kernel with DEVICE_POLLING, edit the file: /usr/src/sys/kern/kern_poll.c and remove the following lines:#ifdef SMP
#include "opt_lint.h"
#ifndef COMPILING_LINT
#error DEVICE_POLLING is not compatible with SMP
#endif
#endif
Чтука реальная, проверял на fxp и dc, жалко что xl не поддерживается :(
А не знаете почему всё застряло на считанных единицах карт? В мане говорится, что поддержка железом не требуется и достаточно в драйвере... Жду не дождусь xl и bge... :-(
Поддержка железом ещё и как требуется -- у карты должен быть аппаратный буфер, в котором она будет хранить пришедшие пакеты до тех пор пока *_poll() из драйвера их заберёт. Соответственно, поллинг возможен даже не в каждой fxp (только в серверных версиях, которые способны хранить до 64 пакетов).
В bge ещё никто и не начинал ничего делать (документации не хватает?) Кстати, лично я не в восторге от этих карт.
всё, с первой до последней строчки - не правда и глупости.
если вы сами не разбираетесь в вопросе, то будте так добры -
не вводите других в заблуждение.пришедшие пакеты не хранятся в памяти карточки. они хранятся в оперативной
памяти хоста.поллинг возможет в каждой fxp. оперативная память хоста может хранить 64
и больше принятых пакетов до того, как они будут переданы на уровень выше.
но нужен ли всем версиям fxp поллинг ? (иногда может хватить простого link0)bge сама по себе не нуждается в поллинге. на гигабитных скоростях задержки до 1000
микросекунд на интерфейсах - не есть good. тем более, что bge сами прекрасно представляют, что такое interrupt moderation.предлагаю вам начать изучать мат-часть.
Не пакетов, а кадров, уважаемый. Изучите терминологию. Не хватало еще для полного счастья, чтобы сетевые карты начали сами IP/IPX пакеты обрабатывать. В оперативной памяти хоста хранятся *пакеты*. А *кадры* (фреймы) хранятся в буфере сетевой карты, если он есть.
> Не пакетов, а кадров, уважаемый.
да вы просто прикопались.> Изучите терминологию. Не хватало еще для полного счастья, чтобы сетевые карты
> начали сами IP/IPX пакеты обрабатывать.
такие слова, как TSO, TOE, вам что-нибудь говорят ?
(я молчу про самостоятельное выставление и валидирование ip4/ip6/tcp/udp чек-сумм)> В оперативной памяти хоста хранятся *пакеты*.
> А *кадры* (фреймы) хранятся в буфере сетевой карты, если он есть.
буфер сетевой карты, как правило, не очень большой.
всего на пару-тройку пакетов в том же fxp...
Чего-чего?
Сссылочку мне сюда. С описанием сетевого адаптер, который сам считает чексуммы L3.
Да, по поводу TCP segmentation offload - то же самое. К *сетевому адаптеру* это имеет удаленное отношение. Всего лишь прослойка между адаптером и стеком. И не пакетов, а фреймов, еще раз вам повторяю.
> Чего-чего?
> Сссылочку мне сюда.
в следующий раз пойдёте в google сами.> С описанием сетевого адаптер, который сам считает чексуммы L3.
The industry's first fully offloaded TCP/IP Offload NIC:
http://www.adaptec.com/worldwide/product/prodtechindex.html?...TSO и checksumming offload:
http://www.3com.ru/products/server_nics/3c996b-t/properties/
(специально для pppp - глянь, в твоём нелюбимом bge(4) целых 96Kb буферной памяти !)> Да, по поводу TCP segmentation offload - то же самое.
> К *сетевому адаптеру* это имеет удаленное отношение.
:)> Всего лишь прослойка между адаптером и стеком. И не пакетов, а
> фреймов, еще раз вам повторяю.
продолжайте изучать терминологию
С каждым годом всё хуже и хуже...
Медитируем над функцией fxp_poll() в /sys/dev/fxp/if_fxp.c
Далее выясняем чем занимается макрос CSR_READ_1 (ответ: вызывает bus_space_read_1() из /sys/i386/include/bus_at386.h, а в ней всё довольно очевидно)ЗЫЖ Пора новый тред по поллингу открывать...
ЗЗЫЖ С терминологией я действительно зарапортовался; конечно, имелись в виду фреймы
Так любая сетевая от Intel поддерживает поллинг?
и еще по поводу xl, карточки 3кома поллинг не пддерживают или дрова xl для FreeBSD эту функцию не поддерживают? как с этим у Linux например?PILA 8460BI INTEL EtherExpress Pro 100+ PCI (chip 82559) будет держать Device polling ? и подойдет ли она для конфиуграции и вопроса: http://www.opennet.me/openforum/vsluhforumID1/49717.html
>Так любая сетевая от Intel поддерживает поллинг?
Нет, не любая; а только та, у которой есть аппаратный буфер.
Поддерживают те карты, которые позиционируются как серверные (список, возможно, не полный)
82546 -- 64 КБ (64 кадра)
82545 -- 64 КБ (64 кадра)
82540 -- 64 КБ (64 кадра)
82557
82558
82559
Эти точно поддерживают.
По идее должны поддерживать все карты серии 8254x и 8255x, но у некоторых из них аппаратный буфер может быть значительно меньше -- ftp://download.intel.com/design/network/applnots/ap453.pdf>и еще по поводу xl, карточки 3кома поллинг не пддерживают или дрова
>xl для FreeBSD эту функцию не поддерживают? как с этим у
>Linux например?
Во всяком случае 3Com Gigabit Server поддерживает (но это не xl, а bge); а 905-е, похоже нет.
Я не очень хорошо ориентируюсь в Linux, но идеи device polling там присутствуют. Правда, почему-то разработчики смотрят только в сторону символьных драйверов (/me shrugs). Под Linux все люди используют не нативный драйвер, а поставляемый Intel в бинарниках (в основном из-за корректной поддержки 802.1q; а также из-за аналога уже упомянутой опции типа link0). В драйверах Intel (бинарных) есть аппаратная поддержка device polling (link0 в FreeBSD), которая работает максимум для 6 кадров, но не требует никакой поддержки от ОС.>PILA 8460BI INTEL EtherExpress Pro 100+ PCI (chip 82559) будет держать Device
>polling ? и подойдет ли она для конфиуграции и вопроса:
См выше. Подойдёт> http://www.opennet.me/openforum/vsluhforumID1/49717.html
Согласен с большинством :) Intel + device polling
Спасибо за такой подробный овтвет! Еще небольшое уточнение:
1. т.е. выходит просто карты серии 3Ком905 не имеют аппаратного буфера? т.е. и под линухом они хуже себя покажут? и FreeBSD здесь не виновата?
2. Будет ли роутер: пень1, озу порядка 32-64Мб, сетевые Intel + device polling, (2 сетки на 100Мбит) показывать работу на уровне аппаратного решения или нужна более серьезная конфигурация? пентиму2 или п3...
Т.е. хватит ли такой конфигурации или при больших нагрузках будут провалы по скорости?
>Спасибо за такой подробный овтвет! Еще небольшое уточнение:
>1. т.е. выходит просто карты серии 3Ком905 не имеют аппаратного буфера? т.е.
>и под линухом они хуже себя покажут? и FreeBSD здесь не
>виновата?
Повторю ещё раз: мне кажется, что поллинг там не реализован; хотя всякое может быть. В любом случае мне не удалось обнаружить драйвера для 905 с его поддержкой.>2. Будет ли роутер: пень1, озу порядка 32-64Мб, сетевые Intel + device
>polling, (2 сетки на 100Мбит) показывать работу на уровне аппаратного решения
>или нужна более серьезная конфигурация? пентиму2 или п3...
>Т.е. хватит ли такой конфигурации или при больших нагрузках будут провалы по
>скорости?
Когда-то работал P-MMX + 64MB RAM с 3 сетевыми картами (кстати, 905-ми 3com ;)) без поллинга. На нём же и v35 сидел (128Кбит/с в Интернет). Здесь многое зависит от задач/настроек, а особенно от структуры трафика.
С аппаратным решением никакой pc на больших нагрузках не сравнится. Здесь дело не в вычислительной мощности (в данном случае можно говорить о кошке 26 серии, у которой центральный процессор вполне даже сопоставим с Pentium I), а в архитектуре -- у pc всё в результате упирается в загруженную под завязку шину, которая используется абсолютно для всего.
Циска для домашней сети, с практически нулевым бюджетом, что находишь из того и собираешь роутер :) , не подходит. Поэтому и ищутся способы добитсья насколько возможной скорости и стабильности на простых конфигурациях. Первая покупка уже наметилась: NTEL EtherExpress Pro 100+ (chip 82559).
"Чего только не придумают русские, что бы не покупать циску".
Щас попробую девайс поллинг поднять и проверить на картах rl... по манам там поддержка есть :)
Вообще в статье так и написано: "Наконец, если у вас есть одна из следующих сетевых карточек, то вы можете включить в ядро опцию DEVICE_POLLING"это, видать, автор новости случайно приравнял "опцию" к "основным" советам ;)
Из man polling
SUPPORTED DEVICES
Device polling requires explicit modifications to the device drivers. As
of this writing, the dc(4), em(4), fwe(4), fxp(4), ixgb(4), nge(4),
re(4), rl(4), sis(4), ste(4), vge(4), and vr(4) devices are supported,
with others in the works.
xl нет :(
а будет ли?
Интересно, а может ли сетевая карточка через DMA скидывать кадры в оперативку, имея тем самым буферы, ограниченные только размером оперативки? Или DMA только для IDE?
>Интересно, а может ли сетевая карточка через DMA скидывать кадры в оперативку,
>имея тем самым буферы, ограниченные только размером оперативки? Или DMA только
>для IDE?
Может, а некоторые так и делают.
1) У DMA существуют свои ограничения на максимальный размер используемой памяти;
2) Кроме того, что скинуть, надо ещё и следить за тем, кто и когда их будет забирать... Поэтому те кто могут -- скидывают, но как копию своих аппаратных буферов. А зачем -- чтобы разгрузить локальную шину.
3) Вообще-то DMA изначально разрабатывался для звуковых карт и флоповодов...
1)Ограничение ISA DMA - 64К за пересылку - достаточный размер даже для гигабита, в PCI bus master.... нуууу сколько памяти хватит, и сколько тебе позволят шину держать.
2) Для тех девайсов которые умеют DMA/Bus mastering и дрова соответствующие.
При скидывании используется механизм похожий на страничную работу памяти. Одна страница передается, вторая заполняется данными. После заполнения, странцы меняются местами.
3) Говорить что DMA разрабатывалось для флопов, а тем более музыкальных карт это мягко скажем бред... тут стоит подучить архитектуру 8080 и хронологию появлению устройств.
>2) Для тех девайсов которые умеют DMA/Bus mastering и дрова соответствующие.
>При скидывании используется механизм похожий на страничную работу памяти. Одна страница передается,
>вторая заполняется данными. После заполнения, странцы меняются местами.
Загвоздка в том, что сетевую карту никто не просит складывать данные в память; она это делает сама, причём в абсолютно непредсказуемые моменты времени...>3) Говорить что DMA разрабатывалось для флопов, а тем более музыкальных карт
> это мягко скажем бред... тут стоит подучить архитектуру 8080
>и хронологию появлению устройств.
Я тогда ещё и в школу не ходил; и разве что S390 видел. Поэтому и не рассуждаю о том, чего никогда не видел (я о вычислительных устройствах на базе i8080)
глюк?!выставил параметры как указано в статье, т.е. поставил
net.inet.tcp.msl=7500
kern.ipc.somaxconn=32768после этого перестали работать
unix sockets, и, соответственно, приложения их использующие..., а также перестал работать kavdaemon :( после того как откатил на свои прежние настройки
net.inet.tcp.msl=30000
kern.ipc.somaxconn=1024все заработало...
>глюк?!
>
>выставил параметры как указано в статье, т.е. поставил
>net.inet.tcp.msl=7500
>kern.ipc.somaxconn=32768
>
>после этого перестали работать
>unix sockets, и, соответственно, приложения их использующие..., а также перестал работать kavdaemon
>:( после того как откатил на свои прежние настройки
>net.inet.tcp.msl=30000
>kern.ipc.somaxconn=1024
>
>все заработало...Были аналогиные симптомы на 5.3 после сборки ядра с предустановленным kern.ipc.somaxconn=32768.
Ничего откатывать не стал, а используемые
drwebd и drweb-sendmail вылечил пересборкой и установкой последних версий из портов (4.32.2 и 4.32.1 соотв.)
вот это:
kern.ipc.somaxconn=32768 -
диверсия для FreeBSD 4.x максимум 32767