BiTel

Привет.
BGBilling 6.0.
Вопрос: есть ли возможность делать привязку динамических IP-пулов к типам сервисов? Т.е. что бы клиенты с разными типами сервисов, подключающиеся к одной и той же железке, получали при этом динамические адреса из разных IP-категорий. В инструкции обнаружили только как это проделать со статическими пулами, но интересует динамика. Спасибо.

Нет. Можно только через привязку опций Inet. И назначать опцию статически на сервис в договоре или указывать в тарифе.

А если в предобработчике, по определенному атрибуту радиус-запроса (например, по NAS-port-ID) выставлять определенное значение realm для логина, и дальше уже работать через default.realm.ip.cat? Вообще, планируется какой-то update в данном плане? Я не программист, поэтому все тонкости понять не смогу, но если мы можем определенной строкой в конфиге определить, какой статический пул будет использоваться для определенного типа сервиса, то почему нельзя сделать тоже самое для динамического пула? Ведь на одной железке, особенно если это мощная железка, могут терминироваться несколько тысяч абонентов, а в данный момент им всем придется использовать либо единый пул динамических адресов, что не очень правильно по многим причинам, либо придется проделывать много ручной работы. А если в будущем пул необходимо будет изменить? Придется у каждого из абонентов менять опцию inet в договоре? Даже если это делать через базу данных, все равно получается как то неправильно, как вы думаете?

Начали тестировать нашу идею, но пока безрезультатно. Может, кто что подскажет? Значит, еще раз: мы пытаемся выдавать различным клиентам адреса из разных динамических пулов. Для этого, в предообработчике запросов, основываясь на поле NAS-port-ID добавляем к логину значение realm. Т.е. получается нечто такое:



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



В конфигурации устройства добавляем:



Но, при попытке подключения мы получаем ошибку 80:


Собственно, вопросы: можно ли в принципе таким вот образом разделять ip-ресурсы? И если да, то что у нас не так?

Забыл, можно попробовать так:

Попробуйте указать через тариф.

Например, создать базовый тариф, который будут расширять другие.
В нём указать ветки:
-- Фильтр по типу сервиса "Другой сервис"
---- Опция "Другой пул"

И настроить пул через опцию Inet:
https://docs.bitel.ru/pages/viewpage.action?pageId=43385867#id-Процессорru.bitel.bgbilling.modules.inet.radius.InetRadiusProcessor-ВыдачаIP-адреса

Желательно, чтобы был установлен также connection.start.fromAccept=1

Этот вариант рассмотрим, попробуем. А что насчет realm-ов? Описанная нами схема вообще работает? Она фигурирует в документации, может быть мы просто что-то не так делаем?

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

Должно работать. По крайней мере, если не добавлять реалм скриптом.
Может быть не нажали "Перечитать конфигурацию" или категория неправильная прописана?

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

Такого (чтобы назначать пулы на разные типы серисов) вроде никто не просил еще.

Чуть вмешаюсь. Коллега aneye имеет в виду, что есть, к примеру один тип сервиса - PPPoE, в его (сервиса) конфиге



Обработчик протокола в зависимости от того, что прилетает в параметре Nas-Port-Id, а конкретно vlan (их ограниченное кол-во),
изменяет User-Name, добавляя realm (и судя по логам это работает).
Далее, в соответствии с документацией, добавляем в конфиге устройства


в надежде, что после этого юзер cisco3@smr получит ip из категории 12, однако получаем приведённую выше ошибку.

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

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

_________________
Клиент: вер. 7.1.206 / 15.08.2019 22:37:24
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_181
Сервер: вер. 7.1.1144 / 15.08.2019 22:39:22
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_181

Типов сервисов может быть гораздо меньше. Если мы будем для каждого пула заводить отдельные опции inet, то при имеющихся 20-30 опциях, которые определяют разную скорость доступа для клиентов, мы получим 60, а если нужен будет еще пул - уже 90, и так далее. Типов сервисов может быть всего два: например, PPPoE-City-A и IPoE-City-A, и тоже самое для City-В, если мы говорим, например, о географическом разделении между двумя городами. Терминироваться клиенты обоих городов будут на одном устройстве (актуально для городов из одной области, а железка в центре), но при этом пулы для них будут разные.

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

Соответственно можно и тип сервиса оставить один, а в тарифе вместо фильтра по типу сервиса использовать фильтр по группе договора.

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

Да.

Две опции с id соответственно 42 и 43.
В конфиге Access+Accounting



В сервис на договоре довешиваем опцию IP_POOL_SMR с id=42.

