Сейчас совсем нет времени писать много - работой завалило.

Но вкратце могу сказать следующее.

Во-первых, кто бы что ни говорил, надо прочитать документацию и держать её в закладках (или даже распечатать):
http://www.cisco.com/en/US/docs/ios/12_2sb/isg/coa/guide/isg... - описание CoA интерфейса и аккаунтинга.
http://www.cisco.com/en/US/docs/ios/12_2sb/isg/configuration... - конфигурирование ISG.

Во-вторых, имеет значение, что у вас за портал, какую технологию вы собираетесь использовать? Например, у нас не пошёл стандартный SESM (возможно, мы не правы, но он показался достаточно убогим по фичам) и мы написали свой на Python/Django с использованием своей библиотеки для работы с CoA.

Если надо совсем "втупую" а SESM не хочется, я бы сделал так: поставил бы radclient от freeradius и формировал бы запросы на stdout в виде attribute-value pair (как radacct) и скармливал бы radclient'у. Типа того:

$ cat getatstus-newstyle    
Packet-Type = CoA-Request
User-Name = "ANY"
Cisco-Account-Info = "S192.168.192.2"
Cisco-AVPair = "subscriber:command=account-profile-status-query"
$ /usr/bin/radclient -x -f getstatus-newstyle 10.0.0.1:1700 coa SecretK3y

Ну и в ответ получаем атрибуты всякие. Точно таким же образом можно и включать-выключать сервисы (см. описание CoA).

С турбо-кнопкой есть три варианта (на мой взгляд):

1. Если у вас есть "обычный" сервис (и он у всех одинаковый), то можно прописать такую полиси, чтобы при включении турбо-сервиса "обычный" выключался и наоборот.
2. Можно логику выключения "основного" сервиса положить на портал, т.е. при включении турбо мы смотрим, что там у пользователя включено, выключаем и включаем
турбо (кажется, для SESM есть специальные атрибуты и он делает это автоматически: взаимоисключающие сервисы.)
3. Также, турбо-сервис можно снабдить более низким приоритетом у его тарфик-класса и при включении такого сервиса он перехватит весь трафик на себя.

В общем, вариантов много. Если мой e-mail вам виден - обращайтесь с конкретными вопросами, так всегда проще.