BGP EVPN

Это страничка с терминологией которую нужно запомнить для понимание EVPN

MP-BGP

MP-BGP (MultiProtocol-BGP) - расширение протокола BGP, при котором есть возможность передавать другие AFI/SAFI.

По сути MP-BGP может работать со многими address family. Информация об address-family передается в полях AFI/SAFI.

AFI

AFI - Address Family Identifier - идентификатор семейства адресов

NLRI

• Network Layer Reachability Information (NLRI) - информация о самих префиксах

MP_REACH_NLRI

• Для других AFI/SAFI (которых не было в изначальном стандарте BGP)

появляется специальный Path Attribute - MP_REACH_NLRI, в котором уже описан NLRI.
Все эти моменты описаны в RFC-4760 (но кто читает RFC)

SAFI

SAFI - Subsequent Address Family Identifier - последующий идентификатор семейства адресов Вот пример, какие семейства AFI/SAFI есть в BGP (их больше сейчас уже на самом деле)

Следует обратить внимание, что для

• AFI/SAFI = 1/1 - ipv4 unicast раздел NLRI в структуре сообщения находится на одном уровне с "Path Attributes",
• а для других AFI/SAFI появляется специальный Path Attribute - MP_REACH_NLRI, в котором уже описан NLRI.

Все эти моменты описаны в RFC-4760

MP-BGP

Вспомним формат сообщения BGP UPDATE в его классическом варианте:

[Withdrawn prefixes (опционально)] + [Path Attributes] + [NLRI]

Withdrawn prefixes и NLRI содержат префиксы IPv4, и их структура не
подразумевает поддержку иных протоколов.

Path attributes (например, AS_PATH, ORIGIN, LOCAL_PREF, NEXT_HOP) привязаны к NLRI; префиксы с разными наборами аттрибутов необходимо передавать разными UPDATE. Также стоит отметить, что NEXT_HOP – это IPv4 адрес.

Чтобы реализовать в BGP поддержку протоколов, отличных от IPv4, были добавлены два новых transitive атрибута.

Первый известен как MP_REACH_NLRI, который имеет следующую структуру: [AFI/SAFI] + [NEXT_HOP] + [NLRI] NEXT_HOP и NLRI выполнены в формате, который определён протоколом, закодированным в AFI/SAFI (Address Family Identifier и Subsequent Address Family Identifier, соответственно).
К примеру, это может быть IPv4 префикс или CLNS.(CLNS (Connectionless Network Service) — протокол 3го уровня в стеке OSI, для передачи данных без установления соединения.)

Таким образом, вся информация о не-IPv4 префиксах закодирована в новом BGP Path Attribute. Типовое сообщение BGP Update, которое несёт MP_REACH_NLRI, не содержит в себе "классического" атрибута NEXT_HOP, Withdrawn Prefixes или NLRI, которые можно найти в обычном UPDATE-сообщении. Для расчёта next-hop маршрутизатору следует использовать информацию из атрибута MP_REACH_NLRI. Тем не менее, MP-BGP UPDATE может нести остальные атрибуты BGP, такие как AS_PATH, ORIGIN, MED, LOCAL_PREF и т.д. Однако в этом случае атрибуты относятся к не-IPv4 префиксам из MP_REACH_NLRI.

Формат второго атрибута, MP_UNREACH_NLRI, похож на формат MP_REACH_NLRI; он перечисляет те маршруты MP-BGP, которые подлежат удалению. Другие атрибуты для этого не нужны, поэтому сообщение UPDATE может состоять только из MP_UNREACH_NLRI.

Список поддерживаемых AFI можно найти в RFC 1700 (несмотря на то, что он устарел, в нем можно найти много полезной информации).

• К примеру, AFI = 1 означает IPv4,
• AFI = 2 относится к IPv6 и т.д.

Subsequent AFI нужны для уточнения назначения префиксов из MP_REACH_NLRI. Например, SAFI = 1 обозначает unicast-маршруты, префиксы из SAFI = 2 предназначены для проверок RPF, а SAFI = 3 позволяет использовать префикс для обеих целей.
Другой важный SAFI – SAFI = 128, который означает MPLS labeled VPN маршрут.
Напоминание: процесс BGP вычисляет лучший путь, сравнивая атрибуты для каждого семейства маршрутов (пара AFI/SAFI) независимо. Поскольку конкретный маршрутизатор может и не поддерживать определённые сетевые протоколы, список доступных AFI/SAFI должен быть обьявлен через BGP capabilities (ещё одно расширение BGP).
Маршрутная информация для сетевого протокола может быть передана по MP-BGP только в том случае, если оба маршрутизатора анонсируют поддержку этого протокола.

Route Distinguisher

• https://habr.com/ru/sandbox/99255/

Route Destingisher (дословно различитель маршрутов).
Route Distinguisher представляет из себя 64-битную последовательность вида type (2 байта):administrator(2 или 4 байта):value(4 или 2 байта).
Поле type указывает в каком формате будут следующие два поля, значения которых указаны ниже:

Или другой пример

Route Distinguisher: 10.80.6.52:1
     Network                                              Next Hop   Metric LocPrf   Weight Path Extended Community 
 *>i [2]:[2]:[48]:[ea:ed:c6:a3:48:00]                     10.80.6.52 200    100      0      ?    RT:64515:8000001 ET:8 UNK:6, 2 UNK:128, 113
 *=i [2]:[2]:[48]:[ea:ed:c6:a3:48:00]                     10.80.6.52 200    100      0      ?    RT:64515:8000001 ET:8 UNK:6, 2 UNK:128, 113 

К PE-маршрутизатору подключены два клиента, но есть проблема — оба клиента имеют одно и то же приватное адресное пространство — 10.0.0.0/24. Предположим что между CE1 и PE запущен OSPF, а между CE2 и PE — RIP.
На PE нам необходимо сделать перераспределение маршрутов из IGP протоколов в BGP, что бы передать маршруты клиентов на другие PE-маршрутизаторы. Для BGP это один и тот же префикс 10.0.0.0/24, поэтому перераспределен и анонсирован соседям по BGP будет только один лучший маршрут. Но нам то надо анонсировать оба маршрута.
Вот тут нам на помощь приходит Route Distinguisher.
Его единственной, но очень важной задачей является сделать заведомо не уникальный префикс уникальным. Получается это с помощью добавления 64-битного Route Distinguisher к искомому префиксу.
Ещё раз: RD — Route Distinguisher — его основная и единственная задача — сделать так, чтобы маршруты не смешались в MBGP — два одинаковых маршрута из разных VPN должны быть таки двумя разными маршрутами. RD не говорит PE, куда нужно экспортировать маршрут и существует/работает только при передаче маршрута.

Ссылки

• https://icebale.readthedocs.io/en/latest/networks/protocols-tech/BGP/BGP/
• https://habr.com/ru/articles/692230/