Catalyst 9000 EWC — устанавливаем и обновляем Embedded Wireless Controller (EWC) на Catalyst 9300. Процесс, сложности, выводы.
В записи Catalyst 9000 серии прошивка хотел дополнить материал информацией по обновлению программного WLC, который можно развернуть на базе такого коммутатора. И честно стал выполнять. Однако, как ни старался сократить, объёмы материала перешкаливали все разумные пределы. Решил в таком случае выложить в виде отдельной, небольшой статьи. И не сокращать, а наоборот увеличить инфу по теме. Тема интересная, познавательная.
Тут надо сказать спасибо моей любимой конторе. На полном серьёзе. Если сразу после сдачи CCNP у меня были исключительно теоретические знания по Wi-Fi, то после года работы в местном Телекоме, сполна “насладился” контроллерами и точками доступа. Тем не менее, на момент мой опыт в теме не так велик и если что-то обозначу неверно, как всегда прошу простить. С другой стороны, писал бы только о вещах, которые знаю в идеале — на сайте было бы пусто.
Для начала предлагаю, если есть желание конечно, полюбопытствовать-ознакомиться, что вообще там присутствует в WLC от CISCO и сравнить решения разных производителей. Ознакомились? Теперь непосредственно поговорим какие существуют варианты для развёртывания беспроводного контроллера CISCO.
Надо сказать, что до EWC на точках от CISCO был похожий (на EWC) режим Mobility Express. Никогда с ним не работал, поэтому не знаю нюансов. Вполне возможно там было что-то/как-то иначе. Появится возможность, обязательно проверю.
Четыре варианта WLC
У отца было четыре сына нас есть четыре опции для развёртывания:
- Embedded Wireless on an Access Point (up to 100 APs);
- Embedded Wireless on Catalyst 9000 Series switches (up to 200 APs);
- Аппаратный 9800-L (up to 500 APs);
- Виртуально-облачный 9800-CL.
То есть, мы можем поставить аппаратный 9800-L, можем развернуть программный WLC, а можем бахнуть VM (On-Premise или в публичном облаке). Для понимания, 9800-L это далеко не самое крутое решение, наоборот, самое простое из аппаратных.

Программный WLC (EWC) возможен:
- На базе Wi-Fi точки, AP 9100 серии;
- Либо на базе коммутатора, 9000 каталиста (от 9300 и выше, модели 9200 не поддерживаются).
Какое сходство? Унифицированный веб-интерфейс, вебка будет выглядеть одинаково во всех вариантах. Такой же интерфейс у 9000 каталиста коммутатора без EWC, если что.

Сама циска утверждает:
Like the 9800 Series Wireless Controller, the EWC on Catalyst Access Points is resilient, secure, and intelligent; is open and programmable; supports streaming telemetry; and yet is simple to deploy and manage.
И да, это будет новый доработанный контроллер. В старом контроллере (например 5500) для создания SSID сначала нужно создать логический интерфейс, обязательно с IP адресом/шлюзом по умолчанию:
Note: It is mandatory to have a valid IP address for technical reasons, but this IP address is not used unless DHCP proxy or radius interface overwrite (under WLAN config) are enabled.
Затем создаётся WLAN и привязывается к этому интерфейсу. В новом контроллере создаётся политика, WLAN привязывается к политике. И есть дефолтная политика, поэтому чтобы просто создать WLAN ничего предварительно делать не нужно. Это удобно, логично, а самое главное снимает часть непоняток для сценариев, где никакой интерфейс не требуется. Поэтому обязательное создание интерфейса и убрали в новой версии.
9800-CL
Вынес в отдельный заголовок. Удобное, быстрое решение в виде VM. Вопрос с лицензиями (разберусь подробнее и дополню).
| Metric | Value |
| Maximum number of access points | Up to 6000 |
| Maximum number of clients | 64,000 |
| Maximum throughput (low profile without SR-IOV)* | 2.1 Gbps |
| Maximum throughput (high profile with SR-IOV)** | 5 Gbps |
| Maximum WLANs | 4096 |
| Maximum VLANs | 4096 |
| Deployment modes | Centralized, Cisco FlexConnect, and fabric wireless (SD-Access) |
| License | Smart License enabled |
Ключевые особенности:
- Cisco Catalyst 9800-CL is available as an Infrastructure-as-a-Service (IaaS) solution on the Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure (Azure);
- Supported with managed VPN deployment mode till 17.7;
- Supported with Public IP for AP onboarding from 17.8.
Проблемы как всегда в мелочах. При развёртывании в публичном облаке работает только как Cisco FlexConnect (local switching only). Для обычного энтепрайзного развёртывания у себя в серверной в режиме Centralized требуется для минимальной установки 4 vCPU, 8Gb памяти и желательна поддержка на сетевой карте хоста виртуализации аппаратной разгрузки (SR-IOV).

Centralized vs FlexConnect
В обоих режимах точка устанавливает CAPWAP туннель до контроллера. В режиме Centralized через контроллер идёт весь трафик, нагрузка на контроллер приличная и высокая утилизация линка контроллера. Сама точка работает на порту доступа, главное чтобы между точкой и контроллером была L3 связность. Режим FlexConnect отличается. Весь трафик точка отправляет самостоятельно, поэтому ей нужен транковый порт. В этом транковом порту Native Vlan для связи с контроллером, а тегированные VLANs — это вланы соответствующих SSIDs. То есть когда точка получает беспроводные данные в некотором SSID, она сразу пихает эти данные в нужный VLAN. Без участия контроллера. При этом CAPWAP туннель до контроллера также поднимается, но только для управляющего трафика. Называется central authentication and local switching. Нагрузка на контроллер небольшая, утилизация линка контроллера обычная.
Ещё про EWC
Являлся до недавнего времени “счастливым” обладателем трёх вариантов CISCO WLC на поддержке (аппаратный, AP EWC и EWC на 9300, а до варианта 9800-CL добрался значительно позже). Вариант на AP был мной успешно изничтожен (но крови попил). Почему “пил кровь” — далее.
Если говорить за EWC на AP, нужно всего несколько точек (2, максимум 3) перевести в EWC, переводить все точки в режим EWC не надо. Специально обратил внимание на этот момент, чуть ниже по тексту расскажу подробнее.
Далее, руками в настройках можно выбрать активный WLC среди EWC-точек (либо он выберется самостоятельно), резервный WLC будет выбран автоматически. При отвале, перезагрузке, выдёргивании патч-корда на активном WLC, роль прозрачно переедет на резервный. Для этого и нужно несколько точек в EWC режиме, для отказоустойчивости. И да, точка-контроллер работает одновременно и как WLC, и как Wi-Fi точка для клиентов. То есть вы не минусуете EWC-точки под контроллер от общего числа точек.
Продолжаем, точка-контроллер работает так же как и остальные, раздаёт Wi-Fi. Это плюс. Но чем больше клиентов на точке-контроллере, чем выше через неё трафик, тем меньше ресурсов остаётся под сам контролер. Минус. Поэтому циска рекомендует под контроллер модели повышенной мощности (C9130AXI/AXE-EWC-X). Это не обязательно и худо-бедно работать будет на любой точке из 9100 серии.
С другой стороны, лучше под контроллер выбирать самую незагруженную точку, где-нибудь в холле офиса. Да ещё, не забывайте нажимать кнопку сохранения в вебке EWC при внесении изменений. Если вы долго не сохраняете конфу и так получится, что упадёт питание на коммутаторе и туда подключены точки активного и резервного контроллера.., загрузится всё со старьём. Было такое, хотел предупредить.
Изначально на моём контроллере все точки были в режиме EWC. Контроллер отображает текущий режим в отдельном столбце при выводе точек. Подумал, что так и нужно, а по-другому не заработает. Затем попробовал перевести одну точку в режим CAPWAP. Это делается прям из веба контроллера. Она нормально прицепилась и продолжала работать штатно. Затем перевёл уже все точки в режим CAPWAP, кроме трёх для отказоустойчивости контроллера. Всё работало штатно, так и оставил. Настройки портов не менялись, они транковые. Точки в одном L2 домене обязательно. Другими словами, образ с поддержкой EWC на точке может спокойно работать и как CAPWAP.
Подробнее о развёртывании EWC на точке, напишу в отдельной статье.
Ограничения
В чём разница между железным и программным вариантами? Во-первых, в цене. Аппаратный 9800-L обойдётся на момент написания ~0,5 млн рублей за железку (цена указана примерная, смотря где брать и в каком состоянии). А их лучше две, для создания отказоустойчивого кластера. Во-вторых, максимальное количество APs, оно отличается в разы. В-третьих, функционал и эффективность работы.
Как привёл выше, вроде бы циска нам говорит, что это подобные решения, с примерно одинаковым функционалом. Всё не так просто. В бизнесе нет чудес и если бы программный контролер был настолько хорош, зачем вообще нужен аппаратный? Купил 98 БУ-шных точек AIR-CAP2802I, две точки C9120AXI, развернул EWC на 9120 и наслаждаешься решением на 100 точек. Да? Нет. 🙂
Только аппаратное решение предлагает высокую пропускную способность (до 5Gbps, до 10Gbps с Performance License), оптимальное автоматическое управление точками и клиентами, расширенный мониторинг.
| Features | 9800-L | 9800-L with Performance License |
|---|---|---|
| APs supported | 250 | 500 |
| Clients supported | 5000 | 10,000 |
| Throughput with IMIX | 5 Gbps | 5 Gbps |
| Throughput without IMIX | 5 Gbps | 10 Gbps (with 1374-byte packet size) |
А программный контроллер (особенно на AP) скорее маркетинговый ход. Урезанный вариант. Чтобы вы увидели как такое вообще бывает, как всё здорово и красиво. И затем приобрели аппаратный. На это расчёт, никто бесплатно расширенные плюшки вам не предложит. Второй расчёт, отбить вам желание покупать решения конкурентов. Типа вот у нас бесплатный контроллер, пожалуйста.
При этом самые значительные отличия между EWC на AP и 9800-L. Первое решение здорово ограничено производительностью слабенького CPU точки. Например, в EWC на AP нет даже функционала SNMP (тут надо заметить нет только в интерфейсе веба, в консоли настройки сделать можно). Повыпиливали-скрыли процессорозависимые фичи. К сожалению, что точно выпилили сказать невозможно. Циска тщательно скрывает различия между решениями. Другого объяснения у меня нет. Хотя вопрос казалось бы на поверхности: чем отличаются? Как ни искал (FAQ по WLC 9800, FAQ по EWC 9800 на AP), найти ответы не смог. Если у тебя есть такая инфа, заделись.
Предполагаю, найдутся скептики, вот мол у нас 100 точек на программном AP контроллере как раз, всё отлично, все довольны. Верю, но с трудом.
EWC на коммутаторе 9300, на мой взгляд, занимает промежуточное положение между EWC на AP и 9800-L. Тут нет такого жёсткого ограничения по CPU. Кстати, CPU коммутатора с включённым функционалом WLC юзается довольно прилично. И вроде бы все фичи на месте.., но пропускной способности 9800-L программному контроллеру не достичь. Косвенно можно судить и по размеру прошивки. Для 9800-L это больше гига (1,1 – 1,3Gb), sub-package WLC для каталиста много меньше (600 – 700Mb). Разница слишком очевидна.
Что выбрать
Излагаю лишь свой взгляд, рассказываю свою практику.
Программный WLC на AP будет работать и на 30, и на 40 точках, при этом заменой аппаратному он не является. С другой стороны, брать аппаратный контроллер на условно 5 точек, смысла нет никакого. Вот за этим, по моему мнению, EWC на AP и нужен.
Программный контроллер на AP оптимален, когда необходимо разместить 5-15 точек.
В этом случае соотношение цена/качество замечательное. Вы покупаете пару точек 9100 для EWC, остальные точки можно взять самые простые из поддерживаемых. Круто? Думаю даже очень круто.
А уж если же вы решили покупать 9300 коммутатор для каких-то своих целей, то на халяву получаете более мощный WLC. Предположим всё это дело в новый офис. Вариант? Вообще хороший вариант. Подороже конечно.
Что делать, если точек под 100? Программный EWC на AP будет работать, будет, но скорее будут и постоянные жалобы от пользователей (от VIP’ов в том числе) на разные баги в работе. Возможен вариант когда к одной точке подцепится 40 клиентов и EWC не станет их перемещать на другие точки. Встречался с таким и не только. Всё это станет плавающей проблемой и вы замучаетесь объяснять, почему нельзя исправить/улучшить. Скорее всего так.
Как поведёт себя 9300 EWC на 100 точках и больше.. сказать сложно, у меня нет такой практики. Вполне возможно что и нормально заработает, без жалоб пользователей. При этом надо заметить, что WLC на 9300 довольно сильно утилизирует CPU коммутатора, а при процедуре обновления и закачки образов точками особенно:
Threshold: Total CPU Utilization(Total/Intr): 87%/0%, Top 3 processes(Pid/Util): 324/54%, 359/28%, 150/1%
Про различие реализаций беспроводного контроллера наверное всё. Переходим непосредственно к каталисту 9300 с EWC.
Обновление Catalyst 9000 EWC
Добрались наконец до 9300 с программным WLC. На основной образ IOS XE коммутатора надо сверху накатить wireless sub-package. Процедура настройки рассказана здесь. Первое, на что надо обратить внимание, там нет ни слова про режим Bundle. Второе, нет ни слова про обновление. Это не случайно. Вот что там сказано:
To enable the non-SD-Access EWC on a Catalyst 9000 switch, the switch needs to have at least the Cisco IOS XE Release 17.3.1 image installed, along with the corresponding wireless sub-package. Please note that the base Cisco IOS XE image and wireless sub-package always need to be the same exact release.
Прошу обратить внимание на выделенное предложение. Как оказалось, версия должна совпадать не только для работоспособности, но и даже для возможности установки sub-package (образа WLC). Поэтому процедуры именно апгрейда не нашел. Да, получилось обновиться, но это не апгрейд в привычном понимании.
Предварительная настройка
Теперь подробнее. Мне выделили тестовый 9300, расположенный в другой локации, для игрищ проверки возможности обновления.
Получается, есть два образа (IOS XE + WLC) исходной версии 17.03.02a (строго как на продуктивном 9300) и два рекомендуемой на момент версии 17.09.04a. Каждый из четырёх файлов размером около гигабайта, поэтому призываю отказаться от установки через заливку с помощью веб-интерфейса. Даже если отключить тайм-аут в веб-интерфейсе 9300, страница всё равно отваливается по тайм-ауту (возможно браузера).

И когда такое произойдёт именно на этапе заливки файла, заливай снова. Поэтому заливка только через FTP/TFTP.

Итак, каталист 9300 версии 17.03.02a без WLC. Активируем веб-интерфейс:
! no ip http server ip http authentication local ip http secure-server !
Заходим на вебку, вкладка Administration – Software Management, подпихиваем файл C9800-SW-iosxe-wlc.17.03.02a.SPA.bin.

После успешной установки на основной дашборде веба значок включения функционала WLC (справа вверху) станет доступным. Нажимаем на него, появляется сообщение что произойдёт логаут и заходить просят через 30 секунд. Это важно, не надо сразу логиниться обратно. Иначе функционал не успеет включиться.
После перезахода основная дашборда изменит вид, на ней появится мониторинг WLC. Указанный значок теперь горит зелёным.

С этим ясно.
Метод тестирования
Далее, как проверить сохранность настроек WLC при обновлении? Настраиваю несколько тестовых SSIDs. Это всё что я смог придумать.

Потому что нет возможности выгружать с продуктивного 9300 отдельно конфиг WLC. Через веб нету, а было бы удобно. В CLI хотя там конфиг WLC отдельным куском после общего конфига, но тоже не разобраться, что именно ещё в общем конфиге относится к WLC. Слишком много всего. Если же загрузить весь конфиг целиком с продуктивного 9300, потеряю удалённый доступ к тестовому коммутатору.
Поэтому вот так настраиваю тестовые SSIDs, а показатель успешности обновления, то что эти SSIDs останутся как я их сконфигурировал. Думаю этого достаточно.
Upgrade Path to Cisco IOS XE Cupertino 17.9.x
Для железного контроллера 9800-L процесс обновления с 17.03 на 17.09 зависит от используемых APs. Если среди них нет 9130 или 9124, то апгрейдимся напрямую. А когда такие точки есть, то через промежуточную версию. Подробнее тут.
Не знаю действует ли это правило для EWC, так как не нашёл подобных доков к релизу встроенного контроллера. У меня в любом случае таких моделей точек нет, но момент надо было отметить. Для меня здесь важнее выработать саму методологию обновления.
Кроме этого перед обновлением убедительно прошу проверить ваши лицензии на устройстве и проконсультироваться в TAC (или у вашего интегратора), что после обновления лицензии не слетят. Данные можно получить через соответствующий раздел вебки либо через консоль:
#show license all
Баги
Единственный известный на момент баг версии (Open Caveats for Cisco IOS XE Cupertino 17.9.4a):
CSCwh37783 - Lobby admin page does not load in the controller.
Как оказалось после обновы, вебка действительно прогружается натужно, вызывая утилизацию CPU. Но таки грузится. Думаю это куда лучше, чем иметь дырявую ко взлому версию IOS XE.
Обновление
Терзал веб, подсовывал новые версии по-разному, апгрейд не проходил. Проблема веба, что там минимум сообщений и непонятно. Перешел в CLI, пробанул там, сразу всё стало ясно:
Switch#install add file flash:C9800-SW-iosxe-wlc.17.09.04a.SPA.bin
--- Starting initial file syncing ---
Info: Finished copying flash:C9800-SW-iosxe-wlc.17.09.04a.SPA.bin to the selected switch(es)
Finished initial file syncing
--- Starting PKG Add operation ---
Performing PKG_ADD on all members
[1] PKG_ADD package(s) on switch 1
FAILED: install_add /flash/C9800-SW-iosxe-wlc.17.09.04a.SPA.bin: Invalid installation package.
Version 17.09.04a.0.6 does not match with 17.03.02a.0.3793.
То есть, для установки версия sub-package должна быть точно равна версии прошивки коммутатора. Иными словами сначала надо прошить сам коммутатор на новую версию. И естественно перезагрузить, чтобы эта версия применилась. После чего установленная версия sub-package окажется более старой, чем основная прошивка. Функционал WLC отключится.

А потом устанавливаем новую версию sub-package, включаем функционал WLC. И видим.., что все настройки WLC обнулись в дефолт. 🙂 Такая вот тема. Как это обойти, не нашёл.

Как можно видеть, на новой версии появилась поддержка 6Ghz (чтобы это заработало, должны уметь сами APs).
В результате обновление было выполнено следующим образом:
- Выгружал конфиг из вебки в файл себе на комп;
- Обновлял основную прошивку, перезагружал;
- Обновлял sub-package;
- Включал функционал WLC;
- Заливал конфиг из файла;
- Ребутил коммутатор.
Всё успешно залилось, хотя возможно есть какие-то ограничения по версиям. Допустим, с этой версии на ту так можно (через сохранённый конфиг), а с этой на другую, уже не прокатит. Рассказал как знаю, думаю кому-то поможет. Либо же возможно кто-то подскажет, как можно сделать лучше.
Продакшен
Через некоторое время обновили в продакшене по данному методу. Всё успешно, уже с подхватом APs и клиентов. Почему-то не догрузились все настройки AAA, пришлось подправлять ручками. Значит предположение о возможной несовместимости каких-то версий оправдано.
#show install summary
[ Switch 1 2 ] Installed Package(s) Information:
State (St): I - Inactive, U - Activated & Uncommitted,
C - Activated & Committed, D - Deactivated & Uncommitted
--------------------------------------------------------------------------------
Type St Filename/Version
--------------------------------------------------------------------------------
IMG C 17.09.04a.0.6
PKG C flash:C9800-SW-iosxe-wlc.17.09.04a.SPA.bin
Ещё перед перезагрузкой после заливки конфига возникло вот такое странное сообщение:
WARNING:
Boot variable either does not exist or buffer is too small
This may impact autoboot of the router. Proceed with caution
Do you wish to proceed with reload anyway[confirm]
Reload command is being issued on Active unit, this will reload the whole stack
Proceed with reload? [confirm]
Перезагрузка прошла при этом без проблем. Тем не менее, обращаю внимание на данный факт.
Итого, ты делаешь так, затем сяк, у тебя не получается, ты не понимаешь. Спустя время приходит опыт и понимание. Но мгновенно такого понимания достичь нельзя. Нужно поблуждать в потёмках, почитать опыт других людей, гайды разумеется, попробовать самому. Это и есть настоящие дневники сетевого инженера.
Ссылка на Best Practices для 9800, всегда полезно почитать. Даже если у тебя нет такого контроллера.
Приглашаю поделиться мнением в Tелеграм канал

