3. Настройка EVPN L3 VXLAN

Связность на 2-ом уровне это, конечно, хорошо, но что если нам необходимо общаться и с узлами, расположенными в других VNI? Просто так покинуть VNI мы не можем - для этого нам нужен маршрутизатор. В EVPN функциональность маршрутизации носит название "Integrated Routing and Bridging" и описана в RFC 9135. Интерфейсы внутри VNI, с помощью которых мы можем выйти за пределы VNI (шлюзы по умолчанию) в EVPN называются IRB-интерфейсами.

Есть две IRB-модели, которые мы можем использовать для организации взаимодействия между VNI: асимметричная и симметричная. Модель "централизованный шлюз" мы рассматривать не будем.

В асимметричной модели мы на каждом лифе настраиваем все VNI, которые присутствуют у нас в фабрике, даже если за локальным лифом нет подключенных клиентов в этих VNI. Маршрутизация между VNI происходит на первом хопе - или на ingress VTEP (для чего и нужно заведение всех VNI на каждый лиф). После перекладывания пакета из родительского VNI в VNI назначения, пакет путешествует до выходного VTEP'а уже в нужном VNI, а выходной VTEP делает коммутацию между VNI и локальным VLAN'ом.

Асимметричная модель IRB

Здесь на Leaf-1 настраиваются оба VNI (100 и 200), даже не смотря на то, что на нем нет клиентов в VNI 200. Маршрутизация происходит только на первом хопе (на Ingress VTEP). Входной VTEP маршрутизирует пакет из VNI в VNI, а выходной VTEP просто коммутирует его в нужный VLAN. Недостаток такого подхода - нужно на каждом VTEP заводить все VNI, а также каждый VTEP должен будет держать информацию о всех L2-адресах в фабрике, что может быть весьма ощутимым в условиях дефицита аппаратных ресурсов памяти.

Симметричная модель дает возможность настраивать на каждом Leaf'е только те VNI, за которыми есть физические клиенты. Все остальные VNI не настраиваются - вместо них выделяется один-единственный VNI, который будет служить как бы транзитным VNI для всего маршрутизируемого трафика. Таким образом вместо забивания всех ненужных нам VNI, мы настраиваем только один. Теперь маршрутизация будет происходить не только на входном VTEP, но и на выходном. Наглядно можно проиллюстрировать картинкой:

Симметричная модель IRB с использованием L3VNI

Здесь на Leaf-1 не настраивается VNI 200, а только транзитная L3VNI. Может возникнуть вопрос - а что мы выиграли? А представьте, что VNI у нас не две штуки, а сто, двести, тысяча?

Мы будем использовать модель симметричного IRB, чтобы не плодить лишних VNI на каждом Leaf'е, а также немножко сэкономить аппаратные L2-ресурсы для FDB. В качестве шлюзов по умолчанию будут использоваться статические anycast-шлюзы (SAG) по схеме "распределенный шлюз" (Distributed Gateway), то есть на каждом Leaf'е в каждом VNI будет создан интерфейс и назначен IP-адрес, который будет служить адресом шлюза по умолчанию для локально подключенных клиентов.

Согласно RFC 9135, пункт 4.1 существуют два подхода к настройке SAG. В первом случае мы настраиваем одинаковый IP и MAC на каждом IRB-интерфейсе конкретного VNI. Во втором варианте мы настраиваем одинаковый IP, но MAC на каждом IRB-интерфейсе конкретного VNI остается уникальным.

Чем хорош первый подход? Тем, что если конечный узел мигрирует с VTEP на VTEP, ему не придется обновлять ARP-запись своего шлюза по умолчанию, он может сразу после миграции начинать работать так, как будто никакой миграции и не было. В случае же с уникальным MAC, обновление в конечном счете потребуется. В принципе, для облегчения обновления ARP-записи шлюза конечным хостом RFC предлагает использовать механизм MAC Aliasing, при котором VTEP'ы анонсируют свои IRB-интерфейсы в EVPN с помощью RT-2 маршрутов, при этом добавляя к ним специальное комьюнити Default Gateway. Другие VTEP'ы, принимая маршрут с таким комьюнити, должны понимать, что такой-то MAC-адрес принадлежит IRB-интерфейсу удаленного VTEP, и должны считать его MAC-адрес - своим собственным, принимая на него Ethernet-кадры, как будто бы это был их локальный MAC! Таким образом перерыва в работе мигрировавшего клиента не должно быть, а в конечном итоге его ARP-запись обновится на актуальную.

Все же второй вариант мне не очень нравится тем, что требуется усложнение плоскости управления - собственно, необходимо генерировать дополнительные маршруты с комьюнити Default GW, нужно их обрабатывать, нужно строить списки MAC Aliasing, нужно сверять DST_MAC приходящих Ethernet-кадров со списком - а не нужно ли нам принять данный кадр? И ради чего? Не проще ли изначально настроить одинаковый anycast MAC на каждом Leaf статически? Мне кажется, что проще. Так и настроим. MAC-адреса каждого IRB-интерфейса для всех четырех Leaf'ов будут совпадать.

Клиенты, адреса и топология

Немножко переделаем L2 и L3-топологии широковещательных доменов, в которых находятся наши клиенты. Сейчас мы поместим каждого клиента в свой собственный VNI, а между ними настроим маршрутизацию. Наши клиенты будут иметь связь друг с другом только через 3-ий уровень (через свои шлюзы - IRB-интерфейсы). Следовательно, наша предыдущая единая плоская сеть 192.168.100.0/24 уже не подойдет. Выделим четыре сети, по одной на каждого клиента:

Коммутатор
IRB-интерфейс
VLAN

Leaf-1

192.168.101.254/24

101

Leaf-2

192.168.102.254/24

102

Leaf-3

192.168.103.254/24

103

Leaf-3

192.168.104.254/24

104

MAC, IP-адреса, VLAN, VNI клиентов, подключенных к Leaf-устройствам.

Клиент
MAC
IP/Mask
VLAN

Client-1

02:01:00:00:00:01

192.168.101.1/24

101

Client-2

02:01:00:00:00:02

192.168.102.2/24

102

Client-3

02:01:00:00:00:03

192.168.103.3/24

103

Client-4

02:01:00:00:00:04

192.168.104.4/24

104

IP-VRF будет иметь имя VRF1.

Ассоциации VLAN : VNI и их RT

VLAN
VNI
RT

101

1101

100:1101

102

1102

100:1102

103

1103

100:1103

104

1104

100:1104

Топология:

Топология L3 VXLAN

Настройка

Как-то менять настройки на Spine после тех, которые были сделаны для L2VXLAN, необходимости нет. Вся конфигурация для L3VXLAN будет произведена на Leaf-коммутаторах.

Настройка Leaf-1

Очистим на лифах конфигурацию overlay, сделанную в предыдущей части. Начальная конфигурация, с которой мы начинаем работать на Leaf-1, сейчас выглядит так:

Погнали!

Во-первых, создадим VRF1 и включим для него маршрутизацию:

Далее создадим VLAN 101, в котором будут наши клиенты (один клиент, но не важно, клиентов могло быть и несколько):

Теперь настроим физический порт, в который подключен наш клиент Client-1:

Теперь создадим IRB-интерфейс для VLAN 101 и установим на него anycast IP-адрес, который будет служить шлюзом по умолчанию для наших клиентов в данном VLAN. Также поместим этот IRB-интерфейс в VRF1:

Теперь настроим интерфейс VXLAN:

Из интересного - здесь мы назначили VNI 1100 на VRF1, то есть превратили VNI 1100 в L3-VNI, который будет служить транзитным VNI для маршрутизации между VNI в VRF1.

Теперь настроим anycast MAC-адрес для наших IRB-интерфейсов:

Настроим MAC-VRF для VLAN 101:

