Отказ WAN в DMVPN: политика маршрутизации или закрытие туннеля?

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

Решение принимается до настройки

Три условия решают это за вас. Зависит ли что-то ещё от того, что интерфейс туннеля поднят, например второй профиль DMVPN или монитор, читающий его состояние? Несёт ли трафик, который должен перейти на резерв, собственную политику или полагается на глобальную таблицу маршрутизации? И нужен ли оператору однозначный переход состояния, или допустимо тихое переключение пути? Ответьте на эти три, и выбор обычно делается сам.

Если закрытие опустило бы работавшие службы, политика маршрутизации — меньшее действие. Если требование в том, что туннель не должен существовать, пока основной WAN опущен, ни одна запись политики не выразит этого.

Запишите ответ, потому что настройка — простая часть.

Что на самом деле меняет политика маршрутизации

При маршрутизации на основе политик отслеживаемый объект может управлять следующим хопом. Запись карты маршрутов называет кандидата на следующий хоп и отслеживаемый объект, который должен быть поднят для его использования, а это состояние отслеживания приходит от зонда IP SLA. Когда объект опускается, запись перестаёт совпадать, и пакет оценивается следующей записью или обычной таблицей маршрутизации.

Эта последняя деталь удивляет людей: политика, которая перестаёт выбирать следующий хоп, обычно разрешает обычную маршрутизацию, а не блокирует трафик. Если вам нужна чёрная дыра при отказе, её придётся написать самому.

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

Что меняет закрытие туннеля

Закрытие интерфейса меняет административное состояние. Каждый туннель, маршрут и сеанс, которые от него зависят, падают сразу, и это именно то, что нужно, если туннель — то, что должно исчезнуть. Так же апплет EEM превращает проблему WAN в сбой, включающий и несвязанные службы.

Если вы пойдёте этим путём, ограничьте апплет одним интерфейсом и одним триггером, сохраните предыдущее административное состояние, определите действие восстановления и убедитесь, что повторные флапы не могут загнать его в цикл.

Жёстко заданная команда восстановления может также отменить закрытие на обслуживание, выполненное кем-то другим.

Заставьте зонд идти тем путём, который вы думаете

Зонд, следующий текущему лучшему маршруту, переходит на резервный WAN вместе со всем остальным, а затем сообщает, что основной здоров, потому что больше его не использует.

Привяжите зонд к интерфейсу или адресу источника того пути, который вы проверяете. Проверьте и то, на что он нацелен, поскольку достижение следующего хопа провайдера доказывает меньше, чем достижение службы, ради которой существует туннель. Задайте задержки подъёма и падения осознанно: короткая задержка падения реагирует быстро и флапает, а длинная переживает короткие колебания и скрывает настоящие отказы. Руководство Cisco по отслеживанию и маршрутизации на основе политик в IOS XE описывает поддерживаемые комбинации, а набор функций на вашей платформе решает, какие из них можно использовать.

Запишите оба значения задержки рядом с отслеживаемым объектом, иначе никто не узнает, почему он вёл себя так.

Решите вопрос восстановления, затем проверьте

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

Если отказ работает, но приложение всё ещё ломается, проблема находится выше уровня маршрутизации, и никакое отслеживание её не исправит.

Сохраните доказательства из того окна, потому что следующее изменение будут сравнивать с ними.