Открыть список
Как стать автором
Обновить

Комментарии 45

Клево!
Я прошу прощения за свой пессимизм, но все же — на кого расчитана статья? Все же контроллер, это уже дорогой продакшн и если такой покупают, то берут человека, который знает как этим пользоваться. Ну глупо же обезъяне давать гранату.
А так очень приятное и доступное описание. Просто нелюблю — как и для MySQL — для cisco пишут все больше и больше HowTo, с помощью них люди понаделают бардака у себя на сети, а потом приходишь в такую компанию и пытаешься исправить этот хаос :(
в нашей стране практикуют как раз раздачу гранат.
Cisco не была бы Cisco, без такого количества HowTo.

По вашему только для Small Bisness надо документацию писать?

Мне кажется намного опасней HowTo сделай почтовый сервер сам.
А сеть, в которой функционирует этот постовый сервер, а так же все остальные системы, основанноая на таких HowTo — вас не смущает, значит?
И что значит «По вашему только для Small Bisness надо документацию писать?»
Документация на сайте Сisco существует абсолютно ко всей продукции. И лежит она в свободном доступе.
это уже смешно-под железку брать человека :))) я не говорю тут про железо уровня ISP, остальное вполне можно изучить по мануалам уже работающим админам. Будут ошибки-в дальнейшем поправят, кто из нас не делал ошибок.
У меня была та же ситуация — принесли контроллер, точки доступа, попросили разобраться и вместе со штаб-квартирой поднять сеть, что и было сделано (железо было не от Циски).
А статья весьма хороша как введение для того, кто получит это хозяйство и не знает с чего начать.
Вот именно для тех, кто «получил хозяйство, и не знает что с ним делать» и написана статья. На самом деле официальная документация написана примерно как «вот фича, включай ей так», при этом мало где рассказано, зачем эта фича нужна, и как с ней связаны другие. Реально понимать, как это всё на самом деле работает, начинаешь через год плотной работы. Если будет интерес, я буду и дальше писать продолжения статьи, с детальным разбором разных особенностей, коих немало.
Реально понимать как все это работает, начинаешь после прочтения rfc.
А не через год плотной работы и набивания шишек себе (хорошо если себе в лабе, плохо если себе и бизнесу, оперируя продакшен оборудованием)
Вы эти RFC когда-нибудь сами читали? Их делают специально такими, чтобы начинающий ничего не понял. К тому же, вендорная реализация может быть немного не такой, как написано в официальном RFC (да и в доке тоже). Большинство шишек набивается из-за косяков индусских кодеров.
До сих пор читаю. Готовлюсь к CCIE и читаю.
И написано там все очень даже простым языком.
Я сдал CCIE R&S не читая RFS, и пока не жалею об этом. Для CCIE Wireless written возможно чтение стантартов и имеет смысл, хотя я лично просто прочитал пару толковых книжек. Для CCIE Wirelеss лабы, уверяю, стандарты совсем не нужны, важны быстрота реакции и знание где что как конфигурится (и это крайне вендорспецифично).
Вот именно, а мне не хочется быть привязанным к одному вендору и попав на консоль другого оборудования, просто развести руками, потому что оно работает по общепринятым протоколам, а не по проприетарным.
За консолью другого оборудования можно развести руками из-за идиотского синтаксиса команд (попробуйте перелезть с циски на H3C). Все вендоры заявляют о поддержке RFC, иначе их хлам никто не купит. На деле проблемы возникают от кривой реализации стандартов. С этим можно бороться только опытом, шишками, да внимательным чтением документации.
В общем глупо спорить — и то и то имеет смысл. Просто мое мнение, что лучше выучить букварь, а потом учить слова, но иногда переходят сразу к слогам — кому как удобнее.
В случае CAPWAP спор бесполезен, т.к. ни один вендор не реализует CAPWAP в чистом виде, и у всех нормальных вендоров есть встроенные средства траблшутинга протоколов инкапсуляции.
Что лучше — иметь одного Левшу, который знает все и с его уходом/болезнью фирма может встать или таки лучше отдел, где есть несколько человек?
Я не говорю про компании уровня 10-50 человек. Я говорю о крупных компаниях, возможно о сети компаний.
В маленькую компанию покупать контроллер — круто, но смысл. Один контроллер 4000 серии в начальном исполнении поддерживает до 12 точек, если не ошибаюсь. Это уже я вно не маленькая контора.
Точки можно разбросать по разным офисам, в каждом будет по админу :)
Конечно идеально иметь бэкап бэкапа на всякий случай, но в действительности (не только российской), к этому приходят только когда уже всё «упало» а поднимать некому. Также идеально, когда сотрудникам дают трейнинг, а потом уже внедряют решение.
Но я по-прежнему считаю, что нет никаких проблем доверить железо толковому админу, только не делать всё сгоряча, а дать разобраться в деталях.
Разбросанные по разным офисам точки реально привязать к одному контроллеру в HQ офисе и управлять ими централизованно.
конечно реально :) я к тому, что такое железо покупают не только под большие офисы но и под распределенную инфраструктуру
Будут ошибки-в дальнейшем поправят