Теперь настроим L3VNI для VRF1, который мы будем использовать для передачи маршрутизируемого трафика (inter-VNI):

Важно отметить, что импорт- и экспорт-RT должны совпадать на всех VTEP для данного VRF.

Теперь включим AF EVPN в настройках процесса BGP:

Общий вид сделанных нами настроек:

Настройка Leaf-2

Напомним, с чем мы начинаем:

Конфигурация Overlay:

Настройка Leaf-3

Начальная конфигурация:

Конфигурация Overlay:

На этом конфигурацию можно считать законченной. Теперь клиенты должны видеть друг друга на третьем уровне. Проверим!

Проверки

Проверка Spine-1

Посмотрим на маршруты MAC/IP:

Видим по одному маршруту MAC-only и по одному маршруту MAC/IP для каждого клиента.

Посмотрим на них поподробнее:

Обратим внимание, что в маршрутах MAC+IP появился второй Route Target, соответствующий RT для нашего VRF1 (то есть один RT - это RT MAC-VRF, а другой RT - это RT IP-VRF), а также появилось указание L3 VNI для данного маршрута, с помощью которого можно смаршрутизировать трафик, предназначенный для данного хоста.

Также обратим внимание, что здесь появляется комьюнити Router's MAC: EvpnRouterMac на MAC/IP-маршрутах. В этом комьюнити указан MAC-адрес VTEP'а, который является некст-хопом для данного маршрута. Этот MAC нужен для того, чтобы входной (ingress) удаленный VTEP установил данный MAC как DST_MAC во внутреннем инкапсулированном кадре VXLAN. Таким образом, когда выходной (egress) VTEP получит этот кадр, он увидит, что DST_MAC является его локальным MAC, таким образом поднимет пакет на 3-ий уровень для маршрутизации. Без локального MAC в DST_MAC внутреннего кадра, наш VTEP просто отправил бы его в свои порты согласно обычной политике форвардинга на 2-ом уровне и никакой маршрутизации у нас не случилось бы. Для этого и нужен атрибут Router's MAC и он обязательно присутствует в маршруте, где есть присутствует L3VNI.

Маршруты MAC+IP будут установлены в таблицу маршрутизации VRF1.

Проверка Spine-2

Проверка Leaf-1

Сессии у нас установлены только со Spine-ами, в обоих AF - IPv4 Unicast и в L2VPN EVPN.

Посмотрим, какие маршруты EVPN есть в RIB нашего Leaf-1:

Некоторые маршруты получены дважды - для каждого из Spine.

Проверка EVI:

Туннели построены только для unicast-трафика (что логично - общих L2VNI с другими Leaf'ами у нас нет).

Взглянем на таблицу маршрутизации VRF1:

Мы видим, что коммутатор установил в таблицу маршрутизации маршруты до других клиентов, доступных в других VNI. Ариста наглядно показывает здесь IP-адрес удаленного VTEP'а, номер VNI, Router's MAC VTEP'а, а также локальный VXLAN-интерфейс.

Проверка Leaf-2

Пробежимся вкратце.

EVI:

И таблица маршрутизации:

Видим маршруты до остальных клиентов в других VNI.

Проверка Leaf-3

EVI:

Ну и взглянем на таблицу маршрутизации:

Две сети являются локальными, о двух клиентах мы знаем от удаленных VTEP'ов.

Проверка связности между клиентами

Проверять будем следующим образом. Сначала мы на клиенте делаем пинг другого клиента (физически находящегося за другим Leaf'ом). Затем смотрим в tcpdump и проверяем, действительно ли трафик инкапсулируется в L3VNI, а не в L2VNI.

Далее пингуем всех остальных клиентов. Так повторяем со всеми клиентами (кроме tcpdump, его сделаем только для первого пинга).

На всякий случай еще раз приведем настройки каждого клиента: Client-1

Client-2

Client-3

Client-4

Итак, проверяем. Запускаем пинг с Client-1 до Client-4. Как это выглядит на топологии (обратный трафик идет зеркально):

Путь прохождения ICMP эхо-запроса от Client-1 до Client-4

Захватываем трафик в Wireshark и смотрим, в каком виде ходят пакеты. На интерфейсе eth3 на Leaf-1 (к которому подключен Client-1), пакеты ICMP Request и ICMP Reply выглядят так:

Запрос: SRC_MAC - наш клиент, DST_MAC - Anycast MAC IRB-интерфейса. SRC_IP - IP Client-1, DST_IP - IP Client-4

Ответ: SRC_MAC - аппаратный адрес Leaf-1, DST_MAC - MAC Client-1. SRC_IP - IP Client-4, DST_IP - IP Client-1

Обычный обмен трафиком, без каких-либо инкапсуляций.

А теперь посмотрим на интерфейс Ethernet1 на Leaf-1, который смотрит в Spine-1. В каком виде здесь мы увидим наш ICMP-обмен?

Тут мы уже видим инкапсуляцию в VNI 1100 - это наш L3VNI. Разберем первый кадр. OUTER_SRC_MAC: аппаратный MAC Leaf-1, OUTER_DST_MAC: MAC-адрес Spine-1. OUTER_SRC_IP: Loopback-адрес Leaf-1 (он же VTEP IP), OUTER_DST_IP: Loopback-адрес Leaf-3 (он же VTEP IP). OUTER_DST_UDP_PORT: 4789 - well-known порт VXLAN. VNI: 1100: L3VNI VRF, в котором живут клиенты. INNER_SRC_MAC: аппаратный MAC Leaf-1. INNER_DST_MAC: аппаратный MAC Leaf-3. INNER_SRC_IP: IP-адрес Client-1. INNER_DST_IP: IP-адрес Client-4.

Аппаратный MAC Leaf-3 был взят из комьюнити Router's MAC в маршруте RT-2 для MAC/IP Client-4:

Разберем второй кадр (с ответом). OUTER_SRC_MAC: аппаратный MAC Spine-1, OUTER_DST_MAC: MAC-адрес Leaf-1. OUTER_SRC_IP: Loopback-адрес Leaf-3 (он же VTEP IP), OUTER_DST_IP: Loopback-адрес Leaf-1 (он же VTEP IP). OUTER_DST_UDP_PORT: 4789 - well-known порт VXLAN. VNI: 1100: L3VNI VRF, в котором живут клиенты. INNER_SRC_MAC: аппаратный MAC Leaf-3. INNER_DST_MAC: аппаратный MAC Leaf-1 (он же взят из комьюнити Router's MAC маршрута RT-2 для Client-1). INNER_SRC_IP: IP-адрес Client-4. INNER_DST_IP: IP-адрес Client-1.

Маршрут RT-2 для Client-1 с Router's MAC:

Посмотрим на интерфейс Ethernet1 на Leaf-3, где мы принимаем пакеты от Spine-1:

Пакеты приходят, инкапсулированные в VXLAN VNI 1100 (L3VNI).

Теперь глянем на интерфейс Ethernet4, в который на Leaf-3 подключен клиент Client-4:

Внешний IP-пакет и VXLAN-заголовки были сняты, и теперь трафик в сторону Client-4 (и от него) идет как обычный IP, без инкапсуляции.

Таким образом мы убедились, что пинги между Client-1 и Client-4 ходят инкапсулированными в L3VNI 1100.

В ARP-таблице у Client-1 только адрес шлюза:

Пропингуем остальных:

Связность есть.

Сделаем проверки для Client-2, Client-3 и Client-4: Client-2:

ARP-таблица Client-2:

Client-3:

ARP-таблица Client-3:

Client-4:

ARP-таблица Client-4:

Всё работает. Теперь мы можем перейти к настройке резервируемости для конечных узлов - EVPN Multihoming.

Previous2. Настройка EVPN L2 VXLANNext4. Настройка EVPN Multihoming

Last updated