Pull to refresh

По мотивам Cisco Live 2009: Advanced Concepts of DMVPN

Reading time 15 min
Views 35K
Продолжая серию статей о VPN, хочу поделиться подробностями о реализации технологии DMVPN, изложенными на Cisco Live 2009. Осторожно, много букв :)

Начну по сложившейся традиции с постановки задачи.

Итак, у нас есть центральный офис и несколько филиалов, мы их хотим объединить в общую сеть с использованием публичных каналов связи (Internet).
image
В отличие от описанной технологии GET VPN, использование интернет-каналов обязывает нас использовать туннелирование (замену заголовка).

Что же такое Dynamic Multipoint VPNs (DMVPN)? Если коротко — это объединение multipoint GRE (mGRE) c IPSec.
mGRE — протокол туннелирования, отличающийся от традиционного GRE возможностью установления туннелей с несколькими соседями на одном интерфейсе. В основе лежит использование Next-Hop Resolution Protocol (NHRP), который позволяет динамически устанавливать такие соединения. IPSec, взаимодействуя с NHRP, по необходимости устанавливает SA и обеспечивает шифрование каждого отдельно соединения.

Важно, что хотя топология соединений — классический hub-n-spoke, DMVPN позволяет динамически устанавливать туннели spoke-to-spoke.

Если совсем коротко, идея NHRP состоит в задании хаба или NHS (Next-Hop Server), указанного для всех spoke статически. Каждый spoke регистрируется динамически (т.е. изначально NHS не знает адресов spoke), устанавливает постоянный туннель с NHS и NHS вносит соответствие его туннельного и реально адреса (mapping) в базу соседей, а также по необходимости сообщает об этом остальным spoke, чтобы они могли установить соединения друг с другом напрямую, а не через хаб. Соединения spoke-to-spoke, в отличие от hub-to-spoke, не постоянные, а временные. Как только трафик между филиалами отсутствует некоторое время, туннель между ними удаляется. Это позволяет использовать в качестве spoke-маршрутизаторов более слабые модели, поскольку на них нет необходимости держать столько соединений, сколько есть spoke. В качестве хаба же, наоборот, приходится выбирать маршрутизатор достаточно сильный, чтобы выдержать соединение со всеми spoke.
image
Поскольку каждый филиал сообщает хабу о своем существовании (посредством регистрации) динамически, то филиальные маршрутизаторы могут быть скрыты за dynamic NAT. А т.к. хаб конфигурится на каждом филиальном маршрутизаторе статически, то он может находиться только за статическим NAT.

Теперь введем понятие фаз DMVPN. Под фазами в данном случае понимается тип (или характер) взаимодействия spoke-to-spoke или spoke-to-hub. Всего существует три фазы.
Phase 1. Реализованы только туннели hub-to-spoke, туннели spoke-to-spoke не устанавливаются и весь трафик течет через хаб. При этом логично заменять в протоколах маршрутизации next-hop с адреса NHC на адрес NHS.
Регистрация проходит следующим образом:
image
Т.е. сначала устанавливается IPSec-туннель, потом NHC шлет сообщение NHRP registration request.
Интервал между сообщениями — 1/3 'ip nhrp registration holdtime' или 'ip nhrp registration timeout'. Если NHS не отвечает — интервал увеличивается в геометрической прогрессии, начиная с 1 (1, 2, 4, 8..., 64,… ). При этом, уже после третьей попытки NHS будет помечен как Down и не будет использоваться. Иными словами, registration requests выполняют еще и функцию keepalive.
Каждое сообщение NHRP Registration содержит соответствие туннельного адреса NHC и его реального адреса (NBMA) и может содержать еще заголовки расширения, например аутентификацию, NAT и т.п.

