Cisco Catalyst 9300 лицензии: как выбрать без переплаты

Какая проблема с выбором Catalyst 9300 на практике

С Catalyst 9300 чаще всего переплачивают не потому, что кто-то любит дорогие опции, а потому что страшно недокупить. Коммутатор берут на 5-7 лет, а требования меняются каждые 6-12 месяцев: появляется 802.1X, растет голос и видео, добавляются новые офисы, ИБ просит больше контроля, а руководству нужна понятная картина по сети. На этом фоне лицензии и наборы функций выглядят как минное поле, и руки тянутся взять «с запасом», чтобы потом не переделывать.

Вторая причина - путаница между тем, что коммутатор умеет «в принципе», и тем, что реально будет использоваться. Многие возможности начинают приносить пользу только вместе с процессами и внешними системами: политиками доступа, централизованным управлением, мониторингом, правилами QoS, регулярным разбором инцидентов. Если этого нет, доплата превращается в набор инструментов, которыми никто не пользуется.

Ограничения, наоборот, всплывают не сразу. Типичный сценарий: сначала сеть работает «как раньше», а через полгода появляются новые задачи и выясняется, что не хватает трех вещей:

• безопасности на портах (гостевой доступ, учет устройств, подготовка к NAC/802.1X)
• видимости (телеметрия, понятные отчеты, диагностика проблем пользователей)
• управляемости (единые настройки, контроль изменений, быстрые типовые внедрения)

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

Задача простая: выбрать минимальный набор, который закрывает потребности сегодня (стабильность, QoS, базовая безопасность), но не упирается в потолок завтра, когда вы начнете внедрять NAC, потребуете больше телеметрии или перейдете к более централизованному управлению.

Сначала требования: что нужно решить до выбора лицензий

Почти все переплаты начинаются с того, что выбирают «самый полный набор», не договорившись внутри компании, какую сеть вы строите и как она будет жить ближайший год. Лицензия и функции должны отвечать на конкретные сценарии, а не на страх «вдруг пригодится».

Сначала зафиксируйте тип среды. Один и тот же коммутатор на этаже в офисе, в учебном корпусе и в больнице будет обслуживать разный трафик и разные требования по доступу. В смешанной сети обычно одновременно есть Wi‑Fi, телефония, рабочие места и IoT (камеры, турникеты, датчики), и именно это задает базовую планку.

Дальше честно опишите нагрузку и сервисы. Голос и видео чувствительны к задержкам и потерям, VDI и тяжелые бизнес-приложения дают пики, камеры создают постоянный фон. Без понимания этого трудно решить, где приоритеты реально нужны, а где они останутся «на бумаге».

Проверьте «физику» порта: скорости на доступе (1G, 10G, мультигига), аплинки, план стекирования, а также питание PoE и PoE‑бюджет. Ошибка здесь болезненнее любой лицензии: если через полгода появятся Wi‑Fi 6/6E точки или новые камеры, может не хватить ни мощности, ни портов.

До выбора уровня лицензий обычно достаточно закрыть несколько вопросов:

• Будет ли L3 на доступе (маршрутизация и ACL на коммутаторе) или достаточно L2 до ядра.
• Нужна ли готовность к 802.1X и сегментации для разных групп пользователей и устройств.
• Какие аплинки нужны сейчас и какой рост портов ожидается в течение 12 месяцев.
• Какие сервисы критичны по задержке (голос, видео, VDI).

Пример: кампус на 2 здания сегодня живет на 1G и телефонии, а через год добавляет 80 камер и Wi‑Fi 6. Если это известно заранее, требования к PoE, аплинкам и политике доступа формулируются сразу. Тогда выбор становится осмысленным, а не «на всякий случай». В проектах системной интеграции (в том числе у GSE.kz) такой опрос часто экономит бюджет сильнее, чем торг по прайсу.

Модель лицензирования простыми словами: что за что отвечает

Удобно разложить лицензирование Catalyst 9300 на три слоя: железо, сетевой функционал и подписка на управление. Когда эти слои путают, обычно и появляется переплата или риск упереться в ограничения через год.

Первый слой - само устройство. Оно покупается один раз и физически остается вашим.

Второй слой - базовые сетевые возможности. Их задает сетевой уровень лицензии (чаще выбор между Network Essentials и Network Advantage). Это про VLAN, маршрутизацию, ACL и другие сетевые функции. Обычно они не зависят от подписки на аналитику и остаются доступны.

