forum.bitel.ru
http://forum.bitel.ru/

Логика работы модуля
http://forum.bitel.ru/viewtopic.php?f=44&t=11986		 Страница 1 из 1
Автор:  ok-2004 [ 06 окт 2016, 12:52 ]
Заголовок сообщения:  Логика работы модуля
Добрый день!
Чота совсем запутался....
Прошу прояснить некоторые мои непонятки по логике модуля INET

Непонятка 1:

Из документации мы знаем, что
Цитата:
Текущий статус сервиса( выставляется в ручную ):
0 - Открыт
1 - Закрыт
2 - Заблокирован

Реальное состояние сервиса на устройстве( выставляется автоматом ):
1 - Подключён
0 - Отключен
-1 - Удалён

Состояние сервиса на устройстве - "подключен" , когда в договоре установлен активный для него статус(contract.status = 0) и сервис в статусе открыт(inet_serv_?.status=0) и баланс больше лимита.


Логично предположить , что cостояние сервиса на устройстве - "отключён", когда contract.status <> 0 и inet_serv_?.status <> 0 и баланс меньше лимита.

Вопрос 1:
При каких условиях состояние сервиса на устройстве переходит в состояние "Удалён" ?

Непонятка 2:

Есть некое устройство типа "микрОтик через апи" , которым BGInetAccess управляет такими командами:

Код:
# Группа 1: Команды создания сервиса на устройстве
sa.command.serv.create.1=/ip/firewall/address-list/add\n=address=$ip/29\n=list=ACCESS_LIST\n=comment=!!$servId!!\n=disabled=yes
sa.command.serv.create.2=/queue/simple/add\n=max-limit=0/100M\n=target=vlan$vlan\n=name=vlan$vlan\n=comment=vlan$vlan
# Группа 2: Команды включения сервиса на устройстве
sa.command.serv.enable=/ip/firewall/address-list/enable\n=numbers="!!$servId!!"
# Группа 3: Команды выключения сервиса на устройстве
sa.command.serv.disable=/ip/firewall/address-list/disable\n=numbers="!!$servId!!"
# Группа 4: Команды удаления сервиса с устройства.
sa.command.serv.cancel.1=/ip/firewall/address-list/remove\n=numbers="!!$servId!!"
sa.command.serv.cancel.2=/queue/simple/remove\n=numbers=vlan$vlan


Вопрос 2а:

При каких условиях вызываются команды из группы 1 :
a. При создании сервиса в договоре клиента ?
б. При первом переводе статуса сервиса в состояние "Открыт" ?

Вопрос 2б:

При каких условиях вызываются команды из группы 4 :
а. При ручном переводе статуса сервиса в состояние "Заблокирован" ?
б. При переходе состояния сервиса на устройстве в состояние "Удалён" ?

Непонятка 3:

В терминах модуля INET существует три сущности:
1. "соединение (connection)" - предоставляет клиенту услуги доступа в инет через BGInetAccess.
2. "сессия(session)" - тарифицирует предоставление этих услуг через BGInetAccounting в рамках этой connection.
3. "сервис" модуля INET в договоре клиента - связывает первые две сущности.

Вопрос 3:
Правильно ли я понимаю что сущность "соединение (connection)" - это и есть "Реальное состояние сервиса на устройстве". ?


Если так ,то для управления доступом в инет надо использовать команды
из серии sa.command.connection/enable/disable/close а не sa.command.serv.enable/disable ?
Автор:  barguzin2 [ 06 окт 2016, 16:32 ]
Заголовок сообщения:  Re: Логика работы модуля
Удален - когда сервис закрывается по периоду. В этом же случае и вызываются команды удаления.
Команды создания выполняются при добавлении сервиса в договор.

connection - это connection, например PPPoE, PPTP. StaticIP - это сессия, у неё нет коннекшина. sa.command.connection вызываются для перевода текущего подключения из состояния в состояние, в зависимости от схемы. В вашем случае нужно вызывать sa.command.serv.enable/disable, хоть у неё и могут быть коннекшины, они останутся висеть, но доступ будет закрыт/открыт.
Автор:  ok-2004 [ 07 окт 2016, 08:55 ]
Заголовок сообщения:  Re: Логика работы модуля
Цитата:
Удален - когда сервис закрывается по периоду. В этом же случае и вызываются команды удаления.
Команды создания выполняются при добавлении сервиса в договор.

Окъ, понятно...
Цитата:
StaticIP - это сессия, у неё нет коннекшина

А вот здесь я с Вами пожалуй не соглашусь. У staticIP и инициализации сессии по нетфлоу тоже есть понятие коннекции.
Например в рамках одной коннекции - сессии разрываются на границе суток или когда изменяются инет-опции.
Цитата:
sa.command.connection вызываются для перевода текущего подключения из состояния в состояние, в зависимости от схемы.

Т.е у коннекции кроме состояния - "вкл/выкл" могут быть какие-то промежуточные состояния ?
Интересно как это повлияет на текущие сессии , принадлежащие этой изменившей своё состояние коннекции ?
Они прервутся ?
Или Вы допускаете мысль, что команды "sa.command.connection" призваны затрагивать такие состояния коннекции, которые не меняют параметров тарификации и следовательно - нет в таких случаях нужды рвать сессии ?

Очень интригует... очень. Хотелось бы посмотреть на такие состояния коннекции, которые не меняют параметров тарификации и не рвут сессии.
Цитата:
нужно вызывать sa.command.serv.enable/disable, хоть у неё и могут быть коннекшины, они останутся висеть, но доступ будет закрыт/открыт.

Мой слабый мозг отказывается понимать эту сложную логическую конструкцию.
Т.е когда я к примеру закрываю юзеру фильтрами на микрОтике доступ в инет - я не рву при этом его коннекцию на этом устройстве ?
Вы опять перевернули моё представление о логике работы модуля INET на 180 гр.
Автор:  barguzin2 [ 07 окт 2016, 09:18 ]
Заголовок сообщения:  Re: Логика работы модуля
Цитата:
А вот здесь я с Вами пожалуй не соглашусь. У staticIP и инициализации сессии по нетфлоу тоже есть понятие коннекии.
Например в рамках одной коннекции сессии разрываются на границе суток или когда изменяются инет-опции.

Вот именно, стартует и делится СЕССИЯ, а не коннекшин. StaticIP ни к чему не коннектится и connection close (disconnect) ему не сделаешь, т.к. его нет.

Разрывать коннекшины или нет - зависит от схемы подключения и оборудования. Например, если для микротика вы скорость навешиваете через выдачу радиус-атрибутов, то для её изменения нужен дисконнект, т.к. он не умеет CoA. Если отключенцам выделяете адреса из определенного пула и не используете правила фаервола - тоже нужен дисконнект. Cisco ISG, RedBack, Accel-PPP умеют CoA, там дисконнект не нужен.

Рвутся не сессии, рвутся коннекшины. Сессии делятся на границе суток, в рамках одного долгого коннекшина может быть несколько сессий.

Вы расскажите что у вас за схема, кто куда подключается и что хотите - тогда будет проще ориентироваться и предлагать какие-то схемы.
Автор:  ok-2004 [ 09 окт 2016, 12:58 ]
Заголовок сообщения:  Re: Логика работы модуля
Цитата:
Вы расскажите что у вас за схема, кто куда подключается и что хотите - тогда будет проще ориентироваться и предлагать какие-то схемы.


Хм...
Обычно посты дальше 13-ой строки превращаются по свежести восприятия в чтение перед сном школьного сочинения на тему:
"Метафизика гендерной вербальности среди жестошёрстных беспозвоночных в пике сезонного анабиоза."

Значит надо как-то кратко и ёмко обяснить....
Наверное так:

Исходные данные:
1. В параметрах сервиса в договоре клиента определяются только 3 параметра: ип инет-шлюза, ип клиента, влан клиента.
2. Значения ограничения скорости берутся из тарифа (InetOption).
3. Все тарифы - анлим. Диапазоны времени и объёмы трафика в них не фигурируют.
4. Доступ в инет клиента обеспечивается стандартным способом - добавлением его ипа в разрешающий адресс-лист.
5. Резка скорости - навешиванием "простой" очереди на его влан.
6. Сессии в пределах этой конекции делятся только при переходе суток, либо по таймауту нетфлоу.
7. InetOption в пределах одной коннекции не меняются, значит и деления сессий по этому признаку в этом случае нет.

Задача:
8. Некоторым клиентам иногда добавлять их ип-ы ещё в один адресс лист.
9. Этот адресс-лист делает Source-Based PolicyRouting для ип-ов этих клиентов.
10. При этом существующие коннекции и сессии не должны разрываться и делиться. Нетфлоу потоки прерыватся не будут.
11. Делать это надо из биллинга.

12. В наборе средств есть только :
http://wiki.bitel.ru/index.php/%D0%9E%D ... krotik_api)_%D0%BE%D0%B1%D1%80%D0%B0%D0%B1%D0%BEВ
13. Наличие ип-а клиента в этом адресс листе не должно зависить не от статуса договора. не от статуса или состояния сервиса.

Кто может подкинуть хотя бы идею реализации этой задачи ?
Автор:  barguzin2 [ 10 окт 2016, 11:58 ]
Заголовок сообщения:  Re: Логика работы модуля
Итак, еще раз - коннекшинов у вас НЕТ!!! и sa.command.connection в вашем случае неприменимы. Есть только сессии, стартующие по трафику. Для коннекшинов есть отдельная таблица inet_connection_{mid}, можете посмотреть - для этих клиентов записей не найдется.

Для решения задачи напрашивается навешивание дополнительной опции прямо на сервис, но опция, вроде, деактивируется при блокировки сервиса, хотя если доступ заблокирован - это не должно смущать, зачем пункт 13 тогда?
Автор:  ok-2004 [ 10 окт 2016, 12:32 ]
Заголовок сообщения:  Re: Логика работы модуля
Код:
mysql -uroot -ppassword -e "select * from inet_session_10 where connectionID in (select id from inet_connection_10 where deviceId=35) order by connectionID;" bgbilling
+---------+----------+------------+--------------+---------------------+-------------+---------------------+-------------+-------------+-------------+--------+
| id      | parentId | splittedId | connectionId | sessionStart        | sessionStop | lastActive          | sessionTime | sessionCost | deviceState | status |
+---------+----------+------------+--------------+---------------------+-------------+---------------------+-------------+-------------+-------------+--------+

| 7387942 |        0 |    7384698 |      5314119 | 2016-10-07 00:00:00 | NULL        | 2016-10-07 08:06:05 |       29165 |     0.00000 |           1 |      1 |
| 7387737 |        0 |    7384728 |      5314149 | 2016-10-07 00:00:00 | NULL        | 2016-10-07 08:06:13 |       29173 |     0.00000 |           1 |      1 |

Как видите - коннекции есть.

Код:
mysql -uroot -ppassword -e "select * from inet_connection_10 where id=5314119;" bgbilling
+---------+----------+----------+------------+---------------+-----------+---------------+----------+------+------------+--------+-----------------+------------------+--------------+-----------+---------------------+-------------+---------------+--------+
| id      | parentId | deviceId | devicePort | agentDeviceId | circuitId | acctSessionId | username | type | accessCode | servId | calledStationId | callingStationId | ipResourceId | ipAddress | connectionStart     | deviceState | deviceOptions | status |
+---------+----------+----------+------------+---------------+-----------+---------------+----------+------+------------+--------+-----------------+------------------+--------------+-----------+---------------------+-------------+---------------+--------+
| 5314119 |        0 |       35 |         14 |             0 | NULL      | NULL          | NULL     |    2 |          0 |  11389 | NULL            | NULL             |            0 | NULL      | 2016-10-06 09:29:30 |           1 |               |      1 |
+---------+----------+----------+------------+---------------+-----------+---------------+----------+------+------------+--------+-----------------+------------------+--------------+-----------+---------------------+-------------+---------------+--------+

servId=11389 - как раз id сервиса клиента, у которого сработали на устройстве правила прописанные в начале треда.
Автор:  barguzin2 [ 10 окт 2016, 13:24 ]
Заголовок сообщения:  Re: Логика работы модуля
Все равно огорчу - это фиктивные коннекшины, для унификации. Для StaticIP не нужно никаких телодвижений, интернет есть и всё. Для PPPoE, PPTP, прочих VPDN нужно сначала установить ПОДКЛЮЧЕНИЕ (которое можно сбросить на оборудовании), и только потом будет щщастье. Даже DHCP требует первичного диалога. Я вот про что. Дальнейшую дискуссию на эту тему продолжать не буду. Схему решения предложил - через отдельную опцию, помимо скорости.
Автор:  vdd [ 20 окт 2016, 13:45 ]
Заголовок сообщения:  Re: Логика работы модуля
Вдруг кто не в курсе
Цитата:
Например, если для микротика вы скорость навешиваете через выдачу радиус-атрибутов, то для её изменения нужен дисконнект, т.к. он не умеет CoA.

http://www.mikrotik.com/download/changelogs/ What's new in 6.33rc37 (2015-Oct-30 13:04): писал(а):
ppp - added CoA support to PPPoE, PPTP & L2TP (Mikrotik-Recv-Limit, Mikrotik-Xmit-Limit, Mikrotik-Rate-Limit, Ascend-Data-Rate, Ascend-XMit-Rate, Session-Timeout);
Автор:  a.vozny [ 16 ноя 2016, 13:47 ]
Заголовок сообщения:  Re: Логика работы модуля
в словарике есть сторик
Код:
         <vendor code="14988" name="Mikrotik">
                    <attribute name="Mikrotik-Recv-Limit" type="integer" code="1" />
                    <attribute name="Mikrotik-Xmit-Limit" type="integer" code="2" />
                    <attribute name="Mikrotik-Group" type="string" code="3" />
                    <attribute name="Mikrotik-Wireless-Forward" type="integer" code="4" />
                    <attribute name="Mikrotik-Wireless-Skip-Dot1x" type="integer" code="5" />
                    <attribute name="Mikrotik-Wireless-Enc-Algo" type="integer" code="6" />
                    <attribute name="Mikrotik-Wireless-Enc-Key" type="string" code="7" />
                    <attribute name="Mikrotik-Rate-Limit" type="string" code="8" />
                    <attribute name="Mikrotik-Realm" type="string" code="9" />
                    <attribute name="Mikrotik-Host-IP" type="ipaddr" code="10" />
                    <attribute name="Mikrotik-Mark-Id" type="string" code="11" />
                    <attribute name="Mikrotik-Advertise-URL" type="string" code="12" />
                    <attribute name="Mikrotik-Advertise-Interval" type="integer" code="13" />
                    <attribute name="Mikrotik-Recv-Limit-Gigawords" type="integer" code="14" />
                    <attribute name="Mikrotik-Xmit-Limit-Gigawords" type="integer" code="15" />
                </vendor>

radius.inetOption.3.attributes=Cisco-AVPair=lcp:interface-config#1=rate-limit input 10485760 1966080 1966080 conform-action transmit exceed-action drop;Cisco-AVPair=lcp:interface-config#1=rate-limit output 10485760 1966080 1966080 conform-action transmit exceed-action drop

сейчас скорость режит accel-ppp , как резать скорость для микротика ?
Автор:  a.vozny [ 16 ноя 2016, 15:21 ]
Заголовок сообщения:  Re: Логика работы модуля
вот так заработало.
vendors=9=Cisco;2011=Huawei;2021=Unix PPP;529=Lucent;6618=Quintum;529=Ascend;311=Microsoft;12341=MPD;14988=Mikrotik
radius.inetOption.1.attributes=Mikrotik-Rate-Limit=5000k/5000k
для смены скорости включил pod на порту 3799
Автор:  ok-2004 [ 16 ноя 2016, 18:06 ]
Заголовок сообщения:  Re: Логика работы модуля
Цитата:
вот так заработало....

смена скорости через радиус на микротике - это давно пройдённый и уже не интересный никому этап.
Мы уже ушли от впн на брасах давно и навсегда и тарифную полосу режем юзерам с помощью simple queues на vlan-интерфейсах.
Сейчас от планарного vlan-на-юзера переходим к иерархическому q-in-q. Так как 4096 вланов не хватает.
Сдесь как-то ув. Snark подымал в который раз тему указания в сервисе двух вланов - s_vlan и c_vlan.
Полностью поддерживаю его вопрос, потому как трудности возникли при управлении резкой скоростей на интерфейсах микротика типа :
s_vlan${i}@c_vlan${j}@ether${n}.
Автор:  a.vozny [ 17 ноя 2016, 15:18 ]
Заголовок сообщения:  Re: Логика работы модуля
2ok-2004
мой пост чуть не в тему... искал по Mikrotik-Recv-Limit...

а как вариант создать суб.договор ?


в догонку
http://wiki.bitel.ru/index.php/IPoE_Accel-ppp
Схема в общих чертах. Для максимальной простоты настройки Q-in-Q на accel-ppp с авторизацией по radius, номера S-Vlan и C-Vlan подставляются в логин пользовате
Страница 1 из 1 Часовой пояс: UTC + 5 часов [ Летнее время ]
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/