Собственно есть домовая сетка с неуправляемыми коммутаторами и серваками контроля доступа и биллинга. Доступ контролируется по технологии так называемого "Русского VPN". сейчас трафик агрегируется на шлюзе и по netflow уходит на биллинг, инфу для контроля доступа и ограничения скорости биллинг передаёт шлюзу по RADIUS.
Хочу уйти от этого. Почитав как это делается пришёл к выводу в необходимости установки управляемых коммутаторов на подъезды. И передачи им функции контроля доступа и скорости за счёт контроля конкретного порта, к которому подключен абонент.
Тоесть нужно чтобы они поддерживали ограничение скорости на порту и, соответственно, блокировку. Как я понял считать пропущенный трафик коммутаторы не умеют, да и ненужно их этим нагружать. Это планирую решить считая по маку и ip на шлюзе. Собственно это приводит к вопросу DHCP и "запоминанию" mac адресов клиентов.
В моей голове складывается такая схема:
- Клиент подключается к порту коммутатора.
- Его мак фиксируется и добавляется в разрешённые.
- DHCP ему выдаётся IP из внутренней подсети, маршруты и прочее.
- Он ходит в нет через шлюз, где на основании этого mac считается его трафик.

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

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

Посмотрите мою тему (тыц), и поищите аналогичные проблемы, чтобы потом не встрять.

Почитайте это. А там дальше уже станет все понятнее.

И это обязательно. Для того, чтобы стало понятно, что это - = утопия.

Спасибо! То что нужно.

Ну, в принципе я могу это без особых проблем решить и на шлюзе. Хотя есть ли какие-либо не серверные решения позволяющие это делать? Тоесть чтобы поставить на доме оптический коммутатор, раздать с него сеть по оптике на управляемые комутаторы, обслуживающие подъезды, и подключить всё это к магистральщику, при этом не устанавливая сервер ибо кроме как гасить порты и шейпировать трафик ничего там и не требуется...

Любой НЕ сохо маршрутизатор. Например Cisco-1941 (в зависимости от кол-ва клиентов и трафика).

Cisco одним портом к "магистральщику", вторым к "подъездным" коммутаторам. На циске и нарежете необходимые полосы клиентам (шейпинг). Правда, у циски нет такого понятия (полисинг там), но по сути и "эффекту" , то что Вам нужно.
Да, у клиентов в этом случае должны быть статические IP, которые Вам должны быть известны (чтобы составить нужное правило полисинга). Естественно также никакого VPN и NAT здесь быть не может - 100% статика на "белых" IP.
В "подъезды" DES-3200-10/18/28.
А вот "гасить порты" эта "система" самостоятельно не сможет, придётся либо ручками, либо скриптом из биллинга.

P.S. Ещё раз повторюсь - коммутаторы "шейпировать" НЕ УМЕЮТ. Bandwidth control на них - это жалкая пародия, за которую ваши клиенты поставят Вас в одну широко известную позу.

Спасибо за информацию!

То есть получается, если просто схематично отобразить, мы задаём DHCP отдавать, в соответствии с полученной с помощью "Option 82" информацией о маке и порте, определённый белый IP. После этого, опять же скриптом(кстати, с помощью какого протокола?), передаём маршрутизатору правило полисинга на основе этого IP. И в итоге получается, что мы управляем подключениями, например с помощью радиуса, на коммутаторе, а скорость балансируем на маршрутизаторе.
Я правильно понял логику?

Да, примерно верно.
Современные маршрутизаторы умеют на основе передаваемых в пакете авторизации опций делать запрос к радиус серверу, а радиус уже будет отвечать настройками шейпера - никаких скриптов и не надо.
Читайте про ISG

Так.

Самое простое - telnet (Perl Net::Telnet), или с помощью того же радиус (циски точно его "понимают"). Наверное возможно и по snmp, но насчёт циско не знаю, практически не юзаю их. Есть пара "точек", где стоит циско. Конфигурация выполнена один раз ручками и динамически не изменяется ("юрики").

А вот радиус здесь совсем и не нужен. Управлять включением/отключением клиентских портов будете так же скриптом с сервера, telnet-ом, или по snmp.
P.S. Как вариант, можно и не блокировать порты, а элементарно с помощью радиус задать маршрутизатору "нулевую" скорость в полисер заблокированного клиента, или, что логичнее, блокировать акцесс-листом.

Большое спасибо за помощь! Зацепившись за инфу в этом топике сразу же удалось откопать множество подробных мануалов в сети.