Третий слой - подписка Cisco DNA (например, Cisco DNA Essentials или старший уровень). Это не про то, будет ли коммутатор переключать трафик, а про то, как вы будете им управлять: централизованные политики, автоматизация, расширенная телеметрия, аналитика, отчеты, интеграции.

Важный момент про сроки: если подписка заканчивается и вы ее не продлеваете, сеть, как правило, продолжает работать на купленном сетевом уровне. Но функции, которые завязаны на Cisco DNA и платформу управления, теряют ценность или становятся недоступны. Отдельно стоит вопрос Smart Licensing: даже если технически все работает, юридически нужно соответствовать купленным правам.

Чтобы не запутаться, выбирайте не «самую старшую лицензию», а набор сценариев:

• Нужна ли маршрутизация и какие протоколы реально планируются.
• Будет ли централизованное управление и автоматизация в ближайший год.
• Нужна ли расширенная телеметрия для мониторинга и разборов.
• Планируется ли NAC и 802.1X, и насколько быстро.
• На какой срок вы берете подписку: 1, 3 или 5 лет.

Для закупочных документов хорошо работает формулировка: «коммутатор с постоянным сетевым функционалом уровня X и подпиской на управление уровня Y сроком N лет, с правом продления». Так меньше спорных трактовок, особенно когда закупку и внедрение ведет интегратор.

QoS на 9300: какой набор функций реально нужен

Для кампусной сети QoS нужен не «вообще», а под конкретные классы трафика. Обычно достаточно закрыть три группы: голос (IP‑телефония), видео (конференции) и несколько критичных сервисов (VDI, ERP/1С, терминальные приложения). Остальное логично оставить в best effort, иначе политика быстро разрастается, и начинается бесконечный спор за приоритет «всего важного».

Практически QoS стоит строить вокруг двух вопросов: где вы доверяете маркировкам (DSCP/CoS) и где реально управляете очередями.

Где ставить приоритет

Политика работает только если точки выбраны правильно:

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

Важно помнить: лицензия не заменяет дисциплину в дизайне QoS. Проблемы почти всегда возникают из-за того, что QoS включили «где-то», но не договорились, кто и где ставит метки.

Классификация трафика: что реально делать

В кампусе лучше начинать с небольшого набора классов и четких правил:

• Голос: доверять только от IP‑телефона (или от голосового VLAN), иначе пользователи быстро «нарисуют» себе приоритет.
• Видео: отдельный класс, но с ограничением, чтобы видео не вытесняло голос.
• Управление Wi‑Fi (контроллер, CAPWAP) и инфраструктурные сервисы: небольшой, но стабильный приоритет.
• Бизнес‑приложения: по согласованным портам/адресам, без формулировки «все корпоративное».

Типичный подводный камень - неверная точка доверия. Например, вы доверяете DSCP на access‑порту, а туда подключен ПК, который отправляет трафик с меткой EF. Итог: голос страдает, потому что «псевдо‑голос» заполняет приоритетную очередь.

Заранее согласуйте с командой телефонии и Wi‑Fi три вещи: какие DSCP они ставят, где разрешен trust, и какие потоки должны переживать перегрузку (голос всегда первый, видео обычно второй).

NAC-готовность: что заложить, даже если NAC будет «потом»

NAC‑готовность - это когда сеть уже умеет пускать разные устройства по правилам: кого-то в рабочую сеть, кого-то в отдельный сегмент, а кого-то не пускать вовсе. Даже если сам NAC (например, Cisco ISE или другой) вы внедрите позже, коммутаторы должны поддерживать базовые механики контроля доступа. Иначе через год придется переделывать дизайн.

В кампусе почти всегда есть несколько типовых «персонажей»: корпоративный ПК, принтер, IP‑телефон, камера, гости. Для ПК обычно нужен 802.1X с выдачей роли (кто это и куда ему можно). Для устройств без 802.1X (принтеры, камеры, иногда телефоны) полезен MAB (проверка по MAC‑адресу) как временная мера. Гостям нужен отдельный сегмент, чтобы они не видели внутренние ресурсы.

Что стоит заложить заранее на Catalyst 9300, независимо от выбранного уровня:

• 802.1X и MAB на access‑портах, чтобы один и тот же порт мог работать с разными типами устройств.
• Отдельные VLAN/сегменты для гостей и для «неопознанных» устройств.
• Базовую сегментацию хотя бы по группам устройств, чтобы позже проще включить политики по ролям.
• План по идентификации: где хранятся учетные записи и как отличать «своих» от «чужих».

