Чеклист перед апгрейдом Cisco IOS-XE и NX-OS: совместимость

Зачем нужен предапгрейд-чеклист и что он закрывает

Апгрейд Cisco IOS-XE или NX-OS часто выглядит просто: загрузил образ, перезагрузил, проверил. На практике сбои чаще происходят не из-за прошивки, а из-за мелочей вокруг обновления, которые не проверили заранее.

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

Предапгрейд-чеклист закрывает три задачи: предсказуемость, скорость восстановления и понятные критерии успеха. Он помогает заранее сверить железо и ресурсы (память, место под образы, состояние модулей), версию и ограничения релиза, реальную конфигурацию и используемые функции, лицензии и зависимости (VRF, EVPN, FEX, ISSU, шифрование, TACACS/RADIUS и т.д.), а также подготовить откат.

На выходе должны остаться конкретные артефакты:

• список устройств и их роль в сервисе (что критично, что можно трогать первым)
• план работ с окном и ответственными
• бэкапы конфигураций и «снимки до» для сравнения
• план отката и признаки, когда его запускать

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

Инвентаризация: что надо знать про каждое устройство

Перед тем как открывать окно работ, соберите инвентарь. Это база для апгрейда IOS-XE и NX-OS: без точных данных легко ошибиться с образом, лицензией или даже порядком перезагрузок.

Сделайте для каждого устройства короткую карточку - только то, что влияет на обновление и риск простоя:

• модель, серийный номер, роль (ядро, доступ, пограничный), площадка и критичность сервиса
• текущая версия ПО, версия ROMMON/BIOS (если применимо), uptime и дата последней перезагрузки
• режим работы: standalone, stack/StackWise, vPC/VSS, FEX, dual-sup, ISSU (если используете)
• где лежат образы и сколько свободного места в bootflash/sup-bootflash
• кто ответственный и как вы зайдете на устройство, если сеть частично упадет (OOB, консоль, терминальный сервер)

Дальше снимите конфигурацию и зафиксируйте то, что сложно восстановить по памяти: список интерфейсов и их назначение, VRF, маршрутизацию (OSPF/BGP/EIGRP), QoS, ACL, NAT, DHCP, NTP, SNMP, TACACS/RADIUS.

Отдельно отметьте нестандартное: EEM-апплеты, кастомные скрипты, автопровижининг, интеграции с мониторингом, требования compliance. Такие детали часто ломаются первыми после обновления.

Пример: если у вас пара Nexus в vPC, запишите критичные VLAN и port-channel, кто primary, где включен peer-gateway. Это помогает не перепутать порядок действий и быстро понять, что поведение после перезагрузки изменилось.

Матрица совместимости по версии: что искать в документации

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

Минимальные требования и «обвязка» релиза

Начните не с новых функций, а с базовых требований к платформе. В релиз-нотах и матрицах обычно указаны:

• минимальные версии bootrom/ROMMON, а для NX-OS еще и EPLD
• рекомендуемые версии (не только «поддерживается», но и «рекомендуется»)
• ограничения по памяти, месту под образы и типам накопителей
• особенности для конкретных моделей и модулей (линейные карты, супервизоры)

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

Что меняется в поведении и как обновляться

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

Чтобы решение принималось быстро, сделайте короткий список стоп-факторов по каждой платформе:

• нужен ROMMON/EPLD апгрейд, а окна на него нет
• используются депрецированные команды
• целевой релиз не поддерживает ваш модуль/трансивер/функцию
• запрещен «прыжок» через версии, требуется промежуточный шаг
• есть известный критичный баг под ваш сценарий (EVPN, HSRP, QoS и т.д.)

Лицензии: как не потерять функции после обновления

Обновление IOS-XE или NX-OS меняет не только баги и функции, но и то, как устройство подтверждает права на них. Поэтому перед апгрейдом проверьте лицензии так же строго, как и сам образ. Иначе можно получить «внезапный даунгрейд» возможностей уже после перезагрузки.

Сначала зафиксируйте текущее состояние: какие пакеты и функции активны и что реально используется в конфигурации. Для IOS-XE обычно смотрят Smart Licensing и уровни (Network Essentials/Advantage), для NX-OS - установленные функции и их статус. Отметьте именно критичное: AAA и шифрование, маршрутизация, сегментация, VXLAN/EVPN, телеметрия.

