Перейти к содержимому
Калькуляторы

bomberman

Активный участник
  • Публикации

    226
  • Зарегистрирован

  • Посещение

Сообщения, опубликованные пользователем bomberman


  1. то один хрен заходить на свитч и прописывать этот влан

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

    А если надо так, чтоб vid написал, и он появился где нужно и сам, то скриптами.

    Писать все vlan-ы везде - тоже моветон, не находите?

  2. Только в ручную. Через время сможете вслепую писать их ))))

    А по делу - GVRP, более удбного пока мне не известно.

    Но я выбрал бы вручную. Не уж то ежедневно приходится столько писать часто, что это становится проблемой?

    ещё можно expect для каждого типа свича/вендора.

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

  4. ISC-DHCP не хочет стартовать, выдаёт Unsupported device type 772 for "lo

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

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

    Что конкретно не выходит?

    А вот по поводу accel, Вы зря. Очень не плохая штука, да к тому же есть модуль, позволяющий писать vlan-ы автоматом, при потребности.

  6.  

    Форк последней версии с патчем:

    https://github.com/a...t-ratelimit-pps

    Прекрасно. Проверил.

    iptables v1.6.1

    Всё работает.

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

    Версию без CIDR/IPv6 с нарезкой по интерфейсу пока у себя тестирую, если будет нормально работать, то потом выложу в отдельную репу

    Отлично. Было б не плохо.

  7. Мне нужно скорость резать по интерфейсу вместо IP (vlan-per-user), а для этого проще поправить версию без CIDR/IPv6.

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

  8. вроде все что было обещано, уже сделано... даже без "под заказ".

    Безусловно. За что автору огромное спасибо. Никто иного не утверждает.

    Но вы не совсем верно истолковали смысл моих слов.

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

  9. Не думали добавить ограничение не только в битах, но и в pps?

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

    Автор, на сколько я понял из ветки форума, писал проэкт под заказ. После окончания, и сдачи, оставил как есть, и не развивает активно.

    Так что спасибо ему за существующий код.

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

  11. Если что и будет в планах такой же только с перламутровым IPv6.

    Вот это совсем не плохо было бы.

    Там весь прикол что с базой он работает прилично опять же если всё пускать через перловый код

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

  12. модуль pppd_compat

    ip-change обрабатывает CoA

    Понял, всё тот же accel только по сути для RADIUS-а. Тоже смотрел в эту сторону, но как то всё же решил попробовать существующие средства.

    Выходит Вы в скриптах только шейперами управляете? Доступ и назначения адресов выполняет accel?

  13. Из-за этого ушел на внешние скрипты и очень рад)

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

     

    По постам выше, сдаётся, что не так что то готовлю, или не совсем понял суть.

  14. А FreeRadius dhcp научился в броадкаст? Он же тоже только через релей умел.

    Отнюдь.. Он давно уж умел. Только были какие то нарекания о сырости, и не полноценности решения. Но это было давно оч. Сам такой метод не использовал.

    Alex/AT GrandPr1de

    Кто пользовался FreeRadius в роли dhcp? Поделитесь впечатлениями, реализацией.

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

  16. У вас LB используется?

    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. Всё работает.

     

    Пока детально не разбирался с причиной, но если кто подскажет причину такого поведения, или направления "копания", буду признателен.

  17. Заметил досадный момент.

    Имеется (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 ?

  18. я не понял, у вас есть перечень протоколов и трафик по ним и вы не можете привести цифры к процентному соотношению?

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

    пологаю nfsen справится.