Policy base маршрутизация

Недавно один человек спросил как можно сделать так, чтоб пользователи одного из VLAN на коммутаторе, получали доступ в интернет от одного провайдера, а пользователи другого VLAN от другого, при этом маршрутизатор с коммутатором соединены отдельным сегментом.

На коммутаторе есть три VLAN:
VLAN1 - 192.168.1.0/24 - Сеть компьютеров 1
VLAN2 - 192.168.2.0/24 - Сеть компьютеров 2
VLAN3 - 192.168.33.0/30 - Сеть маршрутизатора и коммутатора

Интерфейсы на коммутаторе:

VLAN1 - 192.168.1.1/24 он же шлюз для сети 1
VLAN2 - 192.168.2.1/24 он же шлюз для сети 2
VLAN3 - 192.168.33.2/30

И маршрут по умолчанию на маршрутизатор (192.168.33.1)

Интерфейсы и сети на маршрутизаторе:


interface GigabitEthernet0/1
 ip address 192.168.33.1 255.255.255.252
 ip nat inside
 ip policy route-map VLANWEB

подключен к порту коммутатора (на коммутаторе этот порт - порт доступа VLAN3)

И два субинтерфейса на интерфейсе GigabitEthernet0/0 - внешние интерфейсы (у меня не было дополнительных портов на маршрутизаторе, поэтому был сделан транк к коммутатору а там его разборка на два порта, ну и адреса на самом деле не внешние, так как у меня один канал. Он подключен к ASA5505 с двумя Inside интерфейсами - таким образом эмулируются два провайдера)


interface GigabitEthernet0/0.1
 encapsulation dot1Q 1 native
 ip address 172.16.4.112 255.255.255.0
 ip nat outside
 ip virtual-reassembly in

interface GigabitEthernet0/0.2
 encapsulation dot1Q 2
 ip address 192.168.55.210 255.255.255.0
 ip nat outside
 ip virtual-reassembly in

Чтоб маршрутизатор понимал где находятся сети с компьютерами, пропишем к ним статические (можно и динамические) маршруты:


ip route 192.168.1.0 255.255.255.0 192.168.33.2
ip route 192.168.2.0 255.255.255.0 192.168.33.2

Пожелание такое, если оба канала работают исправно, то, пусть пользователи сети 1 ходят в интернет через провайдера, подключенного к субинтерфейсу GigabitEthernet0/0.2.
А пользователи сети 2 ходят в интернет через провайдера, подключенного к субинтерфейсу GigabitEthernet0/0.1

А когда один канал стан недоступен, пусть ходят как получится.

Итак, для начала сделаем трекеры, следящие за состояние каналов:


ip sla 1
 icmp-echo 8.8.8.8 source-interface GigabitEthernet0/0.1
ip sla schedule 1 life forever start-time now

ip sla 2
 icmp-echo 8.8.8.8 source-interface GigabitEthernet0/0.2
ip sla schedule 2 life forever start-time now


track 123 ip sla 1 reachability

track 124 ip sla 2 reachability

Теперь, если прописать маршрут по умолчанию (с трекерами и запасным маршрутом, или без), как ни странно, пакеты, отправленные ip sla, интерфейс источник которой, не является сейчас приоритетным, будут уходить по маршруту по умолчанию, и все будет работать не правильно.
Тут варианта два - самый простой - пинговать шлюз для этого интерфейса, но тогда, если шлюз виден а дальше ничего не работает, мы об этом не узнаем.
Вариант второй - делаем route-map и задаем next hop:


ip access-list extended ISP1_SLA
 permit icmp host 172.16.4.112 any

ip access-list extended ISP2_SLA
 permit icmp host 192.168.55.210 any


route-map RMAP_SLA permit 10
 match ip address ISP2_SLA
 set ip next-hop 192.168.55.1

route-map RMAP_SLA permit 20
 match ip address ISP1_SLA
 set ip next-hop 172.16.4.1

ip local policy route-map RMAP_SLA

Теперь нам нужен route-map для задания next hop для пакетов от компьютеров.
Там мы прописываем - set ip next-hop verify-availability -с разными приоритетами, тот что более приоритетный, для случая когда оба канала работают.


ip access-list extended VLAN1ACL
 permit ip 192.168.1.0 0.0.0.255 any

ip access-list extended VLAN2ACL
 permit ip 192.168.2.0 0.0.0.255 any


route-map VLANWEB permit 10
 match ip address VLAN1ACL
 set ip next-hop verify-availability 192.168.55.1 10 track 124
 set ip next-hop verify-availability 172.16.4.1 20 track 123

route-map VLANWEB permit 20
 match ip address VLAN2ACL
 set ip next-hop verify-availability 172.16.4.1 10 track 123
 set ip next-hop verify-availability 192.168.55.1 20 track 124

Не забываем повесить этот route-map на интерфейс, смотрящий на коммутатор с нашими клиентскими VLAN

interface GigabitEthernet0/1
 ip policy route-map VLANWEB

Теперь еще нужно, чтоб работал NAT (точнее, в нашем случае PAT) на обоих интерфейсах.
Для этого требуется опять же route-map:


ip access-list extended NATACL
 permit ip 192.168.1.0 0.0.0.255 any
 permit ip 192.168.2.0 0.0.0.255 any



route-map NATR1 permit 10
 match ip address NATACL
 match interface GigabitEthernet0/0.1

route-map NATR2 permit 10
 match ip address NATACL
 match interface GigabitEthernet0/0.2



ip nat inside source route-map NATR1 interface GigabitEthernet0/0.1 overload
ip nat inside source route-map NATR2 interface GigabitEthernet0/0.2 overload

По желанию можно сделать статические маршруты по умолчанию с нужным приоритетом,
например так:


ip route 0.0.0.0 0.0.0.0 172.16.4.1 20 track 123
ip route 0.0.0.0 0.0.0.0 192.168.55.1 10 track 124

Ну и теперь, все должно работать - но есть одна проблема, сессий NAT, пока не истекут по таймауту, так и будут висеть, и пользователи могут испытывать неудобства.
Чтобы такого не было, требуется очистить трансляции NAT.
Тут нам поможет механизм обработки событий:


event manager applet ISPSW
 event track 123 state any
 action 1 cli command "enable"
 action 2 cli command "clear ip nat trans forced"

event manager applet ISPSW2
 event track 124 state any
 action 1 cli command "enable"
 action 2 cli command "clear ip nat trans forced"


Тут все в принципе очевидно, при изменении состояния треков, выполняются консольные команды enable и затем clear ip nat trans forced.

Вроде бы ничего не забыл.
Еще рекомендую уменьшить таймаут между посылками ICMP в SLA, иначе долго переключение происходит.

Комментарии

Популярные сообщения из этого блога

DHCP опция 121 - статические маршруты по DHCP

Сброс на заводские настройки, коммутатора Moxa EDS-518A