RoomBot

Ну да - dummynet было первым, что я пробовал: всё работало в принципе неплохо, пока dummynet вместе с сервом не стали зависать из-за syn флуда. Подозреваю конечно, что дело было в моих кривых руках и можно было бы проблему как-то решить, оптимизировав переменные ядра (память, mbuf и т.п.), но не стал.ng_car понравился больше, в первую очередь из-за того, что при его соответствующей настройке tcp трафик режется правильно, а udp и icmp проходят без задержек и почти без потерь. Ipcad не юзал никогда - сразу почему-то взялся за kernel решение... Посмотрим как шлюз будет себя вести когда навешу на него все 1.5 абонентов...

А как с помощью ipfw mask-src/dst организовать выдачу абонам 2-3... IP адреса? Подсетку /29 выдавать?И помом, dummynet задерживает пакеты (шейпит), а ng_car именно ограничивает скорость (rate-limit), что ИМХО работает побыстрее :)

Всем добрго дня :) Собираю шлюз в инет на локальную сеть примерно из 1.5к абонентов. Планирую использовать сервер на FreeBSD с Intel PRO/1000 PT Dual Port - em0 в Интернет, em1 - в Локальную сеть. В дополнение к этому ng_car, ng_netflow, ipfw nat и сам ipfw. Каждому абону ставится номер contract ID (cid) который используется в обрезалке скорости. Такде предоставляем безлимитные тарифы и реальный IP адрес. Базовый конфиг ipfw 00001 nat 1 ip from any to any in via em0 00002 allow tcp from table(5) to xx.xx.xx.251,xx.xx.xx.100 dst-port 22 00003 allow tcp from xx.xx.xx.18 to xx.xx.xx.251 dst-port 4567 00004 deny tcp from any to xx.xx.xx.251,xx.xx.xx.100 dst-port 22,4567 00005 skipto tablearg ip from any to table(1) 00006 skipto tablearg ip from table(2) to any 00007 allow ip from any to xx.xx.xx.251,xx.xx.xx.100 00008 allow ip from xx.xx.xx.251,xx.xx.xx.100 to any 00009 deny ip from any to any # Блок обработки входящего трафа серых ip адресов (безлимитчики) 00500 netgraph tablearg tag 1 ip from any to table(11) out via em1 00501 ngtee 65534 ip from any to any out via em1 00502 allow ip from any to any # Блок обработки исходящего трафа серых ip адресов (безлимитчики) 01000 netgraph tablearg tag 1 ip from table(12) to any in via em1 01001 ngtee 65534 ip from any to any in via em1 01002 nat 1 ip from any to any out via em0 01003 allow ip from any to any # Блок обработки входящего трафа реальников (безлимитчики) 01500 netgraph tablearg tag 1 ip from any to table(11) out via em1 01501 ngtee 65534 ip from any to any out via em1 01502 allow ip from any to any # Блок обработки исходящего трафа реальников (безлимитчики) 02000 netgraph tablearg tag 1 ip from table(12) to any in via em1 02001 ngtee 65534 ip from any to any in via em1 02002 allow ip from any to any # Блок обработеи входящего трафа серых ip адресов 02500 ngtee 65534 ip from any to any out via em1 02501 allow ip from any to any # Блок обработеи исходящего трафа серых ip адресов 03000 ngtee 65534 ip from any to any in via em1 03001 nat 1 ip from any to any out via em0 03002 allow ip from any to any # Блок обработки входящего трафа реальников 03500 ngtee 65534 ip from any to any out via em1 03501 allow ip from any to any # Блок обработки исходящего трафа реальников 04000 ngtee 65534 ip from any to any in via em1 04001 allow ip from any to any 65535 allow ip from any to any В 1 таблицу пишется номер правила на которое прыгать, в соответствии с типом ip адреса (реальник, "серый", лимитчик или безлимитчик) для входящего трафа, а в таблицу 2 - для исходящего трафа. В 65534 хук дублируются пакеты для обсчёта трафа. в 11 и 12 таблицы пишется номера хука ng_ipfw, соединённых с соответствующей нодой ng_car, в которой режется скорость. Стартовая конфигурация netgraph для обсчёта трафика mkpeer ipfw: netflow 65534 iface0 name ipfw:65534 netflow msg netflow: setdlt { iface = 0 dlt = 12 } msg netflow: setifindex { iface = 0 index = 1 } mkpeer netflow: ksocket export inet/dgram/udp msg netflow:export connect inet/xx.xx.xx.23:1670 Нода ng_car конфигурится следующими командами: mkpeer ipfw: car $сid upper name ipfw:$i_сid rate_$сid connect rate_$сid: ipfw: lower $o_сid Далее конфигурируется пропускная способность. На данный момент через этот шлюз подключены примерно 350 абонентов. Трафик мизерный - 4-7Мбайт входящего в ЧНН. Нагрузка на проц 2-3% (cтоит Core-Quad). Тем не менее мне схема кажется не очень хорошей, в первую очередь из-за ограничения в ngctl, что нельзя посмореть больше 1000 но командой ngctl list, а во вторых некоторая сложность конфигурационных скриптов при заведении абонента. И (по моему мнению) кривое прохождение трафа в системе - ipfw -> netgraph -> ipfw -> netflow (через netgraph). Просто ничего пооптимальнее придумать не смог (через pf например и ng_nat) :( К тому же я не могу предсказать, что будет при заведении например 10000 нод в netgraph?? И как поведёт себя ng_car на больших скоростях ~12-20Мбит?? Использовал ли кто netgraph подобным образом со стольким количеством нод? Заранее спасибо за ответы ))