Действующий парк Cisco нельзя переводить на новую модель лицензирования «одним нажатием»: сначала нужно понять, какие устройства и версии ПО уже работают, какие функции реально используются и насколько контур изолирован. После 2022 года базовой моделью стал Smart Licensing Using Policy (SLP), но для закрытых сетей у Cisco остаются два разных сценария — автономный Permanent License Reservation (PLR) и локальный SSM On-Prem, ранее известный как Satellite. Ошибка в выборе приводит либо к ручной работе с каждым узлом, либо к проблемам при использовании функций, для которых требуется отдельная авторизация.
Начните с инвентаризации, а не с активации
Лицензирование нужно проверять не по названию модели, а по связке «устройство — версия ПО — набор функций — режим эксплуатации». Один и тот же парк может содержать оборудование с разными версиями IOS-XE, различными требованиями к лицензиям и неодинаковым сроком дальнейшей эксплуатации.
Соберите по каждому узлу минимальную карточку:
- модель и серийный номер устройства;
- версию IOS-XE;
- используемые уровни Network Essentials или Network Advantage;
- наличие функций, относящихся к Enforced Licenses;
- возможность или запрет исходящего трафика к сервисам Cisco;
- критичность узла и допустимое окно обслуживания;
- планируемую замену, модернизацию или вывод из эксплуатации.
Отдельно фиксируйте, где находится оборудование: в обычной корпоративной сети, в сегменте без прямого доступа в интернет, на удаленной площадке или в полностью изолированном контуре. Для удаленного объекта отсутствие постоянного доступа не всегда означает полную изоляцию: иногда разрешен контролируемый обмен через рабочее место администратора. Это меняет выбор между PLR и SSM On-Prem.
Не смешивайте лицензионную проверку с инвентаризацией оптики, портов и кабельной инфраструктуры. Однако результаты должны сходиться в одной карточке актива. При проектировании сетевой инфраструктуры полезно заранее разделять оборудование, программные функции и внешние компоненты — похожая логика применяется и в материалах о проектировании AV over IP-сети.
Что изменил Smart Licensing Using Policy
В архитектуре SLP стандартный функционал в большинстве случаев доступен без постоянного «дозвона» устройства в облако. Поддержка SLP появилась в ветках IOS-XE 17.3.2 и 17.4.1, поэтому версия ПО должна быть первой точкой проверки при работе с действующим парком.
Практический вывод прост: потеря связи с облаком сама по себе не означает немедленную остановку базовых сетевых функций. Это снижает риск для закрытых площадок, но не отменяет обязанности разобраться с отдельными лицензируемыми возможностями и учетной записью организации.
Особое внимание требуется Enforced Licenses. Примером является HSECK9 — функция, связанная с расширенными возможностями криптографии. Для нее нужен специальный код SLAC. Нельзя исходить из предположения, что переход на SLP автоматически разрешает все функции, доступные в выбранном образе ПО. Перед включением такой возможности проверьте:
- поддерживает ли ее конкретная модель и версия IOS-XE;
- относится ли функция к Enforced Licenses;
- получен ли необходимый SLAC;
- есть ли документированный процесс установки кода в вашем закрытом контуре;
- как будет подтверждаться право использования после замены устройства.
CSLU может применяться как промежуточная утилита для сбора сведений, но в полностью изолированной сети она не решает задачу сама по себе. Если данные нельзя передать из контура разрешенным способом, локальный сбор не заменяет процедуру авторизации.
PLR для единичных критичных узлов
Permanent License Reservation подходит для устройства, которое должно работать автономно и не нуждается в регулярном централизованном обмене. Лицензия резервируется за конкретным оборудованием, поэтому PLR логичен для небольшого числа критичных маршрутизаторов или коммутаторов в изолированном сегменте.
Процесс состоит из нескольких этапов:
- в Smart Account открывается возможность использования PLR; это не универсальная кнопка, доступность зависит от одобрения Cisco;
- устройство формирует Reservation Request Code;
- администратор переносит код на защищенный портал вне изолированного контура;
- портал возвращает Authorization Code;
- код переносится обратно и вводится в CLI устройства;
- результат и исходные сведения сохраняются в документации по узлу.
Главное преимущество PLR — автономность после завершения процедуры. Устройство не должно постоянно обращаться в интернет для работы зарезервированной лицензии. Это удобно там, где политика безопасности запрещает любой сетевой обмен наружу.
Ограничение связано с привязкой к оборудованию. При замене устройства лицензию нельзя безусловно «перетащить» на новый узел как обычный файл. Потребуется процедура возврата, связанная с Return Code, а затем повторная резервация. Поэтому до вывода старого устройства из эксплуатации сохраните его идентификаторы, лицензионное состояние и порядок возврата. Попытка сначала списать или уничтожить актив, а потом восстановить лицензию часто превращается в отдельный административный процесс.
Когда PLR становится плохим выбором
PLR неудобен, если парк постоянно растет, устройства регулярно меняются по гарантии или оборудование распределено по множеству площадок. В таком случае ручной обмен кодами на каждом узле увеличивает вероятность ошибки: можно перепутать серийный номер, применить код не к тому устройству или потерять подтверждение операции.
Еще одна ошибка — резервировать через PLR весь парк только потому, что прямой доступ в интернет запрещен. Сначала проверьте, разрешен ли контролируемый обмен через выделенный административный контур. Если да, централизованное управление может оказаться менее трудоемким.
SSM On-Prem для большого закрытого парка
SSM On-Prem — виртуальная машина в формате OVA, которая размещается в корпоративном ЦОДе или у сервисного партнера и выполняет роль локального аналога облачного центра управления. Такой вариант рассчитан на парк, где оборудование добавляется, заменяется и выводится из эксплуатации регулярно.
Его ценность не в том, что он полностью устраняет лицензионные процедуры, а в централизации операций. Вместо работы с каждым устройством через отдельный перенос кодов организация получает единую локальную точку учета. Это облегчает контроль состава парка, сопоставление устройств и лицензий, а также передачу сведений между изолированным контуром и внешней средой по утвержденной процедуре.
SSM On-Prem требует отдельного планирования. Нужно определить:
- где будет размещена виртуальная машина;
- какие администраторы получат доступ;
- как будут выполняться резервное копирование и восстановление;
- кто отвечает за обновление платформы;
- как данные будут синхронизироваться с внешними системами, если прямой связи нет;
- как оформляется замена самого сервера управления.
Обновление SSM On-Prem выполняется вручную и не является незаметной фоновой операцией. В доступных сведениях указано, что обновления выпускаются раз в год и устанавливаются вручную, в том числе с использованием съемного носителя. Поэтому виртуальная машина должна войти в регламент эксплуатации, а не оставаться «один раз настроенным» сервисом.
Выбирайте SSM On-Prem, если число устройств велико, парк неоднороден, а операции замены и добавления выполняются постоянно. Для одного-двух стабильных узлов он может создать больше инфраструктурных обязанностей, чем решить проблем.
Сравнение сценариев для действующего парка
| Критерий | PLR | SSM On-Prem |
|---|---|---|
| Размер парка | Небольшое число критичных узлов | Средний и большой парк |
| Связь с интернетом | Не требуется после резервирования | Работа через локальный центр, внешняя синхронизация зависит от политики безопасности |
| Администрирование | Ручной обмен запросом и кодом для устройства | Централизованный учет и операции через локальную платформу |
| Замена оборудования | Требуется процедура возврата и повторной привязки | Удобнее при регулярной ротации, но сам SSM On-Prem тоже нужно обслуживать |
| Инфраструктурные расходы | Минимум дополнительных компонентов | Нужна виртуальная машина, регламент обновлений и ответственный администратор |
| Основной риск | Ошибки при ручной работе и потеря данных по возврату | Заброшенная платформа, устаревшая версия или отсутствие процедуры синхронизации |
Таблица не заменяет проверку конкретной модели и версии IOS-XE. Она помогает выбрать рабочий сценарий управления, но не подтверждает наличие конкретной функции или право на ее использование.
Как перевести парк без остановки сети
Безопасный переход выполняется поэтапно, начиная с малокритичного узла. Такой пилот позволяет обнаружить несовместимость версии, отсутствие разрешения на PLR или неверно выбранную процедуру до массовых изменений.
- Разделите парк. Выделите устройства на SLP-совместимых версиях, узлы со старыми версиями, полностью изолированные активы и оборудование, которое планируется заменить.
- Определите функции. Отдельно отметьте базовые уровни Network Essentials и Network Advantage, а также Enforced Licenses вроде HSECK9.
- Зафиксируйте исходное состояние. Сохраните серийные номера, версии, текущий режим лицензирования и резервные копии конфигураций.
- Выберите пилот. Не начинайте с единственного пограничного маршрутизатора или узла, через который проходит критичный трафик.
- Проверьте Smart Account. Убедитесь, что организация видит нужные активы и может запросить PLR, если выбран этот сценарий.
- Настройте процедуру переноса кодов. Для изоляции заранее назначьте рабочее место, носитель и двух сотрудников для проверки соответствия устройства и кода.
- Проверьте аварийную замену. Для PLR заранее опишите, кто выполняет возврат лицензии и где хранится Return Code.
- Только после пилота масштабируйте. Для большого парка перенесите операции в SSM On-Prem и включите обновление платформы в календарь обслуживания.
Не совмещайте переход лицензирования с обновлением IOS-XE, заменой оптических модулей и перестройкой маршрутизации без необходимости. Чем больше изменений попадает в одно окно, тем сложнее определить источник сбоя. Если одновременно обновляется транспортная часть сети, отдельно проверьте совместимость программной и аппаратной составляющих: например, сведения о новых оптических стандартах Cisco и NVIDIA относятся к трансиверам и не заменяют проверку программных лицензий.
Типичные ошибки и контрольный список
Самая частая ошибка — считать отсутствие интернет-доступа достаточным основанием для PLR. Решение должно учитывать размер парка и частоту замен. Вторая — считать SLP полной отменой лицензирования. Базовый функционал и Enforced Licenses имеют разные условия. Третья — не документировать операции, выполненные вручную.
Перед переводом в эксплуатацию проверьте:
- у каждого устройства есть владелец и карточка актива;
- версия IOS-XE сопоставлена с выбранным сценарием;
- функции, требующие SLAC, выделены отдельно;
- для PLR сохранены Reservation Request Code, Authorization Code и сведения о возврате;
- для SSM On-Prem назначены ответственные за обновление, резервное копирование и восстановление;
- описан порядок работы при замене устройства по гарантии;
- пилот проверен на тестовом или малокритичном узле;
- изменения лицензирования не смешаны без необходимости с другими сетевыми работами.
Практический план решения
Для небольшого стабильного парка в полностью изолированном контуре выбирайте PLR, но заранее оформите порядок возврата лицензии при замене оборудования. Для корпоративной сети с сотнями, частыми заменами и несколькими площадками рациональнее рассматривать SSM On-Prem как локальный центр управления. Если парк смешанный, не обязательно навязывать ему один режим: критичные автономные узлы можно оставить на PLR, а управляемую часть перевести в SSM On-Prem.
Рабочий порядок такой: провести инвентаризацию, сопоставить версии и функции, определить границы изоляции, выполнить пилот, документировать коды и только затем масштабировать выбранную модель. Такой подход сохраняет работоспособность действующего оборудования и уменьшает риск, что лицензирование станет причиной аварии при следующем обновлении или замене.