bomberman

Ну никто не говорил, что настроив GVRP будете лежать на диване, и vlan-ы нужные сами будут появляться там где вы возжелали. Но появляться на большей части устройств, где GVRP настроен, они доложны. А уж быть им или нет, Вы решите как минимум на доступе. Ну и разумеется в ядре. А если надо так, чтоб vid написал, и он появился где нужно и сам, то скриптами. Писать все vlan-ы везде - тоже моветон, не находите?

Только в ручную. Через время сможете вслепую писать их )))) А по делу - GVRP, более удбного пока мне не известно. Но я выбрал бы вручную. Не уж то ежедневно приходится столько писать часто, что это становится проблемой? ещё можно expect для каждого типа свича/вендора.

expect

Это будет соответствовать от eth1.0 до eth1.999

Первое что пришло в голову, раскидать абонентов на уровне логики в биллинге. Т.е. авторизировать абонента на каком то одном БРАС-е, за которым закреплён абонент. При аварии чтоб биллинг отвечал для абонента на работающем БРАС-е.

1. Проект всё таки бесплатный решил быть? 2. Поменяйте подпись в теме, указав что проект относительно запрета по роскомнадзоровским спискам.

безусловно. Вам необходимо соблюсти условие, наличия интерфейса dhcp сервера со всеми вашими vlan-ами в одном L2 сегменте, к тому же оконеченным ip адресом. Варианты различны. Бридж например. Или описывать каждый интерфейс, который необходимо слушать dhcp в конфиге.

У ISC-DHCP есть ф-ционал позволяющий выполнять скрипты на разных этапах dhcp сессии. По результату получения - точно. На каких ещё, не помню. Быть может реализовать ваши потребности этим путём? Что конкретно не выходит? А вот по поводу accel, Вы зря. Очень не плохая штука, да к тому же есть модуль, позволяющий писать vlan-ы автоматом, при потребности.

Прекрасно. Проверил. iptables v1.6.1 Всё работает. P.s. сохранил старый Ваш патч, наложил на последнюю версию. Так же всё работает. Отлично. Было б не плохо.

какую? Предлогаю, выложить старую версию и патч для нее, или же оригинал и пропатченную версию.

Так а патч зачем потёрли? Старая репа - это тоже не плохо. А работающий к ней патч с изменением/добавлением ф-ционала, только плюс. Мало ли кому сгодился б. Да к тому же спрашивали. А там быть может если всё хорошо, и автор добавил бы в новые версии.

Тут мелькнул собственный патч некого a290, для ограничения по pps. Но потом сообщение куда то испарилось. Прочему так? Кто то пользовался?

Безусловно. За что автору огромное спасибо. Никто иного не утверждает. Но вы не совсем верно истолковали смысл моих слов. Я хотел донести, что проэкт активно не завивается, выполнены поставленные требования в начале работы, и всё. Остальное по необходимости на усмотрение автора или вновь поставленных задачах.

Похожие предложения уж были, а так же с классификациями, для QOS. Но результат будет вряд ли. Автор, на сколько я понял из ветки форума, писал проэкт под заказ. После окончания, и сдачи, оставил как есть, и не развивает активно. Так что спасибо ему за существующий код.

Кто то реализовывал алгоритм несколько ip на учётку, с разделением между ними скорости учётки, средствами accel, для схемы ipoe? Или только свой шейпер реализовывать и управлять из pppd-compat?

Вот это совсем не плохо было бы. Вот и я о том же, когда говорил о нареканиях и сырости решения. Но наивно пологал, что времени от первого релиза прошло достаточно, чтоб избавиться от perl-овых костылей. Хатя... Как я понял, разрабочики реализовали DHCP там по стольку, по скольку, в классическом варианте, дабы показать возможность работы этого протокола совместно с RADIUS, и реализовали возможность отдавать опции атрибутами. Большего никто и не обещал. Как где то слышал "FreeRADIUS - это фреймворк для протокола RADIUS." (с) Отсюда и костыли, для нужной логики работы. Да и провайдеру мало такая реализация подойдёт в том виде, в котором оно реализовано там, особенно, когда нужно ещё из пакета получить нужные опции, кроме 82й (на сколько я помню это было возможно там), как например номер vlan-а опцией. Для этих целей accel вполне, как по мне.

