Настройка отказоустойчивости Cisco DMVPN средствами EEM (Часть 1)

27 апреля 2016 1920 просмотров

Содержание:

  1. Постановка задачи.
  2. Алгоритм действия.
  3. Реализация.

Постановка задачи

Дано: VPN сеть организации, построенная на технологии DMVPN с одним hub маршрутизатором и несколькими spoke-маршрутизаторами. Задача: обеспечить резервирование VPN на удаленных spoke маршрутизаторах при помощи организации избыточного доступа к сети интернет (подключение дополнительного провайдера). Переход с основного канала VPN на резервный через другого провайдера должен осуществлять по условию превышения заданного времени ответа для некоторого количества echo пакетов в минуту на основном провайдере. Echo запросы осуществляются от маршрутизатора в удалѐнном офисе к интерфейсу центрального маршрутизатора.

Алгоритм действия

Для резервирования VPN сети используется дополнительное DMVPN облако. Удалѐнный офис имеет 2 VPN туннеля: 1 – основное DMVPN облако, доступ через основного провайдера; 2 – резервное DMVPN облако, доступ через резервного провайдера. В нормальном состоянии оба туннеля активны постоянно, трафик движется через основной или резервный туннели (или оба сразу) согласно правилам маршрутизации.

Схема резервирования инфраструктуры VPN:

Схема резервирования инфраструктуры VPN

Состояние основного или резервного канала отслеживается при помощи технологии IP SLA. Данные echo запросов сохраняются в истории в оперативной памяти маршрутизатора. Далее эти данные анализируются при помощи последовательности команд TCL интерпретатора, сохраненных на флеш памяти маршрутизатора (скрипт-файл). Далее если заданный канал признан неудовлетворительным, в текущую конфигурацию маршрутизатора в автоматическом режиме вводятся команды, предписывающие изменить маршрутизацию через резервный канал. Схема взаимодействия представлена ниже:

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

Линия State показывает состояние основного канала. Красным показаны отрезки времени, когда канал неудовлетворителен, зелѐным – когда находится в норме. Каналу присвоен параметр «оценка» по умолчанию равный 0. При фиксации ошибок на канале за заданный промежуток времени к его оценке прибавляется величина A. При отсутствии ошибок с его оценки снимается единица (B). Маршрутизация на канале снимается при изменении его оценки с 0 на положительную величину и восстанавливается при достижении оценкой нулевого значения. Это отражено линией ISP, показывающей изменение маршрутизации между основным и резервным провайдерами. Для того чтобы длительные периоды времени, при которых наблюдаются ошибки на канале, не приводили к избыточному завышению оценки после которой восстановление канала займѐт часы или даже дни введена пороговая величина C – верхняя граница допустимой оценки канала. Таким образом, данная логика позволяет сократить количество переключений маршрутизации на нестабильном канале.

Реализация

А. Добавление статических маршрутов. Добавляем статические маршруты до интерфейсов хаба в датацентре через основного и резервного провайдеров. Это делается для того чтобы данные маршруты существовали всегда вне зависимости от маршрута по умолчанию, который будет меняться по трекингу IP

Sla.

ip route 82.179.a.a 255.255.255.255 x.x.x.x ip

route 82.179.b.b 255.255.255.255 y.y.y.y

соответственно 82.179.a.a и 82.179.b.b - IP адреса центрального хаба соответствующие разным DMVPN облакам.

Б. Перед разворачиванием скрипта необходимо сформировать историю echo запросов хаб роутера в памяти маршрутизатора. Для этого сконфигурируем 2 IP SLA объекта.

ip sla 10

icmp-echo 82.179.a.a source-interface

FastEthernet0/0 threshold 300

timeout 1000

frequency 1 history

lives-kept 1

history buckets-kept

60 history filter all

ip sla schedule 10 life forever start-time

now ip sla 20

icmp-echo 82.179.b.b source-interface

FastEthernet0/1/0 threshold 300

timeout 1000

frequency 1 history

lives-kept 1

history buckets-kept 60

history filter all

ip sla schedule 20 life forever start-time now


Как видно из команд

icmp-echo 82.179.a.a source-interface FastEthernet0/0

icmp-echo 82.179.b.b source-interface FastEthernet0/1/0

опрашиваются интерфейсы центрального хаб роутера. Так как маршруты сконфигурированы статически через разных провайдеров то и опросы будут осуществляться через основного и резервного провайдера. Так как echo запрос должен отправляться каждую секунду следовательно таймаут мы выставляем в 1000 мс и частоту в 1 с.

timeout 1000 frequency 1

Согласно требованиям удовлетворительный пинг на канале не должен превышать 300 мс.

threshold 300

Конфигурируем хранение журнала echo опросов в памяти на 60 (максимально возможно) значений.

history lives-kept 1

history buckets-kept 60

history filter all

стартуем IP SLA

ip sla schedule 10 life forever start-time now

ip sla schedule 20 life forever start-time now

Перейти к прочтению 2ой части статьи

Теги: