VRF, BGP и MPLS. Как провайдеры объединяют изолированные сети клиентов

Представьте оператора связи, который обслуживает тысячу компаний. У каждой собственные филиалы, серверы, маршрутизаторы и внутренние IP-адреса. Более того, несколько клиентов используют одинаковые сети 192.168.1.0/24. При этом все хотят соединить офисы через инфраструктуру провайдера, не предоставляя соседям доступ к своим серверам.

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

Для такой архитектуры используют сочетание VRF, BGP и MPLS. В современных дата-центрах аналогичную задачу часто решают с помощью EVPN/VXLAN.

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

Как VRF, BGP и MPLS работают вместе

Начнём с разделения обязанностей. VRF создаёт независимые таблицы маршрутизации, BGP распространяет сведения о доступных сетях, а MPLS доставляет пакеты через магистраль с помощью меток.

У каждой технологии собственная задача. VRF сама по себе не передаёт маршруты между маршрутизаторами. BGP не создаёт физические каналы связи. MPLS не определяет, каким клиентам разрешено обмениваться трафиком.

Провайдер объединяет три механизма в услугу MPLS L3VPN, которую описывает RFC 4364. Клиент получает связность между своими площадками на третьем уровне модели OSI, а оператор управляет передачей пакетов через общую сеть.

Три типа маршрутизаторов в сети провайдера

В типовой архитектуре участвуют три категории устройств.

• CE (Customer Edge) находится на стороне клиента. Через CE офис или дата-центр подключается к провайдеру. Устройство передаёт оператору маршруты клиентских сетей через статическую маршрутизацию, BGP, OSPF или другой согласованный механизм.
• PE (Provider Edge) стоит на границе инфраструктуры оператора. PE поддерживает клиентские VRF, принимает маршруты от CE и обменивается VPN-маршрутами с другими PE.
• P (Provider) работает внутри магистрали. В классической MPLS L3VPN P-маршрутизаторы пересылают пакеты по транспортным MPLS-меткам и не обязаны хранить маршруты внутренних сетей клиентов.

Предположим, компания ACME подключила два офиса к разным PE-маршрутизаторам. На PE1 создана таблица VRF ACME, на PE2 существует своя VRF ACME. Одинаковое имя удобно администратору, но протоколы не требуют совпадения локальных имён VRF на разных устройствах.

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

Как проходит пакет от одного филиала к другому

Проследим передачу данных из первого офиса ACME в серверную сеть второго офиса.

1. CE первого филиала отправляет IP-пакет на PE1.
2. PE1 определяет VRF по интерфейсу, на котором получил пакет. Для ACME используется отдельная таблица маршрутизации.
3. Маршрутизатор находит маршрут к 10.10.2.0/24. Маршрут ранее поступил от PE2 через MP-BGP.
4. PE1 добавляет сервисную MPLS-метку, объявленную выходным PE, и транспортную метку для доставки пакета к PE2.
5. P-маршрутизаторы пересылают пакет по транспортной метке. Клиентский IP-адрес назначения им для принятия решения не нужен.
6. PE2 обрабатывает сервисную метку, определяет соответствующий контекст пересылки и направляет пакет к CE второго филиала.

Часто говорят, что MPLS L3VPN использует две метки. Для типового LDP- или SR-MPLS-транспорта такая схема действительно характерна, но фактический стек может отличаться. Например, предпоследний маршрутизатор может удалить внешнюю метку перед передачей пакета на PE2. В сетях с Segment Routing транспортная часть также может содержать несколько меток.

Сервисная метка не равна номеру VRF. Выходной маршрутизатор может выделять метки на VRF, интерфейс, маршрут или другой объект пересылки в зависимости от реализации.

Зачем MP-BGP, если уже есть BGP

Обычный BGP умеет распространять IP-префиксы между маршрутизаторами. Но в сети провайдера сразу возникает проблема. Клиент ACME использует 10.10.1.0/24, а клиент BETA использует точно такой же диапазон.

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

MP-BGP (Multiprotocol BGP) расширяет BGP возможностью работать с несколькими семействами адресов. Для MPLS L3VPN используют семейства VPNv4 и VPNv6.

VPNv4-маршрут включает специальный идентификатор Route Distinguisher, обычный IP-префикс и передаваемую средствами BGP информацию, необходимую для доставки через MPLS, включая сервисную метку.

Благодаря MP-BGP два PE-маршрутизатора могут распространять маршруты нескольких клиентов, даже если клиентские адресные пространства полностью совпадают.