Ответ на это сообщение — естественно NHRP registration reply. Содержит соответствие реального и туннельного адресов NHC и NHS, а также все те же заголовки расширения. Фактически еще и подтверждает жизнеспособность хаба.
После регистрации NHC, вывод таблицы NHRP выглядит так:
На Hub:
HUB#sh ip nhrp
10.1.1.2/32 via 10.1.1.2, Tunnel0 created 15:17:10, expire 01:22:43
Type: dynamic, Flags: unique registered
NBMA address: 172.16.2.1
10.1.1.3/32 via 10.1.1.3, Tunnel0 created 15:17:10, expire 01:22:43
Type: dynamic, Flags: unique registered
NBMA address: 172.16.3.1

На Spoke 1:
SPOKE1#sh ip nhrp
10.1.1.1/32 via 10.1.1.1, Tunnel0 created 15:17:45, never expire
Type: static, Flags: used
NBMA address: 172.16.1.1


Раз уж мы коснулись вывода mapping, то давайте обсудим типы и флаги, соответствующие этим mapping.
Типы
  1. Static — запись, для которой на интерфейсе явно прописано соответствие туннельного адреса и реального (ip nhrp map ...)
  2. Dynamic — запись, полученная по NHRP. Бывает двух видов:
  3. Incomplete — мы знаем туннельный адрес spoke, но еще не получили ответ на NHRP Resolution request.

