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 (которых не было в изначальном стандарте BG)
появляется специальный 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. Таким образом, вся информация о не-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 только в том случае, если оба маршрутизатора анонсируют поддержку этого протокола.
Обзор MDT SAFI
Cisco описала в черновике RFC новый SAFI, который может быть использован с обычным AFI, таким как IPv4 или IPv6. Этот SAFI нужен для передачи адреса MDT-группы, а также адресов loopback соответствующих PE. Формат для AFI = 1 (IPv4) следующий:
MP_NLRI = [RD:PE’s IPv4 Address]:[MDT Group Address]
MP_NEXT_HOP = [BGP Peer IPv4 Address]
Значение RD берётся из VRF, который использует MDT, а "IPv4 address" – адрес loopback соответствующего PE. По правилам Cisco это обычно тот же loopback, который используют для установления VPNv4-сессии, однако его можно и изменить командой bgp next-hop уровня VRF.
Если все PE из локальной AS обменяются такой информацией и передадут её PIM SSM, то процесс P-PIM (Provider PIM, который смотрит в ядро провайдера) сможет построить (S,G) дерево для группы MDT в сторону IPv4 адресов других PE. Это возможно благодаря тому, что адреса всех PE известны через IGP, так как все PE находятся в одной AS. В таком случае не должно возникнуть каких-либо проблем с intra-AS mVPN + PIM-SSM из-за BGP-free ядра сети. Стоит отметить, что предшественником SAFI был специальный extended community в VPNv4 AF. MP-BGP использовал значение RD, равное 2 (невозможно в unicast VRF), для передачи адреса соответствующего PE, тогда как community переносил адрес MDT-группы. Это позволило передавать информацию для автонастройки сети в рамках одной AS, так как extended community был non-transitive. Черновик MDT SAFI пришёл на смену этому временному решению.
Теперь представим ситуацию Inter-AS VPN, где хотя бы одна AS использует BGP-free ядро. Как только соседние автономные системы активируют IPv4 MDT SAFI, ASBR обменяются между собой всей информацией, полученной от PE, а затем распространят её в своей AS. После этого процесс P-PIM попробует построить (S,G)-дерево до IP-адресов PE, находящихся в другой AS. Несмотря на то, что PE могут знать адреса PE из соседних AS (например, в случае Inter-AS VPN Option C), P-маршрутизаторы не обладают такой информацией. В случае же Inter-AS VPN Option B даже у PE-маршрутизаторов не будет достаточно информации для построения (S,G)-дерева.
