Labs

⌘K
  6. Labs
  8. Дизайн сетей ЦОД...
  10. VxLAN

VxLAN

Сценарий

Компания GreenSkills, занимающая лидирующие позиции в области инновационных цифровых технологий, столкнулась с необходимостью расширения своих возможностей в связи с увеличением числа клиентов. Существующих мощностей центра обработки данных (ЦОД) оказалось недостаточно для обеспечения качественного и бесперебойного предоставления сервисов.

Для решения этой проблемы компания приняла решение о закупке нового оборудования от компании Arista и аренде стойки в новом, современном центре обработки данных. Это позволит GreenSkills увеличить производительность и эффективность своих сервисов, а также обеспечить высокий уровень удовлетворённости клиентов.

GreenSkills планирует использовать лучшие практики с самыми современными технологиями и инфраструктурами, что позволит компании оставаться на переднем крае цифровых технологий и успешно конкурировать на рынке.

В процессе проектирования вам предстоит настроить VXLAN фабрику для удовлетворения потребностей растущей сети:

  • Собрать схему CLOS, распредеоить адресное пространство.
  • Настроить underlay-сеть при помощи IGP.
  • Настроите BGP peering между Leaf и Spine в AF l2vpn evpn.
  • В overlay сети VxLAN обеспечить связность клиентов в L2VNI.
  • VxLAN. L3VNI настроить маршрутизацию между клиентами в одной зоне безопасности.
  • Создать 3 зоны безопасности (vrf). Обеспечить связность через firewall.

Эта лабораторная работа представляет собой не просто упражнение, а полноценную среду, где теоретические знания применяются на практике. Её цель — помочь вам глубже понять роль технологии VXLAN и её интеграцию с различными сетевыми компонентами. В процессе выполнения лабораторной работы вы сможете отточить свои навыки и освоить лучшие практики, необходимые каждому сетевому инженеру.

Применяя полученные знания и опыт, вы сможете внести вклад в развитие компании GreenSkills и помочь ей выйти на новый уровень. Это отличная возможность продемонстрировать свой потенциал и создать сеть, которая будет не только масштабируемой и надёжной, но и станет основой для достижения амбициозных целей компании. Работая с GreenSkills, вы сможете принять участие в формировании будущего сетевых технологий.

Лабораторная работа требует внимательного изучения и терпения. Не спешите сразу же приступать к изучению и настройке — если возникнут трудности, обратитесь к статьям и урокам. Такой подход позволит вам получить максимальную пользу от лабораторной работы и достичь глубокого понимания сетевых технологий.

1. Топология

1.1 IPv4

Топология Underlay сети:

2. Задачи

2.1 Проектирование адресного пространства

  • Определиться с логикой распределения p2p линков.
  • Определиться с логикой распределения loopback-интерфейсов.
  • Выделить агрегирующую подсеть; выделить из агрегирующей подсети пулы для клиентов.

2.2 Базовая настройка

  • Настроить hostname на оборудовании
  • Все порты должны быть подписаны согласно топологии

2.3 Настройка Underlay сети.

  • С помощью выбранного IGP настроить маршрутизацию внутри фабрики.
  • Обеспечить доступность между Lo1, Lo2 сетевого оборудования внутри фабрики.
  • Настроить BFD.

2.4 Настройка Overlay сети — VxLAN L2VNI.

  • Настроите BGP peering между Leaf и Spine в AF l2vpn evpn.
  • В overlay сети VxLAN обеспечить связность клиентов в L2 VNI.

2.5 VxLAN L3VNI.

  • Настроить маршрутизацию в рамках Overlay между разными VLAN(VxLAN) в одной зоне безопасности
  • Настроите каждого клиента в своем VNI

2.6 VxLAN. Routing

  • Настройте дополнительные зоны безопасности (VRF).
  • Анонсируете суммарные префиксы клиентов в Overlay сеть.
  • Настроите маршрутизацию между клиентами через суммарный префикс. Для связи между зонами безопасности используйте Firewall.
  • Настройте выход в интернет для клиентов.

3. Решение

Для выполнения лабораторной работы будут использованы следующие образы:

  • SPINE, LEAF коммутаторы — Arista switch образ veos-4.29.2F. 1CPU/2048MB RAM/qemu arch x86_64/qemu nic virtio-net-pci/qemu version 4.1.0. Login — admin, Password — none.
  • SRV и Admin — Astra Linux 1.7.5 Смоленск. 2CPU/4096MB RAM/qemu arch x86_64/qemu nic virtio-net-pci/qemu version 4.1.0.
  • Firewall Huawei USG6000v — образ huaweiusg6kv-usg. 2CPU/4096MB RAM/qemu arch x86_64/qemu nic virtio-net-pci/qemu version 4.1.0
UPD: Особенности Arista в виртуализации

После перезагрузки по питанию ВМ Arista из таблицы маршрутизации пропадают(и не пингуются) loopback-интерфейсы. Нужно скопировать конфигурацию, затиреть(wipe) железку и заново заливать конфигурацию с описанной далее двойной перезагрузкой.

3.1 Проектирование адресного пространства

Логика распределения p2p линков:

192.168.N.2*(M-1)/31 – p2p Spine N <-> Leaf M

M= [1 .. 128]

Например:

  • 192.168.1.0/31 — p2p Spine1-Leaf1
  • 192.168.1.2/31 — p2p Spine1-Leaf2
  • 192.168.2.0/31 — p2p Spine2-Leaf1
  • 192.168.2.2/31 — p2p Spine2-Leaf2

Логика распределения loopback-ов:
Чётные + 0 подсеть отдаём Spine. Нечётные подсети отдаём под Leaf:

  • 10.100.0.N/24 — Lo1 SpineN, где N — номер Spine
  • 10.100.1.M/24 — Lo1 LeafM, где M — номер Leaf
  • 10.100.2.N/24 — Lo2 SpineN, где N — номер Spine
  • 10.100.3.M/24 — Lo2 LeafM, где M — номер Leaf
  • 10.100.7.0/24 — FW-интерконекты

Адресация клиентов VXLAN-фабрики(агрегирующая подсеть 10.100.100.0/22):

ИмяIDАдрес/МаскаШлюзИмя VRFЗона безопасностиОписание
admins10010.100.100.0/2410.100.100.1adminsadminsПодсеть администраторов
green-srv10110.100.101.0/2410.100.101.1green-srvgreenСерверная подсеть green
yellow-srv10210.100.102.0/2410.100.102.1yellow-srvyellowСерверная подсеть yellow

3.2 Базовая настройка

Первым делом отключаем zerotouch на Spine/Leaf коммутаторах, после откючения автоматически запустится перезагрузка:

localhost>zerotouch disable

Далее настраиваем hostname, интерконнекты между коммутаторами, loopback-интерфесы согласно топологии. Активное сетевое оборудование именуется по схеме: <Префикс площадки>-<Город>-<Модель оборудования>-<Номер>-<Функциональная роль>

localhost>en
localhost#conf t
localhost(config)#hostname LEAF1
LEAF1(config)#int eth1
LEAF1(config-if-Et1)#no switchport 
LEAF1(config-if-Et1)#description -=SPINE1;eth1=-
LEAF1(config-if-Et1)#ip address 192.168.1.1/31
LEAF1(config-if-Et1)#mtu 9000
LEAF1(config-if-Et1)#int eth2
LEAF1(config-if-Et2)#no switchport 
LEAF1(config-if-Et2)#description -=SPINE2;eth1=-
LEAF1(config-if-Et2)#ip address 192.168.2.1/31
LEAF1(config-if-Et2)#mtu 9000
LEAF1(config-if-Et2)#interface loopback 1
LEAF1(config-if-Lo1)#description Router-ID
LEAF1(config-if-Lo1)#ip address 10.100.1.1/32
LEAF1(config-if-Lo1)#interface loopback 2
LEAF1(config-if-Lo2)#description VTEP source 
LEAF1(config-if-Lo2)#ip address 10.100.3.1/32
LEAF1(config-if-Et2)#service routing protocols model multi-agent
! Change will take effect only after switch reboot
LEAF1(config)#ip routing
LEAF1(config)#write 
Copy completed successfully.
LEAF1(config)#reload

Аналогичные настройки выполняем на остальных коммутатрах фабрики. Как вы могли заметить на p2p линках первый адрес в подсети отдаётся SPINE-коммутаторам. Отличие в конфигурации будет на SPINE-коммутаторах только в том что не будет Loopback2.

Что за команда? service routing protocols model multi-agent

Команда service routing protocols model multi-agent на коммутаторах Arista используется для настройки модели маршрутизации Multi-Agent Routing (MAR), которая позволяет улучшить масштабируемость и отказоустойчивость сети за счет распределения нагрузки между несколькими агентами маршрутизации. Это особенно полезно в больших сетях, где требуется высокая производительность и надежность. В нашем случае это позволит в полной мере использовать протокол BFD в BGP.

Зачем настраивать MTU 9000 на интерфейсах?

Улучшение производительности: Увеличение MTU до 9000 байт позволяет передавать больше данных за один пакет, что может ускорить передачу данных и снизить нагрузку на сеть. Это особенно важно в средах, где требуется высокая пропускная способность, например, при передаче больших объемов данных, таких как видеоконференции, потоковое мультимедиа или передача файлов.

Упрощение конфигурации: Настройка MTU на уровне 9000 байт может упростить конфигурацию сети, поскольку уменьшает необходимость в настройке различных MTU на разных устройствах. Это особенно полезно в сложных сетевых архитектурах, где множество устройств взаимодействуют друг с другом.

Совместимость с jumbo-фреймами: MTU 9000 байт соответствует размеру jumbo-фреймов, поддерживаемых некоторыми сетевыми устройствами. Использование jumbo-фреймов может повысить эффективность передачи данных за счет уменьшения количества заголовков и служебных данных в каждом пакете.

Неплохая статья с тестированием размеров MTU в VxLAN фабрике.

Настраиваем клиентов(linux-сервера) на примере srv-green-1:

#Настройка адресации интерфейса:
adminisrator@astra:~$ nano /etc/network/interfaces

auto eth0
iface eth0 inet static
address 10.10.100.10/24
gateway 10.10.100.1

#Настройка DNS:
adminisrator@astra:~$ nano /etc/resolv.conf

nameserver 77.88.8.8

#Настройка hostname:
adminisrator@astra:~$ hostnamectl set-hostname srv-green1

adminisrator@astra:~$ nano /etc/hosts
*меняем astra на srv-green-1* 
#Нужен ребут

3.3 Настройка Underlay сети

С помощью выбранного IGP настроить маршрутизацию внутри фабрики.

Требования к протоколу маршрутизации

  • Доставка маршрутной информации
  • Быстрая сходимость
  • Маштабируемость
  • Поддержка большого количества префиксов
  • Мультипротокольное использование (IPv4 & IPv6)
  • Распределение балансировки
  • Простота обслуживания сети
  • Удобство автоматизации

В качестве IGP для Underlay в данной лабораторной будем использовать iBGP. При самостоятельном выполнении можете выбрать любой протокол на свой вкус — OSPF, IS-IS или даже eBGP!

Почему iBGP?
  • Один протокол, не требуются IGP (OSPF, IS-IS)
  • Позволяет гибко управлять маршрутной информацией
  • Leaf имеет только сессии со Spine
  • Проще конфигураци

Общие рекомендаци по настройке iBGP как Underlay в сетях CLOS.
  • Использовать Spine как route-reflector, Leaf как oute-reflector-client
  • Включать multipath
  • Использовать одну BGP сессию для передачи информации для множественных address families
  • Настроить таймеры более агрессивно
  • Использовать BFD
  • Использовать route-map, при анонсе локальных префиксов
  • Суммировать маршруты только на Leaf-коммутаторах
  • Сохранять конфигурацию минимально необходимой и простой

Рекомендации по настройке таймеров.
  • Advertisement interval timer = 0 sec (default for iBGP)
  • Keepalive Timer = 3 sec (default 60 sec)
  • Hold Timer = 9 sec (default 180 sec)
  • Connect Timer = 60 sec (default)

Рекомендации по настройке BFD.
  • Tx/Rx 100 ms x 3
  • MicroBFD если используются LAG

Начнём настройку с SPINE коммутаторов. Как описано выше в рекомендациях они будут выступать в роли Route-Reflector. Прописываем наших соседей и объединяем их в одну peer-группу. При использовании peer-групп удобнее выполнять общие настройки не повторяя одни и те же конфигурации для каждого соседа:

router bgp 65100
   router-id 10.100.0.1
   neighbor 192.168.1.1 peer group LEAFS
   neighbor 192.168.1.1 description LEAF1
   neighbor 192.168.1.3 peer group LEAFS
   neighbor 192.168.1.3 description LEAF2
   neighbor 192.168.1.5 peer group LEAFS
   neighbor 192.168.1.5 description LEAF3
Что такое Route Reflector в iBGP?


Route Reflector в контексте IBGP (Internal Border Gateway Protocol) является методом, позволяющим уменьшить требования к полносвязной топологии между всеми узлами BGP в одной автономной системе (AS). Вместо того чтобы каждый узел BGP обменивался маршрутами со всеми остальными узлами в AS, Route Reflector позволяет одному или нескольким узлам действовать как отражатели маршрутов (Route Reflectors или RR).

Узел RR принимает маршруты от других узлов IBGP и отражает их обратно своим клиентам, формируя таким образом кластеры. Клиенты узла RR получают отраженные маршруты, что позволяет им обмениваться информацией о маршрутах без необходимости устанавливать прямые соединения со всеми другими узлами IBGP в AS.

Преимущества использования Route Reflector включают снижение нагрузки на сеть и улучшение масштабируемости, поскольку уменьшается количество необходимых сессий IBGP. Это особенно полезно в больших сетях, где обмен большими объемами маршрутной информации между множеством узлов может стать проблемой.

Важно отметить, что для предотвращения петель при отражении маршрутов используются два новых необязательных непереходных атрибута BGP: ORIGINATOR_ID и CLUSTER_LIST. Эти атрибуты помогают идентифицировать источник маршрута и отслеживать путь его отражения, соответственно, предотвращая петли в сети.

Создаём route-map в которой будем объявлять что мы хотим анонсировать в iBGP, в случае SPINE — Loopback1.

route-map rm_redistribute_lo permit 10
   match interface Loopback1
   set origin igp
!
route-map rm_redistribute_lo deny 40

Настройка группы соседей, таймеров BGP, технологий BFD и RR. 

router bgp 65100
timers bgp 3 9
maximum-paths 10 ecmp 10
neighbor LEAFS bfd 
neighbor LEAFS bfd interval 100 min-rx 100 multiplier 3
neighbor LEAFS next-hop-self
neighbor LEAFS remote-as 65100
neighbor LEAFS route-reflector-client
redistribute connected route-map rm_redistribute_lo
  !
   address-family ipv4
      neighbor LEAFS activate
Опция next-hop-self

Опция next-hop-self в IBGP (Internal Border Gateway Protocol) позволяет принудительно использовать текущий маршрутизатор в качестве следующего хопа (Next Hop) для всех маршрутов, анонсируемых другим маршрутизаторам в той же автономной системе (AS). По умолчанию, в IBGP, следующий хоп для внутренних маршрутов устанавливается как IP-адрес источника внутреннего маршрута, который был введен в BGP. Однако, если необходимо явно указать, что следующий хоп должен быть установлен как адрес самого маршрутизатора, отправляющего маршрут, используется команда next-hop-self.

Это может быть полезно в случаях, когда необходимо гарантировать, что следующий хоп для всех маршрутов, анонсируемых через IBGP, всегда будет указывать на текущий маршрутизатор. Это помогает избежать ситуаций, когда следующий хоп может быть недоступен, что может привести к проблемам с достижением удаленных сетей.

Опция maximum-path 10 ecmp 10

В контексте маршрутизации определяет максимальное количество равноценных путей (ECMP — Equal Cost Multi-Path), которые могут быть использованы для балансировки трафика.

ECMP позволяет распределить трафик по нескольким путям с одинаковой стоимостью, обеспечивая более высокую доступность и надежность сети. Если доступно более 10 равноценных путей, устройство будет использовать только первые 10, установленные этой опцией.