Флаги
  1. Unique. Означает, что данный mapping — уникальный и в случае смены NBMA адреса обновление этой записи проводиться не будет.
  2. Registered — получена из NHRP Registration, обычно бывает на хабе.
  3. Learned — получена из NHRP Registration, наоборот, обычно на spoke.\
  4. Authoritative. Может использоваться для ответов на NHRP resolution request.
  5. Used. Запись использовалась в предшествующие 60 секунд.
  6. Router. Записи для удаленного роутера или для сетей за ним маркируются таким флагом.
  7. Implicit. Запись получена из информации о источнике в NHRP пакете.
  8. Local. Информация о нашей локальной сети, которую мы отдали какому-то другому spoke в ответ на NHRP request. Хранит также NBMA адрес этого spoke.
  9. NAT. (появилась в 12.4(6)Т версии IOS, не показывается после 12.4(15)Т. Показывает, что удаленный пир поддерживает работу через NAT. После 12.4(15) Т просто показывается в записи еще и claimed NBMA адрес.
  10. no socket. Запись, для которой роутер не имеет необходимости или не хочет устанавливать IPSec туннель, потому что нет трафика, которому этот туннель нужен. Если в дальнейшем такой трафик появится, то запись будет преобразована в “socket” и туннель IPsec будет поднят. Записи типа Local и implicit всегда сначала маркируются как “no socket”. Кроме того, NHRP по умолчанию кэширует информацию об источнике из NHRP resolution request или reply, когда они проходят через роутер. Чтобы разрешить такое кэширование, но не поднимать IPSec-туннель, они маркируются как (no socket). Если этого не сделать, будут образованы лишние IPSec сокеты от хаба к spoke, которые не будут использоваться. Данные, прибывающие на туннельный интерфейс и уходящие с него не могут использовать (no socket) запись, поскольку в этом случае роутер является промежуточной нодой на пути между двумя взаимодействующими, и мы вряд ли захотим поднимать еще один туннель с промежуточной точкой. Если же в какой-то момент времени роутер получит пакет данных, который пришел не с туннельного интерфейса и должен использовать (nmo socket) запись, роутер преобразует ее в (socket) запись, поскольку в этом случае роутер будет являться точкой выхода в туннель для этого потока данных. Так же, эти (no socket) записи маркируются как (non-authoritative), поскольку только полученные из NHRP registrations записи маркируются как (authoritative).
  11. Negative. Означает, что запрошенный mapping еще не получен. Когда NHRP шлет NHRP resolution request, он ставит этот (negative) флаг на запись типа incomplete, что избавляет роутер от многократных отправок этих запросов в ожидании ответа или установления IPSec соединения.


После регистрации происходит обмен маршрутной информацией, в которой хаб ставит себя в качестве next-hop для каждого маршрута. После этого NHC могут обмениваться данными, но через хаб.

Из преимуществ такой технологии можно отметить наличие всего одного туннеля на каждом NHC, что позволяет экономить ресурсы.
Недостаток очевиден: маршрутизация через хаб не только нагружает его, но и приводит к существенным задержкам при передаче.

Phase 2. Здесь мы уже можем строить туннели spoke-to-spoke, для чего используется «обман» CEF. Все филиалы получают полностью маршрутную информацию с неизменным next-hop (дальше поясню, как это сделать).

NHC, получив такой маршрут от NHS, помещает для маршрута соответствующую CEF-запись, отмеченную как «invalid», а для next-hop адреса (т.е. адреса другого NHC) — запись типа glean (т.е. адрес L3 должен быть разрешен в адрес L2). Это разрешение осуществляется NHRP, когда первый пакет будет отправлен по этому маршруту.

Пример таких записей:

SPOKE1#sh ip cef 192.168.2.0
192.168.2.0/24, version 27, epoch 0
0 packets, 0 bytes
via 10.1.1.3, Tunnel0, 0 dependencies
next hop 10.1.1.3, Tunnel0
invalid adjacency
SPOKE1#sh ip cef 10.1.1.3
10.1.1.0/24, version 20, epoch 0, attached, connected
0 packets, 0 bytes
via Tunnel0, 0 dependencies
valid glean adjacency


На уровне NHRP тоже существует три вида записей, соответствующих второй фазе.
  1. Запись отсутствует. Все прозрачно, трафик отправляется к NHS, в след за ним летит NHRP resolution request.
  2. Запись типа (no socket). Вроде знаем кому отправлять, но не установлено IPSec соединение. Трафик по-прежнему летит к NHS, и устанавливается соединение с другим NHC
  3. Запись типа (socket). Трафик летит к другому NHC по IPSec туннелю.


Первый пакет будет отправлен через NHS с использованием process switching. NHC пошлет NHS NHRP resolution request, на который NHS ответит адресом, позволяющим дозаполнить запись в CEF.

Особенность. До IOS 12.4.5a запрос и ответ проходил всю цепочку NHS. После (не на 6500 и 7600) функцию ответа на NHRP resolution request переложили на сам NHC, адрес которого нас интересует. Схема взаимодействия новой реализации phase представлена на рисунке:
image

Пример вывода команды debug nhrp packet для phase 2.
SPOKE1#ping 192.168.2.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/41/72 ms
SPOKE1#
*Mar 1 00:30:01.367: NHRP: Send Resolution Request via Tunnel0 vrf 0, packet size: 81
*Mar 1 00:30:01.367: src: 10.1.1.2, dst: 10.1.1.3
*Mar 1 00:30:01.371: (F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1
*Mar 1 00:30:01.371: shtl: 4(NSAP), sstl: 0(NSAP)
*Mar 1 00:30:01.371: (M) flags: "router auth src-stable", reqid: 4
*Mar 1 00:30:01.371: src NBMA: 172.16.2.1
*Mar 1 00:30:01.371: src protocol: 10.1.1.2, dst protocol: 10.1.1.3
*Mar 1 00:30:01.375: (C-1) code: no error(0)
*Mar 1 00:30:01.375: prefix: 0, mtu: 1514, hd_time: 7200
*Mar 1 00:30:01.375: addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0
*Mar 1 00:30:01.375: NHRP: Send Resolution Request via Tunnel0 vrf 0, packet size: 81
*Mar 1 00:30:01.379: src: 10.1.1.2, dst: 10.1.1.1
*Mar 1 00:30:01.379: (F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1
*Mar 1 00:30:01.379: shtl: 4(NSAP), sstl: 0(NSAP)
*Mar 1 00:30:01.383: (M) flags: "router auth src-stable", reqid: 4
*Mar 1 00:30:01.383: src NBMA: 172.16.2.1
*Mar 1 00:30:01.383: src protocol: 10.1.1.2, dst protocol: 10.1.1.3
*Mar 1 00:30:01.383: (C-1) code: no error(0)
*Mar 1 00:30:01.387: prefix: 0, mtu: 1514, hd_time: 7200
*Mar 1 00:30:01.387: addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0
*Mar 1 00:30:01.415: NHRP: Receive Resolution Reply via Tunnel0 vrf 0, packet size: 109
*Mar 1 00:30:01.415: (F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1
*Mar 1 00:30:01.415: shtl: 4(NSAP), sstl: 0(NSAP)
*Mar 1 00:30:01.415: (M) flags: "router auth dst-stable unique src-stable", reqid: 4
*Mar 1 00:30:01.419: src NBMA: 172.16.2.1
*Mar 1 00:30:01.419: src protocol: 10.1.1.2, dst protocol: 10.1.1.3
*Mar 1 00:30:01.419: (C-1) code: no error(0)
*Mar 1 00:30:01.423: prefix: 32, mtu: 1514, hd_time: 6089
*Mar 1 00:30:01.423: addr_len: 4(NSAP), subaddr_len: 0(NSAP), proto_len: 4, pref: 0
*Mar 1 00:30:01.423: client NBMA: 172.16.3.1
*Mar 1 00:30:01.423: client protocol: 10.1.1.3


Наличие поля src NBMA позволяет NHC назначения отвечать минуя хаб.
Замечания.
  • Сохранение адреса next-hop на первый взгляд выглядит логичным и правильным решением. Но есть у него один недостаток: каждый NHC должен получить полностью всю таблицу маршрутизации от NHS, без использования суммаризации. Это позволяет использовать только один уровень NHS, т.е. мы можем обслуживать половину NHC одним NHS, другую половину — другим, но мы обязаны соединить их как NHS друг для друга. Это необходимо для того, чтобы позволить NHRP resolution request пройти все потенциальные NHS. А статическое их указание уменьшает общую надежность.
  • Ну и кроме того, первый пакет будет отправлен не через CEF, а через process switching.

Phase 3.
В этой фазе мы позволяем NHC участвовать в ответе на NHRP resolution requests, отбирая это «преимущество» у NHS.

Рассмотрим по шагам.
image
  1. NHC по традиции регистрируется на NHS, что позволяет последнему установить с NHC соседство по протоколу маршрутизации и обменяться маршрутной информацией. При этом, NHS не обязан сохранять маршрутную информацию в первозданном виде: он может поменять next-hop на себя и даже ее суммаризовать при этом. Более того, чем более общий маршрут мы пошлем обратно NHC, тем легче ему будет :)
  2. NHC получает маршрутную информацию и заполняет CEF-таблицу. Поскольку у теперь next-hop у нас теперь сам NHS, у нас не будет «invalid» или «glean» записей. Другими словами, первый пакет по такому маршруту будет отправлен с помощью CEF… куда???… правильно, на хаб! Но это, кроме всего прочего, означает, что отсутствие «неправильных» записей в CEF не будет вызывать NHRP resolution requests! И здесь на арену выходит NHRP redirect message!
  3. Шаг 3 — прямое продолжение второго. Итак, первый пакет, отправленный от spoke к другому spoke идет через NHS. Когда NHS получает по mGRE туннелю пакет, а потом вынужден отправить его обратно по этому же интерфейсу (но уже другому NHC), NHS шлет источнику такого пакета главную «фишку» третьей фазы — NHRP redirect message. Это сообщение говорит NHC, что он использует «не совсем правильный» :) путь в маршрутизации пакетов. И «намекает», что хорошо бы использовать NHRP resolution для уточнения пути у NHC. Сам же первый пакет тем не менее отправляется NHS по адресу.
  4. Опять продолжаем. Теперь NHC, пославший первый пакет, получает сообщение redirect, содержащее адрес назначения того самого первого пакета. Этот NHC шлет NHRP resolution request об этом же IP, но (внимание!!!) не к NHS, а опять по этому же адресу! Т.е. NHC спрашивает другого NHC о его реальном адресе. Еще раз: адрес назначения в NHRP resolution request не NHS, а именно тот NHC, которым мы интересуемся, хотя мы и (как и первый пакет) будем до него добираться через NHS. NHS отправит его тем же самым путем по назначению (т.е. опять пакет пойдет через хаб, неоптимально).
  5. Развязка :) Теперь наш NHC назначения (а не NHS!!) отвечает на resolution request. Используя реальный адрес, приложенный к запросу, этот NHC ответит отправителю напрямую, минуя NHS. При этом, ответ будет содержать всю сеть (маршрут, префикс), найденный в RIB, а не только запрошенный адрес. Когда наш NHC-отправитель запроса получит такой ответ, он узнает реальный next-hop такого адреса, заполнит NHRP-таблицу и поправит запись в CEF (или новую создаст).


Пример дебажного вывода:
SPOKE2#ping 192.168.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/51/84 ms
SPOKE2#
*Mar 1 00:07:57.151: NHRP: Receive Traffic Indication via Tunnel0 vrf 0, packet size: 97
*Mar 1 00:07:57.155: (F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1
*Mar 1 00:07:57.155: shtl: 4(NSAP), sstl: 0(NSAP)
*Mar 1 00:07:57.159: (M) traffic code: redirect(0)
*Mar 1 00:07:57.159: src NBMA: 172.16.1.1
*Mar 1 00:07:57.159: src protocol: 10.1.1.1, dst protocol: 10.1.1.3
*Mar 1 00:07:57.163: Contents of nhrp traffic indication packet:
*Mar 1 00:07:57.167: 45 00 00 64 00 00 00 00 FE 01 EF EB 0A 01 01 03
*Mar 1 00:07:57.171: C0 A8 01 01 08 00 36 7F 00 00 00
*Mar 1 00:07:57.211: NHRP: Send Resolution Request via Tunnel0 vrf 0, packet size: 85
*Mar 1 00:07:57.215: src: 10.1.1.3, dst: 192.168.1.1
*Mar 1 00:07:57.219: (F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1
*Mar 1 00:07:57.219: shtl: 4(NSAP), sstl: 0(NSAP)
*Mar 1 00:07:57.219: (M) flags: "router auth src-stable nat ", reqid: 5
*Mar 1 00:07:57.219: src NBMA: 172.16.3.1
*Mar 1 00:07:57.219: src protocol: 10.1.1.3, dst protocol: 192.168.1.1
*Mar 1 00:07:57.219: (C-1) code: no error(0)
*Mar 1 00:07:57.219: prefix: 0, mtu: 1514, hd_time: 7200
*Mar 1 00:07:57.219: addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0
*Mar 1 00:07:57.247: NHRP: Receive Resolution Request via Tunnel0 vrf 0, packet size: 105
*Mar 1 00:07:57.251: (F) afn: IPv4(1), type: IP(800), hop: 254, ver: 1
*Mar 1 00:07:57.251: shtl: 4(NSAP), sstl: 0(NSAP)
*Mar 1 00:07:57.255: (M) flags: "router auth src-stable nat ", reqid: 6
*Mar 1 00:07:57.255: src NBMA: 172.16.2.1
*Mar 1 00:07:57.259: src protocol: 10.1.1.2, dst protocol: 10.1.1.3
*Mar 1 00:07:57.263: (C-1) code: no error(0)
*Mar 1 00:07:57.263: prefix: 0, mtu: 1514, hd_time: 7200
*Mar 1 00:07:57.263: addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0
*Mar 1 00:07:57.271: NHRP: Send Resolution Reply via Tunnel0 vrf 0, packet size: 133
*Mar 1 00:07:57.275: src: 10.1.1.3, dst: 10.1.1.2
*Mar 1 00:07:57.279: (F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1
*Mar 1 00:07:57.279: shtl: 4(NSAP), sstl: 0(NSAP)
*Mar 1 00:07:57.283: (M) flags: "router auth dst-stable unique src-stable nat ", reqid: 6
*Mar 1 00:07:57.283: src NBMA: 172.16.2.1
*Mar 1 00:07:57.287: src protocol: 10.1.1.2, dst protocol: 10.1.1.3
*Mar 1 00:07:57.291: (C-1) code: no error(0)
*Mar 1 00:07:57.291: prefix: 32, mtu: 1514, hd_time: 7200
*Mar 1 00:07:57.295: addr_len: 4(NSAP), subaddr_len: 0(NSAP), proto_len: 4, pref: 0
*Mar 1 00:07:57.299: client NBMA: 172.16.3.1
*Mar 1 00:07:57.299: client protocol: 10.1.1.3
*Mar 1 00:07:57.323: NHRP: Receive Resolution Reply via Tunnel0 vrf 0, packet size: 153
*Mar 1 00:07:57.331: (F) afn: IPv4(1), type: IP(800), hop: 254, ver: 1
*Mar 1 00:07:57.331: shtl: 4(NSAP), sstl: 0(NSAP)
*Mar 1 00:07:57.331: (M) flags: "router auth dst-stable unique src-stable nat ", reqid: 5
*Mar 1 00:07:57.335: src NBMA: 172.16.3.1
*Mar 1 00:07:57.339: src protocol: 10.1.1.3, dst protocol: 192.168.1.1
*Mar 1 00:07:57.343: (C-1) code: no error(0)
*Mar 1 00:07:57.343: prefix: 24, mtu: 1514, hd_time: 7200
*Mar 1 00:07:57.343: addr_len: 4(NSAP), subaddr_len: 0(NSAP), proto_len: 4, pref: 0
*Mar 1 00:07:57.347: client NBMA: 172.16.2.1
*Mar 1 00:07:57.347: client protocol: 10.1.1.2


Подчеркнутым выделено получение NHRP редиректа.

Подведем итоги третьей фазы:
  1. Нет неправильных записей в CEF. Все пакеты используют CEF, а NHRP request теперь вызываются не неправильной записью в CEF, а явным указанием от NHS.
  2. NHS теперь не единственный источник информации NHRP. В это вовлекли еще и остальные NHC. Больше похоже на peer2peer.
  3. NHRP replies от NHC содержит целый префикс, а не только next-hop. Именно это, кстати, позволяет нам посылать общий маршрут от NHS к NHC, т.к. NHC назначения вернет именно ему принадлежащий префикс, который может быть более частным, чем тот, что изначально получен от NHS.
  4. Первоначальные пакеты бегут через хаб.
  5. Поскольку ответ дает не NHS, а NHC, в топологии может быть несколько уровней хабов.

Теперь несколько подведем итоги по маршрутизации, вооружившись знаниями о фазах.

Постулат 1. NHC устанавливает соседство по протоколу маршрутизации только с NHS, и никогда с NHC. NHC сообщает о своих локальных сетях NHS.
Постулат 2. NHS устанавливает соседство со всеми NHC. При этом он сообщает NHC о всех сетях, узнанных от других NHC и своих локальных сетях.
кроме того, вне зависимости от фазы, требуется выключать split horizon для RIP и EIGRP.
Но есть и различие в функционировании, в зависимости от фазы:
  1. В phase 1 и phase 3 хаб не может сохранять next-hop в маршрутной информации (например, BGP next-hop-self, OSPF network point-to-multipoint), за счет этого возможно применение суммаризации. Кроме того, число хабов не ограничено и они не обязаны быть одного уровня.
  2. В phase 2 напротив, хаб обязан сохранять next-hop в маршрутной информации (EIGRP no ip next-hop-self, BGP default, OSPF network broadcast), возможно использование не более двух хабов.

Постулат 3. NHS устанавливает соседство по протоколу маршрутизации с другими NHS. При этом
  1. В phase 1 и phase 3 протокол маршрутизации между хабами может отличаться от протокола маршрутизации между хабами и NHC.
  2. В phase 2 хабы обязаны использовать тот же протокол.


— Теперь, когда мы рассмотрели теоретические основы функционирования DMVPN, посмотрим, как его настроить на маршрутизаторах Cisco.
Настройка будет отличаться в зависимости от желамой фазы и роли роутера (Hub или spoke).

По порядку:

Hub с точки зрения NHRP настраивается одинаково для Phase 1 и Phase 2. Разница будет в настройке протоколов маршрутизации.

Создаем туннельный интерфейс и присваиваем ему адрес:
Hub(config)# interface Tunnel0
Hub(config-if)# ip address 10.1.1.1 255.255.255.0


Задаем интерфейс-источник и режим — GRE multipoint
Hub(config-if)# tunnel source FastEthernet0/0
Hub(config-if)# tunnel mode gre multipoint


Далее собственно задаем настройки протокола NHRP.
Идентификатор сети:
Hub(config-if)# ip nhrp network-id 123

Опционально аутентификацию:
Hub(config-if)# ip nhrp authentication cisco

И настраиваем маппинг мультикастовых рассылок в динамически узнаваемые адреса
Hub(config-if)# ip nhrp map multicast dynamic

Phase 3. Отличается от Phase 2 только наличием
Hub(config-if)# ip nhrp redirect

Spoke.

Phase 1.
Создаем туннельный интерфейс и присваиваем ему адрес:
Spoke1(config)# interface Tunnel0
Spoke1(config-if)# ip address 10.1.1.2 255.255.255.0


Задаем интерфейс-источник
Spoke1(config-if)# tunnel source FastEthernet0/0

Поскольку мы планируем связываться только с хабом — можем явно задать адрес назначения и тип туннеля — обычный GRE IP (по умолчанию)
Spoke1(config-if)# tunnel destination 172.16.1.1

Т.к. регистрироваться по протоколу NHRP все равно нужно, то задаем идентификатор сети:
Spoke1(config-if)# ip nhrp network-id 123

Опционально аутентификацию:
Spoke1(config-if)# ip nhrp authentication cisco

И настраиваем маппинг мультикастовых рассылок в адрес хаба (внимание, не туннельный, а реальный)
Spoke1(config-if)# ip nhrp map multicast 172.16.1.1

Указываем туннельный адрес NHS:
Spoke1(config-if)# ip nhrp nhs 10.1.1.1

И создаем маппинг для этого туннельного адреса в реальный:
Spoke1(config-if)# ip nhrp map 10.1.1.1 172.16.1.1

Phase 2.
Почти тоже самое, только задаем tunnel mode и не указываем tunnel destination:
Spoke1(config)# interface Tunnel0
Spoke1(config-if)# ip address 10.1.1.2 255.255.255.0
Spoke1(config-if)# tunnel source FastEthernet0/0
Spoke1(config-if)# tunnel mode gre multipoint
Spoke1(config-if)# ip nhrp network-id 123
Spoke1(config-if)# ip nhrp authentication cisco
Spoke1(config-if)# ip nhrp map multicast 172.16.1.1
Spoke1(config-if)# ip nhrp nhs 10.1.1.1
Spoke1(config-if)# ip nhrp map 10.1.1.1 172.16.1.1


Phase 3. Отличается от Phase 2 только наличием
Spoke1(config-if)# ip nhrp shortcut
Spoke1(config-if)# ip nhrp redirect


Таким образом, мы настроили mGRE. Осталось прицепить к нему IPSec. Настройка одинакова на всех роутерах.

Создаем политику ISAKMP
Router(config)#crypto isakmp policy 10
Router(config-isakmp)# encr aes
Router(config-isakmp)# authentication pre-share
Router(config-isakmp)# group 2


Для простоты описания я использую аутентификацию по общему ключу
Router(config-isakmp)#crypto isakmp key cisco address 0.0.0.0 0.0.0.0

Включаем keepalive
Router(config)#crypto isakmp keepalive 10 3 periodic

Создаем трансформ-сет и привязываем его к профайлу IPSec.
Router(config)#crypto ipsec transform-set IPSEC_SET esp-aes esp-sha-hmac
Router(cfg-crypto-trans)#crypto ipsec profile IPSEC_PROFILE
Router(ipsec-profile)# set transform-set IPSEC_SET


Цепляем профайл на туннельный интерфейс
Router(config)#interface tunnel 0
Router(config-if)#tunnel protection ipsec profile IPSEC_PROFILE


Теперь поговорим о настройках протоколов маршрутизации. Для простоты я ограничусь двумя наиболее распространенными IGP: OSPF и EIGRP, к тому же, один из них link-state, другой distance-vector.

Итак, как мы уже выяснили, phase 1 & 3 обязуют хаб менять next-hop в маршрутной информации на свой адрес, поэтому
OSPF: Hub(config-if)# ip ospf network point-to-multipoint
В случае EIGRP next-hop меняется по умолчанию и дополнительных усилий не требует.
Кроме того, в случае EIGRP и RIP требуется отключать split-horizon : Hub(config-if)#no ip split-horizon eigrp AS_NUMBER

На spoke все просто: настраиваем тип сети OSPF и принудительно запрещаем spoke быть DR или BDR.
OSPF: Spoke(config-if)# ip ospf network point-to-multipoint
Spoke(config-if)# ip ospf priority 0


Для phase 2 немного по-другому.

На хабе нам уже не требуется менять next-hop, но split horizon нам по-прежнему мешает. Поэтому
OSPF: Hub(config-if)# ip ospf network broadcast (таймеры по вкусу)
EIGRP: Hub(config-if)#no ip next-hop-self eigrp AS_NUMBER
Hub(config-if)#no ip split-horizon eigrp AS_NUMBER


На spoke тоже настраиваем тип сети OSPF как broadcast и поскольку нам нужно соседство только с хабом, то по-прежнему принудительно запрещаем spoke быть DR или BDR.
OSPF: Spoke(config-if)# ip ospf network broadcast
Spoke(config-if)# ip ospf priority 0


Подведем итоги технологии.
  • DMVPN — технология, позволяющая строить VPN со множеством участников. Основная топология — hub-n-spoke, но возможно динамическое установление туннелей spoke-to-spoke и даже иерархия хабов.
  • В основе лежит mGRE (а в его основе — NHRP), а защита возложена на IPSec, тесно с ним взаимодействующий.
  • Нагрузка на хаб в общем случае больше, чем на spoke. Это позволяет использовать оборудование, различающееся по производительности, в зависимости от нужд конкретного филиала.
  • Характер работы напрямую зависит от настроенной фазы.
  • Конфигурация протоколов маршрутизации тоже требует внимательности.
  • Из недостатков хотел бы отметить ограниченность поддержки мультикастов и отсутствие поддержки на Cisco ASA (хнык...)


За сим разрешите откланяться :) Конечно, опять не надеюсь на то, что раскрыл все аспекты технологии. За кадром как минимум остались конфигурация с множеством хабов и т.п. Но надеюсь, что общее представление о технологии мне изложить удалось.

Всячески надеюсь на конструктивную критику, т.к. статья большая и наверняка в ней полно неточностей, ошибок и опечаток.

Подкопаев Илья, инструктор

UPD. Спасибо Quickshooter за найденную ошибку :)
Tags:
Hubs:
+3
Comments 17
Comments Comments 17

Articles