Проект обычно усложняют BYOD, старые устройства и требования по строгому разделению зон. BYOD означает, что правила должны меняться быстро и без ручных исключений. Старые устройства часто не поддерживают 802.1X, и тогда важно заранее решить, какие из них допускаются через MAB, а какие переводятся в изолированный сегмент.

Если NAC будет позже, но сеть строите сейчас, сформулируйте требования на входе: сколько типов устройств и «ролей» вы ожидаете, нужен ли гостевой доступ, какие зоны должны быть строго разделены (например, рабочие места и камеры), и какие порты должны поддерживать одновременную работу телефона и ПК. С этими ответами интегратору проще подобрать функции и не упереться в ограничения при росте требований.

Телеметрия и мониторинг: что включать, чтобы было полезно

Мониторинг на Catalyst 9300 лучше начинать не с вопроса «какая лицензия нужна», а с простого: какие ответы вам нужны каждый день. Чаще всего это четыре темы: кто забирает полосу, где потери и ошибки, где петля или шторм, и где началась деградация (например, выросли задержки или появились микропотери).

Базовый минимум, который дает пользу почти сразу: корректные логи, SNMP, Syslog, оповещения и простая инвентаризация. Это закрывает большинство бытовых инцидентов: «порт упал», «ошибки CRC», «пошел широковещательный шторм», «устройство перезагрузилось». Важно не просто собирать, а поставить пороги и понятные уведомления, иначе события утонут в шуме.

Расширенная видимость нужна, когда начинаются споры «сеть виновата или приложение», а также когда есть чувствительные сервисы: ВКС, виртуальные рабочие места, медицинские системы, кассовые узлы. Тогда полезны потоки трафика, метрики по приложениям и телеметрия ближе к реальному времени. Это помогает увидеть, что «интернет медленный» не в целом, а конкретный филиал забивает аплинк резервным копированием в рабочее время.

Централизованная платформа управления и аналитики оправдана, если у вас много коммутаторов, частые изменения, несколько площадок и нужна единая картина по пользователям и политикам. Если сеть небольшая, часто достаточно аккуратно настроенного NMS с понятными дашбордами и алертами.

Чтобы не получилось «собираем все, но не используем», выберите 5-7 метрик и заранее решите, что делаете при срабатывании:

• Загрузка аплинков и top talkers.
• Ошибки на портах (CRC, drops) и рост discards.
• Шторм‑контроль и всплески broadcast/multicast.
• Изменения состояния линков и частые flap‑события.
• Задержка и джиттер для критичных сегментов (если измеряете).
• Таблица MAC и аномалии (всплеск новых MAC как признак петли).
• Температура и питание (PoE‑бюджет, перегрев как причина деградации).

Функции, которые часто забывают при выборе и потом жалеют

При выборе часто смотрят на «громкие» пункты вроде телеметрии или NAC, а спотыкаются о вещи попроще: питание, аплинки, резервирование и то, насколько сложно это потом обслуживать. Эти решения редко выглядят эффектно в спецификации, но именно они становятся ограничением через 6-12 месяцев.

Стек и резервирование: полезно, но не всегда бесплатно по сложности

StackWise часто берут «на всякий случай», а потом выясняется, что в шкафу тесно, кабели стека не заложены, а обновления требуют дисциплины. Стек оправдан, когда критичны отказоустойчивость на уровне доступа и единое управление несколькими коммутаторами как одним устройством. Если это небольшой узел с простой эксплуатацией, иногда проще иметь отдельные коммутаторы и понятный план замены при отказе.

Масштаб VLAN, ACL и политик: эксплуатация важнее максимума в datasheet

Частая ошибка - спроектировать доступ «как получится», а потом год жить с сотнями ACL и исключений. На 9300 это будет работать, но цена - время на поиск причин, почему «у этого кабинета не печатает». Лучше заранее договориться о правилах: сколько VLAN действительно нужно, где заканчиваются локальные исключения, как именуются SVI, ACL и классы QoS.

Аплинки тоже забывают. Сегодня 2x10G хватает, а завтра появляются Wi‑Fi 6/6E точки и растет серверный трафик, и узкое место уже в магистрали. Попросите команду заранее назвать горизонт 12-24 месяца по скорости и типу оптики, чтобы не менять модули и не переделывать кросс.

PoE‑бюджет - классика. Берут «впритык», а затем добавляют камеры и новые точки доступа, и начинаются отключения при пике.

Перед финальным выбором полезно пройтись по короткой проверке:

• Резервирование нужно по требованию бизнеса или «на всякий случай»?
• Есть план по аплинкам (скорость, оптика, запас портов) на 12-24 месяца?
• Посчитан PoE с запасом на рост и худший сценарий потребления?
• Согласованы стандарты конфигураций (шаблоны, именование, кто меняет и как)?
• Ограничены «ручные исключения» в VLAN/ACL, чтобы сеть оставалась поддерживаемой?

Небольшой пример: в кампусе добавили новые Wi‑Fi точки и видеонаблюдение, но PoE рассчитали без запаса, а аплинк оставили 10G. В итоге сеть «по лицензии» умеет многое, но пользователи видят обрывы и задержки. Исправлять это дороже, чем заложить питание и магистраль сразу.

Пошаговая схема выбора лицензий и функций под вашу сеть

Чтобы выбрать лицензии для Catalyst 9300 без переплаты, начните не с прайс-листа, а с того, как сеть используется сегодня и как будет использоваться через год.

Шаги, которые дают понятный результат

1. Опишите 3-5 сценариев, которые сеть обязана держать без сюрпризов. Обычно это: голос, корпоративный Wi‑Fi, гостевой доступ, видеокамеры, 2-3 критичных приложения.

2. Разнесите требования по слоям, чтобы не смешивать «хочу безопасность» и «хочу мониторинг». Для каждого сценария отметьте, что нужно на L2/L3, что относится к доступу (802.1X, сегментация), что к качеству обслуживания (приоритет трафика), что к управлению и телеметрии.

3. Сформируйте «минимум на запуск» и «опции на рост» с датами. Минимум - то, без чего сеть не будет принята в эксплуатацию. Опции - то, что появится через 6-12 месяцев (например, полноценный NAC или более глубокая аналитика). Так проще понять, где достаточно базового набора, а где сразу нужен запас.

4. Проверьте совместимость с тем, что уже есть в компании. Два частых стоп‑фактора: выбранная NAC‑система требует конкретные функции для 802.1X и профилирования устройств, а текущий мониторинг ожидает определенный формат телеметрии и счетчиков. Лучше заранее сверить версии, протоколы и ожидаемые данные, чем «докручивать» после закупки.

5. Оформите спецификацию и критерии приемки. Например: голосовые вызовы не рвутся при нагрузке, гостевая сеть изолирована, для сотрудников работает 802.1X, для камер задан приоритет, а в мониторинге видны задержки, потери и загрузка портов.

Если вы привлекаете интегратора, попросите показать ту же логику в таблице «сценарий -> функция -> лицензия/опция -> срок». Так решение остается понятным, даже когда требования начнут расти.

Пример сценария: средний кампус с ростом требований за год

Представим кампус: 3 корпуса, около 800 сотрудников и студентов/подрядчиков, IP‑телефония на рабочих местах, Wi‑Fi в аудиториях и переговорных, регулярные видеозвонки. Коммутаторы уровня доступа - Catalyst 9300, аплинки на ядро, есть резервирование по питанию и по линкам.

На старте обычно болит не лицензия, а качество сервиса. Если голос и видео «сыпятся», пользователи не будут ждать, пока вы разберетесь с функциями.

Минимальный набор, который стоит зафиксировать сразу в проекте (и в конфигурации), чтобы не переделывать потом:

• QoS для голоса и видео: разметка, очереди, доверие DSCP на нужных портах, защита от «шумных» сегментов.
• Базовый мониторинг: счетчики интерфейсов, ошибки, загрузка, события по питанию и стэку.
• Резервирование: стэкирование там, где нужна отказоустойчивость, и продуманная схема аплинков.
• Аккуратная сегментация: отдельные VLAN/VRF для голоса, корпоративных устройств и гостевых зон.

Через 6-12 месяцев обычно появляются новые задачи: гостевой доступ для посетителей и поэтапный контроль устройств (сначала «кто подключился», потом - «что это за устройство и куда ему можно»). Чтобы это прошло без боли, заранее закладывают NAC‑готовность: 802.1X на портах, MAB для принтеров и телефонов, понятные политики для неуправляемых устройств, а также шаблоны портов (например, «рабочее место», «телефон+ПК», «переговорная»).

Где чаще всего удается избежать переплаты: не покупать «все и сразу», если нет процесса. Расширенную телеметрию и продвинутые сценарии автоматизации разумно докупить позже, когда есть команда и регламенты. При этом базовый сетевой уровень стоит выбирать так, чтобы не упереться в ограничения по L3‑возможностям и политике доступа, когда гостевой доступ и 802.1X станут обязательными.