Понял, всё тот же accel только по сути для RADIUS-а. Тоже смотрел в эту сторону, но как то всё же решил попробовать существующие средства. Выходит Вы в скриптах только шейперами управляете? Доступ и назначения адресов выполняет accel?

Какие методы используете удалённого вызова скриптов на БРАС-е с биллинга? По постам выше, сдаётся, что не так что то готовлю, или не совсем понял суть.

Отнюдь.. Он давно уж умел. Только были какие то нарекания о сырости, и не полноценности решения. Но это было давно оч. Сам такой метод не использовал. Alex/AT GrandPr1de Кто пользовался FreeRadius в роли dhcp? Поделитесь впечатлениями, реализацией.

если не ошибаюсь, версия данного DHCP сервера, по прежнему работает через релей, нет ли в планах у автора доработки с возможностью работы без релея. Или я что то упустил?

LB это что? если Вы о LanBilling? - нет :) Я тоже пологал, что достаточно только L4-Redirect отправить. В принципе так и есть, только вот как то не совсем адекватно работатет при многократной отправке. К тому же заметил не совсем пока понятное для меня поведение, шейпера. настройки были следующие: при использовании police [shaper] attr=Filter-Id up-limiter=police down-limiter=tbf скорость upload (на стороне подписчика), правильно "режется" только в пределах до 1Мб. При указании скорости upload свыше 1Мб, по факту остаётся в пределах 1,2Мб. При 100Мб ~ 2-4 Мб. Собрал ядро с поддержкой ifb, написал слудующую конструкцию в конфиге для использования шейпинга. [shaper] attr=Filter-Id ifb=ifb0 up-limiter=htb down-limiter=tbf Всё работает корректно. ifb accel создаёт, скорость "режется" согласно переданным данным из radius. Всё работает. Пока детально не разбирался с причиной, но если кто подскажет причину такого поведения, или направления "копания", буду признателен.

Заметил досадный момент. Имеется (accel-ppp version e8dda21218a0bcb5363490a35e2cfed798421f2c) испольуемые модули: [modules] log_file log_syslog ipoe radius shaper net-snmp используемая схема (из основного): [ipoe] l4-redirect-ipset=redirect_list shared=1 ifcfg=0 mode=L2 interface=re:eth9.[0-9][0-9] vlan-mon=eth9,9-200 загружены модули ядра: ipoe vlan_mon Всё работает, на первый взгляд. Но заметил момент. Иногда при включении/отключении L4-redirect по средствам COA (несколько раз пробовал включить/отключить на учётку), на интерфейсе пропадают занчения шейпера (в итогде учётка может оказаться без значений шейпера). Вернуть их можно только передав по COA или остановкой сессии и поднятия новой. При поднятии сессии, передаётся следующая информация: Framed-IP-Address = 172.16.0.10 Framed-IP-Netmask = 255.255.255.255 Filter-Id = "2048/1024" L4-Redirect = 1 или 0 (в зависимости от потребности) COA включения/отключения: echo "Framed-IP-Address=172.16.0.10,L4-Redirect="0"" | radclient -x 192.168.50.15:3799 coa testing123 так всё корректно: echo "Framed-IP-Address=172.16.0.10,L4-Redirect="0",Filter-Id="1024/2048"" | radclient -x 192.168.50.15:3799 coa testing123 Иногда и первый вариант работает исправно. Но через некоторое количество раз его выполнения, скорость на интерфейсе может "слететь". или стать не корректной, вида - 0/32669 или 1078558720/1024. При этом отсутствует ping даже на интерфейс самого БРАС-а, который шлюз по умолчанию у клиента. Выполнив COA с установкой нужной скорости, всё возвращяется на круги своя. Какой то закономерности в количестве или последовательности выполнения замечено небыло. (иногда через 3 выполнения проявлялось, иногда больше). Не корректная скорость оказалась единожды, а вот пропадала чаще. Сталкивался ли кто с таким поведением? Или быть может я не корректно выполняю COA ?

Заметно, вряд ли. Тут скорее всего будет правильнее использовать ipset, в случае набора подсетей для правила/действия. А при единственном случае, то смысла нет.

У человека есть NetFlow. Ему нужно в процентном соотношении данные по определённым сетевым протоколам. пологаю nfsen справится.

nfsen