Вы здесь

DMVPN и резервный ISP

Ранее мы уже рассматривали вопросы построения DMVPN в статье DMVPN и EIGRP
В данной статье обсуждается конфигурация DMVPN и EIGRP для работы с основным и резервным провайдером.
Очень часто в центральный офис компании имеет смысл провести два ISP одновременно. Это делается с целью обеспечения надежности подключения к интернету в случае сбоя одного из провайдеров.

Рассмотрим практический пример построения туннелей DMVPN для автоматического переключения на резервного провайдера.
DMVPN_and_Secondary_ISP_0.jpg
В центральном офисе располагаются два маршрутизатора, каждый из которых подключен к основному и резервному провайдеру соответственно.

Каждый HUB поддерживает свой туннельный интерфейс, таким образом на каждый SPOKE терминируются одновременно два туннеля.
Переключение производится с помощью EIGRP.

Primary HUB держит шифрованный туннель,
Secondary HUB имеет слабое железо (C891) и свой туннель не шифрует.

HUB Primary

!----------------------------------------------
! ISP Monitoring
!----------------------------------------------
ip sla 1
icmp-echo 8.8.8.8 source-interface GigabitEthernet0/0
ip sla schedule 1 life forever start-time now
ip sla 2
icmp-echo 82.14.122.138 source-interface GigabitEthernet0/0
ip sla schedule 2 life forever start-time now
ip sla 3
icmp-echo 93.86.61.38 source-interface GigabitEthernet0/0
ip sla schedule 3 life forever start-time now
ip sla 4
icmp-echo 89.117.36.231 source-interface GigabitEthernet0/0
ip sla schedule 4 life forever start-time now

track 1 ip sla 1 reachability
delay down 30 up 30

track 2 ip sla 2 reachability
delay down 30 up 30

track 3 ip sla 3 reachability
delay down 30 up 30

track 4 ip sla 4 reachability
delay down 30 up 30

track 5 list boolean or
object 1
object 2
object 3
object 4
!----------------------------------------------
!Crypto config
!----------------------------------------------

crypto isakmp policy 10
encr 3des
hash md5
authentication pre-share
group 2

crypto isakmp key Mykey address 0.0.0.0 0.0.0.0

crypto ipsec transform-set DMVPN-TR esp-des esp-md5-hmac

crypto ipsec profile DMVPN
set transform-set DMVPN-TR
!----------------------------------------------
!DMVPN Config
!----------------------------------------------

interface Tunnel200
description ### DMVPN TUNNEL HUB
ip address 10.5.0.1 255.255.255.0
no ip redirects
ip mtu 1400
ip nbar protocol-discovery
ip hold-time eigrp 1 35
no ip next-hop-self eigrp 1
ip flow ingress
ip flow egress
ip nhrp authentication baurus
ip nhrp map multicast dynamic
ip nhrp network-id 200
ip tcp adjust-mss 1300
no ip split-horizon eigrp 1
delay 100000
shutdown
tunnel source 187.237.40.107
tunnel mode gre multipoint
tunnel key 123
tunnel protection ipsec profile DMVPN

router eigrp 1
network 10.5.12.0 0.0.3.255
network 10.5.0.0 0.0.0.255
no auto-summary

HUB Secondary

!----------------------------------------------
! ISP Monitoring
!----------------------------------------------
ip sla 1
icmp-echo 8.8.8.8 source-interface FastEthernet8
ip sla schedule 1 life forever start-time now
ip sla 2
icmp-echo 82.114.122.138 source-interface FastEthernet8
ip sla schedule 2 life forever start-time now
ip sla 3
icmp-echo 93.186.61.38 source-interface FastEthernet8
ip sla schedule 3 life forever start-time now
ip sla 4
icmp-echo 89.17.36.231 source-interface FastEthernet8
ip sla schedule 4 life forever start-time now

track 1 ip sla 1 reachability
delay down 30 up 30

track 2 ip sla 2 reachability
delay down 30 up 30

