Ранее мы уже рассматривали вопросы построения DMVPN в статье DMVPN и EIGRP
В данной статье обсуждается конфигурация DMVPN и EIGRP для работы с основным и резервным провайдером.
Очень часто в центральный офис компании имеет смысл провести два ISP одновременно. Это делается с целью обеспечения надежности подключения к интернету в случае сбоя одного из провайдеров.
Рассмотрим практический пример построения туннелей DMVPN для автоматического переключения на резервного провайдера.
В центральном офисе располагаются два маршрутизатора, каждый из которых подключен к основному и резервному провайдеру соответственно.
Каждый HUB поддерживает свой туннельный интерфейс, таким образом на каждый SPOKE терминируются одновременно два туннеля.
Переключение производится с помощью EIGRP.
Primary HUB держит шифрованный туннель,
Secondary HUB имеет слабое железо (C891) и свой туннель не шифрует.
!----------------------------------------------
! 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
!----------------------------------------------
! 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
!----------------------------------------------
!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
Комментарии
DMVPN
А что если у нас есть два провайдера, и остатки L2 "VPN" сети в достаточном количестве.
Т.е часть споков будет коннектится к хабам снаружи, а часть необходимо сконнектить внутри сети, т.е если смотреть на схему сети, со стороны интерфейсов с адресами 10.5.14.95 и 10.5.14.96
Никаких проблем
Только я бы порекомендовал, чтобы на каждом споке была своя IP подсеть и свой маршрутизатор. Даже если у вас L2 VPN не надо городить все в одной подсети.
DMVPN
А вы могли бы привести пример реализации такой же схемы, но с условием что Spoke тоже имеют по 2 ISP. Каким образом организовать переключение туннелей?
Спасибо!
2 ISP у SPOKE
У меня это работает следующим образом:
Если смотреть по схеме статьи, то на 3825 на внешний интерфейс вешается еще один IP, например 187.237.40.108. И аналогично строится дополнительный DMVPN туннель для этого IP.
На SPOKE мы также строим дополнительный туннель до 187.237.40.108. Также в конфиге SPOKE мы добавляем статический маршрут до 187.237.40.108 через резервный ISP.
DMVPN
Здравствуйте ещё раз,
а могли бы вы глянуть на тему 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 туннель от филиала по резервному. Можно сделать аналогично и для второго хаба, но у меня пока на практике такого не было, чтобы упали одновременно основной в ц офисе и основной в филиале. Будет время опишу в статье этот момент, но в принципе все аналогично
DMVPN
C вашего позволения ещё вопрос,
как мне организовать NAT для тех кто за Spoke роутерами.
T.e NAT для 192.168.xxx.xxx Spoke (<--- NAT INSIDE) > HUB (NAT Outside ---->)>internet
Мозг уже сломал. Не вешать же на тунельных интерфейсах NAT inside
DMVPN
Я правильно понимаю,
этот документ как раз и описывает то что я хочу?
http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_e...
На этом примере
На этом примере нат производится в каждом филиале отдельно.
Т.е. применительно к этой статье, для того чтобы сделать нат на spoke1, мы дадим следующие классические команды:
Это рабочий конфиг, прекрасно живет с DMVPN и с EIGRP или OSPF. Тут не нужны лишние роутмапы "nonat", не усложняйте
NAT
Вы хотите чтобы трафик от клиентов 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
Добавить комментарий