Обновление Cisco Catalyst без простоя: ISSU, стек и откат

Что значит "без простоя" на практике

"Без простоя" не всегда означает "без единого разрыва". Чаще это значит, что для пользователей нет заметной остановки сервисов, а обновление проходит так, чтобы влияние уложилось в заранее согласованные рамки.

При обновлении Cisco Catalyst обычно допускают короткие события, которые формально являются разрывом, но в реальности почти не ощущаются: переподнятие отдельных портов на секунды, короткая пауза в пересогласовании LACP, обновление таблиц маршрутизации, переизбрание STP root, единичные потерянные пакеты при переключении.

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

• не более 1 краткого переподключения клиента в Wi-Fi или по проводу
• не более X секунд деградации для критичных приложений
• ноль ручных действий на рабочих местах
• проверка ключевых сервисов после работ

Даже при ISSU возможны "микро-паузы". Они заметнее на сервисах без буфера и с постоянным потоком: IP-телефония и колл-центры, терминалы оплаты и кассы, видеонаблюдение, VDI, VPN-сессии.

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

Подходит ли ваш Catalyst для ISSU и обновления без разрыва

Бесшовное обновление возможно только там, где есть реальная отказоустойчивость. На уровне доступа это часто означает, что краткий разрыв на одном устройстве некритичен (пользователи остаются на Wi‑Fi или уходят на резервный uplink). В распределении и ядре без пары устройств или без шасси с резервным supervisor почти всегда получится только "минимальный простой", но не ноль.

Сначала зафиксируйте роль устройства: доступ, распределение или ядро. Чем ближе к ядру, тем выше цена даже секунды потери маршрутизации и тем строже требования к резервированию (два устройства, два питания, два uplink, разные трассы).

Дальше проверьте, есть ли у платформы и конфигурации механизмы для бесшовного перехода: SSO (stateful switchover) и NSF (non-stop forwarding). Если они не поддерживаются или не включены, ISSU легко превращается в обычную перезагрузку с заметным разрывом.

Практичный минимум, который стоит подтвердить до планирования окна:

• точная модель и режим: одиночный коммутатор, стек, шасси, StackWise Virtual
• есть ли резервирование (пара на LACP/ECMP, HSRP/VRRP, два uplink на разные устройства)
• поддерживает ли ваша ветка IOS XE ISSU именно в вашей схеме (функции, лицензии, тип стека)
• зафиксированы ли текущая и целевая версии, и есть ли прямой путь апгрейда
• что будет "единицей отказа": один коммутатор, весь стек или supervisor

Чтобы не гадать, снимите факты командами и сохраните вывод в файл (это пригодится и для отката):

show version
show redundancy
show platform
show switch (для стека)

Пример: если у вас один Catalyst в небольшом офисе и все рабочие места завязаны на него, ISSU не спасет - любое обновление будет риском. А если это пара коммутаторов распределения с FHRP и дублированными uplink, тогда ISSU и SSO/NSF дают шанс пережить обновление без потери сессий, но только при совпадении модели, версии и набора поддерживаемых функций.

Подготовка образов, совместимости и места на устройстве

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

Сверьте целевую версию IOS XE с моделью коммутатора, типом Supervisor (если он есть), объемом памяти и текущими лицензиями. Некоторые функции (например, шифрование, Network Advantage, DNA) могут требовать конкретного набора лицензий или ограничивать переход на отдельные релизы.

Отдельно проверьте требования к ROMMON. Для некоторых линеек и веток IOS XE обновление ROMMON обязательно и иногда требует перезагрузки. Если производитель рекомендует промежуточный релиз (сначала перейти на X, затем на Y), лучше заложить это в план, чем выяснить в окне.

Перед загрузкой образа определитесь, в каком режиме работает устройство:

• Install mode (packages.conf и набор пакетов) обычно предпочтительнее для ISSU и предсказуемых апгрейдов.
• Bundle mode (загрузка напрямую с .bin) проще, но часто ограничивает возможности бесшовного обновления.

Убедитесь, что на flash достаточно места не только под новый образ, но и под резервную копию. Минимум: место под старый .bin (или packages), текущий packages.conf и запас под временные файлы установки.

После копирования образа проверьте контрольную сумму. Пример типовых команд:

show version
show boot
dir bootflash:
verify /md5 bootflash:<image>.bin

Если на устройстве уже мало свободного места, не удаляйте файлы наугад. Сначала зафиксируйте, с чего именно загружается коммутатор сейчас, и какие файлы точно понадобятся для отката. На Catalyst в install mode удаление не того пакета может привести к тому, что устройство не поднимется в нужный релиз даже после успешной установки.

Контрольные проверки до окна работ (pre-checks)

Главный риск обычно не в самой команде upgrade, а в том, что устройство уже было "на грани". Перед окном важно снять слепок состояния, чтобы потом быстро понять: это последствия обновления или проблема была раньше.

Зафиксируйте текущую версию и роль устройства в сети (ядро, доступ, агрегация). Сохраните бэкап конфигурации и вывод ключевых команд в отдельный файл. Полезно иметь "снимок" для сравнения после окна: список аплинков, порт-каналов, соседей и активных шлюзов.

Железо и здоровье устройства

Проверьте питание и охлаждение: наличие обоих БП (если есть), состояние вентиляторов, температуру, журналы по питанию. Ошибки на портах тоже стоит увидеть заранее: рост CRC/input errors на аплинке легко превращает "без простоя" в короткие обрывы при перезапуске протоколов.

Оцените нагрузку: CPU и память, свободное место во flash, наличие crashinfo. Если crashinfo уже есть, лучше понять причину до обновления, а не разбирать два события сразу.

Резервирование и критичные таблицы

Убедитесь, что резервирование реально работает, а не просто "настроено". Проверьте, что аплинки не в единственном экземпляре, EtherChannel собран и без ошибок, а HSRP/VRRP в ожидаемых ролях (active/standby) и без флапов.

Перед стартом зафиксируйте таблицы, которые чаще всего помогают при разборе: ARP, MAC, маршруты (или дефолтный маршрут), состояние STP (root/port roles). Если после обновления пользователи жалуются на доступ к одному сегменту, сравнение MAC/ARP/STP до и после быстро покажет, не "переехал" ли трафик на другой аплинк или не сменился root bridge.

К концу pre-checks у вас должен быть понятный набор фактов: устройство стабильно, резервирование живое, и есть с чем сравнивать результат после окна.

Короткий чеклист перед стартом окна

Перед началом окна проверьте, что вы сможете управлять устройством даже в аварийном сценарии. Это занимает 3-5 минут, но часто спасает от затяжного восстановления.

Проверьте доступ к управлению: есть ли консоль (на месте или через консоль-сервер) и резервный путь. Хороший минимум - отдельный OOB-канал или второй независимый маршрут до management-интерфейса. Убедитесь, что у вас есть нужные учетные данные и права, а время на устройстве синхронизировано.

Заранее подтвердите, где лежит образ и как вы быстро перекинете его при форс-мажоре. Если загрузка по сети внезапно упадет, должен быть запасной вариант (например, альтернативный сервер или локальная копия на инженерном ноутбуке).

Также заранее проговорите точки принятия решения: кто говорит "go/no-go" и по каким сигналам. Обычно хватает 2-3 триггеров остановки: потеря управления, не поднимается соседство, критичные ошибки в логах после перезагрузки.

• Доступ: консоль + резервный канал управления (OOB/второй путь), проверены логины и права.
• Образ: подтверждены расположение и контрольная сумма, понятен план быстрой доставки (основной и запасной).
• Решения: назначен ответственный за "go/no-go", зафиксированы критерии остановки и отката.
• Наблюдение: согласовано усиленное наблюдение после работ (обычно 15-30 минут) и что именно смотрим.
• Контакты: на связи владелец приложений, дежурный инженер и провайдер/оператор (если задействован).

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

Пошаговый план: одиночный Catalyst с IOS XE и ISSU

На одиночном коммутаторе ключевое условие простое: платформа и текущая конфигурация должны поддерживать ISSU, а устройство должно быть в install mode (IOS XE работает из набора пакетов, а не из одного монолитного образа).

Шаги обновления (install mode и ISSU)

Начните с подготовки пакетов и образа. Если устройство не в install mode, переведите его в этот режим в отдельное окно, потому что это может потребовать перезагрузки.

Дальше действуйте последовательно:

• Скопируйте новый образ на устройство и проверьте контрольную сумму (если она у вас есть от вендора).
• Выполните install add и дождитесь завершения, затем сделайте verify, чтобы убедиться, что пакеты корректно добавлены.
• Запустите переход на новый набор через install activate (или команду ISSU, если она предусмотрена для вашей платформы и версии).
• Во время активации контролируйте, что SSO остается в рабочем состоянии, а NSF не отключается неожиданно.
• После успешной работы на новой версии выполните install commit, чтобы зафиксировать обновление.

Что контролировать во время перехода

Во время активации смотрите системные логи и состояние протоколов. В небольшой сети кратковременный пересчет STP или повторная инициализация соседства может выглядеть как микропотери, но не должен превращаться в длинный обрыв.

Критерии успеха лучше подтвердить сразу: порты в expected state, нет повторяющихся ошибок в логах, контрольные VLAN и uplink работают, CPU и память не ушли в постоянную высокую загрузку, а ключевые проверки (пинг до шлюза, доступ к критичным сервисам) проходят без ухудшений.

Пошаговый план: обновление стека Catalyst

Стек обычно обновляют rolling upgrade: часть участников перезагружается, а сеть продолжает работать за счет active/standby. На практике это и воспринимается как "без простоя", если у вас есть резервирование по uplink и стек в здоровом состоянии.

Сначала зафиксируйте текущее состояние стека: кто active, кто standby, какие номера у участников и какие приоритеты. Если роли неожиданно поменяются, можно получить перерыв, даже если сама прошивка встала нормально.

Перед стартом обновления

Проверьте то, что чаще всего спасает окно:

• все участники видны в стеке, нет "полумертвых" членов
• здоровье StackWise и кабели (ошибки, флаппинг, слабые коннекторы)
• режим загрузки и версии IOS XE на всех членах совпадают
• образ прошивки доступен для всех участников и хватает места
• конфигурация сохранена, роли и приоритеты записаны

После этого еще раз согласуйте ожидания: при rolling upgrade отдельные порты могут кратко мигнуть, а некоторые access-устройства переподнимутся, если у них нет резервирования.

Обновление (типовой порядок)

1. Выровняйте ПО: один и тот же образ и один режим установки на всех members.
2. Запустите установку/активацию обновления на стеке и следите, чтобы перезагрузка шла по участникам, а не одновременно.
3. Контролируйте, что standby готов взять роль active (SSO), прежде чем начнется перезапуск следующего члена.
4. Дождитесь полного возврата всех участников в стек и только потом фиксируйте результат.

Пример: в стеке из 4 коммутаторов критичны uplink на 1 и 2 участнике. Тогда сначала убедитесь, что standby на 2 участнике действительно в состоянии ready, и только потом допускайте перезагрузку 1 участника.

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

План отката: когда и как возвращаться назад

Откат нужен не потому, что вы ждете провал, а потому что хотите быстро вернуть сервис, если что-то пошло не так. Ключевой момент - "точка невозврата": commit. Пока обновление не зафиксировано, вернуться на предыдущую версию обычно проще и быстрее.

Где проходит граница "еще можно быстро назад"

При ISSU (или процессе через install) устройство может держать "старый" и "новый" набор пакетов. До commit вы фактически тестируете новую версию в бою. После commit система начинает считать новую версию основной, а откат часто превращается в полноценную перезагрузку и ручную загрузку предыдущего образа.

Заранее подготовьте "план Б": предыдущий образ должен быть доступен на флеше, а загрузочная конфигурация - понятна.

Варианты возврата и чем они отличаются

• Rollback (возврат install/ISSU): самый быстрый вариант, если вы еще не сделали commit и откат поддерживается вашим методом установки.
• Install remove (очистка неактивных пакетов): это не откат. Команда помогает убрать мусор и освободить место, но не вернет старую версию.
• Ручная загрузка: когда нужно явно указать, с чего грузиться (например, прежний packages.conf или образ), и перезагрузить устройство. Это самый "тяжелый" способ, но он спасает, если автоматический rollback недоступен.

Решение об откате лучше привязать к симптомам, а не к ощущениям:

• петли STP, массовые topology change, рост CPU на control plane
• падение соседств (например, HSRP/OSPF/BGP), flapping портов в аплинках
• резкий рост ошибок на интерфейсах, падение PoE на критичных портах
• жалобы пользователей, подтвержденные метриками (задержки, обрывы, деградация приложений)
• ситуация не стабилизируется простыми действиями (откат конфигурации, отключение проблемного фича-флага)

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

• время начала отката и причина (1-2 предложения)
• команда/метод отката, что именно сделали
• состояние соседств и ключевых сервисов до и после
• кто уведомлен (NOC, владелец сервиса, безопасность)
• итог: вернулись назад или продолжили обновление

Пример: если после перехода на новую версию пошли массовые STP-изменения и начали "сыпаться" аплинки на нескольких коммутаторах стека, остановитесь до commit, зафиксируйте симптомы, выполните rollback и возвращайтесь к разбору уже вне окна.

Контрольные проверки после окна (post-checks)

После обновления важно не просто увидеть, что коммутатор загрузился, а подтвердить, что сеть ведет себя так же (или лучше), чем до окна. Если вы старались сделать переход максимально бесшовным, часть проблем может проявиться только через 10-30 минут под нагрузкой.

Начните с быстрых фактов: версия ПО совпадает с планом, устройство(а) в ожидаемом режиме загрузки, uptime соответствует моменту работ, а в логах нет повторяющихся предупреждений. Если обновляли стек, проверьте, что все члены на месте, роли (active/standby) ожидаемые, и нет признаков рассинхронизации.

Дальше пройдитесь по основным точкам риска:

• Интерфейсы: критичные порты up, скорость/duplex верные, счетчики ошибок и дропов не растут.
• PoE: точки доступа/телефоны получают питание, нет постоянных power-deny.
• L2/L3: STP стабилен, LACP порт-каналы собраны, маршрутизация (OSPF/BGP, если используется) в состоянии full/established.
• Пользовательский взгляд: вход в корпоративные системы, телефония, Wi‑Fi, доступ к файловым ресурсам и ключевым приложениям работает из нескольких сегментов.
• Системное здоровье: CPU/память без аномалий, температуры в норме, нет новых alarm/critical в системных сообщениях.

Если нужно быстро собрать подтверждения, удобно выполнить типовой набор команд (названия могут отличаться по модели/версии):

show version
show logging | last 50
show interfaces status
show interfaces counters errors
show power inline
show spanning-tree summary
show etherchannel summary
show ip ospf neighbor
show ip bgp summary

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

Частые ошибки и ловушки при обновлении Catalyst

Чаще всего окно срывается из-за обновления "по памяти", без проверки ограничений платформы. С бесшовными сценариями это особенно заметно: кажется, что ISSU все сделает само, но детали легко ломают план.

Совместимость: ROMMON и режим загрузки

ISSU и даже обычная перезагрузка могут пойти не так, если не проверить ROMMON и режим загрузки (install или bundle). Типичный сценарий: вы загрузили новый IOS XE, но после reload устройство уходит в ROMMON из-за старого boot-параметра или несовместимого ROMMON, а удаленного доступа уже нет.

Перед окном проверьте базовые вещи:

• версия ROMMON подходит под целевой релиз и модель
• режим загрузки соответствует плану (install/bundle)
• на flash хватает места с запасом под пакеты и логи
• файл образа именно для вашей платформы и лицензии

"Резервирование" на словах

ISSU не спасает, если в реальности нет отказоустойчивости. Один аплинк, один блок питания, один путь до точки управления - и вы уже зависите от одного кабеля или одного коммутатора выше по цепочке. Частый случай: при переключении активного супервизора меняется MAC/роль порта, аплинк моргает на секунды, а дальше выясняется, что второй аплинк не настроен или отключен.

Стек: разный приоритет и "мертвый" standby

Стек выглядит как "одно устройство", но на деле это несколько коммутаторов. Разный приоритет, разные версии, неготовность standby (или его нет) приводят к неожиданному выбору master и лишним перезагрузкам. Еще хуже, когда один участник стека не виден до окна, а это замечают только в момент апгрейда.

Commit слишком рано и отсутствие доступа на случай ЧП

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

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

Пример сценария: обновление в организации без остановки работы

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

За день до окна команда делает "сухой прогон" и оставляет на ночь то, что можно безопасно выполнить в фоне: сверку моделей и версий, проверку питания и резервных линий, контроль места во flash и контрольных сумм, сбор базовой картины по CPU/ошибкам портов/статусам HSRP/VRRP или стека, а также план коммуникаций. Ночью копируют образы на устройства и сохраняют конфигурации, чтобы в окно не тратить время на передачу файлов.

Само окно на 60-90 минут проходит по ролям: один инженер ведет консоль и выполняет команды, второй следит за мониторингом и критичными сервисами (телефония, ERP, доступ к серверной), третий на связи с дежурными на площадке. Ключевой контроль - не "встало ли ПО", а "жив ли трафик": пинги до шлюзов, доступ к тестовым сервисам, отсутствие роста ошибок и дропов на uplink.

Решение об откате принимают по фактам. Например, если после перезагрузки члена стека не поднимается SSO, растет число ошибок на магистральных портах, или критичный VLAN теряет связность дольше согласованного порога (например, 3-5 минут), запускают возврат на предыдущий образ по заранее согласованным шагам.

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

Следующие шаги: закрепляем процесс и снижаем риск

Бесшовное обновление - это не разовая удача, а повторяемый процесс. Помогает "стандарт обновлений": единые версии, понятные роли устройств и одинаковые проверки каждый раз.

Хорошая практика - выбрать "золотую" версию IOS XE для вашей модели Catalyst и обновляться к ней по расписанию (например, раз в квартал или раз в полгода), а не "когда прижмет". Так меньше шанс догонять несколько релизов подряд и ловить несовместимости.

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

Нужна и наблюдаемость. Если вы не видите симптомы заранее, даже удачное окно может обернуться жалобами на "подвисания" позже. Достаточно базового мониторинга: события системы и стека (перезагрузки, split-brain, смена мастера), ошибки портов (CRC, input/output errors, flaps), качество каналов (потери, задержка, джиттер на ключевых маршрутах), питание и среда (PSU, PoE бюджет, температура).

Отдельно проверьте, не уперлись ли вы в железо: одно питание вместо двух, перегруженный PoE, нет резервирования uplink, порты работают на пределе, а стек держится на одном кабеле. Часто именно это ломает бесшовность, а не сама прошивка.

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