Общая настройка BGP на SPINE1 будет выглядеть так:

route-map rm_redistribute_lo permit 10
   match interface Loopback1
   set origin igp
!
route-map rm_redistribute_lo deny 40
!
router bgp 65100
   router-id 10.100.0.1
   timers bgp 3 9
   maximum-paths 10 ecmp 10
   neighbor LEAFS peer group
   neighbor LEAFS remote-as 65100
   neighbor LEAFS next-hop-self
   neighbor LEAFS bfd
   neighbor LEAFS bfd interval 100 min-rx 100 multiplier 3
   neighbor LEAFS route-reflector-client
   neighbor 192.168.1.1 peer group LEAFS
   neighbor 192.168.1.1 description LEAF1
   neighbor 192.168.1.3 peer group LEAFS
   neighbor 192.168.1.3 description LEAF2
   neighbor 192.168.1.5 peer group LEAFS
   neighbor 192.168.1.5 description LEAF3
   redistribute connected route-map rm_redistribute_lo
!
   address-family ipv4
      neighbor LEAFS activate
SPINE2 

route-map rm_redistribute_lo permit 10
   match interface Loopback1
   set origin igp
!
route-map rm_redistribute_lo deny 40
!
router bgp 65100
   router-id 10.100.0.2
   timers bgp 3 9
   maximum-paths 10 ecmp 10
   neighbor LEAFS peer group
   neighbor LEAFS remote-as 65100
   neighbor LEAFS next-hop-self
   neighbor LEAFS bfd
   neighbor LEAFS bfd interval 100 min-rx 100 multiplier 3
   neighbor LEAFS route-reflector-client
   neighbor 192.168.2.1 peer group LEAFS
   neighbor 192.168.2.1 description LEAF1
   neighbor 192.168.2.3 peer group LEAFS
   neighbor 192.168.2.3 description LEAF2
   neighbor 192.168.2.5 peer group LEAFS
   neighbor 192.168.2.5 description LEAF3
   redistribute connected route-map rm_redistribute_lo
!
   address-family ipv4
      neighbor LEAFS activate

На стороне LEAF-ов практически идентичная, только будут отсуствовать атрибуты next-hop-self и route-reflector-client(потому что LEAFы сами по себе клиенты RR). Пример настройки на LEAF1:

route-map rm_redistribute_lo permit 10
   match interface Loopback1
   set origin igp
!
route-map rm_redistribute_lo permit 20
   match interface Loopback2
   set origin igp
!
route-map rm_redistribute_lo deny 40
!
router bgp 65100
   router-id 10.100.1.1
   maximum-paths 10 ecmp 10
   timers bgp 3 9
   neighbor SPINES peer group
   neighbor SPINES remote-as 65100
   neighbor SPINES bfd
   neighbor SPINES bfd interval 100 min-rx 100 multiplier 3
   neighbor 192.168.1.0 peer group SPINES
   neighbor 192.168.1.0 description SPINE1
   neighbor 192.168.2.0 peer group SPINES
   neighbor 192.168.2.0 description SPINE2
   redistribute connected route-map rm_redistribute_lo
  !
   address-family ipv4
      neighbor SPINES activate
!

Повторяем настройку на LEAF2 и Border-Leaf1:

Boreder-Leaf1: 

route-map rm_redistribute_lo permit 10
   match interface Loopback1
   set origin igp
!
route-map rm_redistribute_lo permit 20
   match interface Loopback2
   set origin igp
!
route-map rm_redistribute_lo deny 40
!
router bgp 65100
   router-id 10.100.1.3
   timers bgp 3 9
   maximum-paths 10 ecmp 10
   neighbor SPINES peer group
   neighbor SPINES remote-as 65100
   neighbor SPINES bfd
   neighbor SPINES bfd interval 100 min-rx 100 multiplier 3
   neighbor 192.168.1.4 peer group SPINES
   neighbor 192.168.1.4 description SPINE1
   neighbor 192.168.2.4 peer group SPINES
   neighbor 192.168.2.4 description SPINE2
   redistribute connected route-map rm_redistribute_lo
!
   address-family ipv4
      neighbor SPINES activate
LEAF2 

route-map rm_redistribute_lo permit 10
   match interface Loopback1
   set origin igp
!
route-map rm_redistribute_lo permit 20
   match interface Loopback2
   set origin igp
!
route-map rm_redistribute_lo deny 40
!
router bgp 65100
   router-id 10.100.1.2
   timers bgp 3 9
   maximum-paths 10 ecmp 10
   neighbor SPINES peer group
   neighbor SPINES remote-as 65100
   neighbor SPINES bfd
   neighbor SPINES bfd interval 100 min-rx 100 multiplier 3
   neighbor 192.168.1.2 peer group SPINES
   neighbor 192.168.1.2 description SPINE1
   neighbor 192.168.2.2 peer group SPINES
   neighbor 192.168.2.2 description SPINE2
   redistribute connected route-map rm_redistribute_lo
 !
   address-family ipv4
      neighbor SPINES activate

Проверка работоспособности underlay с LEAF1:

LEAF1#sh ip route 

VRF: default
Codes: C - connected, S - static, K - kernel, 
       O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
       E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
       N2 - OSPF NSSA external type2, B - Other BGP Routes,
       B I - iBGP, B E - eBGP, R - RIP, I L1 - IS-IS level 1,
       I L2 - IS-IS level 2, O3 - OSPFv3, A B - BGP Aggregate,
       A O - OSPF Summary, NG - Nexthop Group Static Route,
       V - VXLAN Control Service, M - Martian,
       DH - DHCP client installed default route,
       DP - Dynamic Policy Route, L - VRF Leaked,
       G  - gRIBI, RC - Route Cache Route

Gateway of last resort is not set

 B I      10.100.0.1/32 [200/0] via 192.168.1.0, Ethernet1
 B I      10.100.0.2/32 [200/0] via 192.168.2.0, Ethernet2
 C        10.100.1.1/32 is directly connected, Loopback1
 B I      10.100.1.2/32 [200/0] via 192.168.1.0, Ethernet1
                                via 192.168.2.0, Ethernet2
 B I      10.100.1.3/32 [200/0] via 192.168.1.0, Ethernet1
                                via 192.168.2.0, Ethernet2
 C        10.100.3.1/32 is directly connected, Loopback2
 B I      10.100.3.2/32 [200/0] via 192.168.1.0, Ethernet1
                                via 192.168.2.0, Ethernet2
 B I      10.100.3.3/32 [200/0] via 192.168.1.0, Ethernet1
                                via 192.168.2.0, Ethernet2
 C        192.168.1.0/31 is directly connected, Ethernet1
 C        192.168.2.0/31 is directly connected, Ethernet2

LEAF1#sh ip bgp 
BGP routing table information for VRF default
Router identifier 10.100.1.1, local AS number 65100
Route status codes: s - suppressed contributor, * - valid, > - active, E - ECMP head, e - ECMP
                    S - Stale, c - Contributing to ECMP, b - backup, L - labeled-unicast
                    % - Pending BGP convergence
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI Origin Validation codes: V - valid, I - invalid, U - unknown
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop

          Network                Next Hop              Metric  AIGP       LocPref Weight  Path
 * >      10.100.0.1/32          192.168.1.0           0       -          100     0       i
 * >      10.100.0.2/32          192.168.2.0           0       -          100     0       i
 * >      10.100.1.1/32          -                     -       -          -       0       i
 * >Ec    10.100.1.2/32          192.168.2.0           0       -          100     0       i Or-ID: 10.100.1.2 C-LST: 10.100.0.2 
 *  ec    10.100.1.2/32          192.168.1.0           0       -          100     0       i Or-ID: 10.100.1.2 C-LST: 10.100.0.1 
 * >Ec    10.100.1.3/32          192.168.2.0           0       -          100     0       i Or-ID: 10.100.1.3 C-LST: 10.100.0.2 
 *  ec    10.100.1.3/32          192.168.1.0           0       -          100     0       i Or-ID: 10.100.1.3 C-LST: 10.100.0.1 
 * >      10.100.3.1/32          -                     -       -          -       0       i
 * >Ec    10.100.3.2/32          192.168.2.0           0       -          100     0       i Or-ID: 10.100.1.2 C-LST: 10.100.0.2 
 *  ec    10.100.3.2/32          192.168.1.0           0       -          100     0       i Or-ID: 10.100.1.2 C-LST: 10.100.0.1 
 * >Ec    10.100.3.3/32          192.168.2.0           0       -          100     0       i Or-ID: 10.100.1.3 C-LST: 10.100.0.2 
 *  ec    10.100.3.3/32          192.168.1.0           0       -          100     0       i Or-ID: 10.100.1.3 C-LST: 10.100.0.1 

LEAF1#sh ip bgp summary 
BGP summary information for VRF default
Router identifier 10.100.1.1, local AS number 65100
Neighbor Status Codes: m - Under maintenance
  Description              Neighbor    V AS           MsgRcvd   MsgSent  InQ OutQ  Up/Down State   PfxRcd PfxAcc
  SPINE1                   192.168.1.0 4 65100            603       603    0    0 00:25:34 Estab   5      5
  SPINE2                   192.168.2.0 4 65100            608       603    0    0 00:25:34 Estab   5      5

LEAF1# ping 10.100.3.2 source 10.100.3.1 repeat 1
PING 10.100.3.2 (10.100.3.2) from 10.100.3.1 : 72(100) bytes of data.
80 bytes from 10.100.3.2: icmp_seq=1 ttl=63 time=3.39 ms

--- 10.100.3.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 3.393/3.393/3.393/0.000 ms

LEAF1# ping 10.100.3.3 source 10.100.3.1 repeat 1
PING 10.100.3.3 (10.100.3.3) from 10.100.3.1 : 72(100) bytes of data.
80 bytes from 10.100.3.3: icmp_seq=1 ttl=63 time=4.57 ms

--- 10.100.3.3 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 4.576/4.576/4.576/0.000 ms

LEAF1# ping 10.100.0.1 source 10.100.3.1 repeat 1
PING 10.100.0.1 (10.100.0.1) from 10.100.3.1 : 72(100) bytes of data.
80 bytes from 10.100.0.1: icmp_seq=1 ttl=64 time=2.12 ms

--- 10.100.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 2.126/2.126/2.126/0.000 ms

LEAF1# ping 10.100.0.2 source 10.100.3.1 repeat 1
PING 10.100.0.2 (10.100.0.2) from 10.100.3.1 : 72(100) bytes of data.
80 bytes from 10.100.0.2: icmp_seq=1 ttl=64 time=1.81 ms

--- 10.100.0.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.816/1.816/1.816/0.000 ms

Тем самым используя iBGP с дополнением Route-Reflector нам удалось настроить underlay-сеть и обеспечить связность между loopback-ами внутри фабрики. Пришло время приступить к самому интересному — к настройке VxLAN!

3.4 Настройка Overlay сети — VxLAN L2VNI.

Для начала создаём vlan и настраиваем access порты на LEAF коммутаторах:

#Создаём vlan-ы:
LEAF1(config)#vlan 101
LEAF1(config-vlan-101)#name green-srv
LEAF1(config-vlan-101)#exit
LEAF1(config)#vlan 102
LEAF1(config-vlan-102)#name yellow-srv
LEAF1(config-vlan-102)#exit 
LEAF1(config)#vlan 100
LEAF1(config-vlan-100)#name admins
LEAF1(config-vlan-100)#exit 

#Настраиваем access-vlan на порту:
LEAF1(config-vlan-101)#int eth3
LEAF1(config-if-Et3)#switchport mode access 
LEAF1(config-if-Et3)#switchport access vlan 101
LEAF1(config-if-Et3)#description -=SRV-GREEN-1;eth0=-

Теперь настроим интерфейс VxLAN. Для этого укажем, что IP-адрес источника VTEP возьмём с интерфейса Loopback2 (те самые адреса которые мы передаём в undarlay). Этот адрес будет использоваться как внешний Source IP в VXLAN-пакетах.

BUM-трафик будем рассылать с помощью механизма Ingress Replication (копируем пришедшие от клиента BUM-пакеты и рассылаем их копии юникастом на удаленные VTEP, на которых есть соответствующий VNI). Таким образом нам не понадобится дополнительно организовывать маршрутизацию мультикаст-трафика в underlay-сети.

Затем мы зададим соответствие между VLAN и VNI, как будто соединяем их перемычкой или мостом, т.к. второй октет у нас фиксированный(100) будем использовать его как часть VNI + номер VLAN.

Например, зададим соответствие между VLAN 101 и VNI 100101. Трафик из VLAN 101, выходя из VXLAN-интерфейса, будет инкапсулироваться в VNI 100101. И наоборот, когда мы получаем пакет из overlay-сети, мы декапсулируем его из VXLAN и направляем в порты VLAN 101.
На LEAF коммутаторах настройка будет идетичной:

interface Vxlan1
   vxlan source-interface Loopback2
   vxlan udp-port 4789
   vxlan vlan 100 vni 100100
   vxlan vlan 101 vni 100101
   vxlan vlan 102 vni 100102
Что такое VNI?

VNI (Virtual Network Identifier) в контексте технологии VXLAN (Virtual eXtensible Local Area Network) является уникальным идентификатором, который используется для изоляции и идентификации различных арендаторов или сегментов сети в центрах обработки данных. VNI работает аналогично VLAN ID, но имеет гораздо больший диапазон значений, что позволяет поддерживать изоляцию огромного количества арендаторов в одной сети.

При инкапсуляции пакетов в VXLAN каждому пакету назначается VNI, который определяет, к какому арендатору или сегменту сети этот пакет принадлежит. Это позволяет нескольким арендаторам совместно использовать одну физическую сеть, при этом оставаясь изолированными друг от друга на уровне L2.

Почему мы не указывам destination в тунельном интерфейсе vxlan? Или подробнее об Ingress Replication в контексте EVPN.

При настройке VXLAN туннеля обычно не указывается явный адрес назначения на стороне туннельного интерфейса, так как в большинстве случаев используется мультикаст адрес для передачи трафика между конечными точками туннеля. Это связано с тем, что VXLAN предназначен для работы в больших сетях, где требуется передача трафика между множеством узлов без необходимости указания каждого адреса назначения отдельно.

Вместо указания адреса назначения для каждого туннеля, VXLAN использует мультикаст адресацию для передачи трафика между конечными точками. Это позволяет значительно упростить конфигурацию и управление сетью, особенно в больших и сложных средах.

Ingress Replication в контексте EVPN (Ethernet VPN) представляет собой метод распространения BUM-трафика (Broadcast, Unknown Unicast, and Multicast) без необходимости использования мультикаст-маршрутизации в underlay-сети. Этот метод применяется, когда мультикаст-маршрутизация в underlay-сети невозможна или нежелательна.

В методе Ingress Replication каждый LEAF-коммутатор объявляет свою принадлежность к определённому VNI через использование типа маршрута 3 MP-BGP EVPN. Это позволяет другим LEAF-коммутаторам узнать, на какие адреса VTEP необходимо переслать BUM-трафик. Затем каждая копия BUM-трафика

Переходим к настройке EVPN и overlay. По сути повторяем настройку underlay, только на адресах Loopback-ов. Отличие будет в отсутсвии опции next-hop-self, активации address-family EVPN и включению поддержки расширенных сообществ. Также явно указываем update-source.

Эти сообщества нужны для передачи route-target’ов (их настройка будет дальше), которые и являются этими самыми расширенными сообществами.

Если не использовать route-target’ы, то ни один Leaf не сможет добавить информацию о хостах в свой MAC-VRF. Дело в том, что именно по route-target’ам определяется, к какому MAC-VRF должна относиться эта маршрутная информация.
Настройка на SPNE-коммутаторах:

