BiTel

ребят подскажите куда копать

хочу сделать такую схему в модуле inet

устрайства
- access
--flow
pppoe 192.168.0.177
pppoe 192.168.0.154
pppoe 192.168.0.34


как назначать ip ресурсы

нужно выдавать на всех устройствах в зависимости от тарифа
- динамически серые адреса
- динамически белые адреса
- привязвать статикой белые адреса

что для этого нужено :
создавать сервисы или опции или плодить устройства или типы устройств ,но так что бы абоненский отдел не бегал по куче менюшек


на данный момент стоит utm в нем сделано все в тарифе , и в названии тарифа указано что это либо белые динамически либо серые динамические , либо серые статика и в тарифе есть два вида опций (статика и динамика)

Мне кажется можно сделать так:
Статический адрес я так понимаю от тарифа то не зависит на самом деле, и его все равно надо прописывать на сервисе. А вот для задачи динамических серых и белых можно использовать:


Где realm мы задаем в preprocessAccessRequest в зависимости от тарифа.

если на абонента вешаю один роутер, то все ок
если подключаю все , вот что получил.

radius 09-09/08:44:13 DEBUG [rdsLstnr-p-7-t-9] InetAccountingPeriodList - Create:
AccountingPeriod: 12: 05.09.2013 00:00:00.0 - 30.09.2015 23:59:59.999
radius 09-09/08:44:13 INFO [rdsLstnr-p-7-t-9] InetApplication - inetServ[id=26] balance ok: 0.00 [0]
radius 09-09/08:44:13 INFO [rdsLstnr-p-7-t-9] InetApplication - TariffOptionMap: {}
radius 09-09/08:44:13 INFO [rdsLstnr-p-7-t-9] InetApplication - OptionSet: [13]
radius 09-09/08:44:13 ERROR [rdsLstnr-p-7-t-9] InetNas - Not found ip resources inetNas:24 and realm: default!


вероятно из за того я пытаюсь навесить сразу все роутеры на абонента, объединив их в папку, потому как абонент может подцепиться с любого pppoe сервера. а как тогда это разруливать. ?

-- flow
- папка
- 192.168.0.34
- 192.168.0.157
- 192.168.0.177

inetNas:24 это ID папки? Тогда надо прописать в свойствах папки:
radius.realm.default.ipCategories=XXXX

Да так заработало.

странный лог наблюдаю


сделал вот такую схему

-- access
-- flow
--папка серые pppoe (radius.realm.default.ipCategories= 6 ) id 23
192.168.0.34 id 24
192.168.0.157 id 25
192.168.0.177 id 26

странный лог

09-09/09:54:10 INFO [rdsLstnr-p-7-t-1] InetRadiusProcessor - REQUEST_AFTER_PREPROCESS:
Packet type: Access-Request
Identifier: 79
Authenticator: {84 36 4E 99 9D A5 5B B3 88 61 4A 16 C7 24 13 F9}
Attributes:
User-Name=ser-123
CHAP-Password={7D E3 1D C2 03 CF 55 27 A0 75 6F 9B 3E 1F 89 DB 98}
NAS-IP-Address=192.168.0.34
NAS-Port=0
Service-Type=2
Framed-Protocol=1
CHAP-Challenge=)E�h��n~�.������v�<�


9-09/09:54:10 DEBUG [rdsLstnr-p-7-t-1] RadiusProcessor - Create new radius session.
09-09/09:54:10 INFO [rdsLstnr-p-7-t-1] InetNas - Search by username=ser-123
09-09/09:54:10 INFO [rdsLstnr-p-7-t-1] InetRadiusProcessor - [username=ser-123] Authenticated as inetServId:26
09-09/09:54:10 DEBUG [rdsLstnr-p-7-t-1] InetNas - agentRemoteId=null
09-09/09:54:10 DEBUG [rdsLstnr-p-7-t-1] InetRadiusProcessor - Identifier from request: null
09-09/09:54:10 DEBUG [rdsLstnr-p-7-t-1] InetRadiusProcessor - MAC-address from request:
09-09/09:54:10 DEBUG [rdsLstnr-p-7-t-1] InetAccountingPeriodList - Create:
AccountingPeriod: 12: 05.09.2013 00:00:00.0 - 30.09.2015 23:59:59.999
09-09/09:54:10 INFO [rdsLstnr-p-7-t-1] InetApplication - inetServ[id=26] balance ok: 0.00 [0]
09-09/09:54:10 INFO [rdsLstnr-p-7-t-1] InetApplication - TariffOptionMap: {}
09-09/09:54:10 INFO [rdsLstnr-p-7-t-1] InetApplication - OptionSet: [13]
09-09/09:54:10 DEBUG [rdsLstnr-p-7-t-1] IpResourceReserveManager - Deleted 200 old IPs
09-09/09:54:10 INFO [rdsLstnr-p-7-t-1] InetRadiusProcessor - Set ip from pool
09-09/09:54:10 INFO [rdsLstnr-p-7-t-1] InetRadiusProcessor - Write new waiting connection to DB
09-09/09:54:10 INFO [rdsLstnr-p-7-t-1] InetRadiusProcessor - New connection id=1246
09-09/09:54:10 INFO [rdsLstnr-p-7-t-1] InetRadiusProcessor - Return code=0
09-09/09:54:10 INFO [rdsLstnr-p-7-t-1] InetRadiusProcessor - RESPONSE_BEFORE_POSTPROCESS:



почему устройсто авторизации с id 26 ?

в мониторинге все верно , авторизация с 192.168.0.34

InetServId это ID не сервера, а сервиса Посмотрите в договор, какой у вас ID сервиса? Ну совпало вот так вот

не нашел где посмотреть..

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

-- flow
--папка белые (id.cat=xx)
--pppoe 192.168.0.34
--pppoe 192.168.0.157
--pppoe 192.168.0.177

-- папка серые (id.cat=xx)
--pppoe 192.168.0.34
--pppoe 192.168.0.157
--pppoe 192.168.0.177

У абонента подключено устройство {папка белые} , а выдача адресов идет из папки серые. получается что категория подхватывается из последней папки, если в последней папке убираю категорию вообще , то получаю ошибку nas


может выдачу ip делать через типы сервисов и опции ... ?

Сегодня обнаружил, что если на устройстве прописать
radius.realm.default.ipCategories=3, 5
То есть на устройстве выдавать адреса из двух пулов
и соответственно
на интерфейсе 0 выдавать из пула с индексом 3
на интерфейсе 1 выдавать из пула с индексом 5
То на обоих интерфейсах DHCP сервер выдает из пула с индексом 3

Если написать так:
radius.realm.default.ipCategories=5
то на обоих интерфейсах выдает адрес из пула с индексом 5
То есть никак не удается на одном интерфейсе динамически выдать из одного пула, а на другом из другого пула

Вариантов как выдать IP - множество. Вы сами должны решить что вам проще и более подходит к ситуации Я лишь предложил один из вариантов.

всетаки по какой причине адреса выдаются из нижней папки..

уже создал группы, в типах сервисов привязал устройства к группе , на устройствах группы тоже привязаны.

все разобрался.

после того как разделил типы nas для статики и динамики , и динамику разделил на серые и белые.
но в конфиге assess был указан только один typeNAS и конкретно для серых адресов.

сейчас займусь упрощением схемы... уберу группы и типы сервисов.

Интересное решение, а я вчера вывернулся тем что создал два типа сервисов. Один выдает адрес динамически, другой назначает статически (из другого пула адресов).
В общем виде проблему пока не победил

Я делаю один тип сервиса с адресом "Динамический или статический", на случай если вдруг абонент захочет статику - просто добавить ему адрес в серис, а не закрывать старый и открывать новый.

Я с ужасом хочу высказать догадку, неужели когда во вкладке конфигурирования интерфейсов для устройства установка "Категория IP" влияет только на то, что я увижу в списке свободных IP во время назначения сервиса в договоре!???????????
А выдаваться на самом деле IP будут согласно строке конфигурации

хм... может это решение моей траблы.

А этого мало ? Сразу видно свободные адреса для выбора, по моему это здорово. При подключении будет выдаваться либо из договора - если адрес на сервисе повешан, либо из указанного пула. Либо из пула disabled если назначен и сервис отключен.

Это то что нужно! Это гениально как все простое!!!
Осталась одна проблема. На одном интерфейсе я должен выдать из одного пула, на другом интерфейсе из другого пула, на третьем - статику.
я пишу в конфиге устройства

в конфигурации интерфейса
на одном интерфейсе пишу Категорию IP из пула с индексом 3
на другом интерфейсе пишу Категорию IP из пула с индексом 5
Прикол в том что на обоих интерфейсах выдает адрес из пула с индексом 3

Из доки:

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

Спасибо! Все понял

запутался...... (inet 5.2 , последний релиз )

что нужно сделать

схема
3 сервера авторизации по pppoe

какие адреса выдавать на любом из серверов
- из пула динамически серые (к примеру 10.10.10.1/22)
- из пула динамически белые (195.10.10.1/23)
- из пула статикой , привязав на абоненте(91.197.1.0/22)

так сдеал сами устройства


вот описание устройств , категории ip указаны в типе устройства



вот категории

и еще файлики



и абонент



как грамотно навесить ip ресурсы , при условии что мне ненужно привязываться к устройству , т.к. оно может быть любое из 3-х ?



логи

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

09-10/17:26:08 DEBUG [event-proc-p-2-t-1] Nas - activate services: []
09-10/17:26:08 INFO [event-proc-p-2-t-1] NasList - LOADED NAS: Nas id: pppoe-сервера-белые-адреса-динамические; ip: 127.0.0.1

а выдача ip адресов всегда идет из нижней папки.

пробуем сделать два устройства

с указанием категории ip адресов в типе устройства для серых (второй по счету ), а в типе устройства для белых адресов не указываем категории вообще.

на абоненту указываем усторойство именно pppo-cisco-серые 192.168.0.34
тип pppoe-dyn-gray-ip

зачем обработчик лезит в первый по счету nas , можно предположить что он его нашел по совпадению с ip адресом .

и никак не связно с выбор из дерева устройств.

09-11/12:25:22 DEBUG [rdsLstnr-p-7-t-10] RadiusProcessor - Create new radius session.
09-11/12:25:22 INFO [rdsLstnr-p-7-t-10] InetNas - Search by username=ser-123
09-11/12:25:22 INFO [rdsLstnr-p-7-t-10] InetRadiusProcessor - [username=ser-123] Authenticated as inetServId:32
09-11/12:25:22 DEBUG [rdsLstnr-p-7-t-10] InetNas - agentRemoteId=null
09-11/12:25:22 DEBUG [rdsLstnr-p-7-t-10] InetRadiusProcessor - Identifier from request: null
09-11/12:25:22 DEBUG [rdsLstnr-p-7-t-10] InetRadiusProcessor - MAC-address from request:
09-11/12:25:22 DEBUG [rdsLstnr-p-7-t-10] InetAccountingPeriodList - Create:
AccountingPeriod: 12: 05.09.2013 00:00:00.0 - 30.09.2015 23:59:59.999
09-11/12:25:22 INFO [rdsLstnr-p-7-t-10] InetApplication - inetServ[id=32] balance ok: 1000.00 [0]
09-11/12:25:22 INFO [rdsLstnr-p-7-t-10] InetApplication - TariffOptionMap: {}
09-11/12:25:22 INFO [rdsLstnr-p-7-t-10] InetApplication - OptionSet: [13]
09-11/12:25:22 ERROR [rdsLstnr-p-7-t-10] InetNas - Not found ip resources inetNas:33 and realm: default!
09-11/12:25:22 ERROR [rdsLstnr-p-7-t-10] InetRadiusProcessor - Can't reserve ip address!
09-11/12:25:22 INFO [rdsLstnr-p-7-t-10] InetRadiusProcessor - Return code=100
09-11/12:25:22 INFO [rdsLstnr-p-7-t-10] InetRadiusProcessor - RESPONSE_BEFORE_POSTPROCESS:
Packet type: Access-Reject
Identifier: 188
Authenticator: {}
Attributes:
Reply-Message=100
PPPD-Downstream-Speed-Limit=16000
PPPD-Upstream-Speed-Limit=16000

информация о версии:

Клиент: вер. 5.2 сборка 1193 от 23.08.2013 15:50:53
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.6.0_26
ВНИМАНИЕ: Необходимо обновить таймзоны
Сервер: вер. 5.2 сборка 1542 от 11.09.2013 19:48:30
os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.6.0_45

bill вер. 5.2 сборка 310 от 05.08.2013 19:12:17
card вер. 5.2 сборка 203 от 21.06.2013 20:24:27
dba вер. 5.2 сборка 150 от 12.10.2012 20:00:49
dialup вер. 5.2 сборка 381 от 21.08.2013 14:18:48
email вер. 5.2 сборка 172 от 12.10.2012 20:00:52
inet вер. 5.2 сборка 1237 от 11.09.2013 19:48:28
ipn вер. 5.2 сборка 250 от 15.05.2013 12:59:45
npay вер. 5.2 сборка 204 от 15.07.2013 19:23:12
phone вер. 5.2 сборка 273 от 06.05.2013 19:22:16
reports вер. 5.2 сборка 193 от 28.02.2013 10:57:03
rscm вер. 5.2 сборка 172 от 24.04.2013 11:02:54
ru.bitel.bgbilling.plugins.crm вер. 5.2 сборка 199 от 11.09.2013 19:48:46
ru.bitel.bgbilling.plugins.documents вер. 5.2 сборка 150 от 03.04.2013 15:51:27
ru.bitel.bgbilling.plugins.helpdesk вер. 5.2 сборка 178 от 03.04.2013 15:51:27
voiceip вер. 5.2 сборка 208 от 21.08.2013 14:19:09

Сервис ты можешь привязать к любому устройству. Обычно даже привязывается к устройству, к которому физически подключен абонент. Статику прямо в сервис прописывается. А вот насчет выдачи дин.адреса в зависимости от типа сервиса - это уже хороший вопрос, т.к. пулы связаны с устройством, а тут еще надо к типу сервиса привязываться. Такого вроде нет, к разработчикам надо, чтобы добавили параметры устройства например

для типа сервиса 1 выдавать из ресурса 3, для типа сервиса 2 - из ресурса 5. Если параметры не заданы, то берется как обычно из radius.realm.default.ipCategories. Аналогично для DHCP. Думаю фича востребована будет.

2barguzin2 про типы сервисов пока пропустим.. хочу решить вот такую задачу.

один тип сервиса
один тип устройства nas
но разные папки с разными категорими ip адресов


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

вот что получил


для папка белые-1 в конфигурации указано

radius.realm=default,local
radius.realm.default.ipCategories=1 (адреса 10.10.10.1-10.10.10.254)
ip.resource.categoryid=1
#radius.deviceTypeids=3

для папки белые-4 указано

radius.realm=default,local
radius.realm.default.ipCategories=4 (адреса 10.12.12.1-10.12.12.254)
ip.resource.categoryid=4
#radius.deviceTypeids=3

абонент получает адреса из 10.12.12.1-254

и он активен в мониторинге в двух вкладках





после отключения , пропадают обе записи.


что делаю не так ?

ты когда папки меняешь нажимаешь снова кнопку Текущие ? Это на самом деле одна и таже сессия. Разные устройства (по ID) могут быть на самом деле одним и тем же физическим с тем же адресом даже, но не в данном случае этот номер не пройдёт, т.к. это устройство - NAS и при получении радиус-пакета будет биллинг будет находить одно и тоже (с меньшим ID?) устройство. Если это Cisco - то можно попробовать решить задачу так: создаем сервис с Тип адреса: не выделять адрес. В зависимости от условия (тариф и прочее) передаем на NAS через опцию (тарифа или самого сервиса в договоре) радиус-атрибут с указанием имени пула, который сконфигурён на цыске (2 пула белые и серые) и цыска сама выделяет адрес из указанного пула. Хотя надо проверять позволит ли биллинг такое и не выдаст ли ошибку что адрес не назначен, по идее должно сработать, т.к. сервис и не требует адреса, но он придёт в Acc-Start пакете. Ну и опять же схема не фонтан - в случае нескольких НАСов диапазоны адресов нужно делить. Все-таки нужно разработчиков подключать чтобы сделали доп. проверку (писал выше) типа сервиса при выдаче адреса.

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

-- с пулом не прокатит т.к много разных устройств
сейчас работает 2 cisco роутера + 1 linux как резерв + в тестировании redback + L3 switch для IPoE (и все это работает на другом билинге за 20 к а не за ..... рублей , с привязанным пулом через опции на тарифе )


UP разработчики ниид хелп. !!!!

+ можноли вешать через опцию(повесив на тариф) ?
+ или указать pool сразу в сервисе ?
+ ну и почему не рабоате дерево

Почему дерево не сработало - уже сказал, вот приходит Auth-Request с адреса 192.168.0.34, аксес ищет устройство ... таааак... мммм... у меня их 3 и все с этим адресом, какое бы взять... возьму ID=8. Конечно на самом деле не так и аксес скорее всего берет первое попавшееся, хранящееся у него в памяти и ни по какому дереву он не бегает, не за чем. Про пулы тоже сразу отметил что вариант не фонтан. Пул (категория) в сервисе не указывается. Можно указать диапазон, но это не то. Через опцию тоже к разработчикам - еще доп.параметры в устройстве сделать:

Вот уже второй параметр придумали наряду с radius/dhcp.ipCategories.sevType.x. Сначала проверять опции, потом тип сервиса, потом дефолт. И будет полное щщастье.

подожду ответа разработчиков.

up