Как показывает практика, исправление архитектурных ошибок вызывает в дальнейшем сильную головную боль. Это как после постройки дома выяснить, что есть какая-то проблема с фундаментом.
Хотя в случае корпоративного вайфая все не так страшно, система обособленная и как правило не шибко критическая.

Ну и незнание фундаментальной теории как правило на порядки увеличивает время траблшутинга: человек просто-напросто не знает, какое поведение считать нормальным, а какое говорит о наличии проблем.

Так что да, нередко нужно нанимать человека под конкретную систему, которая либо уже внедрена, либо скоро будет. Иногда стоимость ошибок такова, что проще заранее заплатить грамотному специалисту.
А как обучаться-то тогда молодым специалистам? С ХауТу начнём, набитием шишек продолжим, пониманием всесторонним завершим и станем специалистом. Why not?
Обычно молодые специалисты останавливаются на том, что прочитают, внедрят строго по инструкции (хорошо, если инструкция правильная) и на этом остановяться.
А то, что у них на соседнем этаже 4 сети беспроводные и все точки хаотично переходят с частоты на частоту — это они не в курсе. (применимо к этому HowTo)
Поэтому я считаю, что начинать нужно не с оборудования и его HowTo, а с теории беспроводных сетей. Не уверен, что люди, взявшиеся по этому мануалу настраивать новое, купленное оборудование, в большинстве своем знают о параметрах беспроводных сетей, для чего они и с чем их едят :(
Это уже этап набивания шишек. ) Понадобится, и продолжится всесторонним изучением. Тут и теория сетей беспроводных изучится, и мануалы все прочтутся…

Быть может, я мечтатель и идеалист?
Опять же — ответил немного выше:
Реально понимать как все это работает, начинаешь после прочтения rfc.
А не через год плотной работы и набивания шишек себе (хорошо если себе в лабе, плохо если себе и бизнесу, оперируя продакшен оборудованием)
Я RFC по CAPWAP и разным 802.11 не читал, и не собираюсь и вам не советую: пустая трата времени (хотя приходилось рыться в RFC когда писал код, реализующий EAP, или DHCP сервер — однако это не админство). Есть куча хороших книжек на эту тему, можно возможность провести эксперименты, поснифить. Если бизнес хочет построить серьезную сетку на оборудовании Cisco (а не воткнуть пару Длинков), запустить ее в продакшн и связать с серьезной задачей, наверное стоит подумать о том, чтобы вложить ресурсы в обучение специалистов, стенд и тесты.
Иногда только с помощью rfc можно понять, что за проблема на сети, т.к. разбирая трафик wireshark-ом, только лишь зная что реально должно стоять в каждом бите заголовков, можно обнаружить проблему.
Угу, а спецами сразу рождаются. с CCNAwireless в зубах.
Есть такая проблема: серьезный опыт не получить без доступа к серьезным железкам, а доступ к серьезным железкам не дадут без серьезного опыта. Решается методом «обучаться у более опытных коллег в роли падавана, сначала занимаясь какой-нибудь некритичной мелочью, а потом постепенно расширять зону ответственности».
Кому как, а мне вот очень кстати пришлось.
Являясь маленьким частным субпровайдером возникла необходимость построить небольшую вафле-сеть над небольшим частным сектором (ибо операторы проводного интернета туда дойтут дет через 10 только). Точек 15-20 вполне бы меня устроили. Были мысли приобрести AIR-CT2504 на 25 «вафель», но пугало два факта — нет практики настройки таких девайсов и цена, а брать кота в мешке за такие деньги — простите, я очкую.
Теперь вот заказал.

