BiTel

В модуле dialup можно указать различные привязки услуг для различных realm-ов:



Не нашел аналога в Inet.

В инет используются Трафики и Типы трафиков. Можно гибко сопоставить содержимое радиус-атрибута -> тип трафика (в привязке) -> услуга (в тарифе). Но про realm там ни слова.

Пример использования у нас:
Клиент с одним PPPoE-логином может подключаться как напрямую через Ethernet, так и через партнерский CDMA-модем, указав специальный realm. Типа, бэкап. Услуги в реалме другие: "Время подключения (CDMA)", "Вх трафик (CDMA)" и т.п. В одном и том же тарифе прописаны разные цены/настройки для разных услуг.

Как такое реализовать в Inet?

Т.о. привязка зависит:
- в dialup : от nas-а и realm-а
- в ipn : от настройки конкретного диапазона на договоре
- в inet : от типа сервиса

Предлагаю обсудить, с примерами из жизни:
- должна ли привязка зависеть от Nas-а?
- нужна ли возможность задавать индивидуальную привязку для конкретного сервиса (на уровне договора)?

По первому случаю могу привести пример - у нас раньше был классический dial-up, где в зависимости от nas-а время соединения считалось по-разному: услуги "Доступ в интернет (время)" и "Доступ в интернет (время, дорогие пулы)".

По второму - только всякие кривые настройки для связи офисов в модуле IPN (вместе с доступом в инет в схеме vlan-per-user для сабинтерфейса настраиваются роуты на серые подсети, для которых заводятся индивидуальные привязки). Но это очень некрасиво, теперь так не делаем, потом черт ногу сломит в этих гадюшниках. Используем стандартные привязки.

Пока в качестве решения вижу либо дать возможность в ProtocolHandler-е явно указывать в preprocessAccountingRequest(...) используемый id привязки типов трафика:

request.setOption( InetRadiusProcessor.TRAFFIC_TYPE_LINK, 2 );

Хотя тогда realm придётся брать самому из пакета.
...Либо дать возможность указывать привязку в ServiceActivator.onAccountingStart()
Разработчикам должно быть виднее.

up

Может быть достаточно будет указание реалма в правиле, с таким же принципом, как ServiceName?

Хм, да, пожалуй так будет логичнее.

привык костыли делать...

Выложили обновление.

Спасибо!

Ага, а как всё-таки выдавать разные наборы опций в разных realm-ах?


Причём различия между realm-ами небольшие. Например, могут быть недоступны некоторые опции (турбокнопка, локальный трафик), могут добавляться другие опции (дополнительные ограничения по скорости для бэкапа, ACL и т.п.). При этом основная часть остаётся такой же.
Сейчас у нас в dialup тариф выглядит примерно так:
- услуга "Время":
- attr:Inet
- attr:Local
- attr:...
- ...
- тарифная опция 1
- наборы радиус-атрибутов
- тарифная опция 2
- наборы радиус-атрибутов
- ...
- услуга "Время для бэкапа через ОпСоС-а 1":
- attr:Inet
- attr:...
- ...
- тарифная опция 1
- наборы радиус-атрибутов (модифицированные)
- тарифная опция 2
- наборы радиус-атрибутов (модифицированные)
- ...
и т.д.

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

Вижу 2 варианта для модуля Inet:
* В каждом realm - своя услуга "Время", как в dialup. Неудобно, см выше.
* Переопределять радиус-атрибуты для опций в зависимости от realm-а.
Тогда можно будет в нашем realm-е прописать пустой набор атрибутов для Local
Что-то типа такого:

Выложили обновление. Добавили возможность задавать набордля опций набор а:И добавили фильтр по реалмам в тарифе.

Круто, спасибо.


Хм, имхо нарушается абстракция тарифов и сущностей модуля от протокола, но вам виднее...

Возник вопрос: если клиент выходит в realm-е, а в привязке realm не указан - трафик привяжется? Т.е. пустой realm - он для всех работает или только для default?

А зачем вообще привязка трафиков задаётся в типе сервиса, а не в устройстве?

Сейчас, если пусто - тоже самое, что прописано "default"; но можно прописать через запятую несколько реалмов. По аналогии с модулем IPN.

Придумал пример, когда привязка трафика зависит от NAS-а:
Допустим, у нас 3 типа трафика:
- внешний
- локальный
- областной

Считаем их через NETFLOW
Для роутеров в городе A "областной" и "локальный" - это одни диапазоны, а в городе Б - другие.
Тип сервиса - одинаковый (обычный "vlan-per-user") => привязка одна и та же.
Тип устройства - тоже один, по-идее.
Отличаются они только положением в дереве устройств и/или группами устройств.
Как считать трафик в таком случае?
В IPN мы бы задали на диапазоне договора разные привязки трафика, что аналогично заведению в Inet разных типов сервиса с разными привязками:
- сервис "vlan-per-user в городе А" с привязкой "netflow город А"
- сервис "vlan-per-user в городе Б" с привязкой "netflow город Б"
Некрасиво, правда?
Потом начнётся: "кто завёл на договоре города А сервис из города Б?" - нужно разделять типы устройств "роутер netflow города А", "роутер netflow города Б" - хотя сущность одна и та же, либо использовать группы устройств.

