Что такое vrf cisco

Описание, настройка и пример использования VRF на cisco

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

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

Чтобы было понятнее, приступим сразу к примеру.

Допустим, у нас есть большая сеть, где работает, скажем, EIGRP, и в этой сети есть маршрутизатор R1. Если мы зайдём на R1 и выполним там команду show ip route, то увидим большое количество маршрутов, пришедших со всех концов нашей сети. Теперь, предположим, что появился клиент, для которого надо сделать какие-то специфичные настройки. В первую очередь особую маршрутизацию, например, особый шлюз по умолчанию или ещё что-то, отдельный DHCP или отдельный NAT – тут то нам и приходит на помощь vrf.

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

Давайте перейдём к практике.

Посмотрим таблицу на нашем реальном маршрутизаторе:

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

Создаём виртуальный маршрутизатор:

Везде где можно написать description лучше его всегда писать.

Далее, выбираем, какие интерфейсы мы хотим отнести к этому vrf. В нашем примере у нас будет стоять задача брать трафик с интерфейса fa0/0.10 (ip 10.0.0.1), натить его и маршрутизировать через интерфейс fa0/0.55 (ip 55.55.55.55) так, чтобы это не влияло на остальные функции маршрутизатора.

Интерфейсы созданы (в данном случае это сабинтерфейсы для работы с VLAN, но это не важно – можно использовать и обычные физические интерфейсы). Для каждого интерфейса мы указали, что трафик должен обрабатываться не по общим правилам а в соответствии с правилами MyRouter. Интерфейсы выходят из сферы влияния основной маршрутизации. Так, например, если мы сейчас напишем команду show ip route, то среди непосредственно подключенных сетей (те что с буковкой «C» в таблице маршрутизации) мы не увидим сетей 10.0.0.0/24 и 55.55.55.0/24. Зато теперь мы можем посмотреть, как выглядит таблица маршрутизации нашего виртуального роутера, для этого набираем команду:

То есть, перед нами простая чистая таблица маршрутизации. Весь трафик, пришедший на fa0/0.10 и fa0/0.55 будет обрабатываться исходя только из одной этой таблицы – то есть общая таблица маршрутизации с кучей маршрутов приниматься во внимание не будет. Теперь вспомним CCNA и добавим статический маршрут по умолчанию, чтобы всё уходило в сеть через fa0/0.55, который у нас в примере будет внешним. При добавлении маршрута нам следует указать, что его надо добавить не в общую таблицу, а в vrf MyRouter:

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

Давайте добавим на наш виртуальный маршрутизатор DHCP и NAT. Пусть клиенты из внутренней сети получают адреса по DHCP а на выходе эти адреса транслируются в 55.55.55.55:

На этом настройка завершена. Обратите внимание, что как в DHCP пуле, так и в NAT-е мы указываем, что всё это относится не к основному, а к виртуальному маршрутизатору (vrf MyRouter).

Источник

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 трансляцию в приватные подсети.

Источник

Front-door VRF. Ещё один практический пример

Привет habr! Про настройку VPN совместно с VRF на оборудовании Cisco существует много статей в Интернете. Здесь есть неплохая шпаргалка по настройке IPsec VPN в виде крипто-карт и VTI-туннелей совместно с VRF. В этой статье хабра приведён пример DMVPN с VRF. VRF даёт большую гибкость при настройке оборудования и вариантов её использования большое количество. Главное не забывать, что у нас есть такой инструмент. В моей заметке я решил рассмотреть ещё одну интересную задачу из нашей практики, для решения которой также пригодилось использование Front-door VRF для построения IPsec туннелей. Речь пойдёт про построение параллельных VPN-туннелей через разных Интернет-провайдеров и распределение трафика по этим туннелям.

Технология Virtual Routing and Forwarding (VRF) позволяет разделить один физический маршрутизатор на несколько логических (виртуальных). Благодаря данной технологии появляется возможность иметь на одном физическом маршрутизаторе несколько независимых таблиц маршрутизации. Технология VRF получила широкое распространение в сетях MPLS. Однако, VRF можно использовать и без MPLS. В этом случае в терминологии Cisco технология получила название VRF lite. Если быть более точным, VRF-lite — это технология, позволяющая строить два или более VPN туннеля на одном VPN концентраторе, в среде, предполагающей пересекающиеся адресные пространства. В данной заметке пересечение адресных пространств затрагиваться не будет.

