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

bomberman

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

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

  • Посещение

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


  1. Что можно расширить в полисере?

    Читайте внимательно эту ветку. Там не раз были предложения о расширении ф-ционала.

    К примеру добавление ipv6.

  2. Я очень сильно подозреваю что самому автору модуль не нужен, а задачи заказчика - полностью закрыты. Потому и правок нет :)

     

    К сожалению так и есть

     

    Я инсайдер и в курсе всех скрытых подробностей появления ratelimit/netflow модулей.

    Этот модуль вообще появился только потому, что автору были предоплачены часы работы (20 часов afair), причем даже без гарантий что что-то получится на выходе. Изначально нужно было выяснить как это реализовать под большую нагрузку и при этом сделать удобным для isp. То что код публичный, так это позиция автора. На данный момент все оплаченное время закончилось.

     

    А очень жаль.

  3. До сих пор не могу понять как в мире опенсоурс могло появится такое продуманное и качественное решение.

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

  4. По лицензированию - одна Lifetime лицензия на один брас.

    Что подразумевается под Lifetime лицензия?

    Верно ли я понял, что заплатив ~ 400EUR. Я получаю софт, который не имеет ограничений работы во времени, и ф-ционале.

    При этом поддержка ограничена временем/сроком. И если мне захочется обновить софт, то необходимо будет продлевать лиценщию на суппорт. Если не продлил - покупать софт снова?

     

    Если мне нужно будет перенести софт на другое железо, к примеру на более производительное. Могу ли я это сделать сам без обращения в суппорт или действий с лицензией? Иными словами лицензия завязывается на железо?

  5. bomberman

    Больной вопрос ( спецов нет, все на удаленке и на коленках. Для тазиков нужен спец по линуксу. Думаю взять микротик, но опять же вдруг получится так же как и с 7200, что нифига подобное не реализовать...

    Ну если на нём будет только NAT, то вполне. Главное чтоб железо выдержало.

  6. Архитектурно не развивается, идёт по сути фикс багов. Ну вообщем кроме как порисовать графики на какому-нибудь тестовом стенде, Cacti уже особо больше ни на что и не годится

    Ну с тестовым стендом Вы уж слишьком. Она ещё поработает. А что архитектурного развитя нет - это согласен. Но будем надеяться что скоро всё поменяется.

  7. Встречал как то однажды утилиту к счётчику, вроде как горячей воды, который на дом ставили. Счётчик по rs-232 подключается, и утилитой от вендора можно было мониторить параметры, а так же вести учёт. Финансовый тоже.

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

    Что то я не припомню о коммерческой составляющей этого проэкта, или автор обещял плюшки за доп плату где то тут?

  9. Как по мне - это вообще первый полисер в линукс

    Ну тут я не соглашусь. Полисинг там был давно. tc в помощь.

    А как подвигается, позволю напомнить, работа над воплощением полисинга над подсетями? Мы по /29 private клиентам выдаём, например.

    IPv6 в планах есть?

    Присоеденяюсь к вопросу.

  10. Если машина тестовая, поставте 777 :) И поглядите будет ли работать. В правах ли дело. Коль в правах дальше по обстоятельству. Смотря от кого работает web сервер. Скорее он туда и писать доложен.

  11. Сделал так. Параметр default_policy теперь может принимать три значения: block-all (блокировать строго все, чего нет в базе), block (блокировать все, кроме самого шейпера), pass (пропускать все).

    Отлично. Считаю будет необходимым.

  12. Плохо в этой схеме то, что мне не известно, чтоб кто-то такое практически использовал

     

    Тоже не встречал. Но попробовать думаю стоит. Хотя бы из интереса.

    самое главное, не понятно какие значения ставить, чтоб получить то, что обычно хотят получить QOS.

     

    Ну раз QOS, то наверное будет логично, для начала попробовать задать общую полосу, и потом вес для какждого типа. Но сумма всех весов в пределах общего канала выделенного для IP или (если несколько IP)подписчика.

    Т.е. я пока это вижу как параметры напрмер:

    IP,<speed - общая скорость для подписчика> <num_q - количество классов> <clss_id=1:speed(или вес в процентах от общей скорости)>...<clss_id=N:speed(или вес в процентах от общей скорости)>

     

    Это первое что пришло на ум. А там быть может что ещё интереснее посоветуется.

    Ну и + идентификация трафика/клиента не по IP или сегменту, а ещё и по внутренней метке, или по значению в поле QOS. Но в последнем случае общей скоростью как вариант - скорость самого интерфейса.

  13. Я уже писал выше про подобный вариант. Сейчас рулю у себя по метке skb->priority, но можно и fwmark как доп.вариант.

     

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

     

    Единственное, в голову приходит идея с различными значениями burst для разных классов трафика. Где для более приоритетного трафика burst выше. Тогда в случае забивания канала он будет проходит в первую очередь.

     

    Некий метод вытеснения выходит. У кого больше, то выше прыгнет, и быстрее пройдет. Так выходит?