отмена
Отображаются результаты для 
Вместо этого искать 
Вы имели в виду: 
cancel
Объявления

Community Live

Community Live

534
Просмотры
0
Полезный материал
10
Ответы
Igor Yakimchuk
Beginner

Вопрос по архитектуре DMVPN

Есть у меня такой вопрос.

Есть HUB у которого два провайдера, есть много Spoke. У некоторых Spoke так же имеется по два провайдера.

И вот вопрос в том, сколько туннелей должно быть? По моим понятиям, для полного покрытия, должно быть по четыре туннеля на каждом spoke ну и естественно на HUB. Или я не прав?

Сразу опишу как считал я:

1. HUB основной провайдер - Spoke основной провайдер

2. HUB основной провайдер - Spoke резервный провайдер

3. HUB резервный провайдер - Spoke основной провайдер

4. HUB резервный провайдер - Spoke резервный провайдер

Ну и где по одному провайдеру на Spoke тоже 4 канала, чтобы получилась полная DMVP система :).

10 ОТВЕТ 10
Oleg Tipisov
Cisco Employee

Можно и так, но проще 2 - основной-основной и резерв-резерв. Дело в том, что "tunnel source <int>" не имеет никакого отношения к тому, с какого интерфейса будет уходить шифрованный трафик. Плюс придется писать "shared" в "tunnel protection ipsec profile".

 

 

да вот как раз shared и пишу. Просто с моей структурой пока косяк есть. Настроено ospf, на каждом туннеле стоимость ospf разная. И вот там где на spoke два провайдера и отваливается например основной, то spoke-spoke пытается соединяться как угодно и в итоге "счастье" не приходит.

То есть туннель поднимается между hub основной и spoke резервный, а вот маршрутизация ведет себя как попало. Например я обращаюсь с Spoke (назовем его spoke1) на Spoke (назовем его spoke2) где отвалился основной канал и маршрутизация в данном случае может пойти через любой spoke вместо того чтобы у hub узнать куда же все таки идти. А так как другие spoke тоже не совсем знают как попасть, то в итоге я до spoke2 со spoke1 могу не попасть.

Олег, вроде не ошибаюсь в имени? :), вот у меня тогда такой вопрос, если мы оставляем два туннеля основной-основной, резервный-резервный и на HUB отваливается основной канал. Как быть в таком случае? Ведь на маршрутизаторах spoke (с двумя провайдерами) настроено к какому внешнему ip hub подключаться и не смогут подключиться к резервному каналу HUB через резервного провайдера Spoke, так Spoke будут выходить в интернет по маршруту по-умолчанию, то есть через основного провайдера.

Это что-то очень запутано сформулировано. Туннели спок-спок - отдельная тема. DMVPN phase 2 или phase 3? В любом сл., даже если споки подключились к хабу через разные primary/secondary туннели, потому что какой-то провайдер полег, они смогут передавать трафик, даже если не смогут установить туннель спок-спок. Трафик пойдет через hub.

 

Под "shared" я имел ввиду другое - опцию "shared" в команде "tunnel protection". Она хорошо описана в документации (Shared tunnel protection). С 4-мя туннелями важно просто не запутаться, какой IPSec profile привязан к какому int tunnel и не забыть опцию shared.


 

про shared я понял и так и указываю.

даже если споки подключились к хабу через разные primary/secondary туннели, потому что какой-то провайдер полег, они смогут передавать трафик, даже если не смогут установить туннель спок-спок. Трафик пойдет через hub.

так вот не идет через HUB, может пойти через любой spoke.

Вот это как раз тот случай, когда надо купить тех. поддержку и открыть кейс в TAC.

а еще вопрос без TAC. На HUB

192.166.x.x     109.197.x.x  QM_IDLE           4522 ACTIVE
192.166.x.x     109.197.x.x  MM_NO_STATE       4490 ACTIVE (deleted)
192.166.x.x     109.197.x.x  MM_NO_STATE       4457 ACTIVE (deleted)
192.166.x.x     109.197.x.x  QM_IDLE           5353 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           5321 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           5281 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           5253 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           5130 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           5106 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           4434 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           4405 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           4252 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           4188 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           4142 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           5878 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           5838 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           5909 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           4633 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           4600 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           5206 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           5174 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           4769 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           4708 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           4676 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           4190 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           4022 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           5843 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           5809 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           5379 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           4338 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           5265 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           5232 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           4986 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           4777 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           4420 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           5811 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           5306 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           4793 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           4767 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           4583 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           5981 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           5842 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           5497 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           5246 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           5214 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           5146 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           4977 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           4947 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           4740 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           4378 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           4236 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           4081 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           5693 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           5470 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           5447 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           5378 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           4944 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           4873 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           4841 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           4690 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           4227 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           4205 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           4138 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           4001 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           5910 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           5759 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           5671 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           5954 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           5895 ACTIVE
192.166.x.x     109.197.x.x  QM_IDLE           5863 ACTIVE

 при этом на SPOKE

192.166.x.x   109.197.x.x  QM_IDLE           1682    0 ACTIVE
192.166.x.x   109.197.x.x  QM_IDLE           1679    0 ACTIVE

почему на HUB столько isakmp устанавливается? И выходит, что забивает для подключения других.

Дело в том, что "tunnel source <int>" не имеет никакого отношения к тому, с какого интерфейса будет уходить шифрованный трафик.
 

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

Так проверил, может конечно не правильно. Был туннель с tunnel source dialer0. Отключили провайдера, который приходил по pppoe и оставили второго. Туннель не поднялся, пока не прописал tunnel source Fastethernet0/1. То есть не просто так получается указывается "tunnel source <int>"

"tunnel source" только выставляет SrcIP в исходящих пакетах после инкапсуляции. Пакеты же отправляются туда, куда показывает таблица маршрутизации, т.е. вовсе не обязательно в тот интерфейс, который указан в "tunnel source". Как поступит ISP, если ему придет пакет с srcIP из адресного пространства др. ISP, - мы не знаем. Равно как не знаем ISP ли там или это "корпоративный WAN". ISP скорее всего дропнет конечно. В любом сл., в схемах с несколькими redundant ISP, если например, применяется схема с 4-мя туннелями, разумно "прибить" два из них к одному ISP и два - к другому. Для этого используется конструкция

 

interface tunnel x

 tunnel route-via fa0/0 mandatory

 

Она позволяет "заузить" список маршрутов, которые рассматриваются при принятии решения о посылке пакета. Будут рассматриватться только маршруты через fa0/0.

 

Документация д.б. в new features для IOS 12.4(11)T - Tunnel Route Selection.

 

Получается все таки надо использовать четыре туннеля, потому что нет уверенности что с двумя туннелями заработает корректно?
 

Создать
Выразить признание своим коллегам
Content for Community-Ad

Сообщество Cisco

Помощь по сообществу