router bgp 65100
neighbor LEAFS-overlay remote-as 65100
neighbor LEAFS-overlay bfd interval 100 min-rx 100 multiplier 3
neighbor LEAFS-overlay route-reflector-client 
neighbor LEAFS-overlay send-community extended 
neighbor LEAFS-overlay update-source loopback 1
neighbor 10.100.3.1 description LEAF1-overlay
neighbor 10.100.3.2 description LEAF2-overlay
neighbor 10.100.3.3 description LEAF3-overlay
neighbor 10.100.3.1 peer group LEAFS-overlay
neighbor 10.100.3.2 peer group LEAFS-overlay
neighbor 10.100.3.3 peer group LEAFS-overlay 
address-family evpn 
neighbor LEAFS-overlay activate
Команда bgp neighbor send-community extended.

Используется для указания, что все стандартные и расширенные сообщества должны быть отправлены между соседями BGP. Это позволяет более точно контролировать распространение маршрутов и политик маршрутизации между устройствами BGP, используя расширенные возможности управления трафиком через сообщества.

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

Также эта команда может быть полезна для обеспечения безопасности сети, позволяя ограничивать распространение определенных маршрутов или политик маршрутизации только между доверенными соседями.

На LEAF-коммутаторах, выполняем аналогичную настрйоку, но с адресами SPINE и используя update-soutce loopback2. Ну и аналогично настройки underlay будет остутсвовать опции route-reflector-client и next-hop-self:
Настройка на LEAF-коммутаторах:

router bgp 65100
neighbor SPINES-overlay remote-as 65100
neighbor SPINES-overlay bfd interval 100 min-rx 100 multiplier 3
neighbor SPINES-overlay send-community extended 
neighbor SPINES-overlay update-source loopback 2
neighbor 10.100.0.1 description SPINE1-overlay
neighbor 10.100.0.2 description SPINE2-overlay
neighbor 10.100.0.1 peer group SPINES-overlay
neighbor 10.100.0.2 peer group SPINES-overlay 
address-family evpn 
neighbor SPINES-overlay activate

На LEAF-коммутатрах у нас добавляется новая настрйока — MAC-VRF, в котрой как раз мы и будем использовать упомянные ранее route-target’ы и route-distinguisher’ы.

RD будем формировать по типу: <последние два октета + незначашие нули Loopback2>:vni. RT по формуле AS:VNI.

Ну и напоследок даем указание распространять в EVPN информацию о всех изученных локально хостах в данном VLAN — redistribute learned.

LEAF1(config)#router bgp 65100
LEAF1(config-router-bgp)#vlan 100
LEAF1(config-macvrf-100)#rd 3001:100100
LEAF1(config-macvrf-100)#route-target both 65100:100100
LEAF1(config-macvrf-100)#redistribute learned 
LEAF1(config-macvrf-100)#exit 

LEAF1(config-router-bgp)#vlan 101
LEAF1(config-macvrf-101)#rd 3001:100101
LEAF1(config-macvrf-101)#route-target both 65100:100101
LEAF1(config-macvrf-101)#redistribute learned 
LEAF1(config-macvrf-101)#exit 

LEAF1(config-router-bgp)#vlan 102 
LEAF1(config-macvrf-102)#rd 3001:100102
LEAF1(config-macvrf-102)#route-target both 65100:100102
LEAF1(config-macvrf-102)#redistribute learned 
LEAF1(config-macvrf-102)#exit
Пояснение для RD (Route Distinguisher).

RD (Route Distinguisher) используется для того, чтобы сделать уникальными маршруты к одному и тому же префиксу, но принадлежащие разным VRF. Это позволяет избежать ситуации, когда BGP выбирает один маршрут как лучший путь (best path) и устанавливает его в FIB, игнорируя остальные.

Для этого мы задаём значение RD, которое делает каждый маршрут уникальным. Форматы для задания RD описаны в RFC 8365, но важно понимать, что BGP не анализирует эту информацию и не пытается понять структуру RD. Для него это просто значение, которое делает маршрут уникальным.

Пояснения для RT (Route Target).

Route target’ы используются для того, чтобы принимающий VTEP (Virtual Tunnel Endpoint) мог определить, в какой VRF(MAC-VRF) следует направить определённую маршрутную информацию.

Политика экспорта из VRF на анонсирующем VTEP должна соответствовать политике импорта в VRF назначения на принимающем VTEP. Например, если VTEP1 анонсирует маршруты для некоторого EVI (Ethernet Virtual Interface) с использованием export RT (Route Target) 1:1, то VTEP2 будет устанавливать эти маршруты именно в тот MAC-VRF, для которого настроена политика import RT 1:1.

Если же на принимающем VTEP не настроен MAC-VRF с соответствующей политикой import RT, то маршрут, анонсированный с использованием указанного RT, не будет установлен на этом VTEP.

Настройка на остальных LEAF-коммутаторах отичаться будет только в значении RD:

LEAF2 

router bgp 65100
   neighbor SPINES send-community extended
   !
   vlan 100
      rd 3002:100100
      route-target both 65100:100100
      redistribute learned
   !
   vlan 101
      rd 3002:100101
      route-target both 65100:100101
      redistribute learned
   !
   vlan 102
      rd 3002:100102
      route-target both 65100:100102
      redistribute learned
Border-Leaf1 

router bgp 65100
   neighbor SPINES send-community extended
   !
   vlan 100
      rd 3003:100100
      route-target both 65100:100100
      redistribute learned
   !
   vlan 101
      rd 3003:100101
      route-target both 65100:100101
      redistribute learned
   !
   vlan 102
      rd 3003:100102
      route-target both 65100:100102
      redistribute learned

Ну в общем то и всё, можем приступить к проверке. На данном этапе клиенты должны иметь связность друг с другом на втором уровне внутри одного VNI (VLAN).

3.4.1 Проверка Overlay сети — VxLAN L2VNI.

Выполним проверку между srv-green-1 и srv-green-2, которые находятся в vlan 101 vni 100101.

SRV-GREEN-1:

administrator@srv-green-1:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 50:1d:51:01:42:00 brd ff:ff:ff:ff:ff:ff
    inet 10.100.101.10/24 brd 10.100.101.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::521d:51ff:fe01:4200/64 scope link 
       valid_lft forever preferred_lft forever


administrator@srv-green-1:~$ ping 10.100.101.20
PING 10.100.101.20 (10.100.101.20) 56(84) bytes of data.
64 bytes from 10.100.101.20: icmp_seq=2 ttl=64 time=5.78 ms
^C
--- 10.100.101.20 ping statistics ---
2 packets transmitted, 1 received, 50% packet loss, time 27ms
rtt min/avg/max/mdev = 5.775/5.775/5.775/0.000 ms

SRV-GREEN-2:

administrator@srv-green-2:~$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 50:b1:ee:01:44:00 brd ff:ff:ff:ff:ff:ff
    inet 10.100.101.20/24 brd 10.100.101.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::52b1:eeff:fe01:4400/64 scope link 
       valid_lft forever preferred_lft forever

administrator@srv-green-2:~$ ping 10.100.101.10
PING 10.100.101.10 (10.100.101.10) 56(84) bytes of data.
64 bytes from 10.100.101.10: icmp_seq=1 ttl=64 time=17.2 ms
^C
--- 10.100.101.10 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 17.191/17.191/17.191/0.000 ms

Теперь посмотрим что мы видим на сетевом оборудовании, сначала проверим на SPINE-коммутаторах, общее состояние BGP:

SPINE1#show bgp summary 
BGP summary information for VRF default
Router identifier 10.100.0.1, local AS number 65100
Neighbor             AS Session State AFI/SAFI                AFI/SAFI State   NLRI Rcd   NLRI Acc
----------- ----------- ------------- ----------------------- -------------- ---------- ----------
10.100.3.1        65100 Established   IPv4 Unicast            Negotiated              2          2
10.100.3.1        65100 Established   L2VPN EVPN              Negotiated              4          4
10.100.3.2        65100 Established   IPv4 Unicast            Negotiated              2          2
10.100.3.2        65100 Established   L2VPN EVPN              Negotiated              3          3
10.100.3.3        65100 Established   IPv4 Unicast            Negotiated              2          2
10.100.3.3        65100 Established   L2VPN EVPN              Negotiated              3          3
192.168.1.1       65100 Established   IPv4 Unicast            Negotiated              2          2
192.168.1.3       65100 Established   IPv4 Unicast            Negotiated              2          2
192.168.1.5       65100 Established   IPv4 Unicast            Negotiated              2          2

Всё ок, с каджым LEAF-коммутатором установилась L2VPN EVPN сессия.

Теперь посмотрим какие маршруты мы получаем по BGP от наших соседей в AFI EVPN:

SPINE1#sh bgp evpn
BGP routing table information for VRF default
Router identifier 10.100.0.1, local AS number 65100
Route status codes: * - valid, > - active, S - Stale, E - ECMP head, e - ECMP
                    c - Contributing to ECMP, % - Pending BGP convergence
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop

          Network                Next Hop              Metric  LocPref Weight  Path
 * >      RD: 3003:100100 mac-ip 502f.be01.4300
                                 10.100.3.3            -       100     0       i
 * >      RD: 3001:100101 mac-ip 501d.5101.4200
                                 10.100.3.1            -       100     0       i
 * >      RD: 3002:100101 mac-ip 50b1.ee01.4400
                                 10.100.3.2            -       100     0       i
 * >      RD: 3001:100102 mac-ip 509d.7c01.4500
                                 10.100.3.1            -       100     0       i
 * >      RD: 3002:100102 mac-ip 50b6.0501.4600
                                 10.100.3.2            -       100     0       i
 * >      RD: 3001:100100 imet 10.100.3.1
                                 10.100.3.1            -       100     0       i
 * >      RD: 3001:100101 imet 10.100.3.1
                                 10.100.3.1            -       100     0       i
 * >      RD: 3001:100102 imet 10.100.3.1
                                 10.100.3.1            -       100     0       i
 * >      RD: 3002:100100 imet 10.100.3.2
                                 10.100.3.2            -       100     0       i
 * >      RD: 3002:100101 imet 10.100.3.2
                                 10.100.3.2            -       100     0       i
 * >      RD: 3002:100102 imet 10.100.3.2
                                 10.100.3.2            -       100     0       i
 * >      RD: 3003:100100 imet 10.100.3.3
                                 10.100.3.3            -       100     0       i
 * >      RD: 3003:100101 imet 10.100.3.3
                                 10.100.3.3            -       100     0       i
 * >      RD: 3003:100102 imet 10.100.3.3
                                 10.100.3.3            -       100     0       i

Мы видим следующее:

  1. От каждого Leaf мы получаем по 3 маршрута с типом RT-3, который называется IMET. Этот маршрут создаётся для каждого отдельного VNI и служит сигналом для других участников EVPN-фабрики о том, что данный VTEP хочет получать BUM-трафик для конкретного VNI, который указан в маршруте IMET.
  2. Также мы наблюдаем пять маршрутов с типом RT-2 называемых MAC/IP, которые используются для объявления информации о доступности хостов в overlay-сети. MAC-адреса в этих маршрутах представляют собой адреса наших клиентов.

Проверка с LEAF-коммутатора.

Общая информация о BGP:

LEAF1# sh bgp summary 
BGP summary information for VRF default
Router identifier 10.100.1.1, local AS number 65100
Neighbor             AS Session State AFI/SAFI                AFI/SAFI State   NLRI Rcd   NLRI Acc
----------- ----------- ------------- ----------------------- -------------- ---------- ----------
10.100.0.1        65100 Established   IPv4 Unicast            Negotiated              5          5
10.100.0.1        65100 Established   L2VPN EVPN              Negotiated              8          8
10.100.0.2        65100 Established   IPv4 Unicast            Negotiated              5          5
10.100.0.2        65100 Established   L2VPN EVPN              Negotiated              8          8
192.168.1.0       65100 Established   IPv4 Unicast            Negotiated              5          5
192.168.2.0       65100 Established   IPv4 Unicast            Negotiated              5          5

Маршруты AFI EVPN:

LEAF1#sh bgp evpn
BGP routing table information for VRF default
Router identifier 10.100.1.1, local AS number 65100
Route status codes: * - valid, > - active, S - Stale, E - ECMP head, e - ECMP
                    c - Contributing to ECMP, % - Pending BGP convergence
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop

          Network                Next Hop              Metric  LocPref Weight  Path
 * >      RD: 3001:100101 mac-ip 501d.5101.4200
                                 -                     -       -       0       i
 * >Ec    RD: 3003:100100 mac-ip 502f.be01.4300
                                 10.100.3.3            -       100     0       i Or-ID: 10.100.1.3 C-LST: 10.100.0.2 
 *  ec    RD: 3003:100100 mac-ip 502f.be01.4300
                                 10.100.3.3            -       100     0       i Or-ID: 10.100.1.3 C-LST: 10.100.0.1 
 * >      RD: 3001:100102 mac-ip 509d.7c01.4500
                                 -                     -       -       0       i
 * >Ec    RD: 3002:100101 mac-ip 50b1.ee01.4400
                                 10.100.3.2            -       100     0       i Or-ID: 10.100.1.2 C-LST: 10.100.0.2 
 *  ec    RD: 3002:100101 mac-ip 50b1.ee01.4400
                                 10.100.3.2            -       100     0       i Or-ID: 10.100.1.2 C-LST: 10.100.0.1 
 * >Ec    RD: 3002:100102 mac-ip 50b6.0501.4600
                                 10.100.3.2            -       100     0       i Or-ID: 10.100.1.2 C-LST: 10.100.0.1 
 *  ec    RD: 3002:100102 mac-ip 50b6.0501.4600
                                 10.100.3.2            -       100     0       i Or-ID: 10.100.1.2 C-LST: 10.100.0.2 
 * >      RD: 3001:100100 imet 10.100.3.1
                                 -                     -       -       0       i
 * >      RD: 3001:100101 imet 10.100.3.1
                                 -                     -       -       0       i
 * >      RD: 3001:100102 imet 10.100.3.1
                                 -                     -       -       0       i
 * >Ec    RD: 3002:100100 imet 10.100.3.2
                                 10.100.3.2            -       100     0       i Or-ID: 10.100.1.2 C-LST: 10.100.0.1 
 *  ec    RD: 3002:100100 imet 10.100.3.2
                                 10.100.3.2            -       100     0       i Or-ID: 10.100.1.2 C-LST: 10.100.0.2 
 * >Ec    RD: 3002:100101 imet 10.100.3.2
                                 10.100.3.2            -       100     0       i Or-ID: 10.100.1.2 C-LST: 10.100.0.1 
 *  ec    RD: 3002:100101 imet 10.100.3.2
                                 10.100.3.2            -       100     0       i Or-ID: 10.100.1.2 C-LST: 10.100.0.2 
 * >Ec    RD: 3002:100102 imet 10.100.3.2
                                 10.100.3.2            -       100     0       i Or-ID: 10.100.1.2 C-LST: 10.100.0.1 
 *  ec    RD: 3002:100102 imet 10.100.3.2
                                 10.100.3.2            -       100     0       i Or-ID: 10.100.1.2 C-LST: 10.100.0.2 
 * >Ec    RD: 3003:100100 imet 10.100.3.3
                                 10.100.3.3            -       100     0       i Or-ID: 10.100.1.3 C-LST: 10.100.0.2 
 *  ec    RD: 3003:100100 imet 10.100.3.3
                                 10.100.3.3            -       100     0       i Or-ID: 10.100.1.3 C-LST: 10.100.0.1 
 * >Ec    RD: 3003:100101 imet 10.100.3.3
                                 10.100.3.3            -       100     0       i Or-ID: 10.100.1.3 C-LST: 10.100.0.2 
 *  ec    RD: 3003:100101 imet 10.100.3.3
                                 10.100.3.3            -       100     0       i Or-ID: 10.100.1.3 C-LST: 10.100.0.1 
 * >Ec    RD: 3003:100102 imet 10.100.3.3
                                 10.100.3.3            -       100     0       i Or-ID: 10.100.1.3 C-LST: 10.100.0.2 
 *  ec    RD: 3003:100102 imet 10.100.3.3
                                 10.100.3.3            -       100     0       i Or-ID: 10.100.1.3 C-LST: 10.100.0.1

