Описание:

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

• Порты GigabitEthernet0/0 и GigabitEthernet0/1 задействованы для подключения ISP.
• Порты GigabitEthernet0/0/0 и GigabitEthernet0/0/1 сконфигурированы в TRUNK и подключены к коммутаторам.
• Для работы с локальной сетью используются VLAN интерфейсы.
• В данной схеме предусматривается три локальных IP сети 192.168.100.0/24 для VLAN 100, 192.168.101.0/24 VLAN 101 и 192.168.102.0/24 VLAN 102.
• В данном примере VLAN 100 и 101 будут иметь связь между собой но 101 будет без доступа к Интернету, а VLAN 102 будет иметь выход только в интернет.

Так задумано что бы показать возможности импорта/экспорта между VRF.

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

interface GigabitEthernet0/0/0 description TRUNK=>sw-access-1 switchport mode trunk no ip address end interface GigabitEthernet0/0/1 description TRUNK=>sw-access-2 switchport mode trunk no ip address end

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

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

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

ip vrf isp1
 description ISP1
 rd 65000:1
 route-target export 65000:1
 route-target import 65000:100
 route-target import 65000:102

ip vrf isp2
 description ISP2
 rd 65000:2
 route-target export 65000:2
 route-target import 65000:100
 route-target import 65000:102

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

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

ip vrf 100
 description VLAN_Desktop
 rd 65000:100
 route-target export 65000:100
 route-target import 65000:1
 route-target import 65000:2
 route-target import 65000:101

ip vrf 101
 description VLAN_Voice
 rd 65000:101
 route-target export 65000:101
 route-target import 65000:100

ip vrf 102
 description VLAN_Wireless
 rd 65000:102
 route-target export 65000:102
 route-target import 65000:1
 route-target import 65000:2

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

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

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

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

WAN

interface GigabitEthernet0/0
 description ISP1
  ip vrf forwarding isp1
  ip address 198.51.100.1 255.255.255.252
  ip nat outside

interface GigabitEthernet0/1
 description ISP2
  ip vrf forwarding isp2
  ip address 203.0.113.1 255.255.255.252
  ip nat outside

LAN

interface Vlan100
 description VLAN_Desktop
 ip vrf forwarding 100
 ip address 192.168.100.254 255.255.255.0
 ip nat inside

interface Vlan101
 description VLAN_Voice
 ip vrf forwarding 101
 ip address 192.168.101.254 255.255.255.0
 ip nat inside

interface Vlan102
 description VLAN_Wireless
 ip vrf forwarding 102
 ip address 192.168.102.254 255.255.255.0
 ip nat inside

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

router bgp 65000
bgp log-neighbor-changes
 
address-family ipv4 vrf 100
 redistribute connected
 maximum-paths 2
 exit-address-family
 
address-family ipv4 vrf 101
 redistribute connected
 exit-address-family
 
address-family ipv4 vrf 102
 redistribute connected
 maximum-paths 2
 exit-address-family
 
address-family ipv4 vrf isp1
 redistribute connected
 redistribute static route-map BGP_Filter
 default-information originate
 exit-address-family
 
address-family ipv4 vrf isp2
 redistribute connected
 redistribute static route-map BGP_Filter
 default-information originate
 exit-address-family

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

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

show ip route vrf 100

B*    0.0.0.0/0 [20/0] via 203.0.112.2 (isp2), 0d01h
                [20/0] via 198.51.100.2 (isp1), 0d01h

Маршрутизаторы 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.

ip route vrf isp1 0.0.0.0 0.0.0.0 198.51.100.2 tag 100 track 100
ip route vrf isp2 0.0.0.0 0.0.0.0 203.0.112.2 tag 100 track 200

• tag — поможет нам отфильтровать для передачи в локальные VRF только эти маршруты
• track — указывает какой объект отвечает за работоспособность маршрута

route-map BGP_Filter permit 10
 description Fix BGP static redistribution
 match tag 100

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