Короткая проверка перед окном работ:

• Снимите выводы команд по лицензиям и сохраните вместе с бэкапом конфигурации.
• Проверьте привязку к серийному номеру, Smart Account/Virtual Account и срок действия подписок.
• Убедитесь, что в целевом релизе не меняется модель лицензирования для вашей платформы.
• Проверьте, есть ли grace period и что будет отключено при его окончании.

Пример: после апгрейда коммутатор поднялся, но VXLAN не стартует, потому что устройство не смогло связаться с лицензирующим сервисом. План действий лучше согласовать заранее: кто подтверждает покупку или перенос, кто дает доступ к аккаунту и какая временная мера допустима (перенос окна, откат, временная лицензия, перевод сервиса на резервный путь).

Железо и ресурсы: модули, память, место под образы

Перед обновлением полезно проверить не только версию ПО, но и «железо»: какие модули стоят, сколько свободного места в flash/bootflash, хватает ли памяти, нет ли скрытых проблем с питанием и охлаждением. После перезагрузки такие вещи проявляются первыми.

Начните с инвентаризации модулей и их совместимости с целевым релизом. Для IOS-XE это особенно важно на шасси с разными линейными картами и супервизорами, для NX-OS - на коммутаторах с отдельными модулями. Если модуль не поддерживается, устройство может загрузиться без части портов или функций.

Проверьте ресурсы и запас по устойчивости:

• свободное место в flash/bootflash под новый образ и резервную копию старого
• достаточно ли RAM для выбранного образа (не «впритык»)
• нагрузку CPU и общую стабильность до окна работ
• состояние PSU и вентиляторов
• актуальность boot-переменных и порядок загрузки

Команды зависят от платформы, но обычно достаточно собрать такой минимум:

show inventory
show version
dir flash:
show platform resources
show environment

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

Совместимость функций: сверяем реальную конфигурацию с целевым релизом

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

Собираем список используемых функций

Лучше выписать функции не из головы, а из вывода команд и конфигов. Для NX-OS обычно помогает список включенных feature, для IOS-XE - поиск по running-config (маршрутизация, безопасность, QoS, мониторинг). Заодно зафиксируйте режим работы: L2/L3, VRF, протоколы, Stack/vPC, active/standby.

Обычно достаточно такого набора:

• show running-config (и отдельно блоки интерфейсов, routing, security)
• show feature или эквивалент
• show ip route, show bgp/ospf neighbor
• show vpc, show switch/stack, show redundancy
• show policy-map interface, show access-lists

Сверяем с целевым релизом и ловим «тихие» изменения

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

Отдельно пройдитесь по сценариям, которые чаще всего ломаются на несовместимостях:

• HA: SSO/NSF, Stateful switchover, ISSU (если планируете)
• vPC/Stack и FHRP (HSRP/VRRP) на стыках
• BGP/OSPF и политики (route-map, prefix-list)
• QoS (классы, очереди, trust boundary)
• ACL, NetFlow/telemetry

Пример: пара коммутаторов в vPC обслуживает шлюз HSRP и имеет QoS на uplink. После обновления может измениться порядок применения QoS или дефолтные таймеры протокола. Вы увидите не «падение», а рост задержек и перекос трафика на одном из линков. Такие вещи лучше заранее отметить как must-test в окне.

Снимки «до»: бэкапы, контрольные точки и доступ на случай аварии

Перед апгрейдом сделайте «снимок состояния», чтобы потом быстро понять, что изменилось, и при необходимости вернуться назад. Проблема часто не в образе, а в том, что нет бэкапа, нет консоли и нечем сравнить «до/после».

Сохраните конфигурацию и зафиксируйте, какие образы и файлы лежат во flash/bootflash.

show running-config
show startup-config
dir flash:
dir bootflash:
show version

Дальше снимите короткие контрольные выводы для сравнения после апгрейда. Не собирайте сотни страниц: достаточно того, что подтверждает живость сети и сервисов.

• соседства: CDP/LLDP, протоколы маршрутизации
• таблицы маршрутов и ARP/ND
• состояние портов и Port-Channel
• питание, модули, ошибки интерфейсов

Перед загрузкой нового образа проверьте контрольные суммы (MD5/SHA) и место под второй образ, если хотите держать запасной файл рядом.

