На сервер доступа замаршрутизировано /26 внешних адресов. Адресация распределяется из пула mpd (в будущем sqlippool), маленькая проверка и клиенту выдается либо внешний либо фейковый адресс.

Пока такая система работает в тестовом режиме около 3 месяцев (без аккаунтинга), обслуживает 150 юзеров.

Косяки, решение которых пока не внедрено:
- Двойной логин под одной учеткой. Решение есть, но пока не внедрено.

Есть ещё таблица usession, где собирается статистика по коннектам.
Ну и понятное дело модифицирован под неё Sseance.pl

Прошу прощения ещё раз за свой "индийский код", конечно правильно было бы отдавать radius отлупом (reject), и все такое, но строгал на коленке, в продакшн не запускал.  

Клиенту назначается адрес из фейковой сети  (таблица users поле ip)
Дальше проверка баланса в radreply:

DROP PROCEDURE IF EXISTS `radreply`;
DELIMITER $$
CREATE PROCEDURE `radreply` (IN login VARCHAR(64), IN mac VARCHAR(18),
IN nas_ip VARCHAR(16))
BEGIN
DECLARE usr_id INT;
DECLARE usr_ip VARCHAR(16);
DECLARE rate_limit INT;
DECLARE rate_limit_out INT;
DECLARE normal_burst INT;
DECLARE normal_burst_out INT;
DECLARE extended_burst INT;
DECLARE extended_burst_out INT;
DECLARE balance_ch INT;
DECLARE lmbalance INT;


SELECT id,balance,limit_balance INTO usr_id,balance_ch,lmbalance FROM
users WHERE name=login;
SELECT plans2.speed,plans2.speed_out INTO rate_limit,rate_limit_out
from users,plans2 where users.name=login and users.paket=plans2.id ;


IF balance_ch < lmbalance THEN
SELECT ip INTO usr_ip FROM users WHERE name=login;
END IF;

INSERT into dblogin (mid,act,time) VALUES (usr_id,47,unix_timestamp());
INSERT INTO usession (login,ip,mac,nas_ip,status) VALUES (login,ip,mac,nas_ip,'START');
SET rate_limit=rate_limit*1024*1024;
SET rate_limit_out=rate_limit_out*1024*1024;
SET normal_burst=ROUND(rate_limit*3/16);
SET normal_burst_out=ROUND(rate_limit_out*3/16);
SET extended_burst=2*normal_burst;
SET extended_burst_out=2*normal_burst_out;

SELECT NULL,login,'Framed-IP-Address',usr_ip,'=';
SELECT NULL,login,'Framed-IP-Netmask','255.255.255.255','=';
SELECT NULL,login,'Framed-Protocol','PPP','=';
SELECT NULL,login,'Simultaneous-Use','1',':=';
IF (rate_limit>0) THEN SELECT usr_id as id,login,"mpd-limit" as
Attribute,concat("out#1=all rate-limit ",rate_limit," ",normal_burst," ",extended_burst) as Value,"+=" as op;
END IF;
IF (rate_limit_out>0) THEN SELECT usr_id as id,login,"mpd-limit" as
Attribute,concat("in#1=all rate-limit ",rate_limit_out," ",normal_burst_out," ",extended_burst_out) as Value,"+=" as op;
END IF;
END$$
DELIMITER;

Соответственно РРРоЕ автризация доступна всегда, просто заблоченым юзерам выдается не маршрутизируемые айпи, с переадресацией на страницу, где сообщается об отсутствии денег или нарушении (спам,флуд,учасник ботнент)
Опять же, я понимаю, что корифеи програмерства меня сейчас заплюют.

Ах да, есть ещё внешний скрипт, чекает баланс каждые 5 минут по крону.

[Косяки:]

На ваше обсуждение выложу тут свои наработки в плане подсчета трафика.
Входящий и исходящий направления подсчитываются с помощью radius аккаунтинга, с помощью процедур radupdate и radstop.