При этом MP-BGP не обязательно соединяет каждый PE со всеми остальными. В крупных сетях маршруты распространяют через Route Reflector, который уменьшает число BGP-соседств.

Route Distinguisher и Route Target. Два механизма, которые постоянно путают

В конфигурациях MPLS L3VPN встречаются строки rd 65000:101 и route-target both 65000:100. Значения похожи, но механизмы решают принципиально разные задачи.

RD делает маршрут различимым в MP-BGP. RT определяет, в какие VRF разрешено импортировать маршрут.

Параметр	Route Distinguisher (RD)	Route Target (RT)
Назначение	Различать одинаковые IP-префиксы	Управлять импортом и экспортом VPN-маршрутов
Пример	65000:101	65000:100
Роль в BGP	Часть VPN-префикса	Расширенное сообщество BGP
Может совпадать у нескольких VRF	Технически возможно, но требует продуманной схемы	Да, совпадение используют для объединения нужных VRF
Управляет доступом между VRF	Нет	Определяет допустимость импорта маршрутов, но не заменяет межсетевой экран
Непосредственно пересылается в MPLS-пакете	Нет	Нет

RD позволяет использовать одинаковые IP-адреса

Допустим, у двух клиентов существует одинаковая сеть 10.10.1.0/24.

На PE1 настроены следующие идентификаторы.

VRF ACME
 RD 65000:101
 IPv4 10.10.1.0/24
 
 VRF BETA
 RD 65000:201
 IPv4 10.10.1.0/24

В MP-BGP маршруты выглядят как разные VPNv4-префиксы.

65000:101:10.10.1.0/24
 65000:201:10.10.1.0/24

Запись выше условная, но передаёт основную идею. RD добавляет к IPv4-префиксу 64-битное значение, благодаря которому BGP различает независимые маршруты к одинаковым адресам.

RD не является идентификатором клиента, криптографическим ключом или правилом доступа.

Более того, во многих архитектурах рекомендуется выделять отдельный RD для каждой VRF на каждом PE. Так BGP сможет хранить несколько путей к одному клиентскому префиксу, полученных от разных PE, не объединяя их преждевременно в один VPNv4-префикс.

RT определяет, какие сети могут обмениваться маршрутами

Теперь представим, что филиалы ACME подключены к PE1 и PE2. У каждого PE свой RD, но оба используют одинаковый Route Target 65000:100.

PE1 экспортирует маршруты ACME с меткой RT 65000:100. PE2 настроен импортировать маршруты с таким RT. Поэтому префиксы первого филиала становятся кандидатами на установку в VRF ACME второго маршрутизатора.

Для клиента BETA используется другой RT, например 65000:200. Маршруты BETA не импортируются в VRF ACME, пока оператор не создаст соответствующее правило.

Существуют два основных направления.

• Export RT задаёт сообщества, которые маршрутизатор присоединяет к экспортируемым VPN-маршрутам.
• Import RT задаёт сообщества, по которым маршрутизатор отбирает маршруты для импорта в VRF.

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

Поэтому отсутствие маршрута в VRF не всегда говорит об ошибке Route Target.

Пример конфигурации на Cisco IOS XE

Ниже фрагмент конфигурации PE1 для двух клиентов. Оба VRF используют собственный RD и отдельный RT.

vrf definition ACME
  rd 65000:101
  address-family ipv4
   route-target both 65000:100
  exit-address-family
 !
 vrf definition BETA
  rd 65000:201
  address-family ipv4
   route-target both 65000:200
  exit-address-family
 !
 interface GigabitEthernet0/0/1
  description Link-to-ACME-CE1
  vrf forwarding ACME
  ip address 192.0.2.1 255.255.255.252
  no shutdown
 !
 router bgp 65000
  bgp router-id 10.255.0.1
  neighbor 10.255.0.2 remote-as 65000
  neighbor 10.255.0.2 update-source Loopback0
  !
  address-family vpnv4
   neighbor 10.255.0.2 activate
   neighbor 10.255.0.2 send-community extended
  exit-address-family
  !
  address-family ipv4 vrf ACME
   neighbor 192.0.2.2 remote-as 65101
   neighbor 192.0.2.2 activate
  exit-address-family

Пример предполагает, что Loopback0 имеет адрес 10.255.0.1/32, удалённый PE или Route Reflector доступен по 10.255.0.2, а маршрутизация магистрали и MPLS-транспорт уже работают. Интерфейс клиента BETA, его маршруты и конфигурация второго PE в приведённый фрагмент не входят.

На PE2 для ACME можно использовать RD 65000:102 при сохранении RT 65000:100. Значение RD изменится, а правила участия в клиентской VPN останутся прежними.

Команда send-community extended позволяет передавать расширенные сообщества BGP, включая RT. Без передачи нужных сообществ удалённый PE может получить VPN-маршрут, но не импортировать его в клиентскую VRF.

Одна только конфигурация BGP ещё не создаёт рабочую MPLS L3VPN. В магистрали также нужны IP-связность между транспортными адресами PE, механизм распределения транспортных меток, поддержка MPLS на соответствующих интерфейсах и корректная пересылка меток.

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

Как проверить работу VRF и MP-BGP

На PE-маршрутизаторе Cisco IOS XE начните с состояния виртуальных таблиц.

show vrf
 show ip route vrf ACME
 show ip route vrf BETA

Проверьте, присутствуют ли локальные и удалённые клиентские маршруты.

Затем посмотрите VPN-маршруты, которыми обмениваются PE.

show bgp vpnv4 unicast all
 show bgp vpnv4 unicast all summary

Синтаксис второй команды и других расширенных представлений BGP может отличаться между платформами. При диагностике проверяйте поддерживаемые варианты через встроенную справку CLI.

Если MP-BGP работает, а клиентский трафик не проходит, проверьте транспортные метки и таблицу пересылки.

show mpls ldp neighbor
 show mpls forwarding-table
 show ip cef vrf ACME

Команда проверки LDP применима к сети, где транспортные метки распространяются через LDP. Если магистраль построена на SR-MPLS, состояние сегментов и транспортных путей проверяют другими средствами.

Наконец, запустите проверку доступности из нужного VRF.

ping vrf ACME 10.10.2.10

Если маршруты присутствуют, но пакеты не доходят, исследуйте транспортный путь, MPLS-метки, MTU, фильтры и обратную маршрутизацию. Если VPN-маршрут виден в глобальной таблице MP-BGP, но отсутствует внутри VRF, проверьте RD, RT, политику импорта и доступность BGP next hop.

VRF без MPLS и EVPN/VXLAN в дата-центрах

MPLS L3VPN хорошо подходит для операторских магистралей, но современная инфраструктура не ограничивается одной технологией передачи пакетов.

Корпоративный маршрутизатор может использовать VRF вместе с BGP без MPLS. В дата-центре виртуальные маршрутизируемые сети часто объединяют через EVPN/VXLAN поверх обычной IP-фабрики.

Как работает BGP внутри VRF без MPLS

Самый простой случай представляет собой VRF Lite. На маршрутизаторе созданы две независимые таблицы маршрутизации. Для каждой можно настроить собственные BGP-соседства.

Например, VRF ACME устанавливает BGP-сессию с маршрутизатором первого филиала, а VRF BETA обменивается маршрутами с другим клиентом.

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

Но возникает ограничение. Обычная BGP-сессия внутри VRF не создаёт автоматически сквозной транспорт между удалёнными VRF на разных устройствах.

Для соединения удалённых площадок необходима соответствующая физическая или логическая связность. Подойдут отдельные каналы, VLAN, GRE-туннели, IPsec-туннели или другие транспортные механизмы.

Возможен и обмен VPN-маршрутами через MP-BGP без MPLS, если выбранная архитектура использует другой способ передачи клиентского трафика. Например, EVPN может распространять маршруты через BGP и передавать пакеты через VXLAN.

Отсутствие MPLS не отменяет потребность в транспортной сети. BGP сообщает, куда направлять пакеты, но сам не доставляет клиентский трафик.

Как EVPN/VXLAN заменяет традиционную схему в дата-центре

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

Для решения подобных задач применяют архитектуру EVPN/VXLAN.

VXLAN (Virtual Extensible LAN) инкапсулирует сетевые кадры в UDP/IP и передаёт через IP-инфраструктуру. Идентификатор VNI (VXLAN Network Identifier) определяет виртуальный сетевой контекст для передаваемого трафика.

VNI занимает 24 бита. Теоретическое пространство идентификаторов значительно больше 4094 значений VLAN ID обычного IEEE 802.1Q. Однако число поддерживаемых виртуальных сетей на конкретном коммутаторе определяется ресурсами оборудования и программными ограничениями, а не только размером поля VNI.

EVPN (Ethernet VPN) использует MP-BGP для распространения информации о конечных устройствах, сетевых сегментах и IP-маршрутах.

Вместе технологии решают две разные задачи.

• EVPN распространяет сведения, необходимые для работы виртуальных сетей.
• VXLAN инкапсулирует и переносит пользовательский трафик через IP-фабрику.

В отличие от классической MPLS L3VPN, транспортной сети VXLAN не требуется переключать MPLS-метки. Обычные маршрутизаторы магистрали обеспечивают IP-доступность между конечными точками туннелей, называемыми VTEP.

VTEP может находиться на коммутаторе Leaf, программном коммутаторе или другом совместимом устройстве.

Зачем в EVPN нужны L2VNI и L3VNI

При построении маршрутизируемого EVPN/VXLAN часто различают два вида виртуальных сетевых идентификаторов.

L2VNI относится к сегменту второго уровня и обычно связан с MAC-VRF, таблицей коммутации и соответствующим широковещательным доменом.

L3VNI используется для маршрутизируемого взаимодействия между IP-VRF на разных VTEP. Несколько сегментов с собственными L2VNI могут принадлежать одной клиентской IP-VRF.

Для маршрутизации между подсетями применяется IRB (Integrated Routing and Bridging). В распространённой модели Symmetric IRB входной VTEP маршрутизирует пакет в клиентской VRF, передаёт через L3VNI, а выходной VTEP выполняет маршрутизацию к локальному сегменту назначения.

Модель подробно описана в RFC 9135. Благодаря такой архитектуре не требуется поддерживать все клиентские подсети второго уровня на каждом Leaf-коммутаторе.

Для обмена сведениями EVPN использует несколько типов маршрутов. Наиболее полезны для понимания следующие.

Тип EVPN-маршрута	Назначение
Type 2	Объявление MAC-адресов и связанных с ними IP-адресов
Type 3	Информация для организации доставки широковещательного, неизвестного одноадресного и многоадресного трафика в сегменте
Type 5	Объявление IP-префиксов для маршрутизируемой связности

Тип 5 позволяет распространять IP-маршруты без необходимости объявлять каждую сеть как отдельный набор MAC/IP-записей. Механизм определён в RFC 9136.

RD и RT сохраняют свои функции и в EVPN. RD различает маршруты, RT определяет допустимость импорта в соответствующий IP-VRF или EVPN-сегмент, а VNI участвует в передаче пакетов.

Поэтому утверждение «VNI заменяет Route Target» неверно. RT работает в плоскости управления, а VNI используется в плоскости передачи данных. Даже при совпадающих VNI маршруты не обязаны импортироваться, если политики RT не позволяют обмен.

Практическая проверка EVPN на FRRouting

FRRouting поддерживает BGP EVPN и позволяет строить лаборатории EVPN/VXLAN на Linux.

В FRR клиентская IP-VRF связывается с L3VNI, а BGP распространяет EVPN-маршруты. При этом операционная система должна иметь корректно созданные VRF, мосты, интерфейсы VXLAN и привязки сегментов.

Типовой фрагмент конфигурации FRRouting для включения обмена EVPN-маршрутами выглядит следующим образом.

router bgp 65000
  neighbor 10.255.0.2 remote-as 65000
  !
  address-family l2vpn evpn
   neighbor 10.255.0.2 activate
   advertise-all-vni
  exit-address-family

Команда advertise-all-vni включает соответствующие механизмы EVPN в FRR, но сама по себе не создаёт интерфейсы VXLAN и не связывает клиентскую VRF с L3VNI.

Для экспорта IPv4-маршрутов конкретной клиентской VRF в виде EVPN Type 5 используется отдельная настройка.

router bgp 65000 vrf ACME
  address-family l2vpn evpn
   advertise ipv4 unicast
  exit-address-family

Конфигурация предполагает, что нужные IPv4-маршруты уже существуют в BGP-таблице VRF ACME, а L3VNI настроен. Без соответствующих маршрутов BGP нечего экспортировать.

Проверить состояние можно командами.

show bgp l2vpn evpn
 show bgp l2vpn evpn route type 5
 show evpn vni
 show bgp vrf ACME ipv4 unicast

Первая команда показывает доступные EVPN-маршруты, вторая позволяет сосредоточиться на IP-префиксах Type 5, а последующие помогают проверить привязку VNI и состояние IPv4-маршрутов клиента.

Полный порядок подготовки интерфейсов Linux, VNI и BGP приведён в руководстве FRRouting. Для воспроизводимой лаборатории нужно согласовать конфигурацию FRR с сетевыми объектами Linux и убедиться, что VTEP-адреса доступны через транспортную сеть.

