Comments 17
Что-то из серии xgu.ru/wiki/DMVPN и там и тут мозг утекает, если просто читать, а не выполнять конкретную задачу.
С eigrp и next-hop-self в phase1_3 and 2 напутали, в первом случае надо наоборот оставлять next-hop-self а во втором no ip next-hop-self eigrp blahblah
Массивный труд, внушает уважение.
Но я за один раз прочесть внимательно не осилил. При том, что я вроде бы знаю, как это работает :) (Ну, пожалуй, кроме Фазы 3 на практике)
Я бы наверно поделил бы на 2 части: теория, практика. И в практике все же упомянул про отказоустойчивость (2 хаба одного облака или 2 независимых облака). Вопросы как раз тут часто возникают: как правильно, как проще, как проще с маршрутизацией увязать
Но я за один раз прочесть внимательно не осилил. При том, что я вроде бы знаю, как это работает :) (Ну, пожалуй, кроме Фазы 3 на практике)
Я бы наверно поделил бы на 2 части: теория, практика. И в практике все же упомянул про отказоустойчивость (2 хаба одного облака или 2 независимых облака). Вопросы как раз тут часто возникают: как правильно, как проще, как проще с маршрутизацией увязать
Спасибо отличная статья.
Коллеги, а не подскажете, как правильно поступить со spoke-2-spoke общением.
Фактически, если у нас падает хаб, мы теряем все EIGRP маршруты. В то же время, NHRP таблица на каждом роутере остаётся. Можно ли заставить роутеры динамически устанавливать сессии друг с дружкой или это не желательно?
Я знаю про dual hub design, но интересует дополнительная отказоустойчивость.
Спасибо.
Фактически, если у нас падает хаб, мы теряем все EIGRP маршруты. В то же время, NHRP таблица на каждом роутере остаётся. Можно ли заставить роутеры динамически устанавливать сессии друг с дружкой или это не желательно?
Я знаю про dual hub design, но интересует дополнительная отказоустойчивость.
Спасибо.
А что подразумеваете под «динамически устанавливать сессии»? они же и так динамически
Сессии динамической маршрутизации. Чтобы процесс маршрутизации на одном spoke устанавливал соседство с другим spoke.
А то получается, что мы соседей видим через NHRP и устанавливаем с ними соединение напрямую, но маршруты от них идут через центральный узел, и вся отказоустойчивость завязана на него.
А то получается, что мы соседей видим через NHRP и устанавливаем с ними соединение напрямую, но маршруты от них идут через центральный узел, и вся отказоустойчивость завязана на него.
UFO just landed and posted this here
Спасибо, тезка :)
согласен, что наверное нужно. Меня смущает, что на некоторых платформах наличие этой команды заставляет пакеты, проходящие через tunnel, подвергаться process-switching. Что медленно и очень нагружает железку.
При этом, если я ничего не путаю за давностью, туннели можно разнести, если сделать у них разный source-int, не потеряв при этом fast и cef
согласен, что наверное нужно. Меня смущает, что на некоторых платформах наличие этой команды заставляет пакеты, проходящие через tunnel, подвергаться process-switching. Что медленно и очень нагружает железку.
При этом, если я ничего не путаю за давностью, туннели можно разнести, если сделать у них разный source-int, не потеряв при этом fast и cef
Писал про эту технологию на жизненном примере, более кратко:
sysadminblog.ru/cisco/2011/06/10/postroenie-kspd-na-osnove-tehnologii-dmvpn-s-otkazoustoychivym-centrom-na-baze-oborudovaniya-cisco.html
Может кому пригодится. Пример взят с рабочих конфигов.
sysadminblog.ru/cisco/2011/06/10/postroenie-kspd-na-osnove-tehnologii-dmvpn-s-otkazoustoychivym-centrom-na-baze-oborudovaniya-cisco.html
Может кому пригодится. Пример взят с рабочих конфигов.
интересно, а можно на филиальном роутере за динамическим нат-ом поднять 2 туннеля DMVPN?
Sign up to leave a comment.
По мотивам Cisco Live 2009: Advanced Concepts of DMVPN