DMVPN в деталях

Введение в EIGRP часть первая.
16.04.2017
Путь к CCIE
Путь к CCIE
08.05.2017

DMVPN в деталях

DMVPN в деталях

DMVPN в деталях

DMVPN расшифровывается как Dynamic Multipoint VPN и является эффективным решением для динамических защищенных оверлейных сетей. Проще говоря, DMVPN — это комбинация следующих технологий:

1) Многоточечная GRE (mGRE)
2) Протокол разрешения следующего перехода (NHRP)
4) Протокол динамической маршрутизации (EIGRP, RIP, OSPF, BGP)
3) Динамическое шифрование посредством IPsec
5) Cisco Express Forwarding (CEF)

Предполагая, что читатель имеет общее представление о том, что такое DMVPN, и хорошее понимании IPsec / CEF, я подробно расскажу о роли и функции каждого компонента. В этой статье я проиллюстрирую два основных этапа DMVPN:

1) Фаза 1 — Hub и Spole (концентратор mGRE, p2p GRE споки)
2) Фаза 2 — Hub и Spoke с туннелями Spoke-Spoke (mGRE везде)

Что касается Фазы 3 DMVPN — «Масштабируемая инфраструктура», для освещения этой темы требуется отдельный пост. Это связано с существенными изменениями, внесенными в логику разрешения NHRP (переадресация и ярлыки NHRP), которые лучше иллюстрируются, когда читатель хорошо понимает первые две фазы. Тем не менее, некоторые намеки о Фазе 3 также будут представлены в этом посте.

Многоточечная GRE

Начнем с базового компонента построения DMVPN — многоточечного туннеля GRE. Классический туннель GRE — точка-точка, но mGRE обобщает эту идею, позволяя туннелю иметь «несколько» мест назначения.

Это может показаться естественным, если адрес назначения туннеля является мультикастом (например, 239.1.1.1). Туннель может использоваться для эффективного распределения одной и той же информации (например, видеопотока) по нескольким адресатам в верхней части сети с поддержкой многоадресной рассылки. Собственно, именно так mGRE используется для реализации многоадресной VPN в Cisco IOS. Однако, если конечные точки туннеля должны обмениваться одноадресными пакетами, специальный «клей» необходим для сопоставления IP-адресов туннеля с «физическими» или «реальными» IP-адресами, используемыми конечными маршрутизаторами. Как мы увидим позже, этот клей называется NHRP.

Обратите внимание, что если вы используете несколько туннелей mGRE для одного и того же интерфейса (например, Loopback0) для одного маршрутизатора, GRE может использовать специальное поле «мультиплексор» в заголовке туннеля для их отличия. Это поле известно как «ключ туннеля», и вы можете определить его в конфигурации туннеля. На самом деле, до IOS 12.3 (14) T или 12.3 (11) T3 использование «ключа туннеля» было обязательным — туннель mGRE не появлялся до тех пор, пока не будет настроен ключ. Начиная с упомянутых версий, вы можете настроить туннель без ключа. Это требование было устранено по двум причинам. Во-первых, аппаратные ASIC платформы 6500 и 7600 не поддерживают обработку ключа туннеля mGRE, и поэтому оптимальная производительность коммутации на этих платформах падает при настройке ключа туннеля. Во-вторых, как мы увидим позже, DMVPN Phase 3 допускает взаимодействие между разными туннелями mGRE, использующими один и тот же идентификатор сети NHRP, только если у них один и тот же ключ туннеля или вообще нет ключа туннеля (поскольку это позволяет отправлять пакеты «между «Туннели»).

NHRP

Теперь перейдем к компоненту, который делает DMVPN действительно динамичным — NHRP. Протокол был определен довольно давно в RFC 2332 (1998 год) для создания схемы оптимизации маршрутизации в сетях NBMA (без широковещательного множественного доступа), таких как ATM, Frame Relay и SMDS (кто-нибудь помнит об этом сейчас? :) Основная идея заключалась в использовании SVC (коммутируемых виртуальных каналов) для создания временных ссылок в облаке NBMA без фул-меш технологии. Рассмотрим следующую схематическую иллюстрацию, где IP-подсеть 10.0.0.0/24 накладывает частично облачное облако NBMA. NHRP аналогичен по функциям ARP, что позволяет разрешать адреса L3 до L2, но делает это более эффективным способом, подходящим для частично сцепленных облаков NBMA, поддерживающих динамические соединения уровня L2.

