Добрый день,
Не знаю как воспримет мою просьбу производитель, и народ (коих хочу высказаться и поддержать мою тему) хотелось бы увидеть в коммутаторах доступа(3028, 3052 , 35хх) зачатки Radius-Nas-клиента, а точнее следующее, DHCP-Radius DHCP Snooping, идея такова при обращении клиента по DHCP коммутатор перехватывал как в DHCP-relay запрос и делал бы запрос в radius-server с логином=имя свича_номер порта, да даже если логин был бы как mac адрес при DHCP-relay_opt82 то тоже бы пошло далее радиус сервер выдает параметры типа запрещено или все ОК ну и параметры IP-Mask-GW-DNS,….. tx_rate rx-rate? vlan?....коммутатор бы выдал юзверю по DHCP все настройки и с помощью DHCP Snooping следил бы за юзверем….
Тоесть чтото похоже на 802.1x и Guest vlan но без запроса у юзверя логина-пароля, а просто опираясь на имя коммутаора-номер порта…
Как вам такой функционал?
Ну на крайний случай в коммутаторах DGS-3612 DGS-3627 реализовать DHCP сервер с поддержкой opt82 c Radius запросом…

Идея безусловно интересная, но зачем тогда это нужно? Просто из-за аккаунтинга? Ведь весь смысл 802.1x именно в первую очередь в отсечении клиента от ближайшего устройства сразу на канальном уровне при неуспешной авторизации. А в этом случае это преимущество теряется. А аккаунтинг можно делать на биллинге на основе информации в полях Option 82. Назначать настройки на порту можно и стандартным способом скриптом по SNMP например.

ну смысл то есть учитывая что 802.1x не везде есть. И там запрос логина пароля, а хочется без этого.

Хотя заставлять RADIUS заниматься функциями DHCP сервера тоже мне кажется не очень правильно.

Да и при dhcp snooping коммутатор просто добавляет поле к пакету, а при RADIUS ему придется транслировать весь пакет в другой, сможет ли он так?

Если сможет не факт что DHCP сервер и Radius сервер работающие по стандарту это поймут.

если DHCP без извратов и "кострированный" радиус то все ок будет...
DHCPсервер(на 24-28 порта-юзверя) ловит пакет и у биллинга по радиусу спрашивает "клиент" с именем (имя свича+номер порта) или (мак адрес как в опт82) и с пустым или с заранее забитым паролем имеет право доступа в сеть? радиус сервер возращает да-нет... если "да" то он возвращает для DHCP сервера ip-mas-gw-dns... DHCP сервер отдает клиенту... если радиус протокол будет бегать по влану управления то это вообще замечтательно...

я тут извращаюсь сам пишу сервер с DHCPопт82-Radius... так как все широко известные биллинговые системы, динамически, из пула, могут выдавать только по Radius... а статику только применяя скрипты и прочую гадость...

а насчет 802.1x раскажите-покажите: Что из ваших мини роутеров, и точек доступа позволяет авторизовываться в качестве клиента, по протоколу 802.1x ?
да и клиенту эта авторизация не всегда нужна...

Пожалуйста специально делали линейку интернет-шлюзоа с 802.1x на WAN DIR-120 и DIR-320.

а в АР? в данный момент я сижу на ноутбуке, точка доступа 2000, она же и натит.... так как есть по мимо нее еще и стационарный комп... и коммуникатор...

Мне вот в этом случае непонятно зачем нужен Radius? Если между клиентом и свитчом он не работает, то почему бы не использовать авторизацию по DHCP с использованием полей Option 82? Только для назначения параметров на порт устройства при успешной авторизации из словаря Radius? Так к чему городить этот нестандартный функционал если всё это просто завязать на скрипты по SNMP.

DIR-320 - рутер с вафлей.
А по тексту - бред, имхо.
DHCP или загнать в LDAP и там удалять/добавлять адреса биллингом, или время от времени рестартить DHCP с новым конфигом. А вообще в свете правил предоставления услуг - 2 профиля ACL
1 профиль - разрешить всем доступ к сайту статистики/личному кабинету.
2 профиль - для заблокированных клиентов, запрещает весь трафик на клиентских портах/порту.
В этому случае DHCP выдает адрес всегда.

насчет выбранной-представленной единственной АР с поддержкой клиента 802.1х вы мне больше помогли... ОЧЕНЬ мало оборудования поддерживает этот протокол- 802.1х, даже в линейке Dlink_a т.е. даже сам производитель делает рекламу вот пользуйтесь авторизацией- этой фишкой... спрашиваешь а что к клиенту будем ставить, а вот 1,2,3эээ 4, и усе... а клиент фирма... у нее есть не только делинк, а есть и линукс роуетер и микротик и cisco... да причем фирма? у клиентов-физиков стоит тоже самое вышеперечисленное и каждому надо объяснять что извините мы применяем протокол который многие производители не поддерживают...

Насчет Radius-DHCP могу заверить очень красивая схема, и вовсе не бред особенно при наличии на нашем рынке кучи биллинговых систем у которых имеется сертификат и нечего кроме radius практически не чего нормально не реализовано, поэтому например циска унифицировала и пошла на хитрость, например в серии маршрутизаторов в IOS Cisco 12.2 SB есть вкусность "PBHK" смысл ее в том чтобы с коммутаторов собирать запросы DHCP opt82 отправлять с помощью radius запрос на сервер в котором в качестве логина идет opt82+mac , радиус сервер говорит да нет... выдает параметры... при успешном доступе DHCP сервер выдаются клиенту все необходимые параметры ip-mask-GW-dns....
А теперь вопрос: а зачем напрягаться ставить отдельный DHCP и прочее, когда можно реализовать в самом свиче доступа? просто реализация 802.1х да хорошо но, используя фишку при которой свичь при приеме запроса DHCP-запроса от клиента просто делает запрос на сервер в качестве логина в запросе берет свое имя и номер порта... или как циска полностью «весь mac адересс» с 82 довесками..
далее принимает ответ и на основании его клиенту выдает необходимые параметры или посылает... т.е нечего не дает , если реализовать передачу доп параметры то можно и регулировать скорость на портах.... если еще и оставить DHCP Snooping вуаля прелесть оператора....

Хотя это мечты... ну и ладно будем реализовывать на Cisco...
но на доступе непременно 3028-3526 сдесь нет равных цена-качество-вкусности...

Кстати Иван пришлите последние прошивочки на 3028-3526 3612,3627

Я Вам прошивки выслал. Как я и говорил идея безусловно интересная. Ещё нужно понять как эта функция грузит CPU в том числе и на Cisco. Я думаю что не мало. В любом случае пришлите пожалуйста ссылку на описание этой функции а также список моделей Cisco которые её уже поддерживают.