В примере для Вас с shared-network класс описан так, что он привязывается к порту любого свитча.
Нет. Там всё же есть к мак свитча, но не читабельный. Почему через точку, а не через двоеточие? Зачем оставили первые 2 байта? :) Ладно. Не суть важно. В моём примере виден ещё 1 вариант — использование ip свитча.
Кстати, делаете туже ошибку, что и я 1 раз сделал. Кнопка «Ответить» лучше под сообщение, а не глобально :)
Написал большой комментарий и случайно затёр его :) Злой :) Повторюсь.
С VLAN согласен, не доглядел. НО!
IP-адрес свитча должен находиться в той же подсети, что и адреса, выдаваемые абонентам.
Навивает именно на ту мысль, что у Вас менеджмент VLAN и пользовательский — это одно и то же. С учётом тяжело читаемости куска конфига свитча — легко запутаться.
Вы напрактике это проверяли? Или это догадки?
У меня сегмент сети прекрасно работает. Между свитчами и isc-сервером 2 шлюза. Ни каких нареканий. В начале была такая же проблема как и у Вас, но она была в неправильной настройке именно isc-сервера. А именно — использование shared-network. Кстати именно конфига ics Вы и не привели. В примере для Вас с shared-network класс описан так, что он привязывается к порту любого свитча. Приведу свой (маленький кусочек). Может понятнее кому-то будет.
Заголовок спойлера
default-lease-time 300;
max-lease-time 600;
authoritative;
ddns-update-style none;
ddns-updates off;
log-facility local7;
deny unknown-clients;
deny bootp;
local-address 172.17.255.99;
option ms-classless-static-routes code 249 = array of integer 8;
if exists agent.circuit-id {
log ( info, concat( " Lease for ", binary-to-ascii (10, 8, ".", leased-address),
" Switch port: ", binary-to-ascii (10, 8, ".", option agent.circuit-id),.
" Switch MAC: ", binary-to-ascii(16, 8, ".", option agent.remote-id)));
}
subnet 172.17.255.0 netmask 255.255.255.0 {
deny unknown-clients;
option routers 172.17.255.253;
}
shared-network "global_net" {
subnet 172.17.254.1 netmask 255.255.255.255 {} # Свитч 1
subnet 172.17.254.14 netmask 255.255.255.255 {} # Свитч 2
subnet 172.17.254.49 netmask 255.255.255.255 {} # и т.д.
#Классы пользователей
class "vishnya" {
match if binary-to-ascii(10, 16, "", substring(option agent.circuit-id, 4, 2)) = "22"
and binary-to-ascii(10, 8, ".", packet(24, 4)) = "172.17.254.1"
and binary-to-ascii(16, 8, ":", substring(hardware,1, 6)) = "0:15:58:71:8f:7c"
;
}
class "sogacheva" {
match if binary-to-ascii(10, 16, "", substring(option agent.circuit-id, 4, 2)) = "23"
and binary-to-ascii(10, 8, ".", packet(24, 4)) = "172.17.254.1"
and binary-to-ascii(16, 8, ":", substring(hardware,1, 6)) = "0:25:22:e2:71:8d"
;
}
class "ers0072" {
match if binary-to-ascii(10, 16, "", substring(option agent.circuit-id, 4, 2)) = "4"
and binary-to-ascii(10, 8, ".", packet(24, 4)) = "172.17.254.14"
and binary-to-ascii(16, 8, ":", substring(hardware,1, 6)) = "f8:d1:11:2:e8:b2"
;
}
#------------------Описания network для 172.17.1.0/24---------------------------
subnet 172.17.1.0 netmask 255.255.255.0 {
allow unknown-clients;
option routers 172.17.1.254;
option domain-name-servers 172.17.100.1, 172.17.100.2;
option ms-classless-static-routes 12, 172,16, 172,17,1,254;
pool{
allow members of "vishnya";
range 172.17.1.144;
}
pool{
allow members of "sogacheva";
range 172.17.1.158;
}
pool{
allow members of "ers0072";
range 172.17.1.48;
}
}
}
В данном конфиге каждый пользователь привязан к конкретному свитчу (его IP) и порту свитча.
Вообще конфиг на 11 тысяч записей весит около 1 мегабайта. Формируется динамически перловым скриптом.
" Вы же рубите порт на 64 пакетах за 5 секунд" Один порт — один клиент. Вполне достаточно.
Готов долго и нудно спорить — но… Думаю бессмысленно. Каждый останется при своём мнении.
Про абонентские порты — это было уже скорее не для Вас, а описание и рекомендация. Для Вас — Вы кинули строки конфигурации вообще фактически без комментариев, почему именно так. Новички воспользуются не задумываясь и наступят на грабли.
Далее.
На практике я писал что у меня freeradius с perl выборкой и snmp правилами для блокировки IP на порту.
А DHCP_snoop используете? Очень хорошая штука в паре с dhcp_relay options 82. Тогда ни какие snmp правила для блокировки не нужны :)
Как я уже сказал — на мой взгляд ОЧЕНЬ спорная статья. Я бы сказал — первый блин комом… :)
По поводу радиуса — было бы интересно посмотреть Ваши наработки — как раз этим направлением занимаюсь :)
config traffic control 1-8 broadcast enable multicast enable unicast disable action drop threshold 64 countdown 5 time_interval 5
#Это спасет от множественных броадкастов, генерируемых клиентами
Хана вашей сетке :)
Вы замеряли сколько в Вашей сети «нормально» бегает бродкаста? В большой сети до нескольких сотен пакетов в секунду. Вы же рубите порт на 64 пакетах за 5 секунд. И дропаете всё что выше. Причём свитч не будет разбираться, что он дропает, полезный бродкаст или нет. Даёте рекомендации без описания, почему и как работает. С этой функцией надо обращаться ОЧЕНЬ аккуратно.
enable loopdetect
config loopdetect ports 1-8 state enable
config loopdetect recover_timer 1200 interval 10 mode port-based
#А это спасёт от петель если уж они образовались
Тут стоит добавить, что НЕ РЕКОМЕНДУЕТСЯ включать этот функционал на магистральных портах :) Только на пользовательских.
Ещё раз о System интерфейса свитча. Он должен быть привязан к отдельному VLAN (в простонародье к менеджмент-VLAN) по 2 причинам:
1. Безопасность. Незачем пользователю видеть IP-управление свитча. Иначе это всегда шанс: перехватить трафик управления, подобрать пароль к свитчу и т.д.
2. Уменьшение нагрузки на CPU свитча. Весть трафик который ip-бродкаст — попадает на проц и обрабатывается им. Вынеся IP управления в другой VLAN — лишаете этот трафик шанса загрузить свитч.
При включенном dhcp_relay и указанной мной выше команде (при правильных настройках), запрос юникастом прекрасно попадает на DHCP-сервер, возвращается и попадает к клиенту. Если у Вас не работало — то только из-за не правильных настроек или словили баг старой прошивки.
В результате у Вас получилась ОЧЕНЬ спорная статься. Те статьи, на которые Вы же ссылаетесь, написаны более правильно, на мой взгляд. Меньше ошибок и глупостей.
1. Начните с того, что обновите прошивку. Firmware Version: Build 4.04.004 — это ОЧЕНЬ старая прошивка. Свежие можно взять тут: forum.dlink.ru/viewtopic.php?f=2&t=92700. Текущая — v4.38.B012. Заводские прошивки глюкавые. Чего не отнять у D-Link, они хотя бы не забрасывают большую часть своих свитчей и продолжают дорабатывать прошивки.
2. IP свитча в пользовательском VLAN — это даже не дыра, а дырища в безопасности.
config dhcp_relay add ipif System xxx.xxx.xxx.xxx — и пакеты на DHCP сервер будут уходить в менеджмент vlan юникастом. Главное, что бы по маршрутизации DHCP-сервер и свитч друг-друга видили. Альтернатива — dhcp_local_relay. Он только добавляет в пакет option 82, пакет дальше идёт бродкастом. Т.е. DHCP-сервер должен быть в этом VLAN.
3. isc-dhcp-server имеет один серьёзный недостаток — если у Вас много записей (а у нормального провайдера их много), то у Вас получится ОЧЕНЬ большой конфиг. Да, его можно формировать скриптом. Но при любом изменении придётся сервис дёргать. Не умеет isc-dhcp-server на лету перечитывать конфиг. Сейчас смотрю в сторону freeradius. Последние версии умеют работать как DHCP-сервер. Со всеми плюшками прямой работы с SQL серверами. (п.с. выше уже написали).
П.С. По настройке — обратитесь в любое представительство D-Link. Благо их много. Консультанты там обычно толковые. Много чего рассказать могут. И семинары бесплатные :)
Ну как бы если коммутатор не настраивать, то там и пароль стандартный. Или пустой, или admin, точно не помню. Так что это, как его, вроде само собой разумеется. А использовать public на snmp v1/2 — это вообще зло.
Т.к. последний раз в серьёз их щупал давно, тут или:
1. На тот момент как я с ними работал этого ещё не было.
2. Не разобрался сам, а в инете нашёл не правильные ответы.
На текущий момент в работе у меня их ни где нет, а покупать чисто для себя побаловаться — как то тоже лишних денег нету :)
Можно. Каждый SSID имеет индивидуальные настройки безопасности. И каждый можно по отдельности привязать к VLAN. В том числе в отдельный VLAN выкидывается и интерфейс администрирования. PoE я писал — есть эта же точка и с PoE, но почему-то в нашем регионе она до сих пор не доступна.
Скрипты — это костыли, т.к. в основном это должно делаться стандартными средствами. Это на мой взгляд. Хотя опять же спорный момент. Просто после работы с немного более дорогими решениями, но где всё это делается без скриптов в течении 2-3 минут — такие вещий воспринимаются как костыли.
А сравнивать не управляемый свитч и управляемый — это вообще не корректно. И ценник у цисок, даже у б.у. задран всё равно. Уже глюков на цисках, даже на шассийных я насмотрелся вагон и маленькую тележку. Когда в ЦОД из 200+ оптических модулей CISCO за первых 2 года в утиль ушло больше 10% модулей — это был полный улёт.
Удачные и неудачные решения есть у всех производителей. Поэтому хороший админ и отличается от посредственного тем, что у он их знает и умеет работать с разными.
Для меня сейчас в D-Link есть 1 главный +. Возможность потестить их оборудование до покупки. С большинством остальных производителей — надо сначала купить, что бы понять — подходит или нет.
Для многих SOHO и SMB — да, разница есть. Хотя опять же недавно смотрел проект для «маленькой» домашней сетки, где больше 15 точек доступа с роумингом. Эххх. Я пока на такой домик не зарабатываю.
А вот не надо. 10 шт. телефонов DPH-150 на этом офисе и ещё больше 15 в других местах. Более 3 лет с первого знакомства. Если к ранним моделям и было пару претензий, которые были решены обновлением прошивок, то последние модели вообще очень хороши и по дизайну и по функционалу. Но опять же — это всё на вкус и цвет. :)
Всё было более 2 лет назад, сейчас с той конторой уже не работаю. Поэтому версии прошивок и моделей точно не помню.
Ситуация 1: Было 3 микротика. Роутеры, где WAN являлся WiFi модулем. Соответственно они создавали треугольник. Производителем заявлено, что поддерживает STP. Включили. Сеть начала падать вся. Даже LAN интерфейсы. Отсылали настройки производителю. Что не так работает они сказать так и не смогли.
Ситуация 2: 2 интерфейса на микротике. Надо использовать 2 провайдера — один основной, второй резервный. Мониторить можно было только Default Gate провайдера. Всё. Мониторить какой-то удалённый сервер и реагировать по доступности этого сервера? Только самописными скриптами. Спасибо хоть так. Балансировка — то же скриптами.
Могу продолжать. Но надо ли?
Может сейчас уже и поменялось в лучшую сторону, но как в том анекдоте «ложки нашли, а вот осадок остался».
TerAnYu — c Mikrotik работал. К сожалению очень много костылей. По сути тот же линух. Не подготовленному пользователю давать в руки нельзя. Точнее пользователю или начинающему админу. Минимальный уровень — средний или профи админ. По мне тогда уж лучше собрать маленький сервер и поставить всё софтово. Но это собственно говоря моё личное мнение.
А так — для своей ниши не плохое решение.
У меня это вызывает восторг, т.к. для большинства предприятий именно это является уровнем Enterprise. Обратите внимание — и Вы и timteka из Москвы. Я не имею ничего против, что на сегодняшний день там многие компании используют самые передовые технологии и могут себе это позволить.
Но когда я прихожу в школу к дочке — я вижу в классе самые простые не управляемые свитчи и они рады, что у них есть хоть это. Когда я прихожу на любую из 5 поддерживаемых мной фирм — там стоит в лучшем случае в качестве точки доступа просто роутер фирмы что-то-Link, и ему уже лет 5, и он о ужас стандарта 802.11G. И им этого хватает! И это всё работает.
И когда шеф хвастается этой точкой DAP-2310 — все его знакомые говорят «круто!». В одной коробочке 3 точки!
И когда маленькой фирме на 10 человек надо сделать гостевой доступ для скучающих ожидающих клиентов очень не хватает таких вот маленьких, бюджетных и простых в администрировании решений. Без контроллеров на серверах. Их нет, они не нужны в небольшой фирме, где веб и почта на хостинге где-то далеко. :)
Кстати очень не много «админов» на сегодняшний день настроить корректно ни то что хомячковый линксис, а хотя бы винду с драйверами корректно поставить.
хомячковый линксис умеет multiple SSID
Кстати этот функционал должен уметь чип, что бы не приходилось, как в делать это программно на ЦПУ (куда опять же нужен шустрее чип). И всё это сказывается на цене. И у хомячкового линксиса цена далеко не самая бюджетная. С тем же функционалом и стабильностью есть много гораздо дешевле решений. Там пол цены только за имя.
Именно поэтому бюджетное решение решение сегодня не умеет ничего кроме точки доступа на 1 SSID. И стоит меньше 50$. А Enterprise (который по Вашему вовсе и не интерпрайз, а так не пойми что) стоит более 150$.
Как то так.
Кстати — я до сих пор не понимаю и не принимаю программных контроллеров. Это должно быть аппаратное решение, иначе ни о какой стабильности говорить нельзя. Программный — только радиус сервер (тут уж аппартно сложно). Но это отдельный холивар :) И думаю тут ему не место.
P.S. ух… Выговорился :) Надо завязывать. Что-то я по молодости (первый день на хабре не рид-онли) увлёкся :)
Не согласен. Если говорить о средних и крупных предприятиях — то да. Это классический современный функционал. Но если смотреть на малое предприятие или вообще домашнее решение — вот смысл там в таком функционале? Ведь за кадую фичу так или иначе приходится платить. А тут оказалось очень бюджетное решение с фугкционалом на уровне Enterprise. Или скорее решение уровня и качества Enterprise по цене бюджетного.
Да я как-то и не ругаюсь вроде. :) Вообще D-Link как и все остальные сейчас. Ни лучше ни хуже. «Просто Вы не умеете их правильно готовить». Под руку подвернулся. А для небольшой фирмы 2х3 метра как раз разница в 20$ уже имеет значение :)
Надеюсь ещё будет возможность и необходимость пощупать такие решения. Всегда интересно новое.
Посмотрел вокруг и подумал. А на D-Link мы действительно подсели. Свитч, ip-телефоны, теперь и WiFi. Незаметненько так :)
Ваш совет напоминает ситуацию: "Покупатель:
- Мне нужна игрушечная машинка для ребёнка.
Продавец:
- Он же когда-то вырастет, берите сразу настоящую! И она же всего в n-цать раз дороже."
Смысл? Если мне нужен будет контролер, я посмотрю контролеры. :) Может быть тогда и на Ваше решение обращу внимание.
Быстрый поиск в интернете по Вашей рекомендации:
1. «Работа с multiple SSID и multiple VLAN — возможна и неоднократно проверена, но не через WEB-морду.» Т.е. быстрой и простой настройки не увидел.
2. Цена на Ubiquity UniFi AP (как я понял самая простая из этой серии) — market.yandex.ua/model.xml?modelid=7350930&hid=723087 от 75$ примерно.
Цена на DAP-2310 — market.yandex.ua/model.xml?modelid=7715367&hid=723087&suggest=1 от 55$ примерно.
Т.е. по цене выгоды не вижу ну ни как.
3. D-Link мне в представительстве производителя без проблем выдали на тест. Я его опробовал перед покупкой. Остальные производители — только по знаком у продавца и «очень окуратно».
Пока что плюсов в Вашей рекомендации не увидел.
Это делает dhcp_server filtre
config filter dhcp_server ports 1-25 state enableНемного проще. :)
Нет. Там всё же есть к мак свитча, но не читабельный. Почему через точку, а не через двоеточие? Зачем оставили первые 2 байта? :) Ладно. Не суть важно. В моём примере виден ещё 1 вариант — использование ip свитча.
Написал большой комментарий и случайно затёр его :) Злой :) Повторюсь.
С VLAN согласен, не доглядел. НО!
Навивает именно на ту мысль, что у Вас менеджмент VLAN и пользовательский — это одно и то же. С учётом тяжело читаемости куска конфига свитча — легко запутаться.
У меня сегмент сети прекрасно работает. Между свитчами и isc-сервером 2 шлюза. Ни каких нареканий. В начале была такая же проблема как и у Вас, но она была в неправильной настройке именно isc-сервера. А именно — использование shared-network. Кстати именно конфига ics Вы и не привели. В примере для Вас с shared-network класс описан так, что он привязывается к порту любого свитча. Приведу свой (маленький кусочек). Может понятнее кому-то будет.
В данном конфиге каждый пользователь привязан к конкретному свитчу (его IP) и порту свитча.
Вообще конфиг на 11 тысяч записей весит около 1 мегабайта. Формируется динамически перловым скриптом.
Готов долго и нудно спорить — но… Думаю бессмысленно. Каждый останется при своём мнении.
Про абонентские порты — это было уже скорее не для Вас, а описание и рекомендация. Для Вас — Вы кинули строки конфигурации вообще фактически без комментариев, почему именно так. Новички воспользуются не задумываясь и наступят на грабли.
Далее.
А DHCP_snoop используете? Очень хорошая штука в паре с dhcp_relay options 82. Тогда ни какие snmp правила для блокировки не нужны :)
Как я уже сказал — на мой взгляд ОЧЕНЬ спорная статья. Я бы сказал — первый блин комом… :)
По поводу радиуса — было бы интересно посмотреть Ваши наработки — как раз этим направлением занимаюсь :)
Хана вашей сетке :)
Вы замеряли сколько в Вашей сети «нормально» бегает бродкаста? В большой сети до нескольких сотен пакетов в секунду. Вы же рубите порт на 64 пакетах за 5 секунд. И дропаете всё что выше. Причём свитч не будет разбираться, что он дропает, полезный бродкаст или нет. Даёте рекомендации без описания, почему и как работает. С этой функцией надо обращаться ОЧЕНЬ аккуратно.
Тут стоит добавить, что НЕ РЕКОМЕНДУЕТСЯ включать этот функционал на магистральных портах :) Только на пользовательских.
Ещё раз о System интерфейса свитча. Он должен быть привязан к отдельному VLAN (в простонародье к менеджмент-VLAN) по 2 причинам:
1. Безопасность. Незачем пользователю видеть IP-управление свитча. Иначе это всегда шанс: перехватить трафик управления, подобрать пароль к свитчу и т.д.
2. Уменьшение нагрузки на CPU свитча. Весть трафик который ip-бродкаст — попадает на проц и обрабатывается им. Вынеся IP управления в другой VLAN — лишаете этот трафик шанса загрузить свитч.
При включенном dhcp_relay и указанной мной выше команде (при правильных настройках), запрос юникастом прекрасно попадает на DHCP-сервер, возвращается и попадает к клиенту. Если у Вас не работало — то только из-за не правильных настроек или словили баг старой прошивки.
В результате у Вас получилась ОЧЕНЬ спорная статься. Те статьи, на которые Вы же ссылаетесь, написаны более правильно, на мой взгляд. Меньше ошибок и глупостей.
2. IP свитча в пользовательском VLAN — это даже не дыра, а дырища в безопасности.
config dhcp_relay add ipif System xxx.xxx.xxx.xxx — и пакеты на DHCP сервер будут уходить в менеджмент vlan юникастом. Главное, что бы по маршрутизации DHCP-сервер и свитч друг-друга видили. Альтернатива — dhcp_local_relay. Он только добавляет в пакет option 82, пакет дальше идёт бродкастом. Т.е. DHCP-сервер должен быть в этом VLAN.
3. isc-dhcp-server имеет один серьёзный недостаток — если у Вас много записей (а у нормального провайдера их много), то у Вас получится ОЧЕНЬ большой конфиг. Да, его можно формировать скриптом. Но при любом изменении придётся сервис дёргать. Не умеет isc-dhcp-server на лету перечитывать конфиг. Сейчас смотрю в сторону freeradius. Последние версии умеют работать как DHCP-сервер. Со всеми плюшками прямой работы с SQL серверами. (п.с. выше уже написали).
П.С. По настройке — обратитесь в любое представительство D-Link. Благо их много. Консультанты там обычно толковые. Много чего рассказать могут. И семинары бесплатные :)
1. На тот момент как я с ними работал этого ещё не было.
2. Не разобрался сам, а в инете нашёл не правильные ответы.
На текущий момент в работе у меня их ни где нет, а покупать чисто для себя побаловаться — как то тоже лишних денег нету :)
А сравнивать не управляемый свитч и управляемый — это вообще не корректно. И ценник у цисок, даже у б.у. задран всё равно. Уже глюков на цисках, даже на шассийных я насмотрелся вагон и маленькую тележку. Когда в ЦОД из 200+ оптических модулей CISCO за первых 2 года в утиль ушло больше 10% модулей — это был полный улёт.
Удачные и неудачные решения есть у всех производителей. Поэтому хороший админ и отличается от посредственного тем, что у он их знает и умеет работать с разными.
Для меня сейчас в D-Link есть 1 главный +. Возможность потестить их оборудование до покупки. С большинством остальных производителей — надо сначала купить, что бы понять — подходит или нет.
Ситуация 1: Было 3 микротика. Роутеры, где WAN являлся WiFi модулем. Соответственно они создавали треугольник. Производителем заявлено, что поддерживает STP. Включили. Сеть начала падать вся. Даже LAN интерфейсы. Отсылали настройки производителю. Что не так работает они сказать так и не смогли.
Ситуация 2: 2 интерфейса на микротике. Надо использовать 2 провайдера — один основной, второй резервный. Мониторить можно было только Default Gate провайдера. Всё. Мониторить какой-то удалённый сервер и реагировать по доступности этого сервера? Только самописными скриптами. Спасибо хоть так. Балансировка — то же скриптами.
Могу продолжать. Но надо ли?
Может сейчас уже и поменялось в лучшую сторону, но как в том анекдоте «ложки нашли, а вот осадок остался».
А так — для своей ниши не плохое решение.
Но когда я прихожу в школу к дочке — я вижу в классе самые простые не управляемые свитчи и они рады, что у них есть хоть это. Когда я прихожу на любую из 5 поддерживаемых мной фирм — там стоит в лучшем случае в качестве точки доступа просто роутер фирмы что-то-Link, и ему уже лет 5, и он о ужас стандарта 802.11G. И им этого хватает! И это всё работает.
И когда шеф хвастается этой точкой DAP-2310 — все его знакомые говорят «круто!». В одной коробочке 3 точки!
И когда маленькой фирме на 10 человек надо сделать гостевой доступ для скучающих ожидающих клиентов очень не хватает таких вот маленьких, бюджетных и простых в администрировании решений. Без контроллеров на серверах. Их нет, они не нужны в небольшой фирме, где веб и почта на хостинге где-то далеко. :)
Кстати очень не много «админов» на сегодняшний день настроить корректно ни то что хомячковый линксис, а хотя бы винду с драйверами корректно поставить.
Кстати этот функционал должен уметь чип, что бы не приходилось, как в делать это программно на ЦПУ (куда опять же нужен шустрее чип). И всё это сказывается на цене. И у хомячкового линксиса цена далеко не самая бюджетная. С тем же функционалом и стабильностью есть много гораздо дешевле решений. Там пол цены только за имя.
Именно поэтому бюджетное решение решение сегодня не умеет ничего кроме точки доступа на 1 SSID. И стоит меньше 50$. А Enterprise (который по Вашему вовсе и не интерпрайз, а так не пойми что) стоит более 150$.
Как то так.
Кстати — я до сих пор не понимаю и не принимаю программных контроллеров. Это должно быть аппаратное решение, иначе ни о какой стабильности говорить нельзя. Программный — только радиус сервер (тут уж аппартно сложно). Но это отдельный холивар :) И думаю тут ему не место.
P.S. ух… Выговорился :) Надо завязывать. Что-то я по молодости (первый день на хабре не рид-онли) увлёкся :)
Надеюсь ещё будет возможность и необходимость пощупать такие решения. Всегда интересно новое.
Посмотрел вокруг и подумал. А на D-Link мы действительно подсели. Свитч, ip-телефоны, теперь и WiFi. Незаметненько так :)
"Покупатель: - Мне нужна игрушечная машинка для ребёнка. Продавец: - Он же когда-то вырастет, берите сразу настоящую! И она же всего в n-цать раз дороже."Смысл? Если мне нужен будет контролер, я посмотрю контролеры. :) Может быть тогда и на Ваше решение обращу внимание.
1. «Работа с multiple SSID и multiple VLAN — возможна и неоднократно проверена, но не через WEB-морду.» Т.е. быстрой и простой настройки не увидел.
2. Цена на Ubiquity UniFi AP (как я понял самая простая из этой серии) — market.yandex.ua/model.xml?modelid=7350930&hid=723087 от 75$ примерно.
Цена на DAP-2310 — market.yandex.ua/model.xml?modelid=7715367&hid=723087&suggest=1 от 55$ примерно.
Т.е. по цене выгоды не вижу ну ни как.
3. D-Link мне в представительстве производителя без проблем выдали на тест. Я его опробовал перед покупкой. Остальные производители — только по знаком у продавца и «очень окуратно».
Пока что плюсов в Вашей рекомендации не увидел.