BiTel

Помогите пожалуйста разобраться с тэгированными атрибутами.
Судя по RFC2868 тэг - это однобайтное поле, которое может принимать значение 0 если оно не используется, или 0x01 through 0x1F, если оно определяет "группу" одинаковых атрибутов в пределах одного пакета.
Теперь я пытаюсь понять как работает bgbilling c тэгированными атрибутами.

Открываем супер документацию.
https://docs.bitel.ru/pages/viewpage.action?pageId=73596971
Тегированные атрибуты указываются в виде: <NAME>:<TAG>=<VALUE>, например: ERX-Activate-Service:2=testtest.
Тегированный атрибут в словаре должен быть помечен атрибутом tag, который определяет логику для разных типов атрибутов.
Дальше идет Таблица. "Логика тегирования". В которой я сколько бы не перечитывал написанное, смысл до меня упорно не доходит. Вот вроде по русски написано, а что сказать то хотели, я не догоняю.

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

Используется тэг, или нет, клиент обязан указать его значение согласно ВАШЕМУ ЖЕ синтаксису, не используется - пусть ставит 0.
Service-Name:1 = “redirect” - тут тэг = 1
Service-Name:0 = “redirect” - а тут тэг = 0
или, как в вашем примеме ERX-Activate-Service:2=testtest. В данном случае 2 это значение тэга, правильно?
Тогда, объясните пожалуйста для особо одаренных, что означает эта ваша таблица с двумя типами тегов 1 и 2. Если можно на примере. Какие значение (1-2) я должен присваивать атрибуту при добавлении в словарь и на основании чего? Или как иначе (значения типов) надлежит использовать?
Спасибо.

Нет, это не так. Хорошо бы было, если бы было так просто, но кто-то при создании RFC пожалел один байт. Тэгирование может быть двух видов для строкового типа, и как оно кодируется в пакете для конкретного атрибута как раз описано в этой таблице. И в зависимости от того, как он кодируется, в dictionary.xml указываеться tag="1" или tag="2".

В атрибутах прописываете просто Service-Name:0=, Service-Name:1=, Service-Name:2= и т.п., т.е. просто указываете значение тэга.

Как же так, открываю RFC 2868 на который вы ссылаетесь и читаю:
Tag
The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. Valid values for this field are 0x01 through 0x1F, inclusive. If the Tag field is unused, it MUST be zero (0x00).
Русским по белому написано, что это один байт, специально выделенный, никто его не жалел. (The Tag field is one octet in length)

Что я не понимаю?

В этом же RFC:

Тогда такой вопрос. Вот взять например атрибут RedBack VSA 190 Service-Name.
В официальной документации по SEOS он описан так:
String. The name of the service to be activated, together with the following optional fields:
:service id—Used when there is more than one instance of the same service.
service-parameter—Zero or more parameters formatted as name-value pairs. Names and values are separated by an equals sign (=) with no spaces around it. Pairs are separated by spaces. You can also specify service parameters in VSA 192. See VSA 192 for formatting details.

Откуда вообще информация, что это тэгированный атрибут? Там ни слова про тег.
Согласен, в примерах, которые Вы привели из RFC 2868 AV подробно описаны, включая как именно кодировать tag, то из какого описания следует что Service-Name и прочие Service-Options тегированные?
Спасибо!

Видимо у ериксон тоже проблемы с документацией

Если не хотите, как другие, чудес чудных и див дивных, то не используйте RSE - спокойней спать будете.

Неужто глюконат?

У кого-то нормально работает, а у кого-то креши бывают - все от железа (SE100/SE600) и от включенных фич зависит. Я не думаю, что вы захотите попасть в ситуацию, например: "а включу ка я xyz... упс! все упало..."
Гораздо проще, спокойнее и надежнее просто навешивать полиси (кроме NAT - его онлайн навесить нельзя) типа
В RSE лично мне видится только один плюс - можно учитывать трафик по направлениям, но я не думаю, что в эпоху скоростных анлимов это важно.

А что, зря делали поддержку RSE (и ISG - вместо него некоторые тоже предпочитают скорости по другому назначать) что ли? )
А разные скорости для локального трафика и для внешнего через полиси в SE тоже можно?

Да можно вроде.
Навесить 91 Sub_Profile_Name а в нем уже в конфигурации SE определить какие угодно полиси включая qos c разными скоростями на различные классы трафика.
Меня RSE привлекает только безразрывным моментом по CoA вместо PoD.

Почему же зря? Кто-то ведь использует. Вы же не виноваты, в том что заявленная в SE фича может приводить к крешам оного SE.


ISG и RSE - это вещи разного порядка. ISG отвечает, в первую очередь, за весь ААА процесс, а нарезка скорости и/или учет трафика там второстепенны, в то время как RSE - это всего лишь резалка скорости и учитывалка трафика по направлениям (обычный, не RSE аккаунтинг, при использовании RSE все равно идет).


Конечно! Рисуется что-то в духе этого:
Потом навешивается либо через RADIUS либо прямо в конфиге
Профилями скорость резать не очень удобно, т.к. их менять нельзя, в отличие от скорости, которую из RADIUS можно слать хоть каждую минуту.



Достаточно юзеру выдать одни и те же адреса и можно навешивать полиси блокируя и восстанавливая инет "без единого разрыва"(с)