Привет, Хабр! Меня зовут Алексей Августинович, я принимаю участие в разработке операционной системы для линейки коммутаторов KORNFELD в YADRO. В этом материале расскажу о возможностях нашей сетевой операционной системы, а именно — о поддержке функциональности L2 VXLAN.
Настройка EVPN/VXLAN в сетях дата-центров — задача не из простых. Поэтому в материале я поделюсь шаблонами конфигураций, которые вы можете адаптировать под свои задачи, так как логика настройки и синтаксис у KORNFELD схожи с популярными вендорами.
VXLAN — технология VPN, которая базируется на концепции инкапсуляции Ethernet-трафика в UDP-дейтаграммы, что позволяет передавать Ethernet-кадры через IP-сеть. Таким образом можно «дотянуть» VLAN до некоторой удаленной точки, имея с ней только IP-связность. Поддержка VXLAN необходима только на VTEP, промежуточные устройства в L3-сети могут не поддерживать VXLAN. Представить это можно так:
Когда говорим о EVPN/VXLAN, можем выделить плоскость данных (VXLAN) и плоскость управления (EVPN). Чтобы избежать путаницы в терминах по ходу статьи, добавлю небольшой глоссарий.
Глоссарий
Плоскость данных
VXLAN (Virtual eXtensible Local Area Network) — это технология, позволяющая «растянуть» широковещательные домены Ethernet поверх общей IP-инфраструктуры, таким образом связав изолированные L2-сегменты между собой. В качестве транспортного протокола передачи данных через общую сеть используется UDP.
VTEP (Virtual Tunnel Endpoint) — PE-устройство на границе между наложенной сетью и физической, в задачу которого входит инкапсуляция и декапсуляция VXLAN-трафика.
VXLAN Segment (сегмент VXLAN) — наложенная сеть второго уровня, связывающая изолированные LAN-домены между собой.
VNI (Virtual Network Identifier) — 24-битный идентификатор в диапазоне 1..16777216, уникально идентифицирующий VXLAN-сегмент в пределах фабрики.
Плоскость управления
EVPN (Ethernet Virtual Private Network) — позволяет PE-устройствам (VTEP в нашем случае) динамически обнаруживать друг друга, устанавливать между собой туннели и обмениваться информацией о доступности узлов в наложенной сети. Для этого существует несколько типов маршрутов.
Для базовой работы
RT-2 (MAC/IP Advertisement Route) нужен для анонсирования MAC-адресов и ARP-записей.
RT-3 (Inclusive Multicast Ethernet Tag Route) — для автоматического обнаружения VTEP и построения туннелей для передачи BUM-трафика.
Для multihoming-сценариев
RT-1 (Ethernet Auto-Discovery Route) используется для автоматического обнаружения сегментов Ethernet в сети, для анонса метки ESI, массовой отмены (withdraw) MAC-адресов, анонсов Aliasing label, обеспечивает работу функции Split horizon.
RT-4 (Ethernet Segment Route) — для выбора DF в ESI.
Для инжектирования IP-префиксов
RT-5 (IP Prefix Route) нужен для анонсирования IP-префиксов произвольной длины.
EVPN предлагает функциональность, которая помогает оптимизировать прохождение трафика через наложенную сеть и повысить надежность подключения конечных узлов к фабрике:
MAC mobility — обнаруживает факт миграции конечного узла в overlay-сети VXLAN с одного VTEP на другой либо из одного Ethernet-сегмента в другой.
DAD (Duplicate address detection) — механизм обнаружения дублированных MAC-адресов в анонсируемых маршрутах типа RT-2 BGP EVPN.
ARP/ND Suppression — позволяет VTEP разрешать ARP-запросы подключенных узлов на основе уже известной информации, полученной в маршрутах RT-2, без необходимости широковещания.
EVPN Multi-homing — обеспечивает возможность подключения конечного узла к двум и более VTEP.
Для своей работы EVPN использует MP-BGP.
EVI (EVPN Instance, экземпляр EVPN) — логический коммутатор, где портами выступают порты доступа на VTEP. Связи между портами разных VTEP будет обеспечивать EVPN и используемая им плоскость данных (VXLAN, MPLS и др). EVI может работать как в режиме VLAN-Aware, так и в режиме VLAN-Based.
NVE (Network Virtualization Edge, граница виртуализации сети) — пограничное PE-устройство в EVPN-фабрике. В случае использования комбинации EVPN/VXLAN, роль устройств NVE будут играть VTEP. Так, термины PE, NVE и VTEP — синонимы.
MAC-VRF — таблица, которая поддерживается на каждом NVE. Содержит MAC-адреса узлов в наложенной сети — как локальных, так и удаленных. Каждому EVI соответствует своя таблица MAC-VRF.
Таблица MAC-VRF — это не таблица MAC-адресов, которую можно посмотреть командой
show mac address-table, а конструкт плоскости управления, которая синхронизируется с системной таблицей MAC.
Один из ключевых процессов при построении VXLAN-сети — поиск удаленных VTEP, которые входят в VXLAN Segment. Каждый VTEP может быть участником множества VXLAN Segment. Чтобы механизм поиска VTEP работал, нужно обеспечить маршрутизацию в underlay-сети.
Реализация KORNFELD
В KORNFELD OS функции плоскости управления выполняет BGP EVPN, он же позволяет автоматически обнаруживать VTEP. Для сопоставления L2-доменов (VLAN) с VXLAN (VNI) используется VLAN-based модель. При использовании этой модели каждому VLAN соответствует отдельный VPN c уникальным VNI и набором RD/RT.
Внутри VXLAN-домена оригинальные Ethernet-кадры передаются без VLAN-тега, даже если изначально он был. Не путаться между собой им помогает VNI в заголовке VXLAN.
Из-за уникального соответствия VLAN-VNI при использовании этой модели термин VNI зачастую используют в более широком смысле, чем просто идентификатор сегмента, замещая им термины EVI и MAC-VRF. У некоторых вендоров VNI обозначает Virtual Network Instance.
Также в KORNFELD OS мы реализовали функциональности MAC mobility, DAD и ARP suppression.
Если хотите присоединиться к разработке сетевого оборудования и программного обеспечения для него, у нас в команде есть вакансии для инженеров:
Применяем знания на практике
Требования к использованию L2 продиктованы спецификой сервисов, размещаемых в центрах обработки данных. В качестве примера можно привести миграцию виртуальных машин, которая требует L2 между хостами. Использование EVPN/VXLAN может дать некоторые преимущества по сравнению с классическими L2-сетями:
отсутствие STP: особенно актуально для крупных сетей, отсюда быстрее сходимость и лучшая утилизация каналов;
увеличенное количество L2-доменов;
балансировка трафика по эквивалентным путям (ECMP);
L2 можно растянуть на несколько площадок;
упрощение конфигурации: чтобы предоставить сервис, изменения нужно внести только на конечных устройствах.
Рассмотрим ситуацию, в которой требуется предоставить решение с вышеперечисленными свойствами, чтобы создать множество изолированных L2-сегментов.
Для решения задачи воспользуемся EVPN/VXLAN. В качестве примера используем топологию CLOS и рекомендации RFC 7938, EBGP как протокол маршрутизации для underlay-сети и EVPN. Используемая адресация — IPv4. BGP-сессии организуем между leaf и spine, Route Reflector не потребуется. В примере используются AS из двухбайтового диапазона, можно использовать AS из четырехбайтового.
Протоколом маршрутизации underlay-сети также могут быть IBGP или IGP. В случае применения IBGP потребуется full-mesh-связность между leaf-коммутаторами. Топологию CLOS нельзя назвать полносвязной, поэтому при использовании IBGP следует использовать Route Reflector. Альтернативное решение — запуск в underlay-сети протокола IGP для обеспечения логической full-mesh-связности.
Вне зависимости от применяемой топологии и используемых протоколов маршрутизации для работы EVPN/VXLAN необходима связность между адресами, по которым строится сессия address-family l2vpn evpn (сигнализации/control plane), и адресами, которые используются в качестве конечных точек при построении туннелей VXLAN (трафик/data plane).
В обоих случаях можно использовать, например, один Loopback-интерфейс. Сессии address-family l2vpn evpn могут строиться напрямую между VTEP, например в full-mesh-топологии. Route reflector с IGP подойдет для небольших неструктурированных топологий.
Настраиваем underlay-сеть
Здесь все довольно просто: нужно настроить адресацию и запустить BGP в address-family ipv4 unicast между leaf и spine, в рамках которых leaf-коммутаторы будут анонсировать адрес своего Loopback-интерфейса. BGP-сессии настроим через peer-group для упрощения конфигурации. Параметры ECMP-балансировки по умолчанию — 5-tuple, максимальное количество путей — 64, оставим без изменений.
Ниже — пример конфигурации для коммутатора leaf1. Остальные настроим аналогичным образом, за исключением анонсов Loopback-интерфейса на spine-коммутаторах — в базовом сценарии он нам не потребуется.
configure terminal
!
interface Loopback0
ip address 10.113.100.1/32
!
interface Ethernet1
ip address 10.113.1.1/31
!
interface Ethernet2
ip address 10.113.2.1/31
!
router bgp 100
router-id 10.113.100.1
!
address-family ipv4 unicast
network 10.113.100.1/32
!
peer-group SPINES
remote-as external
!
address-family ipv4 unicast
activate
!
neighbor 10.113.1.0
description SPINE-1
peer-group SPINES
!
neighbor 10.113.2.0
description SPINE-2
peer-group SPINES
!
hostname leaf1
!
endНастраиваем overlay-сеть
Настройка VXLAN
Подключим клиентов к фабрике. Определим для этого два VNI: 1001 и 1002. Устройства srv1, srv31 и srv4 разместим в VNI 1001, srv2 и srv32, соответственно, в VNI 1002.
Логическая схема будет выглядеть так:
Номера VLAN не важны, но важно соотнести эти VLAN с нужным VNI на конкретном VTEP. Клиенты подключаются к leaf-коммутаторам — значит, именно они должны выполнять роль VTEP, инкапсулировать и декапсулировать VXLAN. Для этого нужно создать и настроить специальный VXLAN-интерфейс. Он создается в единственном экземпляре, на нем настраиваются все уникальные связки VLAN-VNI для тех подключений, которые существуют на VTEP.
Также нужно задать адрес VTEP, который будет выступать в качестве next-hop для маршрутов EVPN. Важно, чтобы выбранный адрес был доступен остальным VTEP.
Пример конфигурации для коммутатора leaf1, остальные настроим по аналогии:
configure terminal
!
vlan 101
!
interface Ethernet10
switchport access Vlan 101
!
interface vxlan vtep1
source-ip 10.113.100.1
map vni 1001 vlan 101
endЕсли на leaf-коммутатор подключаются клиенты, расположенные в разных VNI, VXLAN-интерфейс должен иметь настройки обеих связок VLAN-VNI.
Настройка EVPN
Чтобы overlay-сеть начала работать, осталось настроить EVPN — включить поддержку address-family l2vpn evpn в BGP и разрешить рассылку информацию о EVI. Настройка advertise-all-vni применяется только к leaf-коммутаторам:
configure terminal
!
router bgp 100
!
address-family l2vpn evpn
advertise-all-vni
!
peer-group SPINES
!
address-family l2vpn evpn
activate
!
end В предложенном примере мы не создавали экземпляры EVPN явно, система делает это самостоятельно, также определяя для каждого EVI набор RD и RT.
При автоматическом формировании RD в KORNFELD OS значения полей Administrator subfield и Assigned Number subfield определяются следующим образом:
Поле Administrator subfield для маршрутов RT-1, RT-2, RT-3, RT-4 определяется значением
bgp router-id, для маршрутов RT-5 — значением наибольшего IP-адреса интерфейса, доступного в VRF, префиксы которого анонсируются. Если таковые отсутствуют, то поле Administrator subfield принимает значение 0.0.0.0.Поле Assigned Number subfield инкрементируется на один пункт для каждой пары создаваемых на интерфейсе VXLAN-отношений.
В случае RT немного проще:
Global Administrator — номер автономной системы, указанный в процессе BGP.
Local Administrator — номер VNI, идентифицирующий EVI, которому принадлежит маршрут.
Автоматически сформированный RD позволяет поддерживать уникальность маршрутов, в том числе при наличии идентичных MAC-адресов на разных VTEP в пределах одного EVPN, а автоматические назначенные RT на импорт и экспорт позволяют VTEP изолировать маршруты для каждого экземпляра EVI.
Если вы хотите явно создавать EVI или вам нужно задать данные параметры вручную, то это можно сделать из контекста конфигурации семейства адресов EVPN.
Пример для L2 VNI:
leaf1# configure terminal
leaf1(config)# router bgp 100
leaf1(config-router-bgp)# address-family l2vpn evpn
leaf1(config-router-bgp-af)# vni 1003
leaf1(config-router-bgp-af-vni)# route-target both 1003:1003
leaf1(config-router-bgp-af-vni)# route-target import 1002:1002
leaf1(config-router-bgp-af-vni)# rd 1003:1003Пример для L3 VNI:
leaf1(config)# router bgp 100 vrf Vrf1
leaf1(config-router-bgp)# address-family l2vpn evpn
leaf1(config-router-bgp-af)# rd 1003:1003
leaf1(config-router-bgp-af)# route-target both 1003:1003
leaf1(config-router-bgp-af)# route-target export 1004:1004В этом случае вы можете управлять правилами добавления маршрутов в тот или иной EVI (route leaking) и использовать сценарии взаимодействия между различными EVPN на основе нижестоящего VNI.
Проверяем конфигурацию
Для того, чтобы убедиться в работе предложенной конфигурации, нужно выполнить несколько диагностических команд. Примеры выводов рассмотрим на примере коммутатора leaf3.
В начале проверим, что EVPN-сессии активны. Так мы поймем, что нет ошибок в соединениях, адресации, а параметры BGP определены верно. Для этого используем команду show bgp l2vpn evpn summary, коротко отражающую статус настроенных сессий:
leaf3# show bgp l2vpn evpn summary
BGP router ID : 10.113.100.3
Local AS number : 300
BGP table version: 0
RIB entries : 9
---------------------------------------------------------------------------------------------------------
Neighbor Description AS State/PfxRcd Up/Down TblVer MsgRcvd MsgSent InQ OutQ
---------- ------------- ---- -------------- --------- -------- --------- --------- ----- ------
10.113.1.4 SPINE-1 1000 6 00:32:52 10 79 79 0 0
10.113.2.4 SPINE-2 1000 6 00:32:52 10 79 79 0 0
Total: 2Мы видим две установленные EVPN-сессии до spine-коммутаторов. В каждой сессии принимаем шесть маршрутов: State/PfxRcd = 6. По одному маршруту каждого типа (RT-2 и RT-3) от удаленных VTEP на каждый EVI.
Посмотреть содержимое маршрутов можно командой show bgp l2vpn evpn route. Команде также доступны дополнительные опции для селекции вывода — например, по type можно получить вывод маршрутов определенного типа. В общем выводе мы должны увидеть информацию о MAC-адресах удаленных хостов (RT-2) и маршруты для BUM-трафика (RT-3).
leaf3# show bgp l2vpn evpn route
BGP table version is 12, local router ID is 10.113.100.3
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 0 1000 100 i
RT:100:1001 ET:8
*> [2]:[0]:[48]:[52:A8:00:01:01:10]
10.113.100.1 0 1000 100 i
RT:100:1001 ET:8
* [3]:[0]:[32]:[10.113.100.1]
10.113.100.1 0 1000 100 i
RT:100:1001 ET:8
*> [3]:[0]:[32]:[10.113.100.1]
10.113.100.1 0 1000 100 i
RT:100:1001 ET:8
Route Distinguisher: 10.113.100.2:2
*> [2]:[0]:[48]:[52:A8:00:01:02:20]
10.113.100.2 0 1000 200 i
RT:200:1002 ET:8
* [2]:[0]:[48]:[52:A8:00:01:02:20]
10.113.100.2 0 1000 200 i
RT:200:1002 ET:8
* [3]:[0]:[32]:[10.113.100.2]
10.113.100.2 0 1000 200 i
RT:200:1002 ET:8
*> [3]:[0]:[32]:[10.113.100.2]
10.113.100.2 0 1000 200 i
RT:200:1002 ET:8
Route Distinguisher: 10.113.100.3:2
*> [2]:[0]:[48]:[52:A8:00:01:01:31]
10.113.100.3 32768 i
ET:8 RT:300:1001
*> [3]:[0]:[32]:[10.113.100.3]
10.113.100.3 32768 i
ET:8 RT:300:1001
Route Distinguisher: 10.113.100.3:3
*> [2]:[0]:[48]:[52:A8:00:01:02:32]
10.113.100.3 32768 i
ET:8 RT:300:1002
*> [3]:[0]:[32]:[10.113.100.3]
10.113.100.3 32768 i
ET:8 RT:300:1002
Route Distinguisher: 10.113.100.4:2
*> [2]:[0]:[48]:[52:A8:00:01:01:40]
10.113.100.4 0 1000 400 i
RT:400:1001 ET:8
* [2]:[0]:[48]:[52:A8:00:01:01:40]
10.113.100.4 0 1000 400 i
RT:400:1001 ET:8
*> [3]:[0]:[32]:[10.113.100.4]
10.113.100.4 0 1000 400 i
RT:400:1001 ET:8
* [3]:[0]:[32]:[10.113.100.4]
10.113.100.4 0 1000 400 i
RT:400:1001 ET:8
Displayed 10 prefixes (16 paths)Путей 16, потому что четыре анонсирует leaf3 и по шесть получает через каждый best выбирается стандартными процедурами BGP.
Если нужен ECMP — добавьте bestpath as-path multipath-relax в секцию общих настроек BGP.
На основе полученной сигнализации формируются туннели в плоскости передачи данных:
leaf3# show vxlan remote vtep
------------------------------
VTEP Tunnel type(s)
------------ ----------------
10.113.100.1 BUM,unicast
10.113.100.2 BUM,unicast
10.113.100.4 BUM,unicastВсе говорит о том, что можно передавать трафик.
Поскольку мы рассматриваем L2-сценарий, интересно посмотреть на FDB-таблицу.
leaf3# show mac address-table
-----------------------------------------------------------
VLAN MAC ADDRESS TYPE INTERFACE
-----------------------------------------------------------
101 52:A8:00:01:01:10 STATIC VxLAN DIP: 10.113.100.1
101 52:A8:00:01:01:31 DYNAMIC Ethernet10
101 52:A8:00:01:01:40 STATIC VxLAN DIP: 10.113.100.4
102 52:A8:00:01:02:20 STATIC VxLAN DIP: 10.113.100.2
102 52:A8:00:01:02:32 DYNAMIC Ethernet11Отличия только в записях, изученных через EVPN. Они считаются статичными и не протухают по таймауту, такие записи будут удалены, только когда удаленный VTEP отзовет маршрут RT-2. Исходящим интерфейсом для них будет VXLAN-интерфейс. На основе тех же RT-2 он определит, какой VNI использовать для инкапсуляции и на какой next-hop отправить пакет.
Если MAC-адрес получателя неизвестен, то коммутатор будет «флудить» такой кадр во все интерфейсы этого VLAN, включая VXLAN-интерфейс. По списку рассылки (вывод show vxlan remote vtep) он отправит нужное количество unicast-копий оригинального кадра. Этот метод называется head end replication, или ingress replication.
Изученные МАС-адреса можно посмотреть и в самом EVI. Общий вывод — по команде show evpn mac. Опции для селекции вывода по конкретному MAC, VTEP или экземпляру EVPN:
leaf3# show evpn mac
Flags: D - duplicate, S - sticky, V - SVI
-------------------------------------------------------------------------------
VNI MAC VLAN Origin Interface/VTEP 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Этот вывод дополняется информацией о VNI, происхождении записи (локальная или удаленная) и счетчиком ММ. Он используется для работы MAC Mobility, но про него мы расскажем в другой раз.
Собственно, осталось посмотреть, могут ли хосты общаться в пределах VNI:
root@srv1:~# ip a show e0
2: e0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:a8:00:01:01:10 brd ff:ff:ff:ff:ff:ff
inet 192.168.101.10/24 brd 192.168.101.255 scope global e0
valid_lft forever preferred_lft forever
root@srv1:~# ip neigh
192.168.101.31 dev e0 lladdr 52:a8:00:01:01:31 REACHABLE
192.168.101.40 dev e0 lladdr 52:a8:00:01:01:40 REACHABLE
root@srv1:~# 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=64 time=2.84 ms
64 bytes from 192.168.101.31: icmp_seq=2 ttl=64 time=1.65 ms
--- 192.168.101.31 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 1.653/2.244/2.835/0.591 ms
root@srv1:~# 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=64 time=2.91 ms
64 bytes from 192.168.101.40: icmp_seq=2 ttl=64 time=1.95 ms
--- 192.168.101.40 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 1.947/2.430/2.913/0.483 ms
root@srv1:~# ping -c 2 192.168.102.20
ping: connect: Network is unreachable
root@srv1:~# ping -c 2 192.168.102.32
ping: connect: Network is unreachable Для конечных узлов (клиентов) инфраструктура остается прозрачной, взаимодействие осуществляется посредством Ethernet-коммутации, имитируя подключение всех AC клиента к одному L2-коммутатору. Кроме того, VXLAN-инкапсуляция изолирует различных клиентов или сервисы.
Помимо сценариев, которые я описал выше, вы можете настроить такую функциональность: ECMP (Equal-Cost Multi-Path), ARP Suppression, MAC Мobility и DAD (Duplicate address detection).
Сама по себе L2-функциональность — не исчерпывающая, так как нужно еще организовать маршрутизацию с внешними сетями или между EVI. В следующей статье рассмотрим централизованную и распределенную модели маршрутизации для overlay-сетей.
Если хотите больше узнать о разработке коммутаторов KORNFELD, читайте эти материалы: