Сценарий
Компания 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 | Зона безопасности | Описание |
---|---|---|---|---|---|---|
admins | 100 | 10.100.100.0/24 | 10.100.100.1 | admins | admins | Подсеть администраторов |
green-srv | 101 | 10.100.101.0/24 | 10.100.101.1 | green-srv | green | Серверная подсеть green |
yellow-srv | 102 | 10.100.102.0/24 | 10.100.102.1 | yellow-srv | yellow | Серверная подсеть 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
Мы видим следующее:
- От каждого Leaf мы получаем по 3 маршрута с типом RT-3, который называется IMET. Этот маршрут создаётся для каждого отдельного VNI и служит сигналом для других участников EVPN-фабрики о том, что данный VTEP хочет получать BUM-трафик для конкретного VNI, который указан в маршруте IMET.
- Также мы наблюдаем пять маршрутов с типом 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 |
admin | 1 | 65100:1 | <последние два октета + незначашие нули loopback2>:1 |
green | 10 | 65100:10 | <последние два октета + незначашие нули loopback2>:10 |
yellow | 20 | 65100: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
-
Отличная статья!
-
Спасибо!
-
Leave a Reply