Я открыл тикет по этому поводу, но решил тоже сюда написать, чтобы получить комментарии:
MLAG синхронизирует LACP system-id портов вторичных нод с LACP system-id интерфейса агрегации первичной ноды, которому назначен тот же MLAG ID.
Проблема 1. Если перезагрузить первичную ноду, вторичная нода сбрасывает свои LACP system-ID обратно на стандартные для шасси. Из-за этого возникает ненужный сбой/простой передачи данных на 3-4 секунды (проверено с таймерами LACP минимум 1 секунда) при перезагрузке первичной ноды. Аналогичный сбой случается, когда первичная нода возвращается в сеть, восстанавливая MLAG-пиринговое соединение, и вторичная снова сбрасывает свои LACP system-ID, чтобы совпадать с первичной.
Проблема 2. Отчасти связана и помогает приблизиться к решению. По умолчанию у вас на каждом порте агрегации используется разный LACP system-ID. Это технически неправильно. LACP system-ID должен быть одинаковым для всего шасси (а значит, и для всех MLAG-пиров). Этот ID не связан с MAC-адресом физического порта, он нужен только для сигнализации. Различаться должен только LACP port ID для разных агрегированных портов.
Проблема 3. Похожая на проблему 1: при перезагрузке первичной ноды RSTP bridge ID сбрасывается на значение по умолчанию. В MCLAG-среде с RSTP оба пира должны всегда иметь одинаковый bridge ID, потому что по определению MCLAG - это один физический порт/устройство.
Решение: когда MLAG-пара впервые поднимается, и одно устройство становится первичным, MAC-адрес должен синхронизироваться с вторичным пировым устройством и стать неизменяемым. Так, если первичная нода перезагружается (например, для апгрейда), сеть не будет испытывать серьезной реконсигурации (как со стороны RSTP, так и LACP). Port-ID первичного устройства должен совпадать с MLAG ID. Port-ID вторичного устройства должен быть MLAG ID плюс фиксированное значение, например: добавить 128 для каждого порта на локальном свитче, добавить 1024 за то, что это вторичное устройство. Это гарантирует уникальность всех LACP port ID на всех портах агрегата (даже на разных свитчах). В то же время LACP system ID будет одинаковым для всех устройств. Все эти значения должны быть неизменяемыми. LACP port KEY обычно должен просто совпадать с MLAG ID и быть одинаковым для обоих устройств.
Усовершенствованное решение (рекомендуется тем, кто серьезно занимается MLAG): разрешить установить статический LACP system ID и статический RSTP bridge ID. RSTP bridge ID не должен влиять на MAC-адрес самого моста — MAC-адреса устройств должны оставаться уникальными для целей L3. Также стоит дать пользователю возможность указать, какое устройство является node0, а какое node1.
В обоих решениях влияние касается только MLAG-агрегатов. Агрегаты для ICL-порта и других не-MLAG связей должны работать по традиционной логике.
Стоит отметить, что я наблюдал непоследовательное поведение RSTP ID и MAC моста вторичного устройства при перезагрузке первичной ноды, если на мосту не установлен статический управляемый MAC.
MLAG синхронизирует LACP system-id портов вторичных нод с LACP system-id интерфейса агрегации первичной ноды, которому назначен тот же MLAG ID.
Проблема 1. Если перезагрузить первичную ноду, вторичная нода сбрасывает свои LACP system-ID обратно на стандартные для шасси. Из-за этого возникает ненужный сбой/простой передачи данных на 3-4 секунды (проверено с таймерами LACP минимум 1 секунда) при перезагрузке первичной ноды. Аналогичный сбой случается, когда первичная нода возвращается в сеть, восстанавливая MLAG-пиринговое соединение, и вторичная снова сбрасывает свои LACP system-ID, чтобы совпадать с первичной.
Проблема 2. Отчасти связана и помогает приблизиться к решению. По умолчанию у вас на каждом порте агрегации используется разный LACP system-ID. Это технически неправильно. LACP system-ID должен быть одинаковым для всего шасси (а значит, и для всех MLAG-пиров). Этот ID не связан с MAC-адресом физического порта, он нужен только для сигнализации. Различаться должен только LACP port ID для разных агрегированных портов.
Проблема 3. Похожая на проблему 1: при перезагрузке первичной ноды RSTP bridge ID сбрасывается на значение по умолчанию. В MCLAG-среде с RSTP оба пира должны всегда иметь одинаковый bridge ID, потому что по определению MCLAG - это один физический порт/устройство.
Решение: когда MLAG-пара впервые поднимается, и одно устройство становится первичным, MAC-адрес должен синхронизироваться с вторичным пировым устройством и стать неизменяемым. Так, если первичная нода перезагружается (например, для апгрейда), сеть не будет испытывать серьезной реконсигурации (как со стороны RSTP, так и LACP). Port-ID первичного устройства должен совпадать с MLAG ID. Port-ID вторичного устройства должен быть MLAG ID плюс фиксированное значение, например: добавить 128 для каждого порта на локальном свитче, добавить 1024 за то, что это вторичное устройство. Это гарантирует уникальность всех LACP port ID на всех портах агрегата (даже на разных свитчах). В то же время LACP system ID будет одинаковым для всех устройств. Все эти значения должны быть неизменяемыми. LACP port KEY обычно должен просто совпадать с MLAG ID и быть одинаковым для обоих устройств.
Усовершенствованное решение (рекомендуется тем, кто серьезно занимается MLAG): разрешить установить статический LACP system ID и статический RSTP bridge ID. RSTP bridge ID не должен влиять на MAC-адрес самого моста — MAC-адреса устройств должны оставаться уникальными для целей L3. Также стоит дать пользователю возможность указать, какое устройство является node0, а какое node1.
В обоих решениях влияние касается только MLAG-агрегатов. Агрегаты для ICL-порта и других не-MLAG связей должны работать по традиционной логике.
Стоит отметить, что я наблюдал непоследовательное поведение RSTP ID и MAC моста вторичного устройства при перезагрузке первичной ноды, если на мосту не установлен статический управляемый MAC.
