LuckySB Posted November 25, 2009 (edited) · Report post Столкнулся тут с проблемкой: Периодически, раз в пять минут загрузка 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 Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Dyr Posted November 25, 2009 · Report post Данное правило вас вообще не спасёт от такого флуда, поскольку у всех этих udp-пакетов будут одни и те же src-addr, в данном примере - '192.168.123.123', меняйте на src-port. P.S. Таких ограничений у нас нет, хотя, пожалуй, можно было бы. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
kapa Posted November 25, 2009 (edited) · Report post где-то проскакивало в рассылке от разработчиков ipfw что в коде подправить, чтоб pps можно было ограничить. не представляю, правда, сколько подобное ресурсов сожрёт.... сейчас на pf стоит ограничение сессий до 300 кажется по портам кроме 80, 21... Edited November 25, 2009 by kapa Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
LuckySB Posted November 25, 2009 · Report post Данное правило вас вообще не спасёт от такого флуда, поскольку у всех этих udp-пакетов будут одни и те же src-addr, в данном примере - '192.168.123.123', меняйте на src-port.Гм. вообще-то спасает.Вот только что отключил его и сразу начались проблемы. как токо 123 клиент выдает 10000 udp, swi1:net уходит в 96%, выжирая одно ядро полностью. как токо правило добавляешь - сразу все опять хорошо ))) Мне, если вы не поняли, надо ограничить количество udp пакетов с каждого адреса. а src-port тут воообще не причем. где-то проскакивало в рассылке от разработчиков ipfw что в коде подправить, чтоб pps можно было ограничить.угу. в 2004 году проскакивало. Почему то не закоммитили )Вставлять в боевой рутер экспериментальные фичи я не хочу. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
netb0t Posted November 25, 2009 · Report post Данное правило вас вообще не спасёт от такого флуда, поскольку у всех этих udp-пакетов будут одни и те же src-addr, в данном примере - '192.168.123.123', меняйте на src-port.Гм. вообще-то спасает.Вот только что отключил его и сразу начались проблемы. как токо 123 клиент выдает 10000 udp, swi1:net уходит в 96%, выжирая одно ядро полностью. как токо правило добавляешь - сразу все опять хорошо ))) Мне, если вы не поняли, надо ограничить количество udp пакетов с каждого адреса. а src-port тут воообще не причем. А почему не использовать dummynet?! количество слотов в пайпе как раз и ограничивают pps. У нас например все клиенты загоняются в персональные пайпы и проблем с таким флудом нет. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
kapa Posted November 25, 2009 · Report post А почему не использовать dummynet?! количество слотов в пайпе как раз и ограничивают pps. У нас например все клиенты загоняются в персональные пайпы и проблем с таким флудом нет.у нас в пайпы запихиваются таблицы абонентов, но, по идее, это не должно менять суть...не поделитесь своими значениями pps для разных скоростей? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
netb0t Posted November 25, 2009 · Report post А почему не использовать 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 в частности). Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
LuckySB Posted November 26, 2009 · Report post bw 2048Kbit/s queue 100 Если queue 100 - это 100 pps, то в данной конфигурации максимальная скорость 100*1500*8= 1200 кбит Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
make.kernel Posted November 26, 2009 · Report post Если 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, вообщем в реальной жизни оно позабористее, но труба все считает в байтах, поэтому ппс зависит от размера пакета и я не знаю как регулировать именно ппс на фре. Гуру, поправьте, если я не прав. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Dyr Posted November 26, 2009 · Report post Гм. вообще-то спасает.М-м-м, да, виноват, был неправ. 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. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
LuckySB Posted November 26, 2009 · Report post Пакеты из очереди берутся с частотой kern.hz (по умолчанию 1000), если клиент резко стартанул, например 200 пакетов за 1 мс припустой очереди,Уже загрузка от клиента колоссальная получается ;)200 тысяч пакетов в секунду... В моем случае клиент выдавал udp по 133 байта пачками по 10000 штук за 3-5 секунд, а скорость у него 3мегабита. Чтобы ограничить клиента хотя бы в 1000pps надо ставить queue 30 ;( что приводит ко всяким лагам и скачкам скорости... В моем случае я ограничил его на отправку 50 udp в течении 10 секунд. Неужели никто не сталкивался с подобными проблемами ? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Giga-Byte Posted November 27, 2009 (edited) · Report post Неужели никто не сталкивался с подобными проблемами ?сталкивались.копайте дальше, эксперементируйте, да разберётесь. Edited November 27, 2009 by Giga-Byte Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
