Pull to refresh

Немного об ip sla / rtr в Cisco…

Cisco *
Прочитал две статьи «Dual ISP на маршрутизаторах cisco без BGP» и «Одновременное использование двух провайдеров на маршрутизаторах cisco». На ум пришла мысль попробовать нарисовать и описать решение к ещё одной, немного нестандартной задаче.
Итак, рассмотрим простой пример. Есть клиент и имеется два провайдера (аплинка). Автономной системы для построения 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: Многие комментарии которые можно было бы вставить опущены, так как подразумевается, что предварительно были прочтены указанные выше две статьи, а, следовательно, читатель знает о чём идёт речь.
Tags:
Hubs:
Total votes 2: ↑2 and ↓0 +2
Views 45K
Comments Comments 4