В отличии от 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)
Зачем оно нужно? Рассмотрим такую схему:
В данном сценарии мы имеем потенциальную L2 петлю, так как если BUM трафик от CE1 попадет на PE2, то будет отправлен всем остальным PE маршрутизаторам, включая и PE1. PE1 тоже имеет линк в сторону CE1, от которого и был получен BUM трафик. И если PE1 отправит пакет на CE1, то мы получаем петлю на 2 уровне, а как вы знаете, в L2 заголовке нет поля TTL. Ситуация, мягко говоря, будет неприятная. Как с этим бороться? В EVPN для данной цели используется автоматически выбор Designated Forwarder-а (DF). Как он выбирается мы рассмотрим позже, а пока поговорим о его назначении.
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) не образовалась петля.
При нормальной работе механизма выбора DF одно плечо просто блокируется, а значит PE маршрутизатор не изучает по заблокированному линку MAC-адреса, следовательно и не анонсирует ничего на другие PE маршрутизаторы. Но, даже если каким то заковыристым путем на данный маршрутизатор прилетит BUM трафик, то он будет просто отброшен.
Во втором случае немного сложнее. Тут так же выбирается DF, который имеет право отправлять BUM трафик в сторону CE маршрутизатора — то есть проблемы с трафиком, идущим к CE маршрутизатору, нет. Проблемы могут появиться при передаче BUM трафика от CE маршрутизатора. Так как CE маршрутизатору абсолютно без разницы кто из PE маршрутизаторов DF (точнее сказать CE маршрутизатор думает, что просто подключен к другому коммутатору агрегированным интерфейсом), то возможна следующая ситуация. Предположим, что широковещательный пакет от CE1 прилетел на PE1, который не является DF. PE1 получает пакет и отправляет его всем остальным PE маршрутизаторам, включая и PE2. PE2, являясь DF маршрутизатором для данного сегмента, форвардит BUM трафик обратно на CE маршрутизатор. Да, получили петлю. Вот тут-то нам и пригодится ESI-label. Дело в том, что при отправке пакета на PE2, PE1 навешивает две метки: ESI-label (дно меток) и Inclusive Multicast label. PE2 получает пакет, снимает верхнюю метку и обнаруживает ESI-label, это говорит маршрутизатору о том, что флудить пакет в сторону CE1 не надо, так как трафик из этого сегмента и прилетел. Но зачем же тогда этот пакет вообще отправлять на PE2? Дело в том, что к PE2, помимо CE1, от которой и был получен данный трафик, могут быть подключены другие CE маршрутизаторы, которые могут быть заинтересованы в данном трафике.
Сокращения на схеме:
IM — Inclusive Multicast label
ESI — ESI label
TL — Transport MPLS label
Примечание: PE1 и PE2 непосредственно соединены, поэтому транспортная метка при отправке трафика от PE1 на PE2 не навешивается. Если бы между ними было бы больше одного хопа, то мы бы получили стек из трех меток.