Конфигурация перечитана, сервис access перезапущен.

Ошибок в логе нет, при подключении выдаётся ip из дефолтной категории 8.
Как-то это не работает. Не исключаю ошибку в нашем конфиге, но куда посмотреть?

+ Да же если это заработает, это означает опция=пул, опять же лишнее на договоре, а уж в тарифе и подавно.
Опять же, по приведённой вами ссылке - [url]https://docs.bitel.ru/pages/viewpage.action?pageId=43385867#id-Процессорru.bitel.bgbilling.modules.inet.radius.InetRadiusProcessor-ВыдачаIP-адреса[/url]
написано следующее "... Если же опция будет не активна - то адрес будет выдан из параметра radius.realm.<realm>.ipCategories=<cat_codes>, если он указан..."
Вот это <realm> - оно работает как в инструкции, или у нас где-то косяк в настройке.
Нам, для реализации задачи, этой функциональности на данный момент достаточно (и удобно).
Вот то - с чего начиналась тема.

Куда покопать, как попробовать отладить чтоб приблизиться к результату?

_________________
Клиент: вер. 7.1.206 / 15.08.2019 22:37:24
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_181
Сервер: вер. 7.1.1144 / 15.08.2019 22:39:22
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_181

Продолжим.
Основываясь на одной старой теме с этого же форума:
https://forum.bitel.ru/viewtopic.php?f=44&t=8426&start=30
а также на документации:
https://docs.bitel.ru/pages/viewpage.action?pageId=43385867#id-%D0%9F%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81%D0%BE%D1%80ru.bitel.bgbilling.modules.inet.radius.InetRadiusProcessor-%D0%92%D1%8B%D0%B4%D0%B0%D1%87%D0%B0IP-%D0%B0%D0%B4%D1%80%D0%B5%D1%81%D0%B0
методом проб и ошибок определено, что ниже следующее НЕ РАБОТАЕТ:

Имеется опция inet с кодом 42. Она навешана в дополнение к основной опции на договоре у клиента.

Головное устройство (access+accounting):


Дальше, пробовали в самой опции указать radius.realm.default.ipPool=POOLNAME, или же в конфигурации головного устройства: radius.inetOption.42.default.ipPool=POOLNAME (хотя, стоит отметить, что этих пунктов в документации, по крайней мере в той, на которую была дана ссылка выше - нет).

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


Т.е. либо этот функционал в версии БГ 6.0 не работает в принципе, либо в документации упущен какой-то момент, который позволяет данному функционалу работать.

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

прописан на устройстве

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

Я тут упустил про "если не добавлять реалм скриптом ".
А как он там появится, не у клиентов же такие логины делать, а потом если что менять?
Сомневаюсь что какая-нить cisco на терминации сумеет сама дописать такое, да ещё по условиям.
Или смысл не в этом? Да и собственно судя по логу реалм то виден нормально.
В темах на форуме и в вики в конфигах поголовно realm.default. Ни кто не пользует?
Кто нибудь может подсказать куда смотреть, может на что в конфиге внимание обратить?
Хотя там вроде 2-3 строчки за это отвечают.

_________________
Клиент: вер. 7.1.206 / 15.08.2019 22:37:24
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_181
Сервер: вер. 7.1.1144 / 15.08.2019 22:39:22
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_181

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

Пока странно, что ни с реалмом, ни с опцией у вас адреса из указанного пула не выдает.

В случае подмены реалма, нужно будет подменять его и во всех Accounting-пакетах, а не только в Access-REQUEST.

Так, товарищи, это был глюк. В какой-то момент, так как рабочего решения с разными пулами не находилось, мы решили использовать более большой пул как дефолтный. И... он не заработал! Т.е. мы указали в конфигурации головного устройства radius.realm.default.ipCategories=12 - и при подключении стали получать аналогичные ошибки. При этом, старый пул, radius.realm.default.ipCategories=8 - работал. Проверили все - все было настроено верно. Удалили из категории диапазон и создали его заново - и оно заработало. После этого, попробовали нашу схему с предобработчиком и разными realm-ами на основе NAS-port-ID - и она тоже заработала.

Как уже сказал коллега aneye, это был какой-то пока необъяснённый глюк.
Да, конечно, realm правится и для access, и для accounting пакетов. Будем тестировать схему.
Всем спасибо за помощь.

_________________
Клиент: вер. 7.1.206 / 15.08.2019 22:37:24
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_181
Сервер: вер. 7.1.1144 / 15.08.2019 22:39:22
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_181