Jump to content

Релизы Ubilling


Recommended Posts

  • Replies 1.2k
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Да кстати если кому то нужен шаблон для свича то вот  можно воспользоваться такой штукой  шаблоно-генератором

Преувеличиваем? Ничего особенного и нового я не сделал

Ни один единорог не пострадал? =)

Posted Images

Каким местом биллинг должен соотноситься с вопросами политики внешнего раутинга?

Нормальные люди делают бекап и балансировку аплинков при помощи BGP, ну или на худой конец скриптовыми подпорками. В общем чем угодно только не считалкой денег.

 

ЗЫ второй вопрос в FAQ как бы намекает

Link to post
Share on other sites

Создав во классах трафика 3 линии (тирнет1 тирнет2 тирнет3) и при регистрации юзера указывать одно из них, тогда пользователь будет работать только в по этому маршруту?

Link to post
Share on other sites

Смысл?

 

Всеравно в принципе не понимаю как классификатор трафика, нужный к слову только для раздельного учета трафика (интернет/локалка) по направлениям, тобишь таки тарификации, должен коррелировать хотябы логически с политикой PBR в сети.

 

Если уж так руки чешутся отправлять абонентов разными каналами в интернеты:

1. Для этого существует логика разделения на подсети и сервисы, для логической организации групп абонентов и разбрасывания их по разным серверам доступа

2. Для управления на лету раутингом при подъеме каждого единичного абонента вполне возможно использовать "дополнительные поля профиля" в связке с геттером GetCF (хотя всеравно изврат считаю)

 

 

В норме не предполагается терминация трафика самим биллингом вообще. И это хорошо.

Link to post
Share on other sites

смысл в том, что моя сеть имеет 4 подключения в глобус. Объединение каналов в один не очень хорошо получилось... стабильно хромает, пачка сайтов с маслиной открывается, а в соцсетях вообще медиа воспроизводится 1 из 10. Вообщем бека еще та.

 

Теперь озадачился сделать: при реестрац. юзера указывать вручную ибо автоматически указывать сетевой фейс в глобус.

 

Вот такая вот задача.

Link to post
Share on other sites
смысл в том, что моя сеть имеет 4 подключения в глобус.

Окей, я более убог - всего только 2 аплинка по 10Г.

В любом случае считаю, что биллингу который дефакто и деюре является считалкой денег, должно быть абсолютно на это фиолетово. Такие вещи решаются посредтсвом BGP как я уже упоминал.

 

 

Объединение каналов в один не очень хорошо получилось... стабильно хромает, пачка сайтов с маслиной открывается, а в соцсетях вообще медиа воспроизводится 1 из 10. Вообщем бека еще та.

Кустарная балансировка дефолтраутов при помощи pf round-robin либо ipfw prob/fwd еще никогда нормально не работала. Вижу имели шанс убедиться в этом на собственном опыте.

 

Теперь озадачился сделать: при реестрац. юзера указывать вручную ибо автоматически указывать сетевой фейс в глобус.

Каждому абоненту отдельно в ручную прописывать дефолтраут? Мсье знает толк в извращениях. B)

 

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

 

Из плюсов такого решения:

1. нормальность

2. предсказуемая маршрутизация

3. миграция между сервисами в 1 клик

4. адекватная сегментация сети

5. см. п.1.

 

Хотя для любителей рукоблудствачной работы остается таки рабочий вариант с использованием кастомных полей профиля и GetCF. В древние времена когда была потребность выдавать отдельным юзерам маску скажем /27 для внутренних нужд вместе с основной айпишкой просто строилась логика рисования статичного раута на базе

CUSTOM_MASK=`/etc/stargazer/GetCF $LOGIN 1`
if [ "CUSTOM_MASK" != "" ]
then
route add $CUSTOM_MASK $IP bla bla bla
fi

 

ну или типа того

Link to post
Share on other sites
Почему просто не выделить пусть даже 4 подсети, навешать на них соответственно сервисов и как белые люди распихивать не задумываясь о лишнем туда абонентов?

 

вот так и будут крутится гайки, иных путей пока что не вижу. Да и администрировать будет проще.

Может есть варианты моей ситуации? (что то в стиле "Мой опыт с...")

Link to post
Share on other sites
Может есть варианты моей ситуации? (что то в стиле "Мой опыт с...")

Выше же рассказал, зачем нужна логика подсетей/сервисов.

 

Собственно для провайдеров, которые используют Ubilling, и не имеют возможности сделать нормальную аггрегацию внешних линков, замечено вполне нормальное использование раскидывания юзеров по подсетям с чуть более узкой маской. Дальше как будут распихиваться эти сети и кудой они ходят, через разные экземпляры NAT на разных интерфейсах, через разные удаленные NAS на базе rscriptd, заруливаться к бабушке на деревню или еще куда - биллинг как и задумано не колышет.

 

Абстрагировать логику учета средств от механики и топологии доступа, является единственным кошерным вариантом.

Link to post
Share on other sites

Там нечего думать.

 

Добавляете себе сети для абонентов, допустим:

1. 10.10.0.0/24

2. 10.10.1.0/24

 

На них вешаете сервисы:

1. 10.10.0.0/24 -> Типа интернет

2. 10.10.1.0/24 -> Х...евый интернет

 

Для подсетей добавляете NAS в соответствии со своими реалиями. Если же вы используете раздельные NAS на rscripd или mikrotik на этом все заканчивается. В противном случае едем дальше.

 

Если используете стандартные заготовки для BSD из ubinstaller в варианте billing+nas модифицируете свой /etc/firewall.conf добавив обе подсети масками в table(2) и подняв разные екземпляры nat для каждой из подсетей. Как в общих чертах (а именно в две строчки) работает ipfw nat можете почитать вот тут: http://wiki.ubilling....php?id=ipfwnat

Link to post
Share on other sites

как бы все запустилось, пока что в тестовом режиме 2 подсети. если все будет норм, подкручу еще 2.

 

PS

при какой нагрузке начинается сыпаться штукатурка при ALL in ONE?

Link to post
Share on other sites
как бы все запустилось, пока что в тестовом режиме 2 подсети. если все будет норм, подкручу еще 2.

стратегически без разницы сколько их там будет, оно для того и задумано

 

при какой нагрузке начинается сыпаться штукатурка при ALL in ONE?

Все зависит в первую очередь: от вашего железа и качества сетевых ну и дальше от pps, объема трафика, и количества сессий.

 

Практический опыт других сетей подсказывает что средний тазик ценовой категории ~$1k уверенно держит 1.5к абонентов с тарифами 3-100 Мбит при потоке в ~750Mbit/s в конфигурации "все в одном" практически без тюнинга. Хотя держать такой комбайн лично считаю извратом.

 

pps можно посмотреть вот так:

netstat 1

 

Сколько трафика у вас суммарно думаю сами знаете.

 

Хозяйке на заметку: теоретический запас оставшейся мощи можете оценить на глаз сделав

sysctl net.inet.ip.fastforwarding=1

 

после чего внимательно посмотреть в

top -SHP

сколько отжирают обработчики прерываний сетевых карточек.

 

Есть способ еще проще: сделать ifconfig - если вы видите там карточки вида rl0, vr0, nfe0, ale0 - можете начинать выбирать, кого из пользователей продать на органы, чтобы купить нормальную сетевую :(

Link to post
Share on other sites
сделать ifconfig - если вы видите там карточки вида rl0, vr0, nfe0, ale0

 

ну а что ж там еще может видеть мелкий провайдер??? ;)

Практический опыт других сетей подсказывает...

Вот и спасибо, что бы знать, когда нужно в бабушкин носок копеечки класть... :(

 

PS

вскоре выложу немного измененный "Кабинет пользователя".

Link to post
Share on other sites
ну а что ж там еще может видеть мелкий провайдер???

Что угодно только не это.

Цена адекватной(!) двухголовой igb карточки нынче эквивалентна стоимости "разок нормально побухать".

Link to post
Share on other sites

Вопрос о "Прием заявок".

В alter.ini

SIGREQ_ENABLED=1

 

 

папку "signup" переместил в корень /data

 

 

в БД создал пользователя, базу и сделал все ему права.

 

 

в signup.ini настроил все, как требует БД.

 

При захождении на странице неизвестным пользователем (http://hostname/signup/index.php) появляется страница, но в ней ничего нет.

Link to post
Share on other sites

1. либо PHP < 5.2

2. либо сигнапилке неоткуда получить список улиц, накой черт вы отдельную базу создали?

 

 

Включите хотябы вывод ошибок в PHP, глядишь и увидите, чего ей не нравиться.

Link to post
Share on other sites
Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By camchatix
      Добрий день,
      створили запасний NAS із зайвою хромосомою, все працює але коли треба вбити сесію користувача - то у списку NAS серверів лише один (той що основний)
      переназначити швидкість теж не можу
      я так розумію пакети CoA Disconnect, CoA connect, PoD - ідуть на IP адресу старого NAS ?
    • By grach_witch_cheese
      Вітаю, колеги!
      Маю наступну схему:
      DHCP-сервер: Accel-PPP (IPoE) DHCP-Relay: MikroTik RADIUS: Запущений безпосередньо на сервері uBilling Зараз авторизація абонентів здійснюється за MAC-адресою, але планується перехід на авторизацію через Option 82.
      У документації uBilling наведені приклади конфігурацій, коли DHCP-сервер працює локально (на самому uBilling) і містить відповідні шаблони для обробки Option 82.
      Однак немає чіткої інформації про використання Option 82 при віддаленому DHCP-сервері, зокрема, коли Accel-PPP використовується як DHCP-сервер у режимі remote та налаштований через Купаген.
      Питання:
      Чи можливо використовувати Accel-PPP як віддалений DHCP-сервер з авторизацією через Option 82? Якщо так, то де відбувається парсинг значень Remote-ID і Circuit-ID? Де в цьому випадку мають зберігатися шаблони для Option 82? Буду вдячний за роз'яснення або посилання на відповідні приклади.
    • By nightfly
      Ubilling 1.5.2 rev 9302 Book of Endings
       
      Зміни в структурі БД. alter.ini: нова опція FASTPROFITCALC_ENABLED, що вмикає швидкий підрахунок прибутку. alter.ini: нова необов'язкова опція KARMA_IN_PROFILE що вмикає показ карми в профілі користувача. alter.ini: нова опція SWITCHES_AUTH_ENABLED, що вмикає довідник даних авторизації пристроїв. alter.ini: нова опція PON_SCRIPTS_ENABLED, що вмикає підтримку скриптів OLT в ПОНізаторі. alter.ini: нова опція PON_ONU_FDB_SELFFILTER, що вмикає фільтр MAC-ів при відображенні FDB за ONU. alter.ini: нова опція USERBYIP_ENABLED, що вмикає виклик userbyip в RemoteAPI. alter.ini: пачка нових опцій PB_FASTURL_*, що керують поведінкою модулю відсилання коротких посилань на оплату. Модуль PONizer: виправлена помилка зникнення PON інтерфейсів при опиті BDCOM GP3600 Модуль “Профіль користувача”: для опису плагінів профілю та оверлеїв на кшталт “чорної магії” тепер опційно можливо вказувати link_target. Модуль “Панель задач”: для опису елементів панелі задач, тепер опційно можна вказувати LINK_TARGET. Модуль Записи телефонних розмов: вирішено проблеми швидкодії, при перегляді списку записів дзвінків. Модуль “Записи телефонних розмов”: більше не призводить до вичерпання пам'яті процесу, при перегляді великих архівів дзвінків. Модуль “Записи телефонних розмов”: новий аудіо-плеєр для прослуховування записів з візуалізацією аудіо-хвилі. Модуль “Пошук оплат”: реалізовано можливість швиденького підрахунку прибутку по обраних чекбоксами платежах. Модуль УКВ: реалізовано можливість швиденького підрахунку прибутку по обраних чекбоксами платежах. Модулі Мапа обладнання та користувачів: трішки вичищено код. Ліпше не стало. Модуль “Мапа будинків”: поле пошуку при розташуванні будинку, тепер попередньо заповнено локацією, при переході за посиланням “розташувати на мапі”. Модуль “Панель задач”: опція TB_QUICKSEARCH_INLINE змінила свою поведінку, та може тепер приймати значення 0|1|2. Модуль “Звіт по трафіку”: виправлено проблему відображення графіків OphanimFlow для NAS на роздільних здатностях менше ніж FullHD. Кабінет користувача: в модулі “Відеоспостереження” відображення попереднього перегляду каналів користувача, стало трішки притомнішим. Сховище зображень: трішки покращено поведінку форми завантаження. RemoteAPI: новий виклик onusigcompressor, що радикально стискає розпухаючі дані історії сигналів ONU. RemoteAPI: новий виклик pbxmonrefill, що оновлює кеш записів телефонних розмов. RemoteAPI: новий виклик userbyip, що повертає дані про користувача за його IP. OpenPayz: в бекенді та фронтенді platon виправлено проблему диких заокруглень, при вказанні зовнішньої комісії.  
      Повний чейнджлог
      Оновлена демка
       

    • By ppv
      Після оновлення до 1.5.1 не відображаються сигнали на
      OLT BDCOM P3310B (Device version10.1.0B)

      та
      P3608-2TE (Firmware Version10.1.0E). 

      3310C та P3608B ніяких проблем немає, знімає все добре. 
      З GPON3600-8 все зрозуміло будуть виправлення в Ubilling: 1.5.2.
       
      Може в когось було щось подібне? Хочу знати куди копати.
    • By Remez
      Ценник 5,500
       
      в наличии 3 шт
       
       






×
×
  • Create New...