accounting_update_query = "... ,'%{Acct-Input-Packets}','%{Acct-Output-Packets}')"

Выглядит примерно это так:

1. Создается временная таблица, содержащая поточные даные аккаунтинга по каждому клиенту

CREATE TABLE temp_trf (
login VARCHAR (64),
in_o BIGINT,
out_o BIGINT,
PRIMARY KEY (login)
);

2. Модифицируется процедура radupdate


DROP PROCEDURE IF EXISTS `radupdate`;
DELIMITER $$  
CREATE PROCEDURE `radupdate` (IN login VARCHAR(64), IN stime VARCHAR (12), IN iccts VARCHAR(12), IN occts VARCHAR (12), ip_h VARCHAR(12))
BEGIN
  INSERT into dblogin (mid,act,time) VALUES ((SELECT id FROM users WHERE name=login LIMIT 1),47,unix_timestamp());
  INSERT INTO temp_trf VALUES (login,iccts,occts) ON DUPLICATE KEY UPDATE in_o=iccts, out_o=occts;
END$$
DELIMITER ;

3. Внедряется тригер, который и обрабатывает расчеты

DROP TRIGGER IF EXISTS `update_trf`;
DELIMITER ;;
CREATE TRIGGER `update_trf` AFTER UPDATE ON `temp_trf`
FOR EACH ROW BEGIN
   UPDATE users_trf SET in1 = `in1` + (NEW.in_o - OLD.in_o), out1 = `out1` + (NEW.out_o - OLD.out_o) WHERE uid = (SELECT id FROM users WHERE name= OLD.login LIMIT 1);
END;;


Сделано топорно, готов выслушать ваши идеи
Единственное что меня смущает - производительность тригеров.

Косяки:
- если будет сбой в работе связки NAS(RADIUS+DB+MPD) сервера последняя сессия не будет учтена.
- нагрузка???

Премного благодарен за ответ.

Доброго времени суток.
Волей судеб была необходимость сделать динамическую выдачу внешних адресов. Сделано.
Но с недавнего времени возникла необходимость считать этот самы трафик и подсовывать клиентам.
С помощью процедур заполняются x-таблицы, тоесть в разделе Траффик кабенета юзера трафик наличиствует.
Но, на главной пользовательской странице (модуль Smain.pl) трафик все-равно по нулям. В связи с этим хотелось бы узнать, откуда берутся выборки для формирования значений подведеных красным.
Биллинг официален и куплен за кровные.

При настройке сателлита столкнулся с проблемой дропа тунелей pppoe (FreeBSD 8.1/ mpd5.5 freeradius 2.1.10)
В логах radius.log

Ready to process requests.
rad_recv: Accounting-Request packet from host 172.16.0.13 port 45947, id=157, length=279
Received Accounting-Request packet from client 172.16.0.13 with invalid signature!  (Shared secret is incorrect.) Dropping packet without response.

Но априори ключи правильные, в файле clients.conf и mpd.conf одинаковые
И ещё более странно то что mpd и nodeny access пакетами обменялись, дело только за аккаунтингом осталось.

1. У меня 8.1, где проблема с маршрутизацией решена.
2. Проблема явно с неправильно указаными ключами. Но вот только где эти ключи указать для Accounting-Request'ов ?
Ведь клиент автоизацию проходит, а аккаунт пакеты сервером не передаются из-за incorrect ключа.

Аналогичная проблема с дропом тунелей pppoe (FreeBSD 8.1/ mpd5.5)
В логах radius.log

Ready to process requests.
rad_recv: Accounting-Request packet from host 172.16.0.13 port 45947, id=157, length=279
Received Accounting-Request packet from client 172.16.0.13 with invalid signature!  (Shared secret is incorrect.) Dropping packet without response.

Но априори ключи правильные, в файле clients.conf и mpd.conf одинаковые

Копайте в направлении CoA, через radclient можно динамически менять полосу. Схема уже накатаная и используется.