paralon 27 фев в 13:44

FRRouting. Без кликбейтного названия

Средний

19 мин

8.5K

Сетевые технологии*Настройка Linux*Open source*

Репортаж

Предисловия тоже не будет. Погнали.

Давайте сделаем сеть без коммутаторов и маршрутизаторов

Вот есть у нас два хоста-клиента и есть один Linux. Хосты из одной подссети. Надо чтобы пообщаться смогли они друг с дружкой. В общем, свитчик D-link тупой сделать надо из Линукса:

Ну тут всё просто. Устанавливаем bridge-utils, создаём мостик, добавляем интерфейсы в мост, не забываем его поднять и вуаля:

apt install bridge-utils
brctl addbr Bridge1
brctl addif Bridge1 ens4
brctl addif Bridge1 ens5
ip link set up ens4
ip link set up ens5
ip link set up dev Bridge1

Пинги пошли между хостами. Ура, мы сделал самый тупой в мире свитч ). Даже маки видны:

root@ubuntu:~# brctl showmacs Bridge1 port no mac addr is local? ageing timer 2 00:50:79:66:68:32 no 84.50 1 00:50:79:66:68:33 no 84.50 1 50:4d:8c:00:35:01 yes 0.00 1 50:4d:8c:00:35:01 yes 0.00 2 50:4d:8c:00:35:02 yes 0.00 2 50:4d:8c:00:35:02 yes 0.00

Вот то, что "is not local" - это наши хосты.

Давайте теперь научим свитч понимать Vlan-ы, а второй Linux сделаем роутером простеньким.

Трафик от хоста будет заходить в "access" порт, метиться 802.1q тегом, уходить в "транк", а там, повыше, маршрутизироваться.

Теперь на Linux switch-е нам нужно два моста. По одному на каждый VLAN:

# Убиваем старый мост
ip link set down Bridge1
brctl delbr Bridge1
# Добавляем парочку новых
brctl addbr brVlan10
brctl addbr brVlan20
ip link set up brVlan10
ip link set up brVlan20
brctl addif brVlan10 ens4
brctl addif brVlan20 ens5
# Создаём интерфейсы типа Vlan на нашем "аплинке"
ip link add link ens6 name Vlan10 type vlan id 10
ip link add link ens6 name Vlan20 type vlan id 20
ip link set up dev ens6
# пихаем в мосты
brctl addif brVlan10 Vlan10
brctl addif brVlan20 Vlan20

Ок, теперь, если на первом хосте попробуем попингать шлюз и посмотрим что на ens6, увидим логичные арп-запросы, но помеченные dot1.q тегом номер 10:

Ответов нет - ответить некому. Настроим Linux-роутер, который выше стоит:

# Тут подымем пару интерфейсов типа влан и повесим адреса
ip link add link ens4 name SVI10 type vlan id 10
ip link add link ens4 name SVI20 type vlan id 20
ip link set up ens4
ip addr add 192.168.0.254/24 dev SVI10
ip addr add 172.16.0.254/24 dev SVI20

Теперь можем попингать отсюда наши хосты:

Но вот хосты попингать друг друга не могут, хотя наш новоиспечённый шлюз доступен:

Так мы же функцию роутинга забыли включить на Linux-роутере! Фиксим:

root@ubuntu:~# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 0
root@ubuntu:~# sysctl -w net.ipv4.ip_forward=1
net.ipv4.ip_forward = 1

Ну вот и пинги пошли

В общем, научились делать свитч и научились делать роутер из Линукса!

А теперь давайте выйдем в самый маленький в мире Интернет вот по такой схеме:

На схему добавим настоящий хардварный маршрутизатор, настроим P2P линк до Linux-роутера. Ну и сделаем то же самое со стороны Linux-а:

# Маршрутизатор обычный
True-Hardware-router-0#show run int et1
interface Ethernet1
   description Linux-router
   no switchport
   ip address 10.0.0.1/31

# Маршрутизатор необычный
ip addr add 10.0.0.0/31 dev ens5
ip link set up dev ens5

