А нужен ли нам MC-LAG в EVPN?

Мы рассматривали схему с подключением multihomed CE к PE-кам с использованием LAG. Причем для PE-маршрутизаторов это просто один физический интерфейс, добавленный в бандл, а вот со стороны CE - один LAG, в который добавлены интерфейсы в сторону обеих PE-шек, то есть получается некая эмуляция MC-LAG, во всяком случае CE маршрутизатор/коммутатор будет думать, что подключен к одному и тому же узлу провайдера и балансирует трафик по обоим членам бандла. С точки зрения конфигурации это выглядит так:

Со стороны RZN-SW-1 настраиваем один LAG интерфейс:

Примечание: Перед созданием LAG интерфейсов не забываем в настройках шасси включить соответствующий функционал:

set chassis aggregated-devices ethernet device-count 20
[email protected]> show configuration interfaces ae0
description "LAG to RZN-PE-1/2 | ae0<<>>ae3";
flexible-vlan-tagging;
mtu 1600;
encapsulation flexible-ethernet-services;
aggregated-ether-options {
lacp {
active;
periodic fast;
}
}

В него добавляются линки в сторону обоих PE-маршрутизаторов:

[email protected]> show configuration interfaces ge-0/0/0
description "RZN-PE-1 | ae1<<>>ae3";
gigether-options {
802.3ad ae0;
}
[email protected]> show configuration interfaces ge-0/0/1
description "RZN-PE-2 | ae2<<>>ae3";
gigether-options {
802.3ad ae0;
}

Со стороны PE-маршрутизаторов в таком сценарии должен по идее настраиваться MC-LAG, но с EVPN/MPLS мы обойдемся без этого. На PE-ках собираем LAG в сторону CE и указываем один и тот же system-id, чтобы MAC адрес PE-шек в сторону CE был одинаковым (иначе CE коммутатор будет детектировать MAC-флаппинг):

[email protected]> show configuration interfaces ae3
description "RZN-SW-1 | ge-0/0/0 | ae3<<>>ae0 ";
flexible-vlan-tagging;
mtu 1600;
encapsulation flexible-ethernet-services;
esi {
00:00:00:00:00:00:00:00:00:01;
all-active;
}
aggregated-ether-options {
lacp {
active;
periodic fast;
system-id 02:00:00:00:00:01;
}
}
[email protected]> show configuration interfaces ae3
description "RZN-SW-1 | ae3<<>>ae0 | MC-LAG with RZN-PE-2";
flexible-vlan-tagging;
mtu 1600;
encapsulation flexible-ethernet-services;
esi {
00:00:00:00:00:00:00:00:00:01;
all-active;
}
aggregated-ether-options {
lacp {
active;
periodic fast;
system-id 02:00:00:00:00:01;
}
}

Теперь можно проверить состояние бандла.

Со стороны RZN-SW-1:

[email protected]> show lacp interfaces ae0
Aggregated interface: ae0
LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity
ge-0/0/0 Actor No No Yes Yes Yes Yes Fast Active
ge-0/0/0 Partner No No Yes Yes Yes Yes Fast Active
ge-0/0/1 Actor No No Yes Yes Yes Yes Fast Active
ge-0/0/1 Partner No No Yes Yes Yes Yes Fast Active
LACP protocol: Receive State Transmit State Mux State
ge-0/0/0 Current Fast periodic Collecting distributing
ge-0/0/1 Current Fast periodic Collecting distributing

Со стороны PE маршрутизаторов:

[email protected]> show lacp interfaces ae3
Aggregated interface: ae3
LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity
ge-0/0/4 Actor No No Yes Yes Yes Yes Fast Active
ge-0/0/4 Partner No No Yes Yes Yes Yes Fast Active
LACP protocol: Receive State Transmit State Mux State
ge-0/0/4 Current Fast periodic Collecting distributing
[email protected]> show lacp interfaces ae3
Aggregated interface: ae3
LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity
ge-0/0/4 Actor No No Yes Yes Yes Yes Fast Active
ge-0/0/4 Partner No No Yes Yes Yes Yes Fast Active
LACP protocol: Receive State Transmit State Mux State
ge-0/0/4 Current Fast periodic Collecting distributing

Возможен вариант, когда со стороны PE-маршрутизаторов будут просто физические интерфейсы, а вот со стороны CE — простой статический LAG (без LACP).

Ну и второй вариант подключения — через стандартный MC-LAG со всем вытекающими (ICCP, ICL). Сложно не согласиться, что первый вариант намного проще второго. И применять EVPN/MPLS и MC-LAG лично я смысла не вижу, особенно при условии, что MC-LAG в All-Active режиме еще и требует ICL, кроме случаев, когда MC-LAG жизненно необходим или уже сконфигурен для других сервисов (не ломать же его теперь).

К плюсам EVPN с MC-LAG можно отнести то, что помимо EVPN на данном стыке можно реализовать и другие сервисы с резервированием (ну к примеру VPLS с бекап сайтом или L2CKT с бекапным нейбором — ведь не все железо поддерживает EVPN). А вот из минусов можно выделить то, что обычно MC-LAG ограничен 2-мя нейборами (EVPN multihoming поддерживает больше 2-х PE-шек в режиме Active-Active); необходимость в линке между PE-ками, проприетарность самой технологии (имеется в виду MC-LAG) ну и наверно можно добавить как минус увеличение конфигурации.