Тут уже будет в 2 раза больше записей в отличии от проверки на SPINE. LEAF получает одинаковые маршруты от двух SPINE-коммутаторов по iBGP, и т.к. мы используем ECMP мы будем балансировать трафик.

Проверим EVPN instance.

LEAF1#         sh bgp evpn instance 
EVPN instance: VLAN 100
  Route distinguisher: 3001:100100
  Route target import: Route-Target-AS:65100:100100
  Route target export: Route-Target-AS:65100:100100
  Service interface: VLAN-based
  Local VXLAN IP address: 10.100.3.1
  VXLAN: enabled
  MPLS: disabled
EVPN instance: VLAN 101
  Route distinguisher: 3001:100101
  Route target import: Route-Target-AS:65100:100101
  Route target export: Route-Target-AS:65100:100101
  Service interface: VLAN-based
  Local VXLAN IP address: 10.100.3.1
  VXLAN: enabled
  MPLS: disabled
EVPN instance: VLAN 102
  Route distinguisher: 3001:100102
  Route target import: Route-Target-AS:65100:100102
  Route target export: Route-Target-AS:65100:100102
  Service interface: VLAN-based
  Local VXLAN IP address: 10.100.3.1
  VXLAN: enabled
  MPLS: disabled

Тут мы видим важный пункт Local VXLAN IP address — это наш source адрес VXLAN-тунеля. Также указана модель сервиса: VLAN-Based.

Что такое VLAN-Based и какие есть ещё модели сервиса?

Модель сервиса VLAN-Based, описанная в RFC 7432, позволяет реализовать один-к-одному маппинг между VLAN и EVPN инстансами (EVI), создавая отдельную таблицу MAC-VRF для каждого VLAN. Это означает, что каждый VLAN будет иметь свой уникальный Route Distinguisher (RD) и Route Target (RT), что обеспечивает четкое разделение между различными VLAN доменами.

Преимущества этой модели включают простую и наглядную конфигурацию, где каждый VLAN сопоставляется с отдельным EVI и таблицей MAC-VRF. Это обеспечивает чёткое разделение между VLAN и упрощает управление. Однако, недостатком является увеличение нагрузки на плоскость управления из-за большого количества отдельных EVI. Также требуется ручная настройка Route Targets для каждого L2-домена, что может вызвать сложности при большом количестве VLAN.

Модель сервиса VLAN-Aware Bundle, описанная в RFC 7432, позволяет нескольким VLAN’ам быть маппированными на один EVPN инстанс (EVI), разделяя их внутри MAC-VRF с помощью подтаблиц. Это означает, что вместо создания отдельного EVI для каждого VLAN, несколько VLAN’ов могут быть объединены в одном EVI, что упрощает управление и уменьшает нагрузку на плоскость управления.

В этой модели, для идентификации конкретного L2-домена в маршрутах EVPN используется поле Ethernet Tag ID, в которое подставляется номер VNI. Это позволяет VTEP’ам принимать маршруты только для тех VLAN’ов, которые им действительно нужны, основываясь на значении Ethernet Tag ID.

Настройка не совсем наглядная и может потребовать дополнительной настройки фильтрации, но уменьшается нагрузка на плоскость управления.

Проверка VNI мапинга к VLAN и интерфейсам:

LEAF1#sho vxlan vni 
VNI to VLAN Mapping for Vxlan1
VNI          VLAN       Source       Interface       802.1Q Tag
------------ ---------- ------------ --------------- ----------
100100       100        static       Vxlan1          100       
100101       101        static       Ethernet3       untagged  
                                     Vxlan1          101       
100102       102        static       Ethernet4       untagged  
                                     Vxlan1          102       

VNI to dynamic VLAN Mapping for Vxlan1
VNI       VLAN       VRF       Source       
--------- ---------- --------- ------------

Проверка списка удалённых VTEP и типы тунеля:

LEAF1#show vxlan vtep 
Remote VTEPS for Vxlan1:

VTEP             Tunnel Type(s)
---------------- --------------
10.100.3.2       flood, unicast
10.100.3.3       flood, unicast

Total number of remote VTEPS:  2

Также можем посмотреть L2RIB:

LEAF1#show l2rib input all 
501d.5101.4200, VLAN 101, seq 1, pref 16, learnedDynamicMac, source: Local Dynamic
   Ethernet3
509d.7c01.4500, VLAN 102, seq 1, pref 16, learnedDynamicMac, source: Local Dynamic
   Ethernet4
50b1.ee01.4400, VLAN 101, seq 1, pref 16, evpnDynamicRemoteMac, source: BGP
   VTEP 10.100.3.2
50b6.0501.4600, VLAN 102, seq 1, pref 16, evpnDynamicRemoteMac, source: BGP
   VTEP 10.100.3.2
502f.be01.4300, VLAN 100, seq 1, pref 16, evpnDynamicRemoteMac, source: BGP
   VTEP 10.100.3.3

LEAF1 знает за каким VTEP-ом находится тот или иной mac-address.

Отлично! Нам удалось настроить L2VNI и добиться L2-связности с помощью EVPN.

Конфигурации обордования:

SPINE1 

SPINE1#sh run
! Command: show running-config
! device: SPINE1 (vEOS-lab, EOS-4.29.2F)
!
! boot system flash:/vEOS-lab.swi
!
no aaa root
!
transceiver qsfp default-mode 4x10G
!
service routing protocols model multi-agent
!
hostname SPINE1
!
spanning-tree mode mstp
!
interface Ethernet1
   description -=LEAF1;eth1=-
   mtu 9000
   no switchport
   ip address 192.168.1.0/31
!
interface Ethernet2
   description -=LEAF2;eth2=-
   mtu 9000
   no switchport
   ip address 192.168.1.2/31
!
interface Ethernet3
   description -=LEAF3;eth3=-
   mtu 9000
   no switchport
   ip address 192.168.1.4/31
!
interface Ethernet4
!
interface Ethernet5
!
interface Ethernet6
!
interface Ethernet7
!
interface Ethernet8
!
interface Loopback1
   description Router-ID
   ip address 10.100.0.1/32
!
interface Management1
!
ip routing
!
route-map rm_redistribute_lo permit 10
   match interface Loopback1
   set origin igp
!
route-map rm_redistribute_lo deny 40
!
router bgp 65100
   router-id 10.100.0.1
   timers bgp 3 9
   maximum-paths 10 ecmp 10
   neighbor LEAFS peer group
   neighbor LEAFS remote-as 65100
   neighbor LEAFS next-hop-self
   neighbor LEAFS bfd
   neighbor LEAFS bfd interval 100 min-rx 100 multiplier 3
   neighbor LEAFS route-reflector-client
   neighbor LEAFS-overlay peer group
   neighbor LEAFS-overlay remote-as 65100
   neighbor LEAFS-overlay update-source Loopback1
   neighbor LEAFS-overlay bfd interval 100 min-rx 100 multiplier 3
   neighbor LEAFS-overlay route-reflector-client
   neighbor LEAFS-overlay send-community extended
   neighbor 10.100.3.1 peer group LEAFS-overlay
   neighbor 10.100.3.1 description LEAF1-overlay
   neighbor 10.100.3.2 peer group LEAFS-overlay
   neighbor 10.100.3.2 description LEAF2-overlay
   neighbor 10.100.3.3 peer group LEAFS-overlay
   neighbor 10.100.3.3 description LEAF3-overlay
   neighbor 192.168.1.1 peer group LEAFS
   neighbor 192.168.1.1 description LEAF1
   neighbor 192.168.1.3 peer group LEAFS
   neighbor 192.168.1.3 description LEAF2
   neighbor 192.168.1.5 peer group LEAFS
   neighbor 192.168.1.5 description LEAF3
   redistribute connected route-map rm_redistribute_lo
   !
   address-family evpn
      neighbor LEAFS-overlay activate
   !
   address-family ipv4
      neighbor LEAFS activate
!
end
SPINE1#
SPINE2 

SPINE2#sh run
! Command: show running-config
! device: SPINE2 (vEOS-lab, EOS-4.29.2F)
!
! boot system flash:/vEOS-lab.swi
!
no aaa root
!
transceiver qsfp default-mode 4x10G
!
service routing protocols model multi-agent
!
hostname SPINE2
!
spanning-tree mode mstp
!
interface Ethernet1
   description -=LEAF1;eth2=-
   mtu 9000
   no switchport
   ip address 192.168.2.0/31
!
interface Ethernet2
   description -=LEAF2;eth2=-
   mtu 9000
   no switchport
   ip address 192.168.2.2/31
!
interface Ethernet3
   description -=LEAF3;eth2=-
   mtu 9000
   no switchport
   ip address 192.168.2.4/31
!
interface Ethernet4
!
interface Ethernet5
!
interface Ethernet6
!
interface Ethernet7
!
interface Ethernet8
!
interface Loopback1
   description Router-ID
   ip address 10.100.0.2/32
!
interface Management1
!
ip routing
!
route-map rm_redistribute_lo permit 10
   match interface Loopback1
   set origin igp
!
route-map rm_redistribute_lo deny 40
!
router bgp 65100
   router-id 10.100.0.2
   timers bgp 3 9
   maximum-paths 10 ecmp 10
   neighbor LEAFS peer group
   neighbor LEAFS remote-as 65100
   neighbor LEAFS next-hop-self
   neighbor LEAFS bfd
   neighbor LEAFS bfd interval 100 min-rx 100 multiplier 3
   neighbor LEAFS route-reflector-client
   neighbor LEAFS-overlay peer group
   neighbor LEAFS-overlay remote-as 65100
   neighbor LEAFS-overlay update-source Loopback1
   neighbor LEAFS-overlay bfd interval 100 min-rx 100 multiplier 3
   neighbor LEAFS-overlay route-reflector-client
   neighbor LEAFS-overlay send-community extended
   neighbor 10.100.3.1 peer group LEAFS-overlay
   neighbor 10.100.3.1 description LEAF1-overlay
   neighbor 10.100.3.2 peer group LEAFS-overlay
   neighbor 10.100.3.2 description LEAF2-overlay
   neighbor 10.100.3.3 peer group LEAFS-overlay
   neighbor 10.100.3.3 description LEAF3-overlay
   neighbor 192.168.2.1 peer group LEAFS
   neighbor 192.168.2.1 description LEAF1
   neighbor 192.168.2.3 peer group LEAFS
   neighbor 192.168.2.3 description LEAF2
   neighbor 192.168.2.5 peer group LEAFS
   neighbor 192.168.2.5 description LEAF3
   redistribute connected route-map rm_redistribute_lo
   !
   address-family evpn
      neighbor LEAFS-overlay activate
   !
   address-family ipv4
      neighbor LEAFS activate
!
end
LEAF1 

LEAF1#sh run
! Command: show running-config
! device: LEAF1 (vEOS-lab, EOS-4.29.2F)
!
! boot system flash:/vEOS-lab.swi
!
no aaa root
!
transceiver qsfp default-mode 4x10G
!
service routing protocols model multi-agent
!
hostname LEAF1
!
spanning-tree mode mstp
!
vlan 100
   name admins
!
vlan 101
   name green-srv
!
vlan 102
   name yellow-srv
!
interface Ethernet1
   description -=SPINE1;eth1=-
   mtu 9000
   no switchport
   ip address 192.168.1.1/31
!
interface Ethernet2
   description -=SPINE2;eth1=-
   mtu 9000
   no switchport
   ip address 192.168.2.1/31
!
interface Ethernet3
   description -=SRV-GREEN-1;eth0=-
   switchport access vlan 101
!
interface Ethernet4
   description -=SRV-YELLOW-1;eth0=-
   switchport access vlan 102
!
interface Ethernet5
!
interface Ethernet6
!
interface Ethernet7
!
interface Ethernet8
!
interface Loopback1
   description Router-ID
   ip address 10.100.1.1/32
!
interface Loopback2
   description VTEP source
   ip address 10.100.3.1/32
!
interface Management1
!
interface Vxlan1
   vxlan source-interface Loopback2
   vxlan udp-port 4789
   vxlan vlan 100 vni 100100
   vxlan vlan 101 vni 100101
   vxlan vlan 102 vni 100102
   vxlan learn-restrict any
!
ip routing
!
route-map rm_redistribute_lo permit 10
   match interface Loopback1
   set origin igp
!
route-map rm_redistribute_lo permit 20
   match interface Loopback2
   set origin igp
!
route-map rm_redistribute_lo deny 40
!
router bgp 65100
   router-id 10.100.1.1
   timers bgp 3 9
   maximum-paths 10 ecmp 10
   neighbor SPINES peer group
   neighbor SPINES remote-as 65100
   neighbor SPINES bfd
   neighbor SPINES bfd interval 100 min-rx 100 multiplier 3
   neighbor SPINES-overlay peer group
   neighbor SPINES-overlay remote-as 65100
   neighbor SPINES-overlay update-source Loopback2
   neighbor SPINES-overlay bfd interval 100 min-rx 100 multiplier 3
   neighbor SPINES-overlay send-community extended
   neighbor 10.100.0.1 peer group SPINES-overlay
   neighbor 10.100.0.1 description SPINE1-overlay
   neighbor 10.100.0.2 peer group SPINES-overlay
   neighbor 10.100.0.2 description SPINE2-overlay
   neighbor 192.168.1.0 peer group SPINES
   neighbor 192.168.1.0 description SPINE1
   neighbor 192.168.2.0 peer group SPINES
   neighbor 192.168.2.0 description SPINE2
   redistribute connected route-map rm_redistribute_lo
   !
   vlan 100
      rd 3001:100100
      route-target both 65100:100100
      redistribute learned
   !
   vlan 101
      rd 3001:100101
      route-target both 65100:100101
      redistribute learned
   !
   vlan 102
      rd 3001:100102
      route-target both 65100:100102
      redistribute learned
   !
   address-family evpn
      neighbor SPINES-overlay activate
   !
   address-family ipv4
      neighbor SPINES activate
!
end
LEAF2 

LEAF2#sh run
! Command: show running-config
! device: LEAF2 (vEOS-lab, EOS-4.29.2F)
!
! boot system flash:/vEOS-lab.swi
!
no aaa root
!
transceiver qsfp default-mode 4x10G
!
service routing protocols model multi-agent
!
hostname LEAF2
!
spanning-tree mode mstp
!
vlan 100
   name admins
!
vlan 101
   name green-srv
!
vlan 102
   name yellow-srv
!
interface Ethernet1
   description -=SPINE1;eth2=-
   mtu 9000
   no switchport
   ip address 192.168.1.3/31
!
interface Ethernet2
   mtu 9000
   no switchport
   ip address 192.168.2.3/31
!
interface Ethernet3
   description -=SRV-GREEN-2;eth0=-
   switchport access vlan 101
!
interface Ethernet4
   description -=SRV-YELLOW-2;eth0=-
   switchport access vlan 102
!
interface Ethernet5
!
interface Ethernet6
!
interface Ethernet7
!
interface Ethernet8
!
interface Loopback1
   description Router-ID
   ip address 10.100.1.2/32
!
interface Loopback2
   description VTEP source
   ip address 10.100.3.2/32
!
interface Management1
!
interface Vxlan1
   vxlan source-interface Loopback2
   vxlan udp-port 4789
   vxlan vlan 100 vni 100100
   vxlan vlan 101 vni 100101
   vxlan vlan 102 vni 100102
   vxlan learn-restrict any
!
ip routing
!
route-map rm_redistribute_lo permit 10
   match interface Loopback1
   set origin igp
!
route-map rm_redistribute_lo permit 20
   match interface Loopback2
   set origin igp
