BGP EVPN FRR simple: различия между версиями

Материал из noname.com.ua
Перейти к навигацииПерейти к поиску
 
(не показаны 73 промежуточные версии этого же участника)
Строка 4: Строка 4:
 
[[Категория:FRR]]
  
[[Категория:FRR]]
   
  +
−
[[BGP_EVPN_FRR_simple#PE]]
  
 
=Минимальная конфигурация EVPN по шагам=
  
=Минимальная конфигурация EVPN по шагам=
 
Это документ о настройке абсолютно минимальной конфигурации EVPN
  
Это документ о настройке абсолютно минимальной конфигурации EVPN
   
 
=Сокращения использованные в документе=
  
=Сокращения использованные в документе=
−
==PE==
 +
==<code>PE</code>==
−
* Provider Edge - Маршрутизатор провайдера к которому подключены клиенты
+
* <code>[[BGP_EVPN_FRR_simple#PE|PE]]</code>: Provider Edge - Маршрутизатор провайдера к которому подключены клиенты
  +
−
==CE==
  
  +
==<code>CE</code>==
−
* Client Edge - Маршрутизатор клиента который подключен к провайдеру
  
  +
* <code>[[BGP_EVPN_FRR_simple#CE|CE]]</code>: Client Edge - Маршрутизатор клиента который подключен к провайдеру
  +
  +
==<code>[[BGP_EVPN_FRR_simple#BUM|BUM]]</code>==
  +
Broadcast / Unknown Unicast / Multicast (<code>[[BGP_EVPN_FRR_simple#BUM|BUM]]</code>) - тип трафика, который обычно требует рассылки нескольким получателям, из-за чего потенциально может создавать дополнительную нагрузку на сеть.
  +
<BR>
  +
Примером такой нагрузки можно считать <code>Broadcast Storm</code>
  +
==[[BGP_EVPN_FRR_simple#VTEP|VTEP]]==
  +
<code>[[BGP_EVPN_FRR_simple#VTEP|VTEP]]</code> - Virtual Tunnel End Point, кончная точка тунеля - устройство на котором начинается или заканчивается тунель, в этой статье в качестве
  +
<code>[[BGP_EVPN_FRR_simple#VTEP|VTEP]]</code> выступают 2 маршрутизатора - <code>FRR1</code> и <code>FRR2</code>. В других конфигурациях (например в случае с <code>Calico</code>) в качестве <code>[[BGP_EVPN_FRR_simple#VTEP|VTEP]]</code> могут выступать, например worker-ноды kubernetes кластера.
  +
  +
==<code>[[BGP_EVPN_FRR_simple#VNI|VNI]]</code>==
  +
<code>[[BGP_EVPN_FRR_simple#VNI|VNI]]</code> - VxLAN Network Identifier - идентификатор различных сетей VxLAN (в пределах одного <code>[[BGP_EVPN_FRR_simple#VTEP|VTEP]]</code>). Для упрощения, про <code>[[BGP_EVPN_FRR_simple#VNI|VNI]]</code> можно думать как про <code>Vlan Id</code>, <code>[[BGP_EVPN_FRR_simple#VNI|VNI]]</code> должны быть уникальны в <code>EVPN</code> сети, точно так же как <code>Vlan Id</code> должны быть уникальны в классических сетях. В целом, назначаются произвольно, так же как и <code>Vlan Id</code>
   
 
=Схема сети=
  
=Схема сети=
Строка 24: Строка 36:
 
На этой схеме:
  
На этой схеме:
 
* 2 маршрутизатора <code>FRR</code> выполняют роли <code>[[BGP_EVPN_FRR_simple#PE|PE]]</code>
  
* 2 маршрутизатора <code>FRR</code> выполняют роли <code>[[BGP_EVPN_FRR_simple#PE|PE]]</code>
−
** Сеть <code>tenant используется как транспортная сеть между маршрутизаторами (<code>l2</code> сегмент)
 +
** Сеть <code>tenant</code> используется как транспортная сеть между маршрутизаторами (<code>l2</code> сегмент)
−
** Каждый из [[BGP_EVPN_FRR_simple#PE|PE]] имеет по 1 подключеному CE (Client Edge, маршрутизатор клиента подключенный к оборудованию провайдера)
 +
** Каждый из [[BGP_EVPN_FRR_simple#PE|PE]] имеет по 1 подключеному <code>[[BGP_EVPN_FRR_simple#CE|CE]]</code>
−
** CE максимально упрощены - это просто IP адрес поднятый на бридже (но конечно ничто не мешает использовать отдельную виртуальную машину, разницы нет)
 +
** <code>[[BGP_EVPN_FRR_simple#CE|CE]]</code> максимально упрощены - это просто <code>IP</code> адрес поднятый на бридже (но конечно ничто не мешает использовать отдельную виртуальную машину, разницы нет)
−
* Используется 1 интерфейс для поддключения CE
 +
* Используется 1 интерфейс для поддключения <code>[[BGP_EVPN_FRR_simple#CE|CE]]</code>
−
* Номер <code>VNI</code> (<code>VxLAN</code> Network Identifier) выбран абсолютно произвольно, такое значение взято что бы оно случайно не совпало ни с каким другим и было заведомо больше максимального номера влана
 +
* Номер <code>[[BGP_EVPN_FRR_simple#VNI|VNI]]</code> выбран абсолютно произвольно, такое значение взято что бы оно случайно не совпало ни с каким другим и было заведомо больше максимального номера влана
 
* Management сеть используется только для управлени маршрутизаторами (без нее можно обойтись, она не учавствует маршрутизации) Интерфейсы в этой сети названы <code>external</code> по историческим причинам.
  
* Management сеть используется только для управлени маршрутизаторами (без нее можно обойтись, она не учавствует маршрутизации) Интерфейсы в этой сети названы <code>external</code> по историческим причинам.
 
* Интерфейсы <code>loopback</code> изспользуются для построения сессий BGP
  
* Интерфейсы <code>loopback</code> изспользуются для построения сессий BGP
Строка 87: Строка 99:
   
 
=Настройка демона FRR=
  
=Настройка демона FRR=
−
Эта часть разделена на 2 части - не относящееся к EVPN выжелено в отдельную часть
 +
Эта часть разделена на 2 части - не относящееся к <code>EVPN</code> выделено в отдельную часть
   
 
==Подготовительная настройка==
  
==Подготовительная настройка==
−
* Запустить OSPF в сети tenant для того что бы получить доступность интерфейсов loopback
 +
* Запустить <code>OSPF</code> в сети tenant для того что бы получить доступность интерфейсов <code>loopback</code>
−
* сделать редистрибьюцию маршрутов в OSPF (не уверене что нужно делать все три - static connected и kernel даже скорее всего нет)
 +
* сделать редистрибьюцию маршрутов в OSPF (не уверене что нужно делать все три - <code>static</code>, <code>connected</code> и <code>kernel</code> даже скорее всего нет, но этот вопрос не относится к теме статьи)
−
* тут можно вполне обойтись статикой без OSPF но так сделано для большей "достоверности"
 +
* тут можно вполне обойтись статикой без <code>OSPF</code> но так сделано для большей "достоверности" - как у настоящих провайдеров.
   
 
<BR>
  
<BR>
−
Немного заметок про настройку OSPF:
 +
Немного заметок про настройку <code>OSPF</code>:
 
* <code>prefix-list REDISTRIBUTE- ... </code> - префикс-листы что бы ограничить редистрибьюцию в OSPF только /32 (ge) сетями из диапазона <code>192.168.32.0/24</code>
  
* <code>prefix-list REDISTRIBUTE- ... </code> - префикс-листы что бы ограничить редистрибьюцию в OSPF только /32 (ge) сетями из диапазона <code>192.168.32.0/24</code>
−
* В работе OSPF учавствует только интерфейс <code>tenant</code> ( <code>no ip ospf passive</code>, <code>passive-interface defaul</code>)
 +
* В работе <code>OSPF</code> учавствует только интерфейс <code>tenant</code> ( <code>no ip ospf passive</code>, <code>passive-interface defaul</code>)
   
 
===FRR1 OSPF===
  
===FRR1 OSPF===
Строка 238: Строка 250:
 
=EVPN=
  
=EVPN=
 
==Cхема работы (приблизительная==
  
==Cхема работы (приблизительная==
−
<TODO>
  
−  
 
Существует два типа информации о доступности сети, которую VTEP передает через BGP EVPN:
  
Существует два типа информации о доступности сети, которую VTEP передает через BGP EVPN:
   
−
* VNI, в которых они заинтересованы (маршруты L3)
 +
* <code>[[BGP_EVPN_FRR_simple#VNI|VNI]]</code>, в которых они заинтересованы (маршруты L2???)
−
* локальный MAC-адрес для каждого VNI (маршруты L2)
 +
* локальный MAC-адрес для каждого <code>[[BGP_EVPN_FRR_simple#VNI|VNI]]</code> (маршруты L2)
   
−
==Начальная настройка BGP==
 +
==Начальная настройка <code>BGP</code>==
−
На начальном этапе в конфигурации отсутствуют VxLAN интерфейсы, пока просто проверка что BGP-сессия поднимаются нормально.
 +
На начальном этапе в конфигурации отсутствуют <code>VxLAN</code> интерфейсы, пока просто проверка что <code>BGP</code>-сессия поднимаются нормально.
   
−
* В качестве адреса используется интерфейс loopback - так как он всегда поднят, не зависит от физического состояния линка (адрес на нем может быть доступен через несколько линков в общем случае, при наличии динамической маршрутизации, это общаяя практика)
 +
* В качестве адреса используется интерфейс <code>loopback</code> - так как он всегда поднят, не зависит от физического состояния линка (адрес на нем может быть доступен через несколько линков в общем случае, при наличии динамической маршрутизации, это общаяя практика)
−
* Номер AS - 65000 из частного диапазона, одинаковый на обоих маршрутизаторах
 +
* Номер <code>AS</code> - 65000 из частного диапазона, одинаковый на обоих маршрутизаторах
 
* <code>neighbor fabric peer-group</code> - не смотря на то что у нас всего один neighbor описываем группу - так проще будет расширять
 
* <code>neighbor fabric peer-group</code> - не смотря на то что у нас всего один neighbor описываем группу - так проще будет расширять
−
* bgp router-id 192.168.32.101 - задать идентификатор роутера (что бы он был однозначен а не выбран автоматически)
 +
* <code>bgp router-id 192.168.32.101</code> - задать идентификатор роутера (что бы он был однозначен а не выбран автоматически)
−
* neighbor fabric update-source 192.168.32.101 - указать с какого адреса отправлять обновления. Если этого не сделать то будет выбран адрес интерфейса, в результате пакеты будут уходить не с тем адресом который ожидает сосед, и сессия не поднимется. ("костыль" тут это использовать адреса интерфейсов)
 +
* <code>neighbor fabric update-source 192.168.32.101</code> - указать с какого адреса отправлять обновления. Если этого не сделать то будет выбран адрес интерфейса, в результате пакеты будут уходить не с тем адресом который ожидает сосед, и сессия не поднимется. ("костыль" тут это использовать адреса интерфейсов)
   
 
===FRR1===
  
===FRR1===
Строка 288: Строка 298:
 
</PRE>
  
</PRE>
   
−
==Проверка BGP==
 +
==Проверка <code>BGP</code>==
   
 
<code>frr1# show bgp summary</code>
  
<code>frr1# show bgp summary</code>
Строка 305: Строка 315:
 
</PRE>
  
</PRE>
   
−
L2EVPN не является IP что можно видеть по ошибке ниже:
 +
<code>L2EVPN</code> не является IP что можно видеть по ошибке ниже:
 
<BRE>
  
<BRE>
 
<code>frr1# sho ip bgp summary</code>
  
<code>frr1# sho ip bgp summary</code>
Строка 320: Строка 330:
 
</PRE>
  
</PRE>
   
−
==Добавление конечных точек VTEP==
 +
==Добавление конечных точек <code>VTEP</code>==
 
'''Для начала добвляются конечные точки только на одно роутере - FRR1'''
  
'''Для начала добвляются конечные точки только на одно роутере - FRR1'''
   
 
Для добавления VTEP используется скрипт, рассчитаный на добавление множества VTEP но в целях упрощения добавляем только один.
  
Для добавления VTEP используется скрипт, рассчитаный на добавление множества VTEP но в целях упрощения добавляем только один.
−
* seq 11025 11025 даст список из 1 элемента - 11025
 +
* <code>seq 11025 11025</code> даст список из 1 элемента - 11025
−
* LOCAL_IP="192.168.32.101" - source-адрес VxLAN-тунелей (loopback, причины его использования такие же как и для BGP)
 +
* <code>LOCAL_IP="192.168.32.101"</code> - source-адрес <code>VxLAN</code>-тунелей (<code>loopback</code>, причины его использования такие же как и для BGP)
−
* для FRR2 LOCAL_IP="192.168.32.102"
 +
* для FRR2 <code>LOCAL_IP="192.168.32.102"</code>
 
<PRE>
  
<PRE>
 
#!/bin/bash
  
#!/bin/bash
Строка 351: Строка 361:
 
link/ether 66:f8:b3:52:6b:af brd ff:ff:ff:ff:ff:ff
  
link/ether 66:f8:b3:52:6b:af brd ff:ff:ff:ff:ff:ff
 
</PRE>
  
</PRE>
−
<PRE>
  
−
# brctl show
  
   
  +
<code># brctl show</code>
  +
<PRE>
 
bridge name bridge id STP enabled interfaces
  
bridge name bridge id STP enabled interfaces
 
br-vni11025 8000.5e240380730e no vxlan11025
  
br-vni11025 8000.5e240380730e no vxlan11025
 
</PRE>
  
</PRE>
   
−
==BGP после добавления конечных точек==
 +
==<code>BGP</code> после добавления конечных точек==
   
−
Можно увидеть доступный VNI (номер его 11025 ожидаемо совпадает с добавленным)
 +
Можно увидеть доступный <code>VNI</code> (номер его 11025 ожидаемо совпадает с добавленным)
  +
<BR>
 
<code>show bgp evpn vni</code>
  
<code>show bgp evpn vni</code>
 
<PRE>
  
<PRE>
Строка 375: Строка 386:
 
</PRE>
  
</PRE>
 
<BR>
  
<BR>
−
Однако маршрут в BGP отсутвует (<code>show bgp evpn route</code>)
 +
Однако маршрут в <code>BGP</code> отсутвует (<code>show bgp evpn route</code>)
 
<BR>
  
<BR>
 
Для того что бы маршрут появился требуется добавить строчку в конфигурацию
  
Для того что бы маршрут появился требуется добавить строчку в конфигурацию
Строка 386: Строка 397:
 
</PRE>
  
</PRE>
   
−
После чего маршрут появляется в BGP
 +
После чего маршрут появляется в <code>BGP</code>
 
{{caution|text=
  
{{caution|text=
−
В случае нескольких VNI анонсированны будут все
 +
В случае нескольких <code>[[BGP_EVPN_FRR_simple#VNI|VNI]]</code> анонсированны будут все
 
}}
  
}}
  +
  +
{{caution|text=
  +
Как фильтровать какие <code>[[BGP_EVPN_FRR_simple#VNI|VNI]]</code> анонсировать, а какие нет - пока не ясно, эта часть будет дополнена позже.
  +
}}
  +
 
===Маршруты===
  
===Маршруты===
  +
  +
<code>show bgp evpn route</code>
  +
 
<PRE>
  
<PRE>
−
show bgp evpn route
  
 
BGP table version is 3, local router ID is 192.168.32.101
  
BGP table version is 3, local router ID is 192.168.32.101
 
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
  
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Строка 440: Строка 458:
 
* <code>Advertised to non peer-group peers: 192.168.32.102</code> - информация о том кому анонсируется маршрут
  
* <code>Advertised to non peer-group peers: 192.168.32.102</code> - информация о том кому анонсируется маршрут
 
* <code>Route [3]:[0]:[32]:[192.168.32.101] VNI 11025 </code>
 
* <code>Route [3]:[0]:[32]:[192.168.32.101] VNI 11025 </code>
−
** <code>VNI 11025</code> - Номер VNI
+
** <code>VNI 11025</code> - Номер <code>[[BGP_EVPN_FRR_simple#VNI|VNI]]</code>
 
* <code>Origin IGP, weight 32768, valid, sourced, local, best (First path received)</code> источник маршрута - Internal Gateway Protocol
  
* <code>Origin IGP, weight 32768, valid, sourced, local, best (First path received)</code> источник маршрута - Internal Gateway Protocol
 
* <code>Extended Community: ET:8 RT:65000:11025 </code>
  
* <code>Extended Community: ET:8 RT:65000:11025 </code>
Строка 447: Строка 465:
 
* <code>Last update: Thu Feb 13 10:52:39 2025 </code> - Очевидно?
  
* <code>Last update: Thu Feb 13 10:52:39 2025 </code> - Очевидно?
 
* <code>PMSI Tunnel Type: Ingress Replication, label: 11025 </code>
 
* <code>PMSI Tunnel Type: Ingress Replication, label: 11025 </code>
−
** <code>label: 11025</code> - VNI 11025
 +
** <code>label: 11025</code> - <code>[[BGP_EVPN_FRR_simple#VNI|VNI]]</code> 11025
   
 
{{caution|text=
  
{{caution|text=
−
Обратить внимание - это маршрут типа 3 и значит он применим только для '''B'''roadcast / '''U'''nknown Unicast / '''M'''ulticast ('''BUM''') трафика
 +
Обратить внимание - это маршрут типа 3 и значит он применим только для '''B'''roadcast / '''U'''nknown Unicast / '''M'''ulticast (<code>[[BGP_EVPN_FRR_simple#BUM|BUM]]</code>) трафика
 
}}
  
}}
  +
−
==Добавление VNI на втором роутере (FFR2)==
  
  +
==Добавление <code>[[BGP_EVPN_FRR_simple#VNI|VNI]]</code> на втором роутере (FFR2)==
   
 
После добавлениея интерфейса на втором роутере (тем же скриптом) и активации опции <code>advertise-all-vni</code> ожидаемо появляется второй маршрут (зеркальный по отношению к первому)
  
После добавлениея интерфейса на втором роутере (тем же скриптом) и активации опции <code>advertise-all-vni</code> ожидаемо появляется второй маршрут (зеркальный по отношению к первому)
Строка 468: Строка 487:
 
</PRE>
  
</PRE>
   
−
==Проверка работы BUM трафика==
 +
==Проверка работы <code>[[BGP_EVPN_FRR_simple#BUM|BUM]]</code> трафика==
 
После того как в таблице маршрутизации присутвует 2 маршрута (прямой и обратный) [[BGP_EVPN_route_types#.D0.A2.D0.B8.D0.BF_3|Типа 3]] ожидается что по ним можно будет отправлять например широковещательный трафик
  
После того как в таблице маршрутизации присутвует 2 маршрута (прямой и обратный) [[BGP_EVPN_route_types#.D0.A2.D0.B8.D0.BF_3|Типа 3]] ожидается что по ним можно будет отправлять например широковещательный трафик
 
<BR>
  
<BR>
Строка 512: Строка 531:
 
17:34:38.130696 5e:24:03:80:73:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.99.1 tell 192.168.99.2, length 28
  
17:34:38.130696 5e:24:03:80:73:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.99.1 tell 192.168.99.2, length 28
 
</PRE>
  
</PRE>
−
А на бридже есть как запросы так и ответы - но так как маршрут типа 3 только для '''BUM'''- трафика то ответы никуда дальше бриджа не уходят
+
А на бридже есть как запросы так и ответы - но так как маршрут типа 3 только для <code>[[BGP_EVPN_FRR_simple#BUM|BUM]]</code> - трафика то ответы никуда дальше бриджа не уходят
 
<PRE>
  
<PRE>
 
tcpdump -n -ee -i br-vni11025
  
tcpdump -n -ee -i br-vni11025
Строка 526: Строка 545:
 
}}
  
}}
   
−
==Подключение виртуальных CE==
 +
==Подключение виртуальных <code>[[BGP_EVPN_FRR_simple#CE|CE]]</code>==
−
Для имитации CE я не буду создавать виртуальные машины, а использую просто veth один из которых включая в бридж, а второй "как бы" и есть CE
 +
Для имитации <code>[[BGP_EVPN_FRR_simple#CE|CE]]</code> я не буду создавать виртуальные машины, а использую просто veth один из которых включая в бридж, а второй "как бы" и есть <code>[[BGP_EVPN_FRR_simple#CE|CE]]</code>
 
<BR>
  
<BR>
 
===FRR2===
  
===FRR2===
Строка 548: Строка 567:
 
</PRE>
  
</PRE>
   
−
Назначим адрес виртуальном CE2
+
Назначим адрес виртуальном <code>[[BGP_EVPN_FRR_simple#CE|CE2]]</code>
 
<PRE>
  
<PRE>
 
ip addr add 192.168.98.2/24 dev ce2
  
ip addr add 192.168.98.2/24 dev ce2
Строка 641: Строка 660:
 
* <code>[2]</code> означает, что это Type 2 (MAC/IP Advertisement Route).
 
* <code>[2]</code> означает, что это Type 2 (MAC/IP Advertisement Route).
 
* <code>[EthTag]</code> Ethernet Tag ID (обычно = 0 для VXLAN). В примере это тоже 0
  
* <code>[EthTag]</code> Ethernet Tag ID (обычно = 0 для VXLAN). В примере это тоже 0
−
* <code>[MAC]</code> MAC-адрес хоста. В примере это <code>ce:3b:3b:dc:8d:29</code> что соотвтевует мак-адресу "виртуального CE2":
 +
* <code>[MAC]</code> MAC-адрес хоста. В примере это <code>ce:3b:3b:dc:8d:29</code> что соотвтевует мак-адресу "виртуального <code>[[BGP_EVPN_FRR_simple#CE|CE2]]</code>":
 
<PRE>
  
<PRE>
 
ip link show dev ce2
  
ip link show dev ce2
Строка 709: Строка 728:
 
На всякий случай можно сравнить МАК-адреса
  
На всякий случай можно сравнить МАК-адреса
 
<BR>
  
<BR>
−
frr1 - интерфейс (виртуального): CE
 +
frr1 - интерфейс (виртуального) <code>[[BGP_EVPN_FRR_simple#CE|CE]]</code>
 
<PRE>
  
<PRE>
 
root@frr1:/etc/frr# ip link show dev ce1
  
root@frr1:/etc/frr# ip link show dev ce1
Строка 721: Строка 740:
 
192.168.32.102 100 0 i
  
192.168.32.102 100 0 i
 
</PRE>
  
</PRE>
−
frr2 - интерфейс (виртуального): CE
 +
frr2 - интерфейс (виртуального) <code>[[BGP_EVPN_FRR_simple#CE|CE]]</code>
 
<PRE>
  
<PRE>
 
9: ce2@pe2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
  
9: ce2@pe2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
Строка 733: Строка 752:
 
ET:8 RT:65000:11025
  
ET:8 RT:65000:11025
 
</PRE>
  
</PRE>
  +
===Мак-адреса <code>[[BGP_EVPN_FRR_simple#CE|CE]]</code>===
  +
Для того что бы проще пониммать что за трафик видно в <code>tcpdump</code> выделю еще раз мак-адреса
  +
====MAC/IP <code>[[BGP_EVPN_FRR_simple#CE|CE1]]</code> <code>a2:54:55:00:6d:09</code> <code>192.168.98.1</code>====
  +
<PRE>
  +
ip addr show dev ce1
  +
9: ce1@pe1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
  +
link/ether a2:54:55:00:6d:09 brd ff:ff:ff:ff:ff:ff
  +
inet 192.168.98.1/24 scope global ce1
  +
valid_lft forever preferred_lft forever
  +
inet6 fe80::a054:55ff:fe00:6d09/64 scope link
  +
valid_lft forever preferred_lft forever
  +
</PRE>
  +
  +
====MAC/IP <code>[[BGP_EVPN_FRR_simple#CE|CE2]]</code> <code>ce:3b:3b:dc:8d:29</code> <code>192.168.98.2</code>====
  +
<PRE>
  +
9: ce2@pe2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
  +
link/ether ce:3b:3b:dc:8d:29 brd ff:ff:ff:ff:ff:ff
  +
inet 192.168.98.2/24 scope global ce2
  +
valid_lft forever preferred_lft forever
  +
inet6 fe80::cc3b:3bff:fedc:8d29/64 scope link
  +
valid_lft forever preferred_lft forever
  +
</PRE>
  +
  +
=Проверка прохождения трафика для одного <code>[[BGP_EVPN_FRR_simple#VNI|VNI]]</code>=
  +
  +
Для проверки запускаем пиинг с одного виртуального <code>[[BGP_EVPN_FRR_simple#CE|CE]]</code> : CE1 "подключенного" к <code>FRR1</code>
  +
<BR>
  +
В это же время наблюдаем прохлжение трафика на всех интерфейсах обоих маршрутизаторов:
  +
  +
<code>FRR1</code>:
  +
* <code>ce1</code>
  +
* <code>pe1</code> (второй конец виртуального патч-корда)
  +
* <code>br-vni11025</code>
  +
* <code>vxlan11025</code>
  +
* <code>tenant</code> (напоминание - так назван eth интерфейс в этой лабе, если бы это была не виртуальная машина а физический маршрутизатор то это была бы "реальная", не виртуальная, сетевая карта
  +
  +
  +
  +
  +
==<code>ping</code> <code>[[BGP_EVPN_FRR_simple#CE|CE1]]</code> -> <code>[[BGP_EVPN_FRR_simple#CE|CE2]]</code>==
  +
Запускаем пинг с <code>[[BGP_EVPN_FRR_simple#CE|CE1]]</code>, подключенный к <code>FRR1</code> и имеющий IP адрес <code>192.168.98.2</code><BR>
  +
на <code>[[BGP_EVPN_FRR_simple#CE|CE2]]</code> подключенный к <code>FRR2</code> и имеющий IP адрес <code>192.168.98.2</code>
  +
<PRE>
  +
ping -c2 192.168.98.2
  +
PING 192.168.98.2 (192.168.98.2) 56(84) bytes of data.
  +
64 bytes from 192.168.98.2: icmp_seq=1 ttl=64 time=0.905 ms
  +
64 bytes from 192.168.98.2: icmp_seq=2 ttl=64 time=0.363 ms
  +
</PRE>
  +
  +
==<code>ce1</code>==
  +
Трафик уходит с интерфейса <code>ce1</code> - который в лабе представляет собой интерфейс виртуального <code>[[BGP_EVPN_FRR_simple#CE|CE1]]</code>
  +
<BR>
  +
<code>root@frr1:~# tcpdump -ee -n -i ce1 -v</code>
  +
<BR>
  +
<PRE>
  +
14:17:28.543746 a2:54:55:00:6d:09 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.98.2 tell 192.168.98.1, length 28
  +
14:17:28.544437 ce:3b:3b:dc:8d:29 > a2:54:55:00:6d:09, ethertype ARP (0x0806), length 42: Reply 192.168.98.2 is-at ce:3b:3b:dc:8d:29, length 28
  +
14:17:28.544442 a2:54:55:00:6d:09 > ce:3b:3b:dc:8d:29, ethertype IPv4 (0x0800), length 98: 192.168.98.1 > 192.168.98.2: ICMP echo request, id 7024, seq 1, length 64
  +
14:17:28.544624 ce:3b:3b:dc:8d:29 > a2:54:55:00:6d:09, ethertype IPv4 (0x0800), length 98: 192.168.98.2 > 192.168.98.1: ICMP echo reply, id 7024, seq 1, length 64
  +
14:17:29.545263 a2:54:55:00:6d:09 > ce:3b:3b:dc:8d:29, ethertype IPv4 (0x0800), length 98: 192.168.98.1 > 192.168.98.2: ICMP echo request, id 7024, seq 2, length 64
  +
14:17:29.545599 ce:3b:3b:dc:8d:29 > a2:54:55:00:6d:09, ethertype IPv4 (0x0800), length 98: 192.168.98.2 > 192.168.98.1: ICMP echo reply, id 7024, seq 2, length 64
  +
14:17:33.620753 ce:3b:3b:dc:8d:29 > a2:54:55:00:6d:09, ethertype ARP (0x0806), length 42: Request who-has 192.168.98.1 tell 192.168.98.2, length 28
  +
14:17:33.620765 a2:54:55:00:6d:09 > ce:3b:3b:dc:8d:29, ethertype ARP (0x0806), length 42: Reply 192.168.98.1 is-at a2:54:55:00:6d:09, length 28
  +
</PRE>
  +
  +
Тут видно что сначала идет <code>ARP</code>-запрос и потом нормальный обмен трафиком между
  +
<code>[[BGP_EVPN_FRR_simple#MAC.2FIP_CE1_a2:54:55:00:6d:09_192.168.98.1|a2:54:55:00:6d:09]]</code>
  +
и
  +
<code>[[BGP_EVPN_FRR_simple#MAC.2FIP_CE2_ce:3b:3b:dc:8d:29_192.168.98.2|ce:3b:3b:dc:8d:29]]</code>
  +
  +
==<code>pe1</code> (второй конец виртуального патч-корда)==
  +
Далее трафик попадает на интерфейс <code>pe1</code> который представляет интерфейс <code>[[BGP_EVPN_FRR_simple#PE|PE1]]</code>
  +
<BR>
  +
  +
<code>tcpdump -ee -n -i pe1</code>
  +
<PRE>
  +
listening on pe1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
  +
14:17:28.543751 a2:54:55:00:6d:09 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.98.2 tell 192.168.98.1, length 28
  +
14:17:28.544436 ce:3b:3b:dc:8d:29 > a2:54:55:00:6d:09, ethertype ARP (0x0806), length 42: Reply 192.168.98.2 is-at ce:3b:3b:dc:8d:29, length 28
  +
14:17:28.544442 a2:54:55:00:6d:09 > ce:3b:3b:dc:8d:29, ethertype IPv4 (0x0800), length 98: 192.168.98.1 > 192.168.98.2: ICMP echo request, id 7024, seq 1, length 64
  +
14:17:28.544623 ce:3b:3b:dc:8d:29 > a2:54:55:00:6d:09, ethertype IPv4 (0x0800), length 98: 192.168.98.2 > 192.168.98.1: ICMP echo reply, id 7024, seq 1, length 64
  +
14:17:29.545271 a2:54:55:00:6d:09 > ce:3b:3b:dc:8d:29, ethertype IPv4 (0x0800), length 98: 192.168.98.1 > 192.168.98.2: ICMP echo request, id 7024, seq 2, length 64
  +
14:17:29.545598 ce:3b:3b:dc:8d:29 > a2:54:55:00:6d:09, ethertype IPv4 (0x0800), length 98: 192.168.98.2 > 192.168.98.1: ICMP echo reply, id 7024, seq 2, length 64
  +
14:17:33.620749 ce:3b:3b:dc:8d:29 > a2:54:55:00:6d:09, ethertype ARP (0x0806), length 42: Request who-has 192.168.98.1 tell 192.168.98.2, length 28
  +
14:17:33.620766 a2:54:55:00:6d:09 > ce:3b:3b:dc:8d:29, ethertype ARP (0x0806), length 42: Reply 192.168.98.1 is-at a2:54:55:00:6d:09, length 28
  +
</PRE>
  +
  +
==<code>br-vni11025</code>==
  +
Так как инерфейс <code>pe1</code> включен в интерфейс <code>br-vni11025</code> то дальше трафик сожно наблюдать на бридже:
  +
<BR>
  +
<code>root@frr1:~# tcpdump -n -ee -i br-vni11025</code>
  +
  +
<PRE>
  +
14:17:28.543751 a2:54:55:00:6d:09 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.98.2 tell 192.168.98.1, length 28
  +
14:17:28.544413 ce:3b:3b:dc:8d:29 > a2:54:55:00:6d:09, ethertype ARP (0x0806), length 42: Reply 192.168.98.2 is-at ce:3b:3b:dc:8d:29, length 28
  +
14:17:28.544442 a2:54:55:00:6d:09 > ce:3b:3b:dc:8d:29, ethertype IPv4 (0x0800), length 98: 192.168.98.1 > 192.168.98.2: ICMP echo request, id 7024, seq 1, length 64
  +
14:17:28.544617 ce:3b:3b:dc:8d:29 > a2:54:55:00:6d:09, ethertype IPv4 (0x0800), length 98: 192.168.98.2 > 192.168.98.1: ICMP echo reply, id 7024, seq 1, length 64
  +
14:17:29.545271 a2:54:55:00:6d:09 > ce:3b:3b:dc:8d:29, ethertype IPv4 (0x0800), length 98: 192.168.98.1 > 192.168.98.2: ICMP echo request, id 7024, seq 2, length 64
  +
14:17:29.545584 ce:3b:3b:dc:8d:29 > a2:54:55:00:6d:09, ethertype IPv4 (0x0800), length 98: 192.168.98.2 > 192.168.98.1: ICMP echo reply, id 7024, seq 2, length 64
  +
14:17:33.620718 ce:3b:3b:dc:8d:29 > a2:54:55:00:6d:09, ethertype ARP (0x0806), length 42: Request who-has 192.168.98.1 tell 192.168.98.2, length 28
  +
14:17:33.620766 a2:54:55:00:6d:09 > ce:3b:3b:dc:8d:29, ethertype ARP (0x0806), length 42: Reply 192.168.98.1 is-at a2:54:55:00:6d:09, length 28
  +
</PRE>
  +
  +
<code> brctl showmacs br-vni11025 </code>
  +
<PRE>
  +
port no mac addr is local? ageing timer
  +
1 66:f8:b3:52:6b:af yes 0.00
  +
1 66:f8:b3:52:6b:af yes 0.00
  +
2 6e:2d:c8:13:c4:13 yes 0.00
  +
2 6e:2d:c8:13:c4:13 yes 0.00
  +
2 a2:54:55:00:6d:09 no 0.76
  +
1 ce:3b:3b:dc:8d:29 no 11312.96
  +
1 ce:3b:3b:dc:8d:29 no 0.76
  +
</PRE>
  +
Тут не указаны интерфейсы - а только номера портов, определить номера можно командой
  +
<code>brctl showstp br-vni11025 </code>
  +
<BR>
  +
Для простоты отфильтрую лишнее: <BR>
  +
<code>brctl showstp br-vni11025 | grep -E '\([0-9]\)'</code>
  +
<PRE>
  +
pe1 (2)
  +
vxlan11025 (1)
  +
</PRE>
  +
Если подставить имена интерфейсов то таблица приобретет вид:
  +
<BR>
  +
<code>pe1 (2) a2:54:55:00:6d:09 no 0.76</code><BR>
  +
<code>vxlan11025 (1)[[BGP_EVPN_FRR_simple#MAC.2FIP_CE2_ce:3b:3b:dc:8d:29_192.168.98.2|ce:3b:3b:dc:8d:29]] no 11312.96</code><BR>
  +
===Альтернативный способ===
  +
Проверить таблицы коммутации бриджа
  +
<code>bridge -d fdb show dev br-vni11025</code> <code>br-vni11025</code>
  +
<PRE>
  +
5e:24:03:80:73:0e vlan 1 master br-vni11025 permanent
  +
5e:24:03:80:73:0e master br-vni11025 permanent
  +
</PRE>
  +
Тут не видно мак-адресов отправителя и получателя - <code>[[BGP_EVPN_FRR_simple#MAC.2FIP_CE1_a2:54:55:00:6d:09_192.168.98.1|a2:54:55:00:6d:09]]</code>
  +
и <code>[[BGP_EVPN_FRR_simple#MAC.2FIP_CE2_ce:3b:3b:dc:8d:29_192.168.98.2|ce:3b:3b:dc:8d:29]]</code>
  +
  +
<BR>
  +
Более правильно смотреть полную таблицу коммутации - тогда можно увидеть
  +
<PRE>
  +
bridge fdb show | grep -E 'ce:3b:3b:dc:8d:29|a2:54:55:00:6d:09'
  +
ce:3b:3b:dc:8d:29 dev vxlan11025 vlan 1 extern_learn master br-vni11025
  +
ce:3b:3b:dc:8d:29 dev vxlan11025 extern_learn master br-vni11025
  +
ce:3b:3b:dc:8d:29 dev vxlan11025 dst 192.168.32.102 self extern_learn
  +
a2:54:55:00:6d:09 dev pe1 master br-vni11025
  +
</PRE>
  +
Тут видно что-то очень похожее:
  +
* <code>a2:54:55:00:6d:09 dev pe1 master br-vni11025</code> - мак приходит со стороны <code>pe1</code> через <code>br-vni11025</code>
  +
* <code>ce:3b:3b:dc:8d:29</code> - я не знаю что означают эти записи точно, дальше идут мои предположения:
  +
  +
** <code>dev vxlan11025</code> - MAC-адрес пришёл по VXLAN-интерфейсу <code>vxlan11025</code>
  +
** <code>vlan 1</code> - MAC-адрес относится к <code>VLAN 1</code> (хороший вопрос, который меня всегда мучал - VLAN1 подразумевает отсутвие тега, а что будет если сделать такой интерфейс но с тегом?)
  +
** <code>extern_learn</code> - MAC-адрес был выучен внешним механизмом (BGP EVPN), а не традиционным L2-обучением.
  +
** <code>master br-vni11025</code> <code>vxlan11025</code> является частью бриджа <code>br-vni11025</code>
  +
  +
==<code>vxlan11025</code>==
  +
Тут нет никаких неожиданностей:<BR>
  +
<code>root@frr1:~# tcpdump -n -ee -i vxlan11025</code>
  +
<PRE>
  +
14:17:28.543778 a2:54:55:00:6d:09 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.98.2 tell 192.168.98.1, length 28
  +
14:17:28.544413 ce:3b:3b:dc:8d:29 > a2:54:55:00:6d:09, ethertype ARP (0x0806), length 42: Reply 192.168.98.2 is-at ce:3b:3b:dc:8d:29, length 28
  +
14:17:28.544448 a2:54:55:00:6d:09 > ce:3b:3b:dc:8d:29, ethertype IPv4 (0x0800), length 98: 192.168.98.1 > 192.168.98.2: ICMP echo request, id 7024, seq 1, length 64
  +
14:17:28.544617 ce:3b:3b:dc:8d:29 > a2:54:55:00:6d:09, ethertype IPv4 (0x0800), length 98: 192.168.98.2 > 192.168.98.1: ICMP echo reply, id 7024, seq 1, length 64
  +
14:17:29.545282 a2:54:55:00:6d:09 > ce:3b:3b:dc:8d:29, ethertype IPv4 (0x0800), length 98: 192.168.98.1 > 192.168.98.2: ICMP echo request, id 7024, seq 2, length 64
  +
14:17:29.545584 ce:3b:3b:dc:8d:29 > a2:54:55:00:6d:09, ethertype IPv4 (0x0800), length 98: 192.168.98.2 > 192.168.98.1: ICMP echo reply, id 7024, seq 2, length 64
  +
14:17:33.620718 ce:3b:3b:dc:8d:29 > a2:54:55:00:6d:09, ethertype ARP (0x0806), length 42: Request who-has 192.168.98.1 tell 192.168.98.2, length 28
  +
14:17:33.620768 a2:54:55:00:6d:09 > ce:3b:3b:dc:8d:29, ethertype ARP (0x0806), length 42: Reply 192.168.98.1 is-at a2:54:55:00:6d:09, length 28
  +
</PRE>
  +
  +
==<code>tenant</code>==
  +
Проверка инкапсуляции:
  +
<code>tcpdump -ee -n -i tenant port 4789</code>
  +
<PRE>
  +
14:17:28.543791 00:99:00:00:00:01 > 00:99:00:00:22:01, ethertype IPv4 (0x0800), length 92: 192.168.32.101.34053 > 192.168.32.102.4789: VXLAN, flags [I] (0x08), vni 11025
  +
a2:54:55:00:6d:09 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.98.2 tell 192.168.98.1, length 28
  +
14:17:28.544413 00:99:00:00:22:01 > 00:99:00:00:00:01, ethertype IPv4 (0x0800), length 92: 192.168.32.102.48515 > 192.168.32.101.4789: VXLAN, flags [I] (0x08), vni 11025
  +
ce:3b:3b:dc:8d:29 > a2:54:55:00:6d:09, ethertype ARP (0x0806), length 42: Reply 192.168.98.2 is-at ce:3b:3b:dc:8d:29, length 28
  +
14:17:28.544460 00:99:00:00:00:01 > 00:99:00:00:22:01, ethertype IPv4 (0x0800), length 148: 192.168.32.101.43665 > 192.168.32.102.4789: VXLAN, flags [I] (0x08), vni 11025
  +
a2:54:55:00:6d:09 > ce:3b:3b:dc:8d:29, ethertype IPv4 (0x0800), length 98: 192.168.98.1 > 192.168.98.2: ICMP echo request, id 7024, seq 1, length 64
  +
14:17:28.544617 00:99:00:00:22:01 > 00:99:00:00:00:01, ethertype IPv4 (0x0800), length 148: 192.168.32.102.33214 > 192.168.32.101.4789: VXLAN, flags [I] (0x08), vni 11025
  +
ce:3b:3b:dc:8d:29 > a2:54:55:00:6d:09, ethertype IPv4 (0x0800), length 98: 192.168.98.2 > 192.168.98.1: ICMP echo reply, id 7024, seq 1, length 64
  +
14:17:29.545313 00:99:00:00:00:01 > 00:99:00:00:22:01, ethertype IPv4 (0x0800), length 148: 192.168.32.101.43665 > 192.168.32.102.4789: VXLAN, flags [I] (0x08), vni 11025
  +
a2:54:55:00:6d:09 > ce:3b:3b:dc:8d:29, ethertype IPv4 (0x0800), length 98: 192.168.98.1 > 192.168.98.2: ICMP echo request, id 7024, seq 2, length 64
  +
14:17:29.545584 00:99:00:00:22:01 > 00:99:00:00:00:01, ethertype IPv4 (0x0800), length 148: 192.168.32.102.33214 > 192.168.32.101.4789: VXLAN, flags [I] (0x08), vni 11025
  +
ce:3b:3b:dc:8d:29 > a2:54:55:00:6d:09, ethertype IPv4 (0x0800), length 98: 192.168.98.2 > 192.168.98.1: ICMP echo reply, id 7024, seq 2, length 64
  +
14:17:33.620718 00:99:00:00:22:01 > 00:99:00:00:00:01, ethertype IPv4 (0x0800), length 92: 192.168.32.102.48515 > 192.168.32.101.4789: VXLAN, flags [I] (0x08), vni 11025
  +
ce:3b:3b:dc:8d:29 > a2:54:55:00:6d:09, ethertype ARP (0x0806), length 42: Request who-has 192.168.98.1 tell 192.168.98.2, length 28
  +
14:17:33.620784 00:99:00:00:00:01 > 00:99:00:00:22:01, ethertype IPv4 (0x0800), length 92: 192.168.32.101.34053 > 192.168.32.102.4789: VXLAN, flags [I] (0x08), vni 11025
  +
a2:54:55:00:6d:09 > ce:3b:3b:dc:8d:29, ethertype ARP (0x0806), length 42: Reply 192.168.98.1 is-at a2:54:55:00:6d:09, length 28
  +
14:17:56.659011 00:99:00:00:22:01 > 00:99:00:00:00:01, ethertype IPv4 (0x0800), length 120: 192.168.32.102.57482 > 192.168.32.101.4789: VXLAN, flags [I] (0x08), vni 11025
  +
66:f8:b3:52:6b:af > 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 70: fe80::64f8:b3ff:fe52:6baf > ff02::2: ICMP6, router solicitation, length 16
  +
14:22:18.802890 00:99:00:00:22:01 > 00:99:00:00:00:01, ethertype IPv4 (0x0800), length 120: 192.168.32.102.38741 > 192.168.32.101.4789: VXLAN, flags [I] (0x08), vni 11025
  +
ce:3b:3b:dc:8d:29 > 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 70: fe80::cc3b:3bff:fedc:8d29 > ff02::2: ICMP6, router solicitation, length 16
  +
</PRE>
  +
Тут четко видно что это <code>VXLAN</code> трафик идет между <code>loopback</code> интерфейсами роутеров <code>FRR1</code> и <code>FRR2</code>, а <code>ICMP</code> идет инкапсулированным в <code>[[BGP_EVPN_FRR_simple#VNI|VNI 11025]]</code>
  +
  +
=Добавление дополнительных <code>[[BGP_EVPN_FRR_simple#VNI|VNI]]</code> и проверка прохождения трафика для них=
  +
==netplan==
  +
<PRE>
  +
tunnels:
  +
vxlan11025:
  +
mode: vxlan
  +
link: loopback0
  +
id: 11025
  +
mtu: 8950
  +
accept-ra: no
  +
neigh-suppress: true
  +
link-local: []
  +
mac-learning: false
  +
port: 4789
  +
local: 192.168.32.101
  +
virtual-ethernets:
  +
pe1:
  +
peer: ce1
  +
ce1:
  +
peer: pe1
  +
dhcp4: false
  +
dhcp6: false
  +
addresses: ["192.168.98.1/24"]
  +
bridges:
  +
br-vni11025:
  +
interfaces: ["vxlan11025", "pe1"]
  +
dhcp4: false
  +
dhcp6: false
  +
stp: false
  +
</PRE>
  +
* Это пока не готово но в процессе
  +
  +
=Next Steps=
  +
  +
Следующие шаги:
  +
* [[BGP_EVPN_FRR_AND_ASR1001#FRR_.2B_ASR1001|Дальше добавить к этой схеме железный роутер ASR1001]]
   
 
=Команды=
  
=Команды=

Текущая версия на 15:58, 22 февраля 2025


Минимальная конфигурация EVPN по шагам

Это документ о настройке абсолютно минимальной конфигурации EVPN

Сокращения использованные в документе

PE

  • PE: Provider Edge - Маршрутизатор провайдера к которому подключены клиенты

CE

  • CE: Client Edge - Маршрутизатор клиента который подключен к провайдеру

BUM

Broadcast / Unknown Unicast / Multicast (BUM) - тип трафика, который обычно требует рассылки нескольким получателям, из-за чего потенциально может создавать дополнительную нагрузку на сеть.
Примером такой нагрузки можно считать Broadcast Storm

VTEP

VTEP - Virtual Tunnel End Point, кончная точка тунеля - устройство на котором начинается или заканчивается тунель, в этой статье в качестве VTEP выступают 2 маршрутизатора - FRR1 и FRR2. В других конфигурациях (например в случае с Calico) в качестве VTEP могут выступать, например worker-ноды kubernetes кластера.

VNI

VNI - VxLAN Network Identifier - идентификатор различных сетей VxLAN (в пределах одного VTEP). Для упрощения, про VNI можно думать как про Vlan Id, VNI должны быть уникальны в EVPN сети, точно так же как Vlan Id должны быть уникальны в классических сетях. В целом, назначаются произвольно, так же как и Vlan Id

Схема сети

FRR BGP EVPN 1.drawio.png
Оригинал: Файл:FRR BGP EVPN 1.drawio

Тестовый стенд полностью виртуализирован.
На этой схеме:

  • 2 маршрутизатора FRR выполняют роли PE
    • Сеть tenant используется как транспортная сеть между маршрутизаторами (l2 сегмент)
    • Каждый из PE имеет по 1 подключеному CE
    • CE максимально упрощены - это просто IP адрес поднятый на бридже (но конечно ничто не мешает использовать отдельную виртуальную машину, разницы нет)
  • Используется 1 интерфейс для поддключения CE
  • Номер VNI выбран абсолютно произвольно, такое значение взято что бы оно случайно не совпало ни с каким другим и было заведомо больше максимального номера влана
  • Management сеть используется только для управлени маршрутизаторами (без нее можно обойтись, она не учавствует маршрутизации) Интерфейсы в этой сети названы external по историческим причинам.
  • Интерфейсы loopback изспользуются для построения сессий BGP

Настройка сети на маршрутизаторах

  • Настройки на обоих маршрутизаторах идентичны (с точностью до адресов)
  • dummy поддерживается в относительно новых версиях netplan (Убунту 24.04 поддерживает)

FRR1

network:
    version: 2
    dummy-devices:
        loopback0:
            addresses:
                - 192.168.32.101/32
    ethernets:
        ens3:
            dhcp4: false
            dhcp6: false
            addresses: ["10.80.6.253/24"]
            set-name: "tenant"
            match:
                macaddress: "00:99:00:00:00:01"


        ens5:
            dhcp4: true
            dhcp6: false
            match:
                macaddress: "00:99:00:00:00:03"
            set-name: "external"

FRR2

network:
    version: 2
    dummy-devices:
        loopback0:
            addresses:
                - 192.168.32.102/32
    ethernets:
        ens3:
            dhcp4: false
            dhcp6: false
            addresses: ["10.80.6.252/24"]
            set-name: "tenant"
            match:
                macaddress: "00:99:00:00:22:01"

        ens5:
            dhcp4: true
            dhcp6: false
            match:
                macaddress: "00:99:00:00:22:03"
            set-name: "external"

Настройка демона FRR

Эта часть разделена на 2 части - не относящееся к EVPN выделено в отдельную часть

Подготовительная настройка

  • Запустить OSPF в сети tenant для того что бы получить доступность интерфейсов loopback
  • сделать редистрибьюцию маршрутов в OSPF (не уверене что нужно делать все три - static, connected и kernel даже скорее всего нет, но этот вопрос не относится к теме статьи)
  • тут можно вполне обойтись статикой без OSPF но так сделано для большей "достоверности" - как у настоящих провайдеров.


Немного заметок про настройку OSPF:

  • prefix-list REDISTRIBUTE- ... - префикс-листы что бы ограничить редистрибьюцию в OSPF только /32 (ge) сетями из диапазона 192.168.32.0/24
  • В работе OSPF учавствует только интерфейс tenant ( no ip ospf passive, passive-interface defaul)

FRR1 OSPF

frr version 10.2.1
frr defaults traditional
hostname frr1
log file /var/log/frr.log
log syslog informational
no ip forwarding
no ipv6 forwarding
service integrated-vtysh-config
!
ip prefix-list REDISTRIBUTE-KERNEL-TO-OSPF-LOOPBACK-BLOCK seq 10 permit 192.168.32.0/24 ge 32
ip prefix-list REDISTRIBUTE-STATIC-TO-OSPF-LOOPBACK-BLOCK seq 10 permit 192.168.32.0/24 ge 32
ip prefix-list REDISTRIBUTE-CONNECTED-TO-OSPF-LOOPBACK-BLOCK seq 10 permit 192.168.32.0/24 ge 32
!
interface tenant
 no ip ospf passive
exit
!
router ospf
 ospf router-id 192.168.32.101
 redistribute kernel route-map REDISTRIBUTE-KERNEL-TO-OSPF
 redistribute connected route-map REDISTRIBUTE-CONNECTED-TO-OSPF
 redistribute static route-map REDISTRIBUTE-STATIC-TO-OSPF
 passive-interface default
 network 10.80.6.0/24 area 0
exit
!
route-map REDISTRIBUTE-KERNEL-TO-OSPF permit 10
 match ip address prefix-list REDISTRIBUTE-KERNEL-TO-OSPF-LOOPBACK-BLOCK
exit
!
route-map REDISTRIBUTE-STATIC-TO-OSPF permit 10
 match ip address prefix-list REDISTRIBUTE-STATIC-TO-OSPF-LOOPBACK-BLOCK
exit
!
route-map REDISTRIBUTE-CONNECTED-TO-OSPF permit 10
 match ip address prefix-list REDISTRIBUTE-CONNECTED-TO-OSPF-LOOPBACK-BLOCK
exit
!
end

FRR2 OSPF

frr version 10.2.1
frr defaults traditional
hostname frr2
log file /var/log/frr.log
log syslog informational
no ip forwarding
no ipv6 forwarding
service integrated-vtysh-config
!
ip prefix-list REDISTRIBUTE-KERNEL-TO-OSPF-LOOPBACK-BLOCK seq 10 permit 192.168.32.0/24 ge 32
ip prefix-list REDISTRIBUTE-STATIC-TO-OSPF-LOOPBACK-BLOCK seq 10 permit 192.168.32.0/24 ge 32
ip prefix-list REDISTRIBUTE-CONNECTED-TO-OSPF-LOOPBACK-BLOCK seq 10 permit 192.168.32.0/24 ge 32
!
!
interface tenant
 no ip ospf passive
exit
!
router ospf
 ospf router-id 192.168.32.102
 redistribute kernel route-map REDISTRIBUTE-KERNEL-TO-OSPF
 redistribute connected route-map REDISTRIBUTE-CONNECTED-TO-OSPF
 redistribute static route-map REDISTRIBUTE-STATIC-TO-OSPF
 passive-interface default
 network 10.80.6.0/24 area 0
exit
!
route-map REDISTRIBUTE-KERNEL-TO-OSPF permit 10
 match ip address prefix-list REDISTRIBUTE-KERNEL-TO-OSPF-LOOPBACK-BLOCK
exit
!
route-map REDISTRIBUTE-STATIC-TO-OSPF permit 10
 match ip address prefix-list REDISTRIBUTE-STATIC-TO-OSPF-LOOPBACK-BLOCK
exit
!
route-map REDISTRIBUTE-CONNECTED-TO-OSPF permit 10
 match ip address prefix-list REDISTRIBUTE-CONNECTED-TO-OSPF-LOOPBACK-BLOCK
exit
!
end

Проверка работы OSPF

Соседи видят друг-друга

frr1# show ip ospf neighbor 

Neighbor ID     Pri State           Up Time         Dead Time Address         Interface                        RXmtL RqstL DBsmL
192.168.32.102    1 Full/DR         22h48m06s         30.094s 10.80.6.252     tenant:10.80.6.253                   0     0     0

frr2# show ip ospf neighbor 

Neighbor ID     Pri State           Up Time         Dead Time Address         Interface                        RXmtL RqstL DBsmL
192.168.32.101    1 Full/Backup     22h48m23s         33.773s 10.80.6.253     tenant:10.80.6.252                   0     0     0

Просмотр базы данных OSPF (на примере frr2):

show ip ospf database 

       OSPF Router with ID (192.168.32.102)

                Router Link States (Area 0.0.0.0)

Link ID         ADV Router      Age  Seq#       CkSum  Link count
192.168.32.101 192.168.32.101  1533 0x80000032 0x037a 1
192.168.32.102 192.168.32.102  1542 0x80000032 0xe497 1

                Net Link States (Area 0.0.0.0)

Link ID         ADV Router      Age  Seq#       CkSum
10.80.6.252    192.168.32.102  1692 0x80000030 0x6e90

                AS External Link States

Link ID         ADV Router      Age  Seq#       CkSum  Route
192.168.32.1   192.168.32.101  1683 0x80000030 0xe233 E2 192.168.32.1/32 [0x0]
192.168.32.1   192.168.32.102  1552 0x80000030 0xdc38 E2 192.168.32.1/32 [0x0]
192.168.32.2   192.168.32.101  1563 0x80000030 0xd83c E2 192.168.32.2/32 [0x0]
192.168.32.2   192.168.32.102  1612 0x80000030 0xd241 E2 192.168.32.2/32 [0x0]
192.168.32.101 192.168.32.101  1483 0x80000030 0xf6ba E2 192.168.32.101/32 [0x0]
192.168.32.102 192.168.32.102    12 0x80000031 0xe4c9 E2 192.168.32.102/32 [0x0]

Icon-caution.gif

Уточнение:
Тут присутвуют адреса 192.168.32.1 и 192.168.32.2 которых не должно быть.
Это не ошибка, в лабе они присутвуют в виде статических маршрутов (в моем случае выданных по DHCP) и в OSPF они попали через редистрибьюцию так как тоже относятся к блоку 192.168.32.0/24 и имеют маску /32. В контексте EVPN их можно игнорировать.

EVPN

Cхема работы (приблизительная

Существует два типа информации о доступности сети, которую VTEP передает через BGP EVPN:

  • VNI, в которых они заинтересованы (маршруты L2???)
  • локальный MAC-адрес для каждого VNI (маршруты L2)

Начальная настройка BGP

На начальном этапе в конфигурации отсутствуют VxLAN интерфейсы, пока просто проверка что BGP-сессия поднимаются нормально.

  • В качестве адреса используется интерфейс loopback - так как он всегда поднят, не зависит от физического состояния линка (адрес на нем может быть доступен через несколько линков в общем случае, при наличии динамической маршрутизации, это общаяя практика)
  • Номер AS - 65000 из частного диапазона, одинаковый на обоих маршрутизаторах
  • neighbor fabric peer-group - не смотря на то что у нас всего один neighbor описываем группу - так проще будет расширять
  • bgp router-id 192.168.32.101 - задать идентификатор роутера (что бы он был однозначен а не выбран автоматически)
  • neighbor fabric update-source 192.168.32.101 - указать с какого адреса отправлять обновления. Если этого не сделать то будет выбран адрес интерфейса, в результате пакеты будут уходить не с тем адресом который ожидает сосед, и сессия не поднимется. ("костыль" тут это использовать адреса интерфейсов)

FRR1

router bgp 65000
 bgp router-id 192.168.32.101
 no bgp default ipv4-unicast
 neighbor fabric peer-group
 neighbor fabric remote-as 65000
 neighbor fabric update-source 192.168.32.101
 neighbor fabric capability extended-nexthop
 neighbor 192.168.32.102 peer-group fabric
 !
 address-family l2vpn evpn
  neighbor fabric activate
 exit-address-family
exit

FRR1

router bgp 65000
 bgp router-id 192.168.32.102
 no bgp default ipv4-unicast
 neighbor fabric peer-group
 neighbor fabric remote-as 65000
 neighbor fabric update-source 192.168.32.102
 neighbor fabric capability extended-nexthop
 neighbor 192.168.32.101 peer-group fabric
 !
 address-family l2vpn evpn
  neighbor fabric activate
 exit-address-family
exit

Проверка BGP

frr1# show bgp summary 

L2VPN EVPN Summary:
BGP router identifier 192.168.32.101, local AS number 65000 VRF default vrf-id 0
BGP table version 0
RIB entries 0, using 0 bytes of memory
Peers 1, using 24 KiB of memory
Peer groups 1, using 64 bytes of memory

Neighbor        V         AS   MsgRcvd   MsgSent   TblVer  InQ OutQ  Up/Down State/PfxRcd   PfxSnt Desc
192.168.32.102  4      65000      1411      1411        0    0    0 23:28:54            0        0 FRRouting/10.2.1

Total number of neighbors 1

L2EVPN не является IP что можно видеть по ошибке ниже: <BRE> frr1# sho ip bgp summary 

% No BGP neighbors found in VRF default


Никаких маршрутов пока нет frr1# show bgp 

No BGP prefixes displayed, 0 exist

Добавление конечных точек VTEP

Для начала добвляются конечные точки только на одно роутере - FRR1

Для добавления VTEP используется скрипт, рассчитаный на добавление множества VTEP но в целях упрощения добавляем только один.

  • seq 11025 11025 даст список из 1 элемента - 11025
  • LOCAL_IP="192.168.32.101" - source-адрес VxLAN-тунелей (loopback, причины его использования такие же как и для BGP)
  • для FRR2 LOCAL_IP="192.168.32.102"
#!/bin/bash
LOCAL_IP="192.168.32.101"

for vni in $(seq 11025 11025) ; do
    # Create VXLAN interface
    ip link add vxlan${vni} type vxlan \
        id ${vni} \
        dstport 4789 \
        local ${LOCAL_IP} \
        nolearning

    brctl addbr br-vni${vni}
    brctl addif br-vni${vni} vxlan${vni}
    brctl stp br-vni${vni} off
    ip link set up dev br-vni${vni}
    ip link set up dev vxlan${vni}
done

В результате работы скрипта будет создан 1 VxLAN-тунель и добавлен в бридж 

7: vxlan11025: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-vni11025 state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether 66:f8:b3:52:6b:af brd ff:ff:ff:ff:ff:ff

# brctl show 

bridge name	bridge id		STP enabled	interfaces
br-vni11025		8000.5e240380730e	no		vxlan11025

BGP после добавления конечных точек

Можно увидеть доступный VNI (номер его 11025 ожидаемо совпадает с добавленным)
show bgp evpn vni 

Advertise Gateway Macip: Disabled
Advertise SVI Macip: Disabled
Advertise All VNI flag: Enabled
BUM flooding: Head-end replication
VXLAN flooding: Enabled
Number of L2 VNIs: 1
Number of L3 VNIs: 0
Flags: * - Kernel
  VNI        Type RD                    Import RT                 Export RT                 MAC-VRF Site-of-Origin    Tenant VRF
* 11025      L2   192.168.32.101:2      65000:11025               65000:11025                                         default


Однако маршрут в BGP отсутвует (show bgp evpn route)
Для того что бы маршрут появился требуется добавить строчку в конфигурацию

  • advertise-all-vni
 address-family l2vpn evpn
  neighbor fabric activate
  advertise-all-vni
 exit-address-family

После чего маршрут появляется в BGP

Icon-caution.gif

В случае нескольких VNI анонсированны будут все

Icon-caution.gif

Как фильтровать какие VNI анонсировать, а какие нет - пока не ясно, эта часть будет дополнена позже.

Маршруты

show bgp evpn route 

BGP table version is 3, local router ID is 192.168.32.101
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
EVPN type-1 prefix: [1]:[EthTag]:[ESI]:[IPlen]:[VTEP-IP]:[Frag-id]
EVPN type-2 prefix: [2]:[EthTag]:[MAClen]:[MAC]:[IPlen]:[IP]
EVPN type-3 prefix: [3]:[EthTag]:[IPlen]:[OrigIP]
EVPN type-4 prefix: [4]:[ESI]:[IPlen]:[OrigIP]
EVPN type-5 prefix: [5]:[EthTag]:[IPlen]:[IP]

   Network          Next Hop            Metric LocPrf Weight Path
                    Extended Community
Route Distinguisher: 192.168.32.101:2
 *>  [3]:[0]:[32]:[192.168.32.101]
                    192.168.32.101                     32768 i
                    ET:8 RT:65000:11025

Или более подробно 

frr1# show bgp evpn route detail
Route Distinguisher: 192.168.32.101:2
BGP routing table entry for 192.168.32.101:2:[3]:[0]:[32]:[192.168.32.101]
Paths: (1 available, best #1)
  Advertised to non peer-group peers:
  192.168.32.102
  Route [3]:[0]:[32]:[192.168.32.101] VNI 11025
  Local
    192.168.32.101 from 0.0.0.0 (192.168.32.101)
      Origin IGP, weight 32768, valid, sourced, local, best (First path received)
      Extended Community: ET:8 RT:65000:11025
      Last update: Thu Feb 13 10:52:39 2025
      PMSI Tunnel Type: Ingress Replication, label: 11025

Displayed 1 prefixes (1 paths)

Это Маршрут типа 3 (подробно маршрут такого типа разобран по ссылке)

Тип маршрута виден из [3]:[0]:[32]:[192.168.32.101] выделенной части вывода
Тут отмечу коротко что он означает:

  • Route_Distinguisher 192.168.32.101:2
  • 192.168.32.101:2:[3]:[0]:[32]:[192.168.32.101]
    • [3] - тип маршрута
    • [0] - В случае типа 3 это вероятно (но не точно!) VLAN ID (уточнить)
    • [32] длинна следующего поля - IPv4
    • [192.168.32.101] Источник маршрута
  • Advertised to non peer-group peers: 192.168.32.102 - информация о том кому анонсируется маршрут
  • Route [3]:[0]:[32]:[192.168.32.101] VNI 11025
    • VNI 11025 - Номер VNI
  • Origin IGP, weight 32768, valid, sourced, local, best (First path received) источник маршрута - Internal Gateway Protocol
  • Extended Community: ET:8 RT:65000:11025
    • ET:8 Encapsulation Type 8 - тип зарезервированный за VxLAN
    • RT:65000:11025 Route Target - поле на основании которого принимается решение куда (в какой VRF) помещать маршрут
  • Last update: Thu Feb 13 10:52:39 2025 - Очевидно?
  • PMSI Tunnel Type: Ingress Replication, label: 11025
    • label: 11025 - VNI 11025

Icon-caution.gif

Обратить внимание - это маршрут типа 3 и значит он применим только для Broadcast / Unknown Unicast / Multicast (BUM) трафика

Добавление VNI на втором роутере (FFR2)

После добавлениея интерфейса на втором роутере (тем же скриптом) и активации опции advertise-all-vni ожидаемо появляется второй маршрут (зеркальный по отношению к первому) 

   Network          Next Hop            Metric LocPrf Weight Path
                    Extended Community
Route Distinguisher: 192.168.32.101:2
 *>i [3]:[0]:[32]:[192.168.32.101]
                    192.168.32.101                100      0 i
                    RT:65000:11025 ET:8
Route Distinguisher: 192.168.32.102:2
 *>  [3]:[0]:[32]:[192.168.32.102]
                    192.168.32.102                     32768 i
                    ET:8 RT:65000:11025

Проверка работы BUM трафика

После того как в таблице маршрутизации присутвует 2 маршрута (прямой и обратный) Типа 3 ожидается что по ним можно будет отправлять например широковещательный трафик
Проверка

Добавить адреса на бриджи с обоих сторон=

FRR1 

ip addr add 192.168.99.1/24 dev br-vni11025

FRR2 

ip addr add 192.168.99.2/24 dev br-vni11025

Поднять бриджи

Команда одинаковая на обоих FRR 

ip link set up dev br-vni11025

Проверить IP адрес

Команда одинаковая на обоих FRR, пример для FFR2 

ip -4 a s dev br-vni11025
8: br-vni11025: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    inet 192.168.99.2/24 scope global br-vni11025
       valid_lft forever preferred_lft forever

Проверить что маршрут указывает в правильный интерфейс

ip ro get 192.168.99.1
192.168.99.1 dev br-vni11025 src 192.168.99.2 uid 0
    cache

Запустить ping с FRR2 (192.168.99.2) на FRR1 (192.168.99.1)

Тут видно что на VXLAN есть arp-запросы 

root@frr1:/etc/frr# tcpdump  -n -ee -i vxlan11025
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on vxlan11025, link-type EN10MB (Ethernet), snapshot length 262144 bytes
17:34:36.096216 5e:24:03:80:73:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.99.1 tell 192.168.99.2, length 28
17:34:37.106661 5e:24:03:80:73:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.99.1 tell 192.168.99.2, length 28
17:34:38.130696 5e:24:03:80:73:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.99.1 tell 192.168.99.2, length 28

А на бридже есть как запросы так и ответы - но так как маршрут типа 3 только для BUM - трафика то ответы никуда дальше бриджа не уходят 

tcpdump  -n -ee -i br-vni11025
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on br-vni11025, link-type EN10MB (Ethernet), snapshot length 262144 bytes
17:42:34.674829 5e:24:03:80:73:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.99.1 tell 192.168.99.2, length 28
17:42:34.674914 5e:24:03:80:73:0e > 5e:24:03:80:73:0e, ethertype ARP (0x0806), length 42: Reply 192.168.99.1 is-at 5e:24:03:80:73:0e, length 28
17:42:35.698781 5e:24:03:80:73:0e > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.99.1 tell 192.168.99.2, length 28

Icon-caution.gif

После того как тест завершен IP адреса нужно удалить так как они будут мешать в дальнейшем

Подключение виртуальных CE

Для имитации CE я не буду создавать виртуальные машины, а использую просто veth один из которых включая в бридж, а второй "как бы" и есть CE

FRR2

Настройка интерфейса FRR2

Для начала добавляю конфигурацию на FRR2 

ip link add dev pe2 type veth peer name ce2

brctl addif br-vni11025 pe2

ip link set up dev pe2

ip link set up dev ce2

Назначим адрес виртуальном CE2 

ip addr add 192.168.98.2/24 dev ce2

Проверка BGP (FRR2)

После добавления интерфейса можно видеть что в BGP появился дополнительный маршрут Типа 2 frr2# show bgp evpn route 

BGP table version is 3, local router ID is 192.168.32.102
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
EVPN type-1 prefix: [1]:[EthTag]:[ESI]:[IPlen]:[VTEP-IP]:[Frag-id]
EVPN type-2 prefix: [2]:[EthTag]:[MAClen]:[MAC]:[IPlen]:[IP]
EVPN type-3 prefix: [3]:[EthTag]:[IPlen]:[OrigIP]
EVPN type-4 prefix: [4]:[ESI]:[IPlen]:[OrigIP]
EVPN type-5 prefix: [5]:[EthTag]:[IPlen]:[IP]

   Network          Next Hop            Metric LocPrf Weight Path
                    Extended Community
Route Distinguisher: 192.168.32.101:2
 *>i [3]:[0]:[32]:[192.168.32.101]
                    192.168.32.101                100      0 i
                    RT:65000:11025 ET:8
Route Distinguisher: 192.168.32.102:2
 *>  [2]:[0]:[48]:[ce:3b:3b:dc:8d:29]
                    192.168.32.102                     32768 i
                    ET:8 RT:65000:11025
 *>  [3]:[0]:[32]:[192.168.32.102]
                    192.168.32.102                     32768 i
                    ET:8 RT:65000:11025

Displayed 3 prefixes (3 paths)

frr2# show bgp evpn route detail 


Route Distinguisher: 192.168.32.101:2
BGP routing table entry for 192.168.32.101:2:[3]:[0]:[32]:[192.168.32.101]
Paths: (1 available, best #1)
  Not advertised to any peer
  Route [3]:[0]:[32]:[192.168.32.101]
  Local
    192.168.32.101 (metric 20) from 192.168.32.101 (192.168.32.101)
      Origin IGP, localpref 100, valid, internal, best (First path received)
      Extended Community: RT:65000:11025 ET:8
      Last update: Thu Feb 13 10:52:39 2025
      PMSI Tunnel Type: Ingress Replication, label: 11025

Route Distinguisher: 192.168.32.102:2

BGP routing table entry for 192.168.32.102:2:[2]:[0]:[48]:[ce:3b:3b:dc:8d:29]
Paths: (1 available, best #1)
  Advertised to non peer-group peers:
  192.168.32.101
  Route [2]:[0]:[48]:[ce:3b:3b:dc:8d:29] VNI 11025
  Local
    192.168.32.102 from 0.0.0.0 (192.168.32.102)
      Origin IGP, weight 32768, valid, sourced, local, best (First path received)
      Extended Community: ET:8 RT:65000:11025
      Last update: Fri Feb 14 13:42:50 2025
BGP routing table entry for 192.168.32.102:2:[3]:[0]:[32]:[192.168.32.102]
Paths: (1 available, best #1)
  Advertised to non peer-group peers:
  192.168.32.101
  Route [3]:[0]:[32]:[192.168.32.102] VNI 11025
  Local
    192.168.32.102 from 0.0.0.0 (192.168.32.102)
      Origin IGP, weight 32768, valid, sourced, local, best (First path received)
      Extended Community: ET:8 RT:65000:11025
      Last update: Thu Feb 13 17:24:02 2025
      PMSI Tunnel Type: Ingress Replication, label: 11025

Displayed 3 prefixes (3 paths)

Тут видно что появился дополнительный маршрут типа 2 

Route Distinguisher: 192.168.32.102:2

BGP routing table entry for 192.168.32.102:2:[2]:[0]:[48]:[ce:3b:3b:dc:8d:29]
Paths: (1 available, best #1)
  Advertised to non peer-group peers:
  192.168.32.101
  Route [2]:[0]:[48]:[ce:3b:3b:dc:8d:29] VNI 11025
  Local
    192.168.32.102 from 0.0.0.0 (192.168.32.102)
      Origin IGP, weight 32768, valid, sourced, local, best (First path received)
      Extended Community: ET:8 RT:65000:11025
      Last update: Fri Feb 14 13:42:50 2025
  • [2] означает, что это Type 2 (MAC/IP Advertisement Route).
  • [EthTag] Ethernet Tag ID (обычно = 0 для VXLAN). В примере это тоже 0
  • [MAC] MAC-адрес хоста. В примере это ce:3b:3b:dc:8d:29 что соотвтевует мак-адресу "виртуального CE2":
ip link show dev ce2
9: ce2@pe2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether ce:3b:3b:dc:8d:29 brd ff:ff:ff:ff:ff:ff
  • [IP] (опционально) IP-адрес хоста, связанный с MAC. В примере отсутсвует

FRR1

Настройка интерфейса FRR1

Анадлогичная конфигурация на FRR1 (с точностью до имен интерфейсов и IP адреса) 

ip link add dev pe1 type veth peer name ce1

brctl addif br-vni11025 pe1

ip link set up dev pe1

ip link set up dev ce1

Назначим адрес виртуальном CE1 

ip addr add 192.168.98.1/24 dev ce1

Проверка BGP (FRR1)

На FRR1 ожидаемо 4 маршрута - два типа 3 и 2 типа 2 (тип 2 - по одному для локального и удаленного мак-адреса)

frr1# show bgp evpn route 

BGP table version is 5, local router ID is 192.168.32.101
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
EVPN type-1 prefix: [1]:[EthTag]:[ESI]:[IPlen]:[VTEP-IP]:[Frag-id]
EVPN type-2 prefix: [2]:[EthTag]:[MAClen]:[MAC]:[IPlen]:[IP]
EVPN type-3 prefix: [3]:[EthTag]:[IPlen]:[OrigIP]
EVPN type-4 prefix: [4]:[ESI]:[IPlen]:[OrigIP]
EVPN type-5 prefix: [5]:[EthTag]:[IPlen]:[IP]

   Network          Next Hop            Metric LocPrf Weight Path
                    Extended Community
Route Distinguisher: 192.168.32.101:2
 *>  [2]:[0]:[48]:[a2:54:55:00:6d:09]
                    192.168.32.101                     32768 i
                    ET:8 RT:65000:11025
 *>  [3]:[0]:[32]:[192.168.32.101]
                    192.168.32.101                     32768 i
                    ET:8 RT:65000:11025
Route Distinguisher: 192.168.32.102:2
 *>i [2]:[0]:[48]:[ce:3b:3b:dc:8d:29]
                    192.168.32.102                100      0 i
                    RT:65000:11025 ET:8
 *>i [3]:[0]:[32]:[192.168.32.102]
                    192.168.32.102                100      0 i
                    RT:65000:11025 ET:8

Displayed 4 prefixes (4 paths)
Сопоставление мак-адресов и маршрутов

На всякий случай можно сравнить МАК-адреса
frr1 - интерфейс (виртуального) CE 

root@frr1:/etc/frr# ip link show dev ce1
9: ce1@pe1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether a2:54:55:00:6d:09 brd ff:ff:ff:ff:ff:ff

Соответвующий маршрут: 

Route Distinguisher: 192.168.32.102:2
 *>i [2]:[0]:[48]:[ce:3b:3b:dc:8d:29]
                    192.168.32.102                100      0 i

frr2 - интерфейс (виртуального) CE 

9: ce2@pe2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether ce:3b:3b:dc:8d:29 brd ff:ff:ff:ff:ff:ff

Соответвующий маршрут: 

Route Distinguisher: 192.168.32.101:2
 *>  [2]:[0]:[48]:[a2:54:55:00:6d:09]
                    192.168.32.101                     32768 i
                    ET:8 RT:65000:11025

Мак-адреса CE

Для того что бы проще пониммать что за трафик видно в tcpdump выделю еще раз мак-адреса

MAC/IP CE1 a2:54:55:00:6d:09 192.168.98.1

 ip addr show dev ce1
9: ce1@pe1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether a2:54:55:00:6d:09 brd ff:ff:ff:ff:ff:ff
    inet 192.168.98.1/24 scope global ce1
       valid_lft forever preferred_lft forever
    inet6 fe80::a054:55ff:fe00:6d09/64 scope link
       valid_lft forever preferred_lft forever

MAC/IP CE2 ce:3b:3b:dc:8d:29 192.168.98.2

9: ce2@pe2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether ce:3b:3b:dc:8d:29 brd ff:ff:ff:ff:ff:ff
    inet 192.168.98.2/24 scope global ce2
       valid_lft forever preferred_lft forever
    inet6 fe80::cc3b:3bff:fedc:8d29/64 scope link
       valid_lft forever preferred_lft forever

Проверка прохождения трафика для одного VNI

Для проверки запускаем пиинг с одного виртуального CE : CE1 "подключенного" к FRR1
В это же время наблюдаем прохлжение трафика на всех интерфейсах обоих маршрутизаторов:

FRR1:

  • ce1
  • pe1 (второй конец виртуального патч-корда)
  • br-vni11025
  • vxlan11025
  • tenant (напоминание - так назван eth интерфейс в этой лабе, если бы это была не виртуальная машина а физический маршрутизатор то это была бы "реальная", не виртуальная, сетевая карта



ping CE1 -> CE2

Запускаем пинг с CE1, подключенный к FRR1 и имеющий IP адрес 192.168.98.2
на CE2 подключенный к FRR2 и имеющий IP адрес 192.168.98.2 

ping -c2 192.168.98.2
PING 192.168.98.2 (192.168.98.2) 56(84) bytes of data.
64 bytes from 192.168.98.2: icmp_seq=1 ttl=64 time=0.905 ms
64 bytes from 192.168.98.2: icmp_seq=2 ttl=64 time=0.363 ms

ce1

Трафик уходит с интерфейса ce1 - который в лабе представляет собой интерфейс виртуального CE1
root@frr1:~# tcpdump -ee -n -i ce1 -v 

14:17:28.543746 a2:54:55:00:6d:09 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.98.2 tell 192.168.98.1, length 28
14:17:28.544437 ce:3b:3b:dc:8d:29 > a2:54:55:00:6d:09, ethertype ARP (0x0806), length 42: Reply 192.168.98.2 is-at ce:3b:3b:dc:8d:29, length 28
14:17:28.544442 a2:54:55:00:6d:09 > ce:3b:3b:dc:8d:29, ethertype IPv4 (0x0800), length 98: 192.168.98.1 > 192.168.98.2: ICMP echo request, id 7024, seq 1, length 64
14:17:28.544624 ce:3b:3b:dc:8d:29 > a2:54:55:00:6d:09, ethertype IPv4 (0x0800), length 98: 192.168.98.2 > 192.168.98.1: ICMP echo reply, id 7024, seq 1, length 64
14:17:29.545263 a2:54:55:00:6d:09 > ce:3b:3b:dc:8d:29, ethertype IPv4 (0x0800), length 98: 192.168.98.1 > 192.168.98.2: ICMP echo request, id 7024, seq 2, length 64
14:17:29.545599 ce:3b:3b:dc:8d:29 > a2:54:55:00:6d:09, ethertype IPv4 (0x0800), length 98: 192.168.98.2 > 192.168.98.1: ICMP echo reply, id 7024, seq 2, length 64
14:17:33.620753 ce:3b:3b:dc:8d:29 > a2:54:55:00:6d:09, ethertype ARP (0x0806), length 42: Request who-has 192.168.98.1 tell 192.168.98.2, length 28
14:17:33.620765 a2:54:55:00:6d:09 > ce:3b:3b:dc:8d:29, ethertype ARP (0x0806), length 42: Reply 192.168.98.1 is-at a2:54:55:00:6d:09, length 28

Тут видно что сначала идет ARP-запрос и потом нормальный обмен трафиком между a2:54:55:00:6d:09 и ce:3b:3b:dc:8d:29

pe1 (второй конец виртуального патч-корда)

Далее трафик попадает на интерфейс pe1 который представляет интерфейс PE1

tcpdump -ee -n -i pe1 

listening on pe1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
14:17:28.543751 a2:54:55:00:6d:09 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.98.2 tell 192.168.98.1, length 28
14:17:28.544436 ce:3b:3b:dc:8d:29 > a2:54:55:00:6d:09, ethertype ARP (0x0806), length 42: Reply 192.168.98.2 is-at ce:3b:3b:dc:8d:29, length 28
14:17:28.544442 a2:54:55:00:6d:09 > ce:3b:3b:dc:8d:29, ethertype IPv4 (0x0800), length 98: 192.168.98.1 > 192.168.98.2: ICMP echo request, id 7024, seq 1, length 64
14:17:28.544623 ce:3b:3b:dc:8d:29 > a2:54:55:00:6d:09, ethertype IPv4 (0x0800), length 98: 192.168.98.2 > 192.168.98.1: ICMP echo reply, id 7024, seq 1, length 64
14:17:29.545271 a2:54:55:00:6d:09 > ce:3b:3b:dc:8d:29, ethertype IPv4 (0x0800), length 98: 192.168.98.1 > 192.168.98.2: ICMP echo request, id 7024, seq 2, length 64
14:17:29.545598 ce:3b:3b:dc:8d:29 > a2:54:55:00:6d:09, ethertype IPv4 (0x0800), length 98: 192.168.98.2 > 192.168.98.1: ICMP echo reply, id 7024, seq 2, length 64
14:17:33.620749 ce:3b:3b:dc:8d:29 > a2:54:55:00:6d:09, ethertype ARP (0x0806), length 42: Request who-has 192.168.98.1 tell 192.168.98.2, length 28
14:17:33.620766 a2:54:55:00:6d:09 > ce:3b:3b:dc:8d:29, ethertype ARP (0x0806), length 42: Reply 192.168.98.1 is-at a2:54:55:00:6d:09, length 28

br-vni11025

Так как инерфейс pe1 включен в интерфейс br-vni11025 то дальше трафик сожно наблюдать на бридже:
root@frr1:~# tcpdump -n -ee -i br-vni11025 

14:17:28.543751 a2:54:55:00:6d:09 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.98.2 tell 192.168.98.1, length 28
14:17:28.544413 ce:3b:3b:dc:8d:29 > a2:54:55:00:6d:09, ethertype ARP (0x0806), length 42: Reply 192.168.98.2 is-at ce:3b:3b:dc:8d:29, length 28
14:17:28.544442 a2:54:55:00:6d:09 > ce:3b:3b:dc:8d:29, ethertype IPv4 (0x0800), length 98: 192.168.98.1 > 192.168.98.2: ICMP echo request, id 7024, seq 1, length 64
14:17:28.544617 ce:3b:3b:dc:8d:29 > a2:54:55:00:6d:09, ethertype IPv4 (0x0800), length 98: 192.168.98.2 > 192.168.98.1: ICMP echo reply, id 7024, seq 1, length 64
14:17:29.545271 a2:54:55:00:6d:09 > ce:3b:3b:dc:8d:29, ethertype IPv4 (0x0800), length 98: 192.168.98.1 > 192.168.98.2: ICMP echo request, id 7024, seq 2, length 64
14:17:29.545584 ce:3b:3b:dc:8d:29 > a2:54:55:00:6d:09, ethertype IPv4 (0x0800), length 98: 192.168.98.2 > 192.168.98.1: ICMP echo reply, id 7024, seq 2, length 64
14:17:33.620718 ce:3b:3b:dc:8d:29 > a2:54:55:00:6d:09, ethertype ARP (0x0806), length 42: Request who-has 192.168.98.1 tell 192.168.98.2, length 28
14:17:33.620766 a2:54:55:00:6d:09 > ce:3b:3b:dc:8d:29, ethertype ARP (0x0806), length 42: Reply 192.168.98.1 is-at a2:54:55:00:6d:09, length 28

brctl showmacs br-vni11025 

port no	mac addr		is local?	ageing timer
  1	66:f8:b3:52:6b:af	yes		   0.00
  1	66:f8:b3:52:6b:af	yes		   0.00
  2	6e:2d:c8:13:c4:13	yes		   0.00
  2	6e:2d:c8:13:c4:13	yes		   0.00
  2	a2:54:55:00:6d:09	no		   0.76
  1	ce:3b:3b:dc:8d:29	no		11312.96
  1	ce:3b:3b:dc:8d:29	no		   0.76

Тут не указаны интерфейсы - а только номера портов, определить номера можно командой brctl showstp br-vni11025
Для простоты отфильтрую лишнее:
brctl showstp br-vni11025 | grep -E '\([0-9]\)' 

pe1 (2)
vxlan11025 (1)

Если подставить имена интерфейсов то таблица приобретет вид:
pe1 (2) a2:54:55:00:6d:09 no 0.76
vxlan11025 (1)ce:3b:3b:dc:8d:29 no 11312.96

Альтернативный способ

Проверить таблицы коммутации бриджа bridge -d fdb show dev br-vni11025 br-vni11025 

5e:24:03:80:73:0e vlan 1 master br-vni11025 permanent
5e:24:03:80:73:0e master br-vni11025 permanent

Тут не видно мак-адресов отправителя и получателя - a2:54:55:00:6d:09 и ce:3b:3b:dc:8d:29


Более правильно смотреть полную таблицу коммутации - тогда можно увидеть 

bridge fdb show | grep -E 'ce:3b:3b:dc:8d:29|a2:54:55:00:6d:09'
ce:3b:3b:dc:8d:29 dev vxlan11025 vlan 1 extern_learn master br-vni11025
ce:3b:3b:dc:8d:29 dev vxlan11025 extern_learn master br-vni11025
ce:3b:3b:dc:8d:29 dev vxlan11025 dst 192.168.32.102 self extern_learn
a2:54:55:00:6d:09 dev pe1 master br-vni11025

Тут видно что-то очень похожее:

  • a2:54:55:00:6d:09 dev pe1 master br-vni11025 - мак приходит со стороны pe1 через br-vni11025
  • ce:3b:3b:dc:8d:29 - я не знаю что означают эти записи точно, дальше идут мои предположения:
    • dev vxlan11025 - MAC-адрес пришёл по VXLAN-интерфейсу vxlan11025
    • vlan 1 - MAC-адрес относится к VLAN 1 (хороший вопрос, который меня всегда мучал - VLAN1 подразумевает отсутвие тега, а что будет если сделать такой интерфейс но с тегом?)
    • extern_learn - MAC-адрес был выучен внешним механизмом (BGP EVPN), а не традиционным L2-обучением.
    • master br-vni11025 vxlan11025 является частью бриджа br-vni11025

vxlan11025

Тут нет никаких неожиданностей:
root@frr1:~# tcpdump -n -ee -i vxlan11025 

14:17:28.543778 a2:54:55:00:6d:09 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.98.2 tell 192.168.98.1, length 28
14:17:28.544413 ce:3b:3b:dc:8d:29 > a2:54:55:00:6d:09, ethertype ARP (0x0806), length 42: Reply 192.168.98.2 is-at ce:3b:3b:dc:8d:29, length 28
14:17:28.544448 a2:54:55:00:6d:09 > ce:3b:3b:dc:8d:29, ethertype IPv4 (0x0800), length 98: 192.168.98.1 > 192.168.98.2: ICMP echo request, id 7024, seq 1, length 64
14:17:28.544617 ce:3b:3b:dc:8d:29 > a2:54:55:00:6d:09, ethertype IPv4 (0x0800), length 98: 192.168.98.2 > 192.168.98.1: ICMP echo reply, id 7024, seq 1, length 64
14:17:29.545282 a2:54:55:00:6d:09 > ce:3b:3b:dc:8d:29, ethertype IPv4 (0x0800), length 98: 192.168.98.1 > 192.168.98.2: ICMP echo request, id 7024, seq 2, length 64
14:17:29.545584 ce:3b:3b:dc:8d:29 > a2:54:55:00:6d:09, ethertype IPv4 (0x0800), length 98: 192.168.98.2 > 192.168.98.1: ICMP echo reply, id 7024, seq 2, length 64
14:17:33.620718 ce:3b:3b:dc:8d:29 > a2:54:55:00:6d:09, ethertype ARP (0x0806), length 42: Request who-has 192.168.98.1 tell 192.168.98.2, length 28
14:17:33.620768 a2:54:55:00:6d:09 > ce:3b:3b:dc:8d:29, ethertype ARP (0x0806), length 42: Reply 192.168.98.1 is-at a2:54:55:00:6d:09, length 28

tenant

Проверка инкапсуляции: tcpdump -ee -n -i tenant port 4789 

14:17:28.543791 00:99:00:00:00:01 > 00:99:00:00:22:01, ethertype IPv4 (0x0800), length 92: 192.168.32.101.34053 > 192.168.32.102.4789: VXLAN, flags [I] (0x08), vni 11025
a2:54:55:00:6d:09 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.98.2 tell 192.168.98.1, length 28
14:17:28.544413 00:99:00:00:22:01 > 00:99:00:00:00:01, ethertype IPv4 (0x0800), length 92: 192.168.32.102.48515 > 192.168.32.101.4789: VXLAN, flags [I] (0x08), vni 11025
ce:3b:3b:dc:8d:29 > a2:54:55:00:6d:09, ethertype ARP (0x0806), length 42: Reply 192.168.98.2 is-at ce:3b:3b:dc:8d:29, length 28
14:17:28.544460 00:99:00:00:00:01 > 00:99:00:00:22:01, ethertype IPv4 (0x0800), length 148: 192.168.32.101.43665 > 192.168.32.102.4789: VXLAN, flags [I] (0x08), vni 11025
a2:54:55:00:6d:09 > ce:3b:3b:dc:8d:29, ethertype IPv4 (0x0800), length 98: 192.168.98.1 > 192.168.98.2: ICMP echo request, id 7024, seq 1, length 64
14:17:28.544617 00:99:00:00:22:01 > 00:99:00:00:00:01, ethertype IPv4 (0x0800), length 148: 192.168.32.102.33214 > 192.168.32.101.4789: VXLAN, flags [I] (0x08), vni 11025
ce:3b:3b:dc:8d:29 > a2:54:55:00:6d:09, ethertype IPv4 (0x0800), length 98: 192.168.98.2 > 192.168.98.1: ICMP echo reply, id 7024, seq 1, length 64
14:17:29.545313 00:99:00:00:00:01 > 00:99:00:00:22:01, ethertype IPv4 (0x0800), length 148: 192.168.32.101.43665 > 192.168.32.102.4789: VXLAN, flags [I] (0x08), vni 11025
a2:54:55:00:6d:09 > ce:3b:3b:dc:8d:29, ethertype IPv4 (0x0800), length 98: 192.168.98.1 > 192.168.98.2: ICMP echo request, id 7024, seq 2, length 64
14:17:29.545584 00:99:00:00:22:01 > 00:99:00:00:00:01, ethertype IPv4 (0x0800), length 148: 192.168.32.102.33214 > 192.168.32.101.4789: VXLAN, flags [I] (0x08), vni 11025
ce:3b:3b:dc:8d:29 > a2:54:55:00:6d:09, ethertype IPv4 (0x0800), length 98: 192.168.98.2 > 192.168.98.1: ICMP echo reply, id 7024, seq 2, length 64
14:17:33.620718 00:99:00:00:22:01 > 00:99:00:00:00:01, ethertype IPv4 (0x0800), length 92: 192.168.32.102.48515 > 192.168.32.101.4789: VXLAN, flags [I] (0x08), vni 11025
ce:3b:3b:dc:8d:29 > a2:54:55:00:6d:09, ethertype ARP (0x0806), length 42: Request who-has 192.168.98.1 tell 192.168.98.2, length 28
14:17:33.620784 00:99:00:00:00:01 > 00:99:00:00:22:01, ethertype IPv4 (0x0800), length 92: 192.168.32.101.34053 > 192.168.32.102.4789: VXLAN, flags [I] (0x08), vni 11025
a2:54:55:00:6d:09 > ce:3b:3b:dc:8d:29, ethertype ARP (0x0806), length 42: Reply 192.168.98.1 is-at a2:54:55:00:6d:09, length 28
14:17:56.659011 00:99:00:00:22:01 > 00:99:00:00:00:01, ethertype IPv4 (0x0800), length 120: 192.168.32.102.57482 > 192.168.32.101.4789: VXLAN, flags [I] (0x08), vni 11025
66:f8:b3:52:6b:af > 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 70: fe80::64f8:b3ff:fe52:6baf > ff02::2: ICMP6, router solicitation, length 16
14:22:18.802890 00:99:00:00:22:01 > 00:99:00:00:00:01, ethertype IPv4 (0x0800), length 120: 192.168.32.102.38741 > 192.168.32.101.4789: VXLAN, flags [I] (0x08), vni 11025
ce:3b:3b:dc:8d:29 > 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 70: fe80::cc3b:3bff:fedc:8d29 > ff02::2: ICMP6, router solicitation, length 16

Тут четко видно что это VXLAN трафик идет между loopback интерфейсами роутеров FRR1 и FRR2, а ICMP идет инкапсулированным в VNI 11025

Добавление дополнительных VNI и проверка прохождения трафика для них

netplan

    tunnels:
        vxlan11025:
          mode: vxlan
          link: loopback0
          id: 11025
          mtu: 8950
          accept-ra: no
          neigh-suppress: true
          link-local: []
          mac-learning: false
          port: 4789
          local: 192.168.32.101
    virtual-ethernets:
        pe1:
            peer: ce1
        ce1:
            peer: pe1
            dhcp4: false
            dhcp6: false
            addresses: ["192.168.98.1/24"]
    bridges:
        br-vni11025:
            interfaces: ["vxlan11025", "pe1"]
            dhcp4: false
            dhcp6: false
            stp: false
  • Это пока не готово но в процессе

Next Steps

Следующие шаги:

Команды

  • show bgp summary
  • show evpn mac vni all
  • show bgp evpn vni
Источник — https://noname.com.ua/mediawiki/index.php?title=BGP_EVPN_FRR_simple&oldid=14218