Зачем нужен маршрут типа 1 per-ESI?

Маршрут типа 1 имеет несколько функций.

Сгенерированный per-ESI маршрут типа 1 несет в себе расширенное community в котором указана mpls метка, называемая split horizon label:

bormoglotx@RZN-PE-1> show route table vSwitch-eVPN-1.evpn.0 match-prefix *FFFF* detail 

vSwitch-eVPN-1.evpn.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
1:62.0.0.2:0::01::FFFF:FFFF/304 AD/ESI (1 entry, 1 announced)
*BGP Preference: 170/-101
Route Distinguisher: 62.0.0.2:0
Next hop type: Indirect, Next hop index: 0
Address: 0xb1e55f0
Next-hop reference count: 20
Source: 62.0.0.100
Protocol next hop: 62.0.0.2
Indirect next hop: 0x2 no-forward INH Session ID: 0x0
State: Secondary Active Int Ext
Local AS: 42000.62 Peer AS: 42000.62
Age: 3:20:48 Metric2: 1 
Validation State: unverified 
Task: BGP_42000.62.62.0.0.100
Announcement bits (1): 0-vSwitch-eVPN-1-evpn 
AS path: I (Originator)
Cluster list: 62.0.0.100
Originator ID: 62.0.0.2
Communities: target:42000:1 target:42000:2 target:42000:3 esi-label:all-active (label 302656)
Import Accepted
Localpref: 100
Router ID: 62.0.0.100
Primary Routing Table bgp.evpn.0

Метка указана в строке:

Communities: target:42000:1 target:42000:2 target:42000:3 esi-label:all-active (label 302656)

Как это нам поможет победить описанную выше петлю? Теперь, non-DF маршрутизатор, отправляя BUM трафик в сторону DF-маршрутизатора, будет добавлять в стек меток дополнительную метку, указанную в данном community. То есть получается такая картина: PE маршрутизатор получил BUM трафик из сегмента с ESI X, для которого он является non-DF маршрутизатором. Теперь он должен переслать этот трафик все остальным PE-кам в EVPN домене, включая и другие PE-маршрутизаторы, имеющие линк в ESI X. Всем PE-маршрутизаторам трафик отправляется как обычно — с использованием IM метки, а вот маршрутизатору, который является DF-ом для сегмента ESI X, маршрутизатор сначала навешивает Split horizon метку и только потом IM метку. Это будет указывать DF маршрутизатору на то, что данный пакет пришел из ESI X и обратно в этот сегмент его отправлять не надо. Логично, что эту метку надо добавлять только в том случае, если пакет отправляется в сторону DF маршрутизатора, так как non-DF маршрутизаторы и так этот трафик не отправят в сегмент ESI X.

Со стороны DF маршрутизатора это выглядит так:

Если маршрутизатор получил пакет с IM меткой и S=1 (то есть дно меток а занчит данная метка — последняя в стеке), то маршрутизатор рассылает пакет всем подключенным к нему CE-коммутаторам/маршрутизаторам в данном EVPN инстансе.

Если же маршрутизатор получил пакет с IM меткой и S=0 (то есть данная метка — не последняя в стеке), то верхняя метка снимается и делается второй mpls lookup. Делая второй lookup маршрутизатор видит Split Horizon метку с S=1. Исходя из этого маршрутизатор флудит пакет в сторону всех CE маршрутизаторов/коммутаторов, за исключением того, который находится в том же сегменте, из которого трафик и получен.

Возникает вопрос, почему данный маршрут генерируется per-ESI, но в отличии от маршрута типа 4 имеет нативное community инстанса (или как в нашем случае нескольких инстансов)? Дело в том, что данный маршрут несет в себе не только split horizon label. Если вы обратите внимание на community esi-label:all-active (label 302656), то увидите, что указан тип сегмента all-active или single-active. Эта информация необходима другим PE-кам, чтобы понимать — а можно ли балансировать трафик по PE-кам или нет (но об этом чуть позже) и как использовать Aliasing label.

Еще одна важная функция данного маршрута — обеспечение быстрой сходимости. К примеру у нас отвалился линк в сторону CE устройства, логично что все этот линк отвалился для всех инстансов, в которые он был добавлен. А значит надо отменять все маршруты, которые которые анонсированы PE-кой для данного сегмента, то есть маршрутизатор должен начать отправлять withdraw сообщения, отменяя анонсированные MAC/IP маршруты из всех инстансов, которые имели имели линк в сторону данного ESI, так как теперь эти маршруты не действительны. А если таких маршрутов несколько тысяч? Поэтому вместо отправки кучи withdraw сообщений маршрутизатор отменяется маршрут типа 1, что заставляет все остальные PE маршрутизаторы понять, что через данный PE маршрутизатор больше этот сегмент не доступен. Это называется MAC Mass Withdraw. Маршутизатору проще быстро обработать одно сообщение вместо тысячи, что ествественно сокращает время сходимости, особенно если MAC-адресов за отвалившимся интерфейсом несколько тысяц.

Теперь думаю понятно, почему у данного маршрута именно нативное(-ые) community — в нашем сценарии PE3 не имеет ESI 00:00:00:00:00:00:00:00:00:01 и если community генерировать, как для маршрута типа 4, то PE-3 этот маршрут просто отбросит, проверив его community.

Примечание: если вы заметили в маршруте типа 1, сгенерированного per-ESI, указываются вместо тега все единицы: 1:62.0.0.2:0::01::FFFF:FFFF/304 AD/ESI. Это не прихоть Juniper, тут все согласно RFC — в маршруте типа 1, если он сгенерирован per-ESI в поле tag-id должно быть указано максимально возможное значение (под это поле выделено 32-бита), а mpls метка выставляется в 0.

Таким образом EVPN позволяет избежать петель и обеспечили возможность быстрой сходимости. Но если вы вспомните в начале в выводе мы видели, что соседний маршрутизатор анонсировал нам 2 маршрути типа 1. Что за второй маршрут? Так получилось, что маршрут типа 1 может генерироваться еще и per-EVI.