Как стать автором
Обновить
79
0
Антон Винокуров @antonvn

Пользователь

Отправить сообщение
Действительно, софт и железо контроллеров в партнамбере содержат магические буквы K9, что подразумевает наличие шифрования (протокол обмена данными между контроллером и точками доступа, CAPWAP, использует в качестве транспорта DTLS, а он в свою очередь — AES256). Для кое-кого это красная тряпка. Формально ввезти и продать конечному пользователю оборудование с шифрованием дистрибутор может, но это сопряжено с определенным бумажным геморроем, и дополнительным временем (лицензия, запрос разрешения). Более детально я не в теме. Для контроллеров 5508 есть специальная опция LDPE (они сделали специально для нашего рынка), без шифрования канала данных (подробнее здесь).
А у вас WCS/NCS есть? Штука полезная.
Сейчас рейтинг этой статьи — 0, так что развивать цикл статей дальше желания особо нет :)
на таких придумали switchport port-security либо dot1x (для сильных духом админов)
"… велотренажерах, которые могут вырабатывать электроэнергию до 10кВт мощности"
я сразу подумал о законе сохранения энергии, вечных двигателях и прочем таком. а вы?
С моторолой познакомился, когда они выпустили своё первое WiMAX решение. Чуть ежа не родил, до чего ужас.
А сейчас читаю ваше описание того, как моторольные точки работают, и хоть убей не нахожу ни одной разницы с циской (в H-REAP режиме). Видимо, все вендоры так или иначе другу у друга идеи слизывают, плюс текучка кадров в пределах одной долины дает знать о себе :)
Plug'n'Play на Layer2 у циски тоже работает, на броадкаст 255.255.255.255. Я бы не советовал это использовать из-за неудобной диагностики, да и потом класть контроллер в тот же влан, где и точки — плохой дизайн (раньше LWAPP поддерживал L2 режим, его убрали)
Plug'n'Play на Layer3 — каких, простите, опций? список в студию! да и «мутные конверсии» делаются калькулятором влёт.
Разрешение по DNS-имени опять же есть (CISCO-CAPWAP-CONTROLLER.localdomain), но IMHO это хуже (настраивать лишнюю софтину), я и не стал про это писать.

Вообще тема подключения точек, их авторизации — сложная и местами нетривиальная, я и написал статью, чтобы избавить людей от чтения мутной доки, где много лишнего. И это не реклама циски, это «хозяйке на заметку», чтобы если что — время зря не тратить.
www.cisco.com/en/US/docs/wireless/controller/7.0/configuration/guide/c70ccfg.html#wp2039836
Грубо говоря, до 200 клиентов на радио (отдельно 2.4 и 5 Ггц). Это очень много, на практике рекомендую планировать до 30-50 клиентов на радио, смотря по типу трафика и параметрам помещения. Они же все общий частотный канал делят.
Коллеги, убедительная просьба не разводить, как в прошлый раз, бесполезную дискуссию на тему «ваша циска отстой, вендор Х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, иначе их хлам никто не купит. На деле проблемы возникают от кривой реализации стандартов. С этим можно бороться только опытом, шишками, да внимательным чтением документации.
Я сдал CCIE R&S не читая RFS, и пока не жалею об этом. Для CCIE Wireless written возможно чтение стантартов и имеет смысл, хотя я лично просто прочитал пару толковых книжек. Для CCIE Wirelеss лабы, уверяю, стандарты совсем не нужны, важны быстрота реакции и знание где что как конфигурится (и это крайне вендорспецифично).
Я RFC по CAPWAP и разным 802.11 не читал, и не собираюсь и вам не советую: пустая трата времени (хотя приходилось рыться в RFC когда писал код, реализующий EAP, или DHCP сервер — однако это не админство). Есть куча хороших книжек на эту тему, можно возможность провести эксперименты, поснифить. Если бизнес хочет построить серьезную сетку на оборудовании Cisco (а не воткнуть пару Длинков), запустить ее в продакшн и связать с серьезной задачей, наверное стоит подумать о том, чтобы вложить ресурсы в обучение специалистов, стенд и тесты.
Вы эти RFC когда-нибудь сами читали? Их делают специально такими, чтобы начинающий ничего не понял. К тому же, вендорная реализация может быть немного не такой, как написано в официальном RFC (да и в доке тоже). Большинство шишек набивается из-за косяков индусских кодеров.
Вот именно для тех, кто «получил хозяйство, и не знает что с ним делать» и написана статья. На самом деле официальная документация написана примерно как «вот фича, включай ей так», при этом мало где рассказано, зачем эта фича нужна, и как с ней связаны другие. Реально понимать, как это всё на самом деле работает, начинаешь через год плотной работы. Если будет интерес, я буду и дальше писать продолжения статьи, с детальным разбором разных особенностей, коих немало.

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Дата рождения
Зарегистрирован
Активность