Представьте маршрутизатор, к которому подключены корпоративная сеть, гостевой Wi-Fi и оборудование подрядчика. У каждой сети собственные адреса и правила доступа. Гостям нельзя видеть внутренние серверы, подрядчику нужен доступ только к одному приложению, а администратор должен управлять всеми сегментами с одного устройства.
Обычный маршрутизатор использует общую таблицу маршрутизации. Даже если разделить пользователей по VLAN, устройство сможет маршрутизировать трафик между подключёнными подсетями, если такая маршрутизация разрешена и не заблокирована дополнительными правилами.
Virtual Routing and Forwarding (VRF) меняет подход. Маршрутизатор создаёт несколько независимых таблиц маршрутизации и связывает каждую с определёнными интерфейсами. Пакеты из одной VRF не получают автоматического доступа к маршрутам другой.
Разберём настройку VRF на Cisco IOS XE, Linux и FRRouting. Создадим виртуальные сети, проверим изоляцию, добавим статические маршруты и организуем контролируемый обмен маршрутами через Route Leaking.
Примеры рассчитаны на отдельную лабораторию с IPv4. Названия интерфейсов и некоторые команды Cisco зависят от аппаратной платформы и выпуска IOS XE. Linux-примеры требуют административных сетевых привилегий. Команды для Cisco и FRRouting сверены с документацией производителей, но полноценный запуск лаборатории на реальном маршрутизаторе не выполнялся.
Лабораторные настройки меняют таблицы маршрутизации, интерфейсы и правила пересылки пакетов. Выполняйте команды на тестовых устройствах или виртуальных машинах. На рабочих маршрутизаторах сначала сохраните конфигурацию и предусмотрите доступ к консоли на случай потери сетевого подключения.
1. Практическая схема сети с несколькими VRF
Возьмём две сети. Красная VRF обслуживает корпоративные компьютеры, синяя VRF содержит серверы отдельного подразделения.
| Параметр | VRF RED | VRF BLUE |
|---|---|---|
| Назначение | Корпоративная сеть | Серверный сегмент |
| Подсеть | 10.10.0.0/24 | 10.20.0.0/24 |
| Шлюз | 10.10.0.1 | 10.20.0.1 |
| Тестовый узел | 10.10.0.10 | 10.20.0.10 |
| Таблица Linux | 100 | 200 |
| Интерфейс Cisco | GigabitEthernet0/0 | GigabitEthernet0/1 |
Обе сети подключены к одному маршрутизатору. Пока VRF изолированы, компьютер 10.10.0.10 видит свой шлюз, но не получает доступ к серверу 10.20.0.10. При необходимости можно открыть отдельные маршруты между сегментами.
Маршрутизатор R1
+-------------------------+
| |
| VRF RED |
| Таблица маршрутов 100 |
| |
| 10.10.0.1/24 |
| | |
| | |
| Route Leaking |
| | |
| | |
| 10.20.0.1/24 |
| |
| VRF BLUE |
| Таблица маршрутов 200 |
| |
+-----------+-------------+
|
Два сегмента
RED BLUE
10.10.0.10 10.20.0.10
Клиент СерверДля Cisco номера таблиц в схеме условные. IOS XE связывает VRF с собственными внутренними структурами маршрутизации, поэтому вручную назначать номера 100 и 200, как в Linux, не требуется.
Порядок работы одинаков для разных платформ. Сначала создаём VRF, затем связываем интерфейсы с нужными таблицами, добавляем IP-адреса, проверяем изоляцию и только после успешных проверок открываем необходимые маршруты между сегментами.
Есть одна особенность, которая часто удивляет начинающих администраторов. Две VRF могут использовать одинаковую IP-адресацию. Например, RED и BLUE способны независимо содержать сеть 192.168.1.0/24. Но при прямом обмене маршрутами совпадающие префиксы создают неоднозначность. Для подобной архитектуры потребуются преобразование адресов, отдельный межсетевой шлюз либо другой механизм, учитывающий принадлежность трафика к VRF.
2. Настройка VRF Lite на Cisco IOS XE
В Cisco IOS XE настройка VRF Lite начинается с создания VRF и привязки интерфейсов. Для обычной локальной изоляции не требуется MPLS, а механизм маршрутизации работает с физическими портами, VLAN-интерфейсами и поддерживаемыми логическими интерфейсами.
Создаём две VRF
Подключаемся к маршрутизатору через консоль или SSH и переходим в режим конфигурации.
enable
configure terminal
vrf definition RED
description Corporate network
address-family ipv4
exit-address-family
exit
vrf definition BLUE
description Server network
address-family ipv4
exit-address-family
exitКоманда vrf definition создаёт виртуальный контекст маршрутизации. address-family ipv4 активирует поддержку IPv4 для соответствующей VRF.
В старых конфигурациях Cisco встречаются команды ip vrf RED и ip vrf forwarding RED. Классический синтаксис отличается от современного варианта с vrf definition и vrf forwarding. Смешивать разные формы без проверки поддержки конкретной платформы не следует.
Для простой VRF Lite не нужно обязательно назначать Route Distinguisher (RD). RD играет особую роль при работе с VPN-маршрутами, позволяя различать одинаковые IP-префиксы. Для локальных независимых таблиц маршрутизации RD сам по себе не нужен.
Привязываем физические интерфейсы
Теперь назначим GigabitEthernet0/0 красной VRF, а GigabitEthernet0/1 синей.
interface GigabitEthernet0/0
description VRF RED LAN
vrf forwarding RED
ip address 10.10.0.1 255.255.255.0
no shutdown
exit
interface GigabitEthernet0/1
description VRF BLUE LAN
vrf forwarding BLUE
ip address 10.20.0.1 255.255.255.0
no shutdown
exit
endНа коммутаторах с физическими портами второго уровня предварительно может потребоваться команда no switchport. На маршрутизаторах с обычными интерфейсами третьего уровня такой шаг не нужен.
Есть неприятная особенность IOS XE. При изменении принадлежности интерфейса к VRF устройство может удалить ранее заданный IPv4-адрес. Поэтому в рабочей процедуре сначала выполняют vrf forwarding, а затем заново назначают ip address.
Если сначала настроить IP-адрес, а потом перенести интерфейс в VRF, связь с устройством может пропасть. Особенно опасно менять таким способом интерфейс, через который проходит административная SSH-сессия.
Проверяем созданные VRF
show vrf
show vrf interfaces
show ip route vrf RED
show ip route vrf BLUE
show running-config interface GigabitEthernet0/0
show running-config interface GigabitEthernet0/1После успешной настройки в таблице RED должен появиться непосредственно подключённый маршрут 10.10.0.0/24, а в BLUE маршрут 10.20.0.0/24.
Маршрут 10.20.0.0/24 не должен автоматически появляться в таблице RED. Аналогично, в BLUE не должно быть маршрута к 10.10.0.0/24.
Проверим связь с узлами.
ping vrf RED 10.10.0.10
ping vrf BLUE 10.20.0.10
traceroute vrf RED 10.10.0.10
traceroute vrf BLUE 10.20.0.10Успешный ping подтверждает доступность соответствующего узла из выбранной VRF. Если связь отсутствует, сначала проверяем физический порт, VLAN, адресацию, ARP и межсетевые фильтры.
Настраиваем статические маршруты внутри VRF
Предположим, что за маршрутизатором 10.10.0.254 находится дополнительная корпоративная сеть 10.11.0.0/24.
Добавим маршрут только в RED.
configure terminal
ip route vrf RED 10.11.0.0 255.255.255.0 10.10.0.254
end
show ip route vrf RED 10.11.0.0
show ip route vrf BLUE 10.11.0.0Маршрутизатор 10.10.0.254 должен существовать и иметь действующий путь к сети 10.11.0.0/24. Также потребуется обратный маршрут к источникам трафика. Без выполнения этих условий статическая запись сама по себе не обеспечит обмен пакетами.
Если next-hop доступен через RED, Cisco разрешает адрес следующего узла в контексте RED. Маршрут не должен попадать в BLUE.
У команды ip route vrf существует параметр global, который позволяет искать следующий узел в глобальной таблице маршрутизации. Но такой способ не является универсальной командой обмена маршрутами между двумя произвольными VRF. Для RED и BLUE используем отдельный механизм Route Leaking.
Привязываем виртуальный интерфейс VLAN
Физических портов может не хватать. В таком случае несколько сетевых сегментов передают через один физический интерфейс с тегами 802.1Q.
Предположим, что GigabitEthernet0/2 подключён к коммутатору через trunk, который передаёт VLAN 110.
configure terminal
interface GigabitEthernet0/2
no ip address
no shutdown
exit
interface GigabitEthernet0/2.110
encapsulation dot1Q 110
vrf forwarding RED
ip address 192.0.2.1 255.255.255.0
no shutdown
exit
endПодсеть 192.0.2.0/24 здесь служит лабораторным примером. VLAN 110 должна быть разрешена на порту соседнего коммутатора.
Теперь RED содержит два подключённых сегмента. Обычный физический интерфейс GigabitEthernet0/0 и логический GigabitEthernet0/2.110 используют одну таблицу маршрутизации.
Route Leaking между RED и BLUE на Cisco
Разрешим двум изолированным сетям обмениваться маршрутами. Для начала импортируем только непосредственно подключённые подсети 10.10.0.0/24 и 10.20.0.0/24.
В IOS XE доступно несколько способов Route Leaking. Один из вариантов использует BGP, RD и Route Target. Другой основан на функции Route Replication, которая копирует выбранные маршруты между таблицами без обязательного запуска BGP.
Для нашей схемы подойдёт второй способ. Cisco подтверждает поддержку Route Replication на ряде платформ IOS XE, включая Catalyst 8500 и 9500. Доступность команды и особенности обработки маршрутов необходимо проверять для конкретной модели и выпуска ПО.
Сначала создадим списки разрешённых префиксов.
configure terminal
ip prefix-list RED_PREFIXES seq 10 permit 10.10.0.0/24
ip prefix-list BLUE_PREFIXES seq 10 permit 10.20.0.0/24
route-map RED_TO_BLUE permit 10
match ip address prefix-list RED_PREFIXES
exit
route-map BLUE_TO_RED permit 10
match ip address prefix-list BLUE_PREFIXES
exitТеперь добавим обмен маршрутами.
vrf definition RED
address-family ipv4
route-replicate from vrf BLUE unicast connected route-map BLUE_TO_RED
exit-address-family
exit
vrf definition BLUE
address-family ipv4
route-replicate from vrf RED unicast connected route-map RED_TO_BLUE
exit-address-family
exit
endКоманда в RED импортирует подключённый маршрут 10.20.0.0/24 из BLUE. Команда в BLUE импортирует маршрут 10.10.0.0/24 из RED.
Проверим результат.
show ip route vrf RED 10.20.0.0
show ip route vrf BLUE 10.10.0.0
ping vrf RED 10.20.0.10
ping vrf BLUE 10.10.0.10На поддерживаемых реализациях реплицированные маршруты в выводе Cisco могут иметь обозначение +. Для полной проверки недостаточно увидеть запись в таблице. Нужно убедиться, что маршрут установлен в таблицу пересылки и работает в обоих направлениях.
Если требуется доступ только к одному серверу, вместо всего диапазона 10.20.0.0/24 лучше распространять отдельный маршрут 10.20.0.10/32. Но разрешённый маршрут ещё не ограничивает протоколы и порты. TCP, UDP и ICMP придётся фильтровать отдельными правилами безопасности.
На некоторых платформах для такого узкого экспорта удобнее использовать отдельный статический маршрут к серверу и его выборочную репликацию. Нельзя просто заменить /24 на /32 в списке фильтра и ожидать, что Route Replication автоматически создаст более специфичный маршрут.
3. Настройка VRF в Linux через iproute2
Linux умеет создавать VRF непосредственно средствами ядра. Утилита iproute2 управляет VRF-устройствами, привязкой интерфейсов и отдельными таблицами маршрутизации.
Ядро Linux применяет механизм l3mdev, который связывает входящий сетевой контекст с соответствующей таблицей маршрутизации. Технические детали и ограничения описаны в документации ядра.
Для лаборатории удобнее использовать сетевые пространства имён network namespaces. Создадим два виртуальных компьютера и подключим каждый к своей VRF через пару интерфейсов veth. В результате получим тестовую сеть без физических коммутаторов.
Создаём VRF и две таблицы маршрутизации
Команды выполняются на отдельной Linux-машине с установленными iproute2 и iputils-ping. Понадобятся права администратора, поддержка VRF в ядре и разрешение создавать сетевые интерфейсы. Некоторые контейнерные среды запрещают подобные операции даже пользователю root.
sudo ip link add vrf-red type vrf table 100
sudo ip link add vrf-blue type vrf table 200
sudo ip link set vrf-red up
sudo ip link set vrf-blue up
sudo ip -d link show type vrf
sudo ip rule showКоманда ip link add создаёт VRF-устройство и связывает его с указанной таблицей.
Таблица 100 принадлежит vrf-red, таблица 200 принадлежит vrf-blue. Правило l3mdev позволяет ядру выбирать соответствующую таблицу по VRF-контексту.
Добавим маршруты по умолчанию с запретом пересылки. Подобная запись не отправляет пакеты во внешнюю сеть, а завершает поиск маршрута ошибкой, если более подходящий маршрут отсутствует.
sudo ip route add table 100 unreachable default metric 4278198272
sudo ip route add table 200 unreachable default metric 4278198272Большая метрика позволяет в дальнейшем заменить запрет полноценным маршрутом с меньшей метрикой. Такая схема особенно полезна при работе с FRRouting. Без подходящего маршрута по умолчанию отдельные сценарии поиска могут перейти к последующим правилам маршрутизации, что нежелательно для строгой изоляции.
Создаём два виртуальных компьютера
sudo ip netns add host-red
sudo ip netns add host-blue
sudo ip link add r-uplink type veth peer name eth-r
sudo ip link add b-uplink type veth peer name eth-b
sudo ip link set eth-r netns host-red
sudo ip link set eth-b netns host-blueПары veth работают как виртуальные Ethernet-кабели. Пакет, отправленный через один конец пары, появляется на другом.
Привяжем оставшиеся на основном хосте интерфейсы к нужным VRF.
sudo ip link set r-uplink master vrf-red
sudo ip link set b-uplink master vrf-blue
sudo ip addr add 10.10.0.1/24 dev r-uplink
sudo ip addr add 10.20.0.1/24 dev b-uplink
sudo ip link set r-uplink up
sudo ip link set b-uplink upПосле привязки интерфейсов связанные маршруты появятся в таблицах 100 и 200.
При переносе существующего Linux-интерфейса в VRF ядро перемещает подключённые и локальные маршруты в таблицу VRF. Другие маршруты, зависевшие от интерфейса, могут исчезнуть. Поэтому настраивать дополнительные статические маршруты удобнее после привязки интерфейсов.
Настраиваем адреса виртуальных узлов
sudo ip -n host-red link set lo up
sudo ip -n host-red addr add 10.10.0.10/24 dev eth-r
sudo ip -n host-red link set eth-r up
sudo ip -n host-red route add default via 10.10.0.1
sudo ip -n host-blue link set lo up
sudo ip -n host-blue addr add 10.20.0.10/24 dev eth-b
sudo ip -n host-blue link set eth-b up
sudo ip -n host-blue route add default via 10.20.0.1Теперь основной Linux-хост играет роль маршрутизатора, а два network namespace имитируют самостоятельные компьютеры.
Проверим связь внутри каждой VRF.
sudo ip netns exec host-red ping -c 3 10.10.0.1
sudo ip netns exec host-blue ping -c 3 10.20.0.1Оба шлюза должны отвечать, если интерфейсы подняты и ICMP не блокируется межсетевым экраном.
Теперь попробуем обратиться из красного сегмента к синему.
sudo ip netns exec host-red ping -c 3 -W 1 10.20.0.10Пока между VRF нет разрешённых маршрутов, соединение не должно работать. Таким образом можно убедиться, что изоляция действует.
Проверяем таблицы маршрутизации Linux
ip -d link show type vrf
ip link show master vrf-red
ip link show master vrf-blue
ip route show table 100
ip route show table 200
ip route show vrf vrf-red
ip route show vrf vrf-blue
ip route get vrf vrf-red 10.10.0.10
ip route get vrf vrf-blue 10.20.0.10Команда ip route get показывает, какой путь ядро выберет для конкретного назначения. Такой способ диагностики полезнее простого просмотра всех маршрутов, когда таблица содержит много префиксов.
Для запуска программы в контексте конкретной VRF существует команда ip vrf exec.
sudo ip vrf exec vrf-red ping -c 3 10.10.0.10
sudo ip vrf exec vrf-blue ping -c 3 10.20.0.10Механизм ip vrf exec привязывает сетевые сокеты процесса к выбранной VRF. Его работа зависит от поддержки необходимых возможностей ядра, cgroup v2 и полномочий процесса. В ограниченных контейнерах запуск может завершиться ошибкой даже при наличии VRF-устройства.
Настраиваем статическую маршрутизацию в Linux
Статический маршрут можно добавить непосредственно в нужную таблицу.
sudo ip route add table 100 10.11.0.0/24 via 10.10.0.10 dev r-uplink
ip route show table 100Предполагается, что узел 10.10.0.10 маршрутизирует трафик в сеть 10.11.0.0/24. В созданной лаборатории такой дополнительной сети пока нет, поэтому команда демонстрирует установку маршрута, но не обеспечивает доступность 10.11.0.0/24.
Для удаления записи используется обратная команда.
sudo ip route del table 100 10.11.0.0/24 via 10.10.0.10 dev r-uplinkRoute Leaking в Linux без FRRouting
У Linux нет универсальной команды, которая автоматически копирует все маршруты одной VRF в другую с полноценной меж-VRF-пересылкой. Обычная запись маршрута через интерфейс, принадлежащий другой VRF, также не является надёжным универсальным решением.
Для простой лаборатории можно организовать виртуальное соединение между двумя VRF через пару veth. Каждая сторона получит собственный интерфейс и адрес в транзитной сети.
Следующий вариант представляет альтернативу динамическому Route Leaking через FRRouting, описанному дальше. Не нужно одновременно включать оба механизма в одной лаборатории.
sudo ip link add x-red type veth peer name x-blue
sudo ip link set x-red master vrf-red
sudo ip link set x-blue master vrf-blue
sudo ip addr add 172.31.255.1/30 dev x-red
sudo ip addr add 172.31.255.2/30 dev x-blue
sudo ip link set x-red up
sudo ip link set x-blue upТеперь внутри одной машины появилось виртуальное транзитное соединение. Интерфейс x-red принадлежит красной VRF, x-blue принадлежит синей.
Добавим маршруты к противоположным сетям.
sudo ip route add table 100 10.20.0.0/24 via 172.31.255.2 dev x-red
sudo ip route add table 200 10.10.0.0/24 via 172.31.255.1 dev x-blue
sudo sysctl -w net.ipv4.ip_forward=1Теперь RED отправляет пакеты к сети 10.20.0.0/24 через x-red. Пакет проходит по виртуальному Ethernet-соединению, поступает на x-blue и далее маршрутизируется уже внутри BLUE.
Обратный путь устроен симметрично. BLUE направляет трафик к 10.10.0.0/24 через x-blue, после чего пакет оказывается на x-red.
Проверим доступность.
sudo ip netns exec host-red ping -c 3 10.20.0.10
sudo ip netns exec host-blue ping -c 3 10.10.0.10
ip route show table 100
ip route show table 200Если обе таблицы настроены корректно, IPv4-пересылка включена и правила фильтрации не препятствуют обмену, пакеты должны проходить между виртуальными узлами.
При неудаче проверьте значение rp_filter на интерфейсах и глобальном уровне. Строгая проверка обратного пути может отбрасывать пакеты при некоторых вариантах асимметричной маршрутизации. Отключать такую защиту без анализа причин не следует.
Метод с парой veth удобен для изучения маршрутизации, но создаёт дополнительный транзитный путь внутри Linux. Для сложной сетевой инфраструктуры обычно удобнее управлять обменом маршрутами через FRRouting и явно заданные политики.
4. Настройка VRF в FRRouting и динамический Route Leaking
FRRouting (FRR) предоставляет набор демонов маршрутизации для Linux. Программа поддерживает BGP, OSPF, статические маршруты и работу с несколькими VRF.
Существенное различие между Linux и FRRouting заключается в разделении обязанностей. Ядро Linux создаёт VRF-устройства и непосредственно пересылает пакеты, а FRRouting рассчитывает маршруты, применяет политики и передаёт записи в таблицы ядра.
Команда vrf внутри FRR сама по себе не создаёт Linux VRF-устройство. Для обычного Linux VRF backend сначала нужно создать соответствующую VRF средствами операционной системы.
Установка и подготовка FRRouting
На Debian и Ubuntu, где пакет доступен в подключённых репозиториях, FRRouting можно установить следующим образом.
sudo apt update
sudo apt install frr frr-pythontoolsНастройки запуска демонов обычно находятся в файле /etc/frr/daemons.
Для статических маршрутов используется staticd, для BGP нужен bgpd. Zebra управляет связью между FRR и ядром Linux. В штатных пакетных конфигурациях zebra обычно включена.
Проверьте, что конфигурация демонов содержит необходимые параметры.
zebra=yes
bgpd=yes
staticd=yesПосле изменения файла перезапустим службу.
sudo systemctl restart frr
sudo systemctl status frr
sudo vtysh -c "show version"
sudo vtysh -c "show vrf"Для дальнейших примеров используем созданные ранее Linux VRF vrf-red и vrf-blue с таблицами 100 и 200. Если хотите проверить BGP Route Leaking, начните с базовой лаборатории до добавления транзитной пары x-red и x-blue.
Добавляем статические маршруты через FRR
Откроем интерактивную консоль.
sudo vtyshВнутри FRRouting можно определить статический маршрут в контексте конкретной VRF.
configure terminal
vrf vrf-red
ip route 10.11.0.0/24 10.10.0.10
exit-vrf
end
write memoryМаршрут попадёт в таблицу vrf-red, если следующий узел доступен и FRR сможет установить запись в ядро. Для фактической связи сеть 10.11.0.0/24 должна существовать за 10.10.0.10, а промежуточный узел должен пересылать пакеты.
Проверка выполняется на двух уровнях.
show ip route vrf vrf-redВ обычной консоли Linux проверяем таблицу ядра.
ip route show table 100Если FRR показывает маршрут как выбранный, но таблица Linux не содержит соответствующей записи, проблема может заключаться в разрешении следующего узла, конфликтах с другими маршрутами или невозможности установить маршрут в ядро.
Создаём BGP для каждой VRF
Теперь настроим управляемый обмен маршрутами между RED и BLUE через BGP. Для такой лаборатории внешние BGP-соседи не нужны. FRRouting способен импортировать маршруты между локальными VRF через внутренние механизмы VPN RIB.
Удалите ранее созданный демонстрационный статический маршрут 10.11.0.0/24 либо оставьте его вне политики распространения. Для примера будем обмениваться только двумя непосредственно подключёнными подсетями.
Создадим списки префиксов, которые разрешено передавать через BGP.
configure terminal
ip prefix-list RED_NET seq 10 permit 10.10.0.0/24
ip prefix-list BLUE_NET seq 10 permit 10.20.0.0/24
route-map RED_ONLY permit 10
match ip address prefix-list RED_NET
exit
route-map BLUE_ONLY permit 10
match ip address prefix-list BLUE_NET
exitТеперь настроим два BGP-контекста.
router bgp 65000 vrf vrf-red
bgp router-id 10.10.0.1
address-family ipv4 unicast
redistribute connected route-map RED_ONLY
import vrf vrf-blue
import vrf route-map BLUE_ONLY
exit-address-family
exit
router bgp 65000 vrf vrf-blue
bgp router-id 10.20.0.1
address-family ipv4 unicast
redistribute connected route-map BLUE_ONLY
import vrf vrf-red
import vrf route-map RED_ONLY
exit-address-family
exit
end
write memoryКонфигурация содержит два независимых BGP-контекста с одним приватным номером автономной системы 65000. Маршруты 10.10.0.0/24 и 10.20.0.0/24 попадают в соответствующие таблицы BGP через redistribute connected.
Команда import vrf vrf-blue в красном контексте импортирует маршруты из синего. Для BLUE используется обратная команда.
Команды import vrf route-map ограничивают набор импортируемых префиксов. Так RED получает только разрешённую сеть BLUE, а BLUE только разрешённую сеть RED.
В FRRouting для этого механизма предусмотрен упрощённый синтаксис import vrf, при котором RD и Route Target формируются автоматически. Одновременно смешивать такой способ с явными import vpn и export vpn для тех же VRF нельзя.
По сравнению с ручными статическими маршрутами механизм позволяет распространять изменения таблиц маршрутизации через BGP и централизованно фильтровать импортируемые префиксы.
Проверяем маршруты в FRRouting
show vrf
show ip route vrf vrf-red
show ip route vrf vrf-blue
show bgp vrf vrf-red ipv4 unicast
show bgp vrf vrf-blue ipv4 unicast
show running-configВ таблице RED должен появиться импортированный BGP-маршрут к сети 10.20.0.0/24. В BLUE ожидается маршрут к 10.10.0.0/24.
Но наличие маршрута в BGP RIB не гарантирует успешную пересылку. Проверьте, установлены ли записи в таблицы ядра Linux.
ip route show table 100
ip route show table 200
ip route get vrf vrf-red 10.20.0.10
ip route get vrf vrf-blue 10.10.0.10Проверим доступность с тестовых компьютеров.
sudo ip netns exec host-red ping -c 3 10.20.0.10
sudo ip netns exec host-blue ping -c 3 10.10.0.10Если FRRouting импортировал маршрут, но пакеты не проходят, проверяйте установку в FIB, выбранный исходящий интерфейс, обратный маршрут, разрешение next-hop и правила межсетевого экрана. Разные версии ядра и конфигурации сетевого стека могут по-разному обрабатывать отдельные случаи меж-VRF-пересылки.
Для наглядной проверки можно включить временный перехват пакетов.
sudo tcpdump -ni r-uplink icmp
sudo tcpdump -ni b-uplink icmpЕсли ICMP-запрос виден на входе, но не появляется на нужном выходном интерфейсе, исследуйте таблицу пересылки и фильтрацию. Если запрос доходит до конечного компьютера, но ответ отсутствует, проверяйте обратный путь.
При этом перехват на самом VRF-устройстве не всегда показывает весь транзитный трафик. В Linux пакеты, которые ядро пересылает между интерфейсами, могут не проходить через VRF-устройство как через обычный сетевой интерфейс. Для диагностики транзитных соединений лучше захватывать пакеты на физических или виртуальных интерфейсах, где они действительно поступают и отправляются.
Когда нужны RD и Route Target
Упрощённая команда import vrf удобна для локальной лаборатории. В крупных сетях, особенно с MPLS L3VPN или EVPN, приходится управлять маршрутами разных клиентов и площадок.
Тогда используются два механизма.
Route Distinguisher (RD) делает VPN-маршрут уникальным в контексте соответствующего семейства маршрутов. Например, один и тот же IPv4-префикс 192.168.1.0/24 может существовать у двух клиентов, если соответствующие VPN-маршруты имеют разные RD.
Route Target (RT) определяет, какие маршруты разрешено импортировать или экспортировать между VPN-контекстами. RD не задаёт политику доступа, а RT сам по себе не фильтрует сетевые пакеты.
При расширении архитектуры важно различать распространение информации о маршрутах и реальный сетевой доступ. Даже корректно настроенные RD и RT не заменяют межсетевой экран.
5. Диагностика VRF, типичные ошибки и безопасность
Самая распространённая ошибка при настройке VRF заключается в проверке не той таблицы маршрутизации. Администратор видит правильный адрес на интерфейсе, запускает обычный ping и получает ошибку, потому что запрос ушёл через глобальную таблицу.
Вторая распространённая проблема возникает после Route Leaking. Маршрут к серверу появился, но соединение не работает из-за отсутствующего обратного маршрута, фильтрации или ошибочной установки next-hop.
Проверять сеть нужно последовательно, от интерфейса до прикладного сервиса.
| Симптом | Вероятная причина | Что проверить |
|---|---|---|
| VRF существует, но маршрутов нет | Интерфейс не привязан или выключен | show vrf interfaces, ip link show master |
| Ping до шлюза не проходит | VLAN, адресация, ARP, firewall или состояние линии | show interfaces, ip neigh, tcpdump |
| Связь работает из одной VRF, но не из другой | Команда запущена без VRF-контекста | ping vrf, ip vrf exec |
| Маршрут виден в BGP, но отсутствует в Linux | Ошибка установки в FIB или недоступный next-hop | show ip route vrf, ip route show table |
| Работает только одно направление | Нет обратного пути или пакет блокируется фильтром | Обе таблицы, ACL, nftables, rp_filter |
| Сервис не отвечает, хотя ping работает | Приложение не слушает в нужной VRF | ss -lntup, настройки сокетов |
| После переноса интерфейса пропал IP | Изменение VRF сбросило настройки интерфейса | Конфигурация адреса после привязки |
| Одинаковые адреса вызывают проблемы | Пересекающиеся префиксы при Route Leaking | План адресации, NAT, политика импорта |
Почему сервис может быть недоступен внутри Linux VRF
Linux VRF влияет не только на выбор маршрута, но и на обработку сетевых сокетов. Приложение может слушать порт в обычном сетевом контексте и при этом не принимать соединения, приходящие через интерфейс VRF.
Для управления поведением TCP и UDP существуют параметры ядра.
sysctl net.ipv4.tcp_l3mdev_accept
sysctl net.ipv4.udp_l3mdev_accept
sysctl net.ipv4.raw_l3mdev_acceptДля TCP и UDP параметры tcp_l3mdev_accept и udp_l3mdev_accept по умолчанию обычно выключены. Благодаря такому режиму приложение в глобальном сетевом контексте не начинает автоматически обслуживать подключения из всех VRF.
Можно изменить поведение, например разрешить TCP-сокетам принимать подключения из разных VRF.
sudo sysctl -w net.ipv4.tcp_l3mdev_accept=1Однако глобально включать параметр на производственном маршрутизаторе ради одного сервиса рискованно. Приложения с собственными VRF-привязанными сокетами и приложения с глобальными слушающими сокетами могут начать взаимодействовать неожиданным образом.
Предпочтительнее запускать нужные сетевые службы в соответствующем VRF-контексте или явно привязывать сокеты к VRF-устройству через SO_BINDTODEVICE.
При запуске через systemd для подходящих сервисов может применяться настройка NetworkNamespacePath либо привязка к VRF через отдельную схему запуска. Но network namespace и VRF не идентичны, поэтому переносить конфигурацию одной технологии на другую механически нельзя.
Как проверить безопасность изоляции
Создание отдельных таблиц маршрутизации снижает вероятность случайного обмена трафиком между сегментами. Но сама VRF не является полноценным межсетевым экраном.
После Route Leaking пакеты могут проходить между сетями по разрешённым маршрутам. Даже если маршруты импортированы выборочно, их наличие не означает, что доступ ограничен конкретным приложением.
Предположим, пользователю из RED нужен только HTTPS-сервис 10.20.0.10 на TCP-порту 443. Правильная архитектура предусматривает маршрут к серверу и отдельную политику межсетевого доступа, разрешающую только нужные соединения. Остальные подключения должны блокироваться.
Для маршрутизаторов Cisco такую фильтрацию реализуют ACL либо выделенный межсетевой экран. В Linux применяют nftables, при этом правила нужно проверять в реальном тракте пересылки пакетов, включая выбранные входные и выходные интерфейсы.
Другая опасность связана с чрезмерно широкими маршрутами. Например, импорт маршрута 0.0.0.0/0 из BLUE в RED может направить весь неразрешённый трафик красной сети через синий контекст. На практике подобная ошибка способна неожиданно открыть доступ к сторонним сетям или направить трафик через неверный шлюз.
Нельзя считать безопасной и конфигурацию, в которой импортированы все маршруты через redistribute connected без фильтров. При появлении новых интерфейсов или подсетей они могут попасть в другие VRF без дополнительного решения администратора.
Проверять результат полезно не только с помощью ping, но и реальными TCP-соединениями. Если сервер должен предоставлять HTTPS, убедитесь, что TCP-порт 443 доступен, а другие порты закрыты в соответствии с политикой.
Для Linux достаточно выполнить тест из соответствующего сетевого пространства имён, например с помощью curl.
sudo ip netns exec host-red curl -k --connect-timeout 3 https://10.20.0.10/Команда предполагает, что на 10.20.0.10 действительно запущен HTTPS-сервер. Параметр -k нужен только для лаборатории с самоподписанным сертификатом и отключает проверку его подлинности. В производственной среде использовать такой параметр не следует.
Как убрать настройки после лаборатории
На Cisco можно удалить Route Replication обратными командами no route-replicate, а затем удалить тестовые VRF после освобождения интерфейсов. При этом удаление VRF на рабочем устройстве может разорвать сетевые подключения.
Для Linux-лаборатории сначала остановите FRRouting, если он использовался исключительно для теста, либо удалите соответствующие записи из конфигурации FRR. Затем удалите созданные network namespace и VRF-устройства.
sudo ip netns del host-red
sudo ip netns del host-blue
sudo ip link del x-red 2>/dev/null || true
sudo ip link del r-uplink 2>/dev/null || true
sudo ip link del b-uplink 2>/dev/null || true
sudo ip link del vrf-red
sudo ip link del vrf-blueИнтерфейсы veth удаляются парами, поэтому удалять оба конца отдельно не требуется. Команды предполагают, что устройства созданы только для данной лаборатории.
Удаление VRF не всегда автоматически очищает все вручную добавленные политики маршрутизации и системные параметры. Если изменяли глобальные sysctl или создавали отдельные правила nftables, восстановите исходные значения. Для постоянной конфигурации интерфейсов используйте сетевой менеджер своей системы, например systemd-networkd или NetworkManager, вместо набора временных команд.
Частые вопросы о настройке VRF
Можно ли создать VRF без маршрутизатора Cisco?
Да. Linux поддерживает VRF средствами ядра и iproute2. Для управления динамическими маршрутами можно использовать FRRouting. Такая лаборатория работает на обычном Linux-сервере или виртуальной машине с необходимыми привилегиями и поддержкой ядра.
Чем команда ip vrf отличается от ip link add type vrf?
В Cisco IOS классическая команда ip vrf создаёт виртуальную таблицу маршрутизации. В Linux команда ip link add с параметром type vrf создаёт специальное сетевое устройство и связывает его с таблицей маршрутизации. Синтаксис и внутренняя реализация различаются.
Можно ли использовать один физический порт для нескольких VRF?
Да, через несколько логических интерфейсов, например VLAN-подинтерфейсов. Каждый такой интерфейс можно связать со своей VRF. Но отдельный интерфейс третьего уровня обычно принадлежит только одной VRF одновременно.
Нужен ли BGP для Route Leaking?
Не всегда. Cisco IOS XE поддерживает несколько способов меж-VRF-маршрутизации, включая Route Replication на совместимых платформах. В FRRouting динамический импорт удобно организовать через BGP. Для небольших лабораторий подходят статические маршруты и виртуальные транзитные соединения.
Можно ли использовать одинаковые IP-адреса в разных VRF?
Да. Отдельные VRF способны хранить одинаковые префиксы, потому что таблицы маршрутизации независимы. Проблемы возникают при попытке напрямую объединить такие сети. Для обмена трафиком между пересекающимися адресными пространствами часто требуется NAT или отдельный межсетевой шлюз.
Почему ping работает без VRF, но не работает через ip vrf exec?
Команды используют разные контексты маршрутизации. Обычный ping может выбрать маршрут из глобальной таблицы, тогда как ip vrf exec привязывает сетевые операции процесса к конкретной VRF. Нужно проверить маршруты выбранной таблицы, исходный адрес, сокеты, фильтрацию и наличие обратного пути.
Как сохранить VRF после перезагрузки Linux?
Команды iproute2 изменяют текущее состояние сети, но сами по себе не создают постоянную конфигурацию. Для сохранения VRF используйте поддерживаемый сетевой менеджер, например systemd-networkd или NetworkManager. FRRouting сохраняет собственные настройки маршрутизации отдельно, обычно в /etc/frr/frr.conf.
Почему маршрут есть в FRRouting, но отсутствует в таблице Linux?
Маршрут может быть выбран в управляющей таблице FRR, но не установлен в ядро из-за недоступного следующего узла, конфликта маршрутов, ограничений платформы или ошибки обработки меж-VRF-пути. Сравните show ip route vrf в FRRouting с ip route show table в Linux и проверьте выбранный next-hop.
Можно ли использовать VRF вместе с VLAN и VPN?
Да. VLAN разделяет канальный уровень, VRF обеспечивает независимые таблицы маршрутизации, а VPN может переносить трафик через внешнюю инфраструктуру. В корпоративных и операторских сетях технологии часто применяются совместно. VRF при этом не шифрует пакеты и не заменяет VPN-туннель.
Вывод. Начинать изучение VRF удобнее с лаборатории Linux. Две VRF, два network namespace и несколько команд iproute2 позволяют увидеть независимые таблицы маршрутизации и проверить реальную изоляцию трафика без дорогостоящего оборудования.
Если инфраструктура построена на Cisco IOS XE, достаточно освоить команды vrf definition, vrf forwarding, ip route vrf и диагностику через show ip route vrf. Для контролируемого обмена маршрутами можно использовать Route Replication там, где поддержка подтверждена для платформы.
В Linux-сетях с большим количеством маршрутов FRRouting даёт больше возможностей для динамического обмена и фильтрации префиксов. Но усложняет диагностику, поскольку приходится отдельно проверять маршруты FRR и таблицы ядра.
VRF хорошо подходит для разделения арендаторов, подразделений, служебных сетей и инфраструктуры управления. Однако разделение таблиц маршрутизации не равно полноценной защите. После добавления Route Leaking нужно отдельно контролировать доступ между сегментами, проверять обратные маршруты и не допускать случайного распространения слишком широких префиксов. Правильно настроенная VRF помогает сохранить границы сетей, но безопасность зависит от всей конфигурации маршрутизатора и межсетевых фильтров.
