BiTel

Пробую на тестовом полигоне BGB 6.0 (все обновлено
Ну и пытаюсь перевести свою схему (IPN) на Inet.

В данный момент все клиенты имеют статический IP. Подключены в основном к коммутаторам Dlink. Но есть пока и неуправляемые свичи...
Потихоньку переводим (кого можно) на получение IP по DHCP (свой самописный DHCP-82 сервер на Perl). Хотелось бы перевести на BGB-Inrt-DHCP-82.
Часть клиентов имеет белый IP через VPN. Хотелось бы тоже перевести на BGB-Inet-Radius.
Управление доступом на пограничном шлюзе (Linux, скриптовый шлюз).
NetFlow генерируется на пограничном шлюзе.

В общем, у всех клиентов есть атрибут - статический IP на его физическое подключение. Атрибут этот, бывает, меняется...
Этот атрибут надо использовать также во вложенных устройствах/сервисах (DHCP, Radius, прочее). Его же надо использовать для разбора NetFlow.

Пробую.
Делаю
- тип устройства "IP-type" без обработчиков (не надо ничего обрабатывать).
- сервис "Статический IP": тип адреса - статический; устройство - да, типы устройств - "IP-type"
- устройство "IP" с типом "IP-type" и заданным имеющимся ip.resource.categoryId

Добавляю на договоре модуль Inet, Добавляю сервис "Статический IP", в нем указываю устройство, адрес...
И натыкаюсь, что невозможно указать период владения IP адресом.
Вариант делать период на сервисе не подходит - слишком много придется менять при изменении IP и добавлении нового экземпляра сервиса.

И вот теперь вопрос: как в одном сервисе хранить историю IP? Для обсчета трафика, для разбора полетов обязательно нужно.
Да и изменять на много удобнее указав дату закрытия прошлого и дату открытия нового.
Или переходить на динамические IP? Далеко не всегда получится. Во всяком случае, с белыми IP - нельзя.

Прошу помощи.

PS. Понимаю, что можно смотреть историю по сессиям. Но они стартуют только по трафику или по сигналу (DHCP, Radius).
Есть клиенты, которые в Интернет и не ходят (обходятся локальным ресурсом) - данных по трафику не будет. И DHCP не везде пока возможно. Если бы был вариант старта сессии "Безусловно" - частично бы проблема решилась. Но в любом случае, возможность изменить IP клиента с определенной (будущей) даты очень нужна.

Т.е. есть клиенты, у которых нет DHCP и RADIUS (используется прямое управление коммутатором, по ним идет только netflow) и им часто меняется адрес?

Логичная хотелка.
Я вот думаю, а как будет работать переобсчёт netflow задним числом для таких клиентов, если IP-адрес сменился? Будет пересчитываться трафик по старым, уже созданным сессиям со своими IP, или сессии пересоздадутся уже с новым IP и наработка "поплывёт"?

В том числе и для такой ситуации мы просили у разработчиков дочерние сервисы Мы сделали так - основной сервис используется только для учета device/vlan/port. IP адреса - дочерние по отношению к этому сервисы. А там пожалуйста - указывай какие надо периоды.

Да, такие клиенты есть. Не очень часто, но бывает. При этом, иногда это надо делать будущим числом.

Хотелось бы иметь возможность соорудить такую схему:

- Доступ к сети (параметр - IP, его история, очень желательно чтобы можно было одновременно иметь несколько IP). Дополнительно (при необходимости) - VLAN, свитч/порт (это можно и без истории и в одном экземпляре). Т.е. хранилище параметров физического подключения, для использования всеми подчиненными сервисами.
Подчиненные и при необходимости:
-- DHCP/RADIUS/VPN.
-- NetFlow/SFlow.
-- Что-то свое самописное.

Подчиненные используют текущий набор параметров от вышестоящего. Как дополнительный вариант - возможность переопределения параметров в подчиненном сервисе.

PS. А вообще, как идея... Хотелось бы задавать возможные параметры сервиса (доступные потом в интерфейсе и в обработчике), в конфигурации сервиса.
Где-то так:
param.1.name="Название параметра в интерфейсе" // название в интерфейсе
param.1.type=ip4v // VLAN, int, string, может что-то еще. Может даже выбор значения из справочника-списка?
param.1.histori=1 // параметр с историей или без
param.1.array=0 // возможен или нет набор значений
param.1.default="" // значение по-умолчанию
param.1.parent=1 // наследуется или нет от вышестоящего
param.1.qwerty=0 // 0-3: обязательное или нет, имеет свою настройку в интерфейсе или нет

param.2.name="Другой параметр"
=//=

Ну и потом в обработчике обращаться к значению нужного параметра у конкретного клиента: param.1.value
Понятно, это наверное сильно глобально... Но какая получится гибкость!

Переобсчет - ничего не меняет , он не трогает логи . Переработка - изменит трафики по существующим сессиям, новых сессий не создаст.

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

2 Yagoda, а чем вам этот вариант не устраивает ?




Пусть дочерний сервис это и есть история .

Хм... Такую схему не рассматривали. Должно получиться, но наверное будет несколько неудобнее.
Попробуем.