RoomBot Опубликовано 1 ноября, 2008 · Жалоба Всем добрго дня :) Собираю шлюз в инет на локальную сеть примерно из 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 подобным образом со стольким количеством нод? Заранее спасибо за ответы )) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
hmd Опубликовано 3 ноября, 2008 · Жалоба не совсем понятно зачем мешать сюда NG посмотри в сторону Ipfw mask Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
RoomBot Опубликовано 4 ноября, 2008 (изменено) · Жалоба не совсем понятно зачем мешать сюда NG посмотри в сторону Ipfw mask А как с помощью ipfw mask-src/dst организовать выдачу абонам 2-3... IP адреса? Подсетку /29 выдавать?И помом, dummynet задерживает пакеты (шейпит), а ng_car именно ограничивает скорость (rate-limit), что ИМХО работает побыстрее :) Изменено 4 ноября, 2008 пользователем RoomBot Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 4 ноября, 2008 · Жалоба При такой нагрузке можно хоть по две трубы на рыло создавать в dummynet и обсчитывать это все через ipcad netflow, проц прожует и не заметит. При таком запасе по производительности нужно выбирать простейшие решения. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
RoomBot Опубликовано 4 ноября, 2008 · Жалоба При такой нагрузке можно хоть по две трубы на рыло создавать в dummynet и обсчитывать это все через ipcad netflow, проц прожует и не заметит. При таком запасе по производительности нужно выбирать простейшие решения.Ну да - dummynet было первым, что я пробовал: всё работало в принципе неплохо, пока dummynet вместе с сервом не стали зависать из-за syn флуда. Подозреваю конечно, что дело было в моих кривых руках и можно было бы проблему как-то решить, оптимизировав переменные ядра (память, mbuf и т.п.), но не стал.ng_car понравился больше, в первую очередь из-за того, что при его соответствующей настройке tcp трафик режется правильно, а udp и icmp проходят без задержек и почти без потерь. Ipcad не юзал никогда - сразу почему-то взялся за kernel решение... Посмотрим как шлюз будет себя вести когда навешу на него все 1.5 абонентов... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
snark Опубликовано 10 февраля, 2010 · Жалоба (по моему мнению) кривое прохождение трафа в системе - ipfw -> netgraph -> ipfw -> netflow (через netgraph)а где у Вас возвращение пакетов из нетграфа? у Вас не: ipfw -> netgraph -> ipfw -> netflow а ipfw -> ng_car + ipfw -> ng_netflow Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
TiFFolk Опубликовано 10 февраля, 2010 · Жалоба skipto tablearg ip from Не кэшируется, пробегает по всем правилам. Переделывайте на статические skipto. netgraph tablearg tag 1 ip from any to table(11) out via em1 Зачем вы ставите тег? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 11 февраля, 2010 (изменено) · Жалоба Здесь не нужен Netgraph, если нет PPPoE и прочего. Для шейпинга достаточно банального dummynet с динамическими пайпами и таблицами. Ну да - dummynet было первым, что я пробовал: всё работало в принципе неплохо, пока dummynet вместе с сервом не стали зависать из-за syn флуда. Подозреваю конечно, что дело было в моих кривых руках и можно было бы проблему как-то решить, оптимизировав переменные ядра (память, mbuf и т.п.), но не стал.SYN-flood направлен на DoS-атаку сервисов, использующих TCP-протокол. Шейпер TCP-заголовки не парсит, ему по барабану, какие там флаги в пакетах установлены.ng_car понравился больше, в первую очередь из-за того, что при его соответствующей настройке tcp трафик режется правильно, а udp и icmp проходят без задержек и почти без потерь.Это какие-то галлюцинации. Dummynet и ng_car -- реализации одного и тот же алгоритма token bucket. Они работают просто с пакетами как таковыми, а не с сетевыми протоколами. То, о чем вы пишете, называется приоритезация трафика. Изменено 11 февраля, 2010 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 13 февраля, 2010 · Жалоба некропостеры Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
TiFFolk Опубликовано 13 февраля, 2010 · Жалоба Это все snark =) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
snark Опубликовано 13 февраля, 2010 · Жалоба это все гугл виноват :) этот топик обычно в первых 3-х ссылках Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...