Миграция с Cisco Catalyst на Aruba CX: перенос VLAN, PoE и QoS

Что нужно перенести и почему это важно

Переход с Cisco Catalyst на Aruba CX обычно делают не ради «смены коробки». Цель проще и практичнее: обновить коммутаторы, снизить нагрузку на поддержку, закрыть требования по поставкам и получить предсказуемую сеть на годы вперед. Успех миграции зависит от того, насколько точно вы перенесете то, что пользователи не замечают, пока оно работает.

Важно сохранить не только физические подключения, но и логику сети. В первую очередь проверяют:

• VLAN и сегментацию (кто с кем может общаться)
• транки: native VLAN и список разрешенных VLAN
• PoE: общий бюджет питания, приоритеты портов и поведение при перегрузке
• QoS: маркировку трафика и приоритет для голоса, видеосвязи и критичных сервисов
• служебные настройки: доступ к управлению, NTP, SNMP/мониторинг, журналы

Понять, что миграция прошла успешно, проще по бизнес-признакам: телефония не хрипит, видеозвонки не «сыпятся», принтеры печатают, 1С/CRM открывается как обычно, точки Wi-Fi не отваливаются, а пользователи не создают волну заявок. Хорошая проверка - сравнить ключевые сервисы до и после переключения, а не только «пинги».

Чаще всего простой случается из-за мелочей, которые легко упустить:

• перепутали native VLAN на транке, и часть устройств «уехала» не в тот сегмент
• не учли PoE-бюджет, и точки доступа или телефоны начали перезагружаться
• перенесли VLAN, но забыли про ACL/политики, и сервисы стали недоступны
• не проверили QoS, и голос/видео попали в общую очередь
• не подготовили план отката, и восстановление затянулось

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

Инвентаризация перед миграцией: что собрать за 1 день

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

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

Что собрать (минимальный набор)

• Оборудование и ПО: модели коммутаторов, версии прошивок, модули, лицензии, типы трансиверов и где они стоят.
• Карта портов: какие порты аплинки, где транки, где access, какие LAG/Port-Channel собраны и какие интерфейсы в них входят.
• VLAN-таблица: ID и названия, где используются (кабинеты, этажи, сервисы), и какая native VLAN задана на каждом транке.
• PoE-сводка: какие устройства питаются (телефоны, точки Wi-Fi, камеры), их примерное потребление, и какие точки критичны (ресепшн, кассы, охрана).
• QoS и зависимости: что приоритизируется (голос, видео, VDI/терминалы, медицинские системы), а также внешние сервисы: DHCP, DNS, AAA/RADIUS, NTP, телефония, Wi-Fi-контроллер, видеонаблюдение.

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

Пример: на аплинке включен Port-Channel, а в документации он записан как обычный trunk. Если это не заметить заранее, после замены коммутатора часть VLAN может не пройти, и первыми «упадут» голос или Wi-Fi.

Итог дня должен быть понятным: один файл со списком устройств, одна таблица VLAN, одна схема портов и отдельная заметка с PoE и QoS приоритетами. Этого достаточно, чтобы дальше переносить настройки осознанно, а не «по памяти».

Перевод понятий Cisco на Aruba CX без лишней теории

При миграции проще думать не в командах, а в намерениях: что делает порт, куда ведет аплинк, какие VLAN должны пройти, какие сервисы критичны. Тогда разница между Cisco Catalyst и Aruba CX превращается в «перевод терминов», а не в изучение нового мира.

Роли в сети обычно сохраняются: access (подключение пользователей и телефонов), distribution (агрегация этажей или зон), core (магистраль), edge (выход к провайдерам, межсетевые экраны). На Aruba CX вы строите те же уровни, но чаще опираетесь на более явные профили портов и шаблоны.

Полезные соответствия:

• Port-Channel (Cisco) = LAG (Aruba CX). Логика та же: объединяем порты, следим за LACP и одинаковыми настройками на всех участниках.
• Trunk (Cisco) = tagged VLAN на порту Aruba CX. Access VLAN = untagged VLAN.
• Native VLAN (Cisco) = untagged VLAN на транковом порту Aruba CX. Здесь чаще всего появляются «тихие» ошибки.
• CDP (Cisco) чаще заменяют на LLDP. Если в сети были телефоны или точки доступа, проверьте, что LLDP включен и нужные поля передаются.
• STP/RSTP/MST есть и там, и там. Важно не название, а совпадение режима и приоритетов корневого моста.

По VLAN и транкам главный нюанс в том, что на Aruba CX вы явно разделяете tagged и untagged. При переносе лучше отдельно выписать: какие VLAN должны быть tagged на аплинках, какая VLAN должна быть untagged (если она вообще нужна), и нет ли старых «служебных» VLAN, которые на Cisco были разрешены по привычке.

С ACL и политиками смотрите на точку применения: на порту доступа, на SVI (интерфейсе VLAN) или на аплинке. Проверьте:

• где именно фильтр работал (вход/выход) и на каком интерфейсе
• порядок правил (первое совпадение решает)
• исключения для DHCP, DNS и телефонии
• логирование (если было), чтобы оно не перегрузило устройство

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

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

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

Подготовка

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

Дальше настройте базу управления: отдельный management-доступ (или mgmt VLAN), учетные записи и роли, NTP, syslog, SNMP. Добавьте и «бытовые» вещи: баннер, резервное копирование конфигурации, понятные имена интерфейсов. Это экономит время, когда после переключения нужно быстро разбираться в симптомах.

Практичный порядок работ:

• Загрузите базовую конфигурацию управления и доступа.
• Поднимите L2: VLAN, транки, native VLAN, LAG и проверьте связность между коммутаторами.
• Переключайте аплинки по одному, фиксируя, какой кабель куда переставлен.
• Включайте PoE по очереди: сначала критичные устройства (телефоны, точки Wi-Fi, камеры), затем остальное.
• Перенесите QoS и проверьте голос и видео не только «прозвоном», а в реальной нагрузке.

Переключение и откат

Окно работ обычно планируют на нерабочее время. При этом проверку качества (особенно телефонии) полезно повторить в пиковые часы, когда очереди и буферы ведут себя иначе.

План отката должен быть готов до начала работ и укладываться в 5-10 минут. Минимальный чеклист:

• Сохраненные конфиги старых и новых устройств (с датой и версией).
• Список портов и кабелей: что куда подключено и что уже переключено.
• Порог остановки: какие симптомы считаются критичными (нет связи между VLAN, пропали телефоны, не хватает PoE-бюджета).
• Быстрый возврат: вернуть аплинк на Cisco, отключить проблемный LAG или временно убрать QoS-политику.

Перенос VLAN: транки, native VLAN и типовые нюансы

Чаще всего ломается не «VLAN как номер», а то, как он едет по транку: какие VLAN разрешены, какой VLAN считается native (нетегированный), и где случайно смешали tagged и untagged. Начните с таблицы соответствия: VLAN ID, имя, где используется (порты доступа, транки, SVI на L3) и какие сервисы внутри (DHCP, телефония, Wi-Fi, принтеры).

Транки и native VLAN: где обычно ошибаются

В Cisco вы привыкли к trunk + allowed VLAN + native VLAN. В Aruba CX логика та же, но термины другие: VLAN на транке может быть tagged, а один VLAN может быть untagged (это и есть аналог native VLAN). Главное правило: untagged VLAN должен совпадать на обоих концах линка, иначе часть устройств «пропадает» без явной ошибки.

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

Управляющий VLAN и L3 настройки

Если у вас есть VLAN для управления коммутаторами, отметьте его отдельно и ограничьте доступ: не тащите его на каждый edge-порт и не делайте его untagged «по умолчанию». Так меньше шанс, что управление окажется доступным из не того сегмента.

Если маршрутизация VLAN делается на L3-устройстве, не забудьте про DHCP relay (helper). После переноса SVI на Aruba CX клиенты могут видеть линк, но не получать IP.

Короткий набор проверок после переключения (на каждый ключевой VLAN):

• Клиент получает ожидаемые IP, шлюз и DNS.
• Пингуется шлюз VLAN и один внутренний сервис (например, контроллер домена или CRM).
• Проверяется один типичный пользовательский сценарий (звонок с IP-телефона, печать, вход в Wi-Fi).
• На транках сверяется список разрешенных VLAN и совпадение untagged/native.

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

PoE при миграции: бюджет питания и приоритеты

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

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

Дальше разберите потребление по ролям. IP-телефоны обычно берут немного и должны включаться всегда. Точки доступа могут брать заметно больше (особенно с Wi-Fi 6/6E и USB). Камеры часто потребляют средне, а панели и терминалы дают пики при запуске. Если часть устройств требует PoE+ или выше, убедитесь, что порт и коммутатор это поддерживают.

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

Короткий чек перед переключением:

• Сверьте общий PoE-бюджет Aruba CX и фактическую нагрузку по портам.
• Проверьте режимы на портах: auto, enable, disable, и лимит мощности на порт.
• Назначьте приоритеты PoE для телефонов, магистральных точек доступа и критичных камер.
• Уточните, какие устройства требуют PoE+ и какие могут работать в обычном режиме.
• Проверьте запас по ИБП, если коммутаторы и питание завязаны на него.

План включения делайте поэтапно. Например: сначала поднимите коммутатор и только телефоны, затем Wi-Fi, затем камеры и остальные устройства. Так вы не поймаете одновременный стартовый пик, который иногда «роняет» питание даже при формально достаточном бюджете.

Пример: 24 телефона, 6 точек доступа и 8 камер на одном коммутаторе. Если включить все сразу, точки доступа могут запросить максимум и «съесть» запас. При поэтапном включении и правильно выставленных приоритетах критичные сервисы поднимутся первыми, а оставшиеся порты можно довести до нормы лимитами.

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

Перенос QoS: маркировка, очереди и проверка качества

QoS переносят не ради красивых политик, а ради предсказуемого качества для конкретных сервисов: голос, видеосвязь, VDI, камеры, терминалы в клинике, критичные приложения. До копирования настроек договоритесь с владельцами сервисов, что должно выигрывать в очереди, а что может подождать.

Чаще всего ломается не сама «приоритизация», а ожидания: где ставится маркировка, кому вы доверяете, какие очереди реально перегружаются. Сначала зафиксируйте текущую модель: какие DSCP и CoS используются и на каких портах они появляются.

Что собрать и как сопоставить

Короткая инвентаризация QoS помогает переносить настройки управляемо:

• Какие классы трафика критичны (например, SIP/RTP, Teams/Zoom, VDI, медоборудование).
• Где назначается маркировка: на телефоне, точке доступа, ПК, на access-порту или на uplink.
• Какие значения используются: DSCP (например, EF/AF) и CoS на транках, и где происходит перезапись.
• Какие интерфейсы были узкими местами: uplink, межкоммутаторные линки, выход в ядро.
• Были ли ограничения скорости или шейпинг на uplink и для каких классов.

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

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

Проверка качества после переноса

Тесты лучше подготовить заранее и повторить до и после переключения:

• Один голосовой звонок: без «робота» и заметной задержки.
• Звонок параллельно с загрузкой канала (копирование файла): голос не должен проседать.
• Видеоконференция в пиковые часы.
• Проверка VDI или критичного приложения на отклик.
• Сверка счетчиков очередей и дропов на uplink, чтобы увидеть, где именно начинается проблема.

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

Контрольный список сервисов: быстрые проверки до и после

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

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

• Сохраните конфиги Cisco и снимите вывод ключевых команд: VLAN, транки, PoE, QoS, таблицы MAC, STP, LACP.
• Отметьте критичные порты и что в них включено (аплинки, точки Wi-Fi, телефоны, камеры, серверы).
• Подготовьте план отката: что именно и в каком порядке возвращаете обратно, кто отвечает, сколько времени есть.
• Проверьте доступ администраторов: учетные данные, доступ по SSH/консоли, отдельный доступ в management VLAN.
• Зафиксируйте «эталон»: шлюзы, DNS, основные приложения и контрольные пинги из нескольких точек.

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

• Проверьте доступность шлюзов и основных подсетей, убедитесь, что нет широковещательных штормов и странной загрузки линков.
• Убедитесь, что DHCP раздает адреса, DNS отвечает, время по NTP корректное, доменная аутентификация (AD/LDAP) работает.
• Быстро пройдитесь по пользовательским сценариям: интернет, корпоративные приложения, файлы и печать.
• Отдельно проверьте коммуникации: IP-телефонию, Wi-Fi роуминг, видеоконференции и видеонаблюдение.
• Посмотрите мониторинг и резервное копирование: приходят ли метрики/трапы, не пропали ли бэкапы сетевых устройств.

Пример: после замены доступа «все пингуется», но телефоны не регистрируются. Такой симптом часто указывает на VLAN/транк (не тот native VLAN) или на приоритеты PoE и перегрузку бюджета питания. Держите под рукой 2-3 контрольных устройства (телефон, ноутбук, камера) и проверяйте их по одному и тому же сценарию в каждом шкафу.

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

Самые болезненные сбои обычно не из-за «сложной настройки», а из-за мелких несоответствий, которые проявляются только после переключения.

Одна из типичных ситуаций: VLAN перенесли, но на транках оставили «разрешено все». В итоге в соседние сегменты утекает лишний трафик, появляются неожиданные DHCP-ответы или широковещательные всплески. Правило простое: на каждом транке фиксируйте список разрешенных VLAN и держите его минимальным.

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

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

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

С QoS проблема обычно в доверии маркировке. Политики включили, а DSCP не доверили на входе, или голосовой трафик не попадает в нужную очередь. Итог - жалобы на качество звонков именно после миграции.

Как снизить риск

• Зафиксируйте список разрешенных VLAN на каждом транке и проверьте соответствие схеме.
• Явно задайте native VLAN и проверьте untagged-трафик тестовым хостом.
• Определите STP-root и выставьте приоритеты до переключения.
• Посчитайте PoE-бюджет с запасом и расставьте приоритеты питания для критичных портов.
• Проверьте QoS на реальном трафике: звонок, видеопоток, копирование файла.

Отдельная ошибка - отсутствие плана отката. Держите сохраненные конфиги «до/после», список портов для быстрого возврата и понятный критерий «откатываемся, если...». Это снижает простой даже при неожиданной проблеме.

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

Офис на 150 сотрудников: IP-телефоны на рабочих местах, Wi-Fi для сотрудников и гостей, камеры в коридорах, несколько принтеров и пара небольших серверов. В сети около 10-15 VLAN: пользователи, телефония, видеонаблюдение, Wi-Fi staff, Wi-Fi guest, управление и несколько служебных сегментов.

Подготовку можно уложить в один рабочий день, если не пытаться собрать все идеально. Делают простую таблицу: порт, что подключено, какая VLAN, нужен ли PoE, и есть ли особые настройки (например, voice VLAN или приоритет для телефонов). Параллельно выбирают окно работ (обычно поздний вечер) и заранее предупреждают людей: что может кратко пропасть и что делать, если утром что-то не работает.

Миграцию проводят по частям, чтобы не гасить весь этаж сразу. В первый вечер меняют только пару коммутаторов доступа в одном крыле или на одном этаже. Новые Aruba CX поднимают с теми же VLAN, транками и PoE, но uplink на распределении пока оставляют на Cisco. После этого переводят uplink для этого участка на Aruba и смотрят, как ведут себя телефоны, точки доступа и камеры. Если что-то идет не так, откат простой: вернуть uplink обратно.

После переключения проверяют не только «интернет есть», а конкретные рабочие сценарии:

• Звонок с IP-телефона (внутренний и внешний) и проверка, что голос не «роботит».
• Видеовстреча 5-10 минут без зависаний.
• Нагрузочный тест Wi-Fi: несколько устройств, скачивание файла, быстрый роуминг по офису.
• Просмотр потока с камер и запись.
• Доступ к ключевым сервисам (почта, 1-2 корпоративных приложения, печать).

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

Следующие шаги: пилот, план работ и кому доверить внедрение

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

Зафиксируйте критерии приемки и измеримые проверки. Удобно согласовать их с владельцами сервисов (офисная сеть, телефония, Wi-Fi, видеонаблюдение, серверные VLAN) и превратить в короткий список:

• клиенты получают адрес (DHCP), ходят в интернет и в нужные подсети
• телефоны поднимают линию и не теряют регистрацию при нагрузке
• точки Wi-Fi получают PoE, видны в контроллере и раздают сеть
• критичные приложения проходят с нужным качеством (задержка, потери)
• мониторинг видит устройства и порты, логи собираются

Дальше сделайте пилот на одном сегменте, а не сразу на всем периметре. Выберите участок, где представлены типовые роли портов (пользовательские, точки доступа, телефоны, аплинки), но где возможный сбой не остановит компанию. Например, один этаж офиса или одно крыло поликлиники. После пилота внесите правки в шаблоны и только потом масштабируйте.

Перед окном переключения подготовьте единый комплект: таблицу портов (что куда включено), шаблоны конфигураций, план отката и точки контроля (что проверяем через 15 минут, 1 час, 4 часа). В первые 24-48 часов после миграции особенно важны дежурная поддержка и мониторинг: проблемы чаще всплывают не сразу, а в рабочий пик.

Если нужен перенос под ключ, выбирайте команду с опытом именно в переносе VLAN, PoE и QoS между вендорами. Например, GSE.kz (gse.kz) как системный интегратор может помочь с планированием, внедрением и последующей поддержкой, включая сопровождение 24/7 на время окна и после него.