Теория и практика DMVPN

Абстрагируясь от нашей старой сети, возьмём в рассмотрение только Москву, сеть Интернет, которую будет эмулировать маршрутизатор Балаган-Телеком, и собственно филиалы в Новосибирске, Томске и Брно:

Новый IP-план: Подсети, выделенные для подключения к интернету филиалов:

LAN:

Для туннельных интерфейсов возьмём внутреннюю сеть:

И назначим также адреса Loopback для них:

Идея заключается в том, что на центральном узле будет один единственный динамический туннель, который мы настроим в самом начале, а при добавлении новых удалённых точек, здесь не нужны изменения – ни добавлять новые туннельные интерфейсы, ни перенастраивать уже существующий. Фактически при добавлении новых узлов настраивать нужно только их. Везде запускается протокол NHRP – 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 На 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 < >