Срочно нужен номер круглосуточной поддержки carbonsoft

[sinpain]

Срочно нужен номер круглосуточной поддержки carbonsoft

Клиенты 3 сутки без интернета.

Не можем активировать биллинг

[RN3DCX]

А у вас лицензия часом не от 3-е версии?

[Kolunchik]

del

Edited April 12, 2018 by Kolunchik

[Saab95]

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

[moob82]

13 часов назад, sinpain сказал:

Срочно нужен номер круглосуточной поддержки carbonsoft

Клиенты 3 сутки без интернета.

Не можем активировать биллинг

А что с телефоном на сайта? я по нему звоню. Трубки берут

 

11 часов назад, Saab95 сказал:

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

Не совсем понятно, как это реализовать? Если биллинг связан с платежными системами например и управляющим маршрутизатором. 

Напишите примеры для понимания. Вопрос очень интересный.

[alibek]

10 минут назад, moob82 сказал:

Не совсем понятно, как это реализовать?

В нормальных биллинговых системах есть соответствующий сервисный режим, а на BRAS настраивается резервный RADIUS, либо действие при недоступности RADIUS.

В микротиках все по своему. Скорее всего имеется ввиду базу пользователей держать локально.

[moob82]

1 минуту назад, alibek сказал:

В нормальных биллинговых системах есть соответствующий сервисный режим, а на BRAS настраивается резервный RADIUS, либо действие при недоступности RADIUS.

В микротиках все по своему. Скорее всего имеется ввиду базу пользователей держать локально.

Что дает этот сервисный режим? 

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

[Kolunchik]

Можно держать в запасе accel-ppp с заранее подготовленным конфигом с пулами адресов и указанием пускать всех подряд.

[alibek]

31 минуту назад, moob82 сказал:

Что дает этот сервисный режим?

Возможность получения абонентами сервисов при остановленной биллинговой системе.

Обычно это упрощенная версия биллинга, которая не осуществляет непосредственно биллинг (то есть начисление и списание средств), а зачастую даже не использует БД, а дает на все обращения положительный ответ.

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

[ams666]

ммммм А  в проблема временно просто всем доступ дать ? Да за три дня можно было вручную уже по всем абонентам на микротике вручную acl поправить.  ну или скриптом пробежаться.

 

[TheUser]

1 час назад, alibek сказал:

а на BRAS настраивается резервный RADIUS, либо действие при недоступности RADIUS.

Поддерживаю коллегу. Когда мы переходили на новый биллинг, сразу возникла потребность в резервных RADIUS-серверах (FreeRADIUS), открывающих интернет всем на фиксированной (усредненной) скорости.

Вообще, желательно периодически проводить с персоналом учения вида: "упала база данных биллинга, ваши действия?", "рассыпался RAID с базой биллинга", "BRAS завис и не поднимается после перезагрузки". Тем самым искать слабые места, намечать пути их устранения и/или обхода в аварийной ситуации.

[LostSoul]

Коллега, а вот когда вы внедряли это замечательное техническое решение, вы не задавались вопросом "что мы будем делать когда умрет биллинг?"

И так про каждый конкретный пункт вашего предприятия.

 

Или там в плане написано "будем 3 дня звонить в техподдержку"?

 

 

7 минут назад, TheUser сказал:

Поддерживаю коллегу. Когда мы переходили на новый биллинг, сразу возникла потребность в резервных RADIUS-серверах (FreeRADIUS), открывающих интернет всем на фиксированной (усредненной) скорости.

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

А затем написал экспорт из базы абонентов в обычный текстовый файл и конфиг openradius  к нему.

В результате процесс получения списка IP абонентов и их скоростей  и процесс обслуживания биллинга абсолютно независимы.

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

 

ну и естественно на bras есть "красная кнопка" , активирующая режим "давать всем без проверки на полной скорости".  Уже дважды использовалась за ~12 лет.

 

 

[alibek]

Попинать пионера это конечно святое.

Я тоже хотел пройтись по поводу «телефон указан в платном контракте поддержки» и «бесплатная поддержка осуществляется на форуме».

Но вот однажды у нас сломался биллинг, точнее БД. И разработчик биллинга, несмотря на непродленный сервисный контракт, оперативно эту проблему решил (не бесплатно, конечно, но с постоплатой).

И за это ему огромный бонус, в отличии от Карбонсофта и Гидры.

[LostSoul]

1 минуту назад, alibek сказал:

Но вот однажды у нас сломался биллинг, точнее БД. И разработчик биллинга, несмотря на непродленный сервисный контракт, оперативно эту проблему решил

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

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

 

 

3 минуты назад, alibek сказал:

Попинать пионера это конечно святое.

Это не пионеры. Это подход такой.

 

 

[alibek]

7 минут назад, LostSoul сказал:

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

Не только.

