vrf маршрутизация что это

VRF Lite for fun and profit

Технология Virtual Routing and Forwarding (VRF) нашла широкое применение в сетях MPLS. В таких сетях метки MPLS применяются для разграничения трафика различных пользователей, а VRF поддерживает таблицу маршрутизации для каждого из них. Для обмена маршрутной информацией в таких сетях применяется MP-BGP.

Но существует возможность использовать технологию VRF без MPLS — VRF Lite.

VRF Lite

Рассмотрим топологию, изображенную на первом рисунке. Предположим, к маршрутизатору R1 подключены четыре сети. Необходимо разграничить взаимодействие между сетями так, чтобы первая имела связь со второй, третья с четвертой, но между первой и третьей, первой и четвертой, второй и третьей, второй и четвертой связи не было. Одним из возможных решений будет применение списков доступа (ACL). Второй путь — разделить сети с помощью VRF. Ниже приведена конфигурация, позволяющая это сделать.

!включаем маршрутизацию
ip routing

!включаем Cisco Express Forwarding, необходимый для работы VRF
ip cef

!объявляем два VRF с именами ONE и TWO
ip vrf ONE
!указываем route-distinguisher
rd 65000:1

ip vrf TWO
rd 65000:2

interface FastEthernet 0/0
!указываем, что интерфейс относится к тому или иному VRF
!это необходимо сделать до указания IP адреса
!так как команда ip vrf forwarding удаляет адрес с интерфейса
ip vrf forwarding ONE
ip address 10.0.1.1 255.255.255.0
no shutdown

interface FastEthernet 0/1
ip vrf forwarding ONE
ip address 10.0.2.1 255.255.255.0
no shutdown

interface FastEthernet 1/0
ip vrf forwarding TWO
ip address 10.0.3.1 255.255.255.0
no shutdown

interface FastEthernet 1/1
ip vrf forwarding TWO
ip address 10.0.4.1 255.255.255.0
no shutdown

Теперь можно посмотреть, что у нас получилось:

Интерфейсы маршрутизатора и их сопоставление с VRF.

R1#show ip interface brief

Interface IP-Address OK? Method Status Protocol

FastEthernet0/0 10.0.1.1 YES manual up up

FastEthernet0/1 10.0.2.1 YES manual up up

FastEthernet1/0 10.0.3.1 YES manual up up

FastEthernet1/1 10.0.4.1 YES manual up up

Name Default RD Interfaces

Таблицы маршрутизации глобальная и для каждого VRF

Gateway of last resort is not set

R1#show ip route vrf ONE

Gateway of last resort is not set

10.0.0.0/24 is subnetted, 2 subnets

C 10.0.2.0 is directly connected, FastEthernet0/1

C 10.0.1.0 is directly connected, FastEthernet0/0

R1#show ip route vrf TWO

Gateway of last resort is not set

10.0.0.0/24 is subnetted, 2 subnets

C 10.0.3.0 is directly connected, FastEthernet1/0

C 10.0.4.0 is directly connected, FastEthernet1/1

Проверим связь между сетями:

R1#ping vrf ONE 10.0.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.1.1, timeout is 2 seconds:
.
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

R1#ping vrf ONE 10.0.2.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.2.1, timeout is 2 seconds:
.
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

R1#ping vrf ONE 10.0.3.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.3.1, timeout is 2 seconds:
.
Success rate is 0 percent (0/5)

R1#ping vrf ONE 10.0.4.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.4.1, timeout is 2 seconds:
.
Success rate is 0 percent (0/5)

R1#ping vrf TWO 10.0.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.1.1, timeout is 2 seconds:
.
Success rate is 0 percent (0/5)

R1#ping vrf TWO 10.0.2.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.2.1, timeout is 2 seconds:
.
Success rate is 0 percent (0/5)

R1#ping vrf TWO 10.0.3.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.3.1, timeout is 2 seconds:
.
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms

R1#ping vrf TWO 10.0.4.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.4.1, timeout is 2 seconds:
.
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

Для того, чтобы посмотреть arp таблицу отдельного VRF используйте команду

show ip arp vrf NAME

Кроме того, чтобы установить telnet подключение из определенного VRF необходимо выполнить следующую команду:

telnet HOST /vrf NAME

где HOST — узел, к которому устанавливается подключение, NAME — имя VRF.

Как видно, цель достигнута и сети связаны именно так, как надо.

Динамическая маршрутизация в рамках VRF

Рассмотрим топологию на рисунке 2. Задача сводится к организации динамической маршрутизации в каждом из VRF. Пусть в первом это будет протокол OSPF, во втором — EIGRP. Конфигурация маршрутизатора R1 тогда будет выглядеть следующим образом:

router ospf 1 vrf ONE
network 10.0.1.0 0.0.0.255 area 0
network 10.0.2.0 0.0.0.255 area 0

Видно, что достаточно указать, в каком VRF должен работать процесс OSPF, чтобы все заработало.

router eigrp 100
no auto-summary
address-family ipv4 vrf TWO
network 10.0.3.0 0.0.0.255
network 10.0.4.0 0.0.0.255
no auto-summary
autonomous-system 100
exit-address-family

С EIGRP все немного сложнее, но тоже интуитивно понятно.

Для маршрутизаторов R1 и R2 конфигурации выглядят следующим образом:

router ospf 1
log-adjacency-changes
network 10.0.1.0 0.0.0.255 area 0
network 172.16.1.0 0.0.0.255 area 2
!network 172.16.2.0 0.0.0.255 area 1 для R2

Для маршрутизаторов R3 и R4:

router eigrp 100
network 10.0.3.0 0.0.0.255
network 172.16.3.0 0.0.0.255
!network 172.16.4.0 0.0.0.255 для R4
no auto-summary

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

R1#show ip route vrf ONE

Gateway of last resort is not set

172.16.0.0/24 is subnetted, 2 subnets

O IA 172.16.1.0 [110/2] via 10.0.1.2, 00:38:58, FastEthernet0/0

O IA 172.16.2.0 [110/2] via 10.0.2.2, 00:39:00, FastEthernet0/1

10.0.0.0/24 is subnetted, 2 subnets

C 10.0.2.0 is directly connected, FastEthernet0/1

C 10.0.1.0 is directly connected, FastEthernet0/0

R1#show ip route vrf TWO

Gateway of last resort is not set

172.16.0.0/24 is subnetted, 2 subnets

D 172.16.4.0 [90/30720] via 10.0.4.2, 00:17:37, FastEthernet1/1

D 172.16.3.0 [90/30720] via 10.0.3.2, 00:17:50, FastEthernet1/0

10.0.0.0/24 is subnetted, 2 subnets

C 10.0.3.0 is directly connected, FastEthernet1/0

C 10.0.4.0 is directly connected, FastEthernet1/1

Gateway of last resort is not set

172.16.0.0/24 is subnetted, 2 subnets

C 172.16.1.0 is directly connected, FastEthernet0/1

O IA 172.16.2.0 [110/3] via 10.0.1.1, 00:39:37, FastEthernet0/0

10.0.0.0/24 is subnetted, 2 subnets

O 10.0.2.0 [110/2] via 10.0.1.1, 00:39:37, FastEthernet0/0

C 10.0.1.0 is directly connected, FastEthernet0/0

Gateway of last resort is not set

172.16.0.0/24 is subnetted, 2 subnets

D 172.16.4.0 [90/33280] via 10.0.3.1, 00:18:40, FastEthernet0/0

C 172.16.3.0 is directly connected, FastEthernet0/1

10.0.0.0/24 is subnetted, 2 subnets

C 10.0.3.0 is directly connected, FastEthernet0/0