track 3 ip sla 3 reachability
delay down 30 up 30

track 4 ip sla 4 reachability
delay down 30 up 30

track 5 list boolean or
object 1
object 2
object 3
object 4

!----------------------------------------------
!DMVPN Config
!----------------------------------------------
interface Tunnel300
description ### Secondary DMVPN TUNNEL HUB
ip address 10.5.2.1 255.255.255.0
no ip redirects
ip mtu 1400
ip hold-time eigrp 1 35
no ip next-hop-self eigrp 1
ip nhrp authentication baurus2
ip nhrp map multicast dynamic
ip nhrp network-id 300
ip tcp adjust-mss 1300
no ip split-horizon eigrp 1
delay 200000
tunnel source 13.79.112.234
tunnel mode gre multipoint
tunnel key 1234

router eigrp 1
network 10.5.2.0 0.0.0.255
network 10.5.12.0 0.0.3.255
no auto-summary

SPOKE

!----------------------------------------------
!Crypto config
!----------------------------------------------
crypto isakmp policy 10
encr 3des
hash md5
authentication pre-share
group 2

crypto isakmp key Baukey address 0.0.0.0 0.0.0.0

crypto ipsec transform-set DMVPN-TR esp-des esp-md5-hmac

crypto ipsec profile DMVPN
set transform-set DMVPN-TR

!----------------------------------------------
!DMVPN Config
!----------------------------------------------
interface Tunnel200
description ###DMVPN tunnel SPOKE###
ip address 10.5.0.19 255.255.255.0
no ip redirects
ip mtu 1400
ip nbar protocol-discovery
ip flow ingress
ip flow egress
ip nhrp authentication baurus
ip nhrp map 10.5.0.1 187.237.40.107
ip nhrp map multicast 187.237.40.107
ip nhrp network-id 200
ip nhrp nhs 10.5.0.1
ip nhrp registration no-unique
ip hold-time eigrp 1 35
ip tcp adjust-mss 1300
delay 100000
tunnel source Ethernet1
tunnel mode gre multipoint
tunnel key 123
tunnel protection ipsec profile DMVPN

interface Tunnel300
description ### Seconadary DMVPN tunnel SPOKE###
ip address 10.5.2.19 255.255.255.0
no ip redirects
ip mtu 1400
ip nbar protocol-discovery
ip flow ingress
ip flow egress
ip nhrp authentication baurus2
ip nhrp map 10.5.2.1 13.79.112.234
ip nhrp map multicast 13.79.112.234
ip nhrp network-id 300
ip nhrp nhs 10.5.2.1
ip nhrp registration no-unique
ip hold-time eigrp 1 35
ip tcp adjust-mss 1300
delay 200000
tunnel source Ethernet1
tunnel mode gre multipoint
tunnel key 1234

router eigrp 1
network 10.5.0.0 0.0.0.255
network 10.5.2.0 0.0.0.255
network 10.5.19.0 0.0.0.255
no auto-summary

Комментарии

А что если у нас есть два провайдера, и остатки L2 "VPN" сети в достаточном количестве.
Т.е часть споков будет коннектится к хабам снаружи, а часть необходимо сконнектить внутри сети, т.е если смотреть на схему сети, со стороны интерфейсов с адресами 10.5.14.95 и 10.5.14.96

Только я бы порекомендовал, чтобы на каждом споке была своя IP подсеть и свой маршрутизатор. Даже если у вас L2 VPN не надо городить все в одной подсети.

А вы могли бы привести пример реализации такой же схемы, но с условием что Spoke тоже имеют по 2 ISP. Каким образом организовать переключение туннелей?
Спасибо!

У меня это работает следующим образом:
Если смотреть по схеме статьи, то на 3825 на внешний интерфейс вешается еще один IP, например 187.237.40.108. И аналогично строится дополнительный DMVPN туннель для этого IP.
На SPOKE мы также строим дополнительный туннель до 187.237.40.108. Также в конфиге SPOKE мы добавляем статический маршрут до 187.237.40.108 через резервный ISP.