Таких статей надо много и разных. Простых, доходчивых, есть суть. А на остальные вопросы ответит документация.
Удивительно, что никто не попался на тонкий троллинг, не обратил внимания на слово «виртуальный» или на прикольные serial no. / bia address контроллера в последнем скриншоте (и это не фэйк).
Неужели в IUO добавили беспроводные железки?
А смысл вчитываться в скриншот, который предъявлен как отвязанный от остальной статьи, как образец интерфейса? Там вполне мог быть vWLC на ВМке. Хотя смущает отсутствие сетевого адаптера — не бывает такого, чтобы у WLC не поддерживался проводной адаптер.
Нет, код контроллера к ИОСу никакого отношения не имеет.
Кроме того, модули NME-WLC интегрированы в роутер посредством блока питания :)
А также гигабит эзернета и консоли. Действительно, любой контроллер — это такой линукс, со спецсофтом внутри. Точки доступа, напротив, действительно работают под управлением IOS, который загружается с контроллера (каждый контроллер несет в себе иосы от всех совместимых с ним точек). О загрузке точек и подключении их к контроллеру — в следующей статье.
Ну, IOS это тоже такой юникс со спецсофтом внутри :) Меня лично достает подобная «интеграция». Многие вендоры OEMят беспроводное оборудование, и все равно степень интеграции выше.
Это тяжкое наследие покупки Aerispace. Понятно дело, другим начинать разработку с нуля проще. Да я и не спорю, такой методу подключения контроллера (как и встроенного в 3750, так и WISM) крив и выглядит как собаке пятая нога. А что, цискин VoIP, реализованный на платформе роутеров, лучше что-ли? :)
Ничуть. :) А вы знаете много людей, которые пользуются Cisco VoIP продолжительное время и очень им довольны? :) У меня база небольшая — ~5 организаций, но все недовольны, особенно, после того, как увидели, что делает Avaya и т.п.

К вопросу интеграции:
Motorola купила Symbol, перевела все новые свои беспроводные продукты (MotoMESH и т.д.) на эту платформу; все, что не смогла перевести — продала. Купила AirDefense и за 3-4 года добилась того, что интерфейс ADSP не сильно разнится от интерфейса WiNG, с ADSP можно управлять беспроводкой, беспроводка взаимодейстует с ADSP. Cisco годами не могла прикрутить к WLC даже IOS-подобный CLI. О той волшебной эпохе, когда у них было 3 несовместимых платформы WLAN (Airponet, Airespace, WLSM) вообще молчу :) И такое у Cisco наблюдается не только в WLAN, но в WLAN — особо остро.
Та же HP сейчас активно переваривает купленные Colubris и 3Com, через год-два, может, что и получится :) У Aruba сейчас 4 ОС, но они стараются сократить число интерфейсов.
Вопрос приоритета технологии для вендора — зачем париться, если маркетинг прокачает, и пипл схавает все равно. Сколько я видел людей, покупавших Cisco WLAN, ничего о нем не зная, кроме бренда! Одним даже таким образом впарили Linksys :)

Впарить Cisco Linksys вместо Cisco WLAN — зачёт!
На счет CLI согласен — достаточно сравнить «show run-config commands» и то, что получается после TFTP аплоада конфига. Да я и сам первые полгода от синтаксиса плевался, но что поделать, привык. Есть клиенты, крупные компании, которым моновендорность, энтерпрайз фичи и поддержка важнее моднявости и лишней сотки баксов. Поэтому я занимаюсь циской, а не д-линком.
Из зачетных баек есть еще одна: заказчик (гостиничная сеть) хотел исключительно Циску (ибо «только она будет работать как надо в нашей сверхсложной системе»), интегратор не хотел связываться. Т.к. решение было под ключ, интегратор рискнул и поставил в сеть связку из двух других вендоров (LAN + WLAN). Через год заказчик пришел сказал «мы строим еще гостиницы — дайте нам еще той Циски — мы же говорили, что она классно работает».

Я еще одного крупного клиента ссадил с Cisco WLAN после того, как они выкупили своего конкурента, у которого была беспроводка не-Cisco, и убедились, что она работает надежнее и намного удобнее и проще (и ближе к идеологии Cisco IOS) в плане настройки, чем сама Cisco :) До этого, объяснить им, что есть что-то лучше для их конкретной задачи (Wi-Fi в гипермаркетах и складах) было нереально.