Ниже приведена упрощенная и схематическая иллюстрация процесса NHRP. В вышеупомянутой топологии, чтобы R1 достиг R4, он должен посылать пакеты по PVC между R1-R2, R2-R3 и, наконец, R3-R4. Предположим, что облако NMBA позволяет использовать SVC (коммутируемые виртуальные каналы, динамические пути) — тогда было бы более разумным для R1 установить SVC напрямую с R4 и отправить пакеты оптимальным способом. Однако для этого требуется, чтобы R1 знал адрес NMBA (например, ATM NSAP), связанный с R4, чтобы «поместить вызов». Желательно, чтобы R1 научился R4 IP-адресу NSAP (NBMA-адрес) динамически.

Теперь предположим, что мы включили NHRP на всех интерфейсах NBMA в сети. Каждый маршрутизатор в топологии действует как NHC (Next-Hop Client) или NHS (Next-Hop Server). Одна из функций NHC — зарегистрировать в NHS свой IP-адрес, сопоставленный с адресом уровня NBMA 2 (например, ATM NSAP-адрес). Чтобы сделать регистрацию возможной, вы настраиваете каждый NHC с IP-адресом по крайней мере одной NHS. В свою очередь, NHS действует как агент базы данных, сохраняя все зарегистрированные соответствия и отвечая на запросы NHC. Если NHS не имеет запрошенную запись в своей базе данных, он может перенаправить пакет другой NHS, чтобы проверить, имеет ли он запрашиваемую ассоциацию. Обратите внимание, что маршрутизатор может выступать в роли сервера и клиента Next-Hop одновременно. Вернемся к диаграмме, предположим, что R2 и R3 являются NHS, R1 и R4 являются NHC. Кроме того, предположим, что R4 является NHC и регистрирует свой IP-адрес для сопоставления адресов NBMA с R4, а R1 считает, что R2 является NHS. Оба R2 и R3 рассматривают друг друга как NHS. Когда R1 хочет отправить трафик на R4 (next-hop 10.0.0.4), он пытается разрешить 10.0.0.4, отправив запрос разрешения NHRP на R2 — настроенную NHS. В свою очередь, R2 направит запрос R3, поскольку он не имеет локальной информации.

Очевидно, современные сети, как правило, не слишком используют ATM / SMDS и Frame Relay SVC, но можно принять NHRP для работы с «имитируемыми NBMA» сетями, такими как туннели mGRE. Уровень NBMA сопоставляется с «физической» базовой сетью, в то время как mGRE VPN является «логической» сетью (внутренняя IP-адреса туннеля). В этом случае mGRE использует NHRP для сопоставления «логических» или «туннельных внутри» IP-адресов с «физическими» или реальными IP-адресами. Эффективно, NHRP выполняет описанную выше функцию «склейки», позволяя конечным точкам mGRE обнаруживать реальный IP-адрес друг друга. Так как NHRP определяет роль сервера, естественно, чтобы топология mGRE выстраивалась по принципу Hub-and-Spoke (или сочетания хабов и спиц, в более сложных случаях). Давайте посмотрим на некоторые конкретные сценарии, чтобы проиллюстрировать функциональность NHRP с помощью mGRE.

Фаза 1 NHRP

В фазе 1 NHRP mGRE использует NHRP для информирования концентратора о динамически появляющихся спицах. Изначально вы настраиваете каждый Spoke с IP-адресом концентратора(Hub) в качестве сервера NHS. Тем не менее, туннельный режим говорит: GRE (обычный двухточечный) туннель с фиксированным IP-адресом, равным физическому адресу концентратора. Spoke могут только достигать концентратора и только добираться до других Spoke сетей через концентратор. Преимуществом этапа 1 является упрощенная конфигурация маршрутизатора-концентратора, которая не требует статического сопоставления NHRP для каждого нового spoke.

Поскольку все пакеты проходят через концентратор, практически любой динамический протокол маршрутизации поможет достичь конечной цели. Хабу нужно просто рекламировать маршрут по умолчанию для spoke, в то время как spoke должны рекламировать свои подсети динамически в хабе. Вероятно, имеет смысл запустить EIGRP и суммировать все подсети до 0.0.0.0/0 на концентраторе, фактически отправляя маршрут по умолчанию ко всем spoke (если spoke не используют какой-либо другой маршрут по умолчанию, например, от своих провайдеров). Настройте spoke как STUB EIGRP и объявите их соответствующие подключенные сети. RIP можно настроить аналогичным образом, просто настроив туннели GRE на спицах как пассивные интерфейсы. Для EIGRP и RIP требуется отключить split-horisint на интерфейсе концентратора mGRE, чтобы обмениваться подсетями, говорящими на spoke. Что касается OSPF, оптимальным вариантом будет использовать тип сети точка-многоточка на всех интерфейсах GRE и mGRE. В дополнение к этому настройте фильтр базы данных ip ospf-all на концентраторе и настройте статические маршруты по умолчанию через туннельные интерфейсы на spoke (или статические конкретные маршруты для корпоративных сетей).

