BiTel

Схема сети:

Клиент - Коммутатор с Opt.82 и управлением портами (DES3200-28) - Коммутатор с Opt.82 (DES3010) - Flow agent - Мир
                                                                                               |
                                                                                         Сервер биллинга

Клиент отправляет dhcp запрос, DES3200-28 отправляет relay запрос на DES3010, тот - на сервер биллинга.
Сервер по giaddr определяет устройство, с которого пришел запрос, далее, т.к. это задано в конфиге - находит дочернее устройство по remote-agent-id (DES3200-28).
По порту(или vlan) определяется клиент, сервис которого привязан к DES3200-28.

Если статус сервиса - открыт и баланс не ниже лимита - создается сессия в биллинге и выдается ip.
dhcp.option.leaseTime (например, равный 360) задается в конфиге устройства/типа устройства.
Если в течении session.close.timeout(например, равный 400) нет dhcp запросов, то сессия закрывается.

Также, вместо блокировки возможно выдавать какой-либо серый ip (аналог reject-to-accept).
Дополнительное управление осуществляется по snmp.

Параметры запуска и дамп базы:
http://www.bgbilling.ru/patch/inet-dhcp82.zip

В качестве access и accounting устройства используется одно и тоже виртуальное устройство с кодом 1 (Access+Accounting).
Поэтому в xml запуска прописано rootDeviceId=1

Скриношоты:

Добрый день!

Я правильно понимаю что это только для 5.2 или можно к 5.1 это прикрутить?

Только для 5.2

А не подскажете какие планы выхода 5.2 в свет? Вот честно - уже слюни текут

Где-то в течении лета выйдет. Если не успеем , то осенью

To: borisk
Ставьте пока отдельно и пробуйте. Зачем ждать.

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

Статья на Wiki: http://wiki.bgbilling.ru/index.php/DHCP ... 0%BE%D0%B2

Господа, наконец-то начал реализовывать подобную схему. В вашей схеме (если я правильно понял) все управление реализовывается на клиентском коммутаторе. У же меня система немного другая:
Клиент -- Коммутатор Opt. 82 -- FreeBSD gw (шейпер, dhcp relay) -- Flow Agent

Поскольку документация пока ну в очень зачаточном состоянии, вопрос следующий. Могу ли я организовать выдачу IP адреса по DHCP (по коммутатор + порт) и шейпирование клиента (FreeBSD) в рамках одного сервиса? Или мне надо будет в договоре указывать 2 сервиса, один для DHCP, а другой для шейпинга?

Нужно создать тип устройства FreeBSD, назначить ему класс активации сервисов, который будет работать с FreeBSD, добавить устройство этого типа и сделать его родительским устройством к коммутаторам. Сервисы же привязывать к комутаторам.
Методы serviceModify и т.п. вызываются по очереди, от родительского устройства к дочернему до устройства к которому привязан сервис.

Точно от родительского к дочернему? То есть получается сначала вызовется модификация сервиса на FreeBSD, а уже потом привязка адреса к DHCP? А если я хочу сделать Reject-to-Accept? Или это в другом месте делается?

А что помешает Reject-To-Accept-у?

Ну тут просто у меня есть непонимание того в какой именно момент и каким сервисом нам выдается адрес. Если бы вы еще чуть-чуть подработали документацию было бы вообще прекрасно

Помогите пожалуйста разобраться с этим решением.

Используем схему:
Клиент - (DES3028) - (Cisco 3750) Сервер биллинга


Дерево устройств выглядит так:

В договоре указан клиентский коммутатор и номер порта.

настройка inet-access.xml

- <context name="dhcp">
- <bean name="dhcpProcessor" class="ru.bitel.bgbilling.modules.inet.dhcp.InetDhcpProcessor">
- <constructor>
<param name="deviceTypeIds" value="5" />
</constructor>
</bean>
<scheduledExecutorService name="hrlydtlggr" corePoolSize="1" />
- <bean name="dhcpDataLogger" class="ru.bitel.bgbilling.modules.inet.dhcp.DhcpHourlyDataLogger">
<param name="scheduledExecutor">hrlydtlggr</param>
</bean>
- <bean name="dhcpListener" class="ru.bitel.bgbilling.kernel.network.dhcp.DhcpListener">
- <constructor>
<param name="host" value="" />
<param name="port" value="67" />
<param name="byteBufferCapacity">512 * 1024</param>
<param name="processor">dhcpProcessor</param>
<param name="dataLogger" />
<param name="threadCount">10</param>
<param name="maxQueueSize">200</param>
<param name="dataLogger">dhcpDataLogger</param>
</constructor>
</bean>
</context>
</application>

сервер дропает запросы с релея:
02-01/16:26:04 WARN [dhcpLstnr-p-12-t-8] DhcpListenerWorker - Device not found for address: xx.xx.110.225, ignoring DHCP request.

