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

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

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

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

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

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

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

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

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route
 Gateway of last resort is 212.192.128.177 to network 0.0.0.0
     212.192.129.0/24 is variably subnetted, 7 subnets, 3 masks
D       212.192.129.144/28           [90/28416] via 212.192.128.186, 7w0d, FastEthernet0/0.100
D       212.192.129.128/28           [90/28416] via 212.192.128.186, 7w0d, FastEthernet0/0.100
D       212.192.129.160/27           [90/28416] via 212.192.128.186, 7w0d, FastEthernet0/0.100
D       212.192.129.192/27           [90/28416] via 212.192.128.190, 7w0d, FastEthernet0/0.100
S       212.192.129.224/27 is directly connected, FastEthernet0/0.606
D       212.192.129.0/26           [90/28416] via 212.192.128.186, 7w0d, FastEthernet0/0.100
…

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

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

configure terminal
ip vrf MyRouter
 description VRF for nat from 10.0.0.0 to 55.55.55.55

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

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

interface fa0/0.10
encapsulation dot1q 10
ip vrf forwarding MyRouter
ip address 10.0.0.1 255.255.255.0
ip nat inside
interface fa0/0.55
encapsulation dot1q 55
ip vrf forwarding MyRouter
ip address 55.55.55.55 255.255.255.0
ip nat outside

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

show ip route vrf MyRouter

Вот её вывод:

Routing Table: MyRouter
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
     10.0.0.0/24 is subnetted, 1 subnets
C       10.0.0.0 is directly connected, FastEthernet0/0.10
     55.55.0.0/24 is subnetted, 1 subnets
C       55.55.55.0 is directly connected, FastEthernet0/0.55

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

ip route vrf MyRouter 0.0.0.0 0.0.0.0 55.55.55.56

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

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

ip dhcp excluded-address 10.0.0.1 10.0.0.10
!
ip dhcp pool MyDHCP
   vrf MyRouter
   network 10.0.0.0 255.255.255.0
   domain-name domain.ru
   dns-server 8.8.8.8
   default-router 10.0.0.1
!
access list 101 permit ip 10.0.0.0 0.0.0.255 any
ip nat inside source list 101 interface FastEthernet0/0.55 vrf MyRouter overload

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

Тэги: 

Комментарии

Спасибо, я понял в какой стороне звон, будем практиковать )

Здравствуйте, у меня есть вопрос касательно dns proxy внутри конкретного vrf. Команда ip dns server для vrf не работает. Можно ли заставить сам виртуальный роутер резолвить имена? НА физическом всё работает корректно.

С резолвом вроде разобрался. Теперь вопрос так стоит - можно ли обойтись без nat в vrf? Задача такая: через один виртуальный интерфейс нужно маршутизировать наверх большое количество виртуальных же интерфейсов с прибитыми к ними сетями локалки. NAT в таком случае накладывает большой оверхед, хотелось бы обойтись без него.

Для вашей внутренней VRF сети нужно прописать роут на следующем хопе. Он не знает куда слать адресованные ей пакеты и просто дропает их на интерфейсе Если сетей много - объединить их в одну суперсеть. А то будете для каждой подсети отдельный роут руками прописывать. :)

Нет, не разобрался. То что я принял за работающий dns - оказался эффект кэша циски. ПРоблема вот в чем: клиентский шлюз должен днс запросы на резолв перенаправлять в dns server. Но не перенаправляет. Проблема характерна только для vrf. При тех же настройках на физическом - всё работает. Может кто-нибудь знает как решить эту проблему? Отдавать клиентам адрес dns сервера через dhcp - в моем случае не вариант.

Добавить комментарий