В связи с переходом на 16 версию возник следующий вопрос - как сделать, что бы пользователям pppoe трафик обсчитывался исходя из данных radius, а не netflow. (т.е. по пакетам INPUT_OCTETS и OUTPUT_OCTETS)???
В текущем варианте пользователи авторизуются по radius, а обсчет трафика происходит через netflow.
PPPOE Radius Аккаунтинг
Документация на сайте обновилась (pdf) - http://www.netup.ru/download/UTM5_1_10_nov2005.pdfRAMses писал(а):Блин, ну что, никто не поможет в таком трудном деле??? Разработчики в документацию эту фичу не вносят, оправдываясь тестированием.
Описание тарификации с динамическимим адресами описано на странице 61.
Меня интересует немного другое:
в данный момент адреса раздаются через радиус, но они привязаны к пользователю (т.е. юзеру всегда выдается один и тот же адрес). Обсчитывается это все через netflow.
Теперь же я хочу перевести на обсчет по радиусу. Как это сделать?? Что изменить в тарифных планах или классах трафика???
Более того, хочется перевести всех на динамические адреса.
в данный момент адреса раздаются через радиус, но они привязаны к пользователю (т.е. юзеру всегда выдается один и тот же адрес). Обсчитывается это все через netflow.
Теперь же я хочу перевести на обсчет по радиусу. Как это сделать?? Что изменить в тарифных планах или классах трафика???
Более того, хочется перевести всех на динамические адреса.
В случае если сервер доступа не поддерживает экспорт статистики по протоколу NetFlow, то данные по потребленному трафику можно получить из Radius-Accounting Stop пакета. Для использования этого механизма необходимо добавить в интерфейсе администратора в разделе «Настройки» переменную radius_do_accounting с установленным значением равным 1. Таким образом при получения Accounting Stop пакета RADIUS-сервер создаст два NetFlow пакета, которые далее будут тарифицироваться в ядре биллинговой системы по стандартному механизму. В первом NetFlow-пакете в качестве адреса отправителя будет значиться IP-адрес сервера доступа, а в качестве получателя будет указан IP-адрес абонента использованный в данной сессии. Количество потребленных байт будет равно значению атрибута Acct-Input-Octets (42) из Accounting Stop пакета. Во втором NetFlow-пакете в качестве адреса получателя будет значиться IP-адрес сервера доступа, а в качестве отправителя будет указан IP-адрес абонента использованный в данной сессии. Количество байт будет равно значению атрибута Acct-Output-Octets (43) из Accounting Stop пакета.
Стоит так же отметить, что пока "Radius interim update" не поддерживаетсяи его необходимо отключить на сервере доступа. В будующих релизах планируется поддержка этого типа пакетов.
Стоит так же отметить, что пока "Radius interim update" не поддерживаетсяи его необходимо отключить на сервере доступа. В будующих релизах планируется поддержка этого типа пакетов.
Тогда встречный вопрос - как биллинг поймет, что этот траф идет на этого юзера, а не на другого???
Получается трафик на сервер доступа и с сервера на клиента. Как эти записи ассоциировать непонятно.
Может прикрутить к радиус-серверу функционал, который будет склеивать оба пакета???
И когда ожидается поддержка промежуточных обновлений???
Получается трафик на сервер доступа и с сервера на клиента. Как эти записи ассоциировать непонятно.
Может прикрутить к радиус-серверу функционал, который будет склеивать оба пакета???
И когда ожидается поддержка промежуточных обновлений???
"при получения Accounting Stop пакета RADIUS-сервер создаст два NetFlow пакета, которые далее будут тарифицироваться в ядре биллинговой системы по стандартному механизму" т.е. определение класса трафика будет происходить по стандартному мехнаизму.RAMses писал(а):Тогда встречный вопрос - как биллинг поймет, что этот траф идет на этого юзера, а не на другого???
Получается трафик на сервер доступа и с сервера на клиента. Как эти записи ассоциировать непонятно.
Может прикрутить к радиус-серверу функционал, который будет склеивать оба пакета???
И когда ожидается поддержка промежуточных обновлений???
Например, можно завести два класса:
10 Входящий интернет от IP-адрес НАСа к сети, которая выдается клиентам
20 Исходящий от сети, которая выдается клиентам к IP-адресу НАСа.
Соотнесение на пользователя будет происходить так же по обычному механизму. Ядро биллинговой системы просматривает адреса привязанные к абонентам и находит кому соответсвует этот трафик.
Как проходит тарификация проще посмотреть в документации - http://www.netup.ru/download/UTM5_1_10_nov2005.pdf
По поводу "склеивания" пакетов - зачем ? У нас два разных трафика - incoming и outgoing. Как в одном NEtFlow пакете указать две цифры отвечающие за количество байт ?
По поводу поддержки interim update - по срокам пока к сожалению сориентировать сложно. Постараемся в ближайшее время сделать ... Там проблема в том, что в каждом апдейт пакете высылается сумма всего потребленного трафика по данной сессии т.е. нужно брать разницу от предыдущего апдейт пакета.
Так и есть. Это вытекает из того, что в радиус пакете только два поля bytes in и bytes out без разбивки по адресам источника и получателя. Аналогичная ситуация и с SNMP. Это в "природе" данных протоколов и тут ничего поделать нельзяRAMses писал(а):Ок. Согласен, тарификацию сделать можно.
Но тогда встает вопрос, как разделить трафик? Есть не только внешний, но и специальный и еще пара видов трафика. Классификация базируется на адресах.
В случае с радиусом, по-моему, это сделать невозможно.
Поэтому если необходимо тарифицировать с учетом направленичя трафика, то необходимо использовать NetFlow либо ip-accounting либо другой, который дает разбивку по адресам (тот же sFlow, например).