Cisco Catalyst 9500 распределенное ядро кампуса: миграция

Задача миграции и что именно мы меняем

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

При миграции на Cisco Catalyst 9500 в роли распределенного ядра мы меняем старые центральные коммутаторы на новую пару. Вместе с этим часто меняются скорости аплинков, схема резервирования и логика шлюзов.

На практике к замене приходят по нескольким причинам. Старое ядро начинает упираться в производительность (много VLAN, маршрутов и трафика от Wi‑Fi и видео), не поддерживает нужные функции (телеметрия, современные протоколы, безопасный управляемый доступ) или его обслуживание становится рискованным. Отдельная мотивация - надежность: чтобы обрыв одной линии или перезагрузка одного устройства не превращались в простой всего офиса.

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

Ключевые риски, которые нужно держать под контролем:

• L2‑петли из-за неверно включенных линков или проблем со STP на стыках.
• Ошибки маршрутизации: неверные статические маршруты, неправильный IGP, разные метрики.
• Переезд шлюзов VLAN (SVI) без готовых DHCP, ARP и зависимостей безопасности.
• Неверное подключение аплинков к дистрибуции, серверной зоне или провайдерам (не тот порт или режим).
• Несовпадение MTU, speed/duplex или проблемы по оптике, из-за которых появляются потери.

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

Целевая схема: роли, границы L2/L3 и резервирование

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

Главное архитектурное решение - где заканчивается L2 и начинается L3. Если тянуть большие L2‑домены до ядра "как раньше", вы переносите туда же старые проблемы: затяжные перестроения STP, широковещательный шум и сложные зависимые VLAN. Обычно практичнее ограничить L2 уровнем доступа или дистрибуции, а к ядру поднимать L3‑линки. Тогда отказ или петля в одном здании не "роняет" весь кампус.

До миграции зафиксируйте базовые решения: где будут SVI (на дистрибуции или в ядре), как подключается дистрибуция (L3 point‑to‑point по двум независимым линкам), как устроено резервирование (два устройства ядра с разнесением по стойкам и питанию), какой FHRP используется (HSRP или VRRP с едиными таймерами), и какой протокол маршрутизации выбран (часто OSPF, статика - только для небольших схем, BGP - при нескольких доменах и строгой политике).

Пример типовой идеи для двух корпусов и ЦОДа: в каждом корпусе есть дистрибуция, от нее в оба 9500 идут L3‑линки. Пользовательские VLAN остаются локально, а в ядре - маршрутизация и суммарные префиксы. В таком варианте переключение затрагивает меньше зависимостей, и окно изменений проходит спокойнее.

Подготовка: сбор данных и фиксация текущего состояния

Перед миграцией важно не столько "настроить новый Catalyst 9500", сколько точно понять, как сейчас живет сеть. Большинство сбоев после переключения связаны не с моделью коммутатора, а с мелкими зависимостями: неожиданным DHCP relay на одном SVI, нестандартным MTU на аплинке, забытым ACL для принтеров или особенностями Wi‑Fi контроллера.

Начните с инвентаризации логики: VLAN и их назначения, SVI и подсети, default gateway для сегментов, ACL (включая направление), DHCP relay (ip helper-address), MTU, QoS и multicast (PIM/IGMP, если используется). Если есть VRF, отдельные таблицы маршрутизации или статические маршруты к "особым" сетям, выделите это отдельным блоком, чтобы не потерять при переносе.

Дальше соберите зависимости по L3: кто соседи (межсетевой экран, CE провайдера, DC, контроллеры Wi‑Fi, маршрутизаторы филиалов), какие протоколы между вами (OSPF/BGP/EIGRP или статика), какие таймеры и политики. Полезно заранее согласовать, какие сервисы обязаны подтвердить владельцы: интернет-доступ, телефония, учетные системы, Wi‑Fi, доступ к серверам.

До окна изменений проверьте "физику": совпадение оптики и скоростей на обоих концах, корректность LACP (где он есть), а также режимы trunk/access и список разрешенных VLAN.

Минимальный пакет фиксации "как было":

• Бэкап конфигураций всех затрагиваемых устройств и запись текущих версий ПО.
• Снимок состояния: таблицы маршрутизации, соседства (L2 и L3), состояние портов и агрегатов.
• Список критичных интерфейсов и куда они ведут (порт, устройство, контакт владельца).
• План коммуникаций: кто на связи в окно, кто принимает сервисы, кто дает "ок/не ок".
• Критерии успеха до старта: что должно заработать в первые 10-15 минут после переключения.