Просто, оказывается, есть другие Enterprise вендоры, у которых и поддержка на месте, и востребованные энтерпрайз фичи есть в количестве больше Цискиных, а невостребованных фич не так уж и много (какой % фич железа Cisco используется большинством заказчиков?), и — что главное — работать с ними приятнее, конкуренции в канале меньше, маржи больше :)

Безусловно, в конечном счете, дело исключительно ваше. Может, в вашей местности другие вендоры представлены всякими идиотами — с таким тоже сталкивался :)
После знакомства с тем, что делают Aruba, Motorola, Ruckus, Xirrus, Aerohive и Meru остается один вопрос — зачем возиться с Wi-Fi от Cisco?
Мануалы и книги у них хорошие — да…
Интересно, а делал ли кто-нибудь действительно техническое сравнение функционала всех этих различных вендоров. Так, чтобы не на основе чтения даташита, а реально поковыряв устройства на столе, хотя бы пару недель? Я пока не нашел такого. Очень много кто пишет, что «ваша циска отстой, ставьте XYZ», но это голословные утверждения, вытекающие из того, что пишущий торгует продуктом данного вендора. Так как я сам не ангажирован никем, я бы взялся независимо протестировать устройства других производителей — только кто мне их даст?
Чтобы писать «Ставьте XYZ» нужно понимать, что XYZ меняется в зависимости от задачи, т.к. у разных вендоров разные сильные стороны. Сильная сторона Cisco — интеграция в платформу Cisco. Но в случае Wi-Fi, как мы уже обсудили выше, таковой интеграции не существует, и, следовательно, сильной стороны нет. На самом деле есть еще одна — документация и много толковых людей. Я с удовольствием читаю их руководства по проектированию и проч. рекомендации, благо здравый смысл применим к любому вендору :)
Но вот читая те же инструкции понимаешь, что сеть, которую можно построить на одном контроллере, скажем, Aruba или Motorola, придется строить на 4-5 коробках от Cisco и обеспечивать между ними интеграцию. Ну и другого полно…
Позволю себе не согласиться на тему интеграции Cisco WiFi с остальным от Cisco же. Что касается мониторинга и управления, чисто беспроводную систему WCS давно выкинули, и развивают NCS (она же Prime). Там можно вдобавок рулить коммутаторами (а а какому порту подключена «вредная» точка доступа). Похоже, все остальные цискины платфоры управления в итоге сведутся к нему.
Что касается авторизации, отличный продукт ACS (радиус и такакс сервер) недавно слили вместе с ISE (сам пока не щупал), фактически теперь платформа авторизации, полисинга, мониторинга есть в одном флаконе. Для бедных встроенный радиус-сервер в контроллере тоже есть. Очень сомневаюсь, что у «другого вендора» есть что-то похожее и получше, чем «возьмите фрирадиус».
Это всё как с автомобилями — есть бентли, есть шкода, есть жигули. В принципе, и то и другое везёт. Есть и гаражные дяди васи, и официальный сервис. Вопрос в комфорте, фичах, надежности и стоимости, каждый выбирает сам.
Для многих внедрений не нужна ни система управления, ни все навороты ACS — нужен просто контролллер, точки, какая-нибудь интеграция с Active Directory для EAP, потенциально Captive Portal и хорошая настройка Layer1/Layer2. Для филиальных офисов: роутер, VPN, NAT, WIPS. И тут оказывается, что контроллер Cisco только контролирует точки, еще нужен роутер, пара серверов и вся остальная платформа.

К сожалению (и это признают и сами сотрудники Cisco) в виду узкой специализации железок, для многих задач Cisco либо недостаточна либо избыточна. Циска хороша там, где уже есть МНОГО Циски. Если ее нет (или есть чуть-чуть) — лучше не даже связываться. Это ИМХО.

Ну, если вам нужна машина для работы — вы купите Фольксваген, какой-нибудь, а не Майбах, верно? :) В общем, сейчас мы уйдем в холивор, но, надеюсь, я донес свою точку зрения: не всегда Циско является оптимальным выбором, и в случае Wi-Fi это особенно актуально.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.