!
route-map rm_redistribute_lo deny 40
!
router bgp 65100
   router-id 10.100.1.2
   timers bgp 3 9
   maximum-paths 10 ecmp 10
   neighbor SPINES peer group
   neighbor SPINES remote-as 65100
   neighbor SPINES bfd
   neighbor SPINES bfd interval 100 min-rx 100 multiplier 3
   neighbor SPINES-overlay peer group
   neighbor SPINES-overlay remote-as 65100
   neighbor SPINES-overlay update-source Loopback2
   neighbor SPINES-overlay bfd interval 100 min-rx 100 multiplier 3
   neighbor SPINES-overlay send-community extended
   neighbor 10.100.0.1 peer group SPINES-overlay
   neighbor 10.100.0.1 description SPINE1-overlay
   neighbor 10.100.0.2 peer group SPINES-overlay
   neighbor 10.100.0.2 description SPINE2-overlay
   neighbor 192.168.1.2 peer group SPINES
   neighbor 192.168.1.2 description SPINE1
   neighbor 192.168.2.2 peer group SPINES
   neighbor 192.168.2.2 description SPINE2
   redistribute connected route-map rm_redistribute_lo
   !
   vlan 100
      rd 3002:100100
      route-target both 65100:100100
      redistribute learned
   !
   vlan 101
      rd 3002:100101
      route-target both 65100:100101
      redistribute learned
   !
   vlan 102
      rd 3002:100102
      route-target both 65100:100102
      redistribute learned
   !
   address-family evpn
      neighbor SPINES-overlay activate
   !
   address-family ipv4
      neighbor SPINES activate
!
end
Border-Leaf1 

Boreder-LEAF1#sh run
! Command: show running-config
! device: Boreder-LEAF1 (vEOS-lab, EOS-4.29.2F)
!
! boot system flash:/vEOS-lab.swi
!
no aaa root
!
transceiver qsfp default-mode 4x10G
!
service routing protocols model multi-agent
!
hostname Boreder-LEAF1
!
spanning-tree mode mstp
!
vlan 100
   name admins
!
vlan 101
   name green-srv
!
vlan 102
   name yellow-srv
!
interface Ethernet1
   description -=SPINE1;eth3=-
   mtu 9000
   no switchport
   ip address 192.168.1.5/31
!
interface Ethernet2
   description -=SPINE2;eth3=-
   mtu 9000
   no switchport
   ip address 192.168.2.5/31
!
interface Ethernet3
!
interface Ethernet4
   description -=Admin;eth0=-
   switchport access vlan 100
!
interface Ethernet5
!
interface Ethernet6
!
interface Ethernet7
!
interface Ethernet8
!
interface Loopback1
   description Router-ID
   ip address 10.100.1.3/32
!
interface Loopback2
   description VTEP-Source
   ip address 10.100.3.3/32
!
interface Management1
!
interface Vlan102
!
interface Vxlan1
   vxlan source-interface Loopback2
   vxlan udp-port 4789
   vxlan vlan 100 vni 100100
   vxlan vlan 101 vni 100101
   vxlan vlan 102 vni 100102
!
ip routing
!
route-map rm_redistribute_lo permit 10
   match interface Loopback1
   set origin igp
!
route-map rm_redistribute_lo permit 20
   match interface Loopback2
   set origin igp
!
route-map rm_redistribute_lo deny 40
!
router bgp 65100
   router-id 10.100.1.3
   timers bgp 3 9
   maximum-paths 10 ecmp 10
   neighbor SPINES peer group
   neighbor SPINES remote-as 65100
   neighbor SPINES bfd
   neighbor SPINES bfd interval 100 min-rx 100 multiplier 3
   neighbor SPINES-overlay peer group
   neighbor SPINES-overlay remote-as 65100
   neighbor SPINES-overlay update-source Loopback2
   neighbor SPINES-overlay bfd interval 100 min-rx 100 multiplier 3
   neighbor SPINES-overlay send-community extended
   neighbor 10.100.0.1 peer group SPINES-overlay
   neighbor 10.100.0.1 description SPINE1-overlay
   neighbor 10.100.0.2 peer group SPINES-overlay
   neighbor 10.100.0.2 description SPINE2-overlay
   neighbor 192.168.1.4 peer group SPINES
   neighbor 192.168.1.4 description SPINE1
   neighbor 192.168.2.4 peer group SPINES
   neighbor 192.168.2.4 description SPINE2
   redistribute connected route-map rm_redistribute_lo
   !
   vlan 100
      rd 3003:100100
      route-target both 65100:100100
      redistribute learned
   !
   vlan 101
      rd 3003:100101
      route-target both 65100:100101
      redistribute learned
   !
   vlan 102
      rd 3003:100102
      route-target both 65100:100102
      redistribute learned
   !
   address-family evpn
      neighbor SPINES-overlay activate
   !
   address-family ipv4
      neighbor SPINES activate
!
end

3.5 VxLAN L3VNI.

Связность на L2 конечно хорошо, но что если нам требуется с клентами в других VNI и мы не хотим использовать для этого дополнительный маршрутизатор?

EVPN функциональность маршрутизации носит название «Integrated Routing and Bridging» и описана в RFC 9135. Интерфейсы внутри VNI, с помощью которых мы можем выйти за пределы VNI (шлюзы по умолчанию) в EVPN называются IRB-интерфейсами.

Существует 2 вида IRB — симетричный и асиметричный.

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

В асиметричной модели мы настраиваем на LEAF-коммутаторах абсолбтно все VNI, даже если за конкретным LEAF’ом у нас нет клиентов в этом VNI.

Маршрутизация между в VNI происходит на первом хопе — на ingress VTEP. Именно поэтому необходимо настроить все VNI на каждом LEAF.

После того как пакет перемещается из родительской VNI в целевую VNI, он направляется к выходному VTEP, который находится уже в нужной VNI. Выходной VTEP выполняет коммутацию между VNI и локальным VLAN.

Минус такого подхода заключается в том, что на каждом VTEP нужно настраивать все VNI. Кроме того, каждому VTEP придётся хранить информацию обо всех L2-адресах в фабрике, что может стать проблемой при ограниченном объёме аппаратной памяти.

Симетричная модель IRB.

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

Плюсы данной модели особенно раскрываются когда в фабрике не 10-20 VNI, а например тысячи VNI между которыми нужно гонять трафик. Упрощение в управлениии и экономия ресурсов.

Мы остановимся на симетричной модели и будем настраивать L3VNI. В качесвте шлюзов по умолчанию будем использовать статические anycast-шлюзы (SAG) по схеме Distributed Gateway (распределённый шлюз) — что означает что на каждом LEAF-коммутаторе для каждого VNI будет настроен SVI-интерфейс и назначен одинаковый IP-адрес, который будет служить адресом шлюза по умолчанию для локально подключенных клиентов.

Перед настройкой нужно определиться с значениями для VRF-ов.
RT и RD будут формироваться по аналогии с настройкой для L2VNI:
RT: <номер автономной системы>:<L3VNI>
RD: <последние два октета + незначашие нули loopback2>:<L3VNI>
Идентификатор L3VNI выберем произвольно, пусть это будут 1, 10 и 20.

VRFИдентификатор L3VNIПараметр RT export/importПараметр RD
admin165100:1<последние два октета + незначашие нули loopback2>:1
green1065100:10<последние два октета + незначашие нули loopback2>:10
yellow2065100:20<последние два октета + незначашие нули loopback2>:20

Для начала создадим на LEAF два VRF и включим на них routing:

vrf instance green
ip routing vrf green

vrf instance yellow
ip routing vrf yellow

vrf instance admin
ip routing vrf admin

Настроим виртуальный shared mac-address для SAG на всех LEAF-ах:

ip virtual-router mac-address 00:50:10:00:10:00

Создаём и добавляем L3VNI и VRF в VXLAN-тунель:

int vxlan 1
vxlan vrf admin vni 1
vxlan vrf green vni 10
vxlan vrf yellow vni 20

Создаём SVI интерфейсы с SAG sahred виртуальным адрессом:

int vlan 101
vrf green
p address virtual 10.100.101.1/24

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

router bgp 65100
vrf green
rd 3001:10
route-target export evpn 65100:10
route-target import evpn 65100:10

После этого на всех LEAF-роутерах мы можем увидеть одинаковый ip-адрес SVI интерфейса:

Boreder-LEAF1#sh ip int br                                                                  Address
Interface       IP Address          Status     Protocol          MTU    Owner  
--------------- ------------------- ---------- ------------- ---------- -------
Ethernet1       192.168.1.5/31      up         up               9000           
Ethernet2       192.168.2.5/31      up         up               9000           
Loopback1       10.100.1.3/32       up         up              65535           
Loopback2       10.100.3.3/32       up         up              65535           
Management1     unassigned          down       down             1500           
Vlan100         10.100.100.1/24     up         up               1500           
Vlan101         10.100.101.1/24     up         up               1500           
Vlan102         10.100.102.1/24     up         up               1500           
Vlan4092        unassigned          up         up               9164           
Vlan4093        unassigned          up         up               9164           
Vlan4094        unassigned          up         up               9164

Проверим что мы получаем по BGP EVPN в route-type mac-ip:

Boreder-LEAF1# show bgp evpn route-type mac-ip | include * >
Route status codes: * - valid, > - active, S - Stale, E - ECMP head, e - ECMP
 * >Ec    RD: 3001:100101 mac-ip 501d.5101.4200
 * >Ec    RD: 3001:100101 mac-ip 501d.5101.4200 10.100.101.10
 * >      RD: 3003:100100 mac-ip 502f.be01.4300
 * >      RD: 3003:100100 mac-ip 502f.be01.4300 10.100.100.30
 * >Ec    RD: 3001:100102 mac-ip 509d.7c01.4500
 * >Ec    RD: 3001:100102 mac-ip 509d.7c01.4500 10.100.102.10
 * >Ec    RD: 3002:100101 mac-ip 50b1.ee01.4400
 * >Ec    RD: 3002:100101 mac-ip 50b1.ee01.4400 10.100.101.20
 * >Ec    RD: 3002:100102 mac-ip 50b6.0501.4600
 * >Ec    RD: 3002:100102 mac-ip 50b6.0501.4600 10.100.102.20

Теперь мы получаем не только mac-адреса клиентов, но и их IP-адреса! Видим по одному маршруту MAC-only и по одному маршруту MAC/IP для каждого клиента. Рассмотрим более делатьно:

Boreder-LEAF1#show bgp evpn route-type mac-ip detail

BGP routing table entry for mac-ip 50b6.0501.4600 10.100.102.20, Route Distinguisher: 3002:100102
 Paths: 2 available
  Local
    10.100.3.2 from 10.100.0.1 (10.100.0.1)
      Origin IGP, metric -, localpref 100, weight 0, tag 0, valid, internal, ECMP head, ECMP, best, ECMP contributor
      Originator: 10.100.1.2, Cluster list: 10.100.0.1 
      Extended Community: Route-Target-AS:65100:20 Route-Target-AS:65100:100102 TunnelEncap:tunnelTypeVxlan EvpnRouterMac:50:62:2c:a8:72:a6
      VNI: 100102 L3 VNI: 20 ESI: 0000:0000:0000:0000:0000
  Local
    10.100.3.2 from 10.100.0.2 (10.100.0.2)
      Origin IGP, metric -, localpref 100, weight 0, tag 0, valid, internal, ECMP, ECMP contributor
      Originator: 10.100.1.2, Cluster list: 10.100.0.2 
      Extended Community: Route-Target-AS:65100:20 Route-Target-AS:65100:100102 TunnelEncap:tunnelTypeVxlan EvpnRouterMac:50:62:2c:a8:72:a6
      VNI: 100102 L3 VNI: 20 ESI: 0000:0000:0000:0000:0000

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

Также можем заметить появляется комьюнити Router’s MAC: EvpnRouterMac в mac-ip маршрутах. В нём указан адрес VTEP, который является next-hop’ом для данного маршрута. Он нужен для того, чтобы выходной (ingress) удалённый VTEP установил данный mac-адресс как DST_MAC во внутреннем инкапсулированном кадре VXLAN. Таким обром когда входной (egress) VTEP получит этот кадр, то увидит что DST_MAC является его локальным mac-адрессом и поднимет его на L3 для маршрутизации. Если бы внутренний кадр VXLAN не содержал локальный MAC-адрес в поле DST_MAC, наш VTEP отправил бы его в свои порты согласно стандартной политике пересылки на втором уровне, и маршрутизация не произошла бы. Для этого и нужен атрибут Router’s MAC, который обязательно присутствует в маршрутах с L3VNI.

Маршруты mac-ip будут установлены в таблтцу маршрутизации VRF-а: 

Boreder-LEAF1# sh ip route vrf green

 B I      10.100.101.10/32 [200/0] via VTEP 10.100.3.1 VNI 10 router-mac 50:e8:5d:18:3c:6b local-interface Vxlan1
 B I      10.100.101.20/32 [200/0] via VTEP 10.100.3.2 VNI 10 router-mac 50:62:2c:a8:72:a6 local-interface Vxlan1
 C        10.100.101.0/24 is directly connected, Vlan101

Теперь для проверки работы маршрутизации внутри VRF создадим новый VLAN в VRF green:

Настроим SAG и VLAN на LEAF2 и Border LEAF1:

vlan 200
name green-test

interface vxlan1
vxlan vlan 200 vni 100200


interface Vlan200
   description green-test
   vrf green
   ip address virtual 10.100.200.1/24


router bgp 65100
vlan 200
      rd 3001:100200
      route-target both 65100:100200
      redistribute learned

Проверяем пингами внутри VRF c vlan 101 нового клиента в vlan 200: 

root@srv-green2:~# ip -br a
lo               UNKNOWN        127.0.0.1/8 ::1/128 
eth0             UP             10.100.101.20/24 fe80::52b1:eeff:fe01:4400/64 

root@srv-green2:~# ping 10.100.200.10
PING 10.100.200.10 (10.100.200.10) 56(84) bytes of data.
64 bytes from 10.100.200.10: icmp_seq=1 ttl=62 time=12.2 ms
64 bytes from 10.100.200.10: icmp_seq=2 ttl=62 time=11.7 ms
64 bytes from 10.100.200.10: icmp_seq=3 ttl=62 time=7.04 ms
--- 10.100.200.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 5ms
rtt min/avg/max/mdev = 7.039/10.309/12.153/2.318 ms

Ну и логично, что в других VRF данный хост не доступен:

root@srv-yellow-2:~# ip -br a
lo               UNKNOWN        127.0.0.1/8 ::1/128 
eth0             UP             10.100.102.20/24 fe80::52b6:5ff:fe01:4600/64 

root@srv-yellow-2:~# ping 10.100.200.20
PING 10.100.200.20 (10.100.200.20) 56(84) bytes of data.
From 10.100.102.1 icmp_seq=1 Destination Net Unreachable

--- 10.100.200.20 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

Проверим, что маршрут до хоста появился в таблице маршршутизаци: 

LEAF2#sh ip route vrf green

 B I      10.100.101.10/32 [200/0] via VTEP 10.100.3.1 VNI 10 router-mac 50:e8:5d:18:3c:6b local-interface Vxlan1
 C        10.100.101.0/24 is directly connected, Vlan101
 B I      10.100.200.10/32 [200/0] via VTEP 10.100.3.3 VNI 10 router-mac 50:53:4f:42:99:52 local-interface Vxlan1
 C        10.100.200.0/24 is directly connected, Vlan200

Теперь снимем дамп на Ethernet 2 LEAF2 с помошью Wireshark и посмотрим как выглядит ICMP-пакет в VXLAN с L3VNI:

Frame 129: 148 bytes on wire (1184 bits), 148 bytes captured (1184 bits) on interface -, id 0
Ethernet II, Src: 50:62:2c:a8:72:a6 (50:62:2c:a8:72:a6), Dst: 50:c2:ec:63:f4:d0 (50:c2:ec:63:f4:d0)
Internet Protocol Version 4, Src: 10.100.3.2, Dst: 10.100.3.3
User Datagram Protocol, Src Port: 47254, Dst Port: 4789
Virtual eXtensible Local Area Network
    Flags: 0x0800, VXLAN Network ID (VNI)
    Group Policy ID: 0
    VXLAN Network Identifier (VNI): 10
    Reserved: 0
Ethernet II, Src: 50:62:2c:a8:72:a6 (50:62:2c:a8:72:a6), Dst: 50:53:4f:42:99:52 (50:53:4f:42:99:52)
Internet Protocol Version 4, Src: 10.100.101.20, Dst: 10.100.200.10
Internet Control Message Protocol