ip route vrf isp1 8.8.8.8 255.255.255.255 198.51.100.2
ip route vrf isp1 80.80.80.80 255.255.255.255 198.51.100.2
ip route vrf isp2 8.8.8.8 255.255.255.255 203.0.112.2
ip route vrf isp2 80.80.80.80 255.255.255.255 203.0.112.2

Отдельные маршруты к хостам 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

route-map isp1 permit 10
 match interface GigabitEthernet0/0
 
route-map isp2 permit 10
 match interface GigabitEthernet0/1

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

ip nat inside source route-map isp1 interface GigabitEthernet0/0 vrf 100 overload
ip nat inside source route-map isp2 interface GigabitEthernet0/1 vrf 100 overload
ip nat inside source route-map isp1 interface GigabitEthernet0/0 vrf 102 overload
ip nat inside source route-map isp2 interface GigabitEthernet0/1 vrf 102 overload

Настройка SLA

ip sla auto discovery

ip sla 10
 icmp-echo 198.51.100.2
 vrf isp1
 frequency 5
ip sla schedule 10 life forever start-time now

ip sla 11
 icmp-echo 8.8.8.8
 vrf isp1
 frequency 5
ip sla schedule 11 life forever start-time now

ip sla 12
 icmp-echo 80.80.80.80
 vrf isp1
 frequency 5
ip sla schedule 12 life forever start-time now


ip sla 20
 icmp-echo 203.0.112.2
 vrf isp2
 frequency 5
ip sla schedule 20 life forever start-time now

ip sla 21
 icmp-echo 8.8.8.8
 vrf isp2
 frequency 5
ip sla schedule 21 life forever start-time now

ip sla 22
 icmp-echo 80.80.80.80
 vrf isp2
 frequency 5
ip sla schedule 22 life forever start-time now

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

Настройка track

track 100 list boolean and
 object 101
 object 110
 
track 101 ip sla 10 reachability
 delay down 20 up 180
 
track 102 ip sla 11 reachability
 delay down 20 up 180
 
track 103 ip sla 12 reachability
 delay down 20 up 180
 
track 110 list boolean or
 object 102
 object 103
 
track 200 list boolean and
 object 201
 object 210
 
track 201 ip sla 20 reachability
 delay down 20 up 180
 
track 202 ip sla 21 reachability
 delay down 20 up 180
 
track 203 ip sla 22 reachability
 delay down 20 up 180
 
track 210 list boolean or
 object 202
 object 203
 
track 1000 stub-object

Логика работы:

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

• Если track 100 в состоянии UP то маршрут в таблице есть.
• Объект 100 это boolean and, что означает, что UP он будет считаться если все его объекты в состоянии UP.
• Если любой из объектов 100 DOWN то весть объект 100 будет DOWN.
• Он содержит объекты 101 и 110.
• Объект 101 соответствует SLA 10 — проверяет шлюз провайдера.
• Объект 110 объединяет 102 и 103 как boolean or, что означает, что он будет UP если хотя бы один из его объектов UP.
• Объекты 102 и 103 проверяют 8.8.8.8 и 80.80.80.80 соответственно, их нужно два для исключения ложных срабатываний.

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

track 1000

track 1000 stub-object
 default-state down

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

Настройка EEM

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

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

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

event manager applet CLEANNAT-100
 event track 100 state down
 action 10 cli command "enable"
 action 20 cli command "clean ip nat translation *"
event manager applet CLEANNAT-200
 event track 200 state down
 action 10 cli command "enable"
 action 20 cli command "clean ip nat translation *"

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

tips and tricks

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

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

ntp server vrf isp1 132.163.4.103

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

ping vrf isp1 8.8.8.8

Будьте внимательны.

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

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

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

P.S>

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

ip access-list extended NO_NAT
deny ip any 192.168.0.0 0.0.255.255 
deny ip any 172.16.0.0 0.15.255.255 
deny ip any 10.0.0.0 0.255.255.255 
permit ip any any

route-map isp1 permit 10
 match ip address NO_NAT
 match interface GigabitEthernet0/0