Отказоустойчивый доступ Cisco и Aruba: stacking, VSF, MLAG

Зачем офису и филиалам отказоустойчивый доступ

Сеть доступа - это то, что пользователи чувствуют первым. Пропадают звонки, зависают видеовстречи, не печатает принтер, касса не видит сервер, у сотрудников начинается вечное «то работает, то нет». И часто проблема не в интернете и не в ядре, а в самых простых вещах на этажах и в филиалах.

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

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

Если резервировать только ядро или канал в интернет, а доступ оставить одинарным, массовые инциденты все равно будут. В филиале это особенно больно: пока кто-то доедет и перезапустит железо, проходит полдня.

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

Stacking, VSF и MLAG: коротко о разнице

На практике отказоустойчивый доступ чаще всего строят тремя способами: stacking (Cisco Catalyst), VSF (Aruba CX) и MLAG (у разных вендоров может называться MLAG, VSX и т.п.). Цель одна: выход из строя одного устройства не должен «ронять» пользователей и аплинки целиком.

Stacking и VSF проще всего понимать как «несколько коммутаторов ведут себя как один». Общий конфиг, единая таблица VLAN, единая точка управления. Для администратора это выглядит как один большой коммутатор с большим числом портов.

MLAG - другой подход: это два отдельных коммутатора, которые для подключенных устройств умеют выглядеть как единая точка. Управление чаще раздельное (два конфига), но вверх (или к серверам/точкам доступа) можно дать два линка и собрать один LACP-агрегат в разные «коробки».

Что будет при отказе

В стеке/VSF при отказе одного участника его порты пропадают, но остальные продолжают работать. Если падает мастер, обычно происходит переключение роли и возможна короткая пауза. Поэтому критичные аплинки лучше раскидывать по разным участникам.

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

Как это влияет на аплинки и порты

На аплинках разница ощущается сильнее, чем на пользовательских портах.

• В stacking/VSF аплинк собирают в один LACP-канал как с «одним коммутатором», а физические порты просто распределяют по участникам.
• В MLAG LACP можно разнести по двум устройствам без стека, но нужно аккуратно настроить пару, синхронизацию и служебные связи.

Для рабочего места обычно все равно: один ПК подключен одним кабелем. А вот для точек доступа, мини-коммутаторов и серверов второй линк часто реально полезен.

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

Выбор схемы: офис, этажи и филиалы без лишней сложности

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

Типовые схемы, которые редко подводят

Чаще всего хорошо работают три варианта:

• Небольшой офис: пара коммутаторов доступа в стеке (или VSF) и два аплинка в распределение.
• Средний офис по этажам: на каждом этаже свой стек/VSF, а аплинки поднимаются в пару распределительных коммутаторов.
• Филиал: компактный стек/VSF или два коммутатора с MLAG, если важна независимость устройств и обслуживание без общей точки управления.

Граница L2 и L3 решает половину проблем. Если в филиале нет сложной маршрутизации, держите L2 на доступе, а L3 поднимайте на распределении или на маршрутизаторе филиала. Тогда аварии в L2 не расползаются по всей сети, и проще искать, где именно случилась петля.

Два аплинка вверх: куда их заводить

Если сверху один распределительный коммутатор, оба аплинка обычно собирают в один LACP-порт-канал. Если сверху пара распределительных, лучший вариант - порт-канал в MLAG/VSX-пару. Если такой пары нет, чаще надежнее два независимых аплинка с аккуратно настроенным STP.

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

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

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

Пошагово: как собрать stacking на Cisco Catalyst

Stacking на Cisco Catalyst удобен, когда нужен один логический коммутатор из двух-трех устройств. Для типового офиса это дает понятное управление, общий конфиг и быстрый ввод в работу.

Перед началом

