Автоматический поиск multihomed PE и ESI label

В отличии от VPLS, в EVPN включена функция автоматического обнаружения РЕ-маршрутизаторов, подключенных к одному и тому же СЕ-маршрутизатору (multihomed сайты). В терминах EVPN стык PE<->CE называется Ethernet Segment. Каждому сегменту назначается ESI (Ethernet Segment Identifier, число размером 80 бит записанное в 10 группах по 8 бит в группе). Для single-homed сайтов данный идентификатор не играет роли и поэтому назначается автоматически и равен 0. Но вот для multihomed сайтов данный идентификатор очень важен и должен быть уникальным для всего EVPN-домена (благо количество возможных комбинаций ESI очень велико и равно 2^80). ES, подключенные к одному и тому же CE-маршрутизатору, должны иметь один и тот же ESI. Два значения из всего диапазона зарезервированы, и их нельзя задать административно — это все нули (используется как идентификатор для не multihoming сегментов) и все F.

В представленном выше выводе магический набор букв и цифр :112233445566778899aa: есть не что иное, как ESI, сконфигурированный администратором сети на физическом интерфейсе:

bormoglotx@RZN-PE-2> show configuration interfaces ge-0/0/4
description "link to RZN-MULTI-SW-1";
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
esi {
    11:22:33:44:55:66:77:88:99:aa;
    single-active;
}
mac 50:01:00:02:00:06;
unit 111 {
    encapsulation vlan-bridge;
    vlan-id 111;
    family bridge;
}

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

bormoglotx@RZN-PE-2> show route table RZN-VPN-3.evpn.0 match-prefix *1:62* detail

RZN-VPN-3.evpn.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
1:62.0.0.1:0::112233445566778899aa::0/304 (1 entry, 1 announced)
        *BGP    Preference: 170/-101
                Route Distinguisher: 62.0.0.1:0
                Next hop type: Indirect
                Address: 0x95c0f28
                Next-hop reference count: 20
                Source: 62.0.0.255
                Protocol next hop: 62.0.0.1
                Indirect next hop: 0x2 no-forward INH Session ID: 0x0
                State: Secondary Active Int Ext
                Local AS: 6262 Peer AS: 6262
                Age: 2:50 Metric2: 1
                Validation State: unverified
                Task: BGP_6262.62.0.0.255+179
                Announcement bits (1): 0-RZN-VPN-3-evpn
                AS path: I (Originator)
                Cluster list: 62.0.0.255
                Originator ID: 62.0.0.1
                Communities: target:6262:111 esi-label:00049660(label 300640) -----community-----
                Import Accepted
                Localpref: 100
                Router ID: 62.0.0.255
                Primary Routing Table bgp.evpn.0

Так как данный маршрут имеет в своем составе нативное расширенное комьюнити, характерное для данного EVPN-домена, то все PE маршрутизаторы в evpn-домене импортируют данный маршрут в таблицу маршрутизации соответствующей EVPN instance:

bormoglotx@RZN-PE-3> show route table RZN-VPN-3.evpn.0 match-prefix *1:62* detail | match esi
                Communities: target:6262:111 esi-label:00049660(label 300640)
                Communities: target:6262:111 esi-label:00049680(label 300672)

DF имеет исключительное право отправлять широковещательные кадры в сторону CE маршрутизатора, находящегося в ethernet сегменте, для которого данный PE маршрутизатор является DF. Все остальные non-DF маршрутизаторы BUM трафик в сторону CE маршрутизатора не отправляют.

У нас может быть два сценария: когда используется режим Single-Active и когда используется режим Active-Active (All-Active).

Как нетрудно догадаться, в Single-Active режиме у нас работает только одно плечо, второе находится в резерве. В случае падения основного плеча, трафик переходит на резервное. Возможно использовать одно плечо для передачи трафика в одном влане, а второе во втором, но сразу по обоим плечам в одном влане трафик идти не может (точнее не должен — если не так, то пишите в поддержку, видимо вы нашли баг, либо, что более вероятно, у инженера, который собирал схему, кривые руки).

В Active-Active или All-Active режиме работают все линки от CE к PE, для чего собирается MC-LAG. Принцип работы технологии MC-LAG в данной статье рассматриваться не будет: подразумевается, что читатель уже изучил данную тему.

В первом случае все просто — выбирается DF, и весь трафик, включая и BUM трафик, форвардит только он. При этом ESI label в анонсе отсутствует (во всяком случае на оборудовании Juniper ее нет), хотя согласно RFC даже при Single-Active режиме рекомендуется использовать данную метку, чтобы в случае ошибки в работе механизма выбора DF (когда оба PE маршрутизатора вдруг будут считать себя DF) не образовалась петля.

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

PreviousМаршрут типа 1 (Ethernet Auto-Discovery Route)NextMAC Mass Withdrawal

Last updated