Разрешите мне поглядеть на это дело со своей колокольни. Ну-во первых, вот что-что, а, ИМХО, атрибуты от RADIUS-а совсем не зависят. Так что вместо icradius-a легко могло бы быть использовано что-то типа GNU-RADIUS, xtRADIUS или freeradius. У последнего, кстати, очнь своеобразная и достаточно гибкая SQL-схема, рекомендую. Во-вторых, Вы позиционирует решение маршрутизатора на PC? Для кошек оно, AFAIK, не прокатит - отсуствие нужных атрибутов, да и сработают ли они, если сервер вдруг перегрузится... Так что считать надежнее не на роутере (который вообще никакой системной логикой обременен не должен быть по определению), а таки на отдельной машине. Опять же, завтра Вам понадобилось разбить трафик на классы (допустим, часть из него должна отдаваться по пирингу и не считаться клиенту), опять же, на роутере этого делать нельзя. Ну и наконец, MySQL. При alive-ах раз в минуту легко может загнутся, если не сделать сериализатор. Да и вобще - эта СУБД лучший выбор для вэб-разработок, но никак не для учетных систем. Рекомендую посмотреть в сторону Postgre, она в этом отнощении, ИМХО, очень даже ничего (если, конечно, биллинг не корпоративен, там другие веса).
Вывод - решение грамотное и наверняка адекватное задаче. Минусы - проблемы реализации и невозможность расширения и усложнения системы. Неуниверсальное решение.