Проверьте, что модели действительно поддерживают стек именно в вашей ревизии, и что есть нужные модули/кабели StackWise (часто это отдельные позиции). Заранее решите, кто будет master (active), кто standby, и зафиксируйте порядок членов стека. Это влияет на нумерацию портов и на то, как потом искать «тот самый» порт в шкафу.

Далее продумайте единый план управления: один management IP на весь стек, понятное имя устройства (например, ACCESS-FLOOR3) и документ с привязкой «член стека 1 - верхний коммутатор в стойке».

Сборка и базовая настройка

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

Дальше настройте базовые вещи: VLAN должны совпадать с верхним уровнем, access-порты должны соответствовать рабочим местам и телефонам, trunk вверх должен иметь корректный список VLAN. Аплинки лучше собрать в LACP (port-channel), чтобы один линк не был единственной точкой отказа. Отдельно проверьте, что STP ожидаемо видит стек как одно устройство.

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

Пошагово: как собрать VSF на Aruba CX

VSF (Virtual Switching Framework) превращает два коммутатора Aruba CX в один логический узел. Для пользователей это выглядит как один коммутатор, а для администратора упрощает управление и дает отказоустойчивость на уровне доступа.

1) Подготовка

Проверьте базовые вещи: модели должны поддерживать VSF, а версии ArubaOS-CX должны совпадать. Выберите роли (командир и участник) и задайте приоритеты, чтобы после перезагрузки лидер выбирался предсказуемо. Практичный вариант - один коммутатор как предпочтительный лидер, второй как запасной.

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

2) Кабельная схема и первичная проверка

Соберите VSF-линки по схеме, которую рекомендует вендор для вашей модели: обычно это два линка, чтобы не было одной точки отказа. До ввода в работу проверьте физику: кабели, защелки, что линк поднимается на нужной скорости.

Затем настройте VSF и убедитесь, что узел видит обоих участников, а статус линков healthy/ok. Только после этого переносите пользовательские подключения.

3) Управление, порты пользователей, аплинки и LACP

Задайте единый management IP для всего VSF, настройте доступ (SSH/AAA по вашей политике) и примените одинаковые профили на порты: VLAN, voice VLAN (если нужно), PoE, port-security.

Аплинки к распределению или ядру проще и надежнее делать как LACP-агрегацию (обычно по одному физическому линку с каждого члена VSF). После сборки проверьте LACP, корректность VLAN на транке и то, что STP не блокирует неожиданный путь. Быстрый индикатор здоровья - стабильная таблица MAC без «скачков».

4) Тест отказа

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

MLAG в доступе: когда он лучше стека

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

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

Схема выглядит как пара коммутаторов (A и B), между ними нужны две связи. Первая - межузловой линк (peer-link, иногда его называют ISL) для служебных данных и части трафика. Вторая - keepalive (часто по отдельной сети или через management), чтобы узлы не приняли ситуацию за отказ соседа, если peer-link перегружен или оборван.

Важно не путаться в терминах. На Aruba CX MLAG обычно реализован как VSX: два устройства, синхронизация состояния, общий LACP для агрегированных портов. На Cisco в кампусных сетях похожую роль часто выполняет StackWise Virtual с Multi-Chassis EtherChannel.

Через MLAG чаще всего подключают то, что не должно падать при отказе одного коммутатора: аплинки вверх (LACP на два устройства), серверы и системы хранения с двумя сетевыми картами, контроллеры Wi‑Fi и важные точки доступа.

Аплинки и агрегирование: как подключать вверх без сюрпризов

Самые частые «внезапные» простои в доступе случаются не из-за стека или MLAG, а из-за аплинков: один порт поднялся, второй нет; VLAN забыли; часть пользователей уходит в «черную дыру». Это почти всегда лечится дисциплиной в LACP, trunk и шлюзе.

Если у вас stacking на Cisco Catalyst или VSF на Aruba CX, аплинки обычно проще всего собирать в LACP-канал вверх, как в один логический коммутатор. Два физических линка дают и пропускную способность, и защиту от обрыва. Важно, чтобы оба конца собирали канал одинаково: LACP с одной стороны и «ручной» on с другой часто заканчиваются странными эффектами.

