BiTel

Довольно очевидная вещь, на самом деле.

Вот мы хотим задать клиенту скорость в тарифе в модуле Inet. Скажем, 1000kbps
Для этого мы заводим опцию модуля Inet:
INET1000 (id=1)
В конфиге устройства определяем, скажем:


Или, в случае cisco ISG:
- для устройства, на котором авторизуются родительские сессии:

- для устройства, на котором авторизуются дочерние сессии:


Получается, для каждой скорости придётся определять: новую опцию, новые записи конфигов.
Кроме очевидной громоздкости, невозможно задать скорость и другие радиус-атрибуты индивидуально на логине.
Например, в dialup можно задавать персональные радиус-атрибуты для логина прямо на договоре.
Мы этим активно пользуемся для индивидуального роутинга в vpn:


В Inet можно задать для сервиса (логина) только опции, которые настраиваются глобально:


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

Тогда в нашем случае конфиг скоростей выглядел бы так:


В случае cisco ISG:
- для устройства, на котором авторизуются родительские сессии:

- для устройства, на котором авторизуются дочерние сессии:
тут всё сложнее, т.к. сервисы авторизуются на отдельном договоре, где уже нет нашего {$value}. Придётся прописывать вручную все скорости INET1000 в виде сервисов служебного договора. Но даже так, конфиг устройства для основных сервисов сокращается.

Ну и, появляется возможность конфигурировать Framed-Route и прочие атрибуты прямо на договоре:
создаём шаблонную опцию FramedRoute (id=10)
В конфиге указываем nas.radius.inetOption.1.attributes=Framed-Route={$value}
На договоре для сервиса добаляем опцию FramedRoute с нужным значением.

Discuss?

Можно даже не делить опции на параметризованные и нет, а просто не задавать значение параметра, если он не используется.

Да согласен что текущая конструкция громоздкая. И что нужно упрощать. В принципе для начала пойдет и с переменной.

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

А не для начала?

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

По поводу атрибутов роутинга - мне кажется, что логичнее будет шаблон атрибутов в конфигурации типа сервиса:
serv.params.route.title=Route
serv.radius.attributes=Framed-Route={$route}
А из конфигурации serv.params... при редактировании сервиса будут отображаться дополнительная таблица параметров, куда можно ввести значения.

Конфигурацию, наверное, надо упрощать с помощью шаблонов, как сейчас {@value}, что-то подобное, но наоборот.
Кстати, при объявлении сейчас не обязательно указывать @ вначале (@internet.default.attributes=...). Подойдет любой параметр конфигурации.

Резонно.


Вроде нормальный вариант, завтра подумаю.

Да, подходит.
Только естественно записи должны добавляться и удаляться, один и тот же параметр может повторяться несколько раз (cisco-avpair например).
Пустые значения тоже учитываются, мало ли.

Сделаете?

А эти радиус атрибуты нужно выдавать только в Accept?

Да, а где ещё? В CoA точно не надо.
Вообще, правильный ответ на этот вопрос: "так же, как было сделано в dialup".

up

up

Выложили обновление. В конфигурации типа сервиса, например:

inet вер. 5.2 сборка 877 от 11.05.2012 19:35:18

Клиент: вер. 5.2 сборка 981 от 12.05.2012 16:58:19
os: Windows XP; java: Java HotSpot(TM) Client VM, v.1.6.0_29
Сервер: вер. 5.2 сборка 1185 от 11.05.2012 19:35:19
os: Linux; java: Java HotSpot(TM) Client VM, v.1.6.0_27

Добавили 2 параметра для типа сервиса:



На сервисе договора:


В результате выдаётся только один из атрибутов:



Поэкспериментировал - кажется выдаётся последний из списка serv.radius.realm.default.attributes

Другая проблема - если значение атрибута на задано, он всё равно выдаётся с пустым значением. Это не всегда нужно, чаще даже не нужно.

Третья проблема - если для типа сервиса прописано 2 параметра, то только 2 я и смогу задать, ни больше, ни меньше.
На практике некоторые могут не требоваться (см выше), или один и тот же атрибут нужно добавить несколько раз (например cisco-avpair) с разными значениями.
Короче, нужна кнопка "+", как в dialup.

Вот рабочий клиент в dialup:

up

Выложили.

Подразумевалось, что serv.radius.realm.default.attributes= - это шаблон, т.е. работало так:
serv.radius.realm.default.attributes=Framed-Route=$route;Filter-Id=$acl

Чтобы работало так, как хотите, шаблон serv.radius.realm.default.attributes= нужно убрать, вместо него изменить описание параметров:

Спасибо. Работает.
А можно настройки параметров добавить в настройки шаблонов договоров?

Я всё думаю про framed route / ip route атрибуты радиуса...



Хочется, чтобы дополнительные ip-адреса для сессии учитывались в биллинге:
- по ним считался netflow/детализация
- вёлся учёт ip-ресурсов
- выдавался mapping на cisco SCE

В dialup есть что-то такое, но в документации не описано:

(с) http://dbinfo.bitel.ru
В модуле inet для сбора netflow по нескольким диапазонам для одного сервиса есть механизм дочерних сервисов
Было бы круто через дочерние же сервисы выдавать и framed-route/ip route

Это такая идея, nice-to-have.

Можно попробовать прикостылить самим:
- Завести дочерние сервисы двух типов: для framed route и для ip route
- В скриптах ServiceActivator-а на создание/удаление сервиса прописывать соответствующие атрибуты для родительского сервиса.
- В скриптах ServiceActivator-а на создание/удаление сервиса делать mapping на SCE для родительского сервиса

Возникает вопрос: как работает ServiceActivator для дочерних сервисов? Неплохо бы отразить в документации.

Для дочерних сервисов SA не вызывается. В документации отражено.

Ну не совсем не вызывается - не вызывается отдельно. Но при изменении дочернего сервиса вызовется serviceModify родительского, в котором есть информация о дочерних.

О, вот это оптимально, спасибо.

По поводу Framed-Route: есть непротестированный функционал.
Попробуйте создать тип сервиса, который будет дочерним, в его конфигурации указать serv.radius.framedRoute=1, адреса указать подсеть,
добавить сервис с этим типом на договор с выбранной сетью. Тогда в Access-Accept эта подсеть должна выдаться в атрибуте Framed-Route.

По netflow Framed-Route тоже вроде бы должен считать.

Так это прям именно то, что я хочу
Спасибо, потестируем.

Не работает.

По коду:


и больше routeNets нигде не используется

inet вер. 5.2 сборка 962 от 16.08.2012 15:57:53

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

Действительно. Не напомните как нужно формировать?
"192.168.1.0/24 192.168.1.1 1 2 -1 3 400" - подсеть, IP-адрес из Framed-Ip, потом что-то нужно? Для каждой подсети отдельный Framed-Route?

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

Из мануала к SE100:

Cisco мы передаем либо как

либо


В RFC написано следующее.


Для каждой подсети - отдельный framed routing.

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

Было бы здорово иметь, если использовать heredoc, например, такую:

Ну или еще как нить (в кавычки там заключать, если heredoc не нравится), лишь бы было читабельнее и, как следствие, удобнее.

Выложили обновление модуля. В конфигурации NAS'а (или типа устройства):