Частые ошибки и как их избежать

Самая дорогая ошибка в кампусе - купить максимум, а потом не суметь этим пользоваться. Лицензии и функции раскрываются только вместе с понятной эксплуатацией: кто смотрит алерты, кто меняет политики, кто отвечает за качество голоса и Wi‑Fi.

Ошибки, которые встречаются чаще всего

1. Берут расширенные функции «на вырост», но нет платформы управления и регламентов. Телеметрия есть, отчеты никто не смотрит, инциденты все равно находят по жалобам.

2. Не планируют питание PoE и аплинки. Через год добавляют больше точек Wi‑Fi, камер и телефонов, и коммутатор уже на пределе по бюджету PoE, а аплинк становится узким горлом.

3. Откладывают NAC «на потом», но сеть не готовят. Порты настроены одинаково, нет понятной схемы сегментации, не продуманы гостевые и «карантинные» роли. Когда приходит время включать 802.1X, приходится переделывать доступ по этажам и переписывать шаблоны.

4. Включают QoS, но не согласуют маркировку трафика между телефонией, Wi‑Fi и ядром. Итог типичный: голос «прыгает», хотя приоритет вроде включен.

5. Собирают телеметрию без цели. Данных много, пользы мало: нет базовых метрик, нет порогов и нет ответственных за реакцию.

Как избежать без лишних закупок

Перед выбором уровня лицензий свяжите функции с конкретными задачами и владельцами.

• Зафиксируйте рост на 12-18 месяцев: сколько PoE‑устройств добавится и где понадобится 2.5G/10G.
• Заложите NAC‑готовность: шаблоны портов, роли, отдельные VLAN для гостей и изоляции, пилот на одном корпусе.
• Согласуйте QoS end‑to‑end: кто ставит метки (телефоны, контроллер Wi‑Fi), где доверяете меткам, где перемаркируете.
• Определите 3-5 полезных отчетов по мониторингу (например, топ перегруженных аплинков, порты с ошибками, SLA по голосу) и кто их просматривает.
• Проведите короткий пилот: один коммутатор, один этаж, реальные пользователи. Ошибки там дешевле.

Простой пример: кампус включает QoS для IP‑телефонии, но Wi‑Fi контроллер маркирует голос иначе, чем ожидает проводная сеть. Часто достаточно одной встречи сетевиков и телефонистов и единой таблицы DSCP, чтобы убрать «плавающее качество» без покупки новых лицензий.

Короткий чек-лист и следующие шаги

Перед финальным решением зафиксируйте, что именно должно работать в кампусной сети не «в целом», а каждый день. Самая частая переплата случается, когда покупают «на всякий случай», но не понимают, какие функции реально будут включены в первый год.

Чек-лист перед закупкой

Сведите ответы в одну таблицу на 1 страницу:

• Сценарии трафика: офисные приложения, голос/видео, Wi‑Fi, видеонаблюдение, печать, терминалы.
• Питание и порты: сколько устройств на PoE/PoE+, есть ли запас по мощности.
• Аплинки и производительность: 1/10/25G, сколько магистралей на коммутатор, где возможны узкие места.
• Резервирование: два линка вверх, два коммутатора в стойке, стек и роль каждого узла.
• План роста на 12 месяцев: добавление точек Wi‑Fi, переход на 802.1X, новые сегменты, рост видеоконференций.

По безопасности заложите готовность даже если внедрение будет позже: где будет 802.1X, где нужен MAB для принтеров/телефонов, как будет устроен гостевой доступ (отдельный VLAN/SSID, сроки доступа, базовые правила). Чем раньше это описано, тем меньше переделок в конфигурации.

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

Что прогнать на пилоте и что делать дальше

На пилоте проверяйте не «пинг», а реальные риски:

• Голос/видео под нагрузкой (очереди, приоритеты, задержка).
• Гостевой доступ и базовые политики (кто куда может ходить).
• Отказоустойчивость (обрыв аплинка, перезагрузка узла стека).
• Обновления и откат (время простоя, совместимость, процедура).

Дальше соберите требования, сделайте простую матрицу «нужно сейчас / нужно позже» по QoS, NAC и мониторингу, и только затем сводите это к лицензиям и спецификации.

Если не хватает времени или опыта, системный интегратор вроде GSE.kz (gse.kz) может помочь собрать требования, подготовить спецификацию и внедрить решение так, чтобы не переплачивать за функции, которые не будут использоваться в первый год.