D 10.0.4.0 [90/30720] via 10.0.3.1, 00:18:52, FastEthernet0/0

Заключение

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

Источник

Два провайдера одновременно или Dual ISP with VRF на Cisco | Part 2

Добрый день! На написание этого материала меня вдохновил HunterXXI в своей статье Два провайдера одновременно или Dual ISP with VRF на Cisco. Я заинтересовался, изучил вопрос и применил на практике. Хотел бы поделится своим опытом в реализации Dual ISP на Cisco с реальным использованием одновременно двух ISP и, даже, балансировкой нагрузки.

Демо схема:

Описание:

Все действия выполняются на Cisco 1921 IOS Version 15.5(3)M3 с установленным модулем EHWIC-4ESG.

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

Конфигурация VRF

Технология Cisco Express Forwarding (CEF) — должна быть включена для работы VRF.

Настройка VRF для ISP

Обратите внимание, что в конфигурации нет импорта 65000:101 который будет закреплен за VLAN 101. Таким образом виртуальные маршрутизаторы isp1 и isp2 не будут иметь маршрутов в сеть 192.168.101.0/24

Настройка VRF для VLAN

Снова обратите внимание на VRF 101, который не обменивается маршрутами c ISP но обменивается с VRF 100.

На своём опыте я убедился, что название VRF для ISP удобно использовать как isp1 и isp2, название VRF для VLAN должно соответствовать номеру VLAN, всё что идентифицирует VRF — description. Это связано с тем, что если, например, у Вас поменяется один из провайдеров то вся реконфигурация сведется к изменению IP адреса интерфейса и description-а.

Конфигурация интерфейсов

Применять команду ip vrf forwarding на интерфейсе нужно до назначения IP адреса. В противном случае IP адрес будет удалён и его придётся назначать заново.

Конфигурация BGP

Каждый из BGP address-family настраивается отдельно для VRF и перераспределяет подключенные маршруты (redistribute connected). У нас будет два маршрута по умолчанию, один через VRF isp1 и второй через isp2. Параметр maximum-paths 2 позволит импортировать в VRF 100 и 102 оба маршрута по умолчанию.

Это будет выглядеть так:

Маршрутизаторы Cisco автоматически балансируют трафик по маршрутам в одном направлении с одинаковой стоимостью.

В VRF isp1 и isp2 необходимо, помимо redistribute connected, разрешить redistribute static и default-information originate, что позволит передать шлюз по умолчанию в другие VRF. Вы можете заметить, что redistribute static делается через route-map BGP_Filter. Это происходит исключительно из соображений эстетического вида таблиц маршрутизации VRF определенных в локальную сеть, что бы маршруты к 8.8.8.8 и 80.80.80.80 не попадали в таблицы маршрутизации VRF 100 и 102.

Настройка маршрутизации

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

Используя этот route-map и применяя его в VRF для ISP перераспределяться будут только маршруты с тэгом, а остальные останутся только внутри ISP VRF.

Отдельные маршруты к хостам 8.8.8.8 и 80.80.80.80 необходимы для того, что когда сработает track и отключит шлюз по умолчанию у нас осталась возможность совершать проверку доступности этих адресов. Так как мы не присваиваем им тэг они не будут подпадать под route-map и перераспределяться.

Настройка NAT

Для работы NAT необходимо обозначить inside, outside интерфейсы. В качестве outside мы определяем интерфейсы в которые подключены ISP, командой ip nat outside. Все остальные интерфейсы, которые относятся к LAN обозначаем как inside командой ip nat inside.

Необходимо создать два route-map-а в которых определяются интерфейсы isp1 и isp2

Правила NAT необходимо указывать для каждого VRF через каждый ISP. Так как в нашем условии Vlan 101 не имеет доступа к сети Интернет то правила для него указывать нет необходимости, а даже если их указать — работать не будет, потому что нет маршрутизации.

