BiTel

Добрый день!
Чота совсем запутался....
Прошу прояснить некоторые мои непонятки по логике модуля INET

Непонятка 1:

Из документации мы знаем, что


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

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

Непонятка 2:

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



Вопрос 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 ?

_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)

Удален - когда сервис закрывается по периоду. В этом же случае и вызываются команды удаления.
Команды создания выполняются при добавлении сервиса в договор.

connection - это connection, например PPPoE, PPTP. StaticIP - это сессия, у неё нет коннекшина. sa.command.connection вызываются для перевода текущего подключения из состояния в состояние, в зависимости от схемы. В вашем случае нужно вызывать sa.command.serv.enable/disable, хоть у неё и могут быть коннекшины, они останутся висеть, но доступ будет закрыт/открыт.

Окъ, понятно...

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

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

Очень интригует... очень. Хотелось бы посмотреть на такие состояния коннекции, которые не меняют параметров тарификации и не рвут сессии.

Мой слабый мозг отказывается понимать эту сложную логическую конструкцию.
Т.е когда я к примеру закрываю юзеру фильтрами на микрОтике доступ в инет - я не рву при этом его коннекцию на этом устройстве ?
Вы опять перевернули моё представление о логике работы модуля INET на 180 гр.

_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)

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

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

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

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

Хм...
Обычно посты дальше 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. Наличие ип-а клиента в этом адресс листе не должно зависить не от статуса договора. не от статуса или состояния сервиса.

Кто может подкинуть хотя бы идею реализации этой задачи ?

_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)

Итак, еще раз - коннекшинов у вас НЕТ!!! и sa.command.connection в вашем случае неприменимы. Есть только сессии, стартующие по трафику. Для коннекшинов есть отдельная таблица inet_connection_{mid}, можете посмотреть - для этих клиентов записей не найдется.

Для решения задачи напрашивается навешивание дополнительной опции прямо на сервис, но опция, вроде, деактивируется при блокировки сервиса, хотя если доступ заблокирован - это не должно смущать, зачем пункт 13 тогда?

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


servId=11389 - как раз id сервиса клиента, у которого сработали на устройстве правила прописанные в начале треда.

_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)

Все равно огорчу - это фиктивные коннекшины, для унификации. Для StaticIP не нужно никаких телодвижений, интернет есть и всё. Для PPPoE, PPTP, прочих VPDN нужно сначала установить ПОДКЛЮЧЕНИЕ (которое можно сбросить на оборудовании), и только потом будет щщастье. Даже DHCP требует первичного диалога. Я вот про что. Дальнейшую дискуссию на эту тему продолжать не буду. Схему решения предложил - через отдельную опцию, помимо скорости.

в словарике есть сторик

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 , как резать скорость для микротика ?

вот так заработало.
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

смена скорости через радиус на микротике - это давно пройдённый и уже не интересный никому этап.
Мы уже ушли от впн на брасах давно и навсегда и тарифную полосу режем юзерам с помощью simple queues на vlan-интерфейсах.
Сейчас от планарного vlan-на-юзера переходим к иерархическому q-in-q. Так как 4096 вланов не хватает.
Сдесь как-то ув. Snark подымал в который раз тему указания в сервисе двух вланов - s_vlan и c_vlan.
Полностью поддерживаю его вопрос, потому как трудности возникли при управлении резкой скоростей на интерфейсах микротика типа :
s_vlan${i}@c_vlan${j}@ether${n}.

_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)

2ok-2004
мой пост чуть не в тему... искал по Mikrotik-Recv-Limit...

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


в догонку
http://wiki.bitel.ru/index.php/IPoE_Accel-ppp
Схема в общих чертах. Для максимальной простоты настройки Q-in-Q на accel-ppp с авторизацией по radius, номера S-Vlan и C-Vlan подставляются в логин пользовате