Привет, Хабр! Меня зовут Никита Николайчук, я – ведущий инженер по сетевым технологиям. Сегодня, в 2025 году, далеко не все компании могут позволить себе Cisco Nexus или Huawei Cloud Engine. При этом я пока еще не встречал статьи, которые бы описывали особенности внедрения и эксплуатации vPC (которая MLAG) пары российских вендоров. И начать хочется с Eltex. Безусловно, вы можете найти инструкции от вендора (достаточно подробные и понятные), однако в этой статье я постараюсь показать особенности реализации (или не реализации) некоторых наиболее популярных фич, к которым мы так привыкли, эксплуатируя Cisco и Huawei. Данная статья в некотором смысле представляет собой сравнительную таблицу для трех вендоров, при этом акцент сделан на логику работы и архитектуру коммутаторов Eltex MES (просто потому что про Cisco и Huawei сказали все и всё). Решение vPC/MLAG Eltex не подстраивается под какие-то конкретные модели и реализовано даже на коммутаторах уровня доступа: например, MES2348P, 48x1G – типичный коммутатор уровня доступа, на котором спокойно можно собрать vPC-пару, если вам это необходимо (хотя без особенностей реализации на младших моделях не обошлось, но об этом чуть позже). Лабораторный стенд я собирал на коммутаторах MES5332A (32x10G) – классических коммутаторах уровня агрегации.
Логика работы vPC/MLAG
Начнем с некоторых общих идей vPC/MLAG. В целом, со стороны Eltex вы, пожалуй, увидите отличия по большей части в терминологии. Вводится понятие vPC-домен, в рамках которого c точки зрения протоколов xSTP (поддерживается все: STP, RSTP, MSTP, PVSTP+, RPVSTP+) и LACP другие устройства считают устройства vPC-домена одним логическим целым (объединить всё также можно только две железки). Уже тут вы можете заметить первое отличие от того же Huawei, который VBST (аналог RPVSTP+ в исполнении Huawei) принципиально не поддерживает в MLAG-паре. Каждое устройство в Eltex всё также настраивается отдельно, кроме того, независимые Control Plane и Management Plane по-прежнему остаются актуальными. Синхронизация MAC-таблиц и VRRP происходит через … угадайте что? Правильно, peer-link! Для синхронизации используется VLAN 1, поэтому исключать его из peer-link крайне не рекомендуется. Для проверки доступности второго устройства используется также L3 keepalive link (и вот тут в терминологии Eltex появляется новый термин – peer-detection link). Надеюсь, это не внесет путаницы. В отличие от Huawei и Cisco, Eltex пока не умеет выносить peer-detection (предлагаю использовать в дальнейшем именно вариант peer-detection, чтобы привыкнуть к терминологии вендора) в VRF. Более того, вендор настоятельно не рекомендует собирать peer-detection на oob(mgmt)-интерфейсах и не тестирует работоспособность такого решения (хотя я проверил, и все сценарии отказа отрабатывают нормально). В качестве аргумента в пользу использования под peer-detection одного из основных портов, наверное, можно отнести аппаратную реализацию оборудования. В части о сценариях отказа я приведу на эту тему отдельный пример. Отметим, что вендор также рекомендует, чтобы номер порта для peer-detection был строго меньше номеров портов для peer-link:
Связано это с последовательной инициализацией портов при включении устройств. Данная рекомендация позволяет избежать сценария, когда в процессе инициализации интерфейсов оба устройства выбрали роль Primary (таймер истек, соседа пока нет), а через какое-то время поднялся peer-link и начиналась «пересборка» vPC. Необходимо, чтобы сначала поднялся peer-detection, железки друг друга обнаружили и, как следствие, не назначали на себя неправильные роли раньше времени. Вендор также не рекомендует поднимать peer-detection поверх peer-link, так как в этой ситуации падение peer-link неизбежно приводит к падению peer-detection (и получается так себе резервирование). Я бы хотел подчеркнуть этот довольно очевидный нюанс, так как несколько раз сталкивался с реализациями keepalive поверх peer-link у других вендоров (для чего? А главное зачем?).
Сценарии отказа
Здесь мы сконцентрируемся исключительно на Eltex, тем более что ничего нового относительно Cisco/Huawei мы тут не встретим. Однако переходить к реализации оптимизаций и фич без этой части было бы нечестно и непоследовательно. Сразу оговорюсь, что все графические иллюстрации приведены в парадигме того, что весь L3 трафик терминируется на vPC/MLAG-паре (например, посредством VRRP) и поверх peer-link работает какой-то протокол динамической маршрутизации (например, OSPF). Кроме того, на всех картинках ниже главные роли (Primary/Master/Active/Root) во всех упоминаемых протоколах будут у левого устройства.
1. Падение одного из интерфейсов виртуального Port-Channel: трафик конкретного Port-Channel перераспределится в одно плечо, в остальных Port-Channel изменений не будет.
2. Падение Uplink: трафик из ядра сети будет передаваться по peer-link. Тут следует отметить, что у Huawei есть решение Monitorlink, в котором состояние Downlink-интерфейса зависит от состояния Uplink-интерфейса: то есть падение Uplink приводит к падению Downlink. Это позволяет не задействовать peer-link под пересылку пользовательского трафика, однако на практике я данное решение видел только в лабе.
3. Падение Primary/Secondary коммутатора. В случае отказа Primary-коммутатора Secondary-коммутатор возьмет на себя роль Primary и будет перенаправлять весь трафик. В случае отказа Secondary-коммутатора Primary-коммутатор продолжит передачу трафика без изменений.
4. Падение peer-detection (ну который keepalive) линка. Нет изменений для пользовательского трафика, при выводе команды show vpc peer-detection будет отображаться статус not detect.
5. Падение peer-link. Secondary-коммутатор переводит все порты, состоящие в vPC группах, в состояние errdisable, трафик при этом будет ходить через Primary-коммутатор. Eltex в этой ситуации оперирует именно интерфейсами Port-Channel. Cвязанные с ними VLAN (SVI) перейдут в статус Down, если они были добавлены только в Port-Channel vPC-домена и peer-link.
Вот тут стоит отметить обоснованность решения не собирать peer-detection на oob(mgmt)-портах. Дело в том, что, если трафик обычных портов коммутатора обрабатывается ASIC, то oob(mgmt)-порт имеет прямую шину до CPU. Поэтому гипотетически возможен следующий сценарий отказа: что-то случилось с ASIC на Primary-коммутаторе (с CPU все хорошо)> упал peer-link> Secondary-коммутатор заблокировал свои интерфейсы (peer-detection, как вы понимаете, жив), а Primary с умершим ASIC, мягко говоря, не до обработки трафика. Грустная ситуация. Сценарий, конечно, фантазийно-уникальный, но случиться может именно с вами. В случае использования обычного порта под peer-detection линк он благополучно помрет вместе с ASIC, и роль Primary переедет на вторую железку.
6. Сценарии с двойным отказом:
Падение сначала peer-link, а потом peer-detection (последовательность важна): после падения peer-link Secondary-коммутатор переводит все порты, состоящие в vPC группах, в состояние errdisable, трафик при этом будет ходить через Primary-коммутатор. Падение peer-detection не вызовет дополнительных изменений в сети.
Падение сначала peer-detection, а потом peer-link: split brain scenario. Тут картинку рисовать, наверное, смысла нет. Синхронизации информации не будет (прилег peer-link), но и Primary-коммутатор сообщить соседу, что он все еще жив, не сможет (за пару минут до этого прилег peer-detection). Поэтому Secondary-коммутатор не будет переводить свои порты в состояние errdisable, а начнет считать себя тоже главным. В итоге у нас два Primary-коммутатора и проблемы с сетью. Например, один из коммутаторов vPC-пары отправляет ARP-запрос в сторону нижестоящего устройства (коммутатора/сервера – чего угодно), но нижестоящее устройство упорно отправляет ARP-ответ в сторону другого коммутатора vPC-пары (это же Port-Channel, в котором все порядки наводит балансировка). Первый коммутатор, который отправлял запрос, ARP-ответ в такой ситуации не получит (напоминаю, что peer-link лежит, и второй коммутатор рад бы передать ответ, да не может).
При этом старые сессии могут работать в течении какого-то времени (до протухания записей в таблицах). Отметим, что в сценарии, когда у вас вниз идет не Port-Channel, а, допустим, 2 L3 линка в том же OSPF (L3 to access, все дела), все будет работать, так как тут мы в целом ушли от функционала MLAG.
Конечно, тут можно еще для полноты картины добавить сценарии, когда одновременного отказали оба коммутатора/оба Uplink-порта/оба Downlink порта, но тут все достаточно очевидно: «шеф, все пропало», трафик передаваться не будет.
Собственно, осталось обсудить самое «вкусное», и начнем мы с отношения Eltex к Active/Active в L3-режиме.
L3 Active-Active
Думаю, случай с работой vPC/MLAG в L2 режиме, когда все сети терминируются где-то в ядре, в 2025 году разбирать не станем (хотя не так давно видел такое решение). Вместо этого сосредоточимся на L3. Для терминации сетей на уровне агрегации обычно используют семейство протоколов FHRP (HSRP, VRRP, GLBP). Из них открытым является только VRRP, и он, как и HSRP, предусматривает режим работы Active/Standby. Однако в случае с vPC-парой многие вендоры придумали различные модификации стандартного поведения.
Cisco и Huawei поддерживают Active/Active терминацию шлюза по умолчанию. Кратко вспомним, как это работает.
Cisco: HSRP/VRRP + флаг G. С точки зрения устройства доступа трафик равновероятно может разложиться и в правое, и в левое плечо Port-channel, при этом в качестве MAC получателя будет указан vMAC протокола HSRP/VRRP, который находится на активном с точки зрения HSRP/VRRP коммутаторе. По логике, если трафик с получателем vMAC придет на Stanby/Backup коммутатор, то он должен честно переслать его на Active/Master по peer-link. В решении Active/Active оба коммутатора будут обрабатывать трафик, который пришел на vMAC. Достигается это за счет использования флага G (gateway) для vMAC в таблице MAC-адресов на обоих коммутаторах, при этом Standby/Backup коммутатор изучит vMAC через peer-link. Если MAC-адрес в таблице MAC-адресов помечен флагом G, то коммутатор будет обрабатывать трафик на этот адрес так же, как если бы он был предназначен ему. Таким образом, Standby/Backup коммутатор будет обрабатывать трафик на vMAC наравне с Active/Master коммутатором. Отметим, что данный функционал работает «из коробки», без включения функции peer-gateway.
Решение peer-gateway может быть полезно в ситуациях, когда вы, например, используете динамическую маршрутизацию с двумя соседствами через Port-Channel. Более того, в ситуациях, когда трафик в этом сценарии должен будет пересылаться с одного Member-порта на другой, peer-gateway будет жизненно необходим. По сути оптимизация peer-gateway также направлена на реализацию Active/Active и позволяет коммутатору обработать трафик, который адресован на MAC-адрес его vPC-соседа. В данном решении устройства при обмене по peer-link информацией о MAC-адресах на своих интерфейсах добавляют к полученным от соседа MAC-адресам флаг G (gateway) и, таким образом, могут маршрутизировать трафик, который был адресован их vPC-соседу.
Также peer-gateway полезен при подключении балансировщиков к vPC-паре. Это связано с тем, что у ряда производителей балансировщики отправляют трафик не на MAC-адрес своего шлюза, а на тот MAC, с которого к нему пришел пакет, который был изучен на Data Plane.
Huawei: Dual-Active Gateway. На VLANIF (читай SVI на цисковском) интерфейсах первого и второго узлов MLAG-пары настраиваются одинаковый IP-адрес и одинаковый MAC-адрес. Именно этот адрес указывается в качестве шлюза по умолчанию на нижестоящем устройстве. Таким образом, в какое бы плечо Port-Channel ни разбалансировался трафик на нижестоящем устройстве (уже несколько раз речь заходит про балансировку, поэтому прорекламирую свою статью «Особенности балансировки трафика в агрегированных каналах»), вы все равно попадете на нужный вам IP-адрес, и обе ноды одинаково хорошо смаршрутизируют трафик в сторону ядра сети. Попахивает anycast-gateway, но он тут может использоваться без привязки к VXLAN/EVPN (у Cisco все же anycast-gateway с VXLAN/EVPN связаны неразлучно).
Eltex: традиционный VRRP + Master/Backup. Используется традиционный подход протокола VRRP. Одно из устройств становится мастером и обрабатывает ВЕСЬ L3 трафик. И даже если хэш разложился так, что трафик пошел «не в то» плечо, вторая нода просто перешлет его через peer-link на Master, а Master уже честно обработает трафик:
Да, есть безумные сценарии в стиле «фильтровать VRRP на peer-link и получать на выходе два устройства с одним VIP + vMAC», но предлагаю не идти в эту сторону и уж точно не пробовать на проде. Просто поставить одинаковый IP + MAC, как это сделал Huawei, тоже не получится хотя бы потому, что на Eltex MES нельзя настроить MAC на SVI. Отметим, что, строго говоря, совпадение роли Primary с точки зрения vPC и Master с точки зрения VRRP необязательно (например, актуально для сценария «ручной балансировки», когда у вас для одной части VLAN-ов в качестве Master выступает первая нода, а для другой части – вторая). Отметим еще одну «особенность» реализации: не для всех моделей есть поддержка протокола VRRP в VRF. Другими словами, если вы хотите какую-то SVI перенести в VRF, то VRRP вы там не поднимите (например, в моделях MES3324/48). На MES5332A такой проблемы нет, и все работает и с VRF, и без него.
Синхронизация ARP
Полезный функционал, если vPC/MLAG выступает в роли L3-шлюза. Тут все достаточно просто:
Вендор | Поддержка синхронизации ARP-записей |
Cisco Nexus | да |
Huawei Cloud Engine | да |
Eltex MES | нет |
Оптимизации STP
Отметим, что сама по себе технология vPC/MLAG не отказывается от использования xSTP: вы всё также строите дерево и рассылаете BPDU, просто теперь на коммутаторах доступа не блокируется половина интерфейсов до агрегации, как это было до появления vPC/MLAG (нy и Stack/VSS). По сути вы приходите к Active/Active на L2. Для определенности будем рассматривать наиболее популярный сценарий, где роль Root-коммутатора терминируется на vPC-паре. В базовой реализации Primary коммутатор vPC-пары выбирается Root, а Secondary просто транслирует BPDU от Primary, при этом не изменяя стоимости пути (не прибавляет к RPC стоимость peer-link). При этом сценарий, в котором только один узел рассылает BPDU, приводит к дополнительной нагрузке на peer-link и более длительному (по сравнению с оптимизацией peer-switch) процессу сходимости протокола STP в случае отказа Primary ноды.
Cisco: peer-switch. Использование данной оптимизации позволяет обоим коммутаторам считать себя Root-коммутаторами, генерировать и обрабатывать BPDU. При этом для генерации BPDU используется одинаковый MAC-адрес: System MAC. Он вырабатывается при согласовании vPC-пары и также необходим для работы LACP, чтобы другие узлы считали, что строят Port-Channel c одним устройством. Таким образом, выход из строя Primary vPC-ноды не повлечет за собой конвергенции xSTP (вторая нода как рассылала BPDU с тем же MAC, что и первая, так и будет их рассылать). Применимо также в сценариях, когда vPC-пара не является Root.
Huawei: V-STP. Данная конструкция работает аналогично Cisco peer-switch и включается в Huawei Cloud Engine в MLAG-паре. Тут, правда, есть ограничение: кроме того, что в MLAG на Huawei в целом не поддерживается VBST, при использовании V-STP также перестает поддерживаться MSTP, и на выбор остаются только STP и RSTP. Поэтому при построении одного L2 домена между коммутаторами Cisco и MLAG-парой Huawei с V-STP подружить их будет непросто. Данную оптимизацию также можно применять в сценариях, когда MLAG-пара не является Root.
Eltex. Оба коммутатора пары считают себя Root и шарят один system-mac, однако рассылает BPDU именно Primary коммутатор, а Secondary просто пересылает BPDU, при этом не делая инкремент RPC для peer-link (то есть просто транслирует их, не прибавляя стоимости).
Обновление ПО
Eltex допускает работу vPC-пары на разных версиях для обновления ПО, хотя и не дает четких рекомендаций по типу «дельта версий не должна быть больше условных N релизов». Таким образом, в теории вы можете обновиться с самой древней версии на самую свежую, и корректность работы vPC не должна нарушиться. В целом у того же Huawei есть лицензия на «обновление в режиме обслуживания», когда трафик отводится от обновляемой железки. В теории это должно снизить вероятность потери пакетов, но на практике я этой фичей не пользовался. У Cisco Nexus по каждой серии также есть свои достаточно подробные рекомендации по бесшовному (или почти бесшовному) обновлению. Что касается Eltex, лично у меня есть успешный опыт обновления MES5332A, где в моменте разница в прошивках Primary и Secondary составляла 3 релиза (Primary – Х, Secondary – Х+3), при этом vPC пара после обновления успешно собралась и нормально отрабатывала все сценарии отказа.
Вместо заключения
Это, безусловно, не все тонкости и особенности работы vPC/MLAG, и есть сценарии, которые остались без внимания. Возможно, потом из них получится собрать еще одну мини-статью. Если вам близка тема внедрения vPC на Eltex – приходите со своими историями в комментарии. Благодарю за внимание!
Спасибы
Ярославу Бондаренко (@braonle) за ревью статьи