У Cisco есть много разновидностей NAT. В терминологии Cisco, то что мы используем называется Dynamic NAT with Overload или PAT.

Что нужно для того что бы NAT работал?

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

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

Правило которое мы применяем в нашей конфигурации уже не так очевидно. Как мы помним, route-map isp1 определяет интерфейс GigabitEthernet0/0. Перефразируя команду получается нечто подобное

Получается нужно транслировать трафик source которого GigabitEthernet0/0?

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

Ошибочно можно подумать, что можно делать route-map LAN match interface Vlan100. Применять этот как ip nat inside source route-map LAN и т.д.

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

Настройка SLA

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

Настройка track

В таблице маршрутизации есть маршрут ip route vrf isp1 0.0.0.0 0.0.0.0 198.51.100.2 tag 100 track 100 который завязан на track 100.

track 1000

Этот объект умолчанию имеет состояние DOWN.
В данной конфигурации этот объект необходим для того, что бы принудительно отключить одного из ISP и не подключать его. Для этого track 1000 нужно добавить в объект 100 или 200. Исходя из boolean and, если один из объектов DOWN то весь объект считается DOWN.

Настройка EEM

EEM — Embedded Event Manager позволяет автоматизировать действия в соответствии с определенными событиями.

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

Для того, что бы ускорить этот процесс нам необходимо очистить таблицу NAT командой clear ip nat translation * и лучше всего сделать это автоматически.

Если объекты 100 или 200 перейдут в состояние DOWN то будут выполнены команды action по порядку.

tips and tricks

Хочу отметить ещё несколько особенностей работы с VRF.

Например конфигурация NTP:

Из-за использования VRF любые сетевые операции нужно относить к виртуальному маршрутизатору, это связано с тем, что когда Вы настроите эту конфигурацию и выполните show ip route вы не увидите ни одной записи в таблице маршрутизации.

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

К недостаткам, и это вопрос к уважаемой публике, когда отваливается один из ISP то команда clear ip nat translations * обрывает все соединения, включительно с работающим ISP. Как показала практика, в тех случаях когда отваливается провайдер — пользователи не замечают этот «обрыв» или он не является критичным.

Если кто-то знает как очищать таблицу трансляций частично — буду благодарен.

Не забудьте запретить NAT трансляцию в приватные подсети.

Источник

Настройка резервных интернет-провайдеров в луче DMVPN с помощью функции VRF-Lite

Параметры загрузки

Об этом переводе

Этот документ был переведен Cisco с помощью машинного перевода, при ограниченном участии переводчика, чтобы сделать материалы и ресурсы поддержки доступными пользователям на их родном языке. Обратите внимание: даже лучший машинный перевод не может быть настолько точным и правильным, как перевод, выполненный профессиональным переводчиком. Компания Cisco Systems, Inc. не несет ответственности за точность этих переводов и рекомендует обращаться к английской версии документа (ссылка предоставлена) для уточнения.

Содержание

Введение

В этом документе описывается настройка резервного интернет-провайдера в луче Dynamic Multipoint VPN (DMVPN) с помощью функции Virtual Routing and Forwarding-Lite (VRF-Lite).

Предварительные условия

Требования

Перед выполнением описанной в этом документе настройки компания Cisco рекомендует ознакомиться со следующими темами:

Используемые компоненты

Сведения в этом документе основываются на Cisco IOS® Version 15.4 (2) T.

Сведения, представленные в этом документе, были получены от устройств, работающих в специальной лабораторной среде. Все устройства, описанные в этом документе, были запущены с чистой (стандартной) конфигурацией. В рабочей сети необходимо изучить потенциальное воздействие всех команд до их использования.

Общие сведения

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

Использование услуг двух интернет-провайдеров с целью резервирования стало общей практикой. Администраторы используют два канала поставщика услуг Интернета; один из них является основным подключением, а другой — резервным.