Очень кратко рассмотрим, что нам даёт использование VPN совместно с VRF. Защищаемая сеть, трафик которой подлежит шифрованию, может находиться не в глобальном VRF маршрутизатора. VRF защищаемой сети называется IVRF – Inside VRF. Однако, по умолчанию, маршрутизатор строит IPsec в глобальном VRF. Интернет-провайдеры могут быть подключены к интерфейсам маршрутизатора, которые также находятся не в глобальном VRF маршрутизатора. Такое подключение Интернет-провайдеров позволяет терминировать и утилизировать VPN туннели от удалённых точек одновременно на всех имеющихся Интернет-подключениях маршрутизатора.

В этом случае на маршрутизаторе в глобальном VRF присутствует единственный маршрут по умолчанию. Удалённый офис может строить параллельные VPN туннели до рассматриваемого маршрутизатора через все имеющиеся Интернет-каналы. Но ответный трафик от рассматриваемого маршрутизатора будет идти в соответствии с маршрутом по умолчанию через единственный Интернет-провайдер. Следовательно, ответным трафиком будет утилизироваться только тот Интернет-провайдер, на который указывает маршрут по умолчанию. Рассмотрим пример на основании IPsec VTI-туннелей:

Настройки туннельных интерфейсов маршрутизатора R1:

Настройки туннельных интерфейсов маршрутизатора R2:

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

VRF, к которым подключают каналы Интернет-провайдеров и в которых появляется туннелированный (в частности, зашифрованный) трафик, называют FVRF – Front-door VRF. При корректной настройке IPsec с VRF мы получаем связь между IVRF и FVRF средствами IPsec. Другими словами, защищаемый трафик поступает в IVRF, а после инкапсуляции в туннель автоматически оказывается в FVRF, в котором действуют другие правила маршрутизации. И это очень удобно.

Перехожу к описанию моего примера. Имеется распределённая сеть. В центральном офисе (далее ЦО) два Интернет-провайдера, каждый из которых подключён к собственному маршрутизатору Cisco. Первый Интернет-провайдер ISP1 используется для VPN до удалённых офисов, второй Интернет-провайдер ISP2 – для выхода в Интернет. Между маршрутизаторами ЦО настроен протокол резервирования первого перехода HSRP. В удалённых офисах два варианта граничного оборудования:

Между ЦО и удалёнными офисами маршруты передаются по EIGRP. При отказе ISP1 или маршрутизатора R1 весь трафик переходит на ISP2 и маршрутизатор R2. При отказе ISP2 или R2 выход в Интернет осуществляется через ISP1 и соответственно R1. Данная схема реализована за счёт EIGRP, HSRP и PBR. PBR используется для перенаправления трафика в Интернет через ISP2. PBR настроен с использованием трекинга работоспособности ISP2 (IP SLA PBR Object Tracking).

В ЦО подключается третий Интернет-провайдера ISP3 к маршрутизатору R1. Необходимо распределить трафик по туннелям через ISP1 и ISP3 маршрутизатора R1. Также, необходимо соблюсти некоторые требования отказоустойчивости по Интернет-провайдерам ЦО и маршрутизаторам ЦО. Расписывать все варианты отказа я не буду, упомяну только наиболее важное требование: провайдер ISP1, по которому бегает обычный трафик до удалённых офисов (зелёные туннели на схеме), должен оставаться по возможности не нагруженным. То есть, при отказе ISP2 выход в Интернет должен переходить на ISP3, а при отказе ISP3 трафик внедряемого сервиса (красные туннели на схеме) должен переходить на ISP2.

Схема сети с учётом нового канала (ISP3):

Краткое описание
Так как маршрутизатор R1 в нормальном режиме работы сети (когда все Интернет-провайдеры работоспособны) должен терминировать VPN IPsec туннели одновременно на обоих Интернет-провайдерах (ISP1 и ISP3), было принято решение вынести подключение к новому Интернет-провайдеру ISP3 в отдельный FVRF. При этом защищаемые (локальные) сети и подключение к первому Интернет-провайдеру было решено оставить в глобальном VRF.

После корректной настройки IPsec совместно с FVRF имеем параллельные работоспособные туннели через IPS1 и IPS3. Пример конфигурации IPSec c FVRF будет рассмотрен в следующем разделе. Теперь остаётся распределить потоки трафика по имеющимся туннелям. Для решения данной задачи можно выделить следующие подходы:

На маршрутизаторах ЦО настраиваем правило трансляции сетевых адресов dynamic policy NAT. Данное правило используем, чтобы изменять IP-адреса компьютеров ЦО на некоторый «особенный» IP-адрес, когда они обращаются к некоторым заранее известным серверам в удалённых офисах. Используем именно policy NAT, чтобы изменять IP-адреса клиентов только в случаях обращения к известным IP-адресам серверов. Далее, с помощью настройки EIGRP, раздаём в удалённые офисы «особенный» IP-адрес с лучшей метрикой через туннели ISP3, а для туннелей через ISP1, которые необходимо разгрузить, наоборот, завышаем метрику для «особенного» IP-адреса.