Вот пример конфигурации. Подробное объяснение команд NHRP и вывода команд «show» следует примеру.

R1:
!
! Hub router
!
router eigrp 123
 no auto-summary
 network 10.0.0.0 0.255.255.255
!
! Tunnel source
!
interface Loopback0
 ip address 150.1.1.1 255.255.255.0
!
! VPN network
!
interface Loopback 1
 ip address 10.0.1.1 255.255.255.0
!
! mGRE tunnel
!
interface Tunnel0
 ip address 10.0.0.1 255.255.255.0
 no ip redirects
 ip nhrp authentication cisco
 ip nhrp map multicast dynamic
 ip nhrp network-id 123
 no ip split-horizon eigrp 123
 ip summary-address eigrp 123 0.0.0.0 0.0.0.0 5
 tunnel source Loopback0
 tunnel mode gre multipoint
 tunnel key 123

R2:
!
! Spoke Router
!
router eigrp 123
 no auto-summary
 network 10.0.0.0 0.255.255.255
 eigrp stub connected
!
interface Loopback0
 ip address 150.1.2.2 255.255.255.0
!
interface Loopback 1
 ip address 10.0.2.2 255.255.255.0
!
! GRE tunnel
!
interface Tunnel0
 ip address 10.0.0.2 255.255.255.0
 ip nhrp authentication cisco
 ip nhrp map multicast 150.1.1.1
 ip nhrp map 10.0.0.1 150.1.1.1
 ip nhrp nhs 10.0.0.1
 ip nhrp network-id 123
 ip nhrp registration timeout 30
 ip nhrp holdtime 60
 tunnel source Loopback0
 tunnel destination 150.1.1.1
 tunnel key 123

R3:
!
! Spoke Router
!
router eigrp 123
 no auto-summary
 network 10.0.0.0 0.255.255.255
 eigrp stub connected
!
interface Loopback0
 ip address 150.1.3.3 255.255.255.0
!
interface Loopback 1
 ip address 10.0.3.3 255.255.255.0
!
interface Tunnel0
 ip address 10.0.0.3 255.255.255.0
 ip nhrp authentication cisco
 ip nhrp map multicast 150.1.1.1
 ip nhrp map 10.0.0.1 150.1.1.1
 ip nhrp nhs 10.0.0.1
 ip nhrp network-id 123
 ip nhrp registration timeout 30
 ip nhrp holdtime 60
 tunnel source Loopback0
 tunnel destination 150.1.1.1
 tunnel key 123

Обратите внимание, что только туннель-концентратор использует инкапсуляцию mGRE, а spoke используют обычные туннели GRE с точка-точка подключением. Теперь давайте посмотрим на команды NHRP, использованные в примере выше. Самая основная команда ip nhrp map [Logical IP] [NBMA IP] — создает статическую привязку между логическим IP-адресом и NBMA IP-адресом. Поскольку mGRE обрабатывается NHRP как среда NMBA, логический IP соответствует IP-адресу «внутри» туннеля («внутренний»), а IP-адрес NBMA соответствует «внешнему» IP-адресу (IP-адрес, используемый для источника туннеля) . (С этого момента мы будем называть «внутренний» IP-адрес и просто «IP-адрес» или «логический IP-адрес», а «внешний» IP-адрес — «NBMA-адрес» или «физический IP-адрес»).Использование статических сопоставлений NHRP заключается в том, чтобы «загружать» информацию, чтобы спицы достигли логического IP-адреса концентратора. Следующая команда — ip nhrp map multicast dynamic [[StaticIP] и ее назначение такое же, как «frame-relay map … broadcast ». Команда указывает список адресатов, которые будут получать трафик групповой рассылки / широковещания, исходящий от этого маршрутизатора. Spokes отображает многоадресную рассылку на статический NBMA-IP-адрес концентратора, но концентратор сопоставляет многоадресные пакеты с «динамическими» сопоставлениями — это означает, что концентратор ретранслирует многоадресные пакеты всем спицам, зарегистрированным через NHRP. Отображение многоадресных рассылок важно для того, чтобы протокол динамической маршрутизации устанавливал соседства и обменивался пакетами обновлений. Команда ip nhrp nhs [ServerIP] настраивает клиента NHRP с IP-адресом своего сервера NHRP. Обратите внимание, что «ServerIP» — это логический IP-адрес концентратора (внутри туннеля), поэтому для достижения спиц нужны статические сопоставления NHRP. Спикеры используют NHS для регистрации своего логического IP в ассоциации NBMA IP и отправки запроса разрешения NHRP. (Тем не менее, в этом конкретном сценарии, спикеры не будут отправлять запросы NHRP Resolutions, поскольку они используют направленные туннели GRE — будут отправлены только запросы на регистрацию). Команды ip nhrp network-id И аутентификация ip nhrp [Key] идентифицируют и аутентифицируют логическую сеть NHRP. [ID] и [Key] должны совпадать на всех маршрутизаторах, использующих один и тот же GRE-туннель. Возможно разбиение среды NBMA на несколько сетей NHRP, но это для расширенных сценариев. Что касается аутентификации, это простой текстовый ключ, отправленный во всех сообщениях NHRP. Хотя «идентификатор сети» является обязательным для работы NHRP, вы можете опустить аутентификацию. Следующая команда — ip nhrp holdtime, которая указывает значение времени удержания, заданное в запросах регистрации NHRP. NHS будет хранить запрос на регистрацию в кеше в течение времени удержания, а затем, если обновление регистрации не будет получено, будет тайм аут. NHS также отправит такое же время удержания в ответах на разрешение NHRP, если запрошено для соответствующей ассоциации NHRP. Обратите внимание, что вы настраиваете команду ip nhrp holdtime на spoke, а spoke будет отправлять запросы на регистрацию каждые 1/3 времени удержания. Однако, если вы также настроите тайм-аут регистрации iphrp [Timeout] на spoke, запросы регистрации NHRP будут отправляться каждые [Тайм-аута], а не 1/3 настроенного времени удержания. Значение времени удержания, отправленное в запросах регистрации NHRP, останется таким же, конечно.

Теперь перейдем к командам show. Так как это только хаб, который использует динамические сопоставления NHRP для разрешения адресов NBMA спиц, полезно наблюдать кеш R1 NHRP:

Rack1R1#show ip nhrp detail
10.0.0.2/32 via 10.0.0.2, Tunnel0 created 00:16:59, expire 00:00:30
  Type: dynamic, Flags: authoritative unique registered used
  NBMA address: 150.1.2.2
10.0.0.3/32 via 10.0.0.3, Tunnel0 created 00:11:34, expire 00:00:55
  Type: dynamic, Flags: authoritative unique registered used
  NBMA address: 150.1.3.3

Как мы видим, IP «10.0.0.2» сопоставляется с NBMA-адресом «150.1.2.2», а IP 10.0.0.3 сопоставляется с NBMA-адресом 150.1.3.3. «Авторитетный» флаг означает, что NHS узнала о картографировании (mapping) NHRP непосредственно из запроса регистрации (NHS «обслуживает» конкретный NHC). Флаг «unique» означает, что запрос регистрации NHRP имеет один и тот же «уникальный» набор флагов. Использование этого флага позволяет избежать дублирования NHRP-сопоставлений в кеше. Если уникальное сопоставление для определенного логического IP уже находится в кэше NHRP, а другой NHC пытается зарегистрировать тот же логический IP-адрес в NHS, сервер будет отклонять регистрацию до истечения срока уникальной записи. Обратите внимание, что по умолчанию маршрутизаторы IOS устанавливают этот флаг в запросе регистрации, и это можно отключить с помощью команды ip nhrp registration no-unique на spoke. Иногда это может понадобиться, когда спикер часто меняет свой NBMA IP-адрес и ему необходимо перерегистрировать новое сопоставление с концентратором. Последний флаг, называемый «используемый», означает, что маршрутизатор использует запись NHRP для переключения IP-пакетов. Мы обсудим значение этого флага в разделе переключения процессов NRHP ниже. Также обратите внимание на поле «expires», которое является таймером обратного отсчета, начинающимся с «holdtime», указанного в пакете запроса регистрации.

Рассмотрим процесс регистрации и ответа NHRP в NHS.

Rack1R1#debug nhrp
NHRP protocol debugging is on

Rack1R1#debug nhrp packet
NHRP activity debugging is on

Во-первых, R3 пытается зарегистрировать свой Логический IP для NBMA IP mapping с концентратором. Обратите внимание на конкретный формат пакета NHRP, разделенный на три части.

1) (F) — фиксированная часть. Указывает версию, семейство адресов (afn) и тип протокола (type) для разрешения, а также тип и длину уровня подсети (NBMA) (shtl и sstl). Обратите внимание, что «shtl» равно 4, что является длиной адреса IPv4 в байтах, а «sstl» — для поля «субадресса», который не используется с IPv4.

2) (M) — обязательная часть заголовка. Определяет некоторые флаги, такие как флаг «уникальный» и «Идентификатор запроса», который используется для отслеживания запроса / ответов. Также включает в себя исходный адрес NBMA (источник туннеля в GRE / mGRE) и IP-адреса протокола источника / назначения. IP-адрес назначения — это логический IP-адрес концентратора, а исходный IP-адрес — это логический IP-адрес спицы. Используя этот информационный концентратор, можно заполнить логический IP-адрес в соответствии с назначением IP-адреса NBMA.

3) (C-1) — CIE 1, который обозначает поле «Информация о клиенте». Хотя он не используется в пакетах ниже, в более сложных сценариях, рассмотренных позже, мы увидим, что это поле содержит информацию о сетях, подключенных к запрашивающим / отвечающим маршрутизаторам.

Также обратите внимание на выход проверки NAT, который является расширением Cisco, используемым для того, чтобы сделать работу NHRP для маршрутизаторов, которые туннелируют за NAT.

NHRP: Receive Registration Request via Tunnel0 vrf 0, packet size: 81
 (F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1
     shtl: 4(NSAP), sstl: 0(NSAP)
 (M) flags: "unique", reqid: 26
     src NBMA: 150.1.3.3
     src protocol: 10.0.0.3, dst protocol: 10.0.0.1
 (C-1) code: no error(0)
       prefix: 255, mtu: 1514, hd_time: 60
       addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0
NHRP: netid_in = 123, to_us = 1
NHRP: NAT-check: matched destination address 150.1.3.3
NHRP: Tu0: Found and skipping dynamic multicast mapping  NBMA: 150.1.3.3
NHRP: Attempting to send packet via DEST 10.0.0.3
NHRP: Encapsulation succeeded.  Tunnel IP addr 150.1.3.3

После обработки запроса маршрутизатор отвечает ответом регистрации NHRP. Обратите внимание, что заголовок (M) не изменился, только исходный и целевой логический IP-адрес пакета меняются местами. (R1-> R3)

NHRP: Send Registration Reply via Tunnel0 vrf 0, packet size: 101
 src: 10.0.0.1, dst: 10.0.0.3
 (F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1
     shtl: 4(NSAP), sstl: 0(NSAP)
 (M) flags: "unique", reqid: 26
     src NBMA: 150.1.3.3
     src protocol: 10.0.0.3, dst protocol: 10.0.0.1
 (C-1) code: no error(0)
       prefix: 255, mtu: 1514, hd_time: 60
       addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0
NHRP: 101 bytes out Tunnel0

Теперь NHS получает запрос регистрации от R2 и добавляет соответствующую запись в свой кэш NHRP

NHRP: Receive Registration Request via Tunnel0 vrf 0, packet size: 81
 (F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1
     shtl: 4(NSAP), sstl: 0(NSAP)
 (M) flags: "unique", reqid: 38
     src NBMA: 150.1.2.2
     src protocol: 10.0.0.2, dst protocol: 10.0.0.1
 (C-1) code: no error(0)
       prefix: 255, mtu: 1514, hd_time: 60
       addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0
NHRP: netid_in = 123, to_us = 1
NHRP: NAT-check: matched destination address 150.1.2.2
NHRP: Tu0: Found and skipping dynamic multicast mapping  NBMA: 150.1.2.2
NHRP: Attempting to send packet via DEST 10.0.0.2
NHRP: Encapsulation succeeded.  Tunnel IP addr 150.1.2.2

NHRP: Send Registration Reply via Tunnel0  vrf 0, packet size: 101
 src: 10.0.0.1, dst: 10.0.0.2
 (F) afn: IPv4(1), type: IP(800), hop: 255, ver: 1
     shtl: 4(NSAP), sstl: 0(NSAP)
 (M) flags: "unique", reqid: 38
     src NBMA: 150.1.2.2
     src protocol: 10.0.0.2, dst protocol: 10.0.0.1
 (C-1) code: no error(0)
       prefix: 255, mtu: 1514, hd_time: 60
       addr_len: 0(NSAP), subaddr_len: 0(NSAP), proto_len: 0, pref: 0
NHRP: 101 bytes out Tunnel0

Мы видим, как работает Фаза 1 NRHP. Spoke регистрируют свои соединения с хабом через NHRP, и хаб обучает их NBMA-адресам динамически. В то же время spoke используют туннели типа «точка-точка», чтобы общаться с центром и достигать друг друга. Обратите внимание, что EIGRP — не единственный протокол, подходящий для использования с Фазой 1 NHRP. OSPF также является жизнеспособным решением, благодаря команде типа «point-to-multipoint» и «database filter-all out ». См. Пример ниже для конфигурации OSPF с NHRP Phase 1:

MGRE + NHRP Фаза 1 + OSPF

R1:
!
! Hub router
!
router ospf 123
 router-id 10.0.0.1
 network 10.0.0.0 0.255.255.255 area 0
!
interface Loopback0
 ip address 150.1.1.1 255.255.255.0
!
interface Loopback 1
 ip address 10.0.1.1 255.255.255.0
!
interface Tunnel0
 ip address 10.0.0.1 255.255.255.0
 no ip redirects
 ip nhrp authentication cisco
 ip nhrp map multicast dynamic
 ip nhrp network-id 123
 tunnel source Loopback0
 tunnel mode gre multipoint
 tunnel key 123
 ip ospf network point-to-multipoint
 ip ospf database-filter all out

R2:
!
! Spoke Router
!
router ospf 123
 network 10.0.0.0 0.255.255.255 area 0
 router-id 10.0.0.2
!
interface Loopback0
 ip address 150.1.2.2 255.255.255.0
!
interface Loopback 1
 ip address 10.0.2.2 255.255.255.0
!
interface Tunnel0
 ip address 10.0.0.2 255.255.255.0
 ip nhrp authentication cisco
 ip nhrp map multicast 150.1.1.1
 ip nhrp map 10.0.0.1 150.1.1.1
 ip nhrp nhs 10.0.0.1
 ip nhrp network-id 123
 ip nhrp registration timeout 30
 ip nhrp holdtime 60
 tunnel source Loopback0
 tunnel destination 150.1.1.1
 tunnel key 123
 ip ospf network point-to-multipoint
!
ip route 0.0.0.0 0.0.0.0 Tunnel0

R3:
!
! Spoke Router
!
router ospf 123
 network 10.0.0.0 0.255.255.255 area 0
 router-id 10.0.0.3
!
interface Loopback0
 ip address 150.1.3.3 255.255.255.0
!
interface Loopback 1
 ip address 10.0.3.3 255.255.255.0
!
interface Tunnel0
 ip address 10.0.0.3 255.255.255.0
 ip nhrp authentication cisco
 ip nhrp map multicast 150.1.1.1
 ip nhrp map 10.0.0.1 150.1.1.1
 ip nhrp nhs 10.0.0.1
 ip nhrp network-id 123
 ip nhrp registration timeout 30
 ip nhrp holdtime 60
 tunnel source Loopback0
 tunnel destination 150.1.1.1
 tunnel key 123
 ip ospf network point-to-multipoint
!
ip route 0.0.0.0 0.0.0.0 Tunnel0

Как мы уже говорили, основным преимуществом использования фазы 1 NHRP является упрощенная настройка маршрутизатора-концентратора. Кроме того, маршрутизаторы с голосовыми сообщениями получают минимальную информацию о маршрутизации (они либо суммируются, либо отфильтровываются на концентраторе), и конфигурируются единообразно. В большинстве простых случаев маршрутизаторы с речевыми сигналами могли быть сконфигурированы без каких-либо NHRP, просто используя туннели GRE из точки в точку. Этот сценарий требует, чтобы концентратор создавал статическое сопоставление NHRP для каждого слова. Например:

MGRE + NHRP Фаза 1 + OSPF + Статические сопоставления NHRP

R1:
!
! Hub router
!
router ospf 123
 router-id 10.0.0.1
 network 10.0.0.0 0.255.255.255 area 0
!
interface Loopback0
 ip address 150.1.1.1 255.255.255.0
!
interface Loopback 1
 ip address 10.0.1.1 255.255.255.0
!
interface Tunnel0
 ip address 10.0.0.1 255.255.255.0
 no ip redirects
 ip nhrp authentication cisco
 ip nhrp map 10.0.0.2 150.1.2.2
 ip nhrp map 10.0.0.3 150.1.3.3
 ip nhrp map multicast 150.1.2.2
 ip nhrp map multicast 150.1.3.3
 ip nhrp network-id 123
 tunnel source Loopback0
 tunnel mode gre multipoint
 tunnel key 123
 ip ospf network point-to-multipoint
 ip ospf database-filter all out

R2:
!
! Spoke Router
!
router ospf 123
 network 10.0.0.0 0.255.255.255 area 0
 router-id 10.0.0.2
!
interface Loopback0
 ip address 150.1.2.2 255.255.255.0
!
interface Loopback 1
 ip address 10.0.2.2 255.255.255.0
!
interface Tunnel0
 ip address 10.0.0.2 255.255.255.0
 tunnel source Loopback0
 tunnel destination 150.1.1.1
 tunnel key 123
 ip ospf network point-to-multipoint
!
ip route 0.0.0.0 0.0.0.0 Tunnel0

R3:
!
! Spoke Router
!
router ospf 123
 network 10.0.0.0 0.255.255.255 area 0
 router-id 10.0.0.3
!
interface Loopback0
 ip address 150.1.3.3 255.255.255.0
!
interface Loopback 1
 ip address 10.0.3.3 255.255.255.0
!
interface Tunnel0
 ip address 10.0.0.3 255.255.255.0
 tunnel source Loopback0
 tunnel destination 150.1.1.1
 tunnel key 123
 ip ospf network point-to-multipoint
!
ip route 0.0.0.0 0.0.0.0 Tunnel0

Недостатком первой фазы NHRP является неспособность создать туннели со spoke. Этап 2 NHRP решает эту проблему и допускает создание туннелей со spoke. Чтобы лучше понять второй этап, нам сначала нужно выяснить, как NHRP взаимодействует с CEF — теперь по умолчанию используется метод IP-коммутации на большинстве маршрутизаторов Cisco. Рассмотрим следующую топологию и пример конфигурации. См. Подробную разбивку после конфигурации.

MGRE + NHRP Фаза 2 + EIGRP

R1:
!
! Hub router
!
router eigrp 123
 no auto-summary
 network 10.0.0.0 0.255.255.255
!
interface Loopback0
 ip address 150.1.1.1 255.255.255.0
!
interface Loopback 1
 ip address 10.0.1.1 255.255.255.0
!
interface Tunnel0
 ip address 10.0.0.1 255.255.255.0
 no ip redirects
 ip nhrp authentication cisco
 ip nhrp map multicast dynamic
 ip nhrp network-id 123
 no ip split-horizon eigrp 123
 no ip next-hop-self eigrp 123
 tunnel source Loopback0
 tunnel mode gre multipoint
 tunnel key 123

R2:
!
! Spoke Router
!
router eigrp 123
 no auto-summary
 network 10.0.0.0 0.255.255.255
 eigrp stub connected
!
interface Loopback0
 ip address 150.1.2.2 255.255.255.0
!
interface Loopback 1
 ip address 10.0.2.2 255.255.255.0
!
interface Tunnel0
 ip address 10.0.0.2 255.255.255.0
 ip nhrp authentication cisco
 ip nhrp map multicast 150.1.1.1
 ip nhrp map 10.0.0.1 150.1.1.1
 ip nhrp nhs 10.0.0.1
 ip nhrp network-id 123
 ip nhrp registration timeout 30
 ip nhrp holdtime 60
 tunnel source Loopback0
 tunnel mode gre multipoint
 tunnel key 123

R3:
!
! Spoke Router
!
router eigrp 123
 no auto-summary
 network 10.0.0.0 0.255.255.255
 eigrp stub connected
!
interface Loopback0
 ip address 150.1.3.3 255.255.255.0
!
interface Loopback 1
 ip address 10.0.3.3 255.255.255.0
!
interface Tunnel0
 ip address 10.0.0.3 255.255.255.0
 ip nhrp authentication cisco
 ip nhrp map multicast 150.1.1.1
 ip nhrp map 10.0.0.1 150.1.1.1
 ip nhrp nhs 10.0.0.1
 ip nhrp network-id 123
 ip nhrp registration timeout 30
 ip nhrp holdtime 60
 tunnel source Loopback0
 tunnel mode gre multipoint
 tunnel key 123

Обратите внимание, что оба спикера используют режим инкапсуляции туннеля mGRE, а концентратор устанавливает IP-адрес исходящего маршрутизатора следующего перехода в «отраженных» обновлениях EIGRP (по умолчанию EIGRP устанавливает поле следующего перехода равным «0.0.0.0» — то есть самому себе ). В силу конфигурации EIGRP подсеть «10.0.2.0/24» (подключенная к R2) достигает R3 с IP-адресом следующего перехода «10.0.0.2» (R2). Важно, чтобы R3 узнал «10.0.2.0/24» со следующим шагом логического IP-адреса R2. Как мы увидим ниже, это ключ для запуска CEF. Инкапсуляция mGRE, используемая на spoke, вызовет разрешения NHRP, поскольку теперь это среда NBMA. Теперь, предполагая, что трафик до 10.0.2.0/24 еще не протекает, проверьте запись таблицы маршрутизации для 10.0.2.2 и записи CEF для маршрута и его следующий переход:

Rack1R3#show ip route 10.0.2.2
Routing entry for 10.0.2.0/24
  Known via "eigrp 123", distance 90, metric 310172416, type internal
  Redistributing via eigrp 123
  Last update from 10.0.0.2 on Tunnel0, 00:09:55 ago
  Routing Descriptor Blocks:
  * 10.0.0.2, from 10.0.0.1, 00:09:55 ago, via Tunnel0
      Route metric is 310172416, traffic share count is 1
      Total delay is 1005000 microseconds, minimum bandwidth is 9 Kbit
      Reliability 255/255, minimum MTU 1472 bytes
      Loading 1/255, Hops 2

Rack1R3#show ip cef 10.0.2.2
10.0.2.0/24, version 48, epoch 0
0 packets, 0 bytes
  via 10.0.0.2, Tunnel0, 0 dependencies
    next hop 10.0.0.2, Tunnel0
    invalid adjacency

Rack1R3#show ip cef 10.0.0.2
10.0.0.0/24, version 50, epoch 0, attached, connected
0 packets, 0 bytes
  via Tunnel0, 0 dependencies
    valid glean adjacency

Обратите внимание, что префикс CEF для «10.0.2.0/24» недействителен (но не «подбирается»), так как «10.0.0.2» еще не разрешен. Префикс CEF для «10.0.0.2» имеет «glean» смежность, что означает, что маршрутизатор должен отправить запрос разрешения NHRP для сопоставления логического IP-адреса с NBMA. Поэтому при переключении CEF запросы разрешения NHRP отправляются только для «последующих» IP-адресов и никогда для самих сетей (например, 10.0.2.0/24) (при переключении процессов любой префикс разрешен, как мы увидим позже ). Идем дальше и пингуем от R3 до «10.0.3.3» и наблюдаем за процессом:

Rack1R3#ping 10.0.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/80/180 ms

 

Проверьте сопоставления на маршрутизаторе концентратора. Зарегистрированы только две записи — IP-адреса VPN для R2 и R3 вместе с соответствующими IP-адресами NBMA. Обратите внимание на поле «expire», которое, как упоминалось выше, подсчитывает время истечения срока действия записи на основе настроек «holdtime» интерфейса регистрирующего маршрутизатора. Позже мы увидим, как CEF использует этот таймер обратного отсчета для обновления или удаления записей CEF для IP-адреса следующего перехода

Rack1R1#show ip nhrp
10.0.0.2/32 via 10.0.0.2, Tunnel0 created 00:16:33, expire 00:00:43
  Type: dynamic, Flags: authoritative unique registered
  NBMA address: 150.1.2.2
  Requester: 10.0.0.3 Request ID: 798
10.0.0.3/32 via 10.0.0.3, Tunnel0 created 00:16:34, expire 00:00:51
  Type: dynamic, Flags: authoritative unique registered
  NBMA address: 150.1.3.3
  Requester: 10.0.0.2 Request ID: 813

Проверьте отображения на R2 (обратите внимание, что R2 теперь имеет сопоставление для R3's 
  Next-hop, связанный с его NBMA IP-адресом) 

Rack1R2#show ip nhrp
10.0.0.1/32 via 10.0.0.1, Tunnel0 created 00:14:52, never expire
  Type: static, Flags: authoritative used
  NBMA address: 150.1.1.1
10.0.0.2/32 via 10.0.0.2, Tunnel0 created 00:05:49, expire 00:00:10
  Type: dynamic, Flags: router authoritative unique local
  NBMA address: 150.1.2.2
    (no-socket)
10.0.0.3/32 via 10.0.0.3, Tunnel0 created 00:00:30, expire 00:00:29
  Type: dynamic, Flags: router used
  NBMA address: 150.1.3.3 

Тот же вывод команды на R3 симметричен выводу на R2:

Rack1R3#show ip nhrp
10.0.0.1/32 via 10.0.0.1, Tunnel0 created 00:14:00, never expire
  Type: static, Flags: authoritative used
  NBMA address: 150.1.1.1
10.0.0.2/32 via 10.0.0.2, Tunnel0 created 00:00:05, expire 00:00:54
  Type: dynamic, Flags: router
  NBMA address: 150.1.2.2
10.0.0.3/32 via 10.0.0.3, Tunnel0 created 00:01:46, expire 00:00:13
  Type: dynamic, Flags: router authoritative unique local
  NBMA address: 150.1.3.3
    (no-socket)

Теперь проверьте запись CEF для следующего IP-адреса R2 на R3:

 

Продолжение в ближайшее время…
Оригинал статьи на blog.ine.com

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

Ваш e-mail не будет опубликован. Обязательные поля помечены *