BiTel

Добрый день!
Настраиваю схему:
Bgbilling v5.2
[ISG] - [DHCP Relay] - [Switch Option82] - [Client]
Stage1: Клиенту выдается IP из пула серых адресов (или назначается вручную в бил=биллинге из того же пула) по DHCP c идентификацией, используя Option.82
Stage2: Клиент авторизуется для выхода в Интернет на ISG сервисе (протокол Radius) по серому IP-Адресу, ему выдается реальник из пула (или назначаемый вручную в биллинге).

настраивал по материалами на вики и на форуме.
Использую "ru.bitel.bgbilling.modules.inet.dhcp.InetDhcpProcessor" и "ru.bitel.bgbilling.modules.inet.radius.InetRadiusHelperProcessor"
Сервис "В Интернет по серому IP" навешиваю как дочерний на сервис "Внутрисетевой адрес".
Stage1 успешно проходит, авторизует на устройстве, выдает адрес из пулла или назначаемый вручную!
Stage2 успешно авторизует клиента, после того как он получил адрес по DHCP, выдает ему реальник из пулла.


есть проблемы, подскажите, знающие люди:
1. При перезагрузке BGInetAccess забывает все активные DHCP сессии (выданные адреса). И пока клиент не перезапросит себе IP по DHCP у него не будет работать выход в интернет
Что надо подкрутить, чтобы биллинг помнил клиентов?
(Поведение, что в интернет авторизуем только те ip которые были нами выданы по DHCP полностью устраивает, и именно ради этого поведения такая схема и собирается).

2. В Сервисе "В Интернет по серому IP" прописано ip.resource.category=XX, но биллинг ее игнорирует и не дает назначить на этот дочерний сервис IP адрес из этого ресурса, предлагая выбрать адрес из родительского сервиса. Как объяснить биллингу, что для дочернего сервиса нужно адреса выбирать из другого ресурса?

3. В Сервисе "В Интернет по серому IP" стоит Привязка типов трафика через Radius Acct-Output-Octets, Acct-Output-Gigawords, Acct-Input-Octets и Acct-Input-Gigawords, согласно инструкции (Код вендора -2, код элемента 1 и 2). Но Accounting упорно не хочет заносить информацию со счетчиков в биллинг.
В чем может быть проблема?

В логах есть строки:
Restore connections on InetConnectionKeyMap
Restored connection add ...
Restored connection add ...
?

ip.resource.categoryId нельзя указать в конфигурации типа сервиса, но можно указать в конфигурации устройства так:
ip.resource.categoryId.1,3,5=2
где 1,3,5 - ID типов сервиса, для которых работает указанное значение.


Какие-нибудь другие поля не указаны? Например ServiceName - это фильтр, указывающий, что значение нужно брать только из (ISG-)сервисного аккаунтинга с таким именем (если пусто - то значение берется только из родительского аккаунтинга).

Спасибо, Амир!


Эти строки есть. Проблема была решена установкой на папку с коммутаторами параметров

Для leasetime = 86400
При этом на корневой папке для группы ISG были выставлены иные параметры.
Корневая папка для группы ISG имеет в конфигурации строку со сслыкой на папку с коммутаторами:
device.agentDeviceRootId=320
Это не нарушит работу ISG, переназначив параметры для ISG из конфигурации папки с коммутаторами?
Это нормальное решение или есть более правильный способ, например как то указать DHCP серверу брать leasetime из опций IP-ресурсов?


Спасибо! Помогло.


Поля не заполнены, выглядит так:
(приложил скриншоты)
[/quote]

Этот параметр указывает, где искать агентские устройства (конечные или околоконечные коммутатору). Параметры DHCP-опций же берутся из найденного агентского устройства (если найдено, если нет - из устройства, с которого пришел запрос изначально), учитывая родительские устройства. Получается, что да - сейчас при указании device.agentDeviceRootId параметры DHCP из ISG-устройства не действуют, т.к. он не является родительским.
Можно указать в папке Коммутаторы. Можно эти параметры прописать в Access+Accounting, чтобы работало для всех.
В IP-ресурсах leaseTime наверно лучше не прописывать.


В типе сервиса данная привязка трафика указана?
Сессия в биллинге в состоянии "подключена"?
Попробуйте переключить логирование в режим TRACE, он должен писать после получения UPDATE-пакета:
Add traffic <id>=<количество>.

Добрый день!
Задача похожа. Но исходные данные немного другие:

Есть se600. IPoE L3. Большое количество l3 агрегаций , и маленькое количество белых адресов. Основная масса абонентов за натом. Но некоторым необходим внешник.
Т.к. дробить белую сеть слишком накладно, решили делать "DMZ" (1to1 nat). но тут тоже проблема, ериксон не может получить по радиусу IP для DMZ (ну или по крайней мере мы не нашли как).
Хотелось бы узнать может кто реализовал данную схему. Может есть другие решения.