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, иначе долго переключение происходит.
На коммутаторе есть три 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, иначе долго переключение происходит.
Комментарии
Отправить комментарий