И последнее - доступ на случай потери сети. Убедитесь, что есть рабочая консоль (локальная или через консольный сервер) и Out-of-Band (mgmt VRF, отдельный порт), а учетные данные проверены заранее.

Пилот и тест: как проверить обновление без большого риска

Пилот нужен, чтобы чеклист проверился на реальности, а не на предположениях. Сначала обновляете небольшой кусок сети, который похож на прод, но не уронит бизнес, если что-то пойдет не так.

Начните с критериев успешности. Фразы «устройство поднялось» недостаточно. Заранее зафиксируйте, что должно совпасть до и после:

• соседства и маршрутизация: BGP/OSPF/EIGRP в состоянии up, таблицы не «пустые»
• коммутация: VLAN, trunk, STP без неожиданных пересчетов и блокировок
• доступ: AAA/TACACS/RADIUS, SSH, SNMP, NTP, syslog работают как раньше
• производительность и ошибки: CPU/память в норме, нет роста drops, CRC, flaps
• критичные функции: VXLAN, vPC, HSRP, QoS, NetFlow (или то, что важно именно вам)

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

Обязательно измерьте тайминги: копирование образа, проверка хэшей, установка, перезагрузка, подъем протоколов и синхронизация (если это стек/кластер). Эти цифры потом становятся реальной оценкой окна.

И важно: откат выполните руками хотя бы один раз. Если откат в пилоте не получается быстро и предсказуемо, в проде он подведет.

План отката: что именно откатываем и по каким признакам

Откат продумывают до апгрейда, потому что при сбое времени на спокойные решения уже нет. Сразу определите, что вы считаете «возвратом»: загрузка с предыдущего образа, откат пакетов в install mode (add/remove/activate/commit), переход в rescue или просто переключение переменных boot на старый файл.

Хороший план отката - короткая пошаговая инструкция с командами, ожидаемым результатом и точками решения. Например: «если устройство загрузилось, но не поднимает критичные протоколы, делаем X; если не помогло за N минут, выполняем Y и возвращаемся на старый образ». Заранее проговорите, кто принимает решение об откате и как вы подтверждаете восстановление сервиса.

Триггеры отката

Заранее зафиксируйте симптомы, которые вы считаете критичными, и сколько вы готовы ждать:

• устройство не загружается в рабочий режим или уходит в ROMMON/loader
• не поднимаются management-доступы (SSH/console через OOB) дольше оговоренного времени
• не проходит контрольный набор проверок (маршрутизация, HSRP/VRRP, BGP/OSPF, vPC/Port-Channel, L2/L3 шлюзы)
• повторяющиеся crash, высокая CPU или ошибки модулей после загрузки
• потеря лицензированной функции, без которой сервис не работает

Перед окном работ проверьте, что старый образ реально доступен на устройстве (flash/bootflash), целый (checksum) и прописан как запасной. Отдельно оцените совместимость конфигурации при возврате: новые команды после апгрейда могут мешать старой версии. Практичный подход - хранить бэкап конфига «до» и иметь готовый шаг «вернуть конфиг из бэкапа» сразу после загрузки старого релиза.

Пример: на паре NX-OS с vPC заранее решите, что при потере vPC peer-link более чем на 10 минут вы откатываете сначала вторичный коммутатор, проверяете восстановление vPC и только потом решаете, что делать с первичным.

Пошаговый план работ: от окна обслуживания до подтверждения сервиса

Окно работ лучше описать как сценарий с временем и точками контроля, а не как «обновим и посмотрим». Так проще удержать темп, вовремя остановиться и не растянуть простой.

Таймлайн окна работ

Заранее оцените длительность каждого шага и добавьте буфер:

• T-30 мин: финальное подтверждение окна, доступов и консоли, проверка наличия образов и хэшей
• T0: старт, заморозка изменений, фиксация показателей (CPU, память, uptime, ошибки портов)
• T+X: апгрейд по выбранной процедуре, контроль загрузки и возврата в сеть
• T+Y: проверки сервиса по согласованному списку (маршрутизация, VLAN/VRF, доступ к критичным системам)
• T+Z: буфер на исправления или решение об откате

Роли, коммуникации и форс-мажор

Роли должны быть закреплены за людьми, а не за отделами. Один человек не должен одновременно менять и принимать работу.

