BGP EVPN: различия между версиями
Sirmax (обсуждение | вклад) |
Sirmax (обсуждение | вклад) |
||
| (не показано 13 промежуточных версий этого же участника) | |||
| Строка 42: | Строка 42: | ||
[Withdrawn prefixes (опционально)] + [Path Attributes] + [NLRI] |
[Withdrawn prefixes (опционально)] + [Path Attributes] + [NLRI] |
||
</PRE> |
</PRE> |
||
| − | <code>Withdrawn prefixes</code> и NLRI содержат префиксы IPv4, и их структура не |
+ | <code>Withdrawn prefixes</code> и <code>NLRI</code> содержат префиксы <code>IPv4</code>, и их структура не <BR> |
подразумевает поддержку иных протоколов. |
подразумевает поддержку иных протоколов. |
||
| + | <BR> |
||
| ⚫ | |||
| + | <BR> |
||
| + | <code>Path attributes</code> (например, <code>AS_PATH</code>, <code>ORIGIN</code>, <code>LOCAL_PREF</code>, <code>NEXT_HOP</code>) привязаны к <code>NLRI</code>; |
||
| ⚫ | |||
Также стоит отметить, что NEXT_HOP – это IPv4 адрес. |
Также стоит отметить, что NEXT_HOP – это IPv4 адрес. |
||
<BR> |
<BR> |
||
| + | <BR> |
||
| − | Чтобы реализовать в BGP поддержку протоколов, отличных от IPv4, |
+ | Чтобы реализовать в BGP поддержку протоколов, отличных от IPv4, |
| + | были добавлены два новых transitive атрибута. <BR> |
||
| + | <BR> |
||
Первый известен как MP_REACH_NLRI, который имеет следующую структуру: |
Первый известен как MP_REACH_NLRI, который имеет следующую структуру: |
||
[AFI/SAFI] + [NEXT_HOP] + [NLRI] |
[AFI/SAFI] + [NEXT_HOP] + [NLRI] |
||
| + | 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. |
||
| + | AFI/SAFI (Address Family Identifier и Subsequent Address Family Identifier, соответственно). |
||
| ⚫ | |||
| + | <BR> |
||
| − | Список поддерживаемых 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 маршрут. |
||
| + | К примеру, это может быть IPv4 префикс или CLNS.(CLNS (Connectionless Network Service) — протокол 3го уровня в стеке OSI, для передачи данных без установления соединения.) |
||
| − | Напоминание: процесс BGP вычисляет лучший путь, сравнивая атрибуты для каждого семейства маршрутов (пара AFI/SAFI) независимо. Поскольку конкретный маршрутизатор может и не поддерживать определённые сетевые протоколы, список доступных AFI/SAFI должен быть обьявлен через BGP capabilities (ещё одно расширение BGP). Маршрутная информация для сетевого протокола может быть передана по MP-BGP только в том случае, если оба маршрутизатора анонсируют поддержку этого протокола. |
||
| + | |||
| − | Обзор MDT SAFI |
||
| + | Таким образом, вся информация о не-IPv4 префиксах закодирована в новом BGP Path Attribute. |
||
| − | Cisco описала в черновике RFC новый SAFI, который может быть использован с обычным AFI, таким как IPv4 или IPv6. Этот SAFI нужен для передачи адреса MDT-группы, а также адресов loopback соответствующих PE. Формат для AFI = 1 (IPv4) следующий: |
||
| + | Типовое сообщение BGP Update, которое несёт MP_REACH_NLRI, не содержит в себе "классического" атрибута NEXT_HOP, |
||
| − | MP_NLRI = [RD:PE’s IPv4 Address]:[MDT Group Address] |
||
| + | Withdrawn Prefixes или NLRI, которые можно найти в обычном UPDATE-сообщении. |
||
| − | MP_NEXT_HOP = [BGP Peer IPv4 Address] |
||
| + | Для расчёта next-hop маршрутизатору следует использовать информацию из атрибута MP_REACH_NLRI. |
||
| − | Значение RD берётся из VRF, который использует MDT, а "IPv4 address" – адрес loopback соответствующего PE. По правилам Cisco это обычно тот же loopback, который используют для установления VPNv4-сессии, однако его можно и изменить командой bgp next-hop уровня VRF. |
||
| + | Тем не менее, MP-BGP UPDATE может нести остальные атрибуты BGP, такие как AS_PATH, ORIGIN, MED, LOCAL_PREF и т.д. |
||
| − | Если все 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 пришёл на смену этому временному решению. |
||
| + | Однако в этом случае атрибуты относятся к не-IPv4 префиксам из MP_REACH_NLRI. |
||
| − | Теперь представим ситуацию 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)-дерева. |
||
| + | |||
| + | Формат второго атрибута, MP_UNREACH_NLRI, похож на формат MP_REACH_NLRI; |
||
| + | он перечисляет те маршруты MP-BGP, которые подлежат удалению. |
||
| ⚫ | |||
| + | |||
| + | Список поддерживаемых AFI можно найти в RFC 1700 (несмотря на то, что он устарел, в нем можно найти много полезной информации). |
||
| + | * К примеру, AFI = 1 означает IPv4, |
||
| + | * AFI = 2 относится к IPv6 и т.д. |
||
| + | Subsequent AFI нужны для уточнения назначения префиксов из MP_REACH_NLRI. |
||
| + | Например, |
||
| + | SAFI = 1 обозначает unicast-маршруты, |
||
| + | префиксы из SAFI = 2 предназначены для проверок RPF, а |
||
| + | SAFI = 3 позволяет использовать префикс для обеих целей. |
||
| + | <BR> |
||
| + | Другой важный SAFI – SAFI = 128, который означает MPLS labeled VPN маршрут. |
||
| + | <BR> |
||
| + | Напоминание: процесс BGP вычисляет лучший путь, сравнивая атрибуты для каждого семейства маршрутов (пара AFI/SAFI) независимо. |
||
| + | Поскольку конкретный маршрутизатор может и не поддерживать определённые сетевые протоколы, список доступных AFI/SAFI должен быть обьявлен через BGP capabilities |
||
| + | (ещё одно расширение BGP). |
||
| + | <BR> |
||
| + | Маршрутная информация для сетевого протокола может быть передана по MP-BGP только в том случае, если оба маршрутизатора анонсируют поддержку этого протокола. |
||
| + | |||
| + | =Route Distinguisher= |
||
| + | * https://habr.com/ru/sandbox/99255/ |
||
| + | |||
| + | Route Destingisher (дословно различитель маршрутов). |
||
| + | <BR> |
||
| + | Route Distinguisher представляет из себя 64-битную последовательность вида type (2 байта):administrator(2 или 4 байта):value(4 или 2 байта). |
||
| + | <BR> |
||
| + | Поле type указывает в каком формате будут следующие два поля, значения которых указаны ниже: |
||
| + | <BR> |
||
| + | [[Файл:03-bgp-RD.png]] |
||
| + | <BR> |
||
| + | Или другой пример |
||
| + | <PRE> |
||
| + | 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 |
||
| + | </PRE> |
||
| + | <BR> |
||
| + | [[Файл:04-bgp-RD-02.jpeg]] |
||
| + | <BR> |
||
| + | |||
| + | К PE-маршрутизатору подключены два клиента, но есть проблема — оба клиента имеют одно и то же приватное адресное пространство — 10.0.0.0/24. |
||
| + | Предположим что между CE1 и PE запущен OSPF, а между CE2 и PE — RIP. |
||
| + | <BR> |
||
| + | На PE нам необходимо сделать перераспределение маршрутов из IGP протоколов в BGP, что бы передать маршруты клиентов на другие PE-маршрутизаторы. |
||
| + | Для BGP это один и тот же префикс 10.0.0.0/24, поэтому перераспределен и анонсирован соседям по BGP будет только один лучший маршрут. |
||
| + | Но нам то надо анонсировать оба маршрута. |
||
| + | <BR> |
||
| + | Вот тут нам на помощь приходит Route Distinguisher. |
||
| + | <BR> |
||
| + | Его единственной, но очень важной задачей является сделать заведомо не уникальный префикс уникальным. Получается это с помощью добавления 64-битного Route Distinguisher к искомому префиксу. |
||
| + | <BR> |
||
| + | Ещё раз: |
||
| + | RD — Route Distinguisher — его основная и единственная задача — сделать так, чтобы маршруты не смешались в MBGP — два одинаковых маршрута |
||
| + | из разных VPN должны быть таки двумя разными маршрутами. |
||
| + | RD не говорит PE, куда нужно экспортировать маршрут и существует/работает только при передаче маршрута. |
||
| + | <BR> |
||
=Ссылки= |
=Ссылки= |
||
Текущая версия на 16:25, 10 февраля 2025
Это страничка с терминологией которую нужно запомнить для понимание 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
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, куда нужно экспортировать маршрут и существует/работает только при передаче маршрута.
