задачей было скорее показать теоретические подробности, а не научить конфигурировать. Т.е. статья больше для тех, кто готовится к сертификациям или использует DMVPN в сложных конфигурациях, а потому вынужден глубоко понимать функционал.
С eigrp и next-hop-self в phase1_3 and 2 напутали, в первом случае надо наоборот оставлять next-hop-self а во втором no ip next-hop-self eigrp blahblah
Но я за один раз прочесть внимательно не осилил. При том, что я вроде бы знаю, как это работает :) (Ну, пожалуй, кроме Фазы 3 на практике)
Я бы наверно поделил бы на 2 части: теория, практика. И в практике все же упомянул про отказоустойчивость (2 хаба одного облака или 2 независимых облака). Вопросы как раз тут часто возникают: как правильно, как проще, как проще с маршрутизацией увязать
ну вот я тут обкатаю, а тебе в блог положу в виде двух статей :) Я неделю ее писал, очень уж большая получилась. Но коль уж разбирался досконально, то решил и изложить :)
Коллеги, а не подскажете, как правильно поступить со spoke-2-spoke общением.
Фактически, если у нас падает хаб, мы теряем все EIGRP маршруты. В то же время, NHRP таблица на каждом роутере остаётся. Можно ли заставить роутеры динамически устанавливать сессии друг с дружкой или это не желательно?
Я знаю про dual hub design, но интересует дополнительная отказоустойчивость.
Спасибо.
Сессии динамической маршрутизации. Чтобы процесс маршрутизации на одном spoke устанавливал соседство с другим spoke.
А то получается, что мы соседей видим через NHRP и устанавливаем с ними соединение напрямую, но маршруты от них идут через центральный узел, и вся отказоустойчивость завязана на него.
согласен, что наверное нужно. Меня смущает, что на некоторых платформах наличие этой команды заставляет пакеты, проходящие через tunnel, подвергаться process-switching. Что медленно и очень нагружает железку.
При этом, если я ничего не путаю за давностью, туннели можно разнести, если сделать у них разный source-int, не потеряв при этом fast и cef
По мотивам Cisco Live 2009: Advanced Concepts of DMVPN