> For the complete documentation index, see [llms.txt](https://linkmeup.gitbook.io/sdsm/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://linkmeup.gitbook.io/sdsm/7.-vpn/5.-dmvpn/0.-teoriya-i-praktika.md). # Теория и практика DMVPN Абстрагируясь от нашей старой сети, возьмём в рассмотрение только Москву, сеть Интернет, которую будет эмулировать маршрутизатор Балаган-Телеком, и собственно филиалы в Новосибирске, Томске и Брно: ![](http://img-fotki.yandex.ru/get/4116/83739833.23/0_abac0_a0da6ce2_XL.jpg) Новый IP-план:\ Подсети, выделенные для подключения к интернету филиалов: ![](http://img-fotki.yandex.ru/get/5638/83739833.23/0_abbe5_7cdef57c_XL.jpg) LAN: ![](http://img-fotki.yandex.ru/get/5644/83739833.23/0_abbe6_5d8f81b1_XL.jpg) Для туннельных интерфейсов возьмём внутреннюю сеть: ![](http://img-fotki.yandex.ru/get/6433/83739833.23/0_abbe7_19c2e9b9_XL.jpg) И назначим также адреса Loopback для них: ![](http://img-fotki.yandex.ru/get/5633/83739833.23/0_abbe8_ae57f462_XL.jpg) Идея заключается в том, что на центральном узле будет один единственный динамический туннель, который мы настроим в самом начале, а при добавлении новых удалённых точек, здесь не нужны изменения – ни добавлять новые туннельные интерфейсы, ни перенастраивать уже существующий.\ Фактически при добавлении новых узлов настраивать нужно только их.\ Везде запускается протокол [NHRP](http://searchnetworking.techtarget.com/definition/Next-Hop-Resolution-Protocol) – NBMA Next Hop resolution Protocol.\ Он позволяет динамически изучать адреса удалённых точек, который желают подключиться к основной.\ На нём и основана возможность реализации multipoint VPN. Хаб (центральный узел) здесь выступает как сервер (NHS – Next-Hop Server), а все удалённые узлы будут клиентами (NHC – Next-Hop Client).\ Звучит это сложно. На пальцах объяснить тоже не получится. Надо лишь один раз настроить и посмотреть, как бегают пакеты. Конфигурация хаба: ``` interface Tunnel0 ip address 172.16.254.1 255.255.255.0 ip nhrp map multicast dynamic ip nhrp network-id 1 tunnel source FastEthernet0/1.6 tunnel mode gre multipoint ``` По порядку:\ *ip address 172.16.254.1 255.255.255.0* – IP-адрес из нужного диапазона.\ *ip nhrp map multicast dynamic* – Динамическое изучение данных NHRP от клиентов. Поскольку клиентов у нас множество и они могут быть с динамическими адресами, на хабе нельзя задать явное соответствие внутренних и внешних адресов.\ *ip nhrp network-id 1* – Определяем Network ID – просто идентификатор, который необязательно должен быть одинаковым на всех узлах DMVPN (похож на OSPF Router-ID).\ *tunnel source FastEthernet0/1.6* – наследие GRE – привязка к физическому интерфейсу.\ *tunnel mode gre multipoint* – Туннель на центральном узле будет терминировать все туннели от удалённых точек. То есть он будет точка-многоточка (Point-to-MultiPoint). Конфигурация филиала: ``` interface Tunnel0 ip address 172.16.254.2 255.255.255.0 ip nhrp map 172.16.254.1 198.51.100.2 ip nhrp map multicast 198.51.100.2 ip nhrp network-id 1 ip nhrp nhs 172.16.254.1 ip nhrp registration no-unique tunnel source FastEthernet0/0 tunnel mode gre multipoint ``` По порядку:\ *ip address 172.16.254.2 255.255.255.0* – IP-адрес из нужного диапазона.\ *ip nhrp map 172.16.254.1 198.51.100.2* – Статическое соотношение внутреннего и внешнего адресов хаба.\ *ip nhrp map multicast 198.51.100.2* мультикастовый трафик должен получать хаб. > Без этой команды у вас будут довольно интересные симптомы проблемы.\ > Вот вы запустили OSPF, пиринг поднимается, хаб и филиалы переходят в состояние Full, обменялись маршрутами, и вы уже радуетесь, что всё отлично, и тут бац – пинг пропадает, пиринг падает, но только с одной стороны, мол истёк dead-timer.\ > \ > *Mar 1 01:51:20.331: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.255.2 on Tunnel0 from FULL to DOWN, Neighbor Down: Dead timer expired*\ > *msk-arbat-gw1#*\ > *Mar 1 01:51:25.435: %OSPF-5-ADJCHG: Process 1, Nbr 172.16.255.2 on Tunnel0 from LOADING to FULL, Loading Done*\ > \ > Что за фигня?\ > Смотрим дебаг, смотрим дампы\ > \ > *Mar 1 01:53:44.915: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.4 from 172.16.2.1*\ > *Mar 1 01:53:44.919: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.7 from 172.16.2.33*\ > *Mar 1 01:53:44.923: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.5 from 172.16.2.17*\ > *Mar 1 01:53:44.923: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.8 from 172.16.2.129*\ > *Mar 1 01:53:44.963: OSPF: Send hello to 224.0.0.5 area 0 on Tunnel0 from 172.16.254.1*\ > *msk-arbat-gw1#*\ > *Mar 1 01:53:54.919: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.4 from 172.16.2.1*\ > *Mar 1 01:53:54.923: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.7 from 172.16.2.33*\ > *Mar 1 01:53:54.927: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.5 from 172.16.2.17*\ > *Mar 1 01:53:54.931: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.8 from 172.16.2.129*\ > *Mar 1 01:53:54.963: OSPF: Send hello to 224.0.0.5 area 0 on Tunnel0 from 172.16.254.1*\ > *msk-arbat-gw1#*\ > *Mar 1 01:54:04.919: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.4 from 172.16.2.1*\ > *Mar 1 01:54:04.927: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.7 from 172.16.2.33*\ > *Mar 1 01:54:04.931: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.5 from 172.16.2.17*\ > *Mar 1 01:54:04.935: OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/1.8 from 172.16.2.129*\ > *\*Mar 1 01:54:04.963: OSPF: Send hello to 224.0.0.5 area 0 on Tunnel0 from 172.16.254.1*\ > \ > ![](http://img-fotki.yandex.ru/get/6427/83739833.23/0_abbfc_db7c306e_XXL.jpg)\ > На 5 OSPF Hello от хаба только один Hello от филиала.\ > Как вы уже поняли, маршрутизатор просто не может сообразить куда посылать мультикастовые сообщения на адрес 224.0.0.5, хаб их не получает и дёргает OSPF-сессию. *ip nhrp network-id 1* – Network ID. Не обязательно должен совпадать с таким же на хабе.\ *ip nhrp nhs 172.16.254.1* – Статически настроенный адрес NHRP сервера – хаба. Именно поэтому в центре нам нужен статический публичный адрес. Клиенты отправляют запрос на регистрацию на хаб 172.16.254.1. Этот запрос содержит настроенный локальный адрес туннельного интерфейса, а также свой публичный адрес (случай, когда клиент находится за NAT пока не рассматриваем).\ Полученную информацию хаб заносит в свою NHRP-таблицу соответствия адресов. Эту же таблицу он распространяет по запросу любому Spoke-маршрутизатору. *ip nhrp registration no-unique* – если адрес в филиалах выдаётся динамически, эта команда обязательна.\ *tunnel source FastEthernet0/0* – привязка к физическому интерфейсу.\ *tunnel mode gre multipoint* – указываем, что тип туннеля mGRE – это позволит создавать динамически туннели не только до хаба, но и до других филиалов. У нас ситуация простая – без NAT – и мы можем уже сейчас проверить состояние туннелей. > msk-arbat-gw1#sh int tun 0\ > **Tunnel0 is up, line protocol is up**\ > Hardware is Tunnel\ > Internet address is 172.16.254.1/24\ > MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,\ > reliability 255/255, txload 1/255, rxload 1/255\ > Encapsulation TUNNEL, loopback not set\ > Keepalive not set\ > **Tunnel source 198.51.100.2 (FastEthernet0/1.6), destination UNKNOWN**\ > **Tunnel protocol/transport multi-GRE/IP**\ > Key disabled, sequencing disabled\ > Checksumming of packets disabled > > msk-arbat-gw1#ping 172.16.254.2\ > \ > Type escape sequence to abort.\ > Sending 5, 100-byte ICMP Echos to 172.16.254.2, timeout is 2 seconds:\ > !!!\ > Success rate is 100 percent (5/5), round-trip min/avg/max = 176/213/284 ms > > msk-arbat-gw1#sh ip nhrp brief\ > Target Via NBMA Mode Intfc Claimed\ > 172.16.254.2/32 172.16.254.2 198.51.101.2 dynamic Tu0 < >\ > msk-arbat-gw1#sh ip nhrp\ > 172.16.254.2/32 via 172.16.254.2, Tunnel0 created 00:09:48, expire 01:50:11\ > Type: dynamic, Flags: authoritative unique registered\ > NBMA address: 198.51.101.2\ > \ > nsk-obsea-gw1#sh ip nhrp brief\ > Target Via NBMA Mode Intfc Claimed\ > 172.16.254.1/32 172.16.254.1 198.51.100.2 static Tu0 < >