Это подобно примеру выше, когда в зависимости от dialup Nas-а устанавливается разная цена на время/трафик, только там сервис не привязан жестко к устройству, поэтому разные типы сервиса не заведёшь. В случае с радиусом появился realm, которого нет для netflow.

Можно сделать так:
завести типы трафика "Областной", "Город А", "Город Б", затем
- в тарифах для города А задавать для "Областной" и "Город Б" услугу "областной трафик", для "Город А" - "локальный трафик"
- в тарифах для города Б задавать для "Областной" и "Город А" услугу "областной трафик", для "Город Б" - "локальный трафик"

Но тогда, во-первых, придётся делать разные тарифы для разных городов, а во-вторых, когда добавится город В, нужно будет прописывать его во всех тарифов городов А и Б.

Ещё мне не нравится текущая привязка трафиков тем, что она зависит от типа устройства. Там фигурируют названия сервисов ISG, например. Я не могу сделать один общий тип сервиса "PPPoE" и подключаться к любым типам устройств PPPoE.

Ещё одна проблема, например, с netflow:
Были типы трафика: "Инет", "Локальный".
Решили сделать новый тариф и добавить трафик "Областной" для него. В остальных остаётся по-старому, т.е. областной трафик должен тарифицироваться как "Инет".
При текущей схеме придётся переделывать все старые тарифы, добавлять в них тип трафика "Областной" туда же, где есть "Инет".

В данном случае круто было бы, если типы трафика были организованы в виде дерева. Типа, если в тарифе не нашли ветку для "Областной", то ищем вышестоящий - "Инет". Как-то так.

В phone есть карты зон, например, но они задаются в тарифе, и используются там же.

По сути, что такое привязка? Это правила, по которым данные о трафике (логика железа) превращаются в данные о типах трафика с точки зрения тарификации (логика обсчёта).

С точки зрения железа (deviceType), привязки бывают:
- привязка для netflow
- привязка для pppoe-mpd
- привязка для Cisco ISG
- привязка для RedBack SE 100

С точки зрения логики обсчёта (тип сервиса? realm?), привязки бывают:
- привязка для VPN
- привязка для Internet
(т.е. тут перечисляются предоставляемые типы услуг, безотносительно типа подключения и вендора устройства)

С точки зрения расположения пользователя (device - конкретное устройство, на котором идёт аккаунтинг конкретной сессии):
- привязка для города А
- привязка для города Б
- привязка для бэкапного канала

Т.е. привязка должна определяться device (сюда автоматом попадает deviceType) и некой сущностью "тип услуги", которая определяется на сервисе.

...to be continued

О, блин, сам же писал уже на эту тему:
viewtopic.php?p=58272#p58272

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

Допустим, у нас в сети есть роутеры с ISG и без ISG. Есть 2 типа траифка: интернет и локальный. Тарифы по трафику с разными ценами на них. На роутерах с ISG мы хотим тарифицировать трафик через аккаунтинг сервисных сессий, а на роутерах без ISG - через netflow.
При этом на роутерах с ISG netflow тоже может быть включён - для построения детальной статистики клиенту. Если сделать один тип сервиса "PPPoE", то для него будет одна привязка, которая должна содержать в себе обсчет и netflow и ISG. Но тогда на роутерах с ISG возможна двойная тарификация. Если сделать 2 типа сервиса: "PPPoE + ISG", "PPPoE без ISG", то позже, если мы решим заменить роутер без ISG на роутер с ISG, придётся заводить всем клиентам сервисы другого типа с теми же реквизитами.
Это не говоря о том, что клиенты вообще говоря могут быть не привязаны к конкретному роутеру, а авторизоваться на любом из них в своём сегменте сети (балансировка нагрузки, например). Или клиенты вообще мобильные.
Можно придумать вариант ещё сложнее - для PPPoE используются роутеры разных вендоров.

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

Ещё вопрос к разработчикам: что вы будете делать, когда кроме netflow и radius добавятся другие типы входных данных о трафике? Добавлять поля в inet_traffic_type_link_rule_<mid>?
Первый кандидат - Cisco usage RDRs.

Ещё пара вопросов:
- Зачем в типах сервисов указываются типы устройств? По коду не нашёл, где это нужно. На договоре всё равно можно привязывать к любому устройству или ProcessGroup.
- Что такое "Атрибуты" у устройства?

По поводу привязок - я думаю, логично в конфиге устройств/типов устройств задавать привязки для каждого типа сервисов:



Текущая схема с заданием привязке в типе сервиса работает по-умолчанию, если не привязка не определяется из конфига устройства.
Т.о. тип сервиса определяет тип авторизации и тип услуги (типы сервиса "PPPoE - Интернет", "PPPoE - VPN", "Vlan-per-user - Интернет"), а привязка определяется по устройству и типу сервиса.

Планировалось как раз ограничение при выборе устройства на сервисе в договоре. viewtopic.php?f=44&t=6995&hilit=+%D0%90%D1%82%D1%80%D0%B8%D0%B1%D1%83%D1%82#p54368

До кучи:
viewtopic.php?f=44&t=8646