Немного об ip sla / rtr в 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: Многие комментарии которые можно было бы вставить опущены, так как подразумевается, что предварительно были прочтены указанные выше две статьи, а, следовательно, читатель знает о чём идёт речь.
    • +2
    • 38.5k
    • 4
    Share post

    Similar posts

    Comments 4

      0
      тоже вариант ;)
        0
        Хорошее дополнение про

        default interface

        и про 2 ip next-hop

        В одной статейке нет возможности описать все. Дополнения — это хорошо.
          0
          Полезно. Раньше не обращал внимания что track можно использовать внутри route-map`а.
            0
            У меня вопрос… раз уж мы начали использовать RTR tracking, то зачем мы еще начинаем ip sla использовать???

            Не проще все решить через RTR, применительно к примеру так:

            rtr 1
            type echo protocol ipIcmpEcho 195.5.5.208
            rtr schedule 1 life forever start-time now

            rtr2
            type echo protocol ipIcmpEcho 193.34.140.1
            rtr schedule 1 life forever start-time now

            Only users with full accounts can post comments. Log in, please.