Такой же принцип может быть реализован для резервирования DMVPN на конечном маршрутизаторе с использованием двух поставщиков услуг Интернета. Этот документ призван продемонстрировать, как можно разделить таблицу маршрутизации с помощью VRF-Lite, когда конечный маршрутизатор подключен к двум поставщикам услуг Интернета. Для того чтобы обеспечить резервирование пути для трафика, проходящего через туннель DMVPN, используется динамическая маршрутизация. В примерах конфигурации, которые описаны в этом документе, используется следующая схема конфигурации:

Функция VRF-Lite позволяет реализовать на конечном маршрутизаторе DMVPN несколько экземпляров VPN маршрутизации/перенаправления. Функция VRF-Lite принуждает трафик из нескольких интерфейсов туннеля Multipoint Generic Routing Encapsulation (mGRE) использовать соответствующие им таблицы маршрутизации VRF. Например, если основной поставщик услуг Интернета оканчивается в ISP1 VRF, а дополнительный поставщик услуг Интернета оканчивается в ISP2 VRF, трафик, формируемый в ISP2 VRF, будет использовать таблицу маршрутизации ISP2 VRF, а трафик, формируемый в ISP1 VRF, будет использовать таблицу маршрутизации ISP1 VRF.

Преимущество, которое дает использование наружной функции VRF (fVRF), главным образом заключается в возможности образования отдельной таблицы маршрутизации из глобальной таблицы маршрутизации (в которой имеются интерфейсы туннелей). Использование внутренней функции VRF (iVRF) позволяет определить частное пространство для хранения информации о DMVPN и частной сети. Обе эти конфигурации обеспечивают дополнительную защиту от атак на маршрутизатор из Интернета, где сведения о маршрутизации разделяются.

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

Если оба поставщика услуг Интернета оканчиваются в глобальной VRF, они будут использовать одну таблицу маршрутизации, а работа обоих интерфейсов mGRE будет основана на глобальной информации о маршрутизации. В этом варианте в случае отказа основного поставщика услуг Интернета интерфейс основного поставщика услуг Интернета может сохранить работоспособность, если точка отказа находится в магистральной сети поставщика услуг Интернета, а не подключена к этому интерфейсу напрямую. При этом возникает ситуация, когда оба интерфейса туннелей MGRE продолжают использовать маршрут по умолчанию, который указывает на основного поставщика услуг Интернета, из-за чего происходит сбой резервирования DMVPN.

Хотя существуют некоторые обходные пути для устранения этой проблемы без использования VRF-Lite, основанные на скриптах IP Service Level Agreements (IP SLA) или Embedded Event Manager (EEM), они далеко не всегда являются лучшим выбором.

Методы развертывания

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

Раздельное туннелирование

Когда сведения об определенных подсетях или итоговых маршрутах поступают через интерфейс mGRE, это называется разделенным туннелированием. Если сведения о маршруте по умолчанию поступают через интерфейс mGRE, то это называется tunnel-all.

В примере конфигурации, предоставленном в этом документе, показано разделенное туннелирование.

Туннели между конечными маршрутизаторами

Приведенный в этом документе пример конфигурации является хорошим вариантом для метода развертывания (когда информация о маршруте по умолчанию поступает через интерфейс mGRE).

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

Настройка

В этом разделе описывается процедура настройки резервирования поставщиков услуг Интернета на конечном маршрутизаторе DMVPN посредством функции VRF-Lite.

Примечание.Воспользуйтесь инструментом Command Lookup ( только для зарегистрированных заказчиков), чтобы получить дополнительную информацию о командах, используемых в этом разделе.

Схема сети

Именно эта топология используется в примерах, приведенных в этом документе:

Настройка концентратора

Вот некоторые замечания о соответствующей конфигурации на концентраторе:

Примечание. В этот пример включены только соответствующие разделы конфигурации.

Настройка конечного маршрутизатора

Вот некоторые замечания о соответствующей конфигурации на конечном маршрутизаторе:

Примечание. В этот пример включены только соответствующие разделы конфигурации.

Проверка

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

Основной и дополнительный поставщики услуг Интернета активны

В этом варианте проверки и основной и дополнительный поставщики услуг Интернета активны. Вот некоторые дополнительные примечания об этом варианте:

Далее приведены соответствующие команды show, с помощью которых можно проверить свою конфигурацию в этом варианте:

Основной поставщик услуг Интернета не работает / дополнительный поставщик услуг Интернета активен

В этом варианте время таймеров EIGRP Hold заканчивается для отношений соседства через Tunnel0, когда канал ISP1 выходит из строя, а маршруты к концентратору и другим конечным маршрутизаторам теперь указывают на Tunnel1 (реализованный с помощью Ethernet0/1).

Далее приведены соответствующие команды show, с помощью которых можно проверить свою конфигурацию в этом варианте:

Восстановление канала основного поставщика услуг Интернета

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

Устранение неполадок

Для поиска и устранения неполадок с конфигурацией включите debug ip eigrp и logging dmvpn.

Источник

Маршрутизация в Linux: VRF Lite

Типы маршрутов, таблицы маршрутизации и PBR в Linux

Прежде чем понять суть происходящего, познакомимся с некоторыми отличительными чертами сетевого стека Linux.

Первый отличительный момент — это специальные типы маршрутов. Когда ip-пакет приходит с какого-нибудь интерфейса, надо определить, адресован ли он этому хосту, или другому. Определяется это довольно элегантно — просто для адреса назначения ищется нужный маршрут в таблицах маршрутизации. Если пакет попадает на маршрут типа «local», значит он адресован непосредственно хосту, если нет, то значит его надо маршрутизировать дальше (при этом дальнейший маршрут уже известен) или сделать что-то ещё, в зависимости от типа маршрутов.

Имена таблиц хранятся в файле /etc/iproute2/rt_tables. Под номер таблицы отдано 32 бита, но максимальное количество таблиц в данный момент жёстко ограничено числом 256. Как добавлять/удалять/редактировать маршруты можно почитать в мане к ip-route.

Таблица, в которой надо искать маршруты, определяется политиками маршрутизации. Эта технология называется Policy Based Routing — маршрутизация на основе политик. Суть её в том, что основываясь на каких-либо критериях сетевого пакета мы либо выбираем таблицу, в которой надо искать маршрут, либо определяем действие, которое надо выполнить над пакетом. Каждая политика имеет номер (он может быть даже не уникальным), он же определяем приоритет. Просмотр политик осуществляется в порядке возрастания их приоритетов. Новые политики добавляются перед существующими.

Запираем маршруты в таблицу

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

Допустим, у нас есть вот такая схема:

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

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

Сначала назначаем интерфейсам адреса. При этом подключенные маршруты будут попадать в таблицу main, а локальные и широковещательные — в таблицу local.

Добавляем для удобства имена таблиц маршрутизации.

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

Добавляем остальные маршруты.

Есть один нюанс: что будет, если пакет одного цвета не находит маршрута в своей таблице? Значит, будет продолжен поиск маршрута в других таблицах, что для нас не очень хорошо. Чтобы «запереть» пакет в пределах своего цвета, мы можем в каждую изолированную таблицу добавить маршрут по-умолчанию (либо юникастовый, либо запрещающий), либо после каждой политики поиска маршрута в пределах цвета добавить запрещающую политику. Сделаем для одного цвета первый вариант, а для другого — второй.

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

В итоге, наши таблицы маршрутизации и политики будут выглядеть примерно так:

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

На этом пока всё, но продолжение следует. В нём постараюсь рассказать про динамическую маршрутизацию применительно к vrf с помощью демона маршрутизации bird, и обмен маршрутами между таблицами (vrf leaking).

Источник

• анудеск что это за программа →