Здравствуйте ещё раз,
а могли бы вы глянуть на тему http://sysadmins.ru/post10885111.html#10885111 (я там отписался под ником Dr.Sqaer и схему приложил.)
Уже мозг закипает :)

что используйте L2 VPN как L3. Это означает, что на каждый L2 линк нужно повесить /30 подсеть.
То есть, если к примеру L2 линк соединяет географически удаленные точки А, Б и С, то поставьте в каждую по роутеру и соедините их туннелями (PtP или свой DMVPN)
Возможно, это повлечет необходимость установки дополнительного роутера в районе SW1. Но вы получите гибкость, а также возможность эффективно использовать тот же EIGRP
Простой пример: предположим на вашей схеме падает линк HUB1 - SW1. Это означает что теперь ни один пакет от 192.168.0.1 (HUB1) не попадет на 192.168.0.2 (HUB2), - и это не смотря на то, что есть резервный маршрут. Это из-за того что сеть 192.168.0.0/24 разбилась на две части и каждый из роутеров думает что эта сеть подключена непосредственно к нему.
У L2 есть большой плюс - мы можем построить L3, используя свою адресацию, но избегайте использования L2 канала в прямом смысле как L2 если этого напрямую не требуют условия задачи.
Как только два L2 канала превратятся в L3, ваша схема тутже превратится в "стандартную" с двумя линками и все станет понятнее.

Касательно основных и резервных ISP. Если имеются основной и резервный в ц.офисе и в филиале, то едва ли имеет смысл закладываться на всевозможные комбинации их работы.
У меня используется следующим образом:
- возможность переключения на основной и резервный у ц. офисе (как в этой статье)
- Для филиалов с двумя ISP на одном из хабов ц.офиса добавлен еще один IP и на него маршрутизируется третий DMVPN туннель от филиала по резервному. Можно сделать аналогично и для второго хаба, но у меня пока на практике такого не было, чтобы упали одновременно основной в ц офисе и основной в филиале. Будет время опишу в статье этот момент, но в принципе все аналогично

C вашего позволения ещё вопрос,
как мне организовать NAT для тех кто за Spoke роутерами.
T.e NAT для 192.168.xxx.xxx Spoke (<--- NAT INSIDE) > HUB (NAT Outside ---->)>internet
Мозг уже сломал. Не вешать же на тунельных интерфейсах NAT inside

Я правильно понимаю,
этот документ как раз и описывает то что я хочу?
http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_e...

На этом примере нат производится в каждом филиале отдельно.

Т.е. применительно к этой статье, для того чтобы сделать нат на spoke1, мы дадим следующие классические команды:

interface Ethernet1
 description ###OUTSIDE ###
 ip nat outside
!
interface Vlan1
 description ###INSIDE###
  ip nat inside
!
ip nat inside source list 100 interface Ethernet1 overload
!
access-list 100 permit ip 10.5.19.0 0.0.0.255 any

Это рабочий конфиг, прекрасно живет с DMVPN и с EIGRP или OSPF. Тут не нужны лишние роутмапы "nonat", не усложняйте

Вы хотите чтобы трафик от клиентов spoke приходил на hub и только оттуда натился и уходил наружу? Это самый сложный путь, поскольку интернет трафик должен идти на default gateway и вам придется городить сложную конструкцию из route-map-ов и аксес листов, и как вы правильно подметили, вешать NAT inside на туннельном интерфейсе.
Можно сделать проще: разместить прокси-сервер в центральном офисе и всем клиентам в споках его прописать.
Также вы можете натить в каждом филиале отдельно.

Дело в том, что я хочу выпустить гостевые сети wifi через центральный офис. Т.е сотрудники в удалённых офисах и так ходя через прокси, или имеет смысл не парится и завернуть весь гостевой трафик в прозрачный прокси?

Заворачивать трафик на уровне маршрутизации имеет смысл если стоит задача контроля загрузки канала филиала - т.е. тогда на туннель можно эффективно наложить правила QoS.
Если вы хотите контролировать юзеров в интернете, их скорость, кто куда ходит и т.д., то лучше прокси еще ничего не придумали. Прозрачный прокси работает с протоколами HTTP, HTTPS, FTP - если этого достаточно, то да.
Если людям нужно выходить наружу по PPTP, RDP и т.д., то придется городить на уровне маршрутизации. Ситуация здесь усложняется если есть два ISP, это должны отражать роут-мапы.
Есть еще вариант поставить каждому клиенту PPTP клиента на проксю, например TMG (так делают некоторые ISP). Тогда весь трафик будет заворачиваться и учитываться проксей

долго бился с конфигурацией статьи, но она не рабочая, по крайней мере у меня. Пока не наткнулся на следующую тему https://supportforums.cisco.com/thread/78233 в частности вот (выдержка из ответа wong.jason) - You can use either p-pGRE or mGRE tunnel interfaces on the spoke routers. Multiple p-pGRE interfaces on a spoke router can use the same tunnel source ... IP address, but multiple mGRE interfaces on a spoke router must have a unique tunnel source ... IP address.

После этого повесил на внешний интерфейс секондари ip и на первом тунеле в качестве источника указал первичный Ip а на втором вторичный. и тогда оба тунеля заработали отлично. а у Вас источник одинаков, у меня так не работало.

Хм, у меня подобная кофигурация висит на 23 офисах и все стабильно уже года два точно. Два белых IP для региона роскошь. А эта конфига работает даже когда в регионе серый адрес (см. Подключение региональных офисов с серыми адресами по VPN)
Могу предложить проверить следующее:
1) Обновите IOS до последней версии. Это критично и масса проблем у меня решалась этим путём.
2) Обратите внимание, у каждого туннеля уникальны параметры в строках:
ip nhrp authentication baurus2
tunnel key 1234

Именно эти параметры позволяют строить туннели с одного IP-источника, а если их сделать одинаковыми, пакеты разных GRE будут восприниматься как в одном
3) Уберите для начала всякое шифрование с туннелей, т.е. строку:
tunnel protection ipsec profile DMVPN
4) Конфиг я пробовал только в динамике, а ваша ссылка "DMVPN with Static Routes". Честно говоря вся идея переключения строится именно силами EIGRP

Спасибо за советы. Да маршрутизация пофик какая, тунели должны строится оба. Нашел косяк, проблема была в шифровании, если несколько тунелей, то либо несколько профилей ipsec, либо shared. А то постоянно isakmp перестраивался.

Подскажит, как будет выглядеть настройка, если второй провайдер представляет собой 3G устройство.
Схема получается такая:
int fa0/1 - белый адрес провайдера - здесь все нормально отработывает.
int vlan2 - 192.168.1.10 - подключен к Zyxel (192.168.1.1) с 3g модемом. Эта связка натит серые адреса в некий динамический белый адрес.

Добрый день,

Ezvpn а также DMVPN с серыми адресами работают вполне корректно, но реально скорости всё же не те.
Я пробовал с Yota: Http летает, но как только подключаешь VPN скорости уже не те. Видимо провайдер намеренно душит всё кроме http/https/ftp. Причем душится и полоса пропускания и время отклика. Т.е. реально на Yota может работать только очень небольшой офис на 3-4 человека.
Возможно с G3 будет по другому, расскажите если получится.

По настройкам посмотрите статью Подключение региональных офисов с серыми адресами по VPN

Статью смотрел, сейчас по ней настраиваю, но работает только часть с белыми адресами. Шифрование в принципе вторично, я пока без него пытаюсь.
Там задал вопрос. М.б. куда-то конфиги приложить?

Коллеги, у кого есть какие мысли по теме DMVPN Phase 2 + 3G не работает:

https://supportforums.cisco.com/thread/2266259?tstart=0

Было нечто похожее на йоте DMVPN без шифрования. Но связи spoke-to-spoke не было особо важны. Сейчас еще раз проверил - работает. Т.е. решилось само как то.

Что интересно, криво отрабатывает NHRP:

Уменьшил таймеры:

ip nhrp holdtime 30
ip nhrp registration no-unique
ip nhrp registration timeout 30

###

HUB_1:

#sh ip nhrp br
Target Via NBMA Mode Intfc Claimed
192.168.0.10/32 192.168.0.10 83.220.224.89 dynamic Tu1 10.0.0.1
192.168.0.20/32 192.168.0.20 83.220.224.192 dynamic Tu1 10.2.0.1

HUB_2:

Target Via NBMA Mode Intfc Claimed
192.168.0.10/32 192.168.0.10 83.220.224.89 dynamic Tu1 10.0.0.1
192.168.0.20/32 192.168.0.20 83.220.224.192 dynamic Tu1 10.2.0.1

##

SPOKE_1:

Target Via NBMA Mode Intfc Claimed
192.168.0.1/32 192.168.0.1 141.101.243.16 static Tu1 < >
192.168.0.2/32 192.168.0.2 141.101.243.17 static Tu1 < >
192.168.0.20/32 192.168.0.20 83.220.224.192 dynamic Tu1 10.2.0.1

###

SPOKE_2:

SPOKE_2#ping 10.0.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 640/826/1072 ms

SPOKE_2#traceroute 10.0.0.1
Type escape sequence to abort.
Tracing the route to 10.0.0.1
VRF info: (vrf in name/id, vrf out name/id)
1 test1.0.168.192.in-addr.arpa (192.168.0.1) 240 msec 460 msec 276 msec
2 192.168.0.10 2100 msec 656 msec 644 msec

SPOKE_2#sh ip nhrp br
Target Via NBMA Mode Intfc Claimed
192.168.0.1/32 192.168.0.1 141.101.243.16 static Tu1 < >
192.168.0.2/32 192.168.0.2 141.101.243.17 static Tu1 < >
192.168.0.10/32 192.168.0.10 141.101.243.16 dynamic Tu1 < >

###

Везде база NHRP верная, кроме SPOKE_2 !

Добрый день. Подскажите пожалуйста. Ситуация, в центральном офисе 2 хаба, в филиале споук. Как быть, если нужно переключать туннели дмвпн с основного на резервный не в случаи пропадания, а в случаи ухудшения связи? Например пинги выше 300мс или пропадания пакетов 10%?

Добрый день, вручную выключаете туннельный интерфейс

один вопрос кто не будь из вас сделал на один роутер 2 ISP dmvpn vrf eigrp? я сделал у меня шифрование не работает если кто знает подскажите пожалуйста, я скину свой лаб готовый и рабочий

Пробовал, и есть описание.
Шифрование поднялось, но Столкнулся с проблемами
1) невозможность сбора статистики Netflow из зон VRF, т.е. сбор ведется только с интерфейсов, находящихся в Global.
2) не удалось выполнить NAT на том же роутере, где живут vrf

Очень интересно что получилось у вас, пишите на ciscomaster@mail.ru

у меня все работает, но одна ошибка есть, когда настрою шифрование на туннели, туннели перестанет работать, а так все у меня работает, если что пишите это мой адрес parvin_92@bk.ru

Добавить комментарий

Filtered HTML

  • Адреса страниц и электронной почты автоматически преобразуются в ссылки.
  • Допустимые HTML-теги: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Строки и абзацы переносятся автоматически.

Plain text

  • HTML-теги не обрабатываются и показываются как обычный текст
  • Адреса страниц и электронной почты автоматически преобразуются в ссылки.
  • Строки и абзацы переносятся автоматически.
CAPTCHA
Этот вопрос задается для того, чтобы выяснить, являетесь ли Вы человеком или представляете из себя автоматическую спам-рассылку.
Target Image