Разумеется повезло, что у разработчика не было аврала.

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

[LostSoul]

1 минуту назад, alibek сказал:

прежде чем хотя бы принять заявку.

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

А то разорятся и вообще никогда не заплатят уже.

 

[Saab95]

2 часа назад, moob82 сказал:

Не совсем понятно, как это реализовать? Если биллинг связан с платежными системами например и управляющим маршрутизатором. 

Напишите примеры для понимания. Вопрос очень интересный.

Доступ в интернет можно представить примерно по следующим технологиям:

 

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

 

2. Доступ с порта по IP - тут опять же или по радиусу с локальной базой, это если адреса динамические, если же статика то все проще - и так будет работать, если на маршрутизаторе уже заведены правила.

 

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

 

22 минуты назад, alibek сказал:

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

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

 

2 часа назад, moob82 сказал:

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

Платежи вообще лучше всего в ручном режиме вводить - когда приходят уведомления (на почту или еще куда), после чего оператор вручную вводит их каждому кто оплатил. Если абонентов не 10000 то вполне все можно успевать.

 

Если сеть на микротиках, то целесообразно раздавать фиксированные адреса в случае IPoE, и фиксировано прибивать адреса в PPPoE. Тогда биллинг стоит в сторонке и только отправляет команды на блокировку. То есть не нужно пихать радиус туда, где он не нужен. Даже имея 10 PPPoE терминаторов, можно на всех вести единую базу абонентов. Микротик нормально работает, даже если в учетках по 5-10 тысяч записей.

[alibek]

39 минут назад, Saab95 сказал:

копию локальных пользователей на маршрутизаторе

 

39 минут назад, Saab95 сказал:

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

 

39 минут назад, Saab95 сказал:

если абонент получил IP и подключен к сети - то, не зависимо от биллинга, он будет работать

 

39 минут назад, Saab95 сказал:

держать меньшее количество правил блокировки менее ресурсоемко, и случись что - достаточно стереть данные по ним и все получат доступ

 

40 минут назад, Saab95 сказал:

Платежи вообще лучше всего в ручном режиме вводить

 

40 минут назад, Saab95 сказал:

То есть не нужно пихать радиус туда, где он не нужен.

Прекрасное выступление.

Лет эдак 15-20 назад оно наверное даже имело бы успех.

Сейчас это конечно музейный экспонат.

 

У вас как, абоненты ждут, пока оператор вручную проведет платеж, зайдет на нужный Микротик и подключит порт?

А при смене тарифа порт перенастраивается тоже вручную?

[TheUser]

1 час назад, LostSoul сказал:

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

А затем написал экспорт из базы абонентов в обычный текстовый файл и конфиг openradius  к нему.

Такой подход работает только в небольших операторах.

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

[LostSoul]

8 минут назад, TheUser сказал:

Такой подход работает только в небольших операторах.

Все нормально работает.

Разрабатывается проект технического решения.

После взаимных консультацией визируется по всех отделах.

Определяются зоны ответственности отделов.

И работает.

 

[TheUser]

19 минут назад, LostSoul сказал:

Все нормально работает.

Разрабатывается проект технического решения.

После взаимных консультацией визируется по всех отделах.

Определяются зоны ответственности отделов.

И работает.

Либо я не правильно выразился, а вы неправильно поняли масштабы компании.

[LostSoul]

2 минуты назад, TheUser сказал:

Либо я не правильно выразился, а вы неправильно поняли масштабы компании.

Вы что конкретно хотите сказать?

Что в крупных компаниях критически важные сервисы не дублируют и продумывают ситуационных планов и решений на случай отказов?

Или то, что там не используют utm5 и openradius в исполнении наладчиком-одиночкой?

 

 

[TheUser]

35 минут назад, LostSoul сказал:

Вы что конкретно хотите сказать?

Что в крупных компаниях критически важные сервисы не дублируют и продумывают ситуационных планов и решений на случай отказов?

Или то, что там не используют utm5 и openradius в исполнении наладчиком-одиночкой?

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

"openradius-ом" выйти из положения не получится хотя бы потому, что его никто не позволит поставить.

[myth]

ссзб тогда

[LostSoul]

2 часа назад, TheUser сказал:

было с Мегафоном в прошлом году.

с мегафоном была запроектная авария.

а биллинг планово выводится на профилактику и обновление намного чаще , достаточно регулярно.

на работе сети связи это не сказывается.

То что мегафон вместо openradius использует какие-то свои соответствующие масштабу и отрасли погремушки - это понятно.

Но очевидно, что они есть. 

И как-то согласованы и внедрены.

Режимы работы в процессе обслуживания биллинга.

 

Автор темы же похоже не заморочился этим ни на этапе запуска решения,  ни составляя план работ по обновлению.

На авось видимо. А оно не прокатило.