• исполнитель: делает изменения и ведет лог действий по времени
• контроль сервиса: проверяет приложения/телефонию/доступы и дает «ОК»
• коммуникации: отправляет статусы бизнесу по шаблону (старт, промежуточно, завершили/откатились)
• дежурный вендор/интегратор: на связи для эскалации (например, NOC)
• ответственный за решение «откат/продолжаем»: принимает решение по заранее заданным признакам

Для форс-мажора заранее решите: кто поднимает мост, где запасной доступ (OOB/консоль), есть ли запасное устройство/модуль и где «точка невозврата», после которой окно переносится.

Частые ошибки: что чаще всего ломает апгрейд

Самая частая причина провала - обновление «на удачу». Образ залили, окно короткое, «вроде так делали». А потом выясняется, что часть функций пропала из-за лицензии, а единственный доступ - по SSH, который не поднимается после перезагрузки. Минимум, который должен быть заранее: проверенные лицензии и рабочий консольный доступ (или альтернативный out-of-band).

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

Третья группа ошибок связана с HA, стэком и vPC. Даже если один коммутатор обновился успешно, пара может «развалиться» из-за несовпадения образов, разных ревизий модулей или ограничений mixed-mode. В таких схемах важно заранее сверить, что обе стороны поддерживают выбранный релиз и одинаковый способ установки.

И еще одно: «скопировать образ» не равно «переключиться на него». Для IOS-XE и NX-OS критичны порядок команд, подтверждение активации и перезагрузка.

Быстрый контрольный список: перед стартом и сразу после апгрейда

Когда окно уже открыто, времени на поиски «где лежит образ» нет. Ниже - пункты, которые реально проверить за 10 минут.

Перед стартом:

• нужный образ и правильная checksum (сверена на файле, который лежит на устройстве или на сервере копирования)
• свежий бэкап running-config и ключевые show (версии, модули, лицензии, соседства)
• подтвержденный доступ OOB или консоль, плюс рабочие учетные данные (не только TACACS, но и локальный план на случай отказа AAA)
• свободное место в storage/bootflash и понятный путь boot (что именно грузим после перезагрузки)
• план отката: какой образ ставим обратно, где он лежит и кто дает команду «откатываемся»

Сразу после обновления не пытайтесь «проверить все». Сначала подтвердите базовую работоспособность и отказоустойчивость:

• порты и агрегаты: up/down, ошибки, скорость/дуплекс, состояние port-channel
• маршрутизация и соседства: OSPF/BGP/ISIS, HSRP/VRRP, таблица маршрутов и ARP/ND
• HA: состояние stack/vPC/VSS/SSO, роли, синхронизация, отсутствие split-brain
• сервис: несколько простых тестов (ping между VLAN, доступ к шлюзу, проверка ключевого приложения)
• логи: критические сообщения, crashinfo/core, события лицензирования

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

Пример из практики: простое окно обновления без сюрпризов

Типичный офис: два коммутатора ядра работают парой (vPC и шлюз по HSRP), а на границе стоит маршрутизатор с BGP в сторону провайдера и отдельными ACL для входящего трафика. Цель окна - поднять версии IOS-XE/NX-OS, не потеряв связность и контроль.

За неделю до окна команда собрала реальную картину из конфигурации и вывода show-команд и сверила ее с целевым релизом. Критичные проверки были простые, но точные: состояние vPC (роль, peer-link, consistency), активный HSRP, число BGP-соседей и маршрутов, счетчики дропов по ACL, а также то, что мониторинг видит основные метрики (интерфейсы, CPU, логи).

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

В конце оформили короткий отчет:

• что обновили: модели, старые и новые версии, контрольные суммы образов
• что проверили: vPC/HSRP, BGP, ACL, мониторинг, доступ по OOB/консоли
• что изменилось: предупреждения в логах, отличия конфигурации, статус лицензий
• итог: время простоя (если было), отклонения от плана, решение об откате (не понадобился)

Следующие шаги: закрепляем результат и готовимся к следующему релизу

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

Соберите пакет так, чтобы его мог открыть любой дежурный через полгода и быстро понять контекст:

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

Дальше обновите внутренние инструкции и шаблоны. Если всплыл особый модуль, нестандартная лицензия или зависимость функции, добавьте это в шаблон предапгрейд-проверок.

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