Route Leaking, общие сервисы и границы сетевой изоляции

Изолированные сети удобны до тех пор, пока нескольким клиентам или подразделениям не потребуется доступ к общему ресурсу.

Представим провайдера, который обслуживает инфраструктуру заказчиков. У клиентов разные VRF, но всем нужен доступ к серверу мониторинга, системе обновлений или корпоративному DNS.

Создавать отдельный физический сервер для каждого клиента не всегда оправданно. Вместо полного объединения сетей можно выборочно распространять маршруты.

Подобный механизм называют Route Leaking, или обменом маршрутами между VRF.

Как организовать доступ к общим сервисам

Допустим, существуют три VRF.

• ACME с RT 65000:100.
• BETA с RT 65000:200.
• SHARED с RT 65000:900.

В SHARED находится сервер мониторинга 172.20.0.10/32. Клиентам нужно обращаться к серверу, но доступ между ACME и BETA должен оставаться запрещённым.

На уровне маршрутов можно построить следующую схему.

VRF	Что экспортирует	Что импортирует
ACME	Разрешённые маршруты с RT 65000:100	Маршрут общего сервиса с RT 65000:900
BETA	Разрешённые маршруты с RT 65000:200	Маршрут общего сервиса с RT 65000:900
SHARED	Разрешённые маршруты с RT 65000:900	Маршруты для обратной связи с RT 65000:100 и 65000:200

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

Для этого используют политики маршрутизации, фильтры префиксов и возможности конкретной платформы.

Простое совпадение RT не ограничивает доступ одним сервером. Если под RT 65000:900 экспортировать целую сеть общих сервисов, клиентские VRF смогут получить маршруты ко всем разрешённым для импорта адресам.

Особенно неприятная проблема возникает, когда два клиента используют одинаковые IP-адреса. Единая SHARED VRF не сможет без дополнительных механизмов однозначно маршрутизировать ответы к двум разным узлам с одним адресом назначения.

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

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

Почему Route Leaking может нарушить безопасность

Типичная ошибка заключается в слишком широком импорте Route Target.

Предположим, администратор случайно добавил в VRF ACME следующий импорт.

route-target import 65000:200

Если маршруты клиента BETA экспортируются с RT 65000:200, часть соответствующих VPN-маршрутов может оказаться в ACME после применения остальных правил выбора маршрутов.

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

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

VRF, MPLS L3VPN и VXLAN обеспечивают логическую изоляцию, но сами по себе не гарантируют конфиденциальность трафика. Для передачи чувствительных данных через недоверенную инфраструктуру используйте дополнительные механизмы шифрования, например IPsec или TLS. Изменения RT и Route Leaking проверяйте в лаборатории и применяйте с контролем прав доступа, фильтрацией и аудитом маршрутов.

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

Как масштабировать сеть на тысячи VRF

Разделить два клиента относительно просто. Поддерживать тысячи VPN на сотнях PE гораздо сложнее.

Ограничения появляются сразу на нескольких уровнях.

• Таблицы маршрутизации. Каждый PE должен хранить клиентские маршруты, необходимые для локальных VRF, а управляющая плоскость обрабатывает изменения этих маршрутов.
• Аппаратная память. FIB, TCAM, таблицы меток, MAC-адресов и соседей имеют конечную ёмкость, которая различается между моделями оборудования.
• BGP. Большое число маршрутов, BGP-соседств и изменений состояния сети увеличивает нагрузку на процессоры и память маршрутизаторов.
• EVPN. Большое число VNI, MAC/IP-маршрутов и подключённых устройств может ограничивать масштаб даже при достаточном пространстве идентификаторов.
• Эксплуатация. Автоматическая выдача RD и RT, контроль уникальности идентификаторов, инвентаризация VRF и проверка межсетевых политик становятся самостоятельными задачами.

Для уменьшения числа BGP-соседств применяют Route Reflector. Чтобы не распространять все VPN-маршруты всем участникам сети, используют Route Target Constrain.

Механизм, описанный в RFC 4684, позволяет BGP-маршрутизаторам обмениваться информацией об интересующих их RT и ограничивать распространение ненужных VPN-маршрутов.

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

Но RT Constrain не увеличивает физическую память маршрутизатора и не исправляет ошибочные политики импорта. Разгружая управляющую плоскость, оператор всё равно должен контролировать FIB, доступные ресурсы оборудования и скорость обработки изменений сети.

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

