Резервирование Интернет-каналов без использования BGP

Материал из Xgu.ru

Перейти к: навигация, поиск
Автор: Наташа Самойленко
Короткий URL: 2 ISP без BGP


На этой странице описывается как настроить резервирование провайдеров без использования BGP.

При решении этой проблемы иногда возникает ряд проблем. Как правило, они связаны с небольшими нюансами. Без которых, однако, решение не работает корректно.

Для решения задачи резервирования провайдеров без BGP, требуется взаимодействие большого количества технологий и функций. Тут описаны кратко это технологии, а так же как их использовать для решения этой задачи.

Note-icon.gif

Ранее на этой странице были лабораторные. Они перенесены на страницу Резервирование Интернет-каналов без использования BGP/Lab.

Эта же информация обзорно описана в презентации

Содержание

[править] Общее описание

Для настройки резервирования требуется совмещение нескольких технологий:

В зависимости от того, какая схема работы требуется, могут понадобиться также и другие технологии:

Icon-caution.gif

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

[править] Один пограничный маршрутизатор с двумя каналами к разным провайдерам. Без балансировки нагрузки

Dual isp 1.png

Краткое описание используемых технологий и задач, которые они решают:

  • IP SLA — IP SLA тесты будут мониторить несколько ресурсов в Интернет.
  • Local PBR — политика PBR для тестов IP SLA. Политика будет отправлять пакеты, которые генерирует тест, на определенного провайдера
  • Track — следит за соответствующим тестом IP SLA, а суммарный track объединяет их в один объект
  • Статическая маршрутизация — к маршруту по умолчанию на основного провайдера надо применить суммарный трек. На резервного провайдера настроить маршрут по умолчанию со значением AD, большим чем 1
  • NAT — правила динамической трансляции, с использованием route-map
  • EEM — сценарий EEM будет автоматически очищать таблицу трансляции, после переключения между провайдерами

[править] IP SLA

IP SLA позволяет создавать тесты.

Один из самых простых примеров теста: проверка доступности ресурса с помощью простого “ping” (отправки ICMP-запроса и ожидания ICMP-ответа).

IP SLA нужен для того чтобы была возможность проверить ходит ли трафик через провайдера. И, если трафик не ходит, в ответ, выполнять переключение на резервного провайдера.

Note-icon.gif

  • IP SLA, за время существования, сменил несколько вариантов настройки. Поэтому, настройка в другой версии IOS может отличаться от указанной.
  • Мониторить лучше стабильные ресурсы.
  • В тесте обязательно надо указывать IP-адрес отправителя или интерфейс.

Параметры теста:

  • Threshold – устанавливает верхнее пороговое значение для измерения RTT (round-trip time)
  • Timeout – период времени, который IOS ожидает ответ на пакеты теста
  • Frequency – частота отправки тестовых пакетов

Настройка IP SLA тестов (icmp-echo) 

ip sla 1
 icmp-echo 8.8.8.8 source-interface Gi0/1
 threshold 1000
 timeout 1500
 frequency 3
ip sla schedule 1 life forever start-time now
ip sla 2
 icmp-echo 8.8.4.4 source-interface Gi0/1
 threshold 1000
 timeout 1500
 frequency 3
ip sla schedule 2 life forever start-time now
ip sla 3
 icmp-echo 4.4.4.4 source-interface Gi0/1
 threshold 1000
 timeout 1500
 frequency 3
ip sla schedule 3 life forever start-time now

[править] Проверка IP SLA

Проверить состояние тестов в кратком отображении: 

R1#sh ip sla summary 

IPSLAs Latest Operation Summary
ID  Type       Destination      Stats   Return   Last
                                (ms)    Code     Run
----------- ---------- ---------------  ------ --------------- 
*1  icmp-echo  8.8.8.8          RTT=1    OK      1 second ago
*2  icmp-echo  8.8.4.4          RTT=1    OK      2 seconds ago
*3  icmp-echo  4.4.4.4          RTT=1    OK      1 second ago

Посмотреть более развернутую статистику по тесту: 

R1#sh ip sla statistics 1
IPSLAs Latest Operation Statistics

IPSLA operation id: 1
        Latest RTT: 1 milliseconds
Latest operation start time: 10:22:19 UTC Wed Feb 18 2015
Latest operation return code: OK
Number of successes: 741
Number of failures: 0
Operation time to live: Forever

[править] Настройка Local PBR

Маршрутизация на основе политик (policy based routing, PBR):

  • позволяет маршрутизировать трафик на основании заданных политик, тогда как в обычной маршрутизации, только IP-адрес получателя определяет каким образом будет передан пакет
  • основной объект с помощью которого настраивается PBR: route-map
  • PBR может применяться, как для сквозного трафика, так и для трафика, который генерируется маршрутизатором.

Настройка Local PBR нужна для того, чтобы, при переключении провайдера, пакеты теста IP SLA шли через основного провайдера. Соответственно, в ACL, который использует route-map, должен быть описан трафик тестов IP SLA.

Настройка Local PBR: 

ip access-list extended SLA_ACL
 permit icmp host 70.1.1.1 host 8.8.8.8
 permit icmp host 70.1.1.1 host 8.8.4.4
 permit icmp host 70.1.1.1 host 4.4.4.4

route-map PBR_SLA permit 10
 match ip address SLA_ACL
 set ip next-hop 70.1.1.100

ip local policy route-map PBR_SLA

[править] Проверка работы PBR

Просмотр ACL: 

R1#sh access-lists SLA_ACL
Extended IP access list SLA_ACL
 10 permit icmp host 70.1.1.1 host 8.8.8.8 (17 matches)
 20 permit icmp host 70.1.1.1 host 8.8.4.4 (16 matches)
 30 permit icmp host 70.1.1.1 host 4.4.4.4 (17 matches)

Если PBR работает, то счетчики должны быть ненулевыми: 

R1#sh route-map PBR_SLA
route-map PBR_SLA, permit, sequence 10
  Match clauses:
    ip address (access-lists): SLA_ACL 
  Set clauses:
    ip next-hop 70.1.1.100
  Policy routing matches: 29 packets, 1856 bytes

Второй вариант проверки. Тут также видно явно, что route-map применена: 

R1#sh ip local policy 
Local policy routing is enabled, using route map PBR_SLA
route-map PBR_SLA, permit, sequence 10
  Match clauses:
    ip address (access-lists): SLA_ACL 
  Set clauses:
    ip next-hop 70.1.1.100
  Policy routing matches: 199 packets, 12736 bytes

[править] Настройка Track

Enhanced Object Tracking (track) — это функция оборудования Cisco, которая позволяет отслеживать состояние выбранного объекта и влиять на состояние других функций.

IP SLA не может быть напрямую применен к другим объектам. Для того чтобы маршрут по умолчанию зависел от результатов теста, нужно создать track, которые отслеживает состояние IP SLA и, в зависимости от ответа, переходит в состояние UP или DOWN.

Каждый track (10,20,30) отслеживает свой тест IP SLA: 

track 10 ip sla 1 reachability
track 20 ip sla 2 reachability
track 30 ip sla 3 reachability

Суммарный track настраивается для того, чтобы причиной переключения не было состояние одного объекта. Для каждого теста IP SLA есть свой track, которые потом объединяются в один суммарный.

Суммарный track 100 объединяет созданные track. Настройка “boolean or” обозначает, что суммарный track будет в состоянии UP, если хотя бы один из track в состоянии UP: 

track 100 list boolean or
 object 10
 object 20
 object 30
 delay down 10 up 5

Параметр “delay” в настройке track 100 нужен для того, чтобы track переходил в состояние DOWN с задержкой. Иначе, как только пропадет хотя бы один пакет ICMP, track перейдет в состояние DOWN.

Параметр delay настраивается в соответствии с частотой отправки ICMP-запросов.

В нашем примере, частота 3 секунды, а задержка на переход в состояние DOWN 10 секунд. То есть, track 100 перейдет в состояние DOWN только если все тесты перестали получать ответы. И не получили, как минимум 3 ответа.

Аналогично с переходом в состояние UP.

[править] Проверка работы track 

R1#sh track
Track 10
  IP SLA 1 reachability
  Reachability is Up
    3 changes, last change 4d20h
  Latest operation return code: OK
  Latest RTT (millisecs) 1
  Tracked by:
    Track-list 100
...
Track 100
  List boolean or
  Boolean OR is Up
    4 changes, last change 4d20h
    object 10 Up
    object 20 Up
    object 30 Up
  Delay up 10 secs, down 5 secs
  Tracked by:

[править] Настройка статических маршрутов

Статический маршрут остается в таблице маршрутизации до тех пор, пока маршрутизатор может найти путь к next-hop. Но, если проблема находится внутри сети провайдера, или за ее пределами, с помощью обычного статического маршрута её обнаружить нельзя.

Для того чтобы решить эту проблему, настроенные ранее IP SLA тесты, через суммарный track, применяются к статическому маршруту по умолчанию.

Применение суммарного track к маршруту по умолчанию, который ведет к основному провайдеру: 

ip route 0.0.0.0 0.0.0.0 70.1.1.100 track 100

Маршрут по умолчанию к резервному провайдеру с AD 250: 

ip route 0.0.0.0 0.0.0.0 80.1.1.100 250

[править] Проверка настройки статических маршрутов

Просмотр таблицы маршрутизации с параметром track-table позволяет просмотреть маршруты, к которым применен track: 

R1#sh ip route track-table 
 ip route 0.0.0.0 0.0.0.0 70.1.1.100 track 100 state is [up]

Состояние суммарного track: 

R1#sh track 100             
Track 100
  List boolean or
  Boolean OR is Up
    4 changes, last change 4d20h
    object 10 Up
    object 20 Up
    object 30 Up
  Delay up 5 secs, down 5 secs
  Tracked by:
    STATIC-IP-ROUTING 0

[править] Настройка NAT

Если на маршрутизаторе Cisco созданы два правила для динамической трансляции, он выбирает правило в порядке создания. К сожалению, не учитывается то, через какой интерфейс маршрутизируется пакет.

Поэтому, когда на маршрутизаторе два outside интерфейса, правила трансляции необходимо настраивать с route-map: 

interface GigabitEthernet0/0
 ip nat inside
!
interface GigabitEthernet0/1
 ip nat outside
!
interface GigabitEthernet0/2
 ip nat outside
!
ip access-list standard LAN
 permit 10.1.1.0 0.0.0.255 
!
route-map ISP_1 permit 10
 match ip address LAN
 match interface GigabitEthernet0/1
!
route-map ISP_2 permit 10
 match ip address LAN
 match interface GigabitEthernet0/2
!
ip nat inside source route-map ISP_1 interface Gi0/1 overload
ip nat inside source route-map ISP_2 interface Gi0/2 overload

При переключении между провайдерами, возникает проблема с подвисшими сессиями (как правило, TCP). Для её решения используется EEM. EEM автоматически очищает таблицу трансляций, после каждого переключения.

Note-icon.gif

Обратите внимание, что route-map могут использоваться в разных областях. Например:

  • как фильтры маршрутов
  • для настройки PBR
  • для настройки политик BGP
  • для NAT

Смысл команд внутри route-map, в зависимости от области применения, может меняться. Поэтому, при чтении документации, нужно обращать внимание на то, к каком контексте используется route-map.

В этом контексте, route-map чем-то похожи на ACL. ACL также, в зависимости от области применения, может выполнять разные действия.

Подробнее....

[править] Проверка работы NAT 

R1#sh ip nat statistics 
Total active translations: 0 (0 static, 0 dynamic; 0 extended)
Peak translations: 92, occurred 5d20h ago
Outside interfaces:
  GigabitEthernet0/1, GigabitEthernet0/2
Inside interfaces: 
  GigabitEthernet0/0
Hits: 822  Misses: 0
CEF Translated packets: 85, CEF Punted packets: 397
Expired translations: 142
Dynamic mappings:
-- Inside Source
[Id: 3] route-map ISP_1 interface GigabitEthernet0/1 refcount 0
[Id: 4] route-map ISP_2 interface GigabitEthernet0/2 refcount 0

Total doors: 0
Appl doors: 0
Normal doors: 0
Queued Packets: 0

R1#sh ip nat translations

[править] Настройка EEM

Embedded Event Manager:

  • Функционал встроенный в Cisco IOS, который позволяет создавать сценарии для автоматизации работы устройств.
  • Причиной для выполнения сценария является событие.
    • Например, событием может быть изменение состояния track, запуск сценария вручную, выполнение команды и другие.
  • Сам сценарий может состоять из перечня команд, которые нужно выполнить; генерации syslog-сообщения и других действий.

Каждый сценарий EEM срабатывает на смену состояния суммарного track. После обнаружения смены состояния, сценарий выполняет очистку таблицы трансляций и генерирует log-сообщение. Если эту очистку не выполнять, сессии TCP останутся в подвисшем состоянии. 

event manager applet ISP_1_UP 
 event track 100 state up
 action 001 cli command "enable"
 action 002 cli command "clear ip nat trans *"
 action 003 syslog msg "ISP 1 is UP"

event manager applet ISP_1_DOWN 
 event track 100 state down
 action 001 cli command "enable"
 action 002 cli command "clear ip nat trans *"
 action 003 syslog msg "ISP 1 is DOWN"

[править] Проверка работы EEM 

R1#sh event manager policy registered 
No. Class  Type Event Trap Time Registered          Name
1   applet user track Off  Fri Feb 13 14:09:29 2015 ISP_1_DOWN
 track 200 state down
 maxrun 20.000
 action 001 cli command "enable"
 action 002 cli command "clear ip nat translation *"
 action 003 syslog msg "ISP 1 is DOWN"

2   applet user track Off  Fri Feb 13 14:11:08 2015 ISP_1_UP
 track 200 state up
 maxrun 20.000
 action 001 cli command "enable"
 action 002 cli command "clear ip nat translation *"
 action 003 syslog msg "ISP 1 is UP"


router1#sh track 100
Track 100
  List boolean or
  Boolean OR is Up
    4 changes, last change 4d20h
    object 10 Up
    object 20 Up
    object 30 Up
  Delay up 5 secs, down 5 secs
  Tracked by:
    STATIC-IP-ROUTING 0
    EEM applet ISP_1_DOWN 
    EEM applet ISP_1_DOWN

[править] Итоговая конфигурация R1


[править] Один пограничный маршрутизатор с двумя каналами к разным провайдерам. С балансировкой нагрузки

Dual isp 1.png

Краткое описание используемых технологий и задач, которые они решают:

  • NAT — правила динамической трансляции, с использованием route-map
  • EEM — сценарий EEM будет автоматически очищать таблицу трансляции, после переключения между провайдерами
  • IP SLA — IP SLA тесты будут мониторить несколько ресурсов в Интернет. Так как, по умолчанию, будут использоваться оба провайдера, то тесты должны быть настроены для каждого их них
  • Local PBR — политика PBR для тестов IP SLA. Политика будет отправлять пакеты, которые генерирует тест, на определенного провайдера
  • Track — следит за соответствующим тестом IP SLA, а суммарный track объединяет их в один объект
  • Балансировка нагрузки:
    • Статическая маршрутизация — к каждому провайдеру прописан статический маршрут по умолчанию, и к каждому из них применен суммарный трек
    • PBR
    • Пропорциональная балансировка с помощью статических маршрутов


Icon-caution.gif

Основное описание технологий и настроек находится в разделе с описанием схемы с одним пограничным маршрутизатором и без балансировки нагрузки (в первом разделе).

Настройки, которые потребуются для этой схемы подключения, описаны в соответствующих разделах, но с учетом того, что основная часть описана в первой части. Поэтому, стоит начать с прочтения первого раздела, даже если используется другая схема.

[править] Настройка NAT

Настройки NAT аналогичны: 

interface GigabitEthernet0/0
 ip nat inside
!
interface GigabitEthernet0/1
 ip nat outside
!
interface GigabitEthernet0/2
 ip nat outside
!
ip access-list standard LAN
 permit 10.1.1.0 0.0.0.255 any
!
route-map ISP_1 permit 10
 match ip address LAN
 match interface GigabitEthernet0/1
!
route-map ISP_2 permit 10
 match ip address LAN
 match interface GigabitEthernet0/2
!
ip nat inside source route-map ISP_1 interface Gi0/1 overload
ip nat inside source route-map ISP_2 interface Gi0/2 overload

[править] Настройка EEM

Настройки EEM: 

event manager applet ISP_1_UP 
 event track 100 state up
 action 001 cli command "enable"
 action 002 cli command "clear ip nat trans *"
 action 003 syslog msg "ISP 1 is UP"

event manager applet ISP_1_DOWN 
 event track 100 state down
 action 001 cli command "enable"
 action 002 cli command "clear ip nat trans *"
 action 003 syslog msg "ISP 1 is DOWN"

[править] IP SLA

IP SLA тесты для разных провайдеров могут быть разные, или одни и те же.

В этом примере тесты разные.

Настройка IP SLA тестов (icmp-echo) для ISP 1: 

ip sla 1
 icmp-echo 8.8.8.8 source-interface Gi0/1
 threshold 1000
 timeout 1500
 frequency 3
ip sla schedule 1 life forever start-time now
ip sla 2
 icmp-echo 8.8.4.4 source-interface Gi0/1
 threshold 1000
 timeout 1500
 frequency 3
ip sla schedule 2 life forever start-time now
ip sla 3
 icmp-echo 4.4.4.4 source-interface Gi0/1
 threshold 1000
 timeout 1500
 frequency 3
ip sla schedule 3 life forever start-time now

Настройка IP SLA тестов (icmp-echo) для ISP 2: 

ip sla 11
 icmp-echo 4.2.2.2 source-interface Gi0/2
 threshold 1000
 timeout 1500
 frequency 3
ip sla schedule 11 life forever start-time now
ip sla 12
 icmp-echo 4.2.2.3 source-interface Gi0/2
 threshold 1000
 timeout 1500
 frequency 3
ip sla schedule 12 life forever start-time now
ip sla 13
 icmp-echo 4.2.2.4 source-interface Gi0/2
 threshold 1000
 timeout 1500
 frequency 3
ip sla schedule 13 life forever start-time now

[править] Настройка Local PBR

Настройка Local PBR для тестов на ISP1: 

ip access-list extended SLA1_ACL
 permit icmp host 70.1.1.1 host 8.8.8.8
 permit icmp host 70.1.1.1 host 8.8.4.4
 permit icmp host 70.1.1.1 host 4.4.4.4

route-map PBR_SLA permit 10
 match ip address SLA1_ACL
 set ip next-hop 70.1.1.100

Настройка Local PBR для тестов на ISP2: 

ip access-list extended SLA2_ACL
 permit icmp host 80.1.1.1 host 4.2.2.2
 permit icmp host 80.1.1.1 host 4.2.2.3
 permit icmp host 80.1.1.1 host 4.2.2.4

route-map PBR_SLA permit 20
 match ip address SLA2_ACL
 set ip next-hop 80.1.1.100

Применение политики: 

ip local policy route-map PBR_SLA

[править] Настройка Track

Каждый track (10,20,30) отслеживает свой тест IP SLA для ISP1: 

track 10 ip sla 1 reachability
track 20 ip sla 2 reachability
track 30 ip sla 3 reachability


Суммарный track 100 объединяет созданные track для ISP1: 

track 100 list boolean or
 object 10
 object 20
 object 30
 delay down 10 up 5

Каждый track (110,120,130) отслеживает свой тест IP SLA для ISP2: 

track 110 ip sla 11 reachability
track 120 ip sla 12 reachability
track 130 ip sla 13 reachability

Суммарный track 200 объединяет созданные track для ISP2: 

track 200 list boolean or
 object 110
 object 120
 object 130
 delay down 10 up 5

[править] Балансировка нагрузки

[править] Статическая маршрутизация и CEF

Если настроить два равнозначных статических маршрута (с суммарными трек), то в таблице маршрутизации будут оба маршрута и балансировкой трафика будет заниматься CEF: 

ip route 0.0.0.0 0.0.0.0 70.1.1.100 track 100
ip route 0.0.0.0 0.0.0.0 80.1.1.100 track 200

Note-icon.gif

CEF балансирует трафик на основании пары IP-адрес отправителя и получателя. Поэтому наилучшее распределение трафика будет, если количество адресов большое.

Некоторые платформы позволяют добавлять в алгоритм балансировки порты: 

ip cef load-sharing algorithm include-ports source destination

Добавление портов в выбор пути, позволяет улучшить равномерность распределения трафика между провайдерами.

[править] Балансировка с использованием Policy based routing (PBR)

Балансировку можно настроить с помощью PBR.

Тут показан пример, когда балансировка выполняется просто по адресам отправителя: пакеты с четными адресами отправителя отправляются на ISP1, с нечетными -- на ISP2.

Note-icon.gif

Эти настройки лучше добавить к конфигурации с балансировкой в предыдущем разделе (два равнозначных статических маршрута). Пакеты, которые описаны в PBR, будут маршрутизироваться по правилам PBR. Но, если пакет не попадает под эти правила, или один из треков, который привязан к next-hop, упадет, пакеты будут маршрутизироваться по стандартной таблице маршрутизации.

ACL для выделения нечетных IP-адресов: 

ip access-list standard ODD
 permit 10.1.1.1 0.0.0.254

ACL для выделения четных IP-адресов: 

ip access-list standard EVEN
 permit 10.1.1.0 0.0.0.254

Настройка политики 

route-map POLICY permit 10
 match ip address ODD
 set ip next-hop verify-availability 70.1.1.100 1 track 100
route-map POLICY permit 20
 match ip address EVEN
 set ip next-hop verify-availability 80.1.1.100 2 track 200

Применение политики: 

interface GigabitEthernet0/0
 ip policy route-map POLICY

Просмотр настроек route-map: 

R1# sh route-map POLICY
route-map POLICY, permit, sequence 10
  Match clauses:
    ip address (access-lists): ODD 
  Set clauses:
    ip next-hop verify-availability 70.1.1.100 1 track 100  [up]
  Policy routing matches: 36 packets, 1512 bytes
route-map POLICY, permit, sequence 20
  Match clauses:
    ip address (access-lists): EVEN 
  Set clauses:
    ip next-hop verify-availability 80.1.1.100 2 track 200  [up]
  Policy routing matches: 9 packets, 378 bytes

Просмотр информации о примененных политиках: 

R1# sh ip policy       
Interface      Route map
Gi0/0          POLICY

[править] Итоговая конфигурация R1

[править] Итоговая конфигурация R1 (балансировка с помощью CEF)


[править] Итоговая конфигурация R1 (балансировка с помощью PBR)


[править] Два пограничных маршрутизатора. Без балансировки нагрузки

Dual isp 2.png

Краткое описание используемых технологий и задач, которые они решают:

  • IP SLA — IP SLA тесты будут мониторить несколько ресурсов в Интернет.
  • Local PBR — политика PBR для тестов IP SLA. Политика будет отправлять пакеты, которые генерирует тест, на определенного провайдера
  • Track — следит за соответствующим тестом IP SLA, а суммарный track объединяет их в один объект
  • Статическая маршрутизация — к маршруту по умолчанию на каждого провайдера надо применить суммарный трек
  • NAT — правила динамической трансляции, в данном случае, будут стандартные, без использование route-map, как в предыдущих разделах
  • EEM — выполняет очистку таблицы трансляций. Хотя трансляция для резервного провайдера будет выполняться на другом маршрутизаторе, чтобы сессии не подвисали, лучше очистить их при переключении провайдера
  • HSRP или VRRP используется для резервирования шлюза по умолчанию для хостов
  • OSPF или EIGRP используется для анонса маршрута по умолчанию ниже

Отличия от предыдущих разделов следующие:

  • NAT настраивается стандартно, так как в данной конфигурации только один outside интерфейс
  • HSRP ли VRRP используется для резервирования первого хопа от хостов (то есть, шлюза по умолчанию)
  • OSPF или EIGRP используется, если за пограничными маршрутизаторами есть устройства 3го уровня (как в схеме, которая используется для примера). С помощью протоколов маршрутизации маршрут по умолчанию передается ниже (от R1, R2 к R3, R4)

Icon-caution.gif

Основное описание технологий и настроек находится в разделе с описанием схемы с одним пограничным маршрутизатором и без балансировки нагрузки (в первом разделе).

Настройки, которые потребуются для этой схемы подключения, описаны в соответствующих разделах, но с учетом того, что основная часть описана в первой части. Поэтому, стоит начать с прочтения первого раздела, даже если используется другая схема.

[править] IP SLA

IP SLA тесты для разных провайдеров могут быть разные, или одни и те же. В этом примере тесты разные.

[править] IP SLA на R1

Настройка IP SLA тестов (icmp-echo) на R1 для ISP 1: 

ip sla 1
 icmp-echo 8.8.8.8 source-interface Gi0/1
 threshold 1000
 timeout 1500
 frequency 3
ip sla schedule 1 life forever start-time now
ip sla 2
 icmp-echo 8.8.4.4 source-interface Gi0/1
 threshold 1000
 timeout 1500
 frequency 3
ip sla schedule 2 life forever start-time now
ip sla 3
 icmp-echo 4.4.4.4 source-interface Gi0/1
 threshold 1000
 timeout 1500
 frequency 3
ip sla schedule 3 life forever start-time now

[править] IP SLA на R2

Настройка IP SLA тестов (icmp-echo) для ISP 2: 

ip sla 11
 icmp-echo 4.2.2.2 source-interface Gi0/2
 threshold 1000
 timeout 1500
 frequency 3
ip sla schedule 11 life forever start-time now
ip sla 12
 icmp-echo 4.2.2.3 source-interface Gi0/2
 threshold 1000
 timeout 1500
 frequency 3
ip sla schedule 12 life forever start-time now
ip sla 13
 icmp-echo 4.2.2.4 source-interface Gi0/2
 threshold 1000
 timeout 1500
 frequency 3
ip sla schedule 13 life forever start-time now

[править] Настройка Local PBR

[править] Настройка Local PBR на R1

Настройка Local PBR для тестов на ISP1: 

ip access-list extended SLA1_ACL
 permit icmp host 70.1.1.1 host 8.8.8.8
 permit icmp host 70.1.1.1 host 8.8.4.4
 permit icmp host 70.1.1.1 host 4.4.4.4

route-map PBR_SLA permit 10
 match ip address SLA1_ACL
 set ip next-hop 70.1.1.100


Применение политики: 

ip local policy route-map PBR_SLA

[править] Настройка Local PBR на R2

Настройка Local PBR для тестов на ISP2: 

ip access-list extended SLA2_ACL
 permit icmp host 80.1.1.1 host 4.2.2.2
 permit icmp host 80.1.1.1 host 4.2.2.3
 permit icmp host 80.1.1.1 host 4.2.2.4

route-map PBR_SLA permit 10
 match ip address SLA2_ACL
 set ip next-hop 80.1.1.100

Применение политики: 

ip local policy route-map PBR_SLA

[править] Настройка Track

[править] Настройка Track на R1

Каждый track (10,20,30) отслеживает свой тест IP SLA для ISP1: 

track 10 ip sla 1 reachability
track 20 ip sla 2 reachability
track 30 ip sla 3 reachability


Суммарный track 100 объединяет созданные track для ISP1: 

track 100 list boolean or
 object 10
 object 20
 object 30
 delay down 10 up 5

[править] Настройка Track на R2

Каждый track (110,120,130) отслеживает свой тест IP SLA для ISP2: 

track 110 ip sla 11 reachability
track 120 ip sla 12 reachability
track 130 ip sla 13 reachability

Суммарный track 200 объединяет созданные track для ISP2: 

track 200 list boolean or
 object 110
 object 120
 object 130
 delay down 10 up 5

[править] Настройка статических маршрутов

[править] Настройка статического маршрута по умолчанию на R1

Применение суммарного track к маршруту по умолчанию, который ведет к провайдеру ISP1: 

ip route 0.0.0.0 0.0.0.0 70.1.1.100 track 100

[править] Настройка статического маршрута по умолчанию на R2

Применение суммарного track к маршруту по умолчанию, который ведет к провайдеру ISP2: 

ip route 0.0.0.0 0.0.0.0 80.1.1.100 track 200

[править] Настройка NAT

Настройка NAT, для данной схемы (так как номера интерфейсов inside и outside одинаковы), одинаковая для R1 и R2: 

interface GigabitEthernet0/0
 ip nat inside
!
interface GigabitEthernet0/1
 ip nat outside
!
ip access-list standard LAN
 permit 10.1.1.0 0.0.0.255
 permit 10.0.10.0 0.0.0.255
!
ip nat inside source list LAN interface Gi0/1 overload

[править] Настройка EEM

Настройки EEM на R1: 

event manager applet ISP_1_UP 
 event track 100 state up
 action 001 cli command "enable"
 action 002 cli command "clear ip nat trans *"
 action 003 syslog msg "ISP 1 is UP"

event manager applet ISP_1_DOWN 
 event track 100 state down
 action 001 cli command "enable"
 action 002 cli command "clear ip nat trans *"
 action 003 syslog msg "ISP 1 is DOWN"

Настройки EEM на R2: 

event manager applet ISP_2_UP 
 event track 200 state up
 action 001 cli command "enable"
 action 002 cli command "clear ip nat trans *"
 action 003 syslog msg "ISP 2 is UP"

event manager applet ISP_2_DOWN 
 event track 200 state down
 action 001 cli command "enable"
 action 002 cli command "clear ip nat trans *"
 action 003 syslog msg "ISP 2 is DOWN"

[править] Настройка OSPF

В качестве протокола динамической маршрутизации выбран OSPF. Но аналогичную схему можно реализовать и с EIGRP.

Базовые настройки OSPF будут одинаковыми на всех четырех маршрутизаторах (R1, R2, R3, R4): 

router ospf 1
 auto-cost reference-bandwidth 10000
 network 10.0.0.0 0.255.255.255 area 0

Для того чтобы маршрутизатор R1 был основным выходом из сети (и, соответственно, ISP 1), на маршрутизаторе должен быть анонсирован маршрут по умолчанию, средствами OSPF, с меньшим значением метрики, чем на R2.

Анонс маршрута по умолчанию с маршрутизатора R1 с метрикой 1000: 

router ospf 1
 default-information originate metric 1000

Анонс маршрута по умолчанию с маршрутизатора R2 с метрикой 2000: 

router ospf 1
 default-information originate metric 2000

Note-icon.gif

Команда default-information originate будет анонсировать маршрут по умолчанию в OSPF только при условии, что на маршрутизаторе, на котором дана команда, в таблице маршрутизации есть маршрут по умолчанию. Если его нет, то маршрут по умолчанию в OSPF также не анонсируется.

Так как на маршрутизаторах R1 и R2 статический маршрут по умолчанию зависит от состояния трека, то, соответственно, и анонс маршрута по умолчанию в OSPF, также зависит от трека.

[править] Проверка OSPF

Проверка анонса маршрута по умолчанию на R3.

Если трек в состоянии UP (то есть, тесты IP SLA работают через ISP 1), то R3 и R4 используют маршрут по умолчанию через R1: 

R3# sh ip route

Gateway of last resort is 10.1.1.1 to network 0.0.0.0

     10.0.0.0/24 is subnetted, 2 subnets
C       10.0.10.0 is directly connected, GigabitEthernet0/1
C       10.1.1.0 is directly connected, GigabitEthernet0/0
O*E2 0.0.0.0/0 [110/1000] via 10.1.1.1, 00:06:25, GigabitEthernet0/0


Если трек в состоянии DOWN (то есть, ни один из тестов IP SLA не работает через ISP 1), то R3 и R4 используют маршрут по умолчанию через R2: 

R3# sh ip route

Gateway of last resort is 10.1.1.2 to network 0.0.0.0

     10.0.0.0/24 is subnetted, 2 subnets
C       10.0.10.0 is directly connected, GigabitEthernet0/1
C       10.1.1.0 is directly connected, GigabitEthernet0/0
O*E2 0.0.0.0/0 [110/2000] via 10.1.1.2, 00:00:12, GigabitEthernet0/0

[править] Итоговая конфигурация

[править] Итоговая конфигурация R1


[править] Итоговая конфигурация R2


[править] Дополнительная информация

Источник — «http://5.9.243.178:81/wiki/%D0%A0%D0%B5%D0%B7%D0%B5%D1%80%D0%B2%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_%D0%98%D0%BD%D1%82%D0%B5%D1%80%D0%BD%D0%B5%D1%82-%D0%BA%D0%B0%D0%BD%D0%B0%D0%BB%D0%BE%D0%B2_%D0%B1%D0%B5%D0%B7_%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F_BGP»