BiTel

Подскажите пожалуйста по схеме переноса IPN в Inet.

Сейчас в Inet крутится около 300-400 коммутаторов (постепенно увеличивается) на которых реализована похожая схема IPOE.


Хочу перенести IPN в этот же модуль (не создавая отдельного экземпляра и не рисуя новое дерево устройств).

Сейчас в IPN используется следующая схема. На коммутаторах/шлюзах IP заводятся вручную, а netflow собирается с двух цисок. Т.е. нет никакого автоматического включения/отключения абонентов по балансу. Когда то было руление ACL'ками на шлюзах, но там свои глюки и от этого отказались. Т.к. IPOE будет предусматривать описание всех коммутаторов в биллинге - хочу чтобы и IPN был на них же и можно было рулить портами на коммутаторе.
Для IPOE будет использоваться идентификатор коммутатора, а для IPN - IP и порт.

Возможно ли такое? И как это провернуть?
Как для текущего дерева устройств добавить две циски с которых приходит netflow модуля IPN? Куда их приткнуть и собирать трафик?

Сейчас добавил эти две циски чуть ниже в отдельном дереве
и привязал сервис к одной из них.


Так трафик видно. Но как привязать все это дело к коммутатору, и чтобы трафик так же собирался - ума не приложу.
Доку глянул по диагонали - что-то похожего не увидел.

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

Не совсем понял - в обоих схемах используются одни и те же коммутаторы?
Или только нужно трафик привязать к коммутаторам? Если второе:
http://bgbilling.ru/v6.0/doc/ch17s13s05.html
Для того, чтобы указать, что устройство является источником для всех своих дочерних устройств, достаточно в конфигурации типа устройства-источника прописать:
flow.agent.link={@deviceId}:-1
Но не обязательно устройство-источник должно быть родительским ус-вом для коммутатора. Но источник и коммутатор должны быть внутри одного rootDeviceId.

Да, я хотел бы в обоих схемах использовать одни и те же устройства.
Т.к. например один и тот же коммутатор может иметь порты с которых идет IPOE и с которых подключен внешник. Удобно для статистики например. Да и заводить лишние устройства не нужно.

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

Ап.
Так все же лучше использовать отдельный экземпляр модуля (либо отдельное дерево устройств в текущем модуле), или же можно и нужно на одном устройстве держать два различных сервиса?

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

Вроде бы должно работать, если привязки трафиков указать для коммутаторов, т.е. не в CiscoISG или выше, а ниже уровнем.
Например, указать для каждого коммутатора персонально или в типах устройств-коммутаторах или создать папку в CiscoISG и переместить все AGG туда, а в папке указать привязку типов трафика.
ISG сессии привязаны к CiscoISG и будут использовать его flow.agent.link.
Сессии IPN будут привязаны к коммутатору и будут использовать его flow.agent.link.