Какую технологию выбрать

Сценарий	Подход	Основная причина
Несколько изолированных сетей на одном маршрутизаторе	VRF Lite	Не нужна отдельная транспортная VPN-инфраструктура
Множество филиалов через магистраль провайдера	MPLS L3VPN	Масштабируемый обмен маршрутами и пересылка по меткам
Изолированные сегменты между стойками дата-центра	EVPN/VXLAN	Передача виртуальных сетей через IP-фабрику
Доступ нескольких VRF к общим сервисам	Route Leaking с фильтрацией	Выборочный обмен маршрутами без полного объединения сетей
Соединение площадок через недоверенный интернет	VRF с защищёнными туннелями	Логическая изоляция вместе с шифрованием

Нельзя утверждать, что EVPN/VXLAN всегда лучше MPLS L3VPN. Операторская магистраль и сеть дата-центра предъявляют разные требования к маршрутизации, задержкам, оборудованию и модели эксплуатации.

Кроме того, EVPN не обязательно работает поверх VXLAN. Существуют архитектуры EVPN с MPLS-транспортом. Выбор управляющей плоскости и способа инкапсуляции не следует смешивать в одно решение.

Частые вопросы о VRF, BGP и MPLS

Может ли провайдер использовать один и тот же IP-адрес у нескольких клиентов?

Да. Отдельные VRF позволяют клиентам использовать совпадающие адресные пространства. В MPLS L3VPN RD делает соответствующие VPNv4- или VPNv6-маршруты различимыми для MP-BGP, а RT управляет их импортом в нужные VRF.

Нужно ли настраивать MPLS на клиентском маршрутизаторе CE?

В типовой услуге MPLS L3VPN не нужно. CE обменивается обычными IP-маршрутами с PE, а MPLS-метки обрабатывает инфраструктура оператора. Существуют специальные сценарии, например Carrier's Carrier, где клиентские устройства тоже могут участвовать в MPLS.

Можно ли построить MPLS L3VPN без BGP?

Классическая BGP/MPLS IP VPN использует MP-BGP для распространения VPN-маршрутов между PE. Другие MPLS-сервисы могут использовать иные механизмы, но такую архитектуру уже нельзя без уточнений называть стандартной BGP/MPLS L3VPN по RFC 4364.

Должны ли RD и RT иметь одинаковые значения?

Нет. Например, RD может равняться 65000:101, а RT иметь значение 65000:100. Раздельные схемы назначения часто удобнее, потому что RD различает маршруты, а RT выражает политику их распространения.

Может ли один VRF импортировать маршруты нескольких VPN?

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

Шифруется ли трафик внутри MPLS L3VPN и VXLAN?

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

В чём разница между VRF и сетевыми пространствами имён Linux?

Linux VRF разделяет прежде всего контексты маршрутизации внутри одного сетевого пространства имён. Network Namespace изолирует более широкий набор сетевых объектов, включая интерфейсы, адреса, сокеты и таблицы маршрутизации. Пространства имён подходят для более полной сетевой изоляции процессов, но требуют отдельного проектирования связности между ними.

Почему BGP видит EVPN-маршрут, но трафик через VXLAN не проходит?

Наличие маршрута в BGP ещё не гарантирует успешную передачу пакетов. Проверьте импорт RT, доступность удалённого VTEP, соответствие VNI, тип маршрута, наличие необходимых записей в таблицах пересылки, MTU и правила межсетевого экрана. Ошибка в одной из этих областей может нарушить связность при рабочем BGP-соседстве.

Вывод. VRF, MP-BGP и MPLS позволяют провайдеру объединять многочисленные клиентские сети без отдельной физической магистрали для каждой организации. VRF разделяет таблицы маршрутизации, RD различает совпадающие адреса, RT определяет правила импорта маршрутов, а MPLS передаёт пакеты между площадками. В дата-центрах аналогичные принципы применяются с EVPN и VXLAN.

Для первого знакомства достаточно собрать лабораторию из двух PE, одного P и двух клиентских VRF. Настройте одинаковые IP-префиксы в разных VRF, проверьте обмен VPNv4-маршрутами и убедитесь, что клиенты не получают чужие маршруты. Затем намеренно измените один Import RT и проследите, как поменяется содержимое таблиц маршрутизации. Такой эксперимент лучше всего показывает, где заканчивается изоляция VRF и начинается ответственность администратора за политику обмена маршрутами.

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