Какие нужны обработчики процессов, настройки в устройствах, что бы все взлетело?

C дропами разобрался, нужно было в процесс груп указать dhcp.relay.deviceTypeIds=1,2,3,4.
Теперь такой вопрос, куда вешать настройки дхцп

dhcp.option.serverIdentifier=0.0.0.0
dhcp.option.leaseTime=60
#
dhcp.net.option.193.106.88.0:255.255.255.0.gate=193.106.88.1
dhcp.net.option.193.106.88.0:255.255.255.0.dns=194.165.18.6
#
dhcp.net.option.172.16.24.0:255.255.255.0.gate=172.16.24.1
dhcp.net.option.172.16.24.0:255.255.255.0.dns=194.165.18.6

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

А в типе сервиса тип адреса прописан как статический?

да, в сервисе тип адреса статический.

Настройки DHCP повесил на абонентский коммутатор, dns, mask и gw выдаются, а ip все так же выдается произвольно.


А в логах вылезает такая ошибка:

connection 02-07/16:02:39 ERROR [sa-p-7-t-3] EventWorker - java.util.concurrent.TimeoutException
ru.bitel.bgbilling.common.BGException: java.util.concurrent.TimeoutException
at ru.bitel.bgbilling.kernel.event.AsyncEventWorker.doTasks(AsyncEventWorker.java:92)
at ru.bitel.bgbilling.modules.inet.access.sa.ServiceActivatorWorkerDevice.runWorker(ServiceActivatorWorkerDevice.java:160)
at ru.bitel.bgbilling.kernel.event.EventWorker.internalRunWorker(EventWorker.java:101)
at ru.bitel.bgbilling.modules.inet.access.sa.ServiceActivatorWorkerDevice.runImpl(ServiceActivatorWorkerDevice.java:104)
at ru.bitel.common.worker.WorkerTask.run(WorkerTask.java:86)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
at ru.bitel.common.worker.WorkerThread.run(WorkerThread.java:40)
Caused by: java.util.concurrent.TimeoutException
... 15 more

Все, разобрались, проблемы были из-за не истекшей аренды и включенного dhcp.ipCategories№.
Те на данный момент, если абонент получает адресацию, то пока не пройдет аренда, на другом устройстве он адрес не получит. А можно получить функционал, при котором, если абонент подключает другое устройство текущая аренда будет отозвана и выдана новая?

Со второго декабря в хелпдеске висит пожелание, даже в TODO добавлено

Подскажите, а где указывать параметры конфигураций, описанные тут -http://bgbilling.ru/v5.2/doc/ch15s11s02s01.html?


и вот это где задавать?

Просмотрев скриншоты, догадался куда писать. Но если честно, исходя из документации это совсем не очевидно.
Кстати, ссылка на пример с DHCP.opt82 не работает, zip архив не скачивается.
http://www.bgbilling.ru/patch/inet-dhcp82.zip -

Возникло несколько вопросов.
Первый:
Создал сервис DHCP, вопрос - можно ли прямо в нем указать требуемые пулы из ресурсов IP? Сейчас указал все что нужно в устройстве Access+Accounting.


Второй:
При замене адресов в IP пуле на другие, клиенту продлевается аренда на то, что выдано изначально. Неважно, что уже пул изменился, что несколько раз синхронизированы сервисы, перечитаны конфигурации, перезапущен Access. Пока сессию не сбросишь - ситуация не поменяется. Это я что-то не так делаю?

И последнее:
Указал . Если выбрать у договора статус "Закрыт", то текущая сессия разрывается и договору выдается фейковый IP. Правда он каждую минут выдается следующий по очерёдности (сессия рвется и начинается новая). Фишка в том, что если открыть договор, то последний выданный IP остается навсегда, как во второй ситуации. Как правильно выдавать фейковые IP?

Настройки устройства Access+Accounting

Настройки ресурсов IP

А для чего указывать ресурсы ip в типе сервиса?
При изменении пула dhcp.ipCategories так и должно быть, потому что адрес уже выдался - для чего каждый раз проверять, что ресурсы вдруг изменились?
Однако при изменении статического адреса на самом сервисе сейчас вроде бы тоже ничего не произойдет - вот это уже неправильно.Выложили обновление модуля, должно помочь.

Может просто не обновился?
При обновлении получил такую ошибку:



Я так понял документацию, что IP можно в сервисе указать, но если в устройстве access, то пусть будет устройство.


Ну как, перераспределили пул, по каким-то внутренним причинам или вернуть пришлось. А адреса выданы, придется вручную сбрасывать сессии, чтобы освободить IP.


Сделал update.sh, ничего не обновилось...

не могу качнуть http://www.bgbilling.ru/patch/inet-dhcp82.zip
хочу псм что где и как настраивается..

может есть у кого ? (отпишитесь в личку)

Помогло. При закрытии/открытии договора выдается либо фейковый, либо реальный IP. Все работает правильно. Правда сломалось другое