BGP EVPN FRR simple

Минимальная конфигурация 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

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

• 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]

Уточнение: Тут присутвуют адреса 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

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

Как фильтровать какие 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

Обратить внимание - это маршрут типа 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

После того как тест завершен 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

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

• Дальше добавить к этой схеме железный роутер ASR1001

Команды

• show bgp summary

• show evpn mac vni all
• show bgp evpn vni