Прочитал две статьи «Dual ISP на маршрутизаторах cisco без BGP» и «Одновременное использование двух провайдеров на маршрутизаторах cisco». На ум пришла мысль попробовать нарисовать и описать решение к ещё одной, немного нестандартной задаче.
Итак, рассмотрим простой пример. Есть клиент и имеется два провайдера (аплинка). Автономной системы для построения BGP-peer'ов у нас нет, а работать, при падении одного каналов как-то надо. При этом у нас есть внутренний клиент нашей сети который работает не как все, а с точностью до наоборот. В нормальной (оба канала работают) этот клиент всё-равно ходит через резервный канал (Dialer1), в то время как все работают по основному (Dialer0) и переключается он на основной канал только в том случае если резервный(!) падает (бывает и такое).
Одно из возможных решений (так сказать «в лоб») может выглядеть так:
Да, такая конструкция работает, но есть один недостаток, причём достаточно не очевидный.
Может наблюдаться такая ситуация, что и статус и протокол могут находиться в состоянии Up, а канал может не работать. Тогда эта конструкция ничем не поможет.
Что-же делать? Всё очень просто: использовать возможности sla.
Что нам для этого надо? Просто надо переписать route-map tracking и написать правила для sla.
Собственно всё банально просто. ;)
route-map перестаёт отрабатывать для пакета свои правила после того как обнаружит первое-же совпадение. Поэтому, собственно, порядок определения сиквенсов важен!
Теперь если мы взглянем на состояние интерфейсов то увидим:
При этом видим, что и статус и протокол Dialer1 находятся в состоянии up, т.е. первый вариант route-map tracking не сработал бы и клиент 192.168.0.101 просто не работал бы. Но если мы взглянем на статистику по route-map tracking из второго варианта то увидим:
Состояние в ip next-hop verify-availability 195.5.5.208 10 обозначено как down, а соответственно эти маршруты установлены не будут.
ps: Многие комментарии которые можно было бы вставить опущены, так как подразумевается, что предварительно были прочтены указанные выше две статьи, а, следовательно, читатель знает о чём идёт речь.
Итак, рассмотрим простой пример. Есть клиент и имеется два провайдера (аплинка). Автономной системы для построения BGP-peer'ов у нас нет, а работать, при падении одного каналов как-то надо. При этом у нас есть внутренний клиент нашей сети который работает не как все, а с точностью до наоборот. В нормальной (оба канала работают) этот клиент всё-равно ходит через резервный канал (Dialer1), в то время как все работают по основному (Dialer0) и переключается он на основной канал только в том случае если резервный(!) падает (бывает и такое).
Одно из возможных решений (так сказать «в лоб») может выглядеть так:
interface Vlan1 ip address 192.168.0.1 255.255.255.0 ip policy route-map tracking ! route-map tracking permit 10 match ip address 1 set default interface Dialer1 Dialer0 ! route-map tracking permit 20 match ip address 2 set default interface Dialer0 Dialer1 ! access-list 1 permit 192.168.0.101 access-list 2 deny 192.168.0.101 access-list 2 permit 192.168.0.0 0.0.0.255
Да, такая конструкция работает, но есть один недостаток, причём достаточно не очевидный.
Может наблюдаться такая ситуация, что и статус и протокол могут находиться в состоянии Up, а канал может не работать. Тогда эта конструкция ничем не поможет.
Что-же делать? Всё очень просто: использовать возможности sla.
Что нам для этого надо? Просто надо переписать route-map tracking и написать правила для sla.
interface Vlan1 ip address 192.168.0.1 255.255.255.0 ip policy route-map tracking ! track 123 rtr 1 reachability ! track 124 rtr 2 reachability ! ip sla 1 icmp-echo 195.5.5.208 source-interface Dialer1 timeout 2000 threshold 2 frequency 3 ip sla schedule 1 life forever start-time now ip sla 2 icmp-echo 193.34.140.1 source-interface Dialer0 timeout 2000 threshold 2 frequency 3 ip sla schedule 2 life forever start-time now ! route-map tracking permit 100 match ip address 1 set ip next-hop verify-availability 195.5.5.208 10 track 123 set ip next-hop verify-availability 193.34.140.1 20 track 124 ! route-map tracking permit 120 match ip address 2 set ip next-hop verify-availability 193.34.140.1 10 track 124 set ip next-hop verify-availability 195.5.5.208 20 track 123 ! route-map tracking permit 200 set ip next-hop verify-availability 195.5.5.208 10 track 123 set ip next-hop verify-availability 193.34.140.1 20 track 124 ! access-list 1 permit 192.168.0.101 access-list 2 deny 192.168.0.101 access-list 2 permit 192.168.0.0 0.0.0.255
Собственно всё банально просто. ;)
route-map перестаёт отрабатывать для пакета свои правила после того как обнаружит первое-же совпадение. Поэтому, собственно, порядок определения сиквенсов важен!
Теперь если мы взглянем на состояние интерфейсов то увидим:
#sh ip int br | i ^Dialer Dialer0 193.34.141.151 YES IPCP up up Dialer1 unassigned YES IPCP up up
При этом видим, что и статус и протокол Dialer1 находятся в состоянии up, т.е. первый вариант route-map tracking не сработал бы и клиент 192.168.0.101 просто не работал бы. Но если мы взглянем на статистику по route-map tracking из второго варианта то увидим:
#sh route-map tracking
route-map tracking, permit, sequence 100
Match clauses:
ip address (access-lists): 1
Set clauses:
ip next-hop verify-availability 195.5.5.208 10 track 123 [down]
ip next-hop verify-availability 193.34.140.1 20 track 124 [up]
Policy routing matches: 711 packets, 95929 bytes
route-map tracking, permit, sequence 120
Match clauses:
ip address (access-lists): 2
Set clauses:
ip next-hop verify-availability 193.34.140.1 10 track 124 [up]
ip next-hop verify-availability 195.5.5.208 20 track 123 [down]
Policy routing matches: 216 packets, 14100 bytes
route-map tracking, permit, sequence 200
Match clauses:
Set clauses:
ip next-hop verify-availability 195.5.5.208 10 track 123 [down]
ip next-hop verify-availability 193.34.140.1 20 track 124 [up]
Policy routing matches: 0 packets, 0 bytesСостояние в ip next-hop verify-availability 195.5.5.208 10 обозначено как down, а соответственно эти маршруты установлены не будут.
ps: Многие комментарии которые можно было бы вставить опущены, так как подразумевается, что предварительно были прочтены указанные выше две статьи, а, следовательно, читатель знает о чём идёт речь.