Если это кампус в госорганизации или университете, заранее договоритесь о приемке: сетевые инженеры проверяют маршрутизацию и соседства, служба ИБ - прохождение трафика через FW, прикладные команды - свои сервисы по короткому чеклисту.

Окно изменений: как запланировать и не потерять контроль

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

Как выбрать время и длительность

Выбирайте период с минимальной бизнес‑нагрузкой и с доступной резервной сменой: дежурный инженер, администратор критичных систем (телефония, Wi‑Fi, учетные системы) и человек, который может открыть доступ в серверную. По длительности лучше закладывать запас, но внутри держать короткие этапы по 10-20 минут с проверками.

Перед окном согласуйте единый канал связи и правило фиксации действий: кто и в какое время выполнял команды или перекоммутацию. Это резко упрощает откат.

Роли и точки контроля

Минимальная матрица ролей на окно:

• Исполнитель изменений: вводит команды, делает перекоммутацию.
• Наблюдатель: следит за мониторингом, логами и обращениями пользователей.
• Ответственный за сервисы: подтверждает работоспособность критичных приложений.
• Лицо, принимающее решение: дает go/no-go для продолжения этапов.

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

Go/no-go точки лучше записать заранее. Например, вы продолжаете, если есть консольный доступ к обоим коммутаторам ядра и видны аплинки, подтверждена достижимость основных шлюзов и критичных серверов, нет признаков L2‑петель и всплеска broadcast/unknown traffic, а команда отката понятна и включает физическую схему возврата.

Преднастройка Catalyst 9500 до выхода в прод

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

Начните с управления: management VRF или отдельный mgmt VLAN (как принято у вас), AAA (если используется), NTP, syslog и SNMP. Сразу проверьте, что логи уходят на нужный сервер, время синхронизируется, а доступ по SSH ограничен понятными списками адресов.

Дальше подготовьте VLAN и SVI. IP‑адреса на SVI обычно переносят как есть, а ACL и политики приводят к читаемому виду: одинаковые имена, единая логика, понятные комментарии. Если правила разрослись, можно убрать явные дубли, но без "творческих" изменений: меняйте только то, что нужно для совместимости.

Для аплинков и ключевых узлов заранее соберите LACP Port‑Channel. Номера, режим LACP и набор VLAN должны совпадать с ожиданиями на стороне дистрибуции или агрегации. Частая безопасная практика: физические порты поднять, а сам Port‑Channel держать выключенным до переключения.

Маршрутизацию и соседства тоже можно приготовить заранее: настроить процессы OSPF/BGP, сети и политики, но держать интерфейсы в shutdown или не анонсировать прод‑префиксы, чтобы новые пути не появились раньше времени.

Перед окном еще раз проверьте совместимость: режим STP (PVST/RPVST/MST) и приоритеты корня, PortFast и BPDU Guard на access, UDLD на оптике (если использовался), одинаковый MTU на L3‑линках, а также совпадение speed/duplex и параметров транков на критичных uplink.

Порядок переключения: пошаговый сценарий миграции

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

Перед стартом сделайте предчек на старом ядре и дистрибуции: аплинки должны быть up/up, без роста CRC/input errors; таблицы MAC и ARP - заполнены ожидаемо; STP - без частых пересчетов; соседства маршрутизации (OSPF/EIGRP/BGP) - в норме. Если уже есть нестабильность, окно изменений быстро превратится в разбор старых проблем.

Дальше удобная последовательность шагов:

1. Подключите новые аплинки к Catalyst 9500 параллельно, но не меняйте шлюзы и маршрутизацию. Убедитесь, что порты поднялись, EtherChannel (если есть) собрался, и нет неожиданных блокировок STP.

2. Переносите аплинки дистрибуции на новое ядро небольшими порциями (по зданию, шкафу или паре коммутаторов). После каждой "мини‑волны" проверяйте доступность ключевых сервисов (AD/DNS, телефония, контроллеры Wi‑Fi), чтобы зона риска была небольшой.

3. Когда L2‑топология стабильна, переносите L3‑роль: переключение активного HSRP/VRRP (приоритеты, preempt) и включение нужных SVI на новом ядре. Если возможно, делайте это по группам VLAN и сразу контролируйте маршрут по умолчанию и суммарные маршруты.

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

5. Зафиксируйте результат: сохраните конфигурации, снимите статусы и счетчики, отметьте точное время ключевых переключений.

Во время стабилизации держите фокус на простых метриках: ошибки интерфейсов и дропы, загрузка CPU/памяти, количество STP changes, состояние routing neighbors и жалобы пользователей из разных сегментов (офис, Wi‑Fi, телефония). Если ухудшение началось после конкретного шага, откатывайтесь к последнему стабильному состоянию, а не пытайтесь чинить "на лету" в середине миграции.

План отката: что считаем аварией и как возвращаемся назад

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

Что считаем аварией (триггеры)

Откат обычно запускают по признакам, которые реально бьют по работе:

• критичные сервисы недоступны (AD/DNS, телефония, доступ к ключевым системам);
• маршрутизация "плавает": соседи падают, префиксы пропадают или постоянно меняются;
• признаки L2‑петли: резкий рост broadcast/unknown unicast, рост CPU на коммутаторах, "шторм" в портах;
• массовые потери пакетов или высокая задержка на основных направлениях;
• потеря управления: нет доступа по сети и нет стабильного out-of-band.

Заранее задайте пороги по времени. Например: если 10 минут не восстанавливается связность между зданиями или не работает телефония, команда переходит к откату, а не пробует "еще одну правку".

Самый простой и быстрый откат

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

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

Откатывайте безопасно: делайте один блок действий, затем короткая проверка связности и состояния протоколов. После восстановления сервиса зафиксируйте таймлайн: что изменили, какой симптом появился, на каком шаге и какие счетчики/логи это подтвердили.

Типовые ловушки и ошибки при миграции ядра

Даже если конфиг на новых коммутаторах выглядит "как на старых", проблемы чаще всего появляются на стыках: где L2 встречается с L3, где собираются агрегации, и где неожиданно срабатывают политики безопасности.

L2: trunk и STP

Самая частая ошибка - неверный список allowed VLAN на trunk. Тогда сегменты "пропадают" только на части площадки. Второй популярный сбой - несогласованный native VLAN: трафик начинает метиться по-разному, появляются странные петли или "плавающие" симптомы.

Отдельно проверьте, кто становится STP root. Если после переключения корнем стал доступ или старый коммутатор, кампус может начать жить на резервных связях и ловить неожиданные блокировки.

L3 и безопасность: забыли одно правило и потеряли управление

На уровне L3 часто теряют статические маршруты (к сетям управления, мониторинга, OOB, сервисным подсетям) или указывают неверный next‑hop. Еще один риск - конфликт адресов SVI: если старый и новый шлюз на короткое время оказываются активными одновременно, ARP начинает "ездить", и пользователи видят обрывы сессий.

С ACL похожая история: правило применили не на тот интерфейс или не в том направлении - и вы сами себе отрезали SSH/SNMP или заблокировали сбор логов. Типичный симптом: "пинги ходят, но мониторинг умер".

Агрегации и организация работ

С порт‑каналами ошибки простые, но неприятные: разные режимы LACP, несовпадающие параметры Port‑Channel, разные скорости. В итоге линк физически подключен, но трафик идет через один порт или не идет вовсе.

Чтобы не зависнуть в споре "у кого сломалось", заранее назначьте go/no-go критерии (что должно заработать за первые 10 минут), одного ответственного за приемку сервисов (связь, телефония, Wi‑Fi, критичные системы) и владельца отката.

Пример из практики: после переключения в одном корпусе пропал Wi‑Fi. Причина оказалась в том, что на транке к WLC не попал нужный VLAN из-за allowed list. Такие вещи находятся за минуты, если проверки и ответственные определены заранее.

Чеклист после переключения: быстрые проверки за 10-15 минут

Сразу после перевода трафика на новое ядро важно быстро понять две вещи: сеть жива и она ведет себя так, как вы ожидали.

1) Проверяем "железо" и базовое состояние

Проверьте версию ПО и аптайм (чтобы исключить неожиданные перезагрузки), температуру и питание, загрузку CPU и память. Если используется логическое резервирование (например, StackWise Virtual), убедитесь, что роли активный/резервный совпадают с планом и нет постоянных переключений.

Затем пройдитесь по аплинкам к дистрибуции: интерфейсы up, без всплеска ошибок и дискарда. Если видите рост input errors/CRC или "прыгающую" скорость, это часто указывает на оптику/патчкорд или неверное согласование.

2) L2/L3 и сервисы

Проверьте, что Spanning Tree выбрал нужный root и нет неожиданных blocked портов на критичных связях. Убедитесь, что таблица MAC учится и обновляется на транках.

Дальше L3: таблица маршрутов содержит ожидаемые префиксы, соседства маршрутизации (если они есть) в FULL/ESTABLISHED, HSRP/VRRP - в правильных ролях. Отдельно посмотрите ARP: массовые incomplete или частые изменения MAC для шлюза могут означать петлю или дублирование IP.

