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