Пинги ходят между роутерами, но не ходят в Интернет из Линукса :(

Потому что Линукс понятия не имеет как добраться в этот наш Интернет - он ему и не нужон. Но мы ему поможем - добавим статический маршрут в Интернет через железный маршрутизатор:

ip r add 7.7.7.7/32 via 10.0.0.1 dev ens5

Теперь кайф:

Но мы ж не для Linux-а Интернет-то делали. Никому не нужна сетевая инфраструктура в вакууме - нам важно предоставить сервис конечным хостам. А что там сейчас?

Не выходит - трафик доходит до шлюза, и как-будто бы там и застревает, но если снять дамп на исходящем в Интернет интерфейсе, то увидим что трафик уходит в сторону железного роутера:

... а ответов нет :(

Если потрбалштутить дальше увидим, что пакет даже в Интернет уходит, и даже возвращается! А вот железный роутер не отправляет его обратно в нашу Linux-based локалку. Опять эти треклятые маршруты - он просто не знает где живут наши клиентские сети - маршрутизацию-то мы не настроили. Ну ок, добавим немного статики:

True-Hardware-router-0(config)#ip route 192.168.0.0/24 10.0.0.0
True-Hardware-router-0(config)#ip route 172.16.0.0/24 10.0.0.0

Теперь лучше:

Ну чтож, маршрутизацию мы наладили, но когда сеть становится большой - пилить ручками статические маршруты становится уныло, да и не безопасно с точки зрения стабильности сети. Нужен, конечно, какой-то IaC подход - когда статические маршруты по сети будет разливать бездумная машина, но пока современное сообщество к такому не готово, и доверяет эту задачу динамическим протоколам маршрутизации. Но для таких протоколов, нужен какой-то control plane - какой-то демон (или много демонов), который будет общаться с рядом стоящими маршрутизаторами и обмениваться с ними полезной информацией, а ещё лучше потом и в data plane маршрутики программировать.

Встречайте, FRR!

Практика важнее теории, поэтому давайте просто установим FRR командой

apt install frr

и для чистоты эксперимента грохнем наши статические маршруты, которые мы ручками настроили:

#Linux
root@Linux-simple-router:~# ip r del 7.7.7.7/32 via 10.0.0.1 dev ens5

# Железяка:
True-Hardware-router-0(config)#no ip route 172.16.0.0/24 10.0.0.0
True-Hardware-router-0(config)#no ip route 192.168.0.0/24 10.0.0.0

А теперь настроим между двумя маршрутизаторам самый модный протокол динамической маршрутизации - RIP

В /etc/frr/daemons на линуксе включим RIP и перезапустим frr

sudo sed -i 's/^ripd=no/ripd=yes/' /etc/frr/daemons
sudo systemctl restart frr

Далее заходим через vtysh в командную строку frr-а, и там нас ждёт приятный cisco-like cli, через который мы и настроем RIP:

Linux-simple-router# show run ripd
Building configuration...
...
router rip
 network 172.16.0.0/24
 network 192.168.0.0/24
 network 10.0.0.0/31
exit
!
end

Провернём зеркальную операцию с обратной стороны:

True-Hardware-router-0#show run | sec router.rip
router rip
   network 7.7.7.0/24
   network 10.0.0.0/31
   no shutdown

Глядим - маршруты пришли, видны в таблице маршрутизации в FRR-е:

Linux-simple-router# show ip ro rip

R>* 7.7.7.0/24 [120/2] via 10.0.0.1, ens5, weight 1, 04:46:17

...и даже в ядре Linux-а

Показывать связанность от хоста в "Интернет" не буду - верим мне тут на слово. Да и это уже не важно. А важно то, что мы с помощью FRR-а наполнили таблицу маршрутизации нашего хоста маршрутами из внешних источников.

Что же такое этот наш "FRR"? Пару-тройку фактов приведу. Основное можно прочитать в Гугле, в любой модной LLM или в конце концов на сайте https://frrouting.org/ :

Набор протоколов маршрутизации для Linux (и кажется других Unix тоже)
Форк проекта Quagga (от 2017-го), которая сама является форком проекта Zebra (от 2003-го), которая была создана когда-то в 90-е...
Поддержка всяких разных протоколов:
- Простых и скучных, типа RIP, OSPF, ISIS, BGP, LDP
- Сложных и весёлых, типа NHRP, MP-BGP (в т.ч. EVPN), Babel и даже сигналку для сервисов поверх SRv6 умеет
Основные контрибуторы проекта NVIDIA, Dell, Microsoft. Такие Network OS как Кумулус (https://www.nvidia.com/en-eu/networking/ethernet-switching/cumulus-linux/) и Соник (https://sonicfoundation.dev/) имеют под капотом FRR

Вот и вся теория про FRR. Дальше небольшое отступление про то, как это концептуально работает, и погнали дальше усложнять нашу сеть.

Небольшое напоминание, что у любого современного маршруторизатора есть несколько "плейнов" - нам важны Control Plane и Data Plane. Если очень грубо,то Датаплейн - занимается перекладыванием пакетов из одного интерфейса в другой. А правила, по которым это происходит, ему (датаплейну) доносит контролплейн. Контролплейн - мозги, датаплейн - руки\ноги\сердце. Вот картинка от Ивана:

https://blog.ipspace.net/2013/08/management-control-and-data-planes-in/

А вот ещё от руки:

Всякие протоколы трудятся и делают свои таблички независимо. Потом приходит какой-то арбитр и по каким-то критериям делает одну единую табличку, выбирая кто более лучший - формирует Routing Information Base (RIB). А дальше всё это программируется в хардварный чип и получается Forwarding Information Base. Ну это база, я просто напоминаю.

С другой стороны у Linux-а есть User Space и Kernel Space. Дальше картинка-напоминалка (Я не знаю где её первоисточник, встречал в Интернете без указания авторства. Если кто знает автора и место где она засветилась первый раз - напишите, добавлю копирайт):

Если очень грубо - то в Kernel Space работает операционная система, и что важно для нас - форвардинг трафика (это, конечно, в общем случае, потому что есть известные кейсы где обработку трафика переносим в User Space - типа dpdk и всё такое)

А в User Space работают приложения. Ну например FRR и его демоны.

Собирая всю мозаику воедино получаем такое вот:

https://docs.nvidia.com/networking-ethernet-software/cumulus-linux-510/Layer-3/FRRouting

ControlPlane - в юзерспейсе, DataPlane - в кернелспейсе.

Остаётся мутный пункт с тем, как же маршруты из юзерспейса запихать в ядро. Ну а если приглядеться есть какой-то непонятный netlink между ними. Netlink, если грубо, это некий интерфейс для общения между UserSpace и KernelSpace. Со своим "протоколом", то бишь стандартом общения, что очевидно, потому что было бы странно, если бы было бы иначе.

Наверное, лучшей литературой по тому, как устроен Netlink является kernel.org, конечно (https://docs.kernel.org/userspace-api/netlink/intro.html), ну и описание библиотеки для работы с этими самым Netlink-ом - https://www.infradead.org/~tgr/libnl/doc/core.html . Но там много матана - моя не понимать совсем ничего :( А лучшей русскоязычной статьёй, что я нашёл является вот эта - https://habr.com/ru/articles/121254/ - матана там не меньше, но он хотя бы на русском и с комментариями. В общем, история, в первую очередь, программистская.

Ну а для сетевиков есть дамп трафика, который можно посмотреть в ваершарке. Давайте пока перестанем анонсировать маршрут из "Интернета", включим модуль ядра, чтобы подглядывать за netlink-ом и подглядим за ним:

# выключаем аплинк в сторону Интернета
True-Hardware-router-0(config)#interface Ethernet2
True-Hardware-router-0(config-if-Et2)#shutdown 
###
root@Linux-simple-router:~# modprobe nlmon
root@Linux-simple-router:~# ip link add nlmon0 type nlmon
root@Linux-simple-router:~# ip link set nlmon0 up

После этого у нас в системе появился интерфейс nlmon0 и, включив анонс сети обратно, мы можем посмотреть, что нам нём происходит обычным советским tcpdump-ом:

Включаем анонс сети с соседнего маршрутизатора

Ничего, конечно, не понятно, нужен ваершарк:

Тут тоже много всякого. Нам нужно отфильтровать по "netlink-route.rt_family == 2" - то есть смотрим анонсы IPv4 маршрутов. А не, там тоже много всего получится. Мы ищем что-нибудь про сеть 7.7.7.0, давайте превратим её в 16-ричное число и попробуем поискать в поле "Data" атрибута netlink-сообщения - "netlink.attr_data == 07.07.07.00":

Вот оно, прямо из юзерспейса в кёрнелспейс улеает

Выделил на картинке то, что может быть важно - есть маршрут на сеть, есть маска маршрута, есть некстхоп, есть исходящий интерфейс - что ещё нужно для счастливого маршрута?

Ок, с теорией вроде бы разобрались. Этого должно хватить на пару лет эксплуатации. Погнали сделаем что-нибудь повеселее!

Оверлеи с помощью FRR. MPLS

Как все знают, MPLS сам по себе не может являться целью. MPLS нужен для сервисов. Настроим самый типовой кейс - L3 VPN, вот с такой топологией:

Всё что кругленькое - это обычные убунты

Есть пару vrf-aware роутеров, в которые втыкаются клиенты (Provider Edge - PE) и ядро сети, которое про эти VRF-ы не знает, а просто обеспечит нам транспорт от PE к PE. Ну а сам пользовательский трафик мы обернём MPLS меточками и затуннелируем.

Для начала нужно, конечно, сказать Linux-ам, что бы они теперь превратились в MPLS-aware маршрутизаторы:

# Включаем опции ядра
modprobe mpls_router
modprobe mpls_iptunnel
modprobe mpls_gso
# Включаем обработку MPLS меток на интерфейсах:
sysctl -w net.mpls.conf.ens4.input=1
sysctl -w net.mpls.conf.ens5.input=1
sysctl -w net.mpls.conf.ens6.input=1
# Сколько меток сможем использовать. Мильёна должно хватить сегодня
sysctl -w net.mpls.platform_labels=1048575

IP-линки между маршрутизаторами настраивать мы уже умеем, главное ещё не забыть про "sysctl -w net.ipv4.ip_forward=1" везде.

Теперь осталось наделать красных и зелёных vrf-ов на наших PE-шках:

Красный хост слева настраиваем простенько - IP да шлюз, остальные делаем по аналогии:

Интерфейсы на PE слева пока не настроены:

Поместим их в VRF-ы и повесим адреса!

# Делаем vrf и привязываем его к выделенной таблице маршрутизации
sudo ip link add vrf-Red type vrf table 1001
sudo ip link set dev vrf-Red up

# Запихиваем наш интерфейс в этот vrf, включаем его и вешаем адрес
sudo ip link set dev ens6  master vrf-Red
sudo ip addr add 192.168.0.254/24 dev ens6
sudo ip link set dev ens6 up

Теперь можно посмотреть состояние vrf-а, какие интерфейсы к нему привязаны и его таблицу маршрутизации

Аналогично делаем для зелёного vrf-а, не забывая, что нам надо привязать его к другой таблице маршрутизации для изоляции трафика:

sudo ip link add vrf-Green type vrf table 1002
sudo ip link set dev vrf-Green up
sudo ip link set dev ens7  master vrf-Green
sudo ip addr add 172.16.0.254/24 dev ens7
sudo ip link set dev ens7 up

Теперь хосты могут пингать свои шлюзы, но не могу пингать друг друга, так как находятся в разных VRF-ах:

На правом PE делаем всё по аналогии, но добавим немного энтропии, используя другие таблицы маршрутизации и другие имена VRF, чтобы показать что это всё значимо лишь локально:

# Один vrf:
sudo ip link add vrf-R type vrf table 108
sudo ip link set dev vrf-R up
sudo ip link set dev ens5  master vrf-R
sudo ip addr add 192.168.1.254/24 dev ens5
sudo ip link set dev ens5 up

# И второй:
sudo ip link add vrf-G type vrf table 109
sudo ip link set dev vrf-G up
sudo ip link set dev ens6  master vrf-G
sudo ip addr add 172.16.1.254/24 dev ens6
sudo ip link set dev ens6 up

Ну и можно проверить доступность хостов прям попингав их из vrf-ов:

Как видим из vrf-G хост в "красном" vrf-е не пингается - ибо нефиг

Что ещё нужно сделать, перед тем как приступить к настройке MPLS-ной обвязки через FRR - добавить на всех линукс-маршрутизаторах по новому Loopback интерфейсу - его и будем использовать для всех служебных протоколов (не забываем включить на интерфейсе работу с MPLS-ом)

 ip link add name lo1 type dummy
 ip link set dev lo1 up
 sysctl -w net.mpls.conf.lo1.input=1

Ок, кажется всё что надо было сделать внутри Linux-а сделано. Дальше работаем исключительно с FRR-ом. Ещё раз напомню схему:

План такой:

1) Настраиваем единый OSFP домен, чтобы обменятся адресацией лупбеков

2) Настраиваем MPLS LDP, чтобы обменяться транспортными метками

3) Когда левый PE сможет достучаться до правого используя MPLS - добавим немного MP-BGP магии для обмена сервисными MPLS метками и VRF-ными маршрутами

4) ???
5) PROFIT!

Настройку первых двух пунктов буду показывать на примере связки PE-LEFT <--> P2 - все остальные связанности настраиваются аналогично.

# Заходим в консоль FRR-а:
root@Linux-PE-Left-1:~# vtysh

Hello, this is FRRouting (version 8.1).
Copyright 1996-2005 Kunihiro Ishiguro, et al.

# Все конфигурационные действия делаем из режима конфигурации:
Linux-PE-Left-1# conf t

# Настраиваем адреса на лупбеках:
Linux-PE-Left-1(config)# int lo1
Linux-PE-Left-1(config-if)# ip address 1.1.1.1/32

На этом моменте на левом PE проверяем таблицу маршрутизации чтобы убедиться, что мы не видим маршрутов на P2, а видим только connected сети:

Дальше настраиваем OSPF, включаем его на лупбеке новом и на интерфейсах в сторону других роутеров:

#### Левый PE:
Linux-PE-Left-1# conf t
Linux-PE-Left-1(config)# router ospf
Linux-PE-Left-1(config-router)# network 1.1.1.1/32 area 0
Linux-PE-Left-1(config-router)# network 10.1.2.0/31 area 0
Linux-PE-Left-1(config-router)# network 10.1.3.0/31 area 0

#### P2:
Linux-P-2(config)# router ospf
ospfd is not running
Linux-P-2(config-router)#

Такс...на P2 кажется что-то пошло не так - osfpd там не запущен (странно, что на PE левом такой ошибки не было, скорее всего я настроил там демон раньше - ну Бог мне судья). В общем, исправляемся - включаем osfpd, ldpd и bgpd сразу (хоть он нужен не везде) путём правки файла /etc/frr/daemons:

sudo sed -i 's/^ospfd=no/ospfd=yes/' /etc/frr/daemons
sudo sed -i 's/^ldpd=no/ldpd=yes/' /etc/frr/daemons
sudo sed -i 's/^bgpd=no/bgpd=yes/' /etc/frr/daemons
# рестартим FRR
sudo systemctl restart frr

и смотрим в статусе что у нас все нужные демоны - "Зелёные - Ок":

Донастроим таки OSFP на P2. Делаем вот такой конфиг:

router ospf
 network 2.2.2.2/32 area 0
 network 10.1.2.0/31 area 0
 network 10.2.4.0/31 area 0
exit
# Не забываем сделать "wr" ибо при рестарте FRR-а все пропадёт
Linux-P-2# wr
Note: this version of vtysh never writes vtysh.conf
Building Configuration...
Integrated configuration saved to /etc/frr/frr.conf
[OK]

Если в этот момент посмотреть в дамп трафика между PE-Left и P2 увидим там приятные сообщения про OSFP - сессии установились, LSA разлетелись:

Роутеры подружились друг с другом:

Таблицы маршрутизации наполнились. Лупбеки разлетелись, роутеры могут пингать друг друга по лупбекам:

Раскатываем эту шляпу (настройки OSFP) на всех остальных роутерах и дальше приступаем к настройке LDP:

# LDP настраиваем максимально просто 
# настраиваем router-id, включаем на интерфейсах нам нужных 
# + указываем какой адрес использовать для построения TCP:
mpls ldp
 router-id 1.1.1.1
 address-family ipv4
  discovery transport-address 1.1.1.1
  interface ens4
  interface ens5

То же самое на P2, и смотрим дамп:

Соседства поднялись:

Меточки настроились:

Раскатываем теперь и эту шляпу (LDP) по всем маршрутизаторам. И теперь если мы попингаем с лупбека левого PE (1.1.1.1) лупбек правого PE (5.5.5.5) при этом посмотрим дамп трафика где нибудь между P2 и P4 увидим что трафик оборачивается в MPLS меточку:

Как будто бы всё работает. Но ещё раз - сам по себе MPLS никого профита нам не даёт, нам нужны сервисы!

Для сервисов нужен BGP в адресном семействе VPNv4. BGP будет строится между левым и правым PE:

# Делаем на левом PE
router bgp 65001
 bgp router-id 1.1.1.1
 neighbor 5.5.5.5 remote-as 65001
 !
 address-family vpnv4 unicast
  neighbor 5.5.5.5 activate
  neighbor 5.5.5.5 send-community extended
  exit-address-family

#############################
# Делаем на правом:
router bgp 65001
 bgp router-id 5.5.5.5
 neighbor 1.1.1.1 remote-as 65001
 neighbor 1.1.1.1 update-source 5.5.5.5
 !
 address-family ipv4 vpn
  neighbor 1.1.1.1 activate
 exit-address-family
exit

BGP поднялись на обоих PE-шках, но пока никто никому ничего не анонсирует:

А в Ipv4 AF мы и не планируем ничего анонсировать. Можно вообще сессию убить:

# ==  PE Left: == 
router bgp 65001
 address-family ipv4 unicast
  no neighbor 5.5.5.5 activate
 exit-address-family

# ==  PE Right: == 
router bgp 65001
 address-family ipv4 unicast
  no neighbor 1.1.1.1 activate
 exit-address-family

Теперь собственно осталось добавить анонсы маршрутов из VRF-ов.

Сейчас таблицы маршрутизации в vrf-ах вот такие вот. Видны лишь локальные connected маршруты:

Доподнастроим наш BGP процесс примерно вот таким образом:

# Настраиваем PE левый
# Для зелёного vrf-а:
router bgp 65001 vrf vrf-Green
address-family ipv4 unicast
  redistribute connected
  label vpn export auto
  rd vpn export 1.1.1.1:2
  rt vpn both 65001:2
  export vpn
  import vpn
 exit-address-family
exit

# и красного:

router bgp 65001 vrf vrf-Red

 address-family ipv4 unicast
  redistribute connected
  label vpn export auto
  rd vpn export 1.1.1.1:3
  rt vpn both 65001:3
  export vpn
  import vpn
 exit-address-family
exit

Не забываем следить за всеми RD\RT делами. Зачем всё это нужно, конечно, читать вот тут - https://linkmeup.gitbook.io/sdsm/11.-mpls-l3vpn/5.-faq

После зеркальной настройки с другой стороны (RT лучше сделать одинаковым для каждого vrf-а, а RD - уникальным для связки маршрутизатор+vrf), мы должны увидеть что в VPN4 AF начали отправляться и приниматься какие-то маршруты, и не просто так а отмаркированные каким-то коммунити и меточками:

И маршрутики успешно встали в таблички маршрутизации соответствющих vrf-чиков:

С точки зрения ядра мы видим маршруты в vrf-е тоже и даже написано какие меточки надо добавить где:

Эти меточки можно расшифровать так:

Ну и теперь проверим вот эту вот связанность в красном vrf-е,например:

И, если встанем где-нибудь ваершаком между P2 и P4, увидим красивое:

Как положено - одна меточка для сервиса (vrf-а), другая - для транспорта

Ну всё, хватит с нас MPLS-а.

Оверлеи с помощью FRR. EVPN\VXLAN и немного магии.

А теперь моднейший EVPN\VXLAN с задачей сделать L2VPN. Нужно собрать вот такую топологию:

Условия три:

1) Все сетевые устройства - линукс хосты с FRR-ом.

2) Между сетевыми устройствами только IP маршрутизация - никаких VLAN-ов мы не растягиваем.

3) Надо предоставить L2 связанность между зелёными хостами, чтобы они думали что они в одном броадкаст домене как-будто.

Но мне это всё очень лень делать руками. Очень. Поэтому я прибегну к помощи обычного советского YAML-а. Да, попробую собрать всю лабу с помощью одного маленького YAML-а.

Делать я буду это с помощью проекта netlab tools - https://netlab.tools/

Как его устанавливать, пользоваться и вообще зачем он нужОн я подробно писал в своей вот этой крутой статье - https://t.me/NetArchNotes/14 . Потому лучше прочесть сначала её, чтобы понимать что дальше будет происходить - ибо иначе это реально может казаться магией.

Итак, я захожу на хост, где у меня уже установлен netlab tools + containerlab ( https://containerlab.dev/ - это "провайдер" контейнеризированных сетевых устройств для netlab), делаю там пустую папку и делаю там новый пустой файл topology.yml:

roman@netlab-test:~$ 
roman@netlab-test:~$ mkdir Magic_EVPN_LAB
roman@netlab-test:~$ cd Magic_EVPN_LAB/
roman@netlab-test:~/Magic_EVPN_LAB$ touch topology.yml
roman@netlab-test:~/Magic_EVPN_LAB$ cat topology.yml

Файл пустой, в него я вставлю вот такой yaml с попутными комментариями:

---
# Указываем containerlab в качестве провайдера виртуализации
provider: clab

# По умолчанию все устройства будут FRR-ы
defaults.device: frr

# Подключаем плагин "fabric" - эта обвязка автоматически соберёт нам Leaf-Spine топологию
plugin: [ fabric ]

# нам нужно два спайна и три лифа
fabric.spines: 2
fabric.leafs: 3

# ASN для BGP по умолчанию будет такой
bgp.as: 65000


# описываем общие параметры для групп
groups:
  # если объектов в группе нет - создём их автоматом
  _auto_create: True
  # какие модули буду использованы на лифах
  # нам нужен osfp для андерлей, bgp для оверлея
  # EVPN конечно, сам vxlan и vlan-ы чтобы разместить в хосты в разных вланах
  leafs:
    module: [ospf,bgp,evpn,vxlan,vlan]
  # какие модули будут использованы на спайнах
  # так же указываем что спайны будут выполнять функцию route-reflector-ов для bgp
  spines:
    module: [ospf,bgp,evpn]
    bgp.rr: True

  # Сделаем четыре хоста из линуксов
  hosts:
    members: [GreenHost1, GreenHost2, RedHost1, RedHost2]
    device: linux

# Самый тупой режим настройки vlan-ов - просто бриджуем всё что в одном влане
# без всякого роутинга
vlan.mode: bridge

# тут мы во-первых "втыкаем" хосты в лифы
# во вторых - на созданные линки вешаем VLAN-ы - Зелёный и Красный, как на схеме)
vlans:
  Green:
    links: [GreenHost1-L1,GreenHost2-L3]
  Red:
    links: [RedHost1-L2, RedHost2-L3]

Всё)

Дальше просто запускаем это воооот такой командочкой - "sudo netlab up" , и смотрим на магию. Пару скринов того, что происходит:

Отрабатывает вся машинерия, которая создаёт и запускает все необходимые контейнеры (FRR как сетевые устройства + обычные alpine как хосты), собирает это всё в нужную топологию, создаёт все необходимые бриджы на хосте, пробегается по хостам ансиблом и разливает все необходимые конфиги.

Смотрим, что получилось:

Лифы и спайны с FRR-ом и хосты c линуксами. Можно посмотреть как это выглядит в графическом виде, создаём графическую топологию:

Содержимое вот:

graph {
  bgcolor="transparent"
  node [shape=box, style="rounded,filled" fontname=Verdana]
  edge [fontname=Verdana labelfontsize=10 labeldistance=1.5]
  subgraph cluster_AS_65000 {
    bgcolor="#e8e8e8"
    fontname=Verdana
    margin=16
    label="AS 65000"
    "L1" [
      label="L1 [frr]\n10.0.0.1/32"
      fillcolor="#ff9f01"
      margin="0.3,0.1"
    ]
    "L2" [
      label="L2 [frr]\n10.0.0.2/32"
      fillcolor="#ff9f01"
      margin="0.3,0.1"
    ]
    "L3" [
      label="L3 [frr]\n10.0.0.3/32"
      fillcolor="#ff9f01"
      margin="0.3,0.1"
    ]
    "S1" [
      label="S1 [frr]\n10.0.0.4/32"
      fillcolor="#ff9f01"
      margin="0.3,0.1"
    ]
    "S2" [
      label="S2 [frr]\n10.0.0.5/32"
      fillcolor="#ff9f01"
      margin="0.3,0.1"
    ]
  }
 "L1" -- "S1" [ ]
 "L1" -- "S2" [ ]
 "L2" -- "S1" [ ]
 "L2" -- "S2" [ ]
 "L3" -- "S1" [ ]
 "L3" -- "S2" [ ]
  "Magic_EVPN_7" [style=filled fillcolor="#d1bfab" fontsize=11 margin="0.3,0.1" label="172.16.0.0/24"]
 "GreenHost1" -- "Magic_EVPN_7" [  ]
 "L1" -- "Magic_EVPN_7" [  ]
  "Magic_EVPN_8" [style=filled fillcolor="#d1bfab" fontsize=11 margin="0.3,0.1" label="172.16.0.0/24"]
 "GreenHost2" -- "Magic_EVPN_8" [  ]
 "L3" -- "Magic_EVPN_8" [  ]
  "Magic_EVPN_9" [style=filled fillcolor="#d1bfab" fontsize=11 margin="0.3,0.1" label="172.16.1.0/24"]
 "RedHost1" -- "Magic_EVPN_9" [  ]
 "L2" -- "Magic_EVPN_9" [  ]
  "Magic_EVPN_10" [style=filled fillcolor="#d1bfab" fontsize=11 margin="0.3,0.1" label="172.16.1.0/24"]
 "RedHost2" -- "Magic_EVPN_10" [  ]
 "L3" -- "Magic_EVPN_10" [  ]
}

