ipfw limit ограничим юзера

[LuckySB]

Столкнулся тут с проблемкой:

Периодически, раз в пять минут загрузка swi1:net подскакивала за 90%, сервер начинал пинговаться по 200мс.

Freebsd6.4, mpd4.4, ng_nat, ng_car, em без поллинга.

 

Расследование выявило, что от одного из юзеров в этот момент приходило по 10-20тысяч udp пакетов.

Юзер заявил, что у него свежепоставленная винда, kis2010 и bitcomet включен был.

 

ну и ng_nat весь процессор видимо на себя и перетягивал ;)

 

Пока поставил лично на этого юзера вот такую конструкцию

allow udp from 192.168.123.123 to any via ng* limit src-addr 50

 

Подумываю о подобной вещи для всей сети 192.168.0.0/16 ;)

У кого-нить подобные лимиты стоят уже в боевом режиме ? и какие именно цифирки ограничений ? ;)

Edited November 25, 2009 by LuckySB

[Dyr]

Данное правило вас вообще не спасёт от такого флуда, поскольку у всех этих udp-пакетов будут одни и те же src-addr, в данном примере - '192.168.123.123', меняйте на src-port.

 

P.S. Таких ограничений у нас нет, хотя, пожалуй, можно было бы.

[kapa]

где-то проскакивало в рассылке от разработчиков ipfw что в коде подправить, чтоб pps можно было ограничить.

 

не представляю, правда, сколько подобное ресурсов сожрёт....

 

сейчас на pf стоит ограничение сессий до 300 кажется по портам кроме 80, 21...

Edited November 25, 2009 by kapa

[LuckySB]

Данное правило вас вообще не спасёт от такого флуда, поскольку у всех этих udp-пакетов будут одни и те же src-addr, в данном примере - '192.168.123.123', меняйте на src-port.

Гм. вообще-то спасает.

Вот только что отключил его и сразу начались проблемы. как токо 123 клиент выдает 10000 udp, swi1:net уходит в 96%, выжирая одно ядро полностью.

как токо правило добавляешь - сразу все опять хорошо )))

 

Мне, если вы не поняли, надо ограничить количество udp пакетов с каждого адреса.

а src-port тут воообще не причем.

 

где-то проскакивало в рассылке от разработчиков ipfw что в коде подправить, чтоб pps можно было ограничить.

угу. в 2004 году проскакивало. Почему то не закоммитили )

Вставлять в боевой рутер экспериментальные фичи я не хочу.

[netb0t]

Данное правило вас вообще не спасёт от такого флуда, поскольку у всех этих udp-пакетов будут одни и те же src-addr, в данном примере - '192.168.123.123', меняйте на src-port.

Гм. вообще-то спасает.

Вот только что отключил его и сразу начались проблемы. как токо 123 клиент выдает 10000 udp, swi1:net уходит в 96%, выжирая одно ядро полностью.

как токо правило добавляешь - сразу все опять хорошо )))

 

Мне, если вы не поняли, надо ограничить количество udp пакетов с каждого адреса.

а src-port тут воообще не причем.

А почему не использовать dummynet?! количество слотов в пайпе как раз и ограничивают pps. У нас например все клиенты загоняются в персональные пайпы и проблем с таким флудом нет.

[kapa]

А почему не использовать dummynet?! количество слотов в пайпе как раз и ограничивают pps. У нас например все клиенты загоняются в персональные пайпы и проблем с таким флудом нет.

у нас в пайпы запихиваются таблицы абонентов, но, по идее, это не должно менять суть...

не поделитесь своими значениями pps для разных скоростей?

[netb0t]

А почему не использовать dummynet?! количество слотов в пайпе как раз и ограничивают pps. У нас например все клиенты загоняются в персональные пайпы и проблем с таким флудом нет.

у нас в пайпы запихиваются таблицы абонентов, но, по идее, это не должно менять суть...

не поделитесь своими значениями pps для разных скоростей?

 

bw 128Kbit/s queue 16

bw 256Kbit/s queue 32

bw 512Kbit/s queue 50

bw 1024Kbit/s queue 100

bw 2048Kbit/s queue 100

и тд queue 100. Проблем и жалоб не замечали. Eсли у вас много "заразных" абонентов, то можно попробовать уменьшить кол-во слотов, иначе вместо swi1:net в 100ню будет уходить dummynet (хотя все зависит от вашей конфигурации, ipfw в частности).

 

[LuckySB]

bw 2048Kbit/s queue 100

Если queue 100 - это 100 pps, то в данной конфигурации максимальная скорость 100*1500*8= 1200 кбит

[make.kernel]

Если queue 100 - это 100 pps, то в данной конфигурации максимальная скорость 100*1500*8= 1200 кбит

queue 100 это очередь на 100 пакетов. Если pipe не успевает пропихнуть пакеты быстрее, чем они приходят после наполнения очереди пакеты дропаются. Например на скорости мегабит и пакете 100 байтов, получаем примерно 1000 ппс которые пропустит пайп, все остальное после наполнения очереди в /dev/null. Пакеты из очереди берутся с частотой kern.hz (по умолчанию 1000), если клиент резко стартанул, например 200 пакетов за 1 мс припустой очереди, первый пакет проскочит через трубу - он вписывается в скорость - 1 мбит это 100 байт за мс, со 2 по 102 лягут в очередь, с 103 по 200 будут дропнуты. При этом каждую милисекунду из очереди будет забраться 1 пакет. Не забываем про то, что трафик теоретический 100байтными паетами и очередь может быть не только wfq а еще и red и gred, вообщем в реальной жизни оно позабористее, но труба все считает в байтах, поэтому ппс зависит от размера пакета и я не знаю как регулировать именно ппс на фре. Гуру, поправьте, если я не прав.

[Dyr]

Гм. вообще-то спасает.

М-м-м, да, виноват, был неправ.

limit {src-addr | src-port | dst-addr | dst-port} N

The firewall will only allow N connections with the same set of

parameters as specified in the rule. One or more of source and

destination addresses and ports can be specified. Currently,

only IPv4 flows are supported.

 

[LuckySB]

Пакеты из очереди берутся с частотой kern.hz (по умолчанию 1000), если клиент резко стартанул, например 200 пакетов за 1 мс припустой очереди,

Уже загрузка от клиента колоссальная получается ;)

200 тысяч пакетов в секунду...

В моем случае клиент выдавал udp по 133 байта пачками по 10000 штук за 3-5 секунд, а скорость у него 3мегабита.

Чтобы ограничить клиента хотя бы в 1000pps надо ставить queue 30 ;( что приводит ко всяким лагам и скачкам скорости...

 

В моем случае я ограничил его на отправку 50 udp в течении 10 секунд.

Неужели никто не сталкивался с подобными проблемами ?

[Giga-Byte]

Неужели никто не сталкивался с подобными проблемами ?

сталкивались.

копайте дальше, эксперементируйте, да разберётесь.

Edited November 27, 2009 by Giga-Byte