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

Carbon billing 5, обсуждение пишите, кто что думает, хвалите, ругайте, отправляйте пожелания

Все допетрил) в профиле же ппп можно скрипт допилить))) По сути это можно в скрипте session на биллинге это всё добавить, чтоб при авторизации так же добавлял учётку, а уже в нетватч пинговать биллинг и при недоступности set параметры carbon_pppoe_profile менять. вот только чуток всё таки не пойму add address=10.0.0.122 list=crb_auth_list, как вместо 10.0.0.122 прописать именно ip подключаемого абонента??? или проще не мучатся а вот так сделать add address=10.0.0.0/8 list=crb_auth_list? Вообщем мысля есть, как допилю выложу обязательно! По сути радиус отключать не нужно, а в session добавить пару строк чтоб при авторизации клиента добавлял по переменным с биллинга учётки в сикрет и через нетвачь изменять профиль сервера. После отключения абонента чтоб учётка удалялась и не складировался шлак. Влюбом случаи лучше один бедолага который отключает роутер для экономии электроэнергии и абоны на аварийной скорости, чем раскалённый телефон)))

Изменено пользователем 777BLOODER777

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Если у вас IPoE вдруг станет схема, вы биллинг в режим софтроутера настроите? =)

 

Если же вы хотите сделать такую кривую схему - то нужно создать профили PPPoE, где указать определенную скорость, и абонентов помещать в эти профили, указывая в настройках секретов имя профиля в зависимости от скорости. Кроме всего удалять их не надо, т.к. если у пользователя обрыв, он отключился, биллинг сломался, он подключается а учетки нет=) Сами же записи секретов можете отключать и включать, если биллинг вдруг недоступен.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Радиус отключить именно для авторизации абонентов имеется ввиду правильно? /ppp secret set disabled=no (либо yes) [ find name=Bill* ] profile=carbon_pppoe_profile в нетвач их массово включать и отключать + так же добавить add (либо del) address=10.0.0.0/8 list=crb_auth_list. Это при условии если не отключать радиус для авторизации.

Изменено пользователем 777BLOODER777

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А по какой причине на самом деле учетки абонов должны у биллинга каждый раз запрашиваться? Что на это скажет наш производитель? В чём подвох данного решения?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

 

В этом случае биллинг нужен только для блокировки и отключения блокировки за отсутствие оплаты, а так же для изменения учеток, вся авторизация осуществляется оборудованием самостоятельно. Учет потребленного трафика через нетфлоу. Если биллинг будет отключен - то абоненты смогут работать без проблем, пропадет только учет трафика за время не доступности биллинга.

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

А сама механика подключения на мт работает как? Приоритет берётся из учётки или по радиус в момент подключения, при условии доступности биллинга?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Микротик авторизует из локальной учетки, если ее нет то запрашивает через радиус.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Спасибо!

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Уже 20 дней не работает после обновления отчет по поступившим платежам от абонентов, 20 дней висит заявка в хелпдеске.

Раньше помогало написать г-ну Кучаеву, он торопил разработчиков.

Теперь и это не помогает. Такой вот сервис в карбоне.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Уже 20 дней не работает после обновления отчет по поступившим платежам от абонентов, 20 дней висит заявка в хелпдеске.

Раньше помогало написать г-ну Кучаеву, он торопил разработчиков.

Теперь и это не помогает. Такой вот сервис в карбоне.

Г-н Кучаев и разработчики совсем от рук отбились :), Уже работает. Сломался первый раз этот отчет, сейчас покрыли автотестами, больше не сломается.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Г-н Кучаев и разработчики совсем от рук отбились :), Уже работает. Сломался первый раз этот отчет, сейчас покрыли автотестами, больше не сломается.