Парсить это в голове сложно, давайте сходим например сюда -https://dreampuf.github.io/GraphvizOnline и превратим эти буковки с цифорками в картиночку:

Давайте попробуем провалиться в shell Зелёного Хоста номер 1 и попингать Зелёный Хост номер 2:

Так, в шелл то попали, но что пингать - не понятно, но зато мы теперь знаем IP нашего GreenHost1 - 172.16.0.6 и его mac-адрес - aa:c1:ab:20:fd:4b. Давайте с другой стороны зайдём:

Вуаля, пинги ходят, сосед виден, как родной. А что там на лифе 1, например?

Идём в shell, попадаем в Linux, заходим уже привычным путём в консоль FRR-а и глядим что там нетлаб нам наконфигурил (в этот раз листинг вставлю текстом, так уж и быть):

GreenHost2:/# exit
roman@netlab-test:~/Magic_EVPN_LAB$ sudo netlab connect L1
Connecting to container clab-Magic_EVPN_L-L1, starting bash

Use vtysh to connect to FRR daemon

L1(bash)# 
L1(bash)# vtysh

Hello, this is FRRouting (version 10.0.1_git).
Copyright 1996-2005 Kunihiro Ishiguro, et al.

2025/02/26 16:30:19 [YDG3W-JND95] FD Limit set: 1048576 is stupidly large.  Is this what you intended?  Consider using --limit-fds also limiting size to 100000
L1# 
L1# 
L1# 
L1# show run
Building configuration...

Current configuration:
!
frr version 10.0.1_git
frr defaults datacenter
hostname L1
no ipv6 forwarding
service integrated-vtysh-config
!
vrf mgmt
exit-vrf
!
interface eth1
 description L1 -> S1
 ip address 10.1.0.1/30
 ip ospf area 0.0.0.0
 ip ospf network point-to-point
exit
!
interface eth2
 description L1 -> S2
 ip address 10.1.0.5/30
 ip ospf area 0.0.0.0
 ip ospf network point-to-point
exit
!
interface eth3
 description [Access VLAN Green] L1 -> GreenHost1
exit
!
interface lo
 ip address 10.0.0.1/32
 ip ospf area 0.0.0.0
exit
!
interface vlan1000
 description VLAN Green (1000) -> [GreenHost1,GreenHost2,L3]
exit
!
router bgp 65000
 bgp router-id 10.0.0.1
 no bgp default ipv4-unicast
 bgp bestpath as-path multipath-relax
 neighbor 10.0.0.4 remote-as 65000
 neighbor 10.0.0.4 description S1
 neighbor 10.0.0.4 update-source lo
 neighbor 10.0.0.5 remote-as 65000
 neighbor 10.0.0.5 description S2
 neighbor 10.0.0.5 update-source lo
 !
 address-family ipv4 unicast
  network 10.0.0.1/32
  neighbor 10.0.0.4 activate
  neighbor 10.0.0.4 next-hop-self
  neighbor 10.0.0.5 activate
  neighbor 10.0.0.5 next-hop-self
 exit-address-family
 !
 address-family l2vpn evpn
  neighbor 10.0.0.4 activate
  neighbor 10.0.0.4 soft-reconfiguration inbound
  neighbor 10.0.0.5 activate
  neighbor 10.0.0.5 soft-reconfiguration inbound
  advertise-all-vni
  vni 101000
   rd 10.0.0.1:1000
   route-target import 65000:1000
   route-target export 65000:1000
  exit-vni
  advertise-svi-ip
  advertise ipv4 unicast
 exit-address-family
exit
!
router ospf
 ospf router-id 10.0.0.1
 timers throttle spf 10 50 500
 timers throttle lsa all 100
 timers lsa min-arrival 100
exit
!
end

Контейнер, куда мы провалились - это Linux с запущенным там FRR-ом. Там настроены обычные L3 линки до спайнов. До них же настроен OSFP:

OSFP нужен для того, что бы обменяться лупбеками - чтобы все лифы могли видеть друг друга и спайны. Потом строятся BGP EVPN сессии до этих самых спайнов:

Каждый лиф делает ЭТО с каждым спайном, и отдаёт ему свои локальные EVPN маршруты, получая в замен маршруты от других лифов. Именно за счёт этого, в конечном итоге, достигается связанность по L2 между хостами:

Как, почему и зачем работает EVPN\VXLAN хорошо рассказывают на курсе https://otus.ru/lessons/network_design/

Вот на всякий случай ещё конфиг FRR-а со спайна, чтобы уж наконец-то ВСЁ СТАЛО ПОНЯТНО:

L1(bash)# exit
logout
roman@netlab-test:~/Magic_EVPN_LAB$ sudo netlab connect S1
Connecting to container clab-Magic_EVPN_L-S1, starting bash

Use vtysh to connect to FRR daemon

