отмена
Отображаются результаты для 
Вместо этого искать 
Вы имели в виду: 
Объявления
Добро пожаловать в Сообщество Технической поддержки Cisco. Мы рады получить обратную связь .
New Member

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

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

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

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

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

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

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

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

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

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

Теги (1)
10 ОТВЕТ.
Cisco Employee

Можно и так, но проще 2 -

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

 

 

New Member

да вот как раз shared и пишу.

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

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

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

Cisco Employee

Это что-то очень запутано

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

 

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


 

New Member

про shared я понял и так и

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

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

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

Cisco Employee

Вот это как раз тот случай,

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

New Member

а еще вопрос без 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 устанавливается? И выходит, что забивает для подключения других.

New Member

Дело в том, что "tunnel

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

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

New Member

Так проверил, может конечно

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

Cisco Employee

"tunnel source" только

"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.

 

New Member

Получается все таки надо

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

99
Просмотры
0
Полезный материал
10
Ответы