Первоначальная настройка Wi-Fi контроллера Cisco

    Итак, свершилось. Тебе на стол принесли свежекупленный контроллер wi-fi производства Cisco, и ещё десяток новых точек доступа. Что это, зачем мне, как оно работает? Как мне установить этот контроллер в сеть, и наконец-то «раздать фай-фай правильно»? Об этом и пойдет речь сегодня.

    Зачем нужен контроллер? Не сильно вдаваясь в подробности, точки доступа и контроллер совместно предоставляют доступ беспроводным клиентам к остальной (проводной) части сети. Половину задач, связанных с доступом к радио-среде, генерацией beacon фреймов, шифрованием, выполняет сама точка доступа. Другую половину, в основном ассоциацию и авторизацию, обслуживает контроллер. Это называется Split-MAC архитектурой.



    К контроллеру через локальную коммутируемую сеть подключены точки доступа (конечно, производства Cisco, хоть и протокол взаимодействия CAPWAP открыт). Их может быть до сотен на контроллер, в зависимости от его производительности. Несколько контроллеров можно объединить в группы, при этом обеспечивается скоординированная работа контроллеров, и самих точек, согласно общим настройкам. Преимущества такого подхода очевидны: централизованное управление, гибкость настроек, отказоустойчивость, балансировка нагрузки, интеллектуальные функции вроде бесшовного роуминга, управления частотным ресурсом, мощностью, качеством обслуживания, авторизацией.

    На точках доступа, подключенных к контроллеру, т.н. «легковесных» (lightweighted) работает практически такой же образ IOS (AIR-LAP-xxx), что и на обычных (standalone, AIR-AP-xxx). Разница в отсутствии режима «conf t», так как точки настраиваются контроллером централизованно. Прошивки между standalone lightweighted можно вручную менять «туда и обратно».

    При старте точка доступ производит поиск лучшего из доступных контроллеров по достаточно сложной схеме, авторизуется, скачивает прошивку (если требуется), настройки, и начинает обслуживать клиентов. Между точкой и контроллером организован канал управления (UDP порт 5246), и канал данных (UDP порт 5247). Пользовательские данные инкапсулируются в UDP пакеты независимо от номера клиентского WLAN/VLAN, что позволяет размещать точки доступа где угодно в сети (на access портах коммутаторов), и централизовано управлять безопасностью на уровне VLAN на стороне контроллера. Для случая «удаленного офиса», где нет контроллера, предусмотрен режим с локальным свитчингом трафика клиентов.



    Контроллер архитектурно представляет собой специализированный компьютер (разная аппаратная архитектура и разрядность, в зависимости от модели) с достаточно старой версией MontaVista Linux внутри. К ядру добавлено несколько модулей, иногда драйвера для железа, занимающегося аппаратным ускорением шифрования или пересылки пакетов. Все действия, связанные с жизнедеятельностью контроллера, исполняет большой монолитный процесс, оформленный как user-приложение.

    Подключив контроллер к питанию, COM-порту (9600/8/N/1) и локальной сети, требуется произвести первоначальную настройку. Это просто, если понимаешь, что и зачем спрашивают. Ниже приведена процедура первоначальной настройки контроллера NME-AIR-WLC (модуль для маршрутизатора ISR), в моем случае успешно виртуализированного и затем запущенного в виртуальной машине:

    Cryptographic library self-test....passed!
    XML config selected
    Validating XML configuration
    Cisco is a trademark of Cisco Systems, Inc.
    Software Copyright Cisco Systems, Inc. All rights reserved.

    Cisco AireOS Version 7.0.220.0
    Initializing OS Services: ok
    Initializing Serial Services: ok
    Initializing Network Services: ok
    Starting ARP Services: ok
    Starting Trap Manager: ok
    Starting Network Interface Management Services: ok
    Starting System Services: ok
    Starting Fastpath Hardware Acceleration: ok
    Starting Switching Services: ok
    Starting QoS Services: ok
    Starting Policy Manager: ok
    Starting Data Transport Link Layer: ok
    Starting Access Control List Services: ok
    Starting System Interfaces: ok
    Starting Client Troubleshooting Service: ok
    Starting Management Frame Protection: ok
    Starting Certificate Database: ok
    Starting VPN Services: ok
    Starting LWAPP: ok
    Starting CAPWAP: ok
    Starting LOCP: ok
    Starting Security Services: ok
    Starting Policy Manager: ok
    Starting Authentication Engine: ok
    Starting Mobility Management: ok
    Starting Virtual AP Services: ok
    Starting AireWave Director: ok
    Starting Network Time Services: ok
    Starting Cisco Discovery Protocol: ok
    Starting Broadcast Services: ok
    Starting Logging Services: ok
    Starting DHCP Server: ok
    Starting IDS Signature Manager: ok
    Starting RFID Tag Tracking: ok
    Starting RBCP: ok
    Starting Mesh Services: ok
    Starting TSM: ok
    Starting CIDS Services: ok
    Starting Ethernet-over-IP: ok
    Starting DTLS server: enabled in CAPWAP
    Starting CleanAir: ok
    Starting WIPS: ok
    Starting SSHPM LSC PROV LIST: ok
    Starting RRC Services: ok
    Starting FMC HS: ok
    Starting Management Services:
    Web Server: ok
    CLI: ok
    Secure Web: Web Authentication Certificate not found (error). If you cannot access management interface via HTTPS please reconfig
    Secure Web: Web Authentication Certificate not found (error). If you cannot access management interface via HTTPS please reconfigure Virtual Interface.

    (Cisco Controller)

    Welcome to the Cisco Wizard Configuration Tool
    Use the '-' character to backup


    Приостанавливаем действие фичи autoinstall. Она позволяет контроллеру автоматически загрузить по TFTP заранее приготовленный конфиг-файл. Таким образом, можно развернуть в сети очень много контроллеров, не прибегая к ручной настройке каждого. Полезно, если у вас работает система управления WCS.
    Would you like to terminate autoinstall? [yes]: yes
    AUTO-INSTALL: process terminated -- no configuration loaded


    Устанавливаем имя контроллеру (предлагаемое генерится из МАС-адреса), логин и пароль администратора:
    System Name [Cisco_bb:bb:40] (31 characters max): wlc4.ххх.ххх.net
    Enter Administrative User Name (24 characters max): anton
    Enter Administrative Password (3 to 24 characters): *********
    Re-enter Administrative Password : *********


    Настраиваем адресацию интерфейса управления. Это логический интерфейс, через который контроллер «общается» с внешним миром (кроме точек доступа). Обычная практика такова, что все физические интерфесы контроллера объединяют в EtherChannel группу (вы можете сделать это позднее), и в таком общем канале настраиваете сколько требуется логических интерфейсов, каждый в своем VLANе. В данном примере между коммутатором и контроллером создан trunk-порт, а обслуживание ведется через VLAN 310. Для access-порта, или если у вас применяется native VLAN, укажите номер 0. Адрес DHCP-сервера нужен для пересылки тому клиентских DHCP-запросов, если таковое будет настроено. Контроллер будет DHCP-релеем (хотя также может исполнять роль DHCP-сервера).

    Management Interface IP Address: xx.xx.145.10
    Management Interface Netmask: 255.255.255.128
    Management Interface Default Router: xx.xx.145.1
    Management Interface VLAN Identifier (0 = untagged): 310
    Management Interface Port Num [1]:
    Management Interface DHCP Server IP Address: xx.xx.145.9


    Все контроллеры, кроме модели 5508, используют отдельный логический интерфейс ap-manager для общения с точками доступа. Необходимо настроить его адрес, обычно из той же сети:
    AP Manager Interface IP Address: xx.xx.145.14
    AP-Manager is on Management subnet, using same values
    AP Manager Interface DHCP Server (xx.xx.145.9):


    Последнй логический интерфейс — виртуальный. Он используется для передачи DHCP-запросов клиентам, веб-авторизации, роуминга. На него прописывают адрес, не использующийся нигде в сети и не маршрутизируемый, обычно это 1.1.1.1. Внимание: он должен быть одинаков для нескольких контроллеров, между которыми предполагается роуминг клиентов.
    Virtual Gateway IP Address: 1.1.1.1


    Для целей роуминга клиентов контроллеры объединяются в группы мобильности (mobility group), имя которой и предлагается задать. Также предлагается задать имя группы контроллеров, совокупно обеспечивающих управление радиорескрсом (частотный план и мощность, rf group). Хотя это могут быть разные группы по набору устройств и имени, здесь указывается общее имя (его можно изменить позднее):
    Mobility/RF Group Name: WLAB


    Визард предлагает создать одну беспроводную сеть (WLAN). Я обычно указываю здесь что-нибудь, все равно затем я эту сеть удаляю, и создаю правильную из веб-интерфейса.
    Network Name (SSID): test


    Режим бриджинга DHCP-пакетов экзотичен и на практике вряд ли применяется.
    Configure DHCP Bridging Mode [yes][NO]:


    Вы можете разрешить работу беспроводных клиентов, у которых IP-адрес прописан статически. Реально эта опция включает кэширование ARP на контроллере, что полезно.
    Allow Static IP Addresses [YES][no]:


    Для целей авторизации клиентов (а также доступа к контроллеру, и некоторых специфичных других) может быть использован внешний RADIUS-сервер, который удобнее настраивать позже через веб-интерфейс.
    Configure a RADIUS Server now? [YES][no]: no
    Warning! The default WLAN security policy requires a RADIUS server.
    Please see documentation for more details.


    Каждая точка доступа, и контроллер, имеют допустимые коды страны, в которой они работают. В действительности country code определяет разрешенный набор частот (каналов) и предельных мощностей, что влияет на работу алгоритмов автоматического выбора частоты и т.д. Крайне рекомендуется, чтобы во всей вашей сети список кодов стран был настроен единообразно.
    Enter Country Code list (enter 'help' for a list of countries) [US]: RU


    Контроллер предлагает включить сети 2.4 и 5 ГГц (11b/g/n и 11a/n соответственно). В действительности этот парамер передается на ассоциированные с контроллером точки доступа, на которых собственно и установлено радио. Я советую включать радио через веб-интерфейс уже после того, как все остальные параметры настроены.
    Enable 802.11b Network [YES][no]: no
    Enable 802.11a Network [YES][no]: no


    Запрос на включение полезных алгоритмов динамического управления частотным ресурсом и мощностями, о чем мы говорили ранее.
    Enable Auto-RF [YES][no]:


    Настройки времени (сервер времени, и статичесски заданное время/часовой пояс) важны не только для правильности меток в лог-файлах, но и для работы авторизации точек доступа по сертификатам (они используют CAPWAP, основанный на DTLS, основанный на сертификатах с известными проверками сроков валидности).
    Configure a NTP server now? [YES][no]: no
    Configure the system time now? [YES][no]: no

    Warning! No AP will come up unless the time is set.
    Please see documentation for more details.


    Наконец, если вы готовы, контроллер сохраняет конфигурацию, и перезапускается:
    Configuration correct? If yes, system will save it and reset. [yes][NO]: yes

    Configuration saved!
    Resetting system with new configuration...


    Всё, теперь устройство можно настраивать через веб-интерфейс управления, доступный через пару минут по адресу: httрs://xx.xx.145.10. Чтобы избежать ненужных вопросов о валидности сайта, контроллеру можно впоследствии выписать сертификат для работы SSL.



    Контроллеры можно настраивать и через командную строку (консоль, telnet, ssh). От синтаксиса приверженцы IOS CLI будут плеваться, а фанаты JunOS окажутся в шоке. Командная строка, однако, очень полезна для дебагов, без которых вы в беспроводных системах Cisco просто шагу не ступите.

    Теперь самое время прочитать исчерпывающее руководство по настройке контроллера, и ринуться в бой. При наличии рук и напильника достаточных средств можно подумать о внедрении крайне удобного централизованного средства управления беспроводной сетью NCS/WCS, скриншот которого приведен ниже:



    Следующий шаг — установка и подключение точек доступа.

    P.S. Автор никак не связан с компанией Cisco Systems, ничего не продает и не покупает.
    Поделиться публикацией

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.