Минимальная конфигурация 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` и проверка прохождения трафика для них

Это пока не готово но в процессе

TODO и вопросы

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

VRF и как это совмещается с EVPN - для L2VPN пока не видно нужды в VRF
подключить Cisco ASR1001 к этой схеме (тут что-то есть Cisco_ASR1001_VxLAN)
L2EVPN?
??

Команды

show bgp summary

show evpn mac vni all
show bgp evpn vni

BGP EVPN FRR simple

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

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

PE

CE

BUM

VTEP

VNI

Схема сети

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

FRR1

FRR2

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

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

FRR1 OSPF

FRR2 OSPF

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

EVPN

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

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

FRR1

FRR1

Проверка BGP

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

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

Маршруты

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

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

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

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

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

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

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

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

FRR2

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

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

FRR1

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

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

Сопоставление мак-адресов и маршрутов

Мак-адреса CE

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

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

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

ping CE1 -> CE2

ce1

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

br-vni11025

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

vxlan11025

tenant

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

TODO и вопросы

Команды

Навигация

Поиск

`PE`

`CE`

`BUM`

`VNI`

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

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

Проверка `BGP`

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

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

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

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

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

Мак-адреса `CE`

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

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

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

`ping` `CE1` -> `CE2`

`ce1`

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

`br-vni11025`

`vxlan11025`

`tenant`

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