А нужен ли нам 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

bormoglotx@RZN-SW-1> 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-маршрутизаторов:

bormoglotx@RZN-SW-1> show configuration interfaces ge-0/0/0 
description "RZN-PE-1 | ae1<<>>ae3";
gigether-options {
    802.3ad ae0;
}

bormoglotx@RZN-SW-1> 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-флаппинг):

bormoglotx@RZN-PE-1> 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;
    }
}

bormoglotx@RZN-PE-2> 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:

bormoglotx@RZN-SW-1> 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 маршрутизаторов:

bormoglotx@RZN-PE-1> 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

bormoglotx@RZN-PE-2> 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) ну и наверно можно добавить как минус увеличение конфигурации.