forum.bitel.ru
http://forum.bitel.ru/

Radius тэгированные атрибуты
http://forum.bitel.ru/viewtopic.php?f=44&t=12338		 Страница 1 из 1
Автор:  mhollow [ 28 мар 2017, 13:11 ]
Заголовок сообщения:  Radius тэгированные атрибуты
Помогите пожалуйста разобраться с тэгированными атрибутами.
Судя по 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) я должен присваивать атрибуту при добавлении в словарь и на основании чего? Или как иначе (значения типов) надлежит использовать?
Спасибо.
Автор:  Amir [ 28 мар 2017, 16:28 ]
Заголовок сообщения:  Re: Radius тэгированные атрибуты
Цитата:
Судя по RFC2868 тэг - это однобайтное поле, которое может принимать значение 0 если оно не используется, или 0x01 through 0x1F, если оно определяет "группу" одинаковых атрибутов в пределах одного пакета.
Нет, это не так. Хорошо бы было, если бы было так просто, но кто-то при создании RFC пожалел один байт. Тэгирование может быть двух видов для строкового типа, и как оно кодируется в пакете для конкретного атрибута как раз описано в этой таблице. И в зависимости от того, как он кодируется, в dictionary.xml указываеться tag="1" или tag="2".

В атрибутах прописываете просто Service-Name:0=, Service-Name:1=, Service-Name:2= и т.п., т.е. просто указываете значение тэга.
Автор:  mhollow [ 28 мар 2017, 16:36 ]
Заголовок сообщения:  Re: Radius тэгированные атрибуты
Как же так, открываю 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)

Что я не понимаю?
Автор:  Amir [ 28 мар 2017, 16:54 ]
Заголовок сообщения:  Re: Radius тэгированные атрибуты
В этом же RFC:
Цитата:
3.3. Tunnel-Client-Endpoint
...
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. If the value of the Tag field is greater than 0x00
and less than or equal to 0x1F, it SHOULD be interpreted as
indicating which tunnel (of several alternatives) this attribute
pertains. If the Tag field is greater than 0x1F, it SHOULD be
interpreted as the first byte of the following String field.

Цитата:
3.5. Tunnel-Password
...
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 value of the Tag field is greater than 0x00 and
less than or equal to 0x1F, it SHOULD be interpreted as indicating
which tunnel (of several alternatives) this attribute pertains;
otherwise, the Tag field SHOULD be ignored.
Автор:  mhollow [ 28 мар 2017, 17:33 ]
Заголовок сообщения:  Re: Radius тэгированные атрибуты
Тогда такой вопрос. Вот взять например атрибут 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 тегированные?
Спасибо!
Автор:  mhollow [ 03 апр 2017, 12:21 ]
Заголовок сообщения:  Re: Radius тэгированные атрибуты
Видимо у ериксон тоже проблемы с документацией :lol:
Автор:  snark [ 05 апр 2017, 14:36 ]
Заголовок сообщения:  Re: Radius тэгированные атрибуты
Если не хотите, как другие, чудес чудных и див дивных, то не используйте RSE - спокойней спать будете.
Автор:  mhollow [ 05 апр 2017, 14:39 ]
Заголовок сообщения:  Re: Radius тэгированные атрибуты
Неужто глюконат?
Автор:  snark [ 05 апр 2017, 15:00 ]
Заголовок сообщения:  Re: Radius тэгированные атрибуты
У кого-то нормально работает, а у кого-то креши бывают - все от железа (SE100/SE600) и от включенных фич зависит. Я не думаю, что вы захотите попасть в ситуацию, например: "а включу ка я xyz... упс! все упало..."
Гораздо проще, спокойнее и надежнее просто навешивать полиси (кроме NAT - его онлайн навесить нельзя) типа
Код:
# ВЫКЛючаем инет
radius.disable.attributes=Forward-Policy=in:HTTP_REDIRECT
# ВКЛючаем инет
sa.radius.enable.attributes=Forward-Policy=in:
# режем скорость
radius.inetOption.1.template=Dynamic-QoS-Param=meter-class-rate ANY rate-absolute $rate;Dynamic-QoS-Param=meter-class-burst ANY $burst;Dynamic-QoS-Param=meter-class-excess-burst ANY $excess-burst;Dynamic-QoS-Param=police-class-rate ANY rate-absolute $rate;Dynamic-QoS-Param=police-class-burst ANY $burst;Dynamic-QoS-Param=police-class-excess-burst ANY $excess-burst
В RSE лично мне видится только один плюс - можно учитывать трафик по направлениям, но я не думаю, что в эпоху скоростных анлимов это важно.
Автор:  Amir [ 05 апр 2017, 15:08 ]
Заголовок сообщения:  Re: Radius тэгированные атрибуты
А что, зря делали поддержку RSE (и ISG - вместо него некоторые тоже предпочитают скорости по другому назначать) что ли? )
А разные скорости для локального трафика и для внешнего через полиси в SE тоже можно?
Автор:  mhollow [ 05 апр 2017, 15:15 ]
Заголовок сообщения:  Re: Radius тэгированные атрибуты
Да можно вроде.
Навесить 91 Sub_Profile_Name а в нем уже в конфигурации SE определить какие угодно полиси включая qos c разными скоростями на различные классы трафика.
Меня RSE привлекает только безразрывным моментом по CoA вместо PoD.
Автор:  snark [ 05 апр 2017, 15:45 ]
Заголовок сообщения:  Re: Radius тэгированные атрибуты
Amir писал(а):
зря делали поддержку RSE что ли?

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

Amir писал(а):
ISG - вместо него некоторые тоже предпочитают скорости по другому назначать

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

Amir писал(а):
разные скорости для локального трафика и для внешнего через полиси в SE тоже можно?

Конечно! Рисуется что-то в духе этого:
Код:
!
 policy access-list QOS_IN
  seq 10 permit ip any <сеть> <маска> class LAN <- сеть для которой скорость резаться не будет
  seq 20 permit ip any any class INET
!
 policy access-list QOS_OUT
  seq 10 permit ip <сеть> <маска> any class LAN
  seq 20 permit ip any any class INET
!
...
!
qos policy RATE_IN policing radius-guided
 ip access-group QOS_IN <context name>
  class LAN <- тут скорость не режется
  class INET
   rate 1048576 burst 201326592 excess-burst 402653184
 rate-calculation exclude layer-2-overhead
!
qos policy RATE_OUT metering radius-guided
 ip access-group QOS_OUT <context name>
  class LAN <- тут скорость не режется
  class INET
   rate 1048576 burst 201326592 excess-burst 402653184
 rate-calculation exclude layer-2-overhead
!
Потом навешивается либо через RADIUS либо прямо в конфиге
Код:
 subscriber (default (для всех) или через "profile <имя профиля>" (для тех кому скажут из RADIUS))
   qos policy policing RATE_IN
   qos policy metering RATE_OUT
Профилями скорость резать не очень удобно, т.к. их менять нельзя, в отличие от скорости, которую из RADIUS можно слать хоть каждую минуту.


mhollow писал(а):
Меня RSE привлекает только безразрывным моментом по CoA вместо PoD.

Достаточно юзеру выдать одни и те же адреса и можно навешивать полиси блокируя и восстанавливая инет "без единого разрыва"(с)
Страница 1 из 1 Часовой пояс: UTC + 5 часов [ Летнее время ]
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/