Тут мы видим:

  • OUTER_SRC_MAC: аппаратный MAC LEAF2, OUTER_DST_MAC: MAC-адрес SPINE1;
  • OUTER_SRC_IP: Loopback-адрес LEAF2 (он же VTEP IP), OUTER_DST_IP: Loopback-адрес Boreder LEAF1 (он же VTEP IP);
  • OUTER_DST_UDP_PORT: 4789 — well-known порт VXLAN;
  • VNI: 10: L3VNI VRF green, в котором живут клиенты;
  • INNER_SRC_MAC: аппаратный MAC LEAF2;
  • INNER_DST_MAC: аппаратный MAC Boreder LEAF1;
  • INNER_SRC_IP: IP-адрес SRV-GREEN;
  • INNER_DST_IP: IP-адрес GREEN-TEST.

Таким образом мы создали VRF и настроили маршрутизацию в рамках Overlay между разными VLAN(VxLAN) в одной зоне безопасности.

3.6 VxLAN. Routing.

Что делать, если мы хотим передать в нашу overlay-сеть внешние маршруты, не привязанные к конкретному узлу? Маршруты RT-2 здесь не подходят, так как они жестко привязаны к MAC-адресу и хост-маске /32 или /128, что не позволяет передавать подсети с произвольной маской. Кажется, что проблема неразрешима. Именно поэтому был создан RFC 9136, который описывает новый тип EVPN-маршрута — IP Prefix Advertisement (тип маршрута 5).

В чем его особенность? Он не привязан к MAC-адресу и снимает ограничение на длину маски, передаваемой в NLRI. Таким образом, в RT-5 мы можем передавать, например, маршрут по умолчанию, маршруты до внешних подсетей или даже внутренних подсетей, обслуживающих наши клиентские домены.

Можно задаться вопросом: зачем нам передавать маршруты внутренних подсетей, если MAC/IP-информацию о конечных узлах мы всё равно получаем из маршрутов RT-2?

При выполнении раздела 3.5 в VRF green мы настроили дополнительный VLAN и SAG только на LEAF2 и Borerder LEAF1, а LEAF1 остался не тронутым. Значит ли это что клиенты подключённые к LEAF1 не смогут достигнуть тестовый сервер в VLAN200? 

root@srv-green-1:~# ping 10.100.200.10
PING 10.100.200.10 (10.100.200.10) 56(84) bytes of data.
From 10.100.101.1 icmp_seq=1 Destination Net Unreachable
^C
--- 10.100.200.10 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms


LEAF1#sh ip route vrf green 

Gateway of last resort is not set

 C        10.100.101.0/24 is directly connected, Vlan101

LEAF ничего не знает о сети 10.100.200.0/24 и не маршрутизирует трафик. Но что произойдёт если тестовый сервер green-test будет генерировать трафик, тем самым создавая маршрут RT-2. Для этого запустим пинг с green-test до srv-green2:

root@green-test:~# ping 10.100.101.20
PING 10.100.101.20 (10.100.101.20) 56(84) bytes of data.
64 bytes from 10.100.101.20: icmp_seq=5 ttl=62 time=10.6 ms
64 bytes from 10.100.101.20: icmp_seq=6 ttl=62 time=10.3 ms

Что мы теперь наблюдаем на LEAF1 и SRV-GREEN1:

root@srv-green-1:~# ping 10.100.200.10
PING 10.100.200.10 (10.100.200.10) 56(84) bytes of data.
64 bytes from 10.100.200.10: icmp_seq=1 ttl=62 time=11.9 ms
64 bytes from 10.100.200.10: icmp_seq=2 ttl=62 time=10.5 ms
64 bytes from 10.100.200.10: icmp_seq=3 ttl=62 time=12.6 ms
^C
--- 10.100.200.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 5ms
rtt min/avg/max/mdev = 10.524/11.654/12.554/0.844 ms

LEAF1#sh ip route vrf green

Gateway of last resort is not set

 B I      10.100.101.20/32 [200/0] via VTEP 10.100.3.2 VNI 10 router-mac 50:62:2c:a8:72:a6 local-interface Vxlan1
 C        10.100.101.0/24 is directly connected, Vlan101
 B I      10.100.200.10/32 [200/0] via VTEP 10.100.3.3 VNI 10 router-mac 50:53:4f:42:99:52 local-interface Vxlan1

Вот собственно и ответ, при наличии постоянного трафика от green-test и маршрута RT-2 связность будет, но не все сервера являются активным генератором трафика, можно конечно наколхозить скрипты пинга, что совсем будет не красиво. Но это и не требуется, ведь есть RT-5 маршруты для передачи внутренних подсетей, если Border LEAF1 будет анонстровать маршрут 10.100.200.0/24, то LEAF1 будет иметь маршрут в сеть назнчения, даже если сервер никак о себе не заявляет.

Так приступим же к настрйоке RT-5!
Для начала настроим RT-5 на всех LEAF-коммтуаторах чтобы анонсировать сети внутри фабрики и решить описаннную выше проблему. Для этого всего лишь нужно ввести комманду redistribute connected в AFI IPv4 в VRF. Эта команда включает анонсирование префиксов подсетей в EVPN как маршруты 5-го типа.

router bgp 65100
   vrf admin
      address-family ipv4
         redistribute connected
   vrf green
      address-family ipv4
         redistribute connected
   vrf yellow
      address-family ipv4
         redistribute connected

Теперь проверим решилась ли проблема с подсетью VLAN200 на LEAF1: 

root@srv-green-1:~# ping 10.100.200.1
PING 10.100.200.1 (10.100.200.1) 56(84) bytes of data.
64 bytes from 10.100.200.1: icmp_seq=1 ttl=63 time=24.9 ms
^C
--- 10.100.200.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 24.898/24.898/24.898/0.000 ms

root@srv-green-1:~# ping 10.100.200.10
PING 10.100.200.10 (10.100.200.10) 56(84) bytes of data.
64 bytes from 10.100.200.10: icmp_seq=1 ttl=62 time=24.5 ms
^C
--- 10.100.200.10 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 24.527/24.527/24.527/0.000 ms

LEAF1#sh ip route vrf green 

Gateway of last resort is not set

 C        10.100.101.0/24 is directly connected, Vlan101
 B I      10.100.200.0/24 [200/0] via VTEP 10.100.3.3 VNI 10 router-mac 50:53:4f:42:99:52 local-interface Vxlan1
                                  via VTEP 10.100.3.2 VNI 10 router-mac 50:62:2c:a8:72:a6 local-interface Vxlan1
 B I      10.100.254.4/30 [200/0] via VTEP 10.100.3.3 VNI 10 router-mac 50:53:4f:42:99:52 local-interface Vxlan1

Отлично, теперь можем приступить к анонсу внутренних сетей во внешний мир и принятие внешних маршрутов в нашу фабрику. Для начала настроим интерконнекты на Border Leaf1:

vlan 300
   name fw-interconnect-admin
!
vlan 301
   name fw-interconnect-green
!
vlan 302
   name fw-interconnect-yellow
!
interface Ethernet3
   no switchport
!
interface Ethernet3.300
   description fw-interconnect-admin
   encapsulation dot1q vlan 300
   vrf admin
   ip address 10.100.254.2/30
!
interface Ethernet3.301
   description fw-interconnect-green
   encapsulation dot1q vlan 301
   vrf green
   ip address 10.100.254.6/30
!
interface Ethernet3.302
   description fw-interconnect-yellow
   encapsulation dot1q vlan 302
   vrf yellow
   ip address 10.100.254.10/30

Теперь приступим к настройке BGP-пиринга с Firewall:

  vrf admin
      router-id 10.100.254.2
      neighbor 10.100.254.1 remote-as 65101
      neighbor 10.100.254.1 update-source Ethernet3.300
   !
   vrf green
      router-id 10.100.254.6
      neighbor 10.100.254.5 remote-as 65101
      neighbor 10.100.254.5 update-source Ethernet3.301
   !
   vrf yellow
      neighbor 10.100.254.9 remote-as 65101
      neighbor 10.100.254.9 update-source Ethernet3.302

Подключаемся к Management-порту 0/0/0 Firewall с виртаульной машины Admin через веб https://192.168.0.1:8443, и приступаем к настройке Fiewall:

Первоначальная настройка

Устанавливаем hostname:

Настройка NTP:

Настройка внешнего WAN интерфейса:

Локальные интерфейсы мы будем настраивать отдельно в качестве сабинтерфейсвов. На нербочем интерфейсе настраиваем «фейковый» адрес, чтобы закончить Startup Wizard:

Убираем галочку с настройки DHCP:

Создаём зоны безопасности для мапинга к интерфейсам:

Подлкючаемся через консоль или SSH и проводим настройку сабинтерфейсов. Не забудим включить ICMP для диагностики:

interface GigabitEthernet1/0/1.300
  vlan-type dot1q 300
  ip address 10.100.254.1 255.255.255.252
  alias admin
  service-manage ping permit

interface GigabitEthernet1/0/1.301
  vlan-type dot1q 301
  ip address 10.100.254.5 255.255.255.252
  alias green
  service-manage ping permit

interface GigabitEthernet1/0/1.302
  vlan-type dot1q 302
  ip address 10.100.254.9 255.255.255.252
  alias yellow
  service-manage ping permit

Также настроим loopback-интерфейс который будет использоваться как router-id и адрес управления:

interface LoopBack0
  ip address 10.100.254.254 255.255.255.255
  alias router-id

Добавляем интерфейсы в зоны безопасности:

firewall zone admin
  add interface GigabitEthernet1/0/1.300

firewall zone green
  add interface GigabitEthernet1/0/1.301

firewall zone yellow
  add interface GigabitEthernet1/0/1.302

Настройка BGP со стороны Firewall:

bgp 65101
  router-id 10.100.254.254
  peer 10.100.254.2 description admin-vrf
  peer 10.100.254.2 as-number 65100
  peer 10.100.254.2 connect-interface GigabitEthernet1/0/1.300
  peer 10.100.254.6 description green-vrf
  peer 10.100.254.6 as-number 65100
  peer 10.100.254.6 connect-interface GigabitEthernet1/0/1.301
  peer 10.100.254.10 description yellow-vrf
  peer 10.100.254.10 as-number 65100
  peer 10.100.254.10 connect-interface GigabitEthernet1/0/1.302
#
ipv4-family unicast
  undo synchronization
  peer 10.100.254.2 enable
  peer 10.100.254.2 default-route-advertise
  peer 10.100.254.6 enable
  peer 10.100.254.6 default-route-advertise
  peer 10.100.254.10 enable
  peer 10.100.254.10 default-route-advertise

Переходим к проверке: 

Boreder-LEAF1#sh ip bgp summary vrf admin
BGP summary information for VRF admin
Router identifier 10.100.254.2, local AS number 65100
Neighbor Status Codes: m - Under maintenance
  Neighbor     V AS           MsgRcvd   MsgSent  InQ OutQ  Up/Down State   PfxRcd PfxAcc
  10.100.254.1 4 65101          96849    113721    0    0 00:01:46 Estab   1      1

Boreder-LEAF1#sh ip bgp summary vrf green
BGP summary information for VRF green
Router identifier 10.100.254.6, local AS number 65100
Neighbor Status Codes: m - Under maintenance
  Neighbor     V AS           MsgRcvd   MsgSent  InQ OutQ  Up/Down State   PfxRcd PfxAcc
  10.100.254.5 4 65101          96548    113589    0    0 00:01:56 Estab   1      1

Boreder-LEAF1#sh ip bgp summary vrf yellow
BGP summary information for VRF yellow
Router identifier 10.100.254.10, local AS number 65100
Neighbor Status Codes: m - Under maintenance
  Neighbor     V AS           MsgRcvd   MsgSent  InQ OutQ  Up/Down State   PfxRcd PfxAcc
  10.100.254.9 4 65101          96479    113531    0    0 00:01:53 Estab   1      1

Соседство установилось, от соседа получен префикс. Посмотрим получены ли маршруты на Leaf-ах:

Boreder-LEAF1#sh ip route vrf yellow bgp
Gateway of last resort:
 B E      0.0.0.0/0 [200/0] via 10.100.254.9, Ethernet3.302
 B I      10.100.102.10/32 [200/0] via VTEP 10.100.3.1 VNI 20 router-mac 50:e8:5d:18:3c:6b local-interface Vxlan1
 B I      10.100.102.20/32 [200/0] via VTEP 10.100.3.2 VNI 20 router-mac 50:62:2c:a8:72:a6 local-interface Vxlan1


LEAF2#sh ip route vrf admin bgp 
Gateway of last resort:
B I      0.0.0.0/0 [200/0] via VTEP 10.100.3.3 VNI 1 router-mac 50:53:4f:42:99:52 local-interface Vxlan1
 B I      10.100.100.30/32 [200/0] via VTEP 10.100.3.3 VNI 1 router-mac 50:53:4f:42:99:52 local-interface Vxlan1
 B I      10.100.254.0/30 [200/0] via VTEP 10.100.3.3 VNI 1 router-mac 50:53:4f:42:99:52 local-interface Vxlan1


LEAF1#sh ip route vrf green bgp
Gateway of last resort:
 B I      0.0.0.0/0 [200/0] via VTEP 10.100.3.3 VNI 10 router-mac 50:53:4f:42:99:52 local-interface Vxlan1
 B I      10.100.200.0/24 [200/0] via VTEP 10.100.3.2 VNI 10 router-mac 50:62:2c:a8:72:a6 local-interface Vxlan1
                                  via VTEP 10.100.3.3 VNI 10 router-mac 50:53:4f:42:99:52 local-interface Vxlan1
 B I      10.100.254.4/30 [200/0] via VTEP 10.100.3.3 VNI 10 router-mac 50:53:4f:42:99:52 local-interface Vxlan1

Дефотлтный маршрут получен, но получает ли Firewall информацию о подсетях? 

<Firewall>display bgp routing-table 

 BGP Local router ID is 10.100.254.254 
 Status codes: * - valid, > - best, d - damped,
               h - history,  i - internal, s - suppressed, S - Stale
               Origin : i - IGP, e - EGP, ? - incomplete


 Total Number of Routes: 10
      Network            NextHop        MED        LocPrf    PrefVal Path/Ogn

 *>   10.100.100.0/24    10.100.254.2                          0      65100i
 *>   10.100.101.0/24    10.100.254.6                          0      65100i
 *>   10.100.101.10/32   10.100.254.6                          0      65100i
 *>   10.100.102.0/24    10.100.254.10                         0      65100i
 *>   10.100.102.10/32   10.100.254.10                         0      65100i
 *>   10.100.102.20/32   10.100.254.10                         0      65100i
 *>   10.100.200.0/24    10.100.254.6                          0      65100i
      10.100.254.0/30    10.100.254.2                          0      65100i
      10.100.254.4/30    10.100.254.6                          0      65100i
      10.100.254.8/30    10.100.254.10                         0      65100i

Мы получили не только агрегированные подсети, но и получаем маршруты до хостов из VXLAN-фабрики.. Это из-за того что мы передаём redistribute connected в AFI IPv4. Нужны ли нам эти маршруты? — Конечно нет, Fierewall знает о подсетях в целом и нагружать таблицу маршртуизации нет никакого смысла.

Чтобы это исправить создадим prefix-list и route-map для фильтрации host-маршрутов с маской /32 на Boreder-LEAF1:

ip prefix-list pl-bgp-hosts
 permit 0.0.0.0/32 ge 32

route-map rm-firewall-out deny 10 
 match ip address prefix-list pl-bgp-hosts
route-map rm-firewall-out permit 100

Привяжем созданную route-map к bgp соседу в VRF-ах:

router bgp 65100
vrf admin
      neighbor 10.100.254.1 route-map rm-firewall-out out
!
   vrf green
      neighbor 10.100.254.5 route-map rm-firewall-out out
!
   vrf yellow
      neighbor 10.100.254.9 route-map rm-firewall-out out

Проверяем: 

<Firewall>dis bgp routing-table 

 BGP Local router ID is 10.100.254.254 
 Status codes: * - valid, > - best, d - damped,
               h - history,  i - internal, s - suppressed, S - Stale
               Origin : i - IGP, e - EGP, ? - incomplete


 Total Number of Routes: 6
      Network            NextHop        MED        LocPrf    PrefVal Path/Ogn

 *>   10.100.100.0/24    10.100.254.2                          0      65100i
 *>   10.100.101.0/24    10.100.254.6                          0      65100i
 *>   10.100.102.0/24    10.100.254.10                          0      65100i
 *>   10.100.200.0/24    10.100.254.6                          0      65100i
      10.100.254.0/30    10.100.254.2                          0      65100i
      10.100.254.4/30    10.100.254.6                          0      65100i

Ну и осталось проверть связность клиентов в разных VRF, и доступа в интернет через Firewall:

root@srv-green-1:~# ping -c 1 77.88.8.7
PING 77.88.8.7 (77.88.8.7) 56(84) bytes of data.
64 bytes from 77.88.8.7: icmp_seq=1 ttl=49 time=143 ms

--- 77.88.8.7 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 143.217/143.217/143.217/0.000 ms

root@srv-green-1:~# ping -c 1 10.100.102.10
PING 10.100.102.10 (10.100.102.10) 56(84) bytes of data.
64 bytes from 10.100.102.10: icmp_seq=1 ttl=59 time=86.5 ms

--- 10.100.102.10 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 86.476/86.476/86.476/0.000 ms

root@srv-green-1:~# ping -c 1 10.100.102.20
PING 10.100.102.20 (10.100.102.20) 56(84) bytes of data.
64 bytes from 10.100.102.20: icmp_seq=1 ttl=59 time=146 ms

--- 10.100.102.20 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 146.127/146.127/146.127/0.000 ms

root@srv-green-1:~# ping -c 1 10.100.200.10
PING 10.100.200.10 (10.100.200.10) 56(84) bytes of data.
64 bytes from 10.100.200.10: icmp_seq=1 ttl=62 time=102 ms

--- 10.100.200.10 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 102.451/102.451/102.451/0.000 ms

root@srv-green-1:~# ping -c 1 10.100.100.30
PING 10.100.100.30 (10.100.100.30) 56(84) bytes of data.
64 bytes from 10.100.100.30: icmp_seq=1 ttl=60 time=10.10 ms

--- 10.100.100.30 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 10.954/10.954/10.954/0.000 ms

4. Итог

Отлично! В итоге нам удалось:

  • Собрали схему CLOS, и распределили адресное пространосво.
  • Настроили underlay-сеть с использовантем iBGP.
  • Настроили BGP peering между Leaf и Spine в AF l2vpn evpn с использованием iBGP.
  • В overlay сети VxLAN обмеспечили связность клиентов в L2VN с использованием типов маршрутов rt-2(mac+ip).
  • VxLAN. L3VNI настроили маршрутизацию между клиентами в одной зоне безопасности(vrf).
  • Анонсировали внутренние маршруты и обеспечили связность между VRF через firewall.
  • Настроили BGP peering с Firewall для импорта внешних маршрутов в VXLAN EVPN фабрику.
  • Обеспечили выход в интернет через Firewall.

Итоговая кофигурация оборудования:

SPINE1 

SPINE1#sh run
! Command: show running-config
! device: SPINE1 (vEOS-lab, EOS-4.29.2F)
!
! boot system flash:/vEOS-lab.swi
!
no aaa root
!
transceiver qsfp default-mode 4x10G
!
service routing protocols model multi-agent
!
hostname SPINE1
!
spanning-tree mode mstp
!
interface Ethernet1
   description -=LEAF1;eth1=-
   mtu 9000
   no switchport
   ip address 192.168.1.0/31
!
interface Ethernet2
   description -=LEAF2;eth2=-
   mtu 9000
   no switchport
   ip address 192.168.1.2/31
!
interface Ethernet3
   description -=LEAF3;eth3=-
   mtu 9000
   no switchport
   ip address 192.168.1.4/31
!
interface Ethernet4
!
interface Ethernet5
!
interface Ethernet6
!
interface Ethernet7
!
interface Ethernet8
!
interface Ethernet103
!
interface Loopback1
   description Router-ID
   ip address 10.100.0.1/32
!
interface Management1
!
ip routing
!
route-map rm_redistribute_lo permit 10
   match interface Loopback1
   set origin igp
!
route-map rm_redistribute_lo deny 40
!
router bgp 65100
   router-id 10.100.0.1
   timers bgp 3 9
   maximum-paths 10 ecmp 10
   neighbor LEAFS peer group
   neighbor LEAFS remote-as 65100
   neighbor LEAFS next-hop-self
   neighbor LEAFS bfd
   neighbor LEAFS bfd interval 100 min-rx 100 multiplier 3
   neighbor LEAFS route-reflector-client
   neighbor LEAFS-overlay peer group
   neighbor LEAFS-overlay remote-as 65100
   neighbor LEAFS-overlay update-source Loopback1
   neighbor LEAFS-overlay bfd interval 100 min-rx 100 multiplier 3
   neighbor LEAFS-overlay route-reflector-client
   neighbor LEAFS-overlay send-community extended
   neighbor 10.100.3.1 peer group LEAFS-overlay
   neighbor 10.100.3.1 description LEAF1-overlay
   neighbor 10.100.3.2 peer group LEAFS-overlay
   neighbor 10.100.3.2 description LEAF2-overlay
   neighbor 10.100.3.3 peer group LEAFS-overlay
   neighbor 10.100.3.3 description LEAF3-overlay
   neighbor 192.168.1.1 peer group LEAFS
   neighbor 192.168.1.1 description LEAF1
   neighbor 192.168.1.3 peer group LEAFS
   neighbor 192.168.1.3 description LEAF2
   neighbor 192.168.1.5 peer group LEAFS
   neighbor 192.168.1.5 description LEAF3
   redistribute connected route-map rm_redistribute_lo
   !
   address-family evpn
      neighbor LEAFS-overlay activate
   !
   address-family ipv4
      neighbor LEAFS activate
!
end
SPINE1#
SPINE2 

SPINE2#sh run
! Command: show running-config
! device: SPINE2 (vEOS-lab, EOS-4.29.2F)
!
! boot system flash:/vEOS-lab.swi
!
no aaa root
!
transceiver qsfp default-mode 4x10G
!
service routing protocols model multi-agent
!
hostname SPINE2
!
spanning-tree mode mstp
!
interface Ethernet1
   description -=LEAF1;eth2=-
   mtu 9000
   no switchport
   ip address 192.168.2.0/31
!
interface Ethernet2
   description -=LEAF2;eth2=-
   mtu 9000
   no switchport
   ip address 192.168.2.2/31
!
interface Ethernet3
   description -=LEAF3;eth2=-
   mtu 9000
   no switchport
   ip address 192.168.2.4/31
!
interface Ethernet4
!
interface Ethernet5
!
interface Ethernet6
!
interface Ethernet7
!
interface Ethernet8
!
interface Loopback1
   description Router-ID
   ip address 10.100.0.2/32
!
interface Management1
!
ip routing
!
route-map rm_redistribute_lo permit 10
   match interface Loopback1
   set origin igp
!
route-map rm_redistribute_lo deny 40
!
router bgp 65100
   router-id 10.100.0.2
   timers bgp 3 9
   maximum-paths 10 ecmp 10
   neighbor LEAFS peer group
   neighbor LEAFS remote-as 65100
   neighbor LEAFS next-hop-self
   neighbor LEAFS bfd
   neighbor LEAFS bfd interval 100 min-rx 100 multiplier 3
   neighbor LEAFS route-reflector-client
   neighbor LEAFS-overlay peer group
   neighbor LEAFS-overlay remote-as 65100
   neighbor LEAFS-overlay update-source Loopback1
   neighbor LEAFS-overlay bfd interval 100 min-rx 100 multiplier 3
   neighbor LEAFS-overlay route-reflector-client
   neighbor LEAFS-overlay send-community extended
   neighbor 10.100.3.1 peer group LEAFS-overlay
   neighbor 10.100.3.1 description LEAF1-overlay
   neighbor 10.100.3.2 peer group LEAFS-overlay
   neighbor 10.100.3.2 description LEAF2-overlay
   neighbor 10.100.3.3 peer group LEAFS-overlay
   neighbor 10.100.3.3 description LEAF3-overlay
   neighbor 192.168.2.1 peer group LEAFS
   neighbor 192.168.2.1 description LEAF1
   neighbor 192.168.2.3 peer group LEAFS
   neighbor 192.168.2.3 description LEAF2
   neighbor 192.168.2.5 peer group LEAFS
   neighbor 192.168.2.5 description LEAF3
   redistribute connected route-map rm_redistribute_lo
   !
   address-family evpn
      neighbor LEAFS-overlay activate
   !
   address-family ipv4
      neighbor LEAFS activate
!
end
SPINE2#
LEAF1 

LEAF1#sh run
! Command: show running-config
! device: LEAF1 (vEOS-lab, EOS-4.29.2F)
!
! boot system flash:/vEOS-lab.swi
!
no aaa root
!
transceiver qsfp default-mode 4x10G
!
service routing protocols model multi-agent
!
hostname LEAF1
!
spanning-tree mode mstp
!
vlan 100
   name admins
!
vlan 101
   name green-srv
!
vlan 102
   name yellow-srv
!
vrf instance admin
!
vrf instance green
!
vrf instance yellow
!
interface Ethernet1
   description -=SPINE1;eth1=-
   mtu 9000
   no switchport
   ip address 192.168.1.1/31
!
interface Ethernet2
   description -=SPINE2;eth1=-
   mtu 9000
   no switchport
   ip address 192.168.2.1/31
!
interface Ethernet3
   description -=SRV-GREEN-1;eth0=-
   switchport access vlan 101
!
interface Ethernet4
   description -=SRV-YELLOW-1;eth0=-
   switchport access vlan 102
!
interface Ethernet5
!
interface Ethernet6
!
interface Ethernet7
!
interface Ethernet8
!
interface Loopback1
   description Router-ID
   ip address 10.100.1.1/32
!
interface Loopback2
   description VTEP source
   ip address 10.100.3.1/32
!
interface Management1
!
interface Vlan100
   description admins
   vrf admin
   ip address virtual 10.100.100.1/24
!
interface Vlan101
   vrf green
   ip address virtual 10.100.101.1/24
!
interface Vlan102
   description yellow-srv
   vrf yellow
   ip address virtual 10.100.102.1/24
!
interface Vxlan1
   vxlan source-interface Loopback2
   vxlan udp-port 4789
   vxlan vlan 100 vni 100100
   vxlan vlan 101 vni 100101
   vxlan vlan 102 vni 100102
   vxlan vrf admin vni 1
   vxlan vrf green vni 10
   vxlan vrf yellow vni 20
   vxlan learn-restrict any
!
ip routing
ip routing vrf admin
ip routing vrf green
ip routing vrf yellow
!
route-map rm_redistribute_lo permit 10
   match interface Loopback1
   set origin igp
!
route-map rm_redistribute_lo permit 20
   match interface Loopback2
   set origin igp
!
route-map rm_redistribute_lo deny 40
!
router bgp 65100
   router-id 10.100.1.1
   timers bgp 3 9
   maximum-paths 10 ecmp 10
   neighbor SPINES peer group
   neighbor SPINES remote-as 65100
   neighbor SPINES bfd
   neighbor SPINES bfd interval 100 min-rx 100 multiplier 3
   neighbor SPINES-overlay peer group
   neighbor SPINES-overlay remote-as 65100
   neighbor SPINES-overlay update-source Loopback2
   neighbor SPINES-overlay bfd interval 100 min-rx 100 multiplier 3
   neighbor SPINES-overlay send-community extended
   neighbor 10.100.0.1 peer group SPINES-overlay
   neighbor 10.100.0.1 description SPINE1-overlay
   neighbor 10.100.0.2 peer group SPINES-overlay
   neighbor 10.100.0.2 description SPINE2-overlay
   neighbor 192.168.1.0 peer group SPINES
   neighbor 192.168.1.0 description SPINE1
   neighbor 192.168.2.0 peer group SPINES
   neighbor 192.168.2.0 description SPINE2
   redistribute connected route-map rm_redistribute_lo
   !
   vlan 100
      rd 3001:100100
      route-target both 65100:100100
      redistribute learned
   !
   vlan 101
      rd 3001:100101
      route-target both 65100:100101
      redistribute learned
   !
   vlan 102
      rd 3001:100102
      route-target both 65100:100102
      redistribute learned
   !
   address-family evpn
      neighbor SPINES-overlay activate
   !
   address-family ipv4
      neighbor SPINES activate
   !
   vrf admin
      rd 3001:1
      route-target import evpn 65100:1
      route-target export evpn 65100:1
      !
      address-family ipv4
         redistribute connected
   !
   vrf green
      rd 3001:10
      route-target import evpn 65100:10
      route-target export evpn 65100:10
      !
      address-family ipv4
         redistribute connected
   !
   vrf yellow
      rd 3001:20
      route-target import evpn 65100:20
      route-target export evpn 65100:20
      !
      address-family ipv4
         redistribute connected
!
end
LEAF1#
LEAF2 

LEAF2#sh run
! Command: show running-config
! device: LEAF2 (vEOS-lab, EOS-4.29.2F)
!
! boot system flash:/vEOS-lab.swi
!
no aaa root
!
transceiver qsfp default-mode 4x10G
!
service routing protocols model multi-agent
!
hostname LEAF2
!
spanning-tree mode mstp
!
vlan 100
   name admins
!
vlan 101
   name green-srv
!
vlan 102
   name yellow-srv
!
vlan 200
   name gree-test
!
vrf instance admin
!
vrf instance green
!
vrf instance yellow
!
interface Ethernet1
   description -=SPINE1;eth2=-
   mtu 9000
   no switchport
   ip address 192.168.1.3/31
!
interface Ethernet2
   mtu 9000
   no switchport
   ip address 192.168.2.3/31
!
interface Ethernet3
   description -=SRV-GREEN-2;eth0=-
   switchport access vlan 101
!
interface Ethernet4
   description -=SRV-YELLOW-2;eth0=-
   switchport access vlan 102
!
interface Ethernet5
!
interface Ethernet6
!
interface Ethernet7
!
interface Ethernet8
!
interface Loopback1
   description Router-ID
   ip address 10.100.1.2/32
!
interface Loopback2
   description VTEP source
   ip address 10.100.3.2/32
!
interface Management1
!
interface Vlan100
   description admins
   vrf admin
   ip address virtual 10.100.100.1/24
!
interface Vlan101
   description green-srv
   vrf green
   ip address virtual 10.100.101.1/24
!
interface Vlan102
   description yellow-srv
   vrf yellow
   ip address virtual 10.100.102.1/24
!
interface Vlan200
   description green-test
   vrf green
   ip address virtual 10.100.200.1/24
!
interface Vxlan1
   vxlan source-interface Loopback2
   vxlan udp-port 4789
   vxlan vlan 100 vni 100100
   vxlan vlan 101 vni 100101
   vxlan vlan 102 vni 100102
   vxlan vlan 200 vni 100200
   vxlan vrf admin vni 1
   vxlan vrf green vni 10
   vxlan vrf yellow vni 20
   vxlan learn-restrict any
!
ip virtual-router mac-address 00:50:10:00:10:00
!
ip routing
ip routing vrf admin
ip routing vrf green
ip routing vrf yellow
!
route-map rm_redistribute_lo permit 10
   match interface Loopback1
   set origin igp
!
route-map rm_redistribute_lo permit 20
   match interface Loopback2
   set origin igp
!
route-map rm_redistribute_lo deny 40
!
router bgp 65100
   router-id 10.100.1.2
   timers bgp 3 9
   maximum-paths 10 ecmp 10
   neighbor SPINES peer group
   neighbor SPINES remote-as 65100
   neighbor SPINES bfd
   neighbor SPINES bfd interval 100 min-rx 100 multiplier 3
   neighbor SPINES-overlay peer group
   neighbor SPINES-overlay remote-as 65100
   neighbor SPINES-overlay update-source Loopback2
   neighbor SPINES-overlay bfd interval 100 min-rx 100 multiplier 3
   neighbor SPINES-overlay send-community extended
   neighbor 10.100.0.1 peer group SPINES-overlay
   neighbor 10.100.0.1 description SPINE1-overlay
   neighbor 10.100.0.2 peer group SPINES-overlay
   neighbor 10.100.0.2 description SPINE2-overlay
   neighbor 192.168.1.2 peer group SPINES
   neighbor 192.168.1.2 description SPINE1
   neighbor 192.168.2.2 peer group SPINES
   neighbor 192.168.2.2 description SPINE2
   redistribute connected route-map rm_redistribute_lo
   !
   vlan 100
      rd 3002:100100
      route-target both 65100:100100
      redistribute learned
   !
   vlan 101
      rd 3002:100101
      route-target both 65100:100101
      redistribute learned
   !
   vlan 102
      rd 3002:100102
      route-target both 65100:100102
      redistribute learned
   !
   vlan 200
      rd 3002:100200
      route-target both 65100:100200
      redistribute learned
   !
   address-family evpn
      neighbor SPINES-overlay activate
   !
   address-family ipv4
      neighbor SPINES activate
   !
   vrf admin
      rd 3002:1
      route-target import evpn 65100:1
      route-target export evpn 65100:1
      !
      address-family ipv4
         redistribute connected
   !
   vrf greeb
   !
   vrf green
      rd 3002:10
      route-target import evpn 65100:10
      route-target export evpn 65100:10
      !
      address-family ipv4
         redistribute connected
   !
   vrf yellow
      rd 3002:20
      route-target import evpn 65100:20
      route-target export evpn 65100:20
      !
      address-family ipv4
         redistribute connected
!
end
LEAF2#
Border-LEAF1 

Boreder-LEAF1#sh run
! Command: show running-config
! device: Boreder-LEAF1 (vEOS-lab, EOS-4.29.2F)
!
! boot system flash:/vEOS-lab.swi
!
no aaa root
!
transceiver qsfp default-mode 4x10G
!
service routing protocols model multi-agent
!
hostname Boreder-LEAF1
!
spanning-tree mode mstp
!
vlan 100
   name admins
!
vlan 101
   name green-srv
!
vlan 102
   name yellow-srv
!
vlan 200
   name green-test
!
vlan 300
   name fw-interconnect-admin
!
vlan 301
   name fw-interconnect-green
!
vlan 302
   name fw-interconnect-yellow
!
vrf instance admin
!
vrf instance green
!
vrf instance yellow
!
interface Ethernet1
   description -=SPINE1;eth3=-
   mtu 9000
   no switchport
   ip address 192.168.1.5/31
!
interface Ethernet2
   description -=SPINE2;eth3=-
   mtu 9000
   no switchport
   ip address 192.168.2.5/31
!
interface Ethernet3
   no switchport
!
interface Ethernet3.300
   description fw-interconnect-admin
   encapsulation dot1q vlan 300
   vrf admin
   ip address 10.100.254.2/30
!
interface Ethernet3.301
   description fw-interconnect-green
   encapsulation dot1q vlan 301
   vrf green
   ip address 10.100.254.6/30
!
interface Ethernet3.302
   description fw-interconnect-yellow
   encapsulation dot1q vlan 302
   vrf yellow
   ip address 10.100.254.10/30
!
interface Ethernet4
   description -=Admin;eth0=-
   switchport access vlan 100
!
interface Ethernet5
   description green-test
   switchport access vlan 200
!
interface Ethernet6
!
interface Ethernet7
!
interface Ethernet8
!
interface Loopback1
   description Router-ID
   ip address 10.100.1.3/32
!
interface Loopback2
   description VTEP-Source
   ip address 10.100.3.3/32
!
interface Management1
!
interface Vlan100
   description admins
   vrf admin
   ip address virtual 10.100.100.1/24
!
interface Vlan101
   description green-srv
   vrf green
   ip address virtual 10.100.101.1/24
!
interface Vlan102
   description yellow-srv
   vrf yellow
   ip address virtual 10.100.102.1/24
!
interface Vlan200
   description green-test
   vrf green
   ip address virtual 10.100.200.1/24
!
interface Vxlan1
   vxlan source-interface Loopback2
   vxlan udp-port 4789
   vxlan vlan 100 vni 100100
   vxlan vlan 101 vni 100101
   vxlan vlan 102 vni 100102
   vxlan vlan 200 vni 100200
   vxlan vrf admin vni 1
   vxlan vrf green vni 10
   vxlan vrf yellow vni 20
!
ip virtual-router mac-address 00:50:10:00:10:00
!
ip routing
ip routing vrf admin
ip routing vrf green
ip routing vrf yellow
!
ip prefix-list pl-bgp-hosts
   seq 10 permit 0.0.0.0/32 ge 32
!
ip route vrf green 10.100.254.254/32 10.100.254.5 name BGP-FW-ROUTER-ID
ip route vrf yellow 10.100.254.254/32 10.100.254.9 name BGP-FW-ROUTER-ID
!
route-map rm-firewall-out deny 10
   match ip address prefix-list pl-bgp-hosts
!
route-map rm-firewall-out permit 100
!
route-map rm_redistribute_lo permit 10
   match interface Loopback1
   set origin igp
!
route-map rm_redistribute_lo permit 20
   match interface Loopback2
   set origin igp
!
route-map rm_redistribute_lo deny 40
!
router bgp 65100
   router-id 10.100.1.3
   timers bgp 3 9
   maximum-paths 10 ecmp 10
   neighbor FW peer group
   neighbor SPINES peer group
   neighbor SPINES remote-as 65100
   neighbor SPINES bfd
   neighbor SPINES bfd interval 100 min-rx 100 multiplier 3
   neighbor SPINES-overlay peer group
   neighbor SPINES-overlay remote-as 65100
   neighbor SPINES-overlay update-source Loopback2
   neighbor SPINES-overlay bfd interval 100 min-rx 100 multiplier 3
   neighbor SPINES-overlay send-community extended
   neighbor 10.100.0.1 peer group SPINES-overlay
   neighbor 10.100.0.1 description SPINE1-overlay
   neighbor 10.100.0.2 peer group SPINES-overlay
   neighbor 10.100.0.2 description SPINE2-overlay
   neighbor 10.100.254.1 ebgp-multihop 3
   neighbor 192.168.1.4 peer group SPINES
   neighbor 192.168.1.4 description SPINE1
   neighbor 192.168.2.4 peer group SPINES
   neighbor 192.168.2.4 description SPINE2
   redistribute connected route-map rm_redistribute_lo
   !
   vlan 100
      rd 3003:100100
      route-target both 65100:100100
      redistribute learned
   !
   vlan 101
      rd 3003:100101
      route-target both 65100:100101
      redistribute learned
   !
   vlan 102
      rd 3003:100102
      route-target both 65100:100102
      redistribute learned
   !
   vlan 200
      rd 3001:100200
      route-target both 65100:100200
      redistribute learned
   !
   address-family evpn
      neighbor SPINES-overlay activate
   !
   address-family ipv4
      neighbor SPINES activate
   !
   vrf admin
      rd 3003:1
      route-target import evpn 65100:1
      route-target export evpn 65100:1
      router-id 10.100.254.2
      neighbor 10.100.254.1 remote-as 65101
      neighbor 10.100.254.1 update-source Ethernet3.300
      no neighbor 10.100.254.1 allowas-in
      neighbor 10.100.254.1 route-map rm-firewall-out out
      !
      address-family ipv4
         neighbor 10.100.254.1 activate
         redistribute connected
   !
   vrf green
      rd 3003:10
      route-target import evpn 65100:10
      route-target export evpn 65100:10
      router-id 10.100.254.6
      neighbor 10.100.254.5 remote-as 65101
      neighbor 10.100.254.5 update-source Ethernet3.301
      neighbor 10.100.254.5 route-map rm-firewall-out out
      !
      address-family ipv4
         redistribute connected
   !
   vrf yellow
      rd 3003:20
      route-target import evpn 65100:20
      route-target export evpn 65100:20
      router-id 10.100.254.10
      neighbor 10.100.254.9 remote-as 65101
      neighbor 10.100.254.9 update-source Ethernet3.302
      neighbor 10.100.254.9 route-map rm-firewall-out out
      !
      address-family ipv4
         redistribute connected
!
end
Boreder-LEAF1#
Firewall 

<Firewall>dis cur
!Software Version V500R001C10
#
sysname Firewall
#
 undo l2tp sendaccm enable
 l2tp domain suffix-separator @
#
undo telnet server enable
undo telnet ipv6 server enable
#
clock timezone GMT:London add 00:00:00
#
 firewall packet-filter basic-protocol enable
#
 firewall detect ftp
#
 firewall defend action discard
#
 log type traffic enable
 log type syslog enable
 log type policy enable
#
 undo dataflow enable
#
 isp name "china mobile"                  
 isp name "china mobile" set filename china-mobile.csv
 isp name "china unicom"
 isp name "china unicom" set filename china-unicom.csv
 isp name "china telecom"
 isp name "china telecom" set filename china-telecom.csv
 isp name "china educationnet"
 isp name "china educationnet" set filename china-educationnet.csv
#
 snmp-agent session history-max-number enable
 snmp-agent session trap threshold 1600000
 snmp-agent session-rate trap threshold 64000
#
 web-manager security version tlsv1 tlsv1.1
 web-manager security enable
#
firewall dataplane to manageplane application-apperceive default-action drop
#
 update schedule ips-sdb daily 06:28
 update schedule av-sdb daily 06:28
 update schedule sa-sdb daily 06:28
 update schedule cnc daily 06:28
#
 dns server unnumbered interface GigabitEthernet1/0/0
 dns proxy enable                         
#
ip vpn-instance default
 ipv4-family
#
 time-range worktime
  period-range 08:00:00 to 18:00:00 working-day
#
aaa
 authentication-scheme default
 authentication-scheme admin_local
 authentication-scheme admin_radius_local
 authentication-scheme admin_hwtacacs_local
 authentication-scheme admin_ad_local
 authentication-scheme admin_ldap_local
 authentication-scheme admin_radius
 authentication-scheme admin_hwtacacs
 authentication-scheme admin_ad
 authentication-scheme admin_ldap
 authorization-scheme default
 accounting-scheme default
 domain default
  service-type l2tp ike
  reference user current-domain
 manager-user password-modify enable      
 manager-user audit-admin
  password cipher @%@%uHYjX;c^~%7$a*:1,R~J%*X.'&~FZJZDa&~nO^T,EbLX*X1%@%@%
  service-type web terminal
  level 15

 manager-user api-admin
  password cipher @%@%!_D,B>S27!`T($.|c\w*,=Y31JB'(`k>t;rsT}A#/y.0=Y6,@%@%
  service-type api
  level 15

 manager-user admin
  password cipher @%@%{G=B8|]9=%/jVC@a'aKL\%Uf1-pr!&-a}:27s.M"Iz%*%Ui\@%@%
  service-type web terminal ssh
  level 15
  authentication-scheme admin_local

 role system-admin
  dashboard read-write
  monitor read-write
  policy read-write
  object read-write
  network read-write
  system read-write
 role device-admin                        
  dashboard read-only
  monitor read-only log log-traffic log-threat log-policy-matching report traffic-map threat-map session statistic statistic-acl
  monitor none diagnose
  policy read-write
  object read-write
  network read-write
  system read-write high-reliability
  system none configuration vsys license update-center mail-send feedback
 role device-admin(monitor)
  dashboard read-only
  monitor read-only log log-traffic log-threat log-policy-matching report traffic-map threat-map session statistic statistic-acl
  monitor none diagnose
  policy read-only
  object read-only
  network read-only
  system read-only high-reliability
  system none configuration vsys license update-center mail-send feedback
 role audit-admin
  dashboard read-only
  monitor read-write log-audit
  monitor read-only log log-traffic log-threat log-syslog log-policy-matching report traffic-map threat-map
  monitor none session statistic statistic-acl diagnose
  policy none
  object none                             
  network none
  system none
 bind manager-user audit-admin role audit-admin
#
interface GigabitEthernet0/0/0
 undo shutdown
 ip binding vpn-instance default
 ip address 192.168.0.1 255.255.255.0
 service-manage http permit
 service-manage https permit
 service-manage ping permit
 service-manage ssh permit
 service-manage snmp permit
 service-manage telnet permit
 service-manage netconf permit
#
interface GigabitEthernet1/0/0
 undo shutdown
 service-manage http permit
 service-manage https permit
 service-manage ping permit
 service-manage ssh permit
 ip address dhcp-alloc
#                                         
interface GigabitEthernet1/0/1
 undo shutdown
#
interface GigabitEthernet1/0/1.300
 vlan-type dot1q 300
 ip address 10.100.254.1 255.255.255.252
 alias admin
 service-manage ping permit
#
interface GigabitEthernet1/0/1.301
 vlan-type dot1q 301
 ip address 10.100.254.5 255.255.255.252
 alias green
 service-manage ping permit
#
interface GigabitEthernet1/0/1.302
 vlan-type dot1q 302
 ip address 10.100.254.9 255.255.255.252
 alias yellow
 service-manage ping permit
#
interface GigabitEthernet1/0/2
 undo shutdown
#                                         
interface GigabitEthernet1/0/3
 undo shutdown
#
interface GigabitEthernet1/0/4
 undo shutdown
 ip address 192.168.111.1 255.255.255.0
#
interface Virtual-if0
#
interface NULL0
#
interface LoopBack0
 ip address 10.100.254.254 255.255.255.255
 alias router-id
#
firewall zone local
 set priority 100
#
firewall zone trust
 set priority 85
 add interface GigabitEthernet0/0/0
 add interface GigabitEthernet1/0/4
#
firewall zone untrust                     
 set priority 5
 add interface GigabitEthernet1/0/0
#
firewall zone dmz
 set priority 50
#
firewall zone name admin id 4
 set priority 90
 add interface GigabitEthernet1/0/1.300
#
firewall zone name green id 5
 set priority 80
 add interface GigabitEthernet1/0/1.301
#
firewall zone name yellow id 6
 set priority 75
 add interface GigabitEthernet1/0/1.302
#
l2tp-group default-lns
#
bgp 65101
 router-id 10.100.254.254
 peer 10.100.254.2 as-number 65100
 peer 10.100.254.2 description admin-vrf  
 peer 10.100.254.2 connect-interface GigabitEthernet1/0/1.300
 peer 10.100.254.6 as-number 65100
 peer 10.100.254.6 description green-vrf
 peer 10.100.254.6 connect-interface GigabitEthernet1/0/1.301
 peer 10.100.254.10 as-number 65100
 peer 10.100.254.10 connect-interface GigabitEthernet1/0/1.302
 #
 ipv4-family unicast
  undo synchronization
  peer 10.100.254.2 enable
  peer 10.100.254.2 default-route-advertise
  peer 10.100.254.6 enable
  peer 10.100.254.6 default-route-advertise
  peer 10.100.254.10 enable
  peer 10.100.254.10 default-route-advertise
#
undo ssh server compatible-ssh1x enable
sftp server enable
stelnet server enable
ssh authentication-type default password
ssh user admin
ssh user admin authentication-type all
ssh user admin service-type all
ssh user admin sftp-directory hda1:       
#
user-interface con 0
 authentication-mode aaa
user-interface vty 0 4
 authentication-mode aaa
 protocol inbound ssh
user-interface vty 16 20
#
sa
#
location
#
 multi-interface
  mode proportion-of-weight
#
right-manager server-group
#
api
#
security-policy
 default action permit
#
traffic-policy
#                                         
policy-based-route
#
nat-policy
 rule name GuideNat1730836487201
  egress-interface GigabitEthernet1/0/0
  action nat easy-ip
#
pcp-policy
#
dns-transparent-policy
#
return
<Firewall>


Буду рад обратной связи! Оставляйте комментарии.

#CLOS #VxLAN #BGP

  1. Павел Avatar
    Павел

    Отличная статья!

    Reply
    1. akkontsevoy Avatar
      akkontsevoy

      Спасибо!

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

How can we help?