Модуль "Белый ip"

[fet4]

Здравствуйте!

Интересует модуль покупки абонентом белого Ip

ТЗ:
Подключение "белого ip" через личный кабинет и выдача с пула с привязкой к учетке.
Отключение "белого ip" через личный кабинет и отвязка от учетки.
Отключение "белого ip" по задолженности за данную услугу больше двух месяцев и отвязка от учетки.

[tom]

я в долі

[Efendy]

у тебя такое же условие "Отключение "белого ip" по задолженности за данную услугу больше двух месяцев и отвязка от учетки."?

[fet4]

у тебя такое же условие "Отключение "белого ip" по задолженности за данную услугу больше двух месяцев и отвязка от учетки."?

В идеале это условие должно быть регулируемо.

[tom]

Мені підходить стандартні умови управління послугою.

[Efendy]

Могу предложить такой вариант (есть в базовой поставке):

• Белых ip мало, поэтому лучше их выдавать динамически
• При динамической выдаче ip проверяется существует ли услуга "белый ip". Т.е вам достаточно сделать basic услугу с любым именем и определенной стоимости и в теге указать realip
• Абонент сам может подключить данную услугу
• Клиент сможет заказать смену услуги на, скажем, "отключение белого ip"

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

[fet4]

У меня белые ip используется только темы кто их покупает, у остальных серая динамика.

Поэтому подключение белого ip представляю так.

Клиент подключил услугу белый Ip в кабинете, ему привязался первый свободный белый ip и отвязался серый, клиент перезагрузился и получил его.
Если клиент не оплачивает услугу нужно забрать этот Ip через какое-то время и иметь возможность чтобы он сам мог отключить.

[tom]

Питання №1 - Чи буде привязаний конкретний ір за клієнтом до момента завершення послуги
Питання №2 - Процес відкріплення. Після відкріплення ір, має посилатися CoA disconect? для дропа сесії і отримання нового ір.
Питання №3 - динамічне видання ір, в теорії дійсно може зекономити ір простір. Але 99% потреб реального ір, це мати доступ до кокретних сервісів з підвязкою до ір, або ж мати доступ до внутрішніх ресурсів клієнта по ір (доресі ірv6 є в планах? вже регаю собі, 30% AS в світі мають ipv6). Тоді є сенс розділити реал ір динамічні та статичні. Це також може вплинути на ціну... Як варіант
Питання №4  - обмеження кількості видаваємих ір на клієнта. Щоб він собі не замовив 10 реалок.
Питання №5 - відносно 2х місяців. В будь-якому випадку, блокування клієнта відбуватиметься по загальному балансу. Можливо є сенс, видаляти реалку з привязки до клієнта, черех 2 місяці, чи N місяців. Знову ж таки, не заплатив, послуга завершилась, заплатив через тиждень, а в нього вже інша ір-шка, а в нього налаштовані реєстратори під стару і ..... А так - н місяців тримаємо ір, під тебе.. далі вибачай..

[andromeda]

Могу предложить такой вариант (есть в базовой поставке):

• Белых ip мало, поэтому лучше их выдавать динамически
• При динамической выдаче ip проверяется существует ли услуга "белый ip". Т.е вам достаточно сделать basic услугу с любым именем и определенной стоимости и в теге указать realip
• Абонент сам может подключить данную услугу
• Клиент сможет заказать смену услуги на, скажем, "отключение белого ip"

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

А как определить определеный Pool ip адресов для такой услуги, чтоб он был динамический еще, есть у меня просто маленька сеточка еще не использованая /26 хотелось бы ее так выдовать без жосткой привязки тем клиентам которым это не нужно?

Что сделал
- Услугу создал с тегом realip
- создал пул , имя ,начало-конец пула определил, тип динамический, галочку не ставил, тег добавил realip.
Не выдает (((....