Биллинговая система Nodeny

Когда Nodeny научится работать с динамическими ip-адресами?  ???
Чтобы он мог выдавать по PPPoE динамический реальный ip-адрес абоненту.

Пока не планируется

Зачем??
Хочеш укртелеком переплюнуть??  ;D

А затем, если статика то нужно больше свободных ИР адресов сем есть клиентов а если динамика то на 500 юзверей может быть 400 ИП адресов а в некоторых случаях еще меньше! Первое маркетинговый шаг. Второе економия денег на ИП.

ДХЦП себе поставь))

DHCP тут как корове коньки! пока только пул на нате поможет

Причем тут нат? причем тут дхцп?
Ну не нужен мне никакой нат, не нужно мну дхцп!!
Хочу терминировать пользователей PPPoE и выдавать им реальные ip-адреса! Причем динамические - для экономии адресного ресурса.
Вот такая вот задача!

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

у него реальных адресов меньше чем клиентов, имеющих эти адреса. Это нормальная ситуация, но ее решение требует переработки ядра биллинга, я не рискну пока

Ну будем ждать и надеятся.

Мне в голову приходит добавление отдельной таблицы типа ip_leases и при радиус запросе брать случайный свободный адрес из списка и отдавать юзеру. И вписывать в допполе\алиас договора юзера этот ип

Самое сложно это сказать серверу доступа что у клиента с определенным ипом сменился ип на такойто.

ЗАпарно и наверняка глючно будет.

Еще один вариант применения динамических ип - это хотспот, когда ты генеришь карточки пополнения, привязываешь их к определенному тарифному плану, но заранее не знаешь, с какого ip-адреса клиент прийдет ;)

имели опыт столкнутся с динамическими адресами, по поводу хацкеров, это правда, им наруку, пришлось бегать по СБУ.
сейчас имеем 3 больших пула адресов, каждому клиенту постоянный реальный. не пожалейте денег, есть другие способы экономии.

Думаю реализовать такое можно!
Если прикрутить к РРоЕ серверу скрипт с добавлением правил в фаервол для разрешения доступа.
там такое можна реализовать.

Проблема совсем не в выдаче адресов из пула. А в том, что  параллельно идет процесс подсчета трафика. Ядро получает трафик не на каждого абонента персонально, а скопом на всех клиентов. Оно запрашивает у устройства Х  "дай мне всю информацию о трафика начиная с того момента, когда я в прошлый раз ее запрашивал". Потом ядро смотри на полученные данные и видит: строка нумер 1, 1.2.3.4 передал 1 кб на 2.3.4.5. Оно смотрит в базу и видит, что 1.2.3.4 - это клиент Иванов. Получи Иванов + 1кб.

Теперь представим ситуацию. Иванов подключается, ему выдается ип 1.2.3.4, успевает сконнектиться аська, тут обрыв и Иванов переподключается. В этот момент подключается Петров и получает ип 1.2.3.4. В итоге трафик Иванова в срез будет засчитан Петрову.

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

Выйти из подобной ситуации может резервация ip, т.е. если клиент отключился, то его ip не может быть выдан кому-либо в течение двух срезов трафика (для гарантии). Опять же придется отслеживать ситуацию, когда клиент постоянно переподключается и тогда не резервировать ip, а выдавать ему тот же. Все это возможно, но я не вижу чтоб эффект покрыл вложенные затраты