Просмотр кода страницы BGP EVPN FRR simple

Материал из noname.com.ua

← BGP EVPN FRR simple

У вас нет прав на выполнение действия «редактирование этой страницы» по следующей причине:

---

Вы можете просмотреть и скопировать исходный код этой страницы.

[[Категория:EVPN]] [[Категория:BGP]] [[Категория:Cisco]] [[Категория:FRR]] =Минимальная конфигурация EVPN по шагам= Это документ о настройке абсолютно минимальной конфигурации EVPN =Сокращения использованные в документе= ==<code>PE</code>== * <code>[[BGP_EVPN_FRR_simple#PE|PE]]</code>: Provider Edge - Маршрутизатор провайдера к которому подключены клиенты ==<code>CE</code>== * <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> =Схема сети= [[Файл:FRR BGP EVPN 1.drawio.png]] <BR> Оригинал: [[Файл:FRR BGP EVPN 1.drawio]] <BR> Тестовый стенд полностью виртуализирован. <BR> На этой схеме: * 2 маршрутизатора <code>FRR</code> выполняют роли <code>[[BGP_EVPN_FRR_simple#PE|PE]]</code> ** Сеть <code>tenant</code> используется как транспортная сеть между маршрутизаторами (<code>l2</code> сегмент) ** Каждый из [[BGP_EVPN_FRR_simple#PE|PE]] имеет по 1 подключеному <code>[[BGP_EVPN_FRR_simple#CE|CE]]</code> ** <code>[[BGP_EVPN_FRR_simple#CE|CE]]</code> максимально упрощены - это просто <code>IP</code> адрес поднятый на бридже (но конечно ничто не мешает использовать отдельную виртуальную машину, разницы нет) * Используется 1 интерфейс для поддключения <code>[[BGP_EVPN_FRR_simple#CE|CE]]</code> * Номер <code>[[BGP_EVPN_FRR_simple#VNI|VNI]]</code> выбран абсолютно произвольно, такое значение взято что бы оно случайно не совпало ни с каким другим и было заведомо больше максимального номера влана * Management сеть используется только для управлени маршрутизаторами (без нее можно обойтись, она не учавствует маршрутизации) Интерфейсы в этой сети названы <code>external</code> по историческим причинам. * Интерфейсы <code>loopback</code> изспользуются для построения сессий BGP =Настройка сети на маршрутизаторах= * Настройки на обоих маршрутизаторах идентичны (с точностью до адресов) * <code>dummy</code> поддерживается в относительно новых версиях <code>netplan</code> (Убунту 24.04 поддерживает) ==FRR1== <PRE> 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" </PRE> ==FRR2== <PRE> 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" </PRE> =Настройка демона FRR= Эта часть разделена на 2 части - не относящееся к <code>EVPN</code> выделено в отдельную часть ==Подготовительная настройка== * Запустить <code>OSPF</code> в сети tenant для того что бы получить доступность интерфейсов <code>loopback</code> * сделать редистрибьюцию маршрутов в OSPF (не уверене что нужно делать все три - <code>static</code>, <code>connected</code> и <code>kernel</code> даже скорее всего нет, но этот вопрос не относится к теме статьи) * тут можно вполне обойтись статикой без <code>OSPF</code> но так сделано для большей "достоверности" - как у настоящих провайдеров. <BR> Немного заметок про настройку <code>OSPF</code>: * <code>prefix-list REDISTRIBUTE- ... </code> - префикс-листы что бы ограничить редистрибьюцию в OSPF только /32 (ge) сетями из диапазона <code>192.168.32.0/24</code> * В работе <code>OSPF</code> учавствует только интерфейс <code>tenant</code> ( <code>no ip ospf passive</code>, <code>passive-interface defaul</code>) ===FRR1 OSPF=== <PRE> 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 </PRE> ===FRR2 OSPF=== <PRE> 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 </PRE> ==Проверка работы <code>OSPF</code>== Соседи видят друг-друга <code>frr1# show ip ospf neighbor</code> <PRE> 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 </PRE> <code>frr2# show ip ospf neighbor</code> <PRE> 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 </PRE> Просмотр базы данных <code>OSPF</code> (на примере frr2): <code>show ip ospf database</code> <PRE> 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] </PRE> {{caution|text= Уточнение: <BR> Тут присутвуют адреса <code>192.168.32.1</code> и <code>192.168.32.2</code> которых не должно быть. <BR> Это не ошибка, в лабе они присутвуют в виде статических маршрутов (в моем случае выданных по <code>DHCP</code>) и в <code>OSPF</code> они попали через редистрибьюцию так как тоже относятся к блоку <code>192.168.32.0/24</code> и имеют маску <code>/32</code>. В контексте <code>EVPN</code> их можно игнорировать. }} =EVPN= ==Cхема работы (приблизительная== Существует два типа информации о доступности сети, которую VTEP передает через BGP EVPN: * <code>[[BGP_EVPN_FRR_simple#VNI|VNI]]</code>, в которых они заинтересованы (маршруты L2???) * локальный MAC-адрес для каждого <code>[[BGP_EVPN_FRR_simple#VNI|VNI]]</code> (маршруты L2) ==Начальная настройка <code>BGP</code>== На начальном этапе в конфигурации отсутствуют <code>VxLAN</code> интерфейсы, пока просто проверка что <code>BGP</code>-сессия поднимаются нормально. * В качестве адреса используется интерфейс <code>loopback</code> - так как он всегда поднят, не зависит от физического состояния линка (адрес на нем может быть доступен через несколько линков в общем случае, при наличии динамической маршрутизации, это общаяя практика) * Номер <code>AS</code> - 65000 из частного диапазона, одинаковый на обоих маршрутизаторах * <code>neighbor fabric peer-group</code> - не смотря на то что у нас всего один neighbor описываем группу - так проще будет расширять * <code>bgp router-id 192.168.32.101</code> - задать идентификатор роутера (что бы он был однозначен а не выбран автоматически) * <code>neighbor fabric update-source 192.168.32.101</code> - указать с какого адреса отправлять обновления. Если этого не сделать то будет выбран адрес интерфейса, в результате пакеты будут уходить не с тем адресом который ожидает сосед, и сессия не поднимется. ("костыль" тут это использовать адреса интерфейсов) ===FRR1=== <PRE> 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 </PRE> ===FRR1=== <PRE> 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 </PRE> ==Проверка <code>BGP</code>== <code>frr1# show bgp summary</code> <PRE> 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 </PRE> <code>L2EVPN</code> не является IP что можно видеть по ошибке ниже: <BRE> <code>frr1# sho ip bgp summary</code> <PRE> % No BGP neighbors found in VRF default </PRE> <BR> Никаких маршрутов пока нет <code>frr1# show bgp</code> <PRE> No BGP prefixes displayed, 0 exist </PRE> ==Добавление конечных точек <code>VTEP</code>== '''Для начала добвляются конечные точки только на одно роутере - FRR1''' Для добавления VTEP используется скрипт, рассчитаный на добавление множества VTEP но в целях упрощения добавляем только один. * <code>seq 11025 11025</code> даст список из 1 элемента - 11025 * <code>LOCAL_IP="192.168.32.101"</code> - source-адрес <code>VxLAN</code>-тунелей (<code>loopback</code>, причины его использования такие же как и для BGP) * для FRR2 <code>LOCAL_IP="192.168.32.102"</code> <PRE> #!/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 </PRE> В результате работы скрипта будет создан 1 VxLAN-тунель и добавлен в бридж <PRE> 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 </PRE> <code># brctl show</code> <PRE> bridge name bridge id STP enabled interfaces br-vni11025 8000.5e240380730e no vxlan11025 </PRE> ==<code>BGP</code> после добавления конечных точек== Можно увидеть доступный <code>VNI</code> (номер его 11025 ожидаемо совпадает с добавленным) <BR> <code>show bgp evpn vni</code> <PRE> 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 </PRE> <BR> Однако маршрут в <code>BGP</code> отсутвует (<code>show bgp evpn route</code>) <BR> Для того что бы маршрут появился требуется добавить строчку в конфигурацию * <code>advertise-all-vni</code> <PRE> address-family l2vpn evpn neighbor fabric activate advertise-all-vni exit-address-family </PRE> После чего маршрут появляется в <code>BGP</code> {{caution|text= В случае нескольких <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> 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 </PRE> Или более подробно <PRE> 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) </PRE> Это [[BGP_EVPN_route_types#.D0.A2.D0.B8.D0.BF_3|Маршрут типа 3]] (подробно маршрут такого типа разобран по ссылке) <BR> <BR>Тип маршрута виден из <code>'''[3]''':[0]:[32]:[192.168.32.101]</code> выделенной части вывода <BR> Тут отмечу коротко что он означает: * [[BGP_EVPN#Route_Distinguisher|Route_Distinguisher]] 192.168.32.101:2 * <code>192.168.32.101:2:[3]:[0]:[32]:[192.168.32.101]</code> ** <code>[3]</code> - тип маршрута ** <code>[0]</code> - В случае типа 3 это вероятно (но не точно!) VLAN ID (уточнить) ** <code>[32]</code> длинна следующего поля - IPv4 ** <code>[192.168.32.101]</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>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>Extended Community: ET:8 RT:65000:11025 </code> ** <code>ET:8</code> Encapsulation Type 8 - тип зарезервированный за VxLAN ** <code>RT:65000:11025 </code> Route Target - поле на основании которого принимается решение куда (в какой VRF) помещать маршрут * <code>Last update: Thu Feb 13 10:52:39 2025 </code> - Очевидно? * <code>PMSI Tunnel Type: Ingress Replication, label: 11025 </code> ** <code>label: 11025</code> - <code>[[BGP_EVPN_FRR_simple#VNI|VNI]]</code> 11025 {{caution|text= Обратить внимание - это маршрут типа 3 и значит он применим только для '''B'''roadcast / '''U'''nknown Unicast / '''M'''ulticast (<code>[[BGP_EVPN_FRR_simple#BUM|BUM]]</code>) трафика }} ==Добавление <code>[[BGP_EVPN_FRR_simple#VNI|VNI]]</code> на втором роутере (FFR2)== После добавлениея интерфейса на втором роутере (тем же скриптом) и активации опции <code>advertise-all-vni</code> ожидаемо появляется второй маршрут (зеркальный по отношению к первому) <PRE> 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 </PRE> ==Проверка работы <code>[[BGP_EVPN_FRR_simple#BUM|BUM]]</code> трафика== После того как в таблице маршрутизации присутвует 2 маршрута (прямой и обратный) [[BGP_EVPN_route_types#.D0.A2.D0.B8.D0.BF_3|Типа 3]] ожидается что по ним можно будет отправлять например широковещательный трафик <BR> Проверка ===Добавить адреса на бриджи с обоих сторон==== FRR1 <PRE> ip addr add 192.168.99.1/24 dev br-vni11025 </PRE> FRR2 <PRE> ip addr add 192.168.99.2/24 dev br-vni11025 </PRE> ===Поднять бриджи=== Команда одинаковая на обоих FRR <PRE> ip link set up dev br-vni11025 </PRE> ===Проверить IP адрес=== Команда одинаковая на обоих FRR, пример для FFR2 <PRE> 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 </PRE> ===Проверить что маршрут указывает в правильный интерфейс=== <PRE> ip ro get 192.168.99.1 192.168.99.1 dev br-vni11025 src 192.168.99.2 uid 0 cache </PRE> ===Запустить ping с FRR2 (192.168.99.2) на FRR1 (192.168.99.1)=== Тут видно что на VXLAN есть arp-запросы <PRE> 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 </PRE> А на бридже есть как запросы так и ответы - но так как маршрут типа 3 только для <code>[[BGP_EVPN_FRR_simple#BUM|BUM]]</code> - трафика то ответы никуда дальше бриджа не уходят <PRE> 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 </PRE> {{caution|text= После того как тест завершен IP адреса нужно удалить так как они будут мешать в дальнейшем }} ==Подключение виртуальных <code>[[BGP_EVPN_FRR_simple#CE|CE]]</code>== Для имитации <code>[[BGP_EVPN_FRR_simple#CE|CE]]</code> я не буду создавать виртуальные машины, а использую просто veth один из которых включая в бридж, а второй "как бы" и есть <code>[[BGP_EVPN_FRR_simple#CE|CE]]</code> <BR> ===FRR2=== ====Настройка интерфейса FRR2==== Для начала добавляю конфигурацию на FRR2 <PRE> ip link add dev pe2 type veth peer name ce2 </PRE> <PRE> brctl addif br-vni11025 pe2 </PRE> <PRE> ip link set up dev pe2 </PRE> <PRE> ip link set up dev ce2 </PRE> Назначим адрес виртуальном <code>[[BGP_EVPN_FRR_simple#CE|CE2]]</code> <PRE> ip addr add 192.168.98.2/24 dev ce2 </PRE> ====Проверка BGP (FRR2)==== После добавления интерфейса можно видеть что в BGP появился дополнительный маршрут [[BGP_EVPN_route_types#.D0.A2.D0.B8.D0.BF_2|Типа 2]] <code>frr2# show bgp evpn route</code> <BR> <PRE> 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) </PRE> <code>frr2# show bgp evpn route detail</code> <PRE> 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) </PRE> Тут видно что появился дополнительный маршрут типа 2 <PRE> 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 </PRE> * <code>[2]</code> означает, что это Type 2 (MAC/IP Advertisement Route). * <code>[EthTag]</code> Ethernet Tag ID (обычно = 0 для VXLAN). В примере это тоже 0 * <code>[MAC]</code> MAC-адрес хоста. В примере это <code>ce:3b:3b:dc:8d:29</code> что соотвтевует мак-адресу "виртуального <code>[[BGP_EVPN_FRR_simple#CE|CE2]]</code>": <PRE> 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 </PRE> * <code>[IP]</code> (опционально) IP-адрес хоста, связанный с MAC. В примере отсутсвует ===FRR1=== ====Настройка интерфейса FRR1==== Анадлогичная конфигурация на FRR1 (с точностью до имен интерфейсов и IP адреса) <PRE> ip link add dev pe1 type veth peer name ce1 </PRE> <PRE> brctl addif br-vni11025 pe1 </PRE> <PRE> ip link set up dev pe1 </PRE> <PRE> ip link set up dev ce1 </PRE> Назначим адрес виртуальном CE1 <PRE> ip addr add 192.168.98.1/24 dev ce1 </PRE> ====Проверка BGP (FRR1)==== На FRR1 ожидаемо 4 маршрута - два типа 3 и 2 типа 2 (тип 2 - по одному для локального и удаленного мак-адреса) <code>frr1# show bgp evpn route</code> <PRE> 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) </PRE> =====Сопоставление мак-адресов и маршрутов===== На всякий случай можно сравнить МАК-адреса <BR> frr1 - интерфейс (виртуального) <code>[[BGP_EVPN_FRR_simple#CE|CE]]</code> <PRE> 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 </PRE> Соответвующий маршрут: <PRE> Route Distinguisher: 192.168.32.102:2 *>i [2]:[0]:[48]:[ce:3b:3b:dc:8d:29] 192.168.32.102 100 0 i </PRE> frr2 - интерфейс (виртуального) <code>[[BGP_EVPN_FRR_simple#CE|CE]]</code> <PRE> 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 </PRE> Соответвующий маршрут: <PRE> 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 </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> * Это пока не готово но в процессе =TODO и вопросы= Следующие шаги: * <code>VRF</code> и как это совмещается с <code>EVPN</code> - для <code>L2VPN</code> пока не видно нужды в <code>VRF</code> * подключить <code> Cisco ASR1001 к этой схеме</code> (тут что-то есть [[Cisco_ASR1001_VxLAN]]) * L2EVPN? * ?? =Команды= * <code>show bgp summary</code> * <code>show evpn mac vni all</code> * * <code>show bgp evpn vni</code> *

Возврат к странице BGP EVPN FRR simple.