Большим игрокам это очень надо, но решения будут проприетарными. Джунипер делает JunOS Space, циска Cisco One, наверняка за этим последуют и другие. Направление централизации управления и выноса части мозгов в control plane где-то в сети (чтобы как минимум руками не конфигурить правила для mpls te) — вполне здравое.
Но вот во что я не верю, так в абстрактный university research, который придумал нечто феерическое и пытается впарить это VMware, Inc.
В прошлой жизни я сам поработал некоторое время в классическом западном computer science и мужики вроде основателей Nicria были моими коллегами. Да, они знали Кнута наизусть и могли в ночи разбуженные воспроизвести алгоритм Дейкстры на Алголе. Но такие люди страшно далеко оторваны от реалий. Маршрутизатор они в глаза не видели, а BGP для них — набор RFC, а не двести строчек конфига. Они, наверное, могут придумать что-то интересное, но посмотрите сами — 95% научных статей по компьютерной тематике (не в журнале Хакер, а в тех что издает IEEE) — не применимая в жизни туфта. Неприменимая потому, что у университетских исследователей, и у больших корпораций очень, очень разные задачи, проблемы, финансирование, образ мыслей. Редко когда какие-то наработки находят применение в реальном продукте, и еще реже, когда получается надвендорный продукт.
Очень интересно, как большие вендоры вроде Cisco и Juniper отнесутся к тому, что какая-то стороняя софтина, разработанная индусскими студентами (это же пока университетский ресерч, не так ли) будет управлять потоками трафика на их железе. Пока такого рода управление (вынесенное в отдельный control plane, либо по-старинке в ядре операционки) делается проприетарным софтом, существуют понятия «ответственность», «саппорт», «SLA» и т.п. А если этим занимается нечто, к которому вендор (кроме API) имеет мало отношения, кому конечный пользователь станет предъявлять претензии?
Мне кажется, до реальных продуктов с SDN еще очень далеко. Это тема — для диссертаций, симуляций в OpNET Modeler, как это случилось в свое время c G-MPLS.
Можно понять VMware, она железа не делает, и опыт с Nexus 1000v оказался вполне успешным. Но другим большим игрокам IMHO это нафиг не надо.
Это всё здорово, при наличии а) грамотного админа и б) вменяемого беспроводного оборудования. Однако, увы, до сих пор подавляющее большинство беспроводных сетей строится пионерами и на д-линках. По бедности, конечно же…
EAP-TLS требует клиентских сертификатов, распространение которых юзерам в не-только-виндовс среде вызывает определенный геморрой. PEAP — вполне себе нормальный выход.
Действительно, софт и железо контроллеров в партнамбере содержат магические буквы K9, что подразумевает наличие шифрования (протокол обмена данными между контроллером и точками доступа, CAPWAP, использует в качестве транспорта DTLS, а он в свою очередь — AES256). Для кое-кого это красная тряпка. Формально ввезти и продать конечному пользователю оборудование с шифрованием дистрибутор может, но это сопряжено с определенным бумажным геморроем, и дополнительным временем (лицензия, запрос разрешения). Более детально я не в теме. Для контроллеров 5508 есть специальная опция LDPE (они сделали специально для нашего рынка), без шифрования канала данных (подробнее здесь).
"… велотренажерах, которые могут вырабатывать электроэнергию до 10кВт мощности"
я сразу подумал о законе сохранения энергии, вечных двигателях и прочем таком. а вы?
С моторолой познакомился, когда они выпустили своё первое WiMAX решение. Чуть ежа не родил, до чего ужас.
А сейчас читаю ваше описание того, как моторольные точки работают, и хоть убей не нахожу ни одной разницы с циской (в H-REAP режиме). Видимо, все вендоры так или иначе другу у друга идеи слизывают, плюс текучка кадров в пределах одной долины дает знать о себе :)
Plug'n'Play на Layer2 у циски тоже работает, на броадкаст 255.255.255.255. Я бы не советовал это использовать из-за неудобной диагностики, да и потом класть контроллер в тот же влан, где и точки — плохой дизайн (раньше LWAPP поддерживал L2 режим, его убрали)
Plug'n'Play на Layer3 — каких, простите, опций? список в студию! да и «мутные конверсии» делаются калькулятором влёт.
Разрешение по DNS-имени опять же есть (CISCO-CAPWAP-CONTROLLER.localdomain), но IMHO это хуже (настраивать лишнюю софтину), я и не стал про это писать.
Вообще тема подключения точек, их авторизации — сложная и местами нетривиальная, я и написал статью, чтобы избавить людей от чтения мутной доки, где много лишнего. И это не реклама циски, это «хозяйке на заметку», чтобы если что — время зря не тратить.
Коллеги, убедительная просьба не разводить, как в прошлый раз, бесполезную дискуссию на тему «ваша циска отстой, вендор ХYZ лучше». Может быть. Докажите. Напишите сами статью.
Спасибо.
Впарить Cisco Linksys вместо Cisco WLAN — зачёт!
На счет CLI согласен — достаточно сравнить «show run-config commands» и то, что получается после TFTP аплоада конфига. Да я и сам первые полгода от синтаксиса плевался, но что поделать, привык. Есть клиенты, крупные компании, которым моновендорность, энтерпрайз фичи и поддержка важнее моднявости и лишней сотки баксов. Поэтому я занимаюсь циской, а не д-линком.
Это тяжкое наследие покупки Aerispace. Понятно дело, другим начинать разработку с нуля проще. Да я и не спорю, такой методу подключения контроллера (как и встроенного в 3750, так и WISM) крив и выглядит как собаке пятая нога. А что, цискин VoIP, реализованный на платформе роутеров, лучше что-ли? :)
Позволю себе не согласиться на тему интеграции Cisco WiFi с остальным от Cisco же. Что касается мониторинга и управления, чисто беспроводную систему WCS давно выкинули, и развивают NCS (она же Prime). Там можно вдобавок рулить коммутаторами (а а какому порту подключена «вредная» точка доступа). Похоже, все остальные цискины платфоры управления в итоге сведутся к нему.
Что касается авторизации, отличный продукт ACS (радиус и такакс сервер) недавно слили вместе с ISE (сам пока не щупал), фактически теперь платформа авторизации, полисинга, мониторинга есть в одном флаконе. Для бедных встроенный радиус-сервер в контроллере тоже есть. Очень сомневаюсь, что у «другого вендора» есть что-то похожее и получше, чем «возьмите фрирадиус».
Это всё как с автомобилями — есть бентли, есть шкода, есть жигули. В принципе, и то и другое везёт. Есть и гаражные дяди васи, и официальный сервис. Вопрос в комфорте, фичах, надежности и стоимости, каждый выбирает сам.
Интересно, а делал ли кто-нибудь действительно техническое сравнение функционала всех этих различных вендоров. Так, чтобы не на основе чтения даташита, а реально поковыряв устройства на столе, хотя бы пару недель? Я пока не нашел такого. Очень много кто пишет, что «ваша циска отстой, ставьте XYZ», но это голословные утверждения, вытекающие из того, что пишущий торгует продуктом данного вендора. Так как я сам не ангажирован никем, я бы взялся независимо протестировать устройства других производителей — только кто мне их даст?
А также гигабит эзернета и консоли. Действительно, любой контроллер — это такой линукс, со спецсофтом внутри. Точки доступа, напротив, действительно работают под управлением IOS, который загружается с контроллера (каждый контроллер несет в себе иосы от всех совместимых с ним точек). О загрузке точек и подключении их к контроллеру — в следующей статье.
Удивительно, что никто не попался на тонкий троллинг, не обратил внимания на слово «виртуальный» или на прикольные serial no. / bia address контроллера в последнем скриншоте (и это не фэйк).
За консолью другого оборудования можно развести руками из-за идиотского синтаксиса команд (попробуйте перелезть с циски на H3C). Все вендоры заявляют о поддержке RFC, иначе их хлам никто не купит. На деле проблемы возникают от кривой реализации стандартов. С этим можно бороться только опытом, шишками, да внимательным чтением документации.
Но вот во что я не верю, так в абстрактный university research, который придумал нечто феерическое и пытается впарить это VMware, Inc.
В прошлой жизни я сам поработал некоторое время в классическом западном computer science и мужики вроде основателей Nicria были моими коллегами. Да, они знали Кнута наизусть и могли в ночи разбуженные воспроизвести алгоритм Дейкстры на Алголе. Но такие люди страшно далеко оторваны от реалий. Маршрутизатор они в глаза не видели, а BGP для них — набор RFC, а не двести строчек конфига. Они, наверное, могут придумать что-то интересное, но посмотрите сами — 95% научных статей по компьютерной тематике (не в журнале Хакер, а в тех что издает IEEE) — не применимая в жизни туфта. Неприменимая потому, что у университетских исследователей, и у больших корпораций очень, очень разные задачи, проблемы, финансирование, образ мыслей. Редко когда какие-то наработки находят применение в реальном продукте, и еще реже, когда получается надвендорный продукт.
Мне кажется, до реальных продуктов с SDN еще очень далеко. Это тема — для диссертаций, симуляций в OpNET Modeler, как это случилось в свое время c G-MPLS.
Можно понять VMware, она железа не делает, и опыт с Nexus 1000v оказался вполне успешным. Но другим большим игрокам IMHO это нафиг не надо.
Сейчас рейтинг этой статьи — 0, так что развивать цикл статей дальше желания особо нет :)
я сразу подумал о законе сохранения энергии, вечных двигателях и прочем таком. а вы?
А сейчас читаю ваше описание того, как моторольные точки работают, и хоть убей не нахожу ни одной разницы с циской (в H-REAP режиме). Видимо, все вендоры так или иначе другу у друга идеи слизывают, плюс текучка кадров в пределах одной долины дает знать о себе :)
Plug'n'Play на Layer3 — каких, простите, опций? список в студию! да и «мутные конверсии» делаются калькулятором влёт.
Разрешение по DNS-имени опять же есть (CISCO-CAPWAP-CONTROLLER.localdomain), но IMHO это хуже (настраивать лишнюю софтину), я и не стал про это писать.
Вообще тема подключения точек, их авторизации — сложная и местами нетривиальная, я и написал статью, чтобы избавить людей от чтения мутной доки, где много лишнего. И это не реклама циски, это «хозяйке на заметку», чтобы если что — время зря не тратить.
Грубо говоря, до 200 клиентов на радио (отдельно 2.4 и 5 Ггц). Это очень много, на практике рекомендую планировать до 30-50 клиентов на радио, смотря по типу трафика и параметрам помещения. Они же все общий частотный канал делят.
Спасибо.
На счет CLI согласен — достаточно сравнить «show run-config commands» и то, что получается после TFTP аплоада конфига. Да я и сам первые полгода от синтаксиса плевался, но что поделать, привык. Есть клиенты, крупные компании, которым моновендорность, энтерпрайз фичи и поддержка важнее моднявости и лишней сотки баксов. Поэтому я занимаюсь циской, а не д-линком.
Что касается авторизации, отличный продукт ACS (радиус и такакс сервер) недавно слили вместе с ISE (сам пока не щупал), фактически теперь платформа авторизации, полисинга, мониторинга есть в одном флаконе. Для бедных встроенный радиус-сервер в контроллере тоже есть. Очень сомневаюсь, что у «другого вендора» есть что-то похожее и получше, чем «возьмите фрирадиус».
Это всё как с автомобилями — есть бентли, есть шкода, есть жигули. В принципе, и то и другое везёт. Есть и гаражные дяди васи, и официальный сервис. Вопрос в комфорте, фичах, надежности и стоимости, каждый выбирает сам.