Привет, Хабр! Меня зовут Алексей, я участвую в разработке операционной системы для линейки коммутаторов KORNFELD в YADRO. Ранее я писал об организации L2-связности — она покрывает только часть потребностей, и рано или поздно требуется связать VXLAN-сегменты между собой или с внешними сетями. В этой статье рассмотрим варианты решения такой задачи. Все примеры беру из практики работы с KORNFELD, ��ак как логика настройки и синтаксис схожи с популярными вендорами.
В прошлой публикации я описал примеры настройки L2 EVPN/VXLAN и привел глоссарий. Там можно посмотреть значения терминов, которые я использую и в этой статье.
Вариантов создать L3-связность не так много:
централизованная модель:
централизованный шлюз (centralized gateway),
распределенная модель:
асимметричный шлюз (asymmetric IRB),
симметричный шлюз (symmetric IRB).
Все эти решения поддерживаются в Kornfeld OS. Разберемся, как в теории работает каждое из них.
Централизованный шлюз
Эта схема похожа на inter-vlan routing, когда необходимо дотянуть VLAN до устройства, которое будет маршрутизировать пакеты между интерфейсами. Только в случае централизованного шлюза дотянуть нужно VXLAN-сегменты, то есть придется создать все EVI, для которых делаем маршрутизацию. Кроме того, необходимо анонсировать RT-2-маршрут с информацией о MAC- и IP-адресах шлюза. Трафик к шлюзу и от него доставляется в пользовательских сегментах. Резервирование работает с помощью VRRP или SAG-интерфейсов.
Асимметричный шлюз
Чтобы было понятнее: на картинке все VTEP выполняют роль шлюза, но на деле не всегда это именно так. Могут быть задействованы только те VTEP, к которым присоединен сегмент, участвующий в маршрутизации. Видно, что есть отличие от централизованной модели, но в чем особенности?
Так как модель распределенная, то маршрутизация (L3-lookup) выполняется на нескольких устройствах. В асимметричном варианте — на входящем VTEP с последующей коммутацией трафика в целевом EVI. То есть исходящий VTEP получает трафик в том EVI, в котором находится получатель, и ему нужно только выполнить декапсуляцию. В этом заключается асимметричность.
Роли VTEP:
Входящий (ingress) VTEP — тот, что получил трафик от хоста и выполнил инкапсуляцию VXLAN.
Исходящий (egress) VTEP — тот, что выполнил декапсуляцию VXLAN и передал трафик в сторону хоста.
Эти роли справедливы исключительно относительно конкретного VXLAN-туннеля.
На каждом VTEP, выполняющем роль шлюза, создаются EVI, для ко��орых обеспечивается маршрутизация, даже если локальных подключений для этого EVI на VTEP не существует. Анонсировать информацию о шлюзе не требуется, адресация шлюза имеет значение в пределах VTEP и используется локально подключенными ресурсами.
Симметричный шлюз
Особенность метода — для маршрутизации между сегментами и внешними сетями используется дополнительный служебный сегмент L3 EVI, с которым через VRF объединяются пользовательские сегменты, а передача трафика между VTEP производится на основе VNI служебного сегмента. На каждом VTEP создается экземпляр L3 EVI. Таким образом, маршрутизация (L3-lookup) выполняется дважды: на входящем и исходящем VTEP.
Любой из вариантов шлюза может использовать как уникальную адресацию (IP- и MAC-адреса), так и SAG-интерфейсы с идентичными IP- и MAC-адресами. Далее будем рассматривать шлюзы совместно с SAG.
Если хотите работать сетевым инженером в KORNFELD, оставьте заявку на эти вакансии:
Настройка L3 overlay-сети
Перед нами стоит задача обеспечить взаимодействие между изолированными пользовательским сегментами через L3 overlay-сеть, а также выход во внешние сети. Для экспериментов будем использовать ту же топологию, что и в прошлый раз, добавив к ней имитацию внешней сети.
В ней уже организованы связность в underlay-сети на основе EBGP и L2 overlay-сегменты для подключенн��х клиентов. EVPN-сессии активны:
spine1# show bgp l2vpn evpn summary BGP router ID : 10.113.0.1 Local AS number : 1000 BGP table version: 0 RIB entries : 9 --------------------------------------------------------------------------------------------------------- Neighbor Description AS State/PfxRcd Up/Down TblVer MsgRcvd MsgSent InQ OutQ ---------- ------------- ---- -------------- --------- -------- --------- --------- ----- ------ 10.113.1.1 LEAF-1 100 2 01w0d17h 2092 19519 19521 0 0 10.113.1.3 LEAF-2 200 2 01w0d17h 2092 19517 19521 0 0 10.113.1.5 LEAF-3 300 3 01w0d17h 2092 19520 19520 0 0 10.113.1.7 LEAF-4 400 2 01w0d17h 2092 19518 19520 0 0 Total: 4
MAC-адреса по фабрике разошлись:
leaf3# show evpn mac Flags: D - duplicate, G - default gateway, I - local-inactive, P - peer-active, S - sticky, V - SVI, X - peer-proxy ------------------------------------------------------------------------------ VNI MAC VLAN Origin Intf/VTEP/ESI MM Seq Flags ----- ----------------- ------ -------- --------------- -------- ------- 1001 52:A8:00:01:01:10 101 remote 10.113.100.1 0/0 1001 52:A8:00:01:01:31 101 local Ethernet10 0/0 1001 52:A8:00:01:01:40 101 remote 10.113.100.4 0/0 1002 52:A8:00:01:02:20 102 remote 10.113.100.2 0/0 1002 52:A8:00:01:02:32 102 local Ethernet11 0/0 Total: 5
Далее посмотрим, как в Kornfeld OS запустить такие шлюзы.
Централизованный шлюз
Шлюз можно разместить на одном устройстве, но лучше предусмотреть два или более — для повышения отказоустойчивости. Будем использовать leaf-1 и leaf-2. Для этого дотянем до них недостающие VXLAN-сегменты и создадим SVI-интерфейсы с адресацией из нужных нам сетей.
По конфигурации нужно сделать следующее:
создать сегменты на leaf-1 и leaf-2,
создать SVI (SAG), поместить в нужный VRF,
анонсировать адресацию шлюза.
На примере leaf-1 это будет выглядеть так:
1. Создали нужный нам VLAN с любым ID и добавили его к VXLAN-сегменту, который дотягиваем:
configure terminal vlan 102 ! interface vxlan vtep1 map vni 1002 vlan 102 ! end
2. Создали VRF и поместили в него шлюзы. Хоть SAG и выглядит как SVI-интерфейс, но настраивается немного иначе. MAC-адрес, используемый SAG-интерфейсами внутри одной коробки, задается глобально:
configure terminal ! ip vrf Vrf1 ! ip anycast-address enable ip anycast-mac-address 00:00:5E:00:01:12 ! interface Vlan101 ip vrf forwarding Vrf1 ip anycast-address 192.168.101.1/24 ! interface Vlan102 ip vrf forwarding Vrf1 ip anycast-address 192.168.102.1/24 ! end
Предпочтительнее использовать MAC-адрес из диапазона 00-00-5E-00-01-xx, чтобы избежать конфликтов с адресацией подключенных ресурсов, так как MAC-адрес SAG-интерфейса не изучается в VLAN, которому соответствует SVI.
Посмотрим, что получилось.
leaf1# show ip static-anycast-gateway Static anycast gateway enabled: yes Anycast gateway MAC address : 00:00:5E:00:01:12 Total number of gateways : 2 In administrative UP state : 2 In operational UP state : 2 ------------------------------------------------------ Interface Gateway address VRF Admin Oper ----------- ----------------- ----- ------- ------ Vlan101 192.168.101.1/24 Vrf1 up up Vlan102 192.168.102.1/24 Vrf1 up up leaf1# show ip route vrf Vrf1 Codes: K - kernel route, C - connected, S - static, B - BGP, O - OSPF > - selected route, * - FIB route, q - queued route, r - rejected route, # - not installed in hardware Destination Gateway Interface Dist/Metric Uptime Tag ------------------------------------------------------------------------- C>* 192.168.101.0/24 Direct Vlan101 0/0 00:00:43 C>* 192.168.102.0/24 Direct Vlan102 0/0 00:00:43
С этим можно работать. Но для чего мы планировали анонсировать адресацию шлюза? Если на данном шаге отправить трафик на шлюз или в другой сегмент, например, с srv4, то на leaf4 увидим не очень приятную картину:
11:55:53.352966 52:a8:00:00:44:44 > 52:a8:00:00:10:00, ethertype IPv4 (0x0800), length 148: (tos 0x0, ttl 64, id 56005, offset 0, flags [none], proto UDP (17), length 134) 10.113.100.4.50958 > 10.113.100.1.4789: VXLAN, flags [I] (0x08), vni 1001 52:a8:00:01:01:40 > 00:00:5e:00:01:12, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 29069, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.101.40 > 192.168.101.1: ICMP echo request, id 3, seq 134, length 64 11:55:54.355139 52:a8:00:00:44:44 > 52:a8:00:00:10:00, ethertype IPv4 (0x0800), length 148: (tos 0x0, ttl 64, id 59885, offset 0, flags [none], proto UDP (17), length 134) 10.113.100.4.50958 > 10.113.100.3.4789: VXLAN, flags [I] (0x08), vni 1001 52:a8:00:01:01:40 > 00:00:5e:00:01:12, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 29250, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.101.40 > 192.168.101.1: ICMP echo request, id 3, seq 135, length 64
Один и тот же запрос отправляется на 10.113.100.1 и 10.113.100.3. Это работает ingress replication для BUM-трафика. Но откуда BUM в запросе unicast-адреса? Нет EVPN-маршрутов на L2-VTEP до шлюза, а значит, нет и данных в EVPN.
leaf4# show evpn mac Flags: D - duplicate, G - default gateway, I - local-inactive, P - peer-active, S - sticky, V - SVI, X - peer-proxy ------------------------------------------------------------------------------ VNI MAC VLAN Origin Intf/VTEP/ESI MM Seq Flags ----- ----------------- ------ -------- --------------- -------- ------- 1001 52:A8:00:01:01:10 101 remote 10.113.100.1 0/0 1001 52:A8:00:01:01:31 101 remote 10.113.100.3 0/0 1001 52:A8:00:01:01:40 101 local Ethernet10 0/0 Total: 3
Включим анонсы и перепроверим.
configure terminal ! router bgp 100 ! address-family l2vpn evpn advertise-default-gw ! end
Появилась запись шлюза.
leaf4# show evpn mac Flags: D - duplicate, G - default gateway, I - local-inactive, P - peer-active, S - sticky, V - SVI, X - peer-proxy ------------------------------------------------------------------------------ VNI MAC VLAN Origin Intf/VTEP/ESI MM Seq Flags ----- ----------------- ------ -------- --------------- -------- ------- 1001 00:00:5E:00:01:12 101 remote 10.113.100.1 0/0 G 1001 52:A8:00:01:01:10 101 remote 10.113.100.1 0/0 1001 52:A8:00:01:01:31 101 remote 10.113.100.3 0/0 1001 52:A8:00:01:01:40 101 local Ethernet10 0/0 Total: 4
Она сформировалась на основании одного из полученных маршрутов — от leaf1 или leaf2. Поэтому пока один из них «жив», мы можем роутить трафик.
Route Distinguisher: 10.113.100.1:2 * [2]:[0]:[48]:[00:00:5E:00:01:12]:[32]:[192.168.101.1] 10.113.100.1 0 1000 100 i RT:100:1001 ET:8 Default Gateway *> [2]:[0]:[48]:[00:00:5E:00:01:12]:[32]:[192.168.101.1] 10.113.100.1 0 1000 100 i RT:100:1001 ET:8 Default Gateway ***************************вывод сокращен************************** Route Distinguisher: 10.113.100.2:3 *> [2]:[0]:[48]:[00:00:5E:00:01:12]:[32]:[192.168.101.1] 10.113.100.2 0 1000 200 i RT:200:1001 ET:8 Default Gateway * [2]:[0]:[48]:[00:00:5E:00:01:12]:[32]:[192.168.101.1] 10.113.100.2 0 1000 200 i RT:200:1001 ET:8 Default Gateway
Путей четыре, так как маршрут от leaf1 и leaf2 мы получаем от spine1 и spine2.
У резервирования централизованного шлюза на SAG есть небольшой нюанс, который нужно учесть: в случае разрешения IP-адреса клиента одним из SAG (например, leaf1), ARP-reply от клиента может приземлиться на другой SAG (leaf2). В результате SAG (leaf1), пославший запрос, будет продолжать попытки разрешения. Обойти это можно, используя ARP Suppression на L2-VTEP. Таким образом, они будут распространять RT-2-маршрут для искомого узла, что позволит установить ARP-запись на всех SAG. Для этого нужно добавить такие настройки на leaf3 и leaf4, именно они в нашей схеме реализуют L2-VTEP. Пример для leaf3:
configure terminal ! interface Vlan 101 ! interface Vlan 102 ! interface vxlan vtep1 arp-suppression interface Vlan101 arp-suppression interface Vlan102 ! end
Также это уменьшит количество флуда в фабрике, позволит VTEP явно анонсировать локальные ARP-записи.
В целом все готово. Осталось добавить маршруты на шлюз на хостах и проверить связность. Выход на внешние сети организуется непосредственно на Border leaf при помощи какого-нибудь протокола маршрутизации или размещением статического маршрута на внешний ресурс. Сейчас внешний мир имитирует сеть 192.168.0.255/32 на WAN/EDGE-устройстве, на Border leaf на нее установлен статический маршрут по умолчанию.
[root@srv4 ~]$ ping -c 2 192.168.102.20 PING 192.168.102.20 (192.168.102.20) 56(84) bytes of data. 64 bytes from 192.168.102.20: icmp_seq=1 ttl=63 time=3.48 ms 64 bytes from 192.168.102.20: icmp_seq=2 ttl=63 time=3.20 ms --- 192.168.102.20 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1002ms rtt min/avg/max/mdev = 3.199/3.340/3.481/0.141 ms [root@srv4 ~]$ ping -c 2 192.168.102.32 PING 192.168.102.32 (192.168.102.32) 56(84) bytes of data. 64 bytes from 192.168.102.32: icmp_seq=1 ttl=63 time=4.97 ms 64 bytes from 192.168.102.32: icmp_seq=2 ttl=63 time=3.65 ms --- 192.168.102.32 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1002ms rtt min/avg/max/mdev = 3.653/4.310/4.967/0.657 ms [root@srv4 ~]$ ping -c 2 192.168.0.255 PING 192.168.0.255 (192.168.0.255) 56(84) bytes of data. 64 bytes from 192.168.0.255: icmp_seq=1 ttl=63 time=3.71 ms 64 bytes from 192.168.0.255: icmp_seq=2 ttl=63 time=3.44 ms --- 192.168.0.255 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 3.438/3.572/3.706/0.134 ms srv4 (192.168.101.40) -> 192.168.0.255 (192.168.0.255) 2025-12-05T11:42:41+0300 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 192.168.101.1 0.0% 33 2.2 1.7 1.1 5.3 0.7 2. 192.168.0.255 0.0% 33 4.1 3.7 3.3 4.2 0.3
Маршрутизация выполняется в Vrf1 между SVI-интерфейсами на leaf1 или leaf2, доставка трафика — в VNI, которому принадлежит узел-получатель.
Схематично процесс выглядит так:
SRV A1 инициирует передачу данных на шлюз согласно своей таблице маршрутизации в пользовательском VLAN A.
Входящий VTEP A получает кадр в клиентском VLAN, в поле DST_MAC которого содержится MAC-адрес его SVI-интерфейса, выполняет декапсуляцию трафика и передает пакет на маршрутизацию. Взаимосвязь между EVI и VRF определяется связкой SVI-VLAN-VNI и размещением данного SVI в VRF. Так определяется набор AC, для которых шлюз будет обеспечивать маршрутизацию в рамках конкретного VRF.
По таблице маршрутизации VRF определяется исходящий интерфейс — SVI B.
Связка SVI-VLAN-VNI определит целевой EVI, метку VNI которого следует использовать при создании VXLAN-туннеля для доставки трафика на удаленный VTEP. Трафик от шлюза к получателю доставляется в VXLAN-сегменте получателя.
Исходящий VTEP B получает трафик в том EVI, в котором получатель, выполняет декапсуляцию трафика (терминацию VXLAN-заголовка) и коммутацию кадра в клиентский интерфейс.
SRV B2 принимает данные от шлюза в VLAN B.
У этой конструкции есть недостаток: то, как устроена передача данных через фабрику до шлюза и обратно, даже если сегменты подключены к одному коммутатору.
Распределенный асимметричный шлюз
В асимметричной модели у каждого VTEP должны быть все используемые связки VLAN-VNI, а также все шлюзы для маршрутизации внутри overlay-сети. Анонсировать информацию о шлюзе не нужно, поскольку он и так будет настроен на каждом VTEP. Для адресации также используем SAG. Перейдем к настройкам, используем схему в исходном состоянии.
Для возврата к начальном�� состоянию загрузим ранее сохраненную конфигурацию командой
copy saved-configuration <saved-config-name> running-configuration.
На каждом leaf-коммутаторе приведем конфигурацию к следующему виду:
configure terminal ! ip anycast-mac-address 00:00:5e:00:01:12 ip anycast-address enable ! ip vrf Vrf1 ! vlan 101-102 ! interface Vlan101 ip vrf forwarding Vrf1 ip anycast-address 192.168.101.1/24 ! interface Vlan102 ip vrf forwarding Vrf1 ip anycast-address 192.168.102.1/24 ! interface vxlan vtep1 source-ip <loopback_ip> map vni 1001 vlan 101 map vni 1002 vlan 102 ! end
Для всех VTEP настройки идентичны, кроме параметра source-ip. На этом настройка закончена. У VTEP есть набор интерфейсов, каждый из которых, с одной стороны, связан с уникальным VXLAN-сегментом, с другой — входит в общее пространство Vrf1. Таким образом, каждый VTEP принимает решение о маршрутизации исключительно локально, перекладывая трафик между присоединенными к VRF интерфейсами. В отличие от централизованной модели, трафик не ходит к шлюзу по фабрике, целевой сегмент определяется на входящем VTEP.
Выход на внешние сети внутри чистой асимметричной модели реализовать проблематично. Главная проблема — как доставлять маршруты в VRF на VTEP. Так или иначе, для этого понадобится L3 EVI, а также поддержка overlay-index, который не доступен в релизе Kornfeld OS 1.7 и пока только в планах. Оставим эту задачу для симметричной модели и проверим состояние фабрики после введенной конфигурации.
Посмотрим, что вышло из конфигурации. show evpn vni detail говорит, что на остальных VTEP есть тот же набор EVI.
leaf1# show evpn vni detail ------------------------------------------------ VNI 1001 ------------------------------------------------ Type : L2 VRF : Vrf1 Mapped VLAN ID : 101 SVI interface : Vlan101 Source VTEP IP : 10.113.100.1 ARP suppression : disabled Advertisement of SVI MAC/IP : disabled Advertisement of default GW MAC/IP: disabled MACs learned in VN : 3 ARPs learned in VN : 3 Remote VTEPs : 10.113.100.2 10.113.100.3 10.113.100.4 ------------------------------------------------ VNI 1002 ------------------------------------------------ Type : L2 VRF : Vrf1 Mapped VLAN ID : 102 SVI interface : Vlan102 Source VTEP IP : 10.113.100.1 ARP suppression : disabled Advertisement of SVI MAC/IP : disabled Advertisement of default GW MAC/IP: disabled MACs learned in VN : 2 ARPs learned in VN : 2 Remote VTEPs : 10.113.100.2 10.113.100.3 10.113.100.4
Информация о MAC-адресах, ARP-записях из EVPN-маршрутов RT-2 (MAC + IP), попадает в таблицы соответствующего EVI.
leaf1# show evpn mac Flags: D - duplicate, G - default gateway, S - sticky, V - SVI ------------------------------------------------------------------------------- VNI MAC VLAN Origin Interface/VTEP MM Seq Flags ----- ----------------- ------ -------- ---------------- -------- ------- 1001 52:A8:00:01:01:10 101 local Ethernet43 0/0 1001 52:A8:00:01:01:31 101 remote 10.113.100.3 0/0 1001 52:A8:00:01:01:40 101 remote 10.113.100.4 0/0 1002 52:A8:00:01:02:20 102 remote 10.113.100.2 0/0 1002 52:A8:00:01:02:32 102 remote 10.113.100.3 0/0 Total: 5 leaf1# show evpn arp-cache Flags: D - duplicate, G - default gateway, V - SVI ------------------------------------------------------------------------------------------- VNI IP address MAC address Origin State MM Seq Flags VTEP ----- -------------- ----------------- -------- ------- -------- ------- ------------ 1001 192.168.101.10 52:A8:00:01:01:10 local active 0/0 1001 192.168.101.31 52:A8:00:01:01:31 remote active 0/0 10.113.100.3 1001 192.168.101.40 52:A8:00:01:01:40 remote active 0/0 10.113.100.4 1002 192.168.102.20 52:A8:00:01:02:20 remote active 0/0 10.113.100.2 1002 192.168.102.32 52:A8:00:01:02:32 remote active 0/0 10.113.100.3 Total: 5
Это нам дает связь между сегментами.
[root@srv2 ~]$ ip neighbor 192.168.102.1 dev eth2 lladdr 00:00:5e:00:01:12 STALE 192.168.102.32 dev eth2 lladdr 52:a8:00:01:02:32 REACHABLE [root@srv2 ~]$ ping -c 2 192.168.101.10 PING 192.168.101.10 (192.168.101.10) 56(84) bytes of data. 64 bytes from 192.168.101.10: icmp_seq=1 ttl=63 time=0.088 ms 64 bytes from 192.168.101.10: icmp_seq=2 ttl=63 time=0.269 ms --- 192.168.101.10 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1011ms rtt min/avg/max/mdev = 0.088/0.178/0.269/0.090 ms [root@srv2 ~]$ ping -c 2 192.168.101.31 PING 192.168.101.31 (192.168.101.31) 56(84) bytes of data. 64 bytes from 192.168.101.31: icmp_seq=1 ttl=63 time=0.337 ms 64 bytes from 192.168.101.31: icmp_seq=2 ttl=63 time=0.294 ms --- 192.168.101.31 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1012ms rtt min/avg/max/mdev = 0.294/0.315/0.337/0.021 ms [root@srv2 ~]$ ping -c 2 192.168.101.40 PING 192.168.101.40 (192.168.101.40) 56(84) bytes of data. 64 bytes from 192.168.101.40: icmp_seq=1 ttl=63 time=0.893 ms 64 bytes from 192.168.101.40: icmp_seq=2 ttl=63 time=0.192 ms --- 192.168.101.40 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1011ms rtt min/avg/max/mdev = 0.192/0.542/0.893/0.350 ms
Маршрутизация выполняется в Vrf1 между SVI-интерфейсами на входящем VTEP, доставка трафика — в VNI, которому принадлежит получатель.
Схематично процесс выглядит так:
SRV A1 инициирует передачу данных на шлюз в VLAN A согласно своей таблице маршрутизации.
Входящий VTEP A, получая кадр в клиентском VLAN, в поле DST_MAC которого содержится MAC-адрес его SVI-интерфейса, выполняет декапсуляцию трафика (терминацию L2-заголовка) и передает пакет на маршрутизацию. Взаимосвязь между EVI и VRF определяется связкой SVI-VLAN-VNI и размещением данного SVI в VRF. Таким образом, определяется набор AC, для которых шлюз будет обеспечивать маршрутизацию в рамках конкретного VRF.
По таблице маршрутизации VRF определяет исходящий интерфейс — SVI B.
Связка SVI-VLAN-VNI определит целевой EVI, метку VNI которого следует использовать при создании VXLAN-туннеля для доставки трафика на удаленный VTEP. Трафик от шлюза к получателю доставляется в VXLAN-сегменте получателя.
Исходящий VTEP B получает трафик в том EVI, в котором находится получатель, выполняет декапсуляцию трафика (терминацию VXLAN-заголовка) и коммутацию кадра в клиентский интерфейс.
SRV B2 принимает данные от шлюза в VLAN B.
SRV B2 отвечает, отправляя данные на собственный шлюз — SVI B.
Входящий VTEP B терминирует L2-заголовок.
По таблице маршрутизации локального VRF определяет исходящий интерфейс — SVI A.
VRF отправляет трафик на VTEP A в сегменте получателя.
Исходящий VTEP A выполняет декапсуляцию трафика и коммутацию кадра в клиентский интерфейс.
SRV A1 принимает данные от шлюза в VLAN A.
Распределенный симметричный шлюз
При использовании симметричной модели шлюза, в отличие от асимметричной, нет необходимости настраивать все связки VLAN-VNI на каждом VTEP. Вместо этого нужно сделать отдельный сегмент, который свяжет все остальные. Также нужно будет донастроить секцию BGP. Откатим схему в начало и начнем. Роль шлюзов выполнят SAG-интерфейсы. На коммутаторах leaf1 и leaf2 организуем связь с внешними сетями.
Добавим на каждый leaf-коммутатор такую конфигурацию:
configure terminal ! vlan 301 ! ip vrf Vrf1 ! ip anycast-address enable ip anycast-mac-address 00:00:5E:00:01:12 ! interface Vlan102 ip vrf forwarding Vrf1 ip anycast-address 192.168.102.1/24 ! interface Vlan301 no autostate ip vrf forwarding Vrf1 ! interface vxlan vtep1 map vni 3001 vlan 301 map vni 3001 vrf Vrf1 ! end
Подведем итог.
Создали новый VLAN, который будем ассо��иировать с сервисным EVI (L3 VNI).
Создали VRF, который свяжет интерфейсы клиентских шлюзов c L3 сегментом.
Включили поддержку Anycast-адресации и установим MAC-адрес SAG-интерфейса.
Создали клиентский и сервисный SVI-интерфейсы (клиентские создаем те, которые подключены к VTEP).
Связали сервисный VLAN и пользовательский VRF с экземпляром EVI.
Так как сервисный сегмент будет передавать не только трафик, но и маршруты, то в BGP нужно создать инстанс для нашего Vrf1. Делаем на примере leaf1:
configure terminal ! router bgp 100 vrf Vrf1 ! address-family ipv4 unicast redistribute connected maximum-paths 8 ! address-family l2vpn evpn advertise ipv4 unicast rd 10.113.100.1:3001 ! end
Поскольку все шлюзы — это присоединенные сети, импортируем их через redistribute connected и попросим EVPN анонсировать их в своих маршрутах. Для передачи IP-префиксов произвольной длины используем маршрут RT-5. Также в этой секции можно задать параметры RD и RT для маршрутов данного VRF. В этом примере зададим RD, чтобы принять анонсы от всех VTEP, поскольку адресация пересекается.
Для Border leaf добавим еще конфигурацию пиринга с EDGE-устройством.
configure terminal ! ip prefix-list default-route seq 1 permit 0.0.0.0/0 ! route-map DEFAULT_ONLY permit 1 match ip address prefix-list default-route ! router bgp 100 vrf Vrf1 ! neighbor 10.113.15.0 remote-as external ! address-family ipv4 unicast activate route-map DEFAULT_ONLY in ! end
Пора посмотреть, что же вышло. Начнем с сервисного сегмента: он в рабочем состоянии и связан с нужным VRF, RD сформировались автоматом, RMAC есть, о нем позже.
leaf1# show bgp l2vpn evpn vni 3001 --------------------------------------- VNI 3001 --------------------------------------- Mapped to VLAN : yes Type : L3 VRF : Vrf1 Route distinguisher : 10.113.100.1:3001 Originator IP : 10.113.100.1 Router's MAC : 52:A8:00:00:11:11 Import route targets: 100:3001 Export route targets: 100:3001
А тут в последней строке будет список сегментов, с которыми связан сервисный внутри VTEP.
leaf1# show evpn vni 3001 ------------------------------------ VNI 3001 ------------------------------------ Type : L3 VRF : Vrf1 Mapped VLAN ID : 301 SVI interface : Vlan301 Source VTEP IP : 10.113.100.1 Router's MAC : 52:A8:00:00:11:11 Connected L2 VNIs: 1001
Еще интересно, что с префиксами, которые импортировали в BGP, и где те самые RT-5? Заглянем в таблицу Vrf1.
leaf1# show ip route vrf Vrf1 Codes: K - kernel route, C - connected, S - static, B - BGP, O - OSPF > - selected route, * - FIB route, q - queued route, r - rejected route, # - not installed ine Destination Gateway Interface Dist/Metric Uptime Tag ----------------------------------------------------------------------------------- B>* 0.0.0.0/0 via 10.113.15.0 Ethernet5 20/0 00:02:33 C>* 10.113.15.0/31 Direct Ethernet5 0/0 00:02:33 B>* 10.113.25.0/31 via 10.113.100.2 Vlan301 20/0 00:02:03 C>* 192.168.101.0/24 Direct Vlan101 0/0 00:02:32 B>* 192.168.101.40/32 via 10.113.100.4 Vlan301 20/0 00:01:06 B>* 192.168.102.0/24 via 10.113.100.2 Vlan301 20/0 00:02:03 * via 10.113.100.3 Vlan301 B>* 192.168.102.32/32 via 10.113.100.3 Vlan301 20/0 00:01:13
Есть импортированная сеть 192.168.102.0/24, и известна она стала как раз за счет RT-5, которые прислали leaf2 и leaf3.
leaf1# show bgp l2vpn evpn route 192.168.102.0/24 BGP routing table entry for 10.113.100.2:3001:[5]:[0]:[24]:[192.168.102.0] Paths: (2 available, best #2) Advertised to non peer-group peers: kornfeld(10.113.1.0) kornfeld(10.113.2.0) Route [5]:[0]:[24]:[192.168.102.0] VNI 3001 1000 200 10.113.100.2 from kornfeld(10.113.2.0) (10.113.0.2) Origin incomplete, valid, external Extended Community: RT:200:3001 ET:8 RMAC:52:A8:00:00:22:22 Last update: Fri Dec 5 13:12:52 2025 Route [5]:[0]:[24]:[192.168.102.0] VNI 3001 1000 200 10.113.100.2 from kornfeld(10.113.1.0) (10.113.0.1) Origin incomplete, valid, external, bestpath-from-AS 1000, best (Older Path) Extended Community: RT:200:3001 ET:8 RMAC:52:A8:00:00:22:22 Last update: Fri Dec 5 13:12:52 2025 BGP routing table entry for 10.113.100.3:3001:[5]:[0]:[24]:[192.168.102.0] Paths: (2 available, best #2) Advertised to non peer-group peers: kornfeld(10.113.1.0) kornfeld(10.113.2.0) Route [5]:[0]:[24]:[192.168.102.0] VNI 3001 1000 300 10.113.100.3 from kornfeld(10.113.2.0) (10.113.0.2) Origin incomplete, valid, external Extended Community: RT:300:3001 ET:8 RMAC:52:A8:00:00:33:33 Last update: Fri Dec 5 13:12:42 2025 Route [5]:[0]:[24]:[192.168.102.0] VNI 3001 1000 300 10.113.100.3 from kornfeld(10.113.1.0) (10.113.0.1) Origin incomplete, valid, external, bestpath-from-AS 1000, best (Older Path) Extended Community: RT:300:3001 ET:8 RMAC:52:A8:00:00:33:33 Last update: Fri Dec 5 13:12:42 2025
Аналогично и дефолт анонсируется пограничными коммутаторами, как RT-5. Таким образом можно анонсировать в фабрику внешние маршруты.
leaf1# show bgp l2vpn evpn route 0.0.0.0 BGP routing table entry for 10.113.100.1:3001:[5]:[0]:[0]:[0.0.0.0] Paths: (1 available, best #1) Advertised to non peer-group peers: spine1(10.113.1.0) spine2(10.113.2.0) Route [5]:[0]:[0]:[0.0.0.0] VNI 3001 4294967295 10.113.100.1 from 0.0.0.0 (10.113.100.1) Origin incomplete, valid, sourced, local, bestpath-from-AS 4294967295, best (First path receive) Extended Community: ET:8 RT:100:3001 RMAC:52:A8:00:00:11:11 Last update: Fri Dec 5 16:28:50 2025 BGP routing table entry for 10.113.100.2:3001:[5]:[0]:[0]:[0.0.0.0] Paths: (2 available, best #2) Advertised to non peer-group peers: spine1(10.113.1.0) spine2(10.113.2.0) Route [5]:[0]:[0]:[0.0.0.0] VNI 3001 1000 200 4294967295 10.113.100.2 from spine2(10.113.2.0) (10.113.0.2) Origin incomplete, valid, external Extended Community: RT:200:3001 ET:8 RMAC:52:A8:00:00:22:22 Last update: Fri Dec 5 16:29:29 2025 Route [5]:[0]:[0]:[0.0.0.0] VNI 3001 1000 200 4294967295 10.113.100.2 from spine1(10.113.1.0) (10.113.0.1) Origin incomplete, valid, external, bestpath-from-AS 1000, best (Older Path) Extended Community: RT:200:3001 ET:8 RMAC:52:A8:00:00:22:22 Last update: Fri Dec 5 16:29:20 2025
Хорошо, но откуда еще /32? Это по сути ARP-записи, которые изучили VTEP и распространили в маршрутах RT-2. А в VRF они попали по наличию в них RT нашего Vrf1.
leaf1# show bgp l2vpn evpn vrf-import-rt -------------------------------- Route target Importing VRFs -------------- ---------------- 100:3001 Vrf1 Total: 1 leaf1# show bgp l2vpn evpn route type 2 self-originate BGP table version is 168, local router ID is 10.113.100.1 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: 10.113.100.1:2 *> [2]:[0]:[48]:[52:A8:00:01:01:10] 10.113.100.1 32768 i ET:8 RT:100:1001 *> [2]:[0]:[48]:[52:A8:00:01:01:10]:[32]:[192.168.101.10] 10.113.100.1 32768 i ET:8 RT:100:1001 RT:100:3001 RMAC:52:A8:00:00:11:11 Displayed 2 prefixes (2 paths) (of requested type)
На примере leaf1 видим, что он конструирует маршрут с двумя RT:
RT:100:1001— для L2VNI, чтобы запись попала в ARP-кэш EVPN на других VTEP.RT:100:3001— чтобы запись попала в VRF в виде /32-маршрута.
Маршрутов видим значительно больше, чем в предыдущих моделях — так и должно быть. Удаленные узлы могут доставлять IP-префиксы, как подключенные, так и пришедшие извне. Кроме того, локально изученные удаленными VTEP ARP-записи присутствуют в виде /32 маршрутов.
Напоследок попробуем разобраться с RMAC, который упоминали ранее. Посмотрим на ARP-кеш Vrf1.
leaf1# show ip arp vrf Vrf1 --------------------------------------------------------------------------------- Address Hardware address Interface Egress Interface Type -------------- ------------------ ----------- ----------------------- ------- 10.113.15.0 50:20:00:BA:F0:50 Ethernet5 - Dynamic 10.113.100.2 52:A8:00:00:22:22 Vlan301 - Remote 10.113.100.3 52:A8:00:00:33:33 Vlan301 - Remote 10.113.100.4 52:A8:00:00:44:44 Vlan301 - Remote 192.168.101.10 52:A8:00:01:01:10 Vlan101 Ethernet10 Dynamic 192.168.101.31 52:A8:00:01:01:31 Vlan101 VxLAN DIP: 10.113.100.3 Remote 192.168.101.40 52:A8:00:01:01:40 Vlan101 VxLAN DIP: 10.113.100.4 Remote Total: 7
В ARP-кеше содержатся записи, указывающие на адреса loopback-интерфейсов удаленных VTEP. Для чего это нужно? В отличие от двух других моделей шлюза, в симметричной отсутствует прямая L2-связь с получателем в другом сегменте, трафик передается через L3 VNI. Это означает, что на стороне входящего VTEP после выполнения L3-lookup внутренний L2-заголовок пакета должен быть заполнен так, чтобы пакет мог быть принят L3-интерфейсом исходящего VTEP. То есть он должен обнаружить в поле DST_MAC собственный MAC-адрес.
В общем, можно сказать, что этот процесс похож на обычный сопровождающийся сменой L2-заголовка переход пакета из одного L2-сегмента в другой, только без использования ARP-протокола для разрешения MAC-адреса следующего перехода. В EVPN для этой цели используется RMAC, который передается через extended community. Он и позволяет разрешить адрес перехода, указанный в таблице маршрутизации. Схематично процесс выглядит так:
Исходящий VTEP на основе поля DST_MAC проверяет, что пакет предназначен ему. Если проверка успешна, то для пакета выполняется L3-lookup и последующая обработка. Если в поле DST_MAC указан не его MAC-адрес, то исходящий VTEP отбросит такой пакет.
Осталось проверить, работает ли коммуникация оборудования в разных VNI и с внешним ресурсом.
[root@srv4 ~]$ ip neighbor 192.168.101.1 dev ens3 lladdr 00:00:5e:00:01:12 REACHABLE 192.168.101.31 dev ens3 lladdr 52:a8:00:01:01:31 STALE 192.168.101.10 dev ens3 lladdr 52:a8:00:01:01:10 STALE [root@srv4 ~]$ ping -c 2 192.168.102.20 PING 192.168.102.20 (192.168.102.20) 56(84) bytes of data. 64 bytes from 192.168.102.20: icmp_seq=1 ttl=62 time=2.14 ms 64 bytes from 192.168.102.20: icmp_seq=2 ttl=62 time=2.63 ms --- 192.168.102.20 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 2.144/2.389/2.634/0.245 ms [root@srv4 ~]$ ping -c 2 192.168.0.255 PING 192.168.0.255 (192.168.0.255) 56(84) bytes of data. 64 bytes from 192.168.0.255: icmp_seq=1 ttl=62 time=3.46 ms 64 bytes from 192.168.0.255: icmp_seq=2 ttl=62 time=3.42 ms --- 192.168.0.255 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1002ms rtt min/avg/max/mdev = 3.416/3.437/3.458/0.021 ms srv4 (192.168.101.40) -> 192.168.0.255 (192.168.0.255) 2025-12-05T20:51:51+0300 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 192.168.101.1 0.0% 7 0.5 0.5 0.4 0.7 0.1 2. 10.113.25.1 0.0% 7 1.8 1.8 1.5 2.4 0.3 3. 192.168.0.255 0.0% 6 3.3 3.3 3.1 3.5 0.1
SRV B1 инициирует передачу данных на шлюз согласно своей таблице маршрутизации в VLAN B.
Входящий VTEP A, получая кадр в клиентском VLAN, в поле DST_MAC которого содержится MAC-адрес его SVI-интерфейса, выполняет декапсуляцию трафика (терминацию L2-заголовка) и передает пакет на маршрутизацию.
По таблице маршрутизации VRF определяет исходящий интерфейс, в данном случае интерфейс L3 EVI.
Заполняет внутренний L2-заголовок, используя RMAC. Инкапсулирует трафик с меткой L3 VNI.
Исходящий VTEP B выполняет декапсуляцию трафика (терминацию VXLAN-заголовка) и на основе DST_MAC проверяет, что пакет предназначен ему. Если так, терминирует L2-заголовок и передает пакет на маршрутизацию.
По таблице маршрутизации VRF определяет исходящий интерфейс.
Опционально VRF выполняет разрешение адреса с использованием ARP. Заполняет L2-заголовок, используя данные ARP, отправляет пакет в L2-сегмент.
SRV A2 принимает данные от шлюза в пользовательском VLAN A.
Чтобы правильно выбрать модель маршрутизации, стоит отталкиваться от набора решаемых задач. Кроме того, ограничений на совместное использование в пределах одной фабрике тоже нет. Если остались вопросы о моделях и их настройке в коммутаторах, задавайте их в комментариях.