Для финальной проверки выберите 3-5 контрольных сервисов и проверьте доступность с разных сегментов: DNS, AD/LDAP, телефония, контроллер/шлюз Wi‑Fi, ключевое приложение (например, ERP). Завершите просмотром логов на критичные сообщения и убедитесь, что устройства появились в мониторинге и графики интерфейсов обновляются.

Набор команд для проверки: что смотреть и что должно быть нормой

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

Быстрый набор команд

! Порты, ошибки, оптика
show interfaces status
show interfaces counters errors
show interface transceiver detail

! LACP и EtherChannel
show etherchannel summary
show lacp neighbor

! STP
show spanning-tree summary
show spanning-tree vlan <X>

! L3 и таблицы
show ip interface brief
show ip route
show arp
show ip ospf neighbor
! или, если у вас BGP
show ip bgp summary

! Шлюзы первого хопа (выберите свой протокол)
show standby brief
show vrrp brief

! Быстрый траблшутинг
ping <IP> source <SOURCE_IP>
traceroute <IP> source <SOURCE_IP>
show logging | include (UPDOWN|LINEPROTO|SPANTREE|LACP|HSRP|VRRP|OSPF|BGP)

Что считать нормой

По интерфейсам: нужные аплинки up/up, скорость и дуплекс ожидаемые, счетчики errors/CRC/input-output drops не растут. По оптике: адекватные Rx/Tx уровни и отсутствие сообщений о проблемах модуля.

По LACP: EtherChannel в состоянии (P) на рабочих портах, без (I) individual и без (s) suspended. В show lacp neighbor видны соседи на всех членах канала.

По STP: топология стабильна, нет частых topology change, root ожидаемый, критичные порты в forwarding.

По L3: SVI или routed‑порты подняты, маршрут по умолчанию и ключевые сети присутствуют в show ip route, ARP заполнен для активных сегментов. Для OSPF/BGP главное - соседства в FULL/Established и отсутствие постоянных flaps.

Для HSRP/VRRP: роли активный/резервный соответствуют плану и одинаково видны на обоих узлах. Если пинги с указанием source проходят до критичных подсетей, обычно это подтверждает и маршрутизацию, и обратный путь.

Пример сценария для кампуса: как это выглядит по шагам

Исходные данные: два корпуса (А и Б), по три коммутатора доступа в каждом, отдельная серверная с несколькими стойками и старое ядро на двух коммутаторах. Цель - перейти на Catalyst 9500 в роли распределенного ядра без полного простоя, сохранив управляемость и понятный откат.

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

• Этап 1: корпус А (перенос uplink‑ов доступа на новое ядро, проверка пользователей).
• Этап 2: корпус Б (тот же сценарий и сравнение поведения).
• Этап 3: серверная (перенос агрегации серверных коммутаторов и важных L3‑шлюзов).
• Этап 4: уборка (отключение старых связей, выравнивание маршрутизации, финальная проверка).

На каждом этапе важно, чтобы проверку делали не только сетевые инженеры. Бизнесу достаточно короткого списка действий: открыть почту (в браузере и клиенте), зайти в ERP, сделать тестовый звонок (IP‑телефония), отправить пробную печать, переподключиться к Wi‑Fi и пройти авторизацию.

Первые 24 часа после переключения полезно держать под наблюдением несколько метрик: рост ошибок на портах, flaps на линках, загрузку CPU/памяти на ядре, время восстановления связности после перетыкания линка.

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

Что сделать после миграции: закрепляем результат и планируем дальше

После переключения важно не только убедиться, что "все работает", но и зафиксировать новое состояние. Через неделю детали забудутся, а временные решения станут постоянными.

Зафиксируйте итоговую схему и факты

Соберите as‑built пакет. Хороший минимум:

• обновленная логическая схема (ядро, дистрибуция, границы L2/L3, резервирование);
• таблица портов: что подключено к каждому аплинку, какие порты в Port‑Channel, какие скорости и трансиверы;
• список VLAN и SVI, актуальные IP‑подсети и шлюзы, где включены DHCP relay и какие ACL применяются;
• итоговые версии конфигураций и бэкапы, подписанные датой и номером окна изменений;
• базовые показатели "нормы": задержка, потери, загрузка линков, CPU/память, количество маршрутов и соседств.

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

Сделайте проверки стандартом

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

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

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

Если миграция сложная или впереди следующие этапы, имеет смысл подключать системного интегратора для планирования и ночного сопровождения работ. Например, GSE.kz как производитель и интегратор ИТ‑инфраструктуры в Казахстане может закрыть проект под ключ: от архитектуры и поставки оборудования до внедрения и поддержки.