С MLAG (VSX/MC-LAG) добавляется выбор: заводить канал в пару распределения или в одно устройство. Правило простое: если сверху есть пара, которая умеет MLAG, лучше терминировать канал на этой паре (один линк в первое устройство, второй во второе) и получить отказоустойчивость без STP-блокировок. Если сверху одно устройство, канал собирается туда, а резервирование дальше решается на уровне маршрутизации или отдельного второго аплинка.

Trunk и список VLAN - отдельная зона риска. Лучше заранее договориться о явном списке VLAN на аплинках и одинаковом native VLAN (или вообще без native, где это возможно). Иначе можно получить ситуацию, когда трафик в VLAN ходит вниз, а обратно не возвращается.

Шлюз VLAN тоже продумайте заранее: кто будет default gateway для пользователей. В Cisco это чаще HSRP/VRRP на распределении, в Aruba - VRRP или distributed gateway в паре. Смысл один: при отказе одного устройства шлюз должен оставаться доступным без смены IP у клиентов.

После включения не ограничивайтесь пингом. Минимум проверьте состояние LACP, стабильность таблиц MAC/ARP, счетчики ошибок на аплинках, поведение STP и логи на предмет несовпадения VLAN/trunk или flapping.

Пример из практики: на этаже стоит пара коммутаторов доступа в VSF, а вверх два аплинка в пару распределения. Если на одном аплинке забыли добавить VLAN для телефонии, телефоны «видны», но не регистрируются: часть трафика идет через второй линк и теряется на распределении. Явный allowed VLAN на обоих концах и одинаковые настройки trunk решают это быстро.

Обслуживание и обновления: как не устроить себе простой

Отказоустойчивость чаще ломается не на аварии, а на плановых работах. В стеке (Cisco Catalyst stacking, Aruba CX VSF) и в MLAG-парах (VSX/MLAG) многое можно делать почти незаметно для пользователей, если заранее понимать границы.

Что можно делать без остановки, а где нужно окно работ

Без окна обычно проходят задачи, которые не меняют роли устройств и не рвут аплинки: замена одного кабеля аплинка при наличии второго линка в LACP, точечные изменения портов и профилей, замена одного устройства в паре при готовом конфиге.

Окно работ почти всегда нужно для изменений, которые могут перезапустить стек/пару или вызвать пересчет протоколов: смена версии ПО, замена master/primary, массовые изменения STP, переразметка LACP-групп на аплинках.

Обновления ПО: безопасный порядок и откат

План обновления лучше держать одинаковым для офиса и филиалов. Практичный порядок обычно такой: резервная копия конфига и фиксация версии, проверка свободной памяти и образа, обновление по принципу «сначала вторичный, потом основной», затем проверка сервисов (LACP, получение адресов, телефония, Wi‑Fi).

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

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

Для мониторинга важно ловить ранние сигналы: рост ошибок на портах, flapping линков, частые смены роли master/primary, перегрев, просадки питания, нестабильность VSF/stack-линков.

Документацию держите «дежурной» и короткой: схема подключений, список версий и где лежат образы, правила ролей, доступ к консоли/Out-of-Band, короткий план проверки после работ.

Если инфраструктуру обслуживает интегратор, договоритесь о едином регламенте и проверках для всех площадок. Тогда не появятся «особенные» филиалы, которые падают при первом же плановом обновлении.

Типовые ошибки при stacking, VSF и MLAG

Самые неприятные отказы почти всегда связаны не с железом, а с мелочами в настройках и процессе.

Частая ловушка - разные версии ПО и «тихие» несовместимости. В стеке Cisco Catalyst или паре Aruba CX (VSF/VSX) устройства могут подняться, но часть функций будет вести себя странно: от LACP до поведения STP. Особенно опасно, когда один коммутатор уже обновили «на всякий случай», а второй забыли.

Вторая ошибка - аплинки без нормальной агрегации. Один аплинк без LACP кажется простым решением, но при аварии вы получаете блокировку STP, петлю или выборочную потерю VLAN. Не менее частая история - на одном конце транка разрешен один набор VLAN, а на другом другой. Снаружи это выглядит как «то работает, то нет».

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

Отдельно опасно смешивать STP и MLAG/VSX без понимания ролей. В MLAG часть петель предотвращается самой парой, но STP все равно остается в сети и должен быть предсказуемым (корень, приоритеты и где он действительно нужен).

Перед запуском помогает короткая проверка: зафиксировать модели и версии, сверить LACP и VLAN на обоих концах аплинков, убедиться, что stacking/VSF собран в кольцо и промаркирован, определить STP root, сделать тест отказа и подготовить план отката.

Быстрый чеклист перед запуском

Перед включением в прод лучше потратить час на проверку, чем потом искать, почему стек или MLAG ведет себя странно.

Что проверить до переключения пользователей

Начните с физики: актуальная схема портов, понятная маркировка, stacking/VSF-линки воткнуты именно туда, куда указано в схеме.

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

Аплинки вверх делайте предсказуемо: LACP, одинаковые настройки trunk и один и тот же список VLAN на всем пути.

Короткий контрольный набор:

• Схема и маркировка совпадают с реальностью.
• Версии ПО одинаковые, бэкапы конфигов проверены.
• Аплинки в LACP, trunk одинаковый, VLAN совпадают.
• Тест отказа пройден: выключили одно устройство и один аплинк, сервисы не упали.
• Настроены базовые алерты: падение линков, ошибки портов, перегрев.

Мини-тест отказа, который правда ловит проблемы

Во время низкой нагрузки отключите один аплинк, затем питание одного коммутатора. Если пользователи теряют сеть дольше пары десятков секунд, первым делом проверьте LACP, STP/loop protection и согласованность VLAN на транках.

Пример: головной офис и три филиала на одной логике

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

В головном офисе на этаже ставим два access-коммутатора и объединяем их в один логический узел: Cisco Catalyst stacking или Aruba CX VSF. Вверх даем два аплинка в пару распределительных коммутаторов, обычно через LACP. При отказе одного access-коммутатора или одного аплинка этаж не падает целиком.

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

Для филиалов, где нет сильного инженера на месте, чаще проще стек (stacking/VSF): управляется как один, меньше ручных настроек. Если в филиале важна независимость control-plane и ожидаются регулярные обновления с минимальным простоем, тогда имеет смысл смотреть в сторону MLAG/VSX.

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

Следующие шаги: как быстро перейти от идеи к рабочей схеме

Соберите исходные данные в одном месте: точные модели коммутаторов и модулей, требования по допустимому простою (например, 5 минут или 0), список VLAN и критичных сервисов (телефония, кассы, Wi‑Fi, видеонаблюдение), а также как сегодня подключены аплинки вверх.

Дальше сделайте схему на одной странице. Не нужно рисовать весь офис до розетки. Достаточно показать, где будет пара/стек коммутаторов, куда идут аплинки, где нужен LACP и какие устройства должны пережить отказ одного коммутатора или линка. На этом шаге обычно становится понятно, нужен ли stacking/VSF или логичнее MLAG/VSX.

Мини-план внедрения

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

Отдельно продумайте поддержку: кто реагирует ночью, какие запчасти держать (кабели stacking/VSF, SFP, блок питания), и за сколько часов вы обязаны восстановиться. Для офисов и филиалов это часто важнее, чем идеальная архитектура.

Если нужен отказоустойчивый доступ на Cisco и Aruba без лишних рисков, можно привлечь GSE.kz как системного интегратора: помогут с проектом, внедрением и 24/7 поддержкой с сервисной сетью по Казахстану.