Таким образом, запрос от клиентов ЦО попадает на сервер в удалённом офисе с изменённым IP-адресом источника. В ответ сервер генерирует трафик на изменённый IP-адрес, а роутер в удалённом офисе маршрутизирует этот поток трафика в требуемый туннель. При этом на роутерах в удалённых офисах не требуется дополнительной настройки маршрутизации: управление маршрутами осуществляется посредством EIGRP из консоли маршрутизаторов ЦО. Ниже представлена схема прохождения запроса/ответа. Реальный IP-адрес клиента: 192.168.1.100. «Особенный» IP-адрес, в который происходит преобразование IP-адреса клиента: 10.10.10.10. IP-адрес сервера в удалённом офис: 172.16.1.100.

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

Представим схему, когда отказывает ISP1. В этом случае запросы начинают ходить через маршрутизатор R2 и туннели ISP2, и схема прохождения запроса/ответа приобретает следующий вид:

По схеме видно, для пакетов запросов трансляция IP-адреса источника выполняется на маршрутизаторе R2. Ответные пакеты приходят через туннели ISP3 на маршрутизатор R1. Однако, чтобы выполнить процедуру UNNAT и преобразовать IP-адрес получателя в реальный IP-адрес клиента, приходится отправлять пакеты обратно на маршрутизатор R2.

IP-адресация ЦО:

IP-адресация удалённого офиса типа 1 (VTI-туннели):

IP-адресация удалённого офиса типа 2 (GRE over IPsec туннели):

Схема сети:

Рассмотрим конфигурацию маршрутизатора R1. Сперва приведу пример настройки VPN-туннелей до удалённых офисов типа 1 (VTI-туннели) и типа 2 (GRE over IPsec туннели). На схеме и в конфигурации применяю следующие обозначения VPN-туннелей:

Настройка VTI-туннеля через провайдера ISP1 для связи с удалёнными офисами типа 1.

Настройка VTI-туннеля через провайдера ISP3 в новом VRF «ISP3-vrf» для связи с удалёнными офисами типа 1.

Настройка туннеля GRE over IPsec через провайдера ISP1 для связи с удалёнными офисами типа 2.

Настройка туннеля GRE over IPsec через провайдера ISP3 в новом VRF «ISP3-vrf» для связи с удалёнными офисами типа 2.

По приведённым примерам настраиваются VPN-туннели до всех удалённых офисов. Настройки VPN туннелей на маршрутизаторе R2 в ЦО и на маршрутизаторах и Cisco ASA в удалённых офисах рассматривать не буду в виду их тривиальности.

Теперь, когда готовы VPN-туннели до всех удалённых офисов, можно перейти к рассмотрению настроек маршрутизации. В сети используется EIGRP. Сперва необходимо настроить правила dynamic policy NAT для выделения клиентов внедряемой системы.

Данные настройки NAT приводят к преобразованию IP-адресов клиентов в «особенный» IP-адрес 10.10.10.10 при обращении к серверам в удалённых офисах.

Остаётся настроить EIGRP на маршрутизаторе в ЦО таким образом, чтобы сеть 10.10.10.10/32 анонсировался в удалённые офисы с лучшей метрикой через туннели провайдера ISP3. В нашем примере это Tunnel 11 и Tunnel 21. Для управления метрикой EIGRP я решил использовать конструкцию offset-list. Напомню, с помощью директивы offset-list можно прибавлять указанное значение к анонсируемой метрике маршрута. Настройки EIGRP:

Описанная конфигурация делает процедуру добавления новых серверов в удалённых офисах, трафик от которых нужно маршрутизировать через туннели нового провайдера ЦО ISP3, максимально простой. При появлении нового сервера достаточно внести его IP-адрес в группу объектов «System-Servers»:

На этом я завершаю рассмотрение конфигураций маршрутизатора R1 ЦО. Конфигурация маршрутизатора R2 в ЦО и конфигурации сетевых устройств в удалённых офисах не представляют интереса в рамках данной статьи.

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

На примере данной задачи я рассмотрел использование Front-door VRF для построения IPsec туннелей. Кроме того, я показал вариант централизации настроек маршрутизации для топологии «звезда» с использованием правил NAT. Front-door VRF для построения IPsec является удобным инструментом, позволяющим строить мост для передачи трафика между VRF маршрутизатора: защищаемый трафик может находиться в IVRF или глобальном VRF, а инкапсулированный (зашифрованный) трафик оказывается в FVRF. В FVRF работают собственные правила маршрутизации, благодаря чему появляется возможность отправлять трафик FVRF через дополнительные каналы связи, в частности, через дополнительного Интернет-провайдера.

Источник