S1(bash)# vtysh

Hello, this is FRRouting (version 10.0.1_git).
Copyright 1996-2005 Kunihiro Ishiguro, et al.

2025/02/26 16:43:11 [YDG3W-JND95] FD Limit set: 1048576 is stupidly large.  Is this what you intended?  Consider using --limit-fds also limiting size to 100000
S1# show run
Building configuration...

Current configuration:
!
frr version 10.0.1_git
frr defaults datacenter
hostname S1
no ipv6 forwarding
service integrated-vtysh-config
!
vrf mgmt
exit-vrf
!
interface eth1
 description S1 -> L1
 ip address 10.1.0.2/30
 ip ospf area 0.0.0.0
 ip ospf network point-to-point
exit
!
interface eth2
 description S1 -> L2
 ip address 10.1.0.10/30
 ip ospf area 0.0.0.0
 ip ospf network point-to-point
exit
!
interface eth3
 description S1 -> L3
 ip address 10.1.0.18/30
 ip ospf area 0.0.0.0
 ip ospf network point-to-point
exit
!
interface lo
 ip address 10.0.0.4/32
 ip ospf area 0.0.0.0
exit
!
router bgp 65000
 bgp router-id 10.0.0.4
 no bgp default ipv4-unicast
 bgp cluster-id 10.0.0.4
 bgp bestpath as-path multipath-relax
 neighbor 10.0.0.1 remote-as 65000
 neighbor 10.0.0.1 description L1
 neighbor 10.0.0.1 update-source lo
 neighbor 10.0.0.2 remote-as 65000
 neighbor 10.0.0.2 description L2
 neighbor 10.0.0.2 update-source lo
 neighbor 10.0.0.3 remote-as 65000
 neighbor 10.0.0.3 description L3
 neighbor 10.0.0.3 update-source lo
 neighbor 10.0.0.5 remote-as 65000
 neighbor 10.0.0.5 description S2
 neighbor 10.0.0.5 update-source lo
 !
 address-family ipv4 unicast
  network 10.0.0.4/32
  neighbor 10.0.0.1 activate
  neighbor 10.0.0.1 route-reflector-client
  neighbor 10.0.0.1 next-hop-self
  neighbor 10.0.0.2 activate
  neighbor 10.0.0.2 route-reflector-client
  neighbor 10.0.0.2 next-hop-self
  neighbor 10.0.0.3 activate
  neighbor 10.0.0.3 route-reflector-client
  neighbor 10.0.0.3 next-hop-self
  neighbor 10.0.0.5 activate
  neighbor 10.0.0.5 next-hop-self
 exit-address-family
 !
 address-family l2vpn evpn
  neighbor 10.0.0.1 activate
  neighbor 10.0.0.1 route-reflector-client
  neighbor 10.0.0.1 soft-reconfiguration inbound
  neighbor 10.0.0.2 activate
  neighbor 10.0.0.2 route-reflector-client
  neighbor 10.0.0.2 soft-reconfiguration inbound
  neighbor 10.0.0.3 activate
  neighbor 10.0.0.3 route-reflector-client
  neighbor 10.0.0.3 soft-reconfiguration inbound
  neighbor 10.0.0.5 activate
  neighbor 10.0.0.5 soft-reconfiguration inbound
  advertise-all-vni
  advertise-svi-ip
  advertise ipv4 unicast
 exit-address-family
exit
!
router ospf
 ospf router-id 10.0.0.4
 timers throttle spf 10 50 500
 timers throttle lsa all 100
 timers lsa min-arrival 100
exit
!
end

С точки зрения датаплейна - трафик от GreeHost1 попадает на eth3 интерфейс хоста L1 (Leaf-1), где он бриджуется с помощью моста Vlan1000 с интерфейсом vxlan101000:

А вот что можно узнать про этот самый Vxlan101000:

Тут много всего, но из интересного для нас:

vxlan id - 101000
local 10.0.0.1: Локальный IP-адрес, используемый для инкапсуляции VXLAN
nolearning - обычно это указывает на то, что мы отказались от Flood&Learn подхода в пользу какого-то control plane - в нашем случае, очевидно, EVPN

Немного инфы по заполненности MAC-таблицы:

Видно, что пару маков пришло с удалённого VTEP-а - 10.0.0.3 (это наш третий лиф). Эти маки пришли в виде route type 2 маршрутов EVPN-а. Вот они (для уменьшения вывода я выключил EVPN сессию до второго спайна):

Мак "ВСЕ_НУЛИ" в выводе выше показывает, куда мы можем слать BUM-трафик. Обычно это рождается третьим типом EVPN-маршрутов, который как бэ намекает нашему роутеру куда слать BUM трафик для конкретного VNI, если что:

Ну и что бы это всё работало на уровне ядра, нужно включить поддержку vxlan как такового и поддержку энкапсуляции:

modprobe vxlan
modprobe ip6_udp_tunnel
modprobe udp_tunnel

В общем, вот так вот работает EVPN с VXLAN-ом на FRR :-)

Выводы

FRR - это хорошо. И ещё я пишу тут - https://t.me/NetArchNotes

Теги:

Хабы: