BiTel

Когда планируется добавить поддержку RFC3162 атрибутов в RADIUS? И планируется ли вообще?
Переводить их из бинарного вида и обратно как-то не очень удобно.

уже несколько тем поднималось про ipv6 его планируется(насколько я понял) делать в модуле INET и там радиуса как такового не будет.

_________________

Код:

  Клиент: вер. 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
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

Как это не будет? . Поддержка radius-протокола в inet есть и работает ..Убирать чтоли ?

Поддержки RFC3162 пока нет. В целом планируется.

Эм, не, я имел ввиду что нынешний радиус уберется, а будет тока Inet. Сформулировал как то неверно. =)

_________________

Код:

  Клиент: вер. 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
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

Желательно побыстрее А то железо умеет, а биллинг нет.

Считать трафик IPv6 задачи не стоит, а вот раздавать адреса хотелось бы стандартными средствами, а не через cisco av-pair.

Хотелось бы чтоб хотябы к лету появилось.
Нужно поучаствовать в "World IPv6 Launch" http://www.worldipv6launch.org/

Ну тогда нам нужен тестовый стенд и более-менее подробное описание, как будут адреса выдаваться, т.к. скорее всего понадобиться оптимизировать обработку netflow под ipv6.

Предлагаю сделать это в 2 этапа:
1. Добавить поддержку RFC3162 атрибутов, чтобы можно было вручную в профиле логина их назначать и в логах они в человеческом виде писались.
На этом этапе можно будет протестировать правильность формирования атрибутов и взаимодействие с железом.
Так же можно будет обкатать типовые схемы применения.
2. По обкатанным решениям добавить автоматизацию и учет.
Нетфлов на IPv6 наверное не очень хорошая идея. Быть может не будем тянуть за собой в новый протокол тяжелое наследие прошлого.
Учет лучше делать через RADIUS, например через ISG.

незабывайте что нетфлоу нужно для структур

_________________

Код:

  Клиент: вер. 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
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

Для каких структур? Им нужен СОРМ.
А от детализации по трафику и их и клиентов надо отучать.
"Нет технической возможности".

Эм, а поделитесь как их отучить? потому как по закону должны хранить 3 года, даже если есть сорм.

_________________

Код:

  Клиент: вер. 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
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

По какому закону? Где это прочитать можно?

google.com
Было время задавался вопросом, находится быстро

_________________

Код:

  Клиент: вер. 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
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

Вот так всегда. Все говорят "по закону нужно", но никто не знает, по какому

Фу наивный. Сам же главное на наге это обсуждал и тебе сказали что операторы связи ДОЛЖНЫ хранить
http://forum.nag.ru/forum/index.php?showtopic=63382
Хотя с другой стороны опять таки считать это оказанными оператором услугами связи или нет. вопрос спорный. но почему то я думаю если фейсы к вам обратятся с вопросом предоставления инфы куда и в какое время ходил такой то абонент, и вы ее не предоставите - вас сделают крайним в любом случае

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

Обычно обращаются с вопросом, кто выходил в такое-то время с такого-то адреса. Для этого netflow не нужен.

Не знаю у нас наоборот любят сказать кто из ваших абонентов в такое то время коннектился к такому то IP

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

У них на это СОРМ есть. Вот в нем пусть и смотрят кто и куда коннектился.
В упомянутых "Правилах применения автоматизированных систем расчетов" нигде не расшифровывается что есть информация о соединениях и трафике. Поэтому информацией о соединениях можно считать время начала и окончания сессии, а информацией о трафике - количество байт скачанных за аккаунтинговые периоды.
Инфу об абонентах и первичную информацию, на основании которой производится тарификация хранить надо. Но зачем в качестве такой первичной информации использовать нетфлов? Лучше в качестве первичной информации использовать RADIUS, его логи и хранить. Они занимают гораздо меньше места.