У меня до сих пор не работает, никаких комментариев по заявке нет. Заявка SUP-103008.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Г-н Кучаев Вы не против если я выложу свою схему работы биллинга-микротика при условии недоступности по каким либо причинам первого. Схема заточена для работы PPPoE, с авторизацией по радиус. Мне кажется у вас и жалоб меньше станет, что у кого то не смог авторизироваться абонент, поднялась паника, все логины и пароли в биллинге, который по каким либо причинам недоступен и в итоге решили не работать с вами. Не буду утверждать что он идеальный, но работает! Единственное что я не нашел путь как задать диапазон адресов (поставил 10.0.0.0/8) абонентов из переменных который работает с сервером авторизации, а так он заливается вместе с вашими правилами-настройками на микротик и не требует лишних телодвижений.

Изменено пользователем 777BLOODER777

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если абоненты работают по серым адресам - адреса должны быть статические. Если белых адресов достаточно, то они тоже должны быть статические. Т.к. если все динамикой, сложнее реализовать СОРМ на сети.

Кроме всего радиус в 80 процентах случаев, когда его используют, вообще не нужен. Ведите базу логин + ип в биллинге, и копию этих данных в локальных записях микротика. Тогда обычная авторизация будет без радиуса, но всегда будет возможность его использовать без необходимости что-то править.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Г-н Кучаев и разработчики совсем от рук отбились :), Уже работает. Сломался первый раз этот отчет, сейчас покрыли автотестами, больше не сломается.

У меня до сих пор не работает, никаких комментариев по заявке нет. Заявка SUP-103008.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Г-н Кучаев, чтож вы меня игнорируете то? Я то из лучших побуждений.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У меня 2 вопроса:

 

1. Как реализовать на основе билинга карбон автоматическую рассылку Юр лицам пакета документов в электронном виде. Это возможно?

2. Как в карбоне реализована блокировка интернета на срок абонентом, например при отъезде в отпуск? на какой срок, в какой период, и сколько раз в год?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Г-н Кучаев Вы не против если я выложу свою схему работы биллинга-микротика при условии недоступности по каким либо причинам первого. Схема заточена для работы PPPoE, с авторизацией по радиус. Мне кажется у вас и жалоб меньше станет, что у кого то не смог авторизироваться абонент, поднялась паника, все логины и пароли в биллинге, который по каким либо причинам недоступен и в итоге решили не работать с вами. Не буду утверждать что он идеальный, но работает! Единственное что я не нашел путь как задать диапазон адресов (поставил 10.0.0.0/8) абонентов из переменных который работает с сервером авторизации, а так он заливается вместе с вашими правилами-настройками на микротик и не требует лишних телодвижений.

Добрый день! Да, конечно, выкладывайте. Вы автор схемы и Вам решать, что с ней делать. Мы предлагаем всего лишь один из вариантов. Можно либо его принять, либо потратить время и сделать свою схему. Поддерживать свою схему нужно тоже самостоятельно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У меня 2 вопроса:

 

1. Как реализовать на основе билинга карбон автоматическую рассылку Юр лицам пакета документов в электронном виде. Это возможно?

2. Как в карбоне реализована блокировка интернета на срок абонентом, например при отъезде в отпуск? на какой срок, в какой период, и сколько раз в год?

 

>>> 1. Как реализовать на основе билинга карбон автоматическую рассылку Юр лицам пакета документов в электронном виде. Это возможно?

-- каких документов? счета/акты? Да, конечно.

>>> 2. Как в карбоне реализована блокировка интернета на срок абонентом, например при отъезде в отпуск? на какой срок, в какой период, и сколько раз в год?

-- Функция называется "Добровольная блокировка". На любой срок и столько раз, сколько разрешите, подробности в статье: http://docs.carbonsoft.ru/pages/viewpage.action?pageId=50659526 , http://docs.carbonsoft.ru/pages/viewpage.action?pageId=66486273 . Кстати, там в формах настройки блокировки можно настроить сколько раз в месяц, но не в год.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

1. Внесены изменения в session, добавлены две строчки которые при авторизации клиента добавляют-обновляют учётную запись и добавляют к ней комментарий "crb_reserve_secret", который позже понадобится для netwatch.

 

user_rate_set(){

# Сначала удалим queue simple из старого сервиса, потом добавим в новый (изменён, queue simple теперь отображается номер договора и добавлены переменные limit-at=${rate_out}K/${rate_in}K, что даёт резать трафик более плавно без скачков при тарифах с низкими скоростями)

while send_mikrotik_cmd -s "$nas_ip" "${telnet_login}" "${telnet_password}" /queue simple remove [/queue simple find name=${login}]; do :; done

send_mikrotik_cmd "$nas_ip" "${telnet_login}" "${telnet_password}" /queue simple add name=crb_${contract_number} target=${ip}/32 parent=none priority=8/8 queue=default-small/default-small limit-at=${rate_out}K/${rate_in}K max-limit=${ceil_out}K/${ceil_in}K burst-limit=0/0 burst-threshold=0/0 burst-time=0s/0s

# Сначала удалим из secret учётку со старыми данными, потом добавим его с новыми данными из биллинга (обновление учётки пользователя обязательно, так как при смене пароля будет стучатся со старыми данными. учётка добавляется выключенной до падения связи с биллингом. при падении активируется через netwatch)

send_mikrotik_cmd "$nas_ip" "${telnet_login}" "${telnet_password}" /ppp secret remove [/ppp secret find name=${login}]

send_mikrotik_cmd "$nas_ip" "${telnet_login}" "${telnet_password}" /ppp secret add comment=crb_reserve_secret disabled=yes name=${login} password=${pwd} profile=carbon_pppoe_profile remote-address=${ip}

}

 

 

user_del(){

# Добавлена строка которая при удалении учётной записи в биллинге так же удаляет его с сервера авторизации PPPoE.

while send_mikrotik_cmd -s "$nas_ip" "$telnet_login" "$telnet_password" /ip firewall address-list remove numbers=${contract_number}_crb_auth; do :; done

while send_mikrotik_cmd -s "$nas_ip" "$telnet_login" "$telnet_password" /ip firewall address-list remove numbers=${contract_number}_crb_negbal; do :; done

while send_mikrotik_cmd -s "$nas_ip" "$telnet_login" "$telnet_password" /ip firewall address-list remove numbers=${contract_number}_crb_blocked; do :; done

while send_mikrotik_cmd -s "$nas_ip" "$telnet_login" "$telnet_password" /queue simple remove [/queue simple find name=${login}]; do :; done

while send_mikrotik_cmd -s "$nas_ip" "$telnet_login" "$telnet_password" /ppp secret remove [/ppp secret find name=${login}]; do :; done

}

 

2. В pppoe.cfg.tmplt добавлено правило netwatch пинговать ip нашего биллинга. При чп на сервере биллинга, netwatch ищет все учётные записи которые создавались ранее при авторизации с комментарием "crb_reserve_secret" и активирует их, а так же добавляет подсеть 10.0.0.0/8 в crb_auth_list. При восстановлении связи с биллингом учётки выключаются и работает полноценная авторизация через радиус, а так же подсеть 10.0.0.0/8 в crb_auth_list удаляется. Вместо подсети серых адресов можно добавить свои, так же с комментариями и группами их отключать, либо включать.

 

/tool netwatch add comment=reserve_authorization host={{billing_ip}} interval=5m timeout=5s down-script="/ppp secret set disabled=no [/ppp secret find comment=crb_reserve_secret] \r\n\r/ip firewall address-list add address=10.0.0.0/8 comment=crb_reserve_address list=crb_auth_list" up-script="/ppp secret set disabled=yes [/ppp secret find comment=crb_reserve_secret] \r\n\r/ip firewall address-list remove [/ip firewall address-list find comment=crb_reserve_address]"

 

 

 

3. Вместо ip абонента в simpl, negbal, bloced теперь отображается номер договора.

 

СКАЧАТЬ

 

Данная схема работает с PPPoE сервером на микротик и авторизацией через радиус.

Изменено пользователем 777BLOODER777

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У меня 2 вопроса:

 

1. Как реализовать на основе билинга карбон автоматическую рассылку Юр лицам пакета документов в электронном виде. Это возможно?

2. Как в карбоне реализована блокировка интернета на срок абонентом, например при отъезде в отпуск? на какой срок, в какой период, и сколько раз в год?

 

>>> 1. Как реализовать на основе билинга карбон автоматическую рассылку Юр лицам пакета документов в электронном виде. Это возможно?

-- каких документов? счета/акты? Да, конечно.

>>> 2. Как в карбоне реализована блокировка интернета на срок абонентом, например при отъезде в отпуск? на какой срок, в какой период, и сколько раз в год?

-- Функция называется "Добровольная блокировка". На любой срок и столько раз, сколько разрешите, подробности в статье: http://docs.carbonsoft.ru/pages/viewpage.action?pageId=50659526 , http://docs.carbonsoft.ru/pages/viewpage.action?pageId=66486273 . Кстати, там в формах настройки блокировки можно настроить сколько раз в месяц, но не в год.

Спасибо

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 21.12.2016 в 17:06, product manager CB5 сказал:

Думаю, что вопрос с базой данных закрыт и не будет обсуждаться больше. Только firebird на ближайшие пару лет, в дальнейшем возможно добавится oracle. Firebird самая надежная база, проверенная многократными испытаниями. Мы в компании тестировали разные базы на отказоустойчивость. Ломали их, выключали электричество и т.д. Она не падает при корректной работе с ней. Если она упала - каждый случай расследуется и о нем знает руководство. Более 600 клиентов пользуется Carbon billing 4 и Сarbon billing 5 и ни у кого она не падает. Если вы используете Carbon billing 5 и Вам пришлось восстанавливаться из бэкапа напишите нам в хелпдеск, мы разберемся и сделаем так, чтобы у Вас не повреждалась база и не пришлось восстанавливаться из бэкапа. Это наш принцип, наша политика. Если периодически повреждается база - такой биллинг надо выкинуть.

Не считая 3-х месяцев, год прошел.

Есть движения в строну oracle, ТоваришЬ Кучаев ?

 

Изменено пользователем RN3DCX

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 01.09.2017 в 23:26, RN3DCX сказал:

Не считая 3-х месяцев, год прошел.

Есть движения в строну oracle, ТоваришЬ Кучаев ?

 

продвижения нет, особо это не актуально. Нет такого, что каждый день или даже месяц кто-нибудь просит оракл, вообще редко просят. Раз в пару мес, приходит какой-нибудь новый крупный клиент спрашивает, "а можно оракл?" - но когда доходит до дела, как то не критичен вопрос становится. По факту запрос рынка слишком мал чтобы оракл сейчас внедрять. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А по мне так вопрос не в спросе, а в цене.

Тратить 17000$ на базу данных, эти вложения явно не вписывается в вашу концепцию. 

Т.к. стратегия вашей компании строиться на монетизировании opensource решений.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Да, и еще забыл добавить, к мотивации отказа от oracle!

Вряд ли, ваши пионеры молодые специалисты умеют работать с данной базой!?

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

В итоге вы потратите минимум 6 месяцев на адаптацию, а скорей всего и все 10-12, опять же из-за отсутствия квалификации ваших сотрудников.

Что по итогу для компании не РЕНТАБЕЛЬНО.

 

P.S. не надо вещать лапшу на уши, про возможный переезд на oracle, который по априоре не может состояться!

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Работа Carbon Billing 5 никак не зависит от используемой базы данных т.к. между функционалом и БД есть прослойка в виде ORM и он поддерживает Oracle.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.