12 35-13 35-Олег Типисов-Как настроить DMVPN и избежать ... ·...

CiscoConnectМосква, 2017

Цифровизация: здесь и сейчас

Как настроить DMVPN и избежать проблемОлег Типисов

Инженер Cisco TAC

© 2017 Cisco and/or its affiliates. All rights reserved.

Введение

• В данной презентации рассматриваются некоторые вопросы настройки и функционирования Dynamic Multipoint VPN (DMVPN)

• Выбраны темы, по которым открывается наибольшее число кейсов в Cisco TAC:

• Отличия в работе DMVPN Phase2 и Phase3• Подключение к двум провайдерам• Динамическая маршрутизация с использованием EIGRP и iBGP• Балансировка нагрузки, симметрия и отказоустойчивость• Использование BFD совместно с BGP поверх mGRE• QoS (Hub->Spoke, Spoke->Hub, Spoke<->Spoke, AQoS)• Вопросы масштабируемости

• Более полно технология DMVPN рассматривается в презентациях Cisco Live!

Cisco Connect 2017 © 2017 Cisco and/or its affiliates. All rights reserved. 03

Презентации Cisco Live! Las Vegas 2016

• BRKSEC-2054 GET Your VPN's Secured with ESON• BRKRST-2362 IWAN - Implementing Performance Routing (PfRv3)• BRKRST-2043 IWAN AVC/QoS Design• BRKCRS-2000 Intelligent WAN (IWAN) Architecture• BRKSEC-3001 Advanced IKEv2 Protocol• BRKCRS-2002 IWAN Design and Deployment Workshop• BRKSEC-4054 Advanced Concepts of DMVPN• BRKRST-2041 WAN Architectures and Design Principles• BRKSEC-3052 Troubleshooting DMVPNs• BRKRST-3413 IWAN Serviceability: Deploying, Monitoring, and Operating• BRKRST-2042 Highly Available Wide Area Network Design• BRKCRS-2007 Migrating Your Existing WAN to Cisco’s IWAN• BRKSEC-3054 IOS FlexVPN Remote Access, IoT and Site-to-Site advanced Crypto VPN

Designs• BRKSEC-1050 An Overview of Site-to-Site Cisco VPN Technologies• BRKRST-2514 Application Optimization and Provisioning the Intelligent WAN (IWAN)• BRKSEC-2881 Designing Remote-Access and Site-to-Site IPSec networks with FlexVPN


Топология и версии ПО

• Представленные выводы были собраны на стенде• DMVPN Hub-1: ASR1002-X, IOS-XE 16.4(1) (Everest)• DMVPN Spoke-2: CISCO892, IOS 15.6(3)M1• DMVPN Spoke-3: ISR4331, IOS-XE 16.4(1) (Everest)


Spoke-2

192.168.2.2/24 192.168.3.128/25

Physical: 1.1.19.1Tunnel1: 10.1.1.1Tunnel2: 10.2.2.1

Spoke-3

Physical: 2.2.29.2Tunnel1: 10.1.1.2


192.168.1.1/24

Hub-1

192.168.3.32/27

Physical: 22.22.29.2Tunnel2: 10.2.2.2

Physical: 33.33.39.3Tunnel2: 10.2.2.3

.9

Содержание

• Основы DMVPN• DMVPN Phase2• DMVPN Phase3• Базовые варианты дизайна• Подключение к двум провайдерам• Per-Tunnel QoS for DMVPN• BGP и BFD• Рекомендации по масштабируемости


Основы DMVPN


Что такое DMVPN?

• DMVPN – это способ организации Site-to-Site IPSec VPN• Маршрутизация определяет, какой трафик шифруется• Размер конфигурации DMVPN Hub не зависит от числа Spokes• Топология Hub – Spoke• При необходимости создаются туннели Spoke – Spoke

• Состоит из• Multipoint GRE (mGRE) Tunnel Interface• IGP / BGP• Next Hop Resolution Protocol (NHRP)• IPSec (IKEv1 / IKEv2). Также может использоваться без IPSec

• Поддерживаются• IPv4, IPv6, MPLS в качестве транспорта• IPv4, IPv6, MPLS в качестве пассажира• Динамические IP-адреса на Spokes• Spokes м.б. за динамическим NAT, Hub – за статическим NAT


Фазы DMVPN

• DMVPN Phase2 – IOS 12.3(8)T1• Туннели Spoke – Spoke• Все основные протоколы маршрутизации кроме IS-IS• Масштабируемость за счет нескольких Hub в кольце (daisy chain)• Per-Tunnel QoS – 12.4(22)T• Нет суммаризации маршрутов на Hub

• DMVPN Phase3 – IOS 12.4(6)T• Иная логика работы протокола NHRP• Возможна суммаризация маршрутов на Hub• Маршруты NHRP в RIB и FIB – 15.2(1)T• Древовидные иерархии Hubs вместо колец• Off-subnet Next-hops – 15.4(1)T, 15.3(3)S• Постепенно сняты многие ограничения, связанные с протоколами

динамической маршрутизации


Как работает DMVPN

• DMVPN Spokes устанавливают IPSec-туннель с DMVPN Hub• Постоянный туннель

• Spokes (NHC) регистрируются на Hub (NHS) по NHRP• На Hub создается запись “Spoke Tunnel IP” <-> “Spoke Physical IP”• Вместо “Physical IP” в NHRP используется термин “NBMA IP”

• Протокол динамической маршрутизации между Spokes и Hub• Phase2: Hub не должен менять next-hop при передаче маршрута• Phase3: Hub должен заменять next-hop на свой IP

• Туннель Spoke – Spoke создается трафиком• Для этого Spoke должен узнать NBMA IP удаленного Spoke• Процедура получения NBMA IP различается в Phase2 и Phase3

• Если трафика нет, то через некоторое время динамический туннель Spoke – Spoke терминируется


Как работает DMVPN


DynamicSpoke-to-spoke tunnels

Spoke-2

Spoke-3

192.168.3.0/24

.3

192.168.2.0/24

.2

192.168.1.0/24.1

...

Physical:1.1.19.1Tunnel1:10.1.1.1



StaticSpoke-to-hub tunnels

StaticknownIPaddress

Canhavedynamicorunknown IPs

LANscanhaveprivateaddressing

Протокол NHRP

• RFC 2332• При инкапсуляции в GRE не использует IP• Номер протокола в заголовке GRE – 0x2001

• Типы сообщений NHRP:• NHRP Registration Request, NHRP Registration Reply• NHRP Resolution Request, NHRP Resolution Reply• NHRP Purge Request, NHRP Purge Reply • NHRP Error Indication• NHRP Traffic Indication (Redirect)


Phase2/Phase3: Регистрация споков

• NHS Tunnel IP и NBMA IP прописываются на NHC статически• NHC регистрируют на NHS свои Tunnel IP и NBMA IP

• После чего Hub и Spoke cмогут начать общаться по unicast

• Это также приводит к созданию multicast-записи в кеше NHRP• После чего между Hub и Spoke cможет работать EIGRP или OSPF

• NHC шлют Registration Request на NHS переодически• Частота регистраций равна 1/3 от NHRP Holdtime

• NHRP Registration Reply от NHS говорит о том, что Hub жив• Если Registration Reply от NHS не приходит, то повторы

• Через 1, 2, 4, 8, 16, 32, 64, 64, ... сек.• NHS down после неполучения ответа на 3-й запрос• Но Registration Requests продолжают посылаться

• Также, NHC понимает, что NHS недоступен, при падении IPSec


IPSec Dead PeerDetection (DPD)


• Кр. собственно регистрации, сообщения NHRP Registration Request и Registration Reply выполняют и ряд др. функций

• NHRP Registration Request/Reply обеспечивают работу споков через NAT и помогают определить, находится ли за NAT’ом Hub

• NAT Address Extension

• NHRP Registration Request позволяет передавать NHRP Group для Per-Tunnel DMVPN QoS

• Vendor Private Extension

• Поддерживается аутентификация (пока только plain text)• Authentication Extension

• Есть защита от зацикливания сообщений NHRP• Forward Transit NHS Record Extension• Reverse Transit NHS Record Extension




Spoke-2192.168.2.2/24

= PermanentIPsectunnels

192.168.3.3/24


Spoke-3



10.1.1.1à 1.1.19.1 10.1.1.1à 1.1.19.1

10.1.1.2à 2.2.29.210.1.1.3à 3.3.39.3

192.168.1.1/24

192.168.2.0/24à Conn. 192.168.3.0/24à Conn.

192.168.1.0/24à Conn.

NHRPmapping

RoutingTable

NHRPRegistration

Phase2: Spoke – Spoke (Resolution Request)

• NHRP в DMVPN Phase2 – это в каком-то смысле аналог ARP• Он позволяет узнать Physical IP (NBMA IP) по Tunnel Interface IP• В таблице маршрутизации удаленная LAN д.б. видна через IP-

адрес туннельного интерфейса удаленного спока• EIGRP: "no ip next-hop-self eigrp 1“ на Hub• По умолчанию в RIP или iBGP (Hub – Route Reflector)• OSPF: “ip ospf network broadcast”

• Spoke-2 посылает Resolution Request про next-hop 10.1.1.3• Пока туннель Spoke – Spoke не создан и не получен Resolution

Reply, пользовательский трафик передается через Hub в режиме Process Switching

• CEF adjacency = incomplete




Spoke-2192.168.2.2/24

192.168.3.3/24


Spoke-3



10.1.1.2à 2.2.29.2192.168.1.1/24

192.168.2.0/24à 10.1.1.2192.168.3.0/24à 10.1.1.3

192.168.1.0/24à Conn.

192.168.1.0/24à 10.1.1.1192.168.2.0/24à Conn.

10.1.1.1à 1.1.19.1

192.168.1.0/24à 10.1.1.1

192.168.3.0/24à Conn.

10.1.1.1à 1.1.19.110.1.1.3à ??? 10.1.1.2à 2.2.29.2

10.1.1.3à 3.3.39.3

192.168.3.0/24à 10.1.1.3192.168.2.0/24à 10.1.1.2

10.1.1.1à 1.1.19.1 10.1.1.1à 1.1.19.110.1.1.3à incomplete 10.1.1.2à incomplete

10.1.1.2à 2.2.29.2CEFFIBTable

NHRPmapping

CEFAdjacency

DatapacketNHRPResolution

10.1.1.3à 3.3.39.3

Phase2: Spoke – Spoke (Resolution Reply)

• Hub не отвечает на NHRP Resolution Request, хотя имеет для этого подходящую запись в кеше NHRP о Spoke-3

• Поведение по умолчанию начиная с 12.4(6)T для Phase3 и Phase2• "{ip | ipv6} nhrp cache non-authoritative“ – это значение по умолчанию• Что предписывает хабу помещать запись в кеш NHRP как

неавторитетную. Такая запись не может быть использована для ответа, т.к. запросы споков имеют флаг ‘A’

• Именно поэтому Hub передает запрос Spoke-3 для ответа

• Spoke-3 пополняет свой кеш NHRP информацией из запроса• И отвечает напрямую Spoke-2, что приводит к подъему IPSec• Ответ формирует кеш NHRP и CEF adjacency на Spoke-2• После этого трафик передается по туннелю Spoke – Spoke в

режиме CEF• Таблица маршрутизации (RIB и FIB) не меняется


Phase2: Spoke – Spoke (Resolution Reply)


Spoke-2192.168.2.2/24

192.168.3.3/24


Spoke-3



192.168.1.1/24

192.168.2.0/24à 10.1.1.2192.168.3.0/24à 10.1.1.3

192.168.1.0/24à Conn.

192.168.1.0/24à 10.1.1.1192.168.2.0/24à Conn.

10.1.1.1à 1.1.19.1

192.168.1.0/24à 10.1.1.1

192.168.3.0/24à Conn.

10.1.1.1à 1.1.19.1

10.1.1.3à ???10.1.1.2à 2.2.29.2

10.1.1.2à 2.2.29.210.1.1.3à 3.3.39.3

192.168.3.0/24à 10.1.1.3

192.168.2.0/24à 10.1.1.2

10.1.1.1à 1.1.19.110.1.1.1à 1.1.19.1

10.1.1.3à incomplete10.1.1.3à 3.3.39.310.1.1.2à incomplete10.1.1.2à 2.2.29.2

10.1.1.2à 2.2.29.2

10.1.1.3à 3.3.39.3

CEFFIBTable

NHRPmapping

CEFAdjacency

DatapacketNHRPResolution

10.1.1.3à 3.3.39.3

10.1.1.2à 2.2.29.210.1.1.3à 3.3.39.310.1.1.2à 2.2.29.2

DMVPN Phase3

• В протоколе NHRP “номер версии” всегда равен ‘1’• Т.е. различить Phase2 и Phase3 по номеру версии нельзя

• Для Phase3 необходимо выполнение трех условий• Hub должен являться next-hop для Spokes

• “ip next-hop-self eigrp 1” – это значение по умолчанию• “neighbor ... next-hop-self all” – на BGP Route Reflector• “ip ospf network point-to-multipoint”

• Hub • {ip | ipv6} nhrp redirect

• Spokes• {ip | ipv6} nhrp shortcut

• Суммаризация маршрутов опциональна


Phase3: Суммаризация маршрутов


Spoke-2192.168.2.2/24

192.168.3.3/24


Spoke-3



10.1.1.1à 1.1.19.1 10.1.1.1à 1.1.19.1

= PermanentIPsectunnels

10.1.1.2à 2.2.29.210.1.1.3à 3.3.39.3

192.168.1.1/24

192.168.0.0/16à 10.1.1.1192.168.0.0/16à 10.1.1.1

192.168.2.0/24à 10.1.1.2192.168.3.0/24à 10.1.1.3

192.168.2.0/24à Conn. 192.168.3.0/24à Conn.

192.168.1.0/24à Conn.NHRPmapping

RoutingTable

Routingpacket

192.168.0.0/16à Summ.

Phase3: Spoke – Spoke (NHRP Redirect)

• Spoke-2• Шлет трафик через Hub в соответствии с таблицей маршрутизации• В данном примере трафик идет в удаленную LAN на 192.168.3.x

• Hub• Передает трафик дальше по таблице маршрутизации• Если в том же облаке DMVPN, т.е. в тот же туннельный интерфейс• Или др. туннельный интерфейс с тем же “{ip | ipv6} nhrp network-id”• То проверяет наличие команды “{ip | ipv6} nhrp redirect”• И шлет NHRP Traffic Indication, Code = Redirect исходному Spoke• В теле Redirect указывается IP-адрес, на который шел трафик• Формирует NHRP Redirect Table для прореживания сообщений

NHRP Redirect (“show ip nhrp redirect”)


Phase3: Spoke – Spoke (NHRP Redirect)


Spoke-2192.168.2.2/24

192.168.3.3/24


Spoke-3



10.1.1.2à 2.2.29.210.1.1.3à 3.3.39.3

192.168.1.1/24

192.168.2.0/24à 10.1.1.2192.168.3.0/24à 10.1.1.3

192.168.1.0/24à Conn.

CEFFIBTable

NHRPmapping

192.168.2.0/24à Conn.

10.1.1.1à 1.1.19.1

192.168.3.0/24à Conn.

10.1.1.1à 1.1.19.1

192.168.3.xà ???

192.168.0.0/16à 10.1.1.1192.168.0.0/16à 10.1.1.1

CEFAdjacency

10.1.1.1à 1.1.19.1

10.1.1.2à 2.2.29.2

DatapacketNHRPRedirectNHRPResolution

10.1.1.1à 1.1.19.1

10.1.1.3à 3.3.39.3


• Spoke-2• Получает NHRP Traffic Indication, Code = Redirect• Проверяет наличие команды “{ip | ipv6} nhrp shortcut”• Генерирует NHRP Resolution Request про указанный IP 192.168.3.x• И посылает его на данный IP согласно таблице маршрутизации• Т.к. “{ip | ipv6} nhrp send-routed” – это значение по умолчанию

• Hub• Передает Resolution Request дальше, в сторону Spoke-3, согласно

таблице маршрутизации• Т.к. "{ip | ipv6} nhrp cache non-authoritative“ – значение по умолчанию

• Spoke-3• Пополняет NHRP cache информацией из запроса• Если Spoke-3 является выходным узлом из этого облака DMVPN

согласно таблице маршрутизации, то он устанавливает туннель IPSec с Spoke-2 и отвечает на запрос




Spoke-2192.168.2.2/24

192.168.3.3/24


Spoke-3



10.1.1.2à 2.2.29.210.1.1.3à 3.3.39.3

192.168.1.1/24

192.168.2.0/24à 10.1.1.2192.168.3.0/24à 10.1.1.3

192.168.1.0/24à Conn.

CEFFIBTable

NHRPmapping

192.168.2.0/24à Conn.

10.1.1.1à 1.1.19.1

192.168.3.0/24à Conn.

10.1.1.1à 1.1.19.1

192.168.3.xà ???

192.168.0.0/16à 10.1.1.1192.168.0.0/16à 10.1.1.1

CEFAdjacency

10.1.1.1à 1.1.19.110.1.1.2à 2.2.29.2

10.1.1.2à 2.2.29.2

10.1.1.2à 2.2.29.2


10.1.1.1à 1.1.19.1

10.1.1.3à 3.3.39.3

10.1.1.2à2.2.29.2

Spoke – Spoke (Resolution Reply)

• Spoke-3• В Resolution Reply указывает длину маски той подсети, которой

соответствует IP-адрес в запросе (192.168.3.x)• Маска подсети берется из RIB. Соответствующая сеть не обязана

иметь тип “connected”• Для поиска подсети используется алгоритм Longest Match• Если запрашиваемому адресу соответствует маска /0, то

возвращается длина 32 или 128 (это “защита от дурака”)

• Spoke-2• Получает NHRP Resolution Reply по туннелю Spoke – Spoke • Пополняет кеш NHRP• Начиная с версии 15.2(1)T изменяет таблицу маршрутизации

• После этого трафик передается напрямую по туннелю Spoke –Spoke в режиме CEF


Spoke – Spoke (Resolution Reply – 15.2(1)T+)


Spoke-2192.168.2.2/24

192.168.3.3/24


Spoke-3



10.1.1.2à 2.2.29.210.1.1.3à 3.3.39.3

192.168.1.1/24

192.168.2.0/24à 10.1.1.2192.168.3.0/24à 10.1.1.3

192.168.1.0/24à Conn.

CEFFIBTable

NHRPmapping

192.168.2.0/24à Conn.

10.1.1.1à 1.1.19.110.1.1.1à 1.1.19.1

192.168.3.xà ???

192.168.0.0/16à 10.1.1.1 192.168.0.0/16à 10.1.1.1

CEFAdjacency

10.1.1.1à 1.1.19.110.1.1.3à 3.3.39.3 10.1.1.2à 2.2.29.2

10.1.1.2à 2.2.29.2

192.168.3.0/24à 3.3.39.310.1.1.2à 2.2.29.2


10.1.1.1à 1.1.19.1

10.1.1.3à 3.3.39.3

192.168.3.0/24à Conn.

10.1.1.3à 3.3.39.3192.168.2.0/24à 2.2.29.2

192.168.3.0/24à 10.1.1.3192.168.2.0/24à 10.1.1.2

Phase3: Изменение таблицы маршрутизации

• В сл. DMVPN Phase3, начиная с версии 15.2(1)T, NHRP производит изменение таблицы маршрутизации (RIB и FIB)

• Т.е. NHRP – это уже почти протокол маршрутизации• Административная дистанция NHRP равна 250• Метрика вычисляется по определенному закону

• Ниже M1 – это длина маски маршрута, бывшего на Spoke-2 до установления туннеля Spoke – Spoke, а M2 – длина маски в сообщении NHRP Resolution Reply, полученном от Spoke-3

• Если M1 < M2 (суммаризация маршрутов на Hub)• То на Spoke-2 добавляется маршрут NHRP (тип ‘H’)

• Если M1 = M2 (суммаризации нет)• То на Spoke-2 добавляется т.н. Next-hop Override (NHO) (флаг ‘%’)

• Если M1 > M2 (что странно)• То маска M2 делается равной маске M1 и дело сводится к п. 2


Основные отличия Phase2 и Phase3

• NHRP Resolution Request• Phase2: запрос о next-hop• Phase3: запрос об адресе в удаленной LAN

• NHRP Resolution Reply• Phase2: ответ содержит NBMA IP• Phase3: ответ содержит NBMA IP и длину маски для изменения RIB

• Кто инициирует NHRP Resolution Request• Phase2: Spoke самостоятельно• Phase3: Spoke после получения NHRP Redirect от Hub

• Кто отвечает на запрос• Phase2: владелец адреса (next-hop)• Phase3: роутер, являющийся точкой выхода из облака DMVPN

• Куда передается NHRP Resolution Request• Phase2: NHS Path• Phase3: Routed Path (with fallback to NHS Path)


DMVPN Phase2


Пример настройки DMVPN Phase2

• Параметры IPSec / IKEv1 (общая настройка Hub & Spokes)


crypto logging session

crypto isakmp policy 10encr aesauthentication pre-sharegroup 2

crypto isakmp key cisco address 0.0.0.0

crypto isakmp keepalive 10 3

crypto ipsec transform-set DMVPN esp-aes esp-sha-hmacmode transport

crypto ipsec profile DMVPNset transform-set DMVPN

crypto call admission limit ike in-negotiation-sa 20

interface Tunnel1ip mtu 1400ip tcp adjust-mss 1360tunnel source GigabitEthernet0/0/0tunnel mode gre multipoint[tunnel key 1]tunnel protection ipsec profile DMVPN [shared]

Обычно применяются цифровые сертификаты

Рекомендуется. “logging dmvpn” не рекомендуется

Рекомендуется на Spoke. Рекомендуется на Hub, но только, если сеть не слишком велика

Рекомендуется “mode transport”. Практически обязательно, если Spokes за NAT

Рекомендуется в средних и больших сетях

Обязательно, чтобы избежать фрагментации

Tunnel Key и Shared Tunnel Protection – см. далее


• Параметры NHRP и EIGRP


! Hub

interface Tunnel1bandwidth 10000delay 100ip address 10.1.1.1 255.255.255.0no ip redirectsno ip next-hop-self eigrp 1no ip split-horizon eigrp 1ip nhrp authentication Secretip nhrp network-id 1ip nhrp map multicast dynamic

! Spoke-2

interface Tunnel1bandwidth 10000delay 100ip address 10.1.1.2 255.255.255.0no ip redirectsip nhrp authentication Secretip nhrp network-id 1ip nhrp holdtime 600ip nhrp nhs 10.1.1.1 nbma 1.1.19.1 multicastip nhrp registration no-unique

Параметры EIGRPВ больших сетях необходимо увеличить таймеры

Значение по умолчанию начиная с 16.3(1)Используйте “show run all | sec interface Tunnel1”

Значение по умолчанию начиная с 16.3(1)Используйте “show run all | sec interface Tunnel1”

Синтаксис, совмещающий:ip nhrp nhs 10.1.1.1ip nhrp map 10.1.1.1 1.1.19.1ip nhrp map multicast 1.1.19.1

Необходимо, если NBMA-адрес Spoke может меняться

! Hub

router eigrp 1network 10.1.1.0 0.0.0.255network 192.168.1.0

ip route 0.0.0.0 0.0.0.0 1.1.19.9

! Spoke-2

router eigrp 1network 10.1.1.0 0.0.0.255network 192.168.2.0eigrp stub connected

ip route 0.0.0.0 0.0.0.0 2.2.29.9


• Маршрутизация


Используйте stub mode на нетранзитных узлах для лучшей масштабируемости EIGRP

Ситуация усложняется при необходимостиподключения к двум провайдерам

! Hubs

interface Tunnel …{ip | ipv6} nhrp map multicast dynamic{ip | ipv6} nhrp max-send 10000 every 10

! Spokes

interface Tunnel …{ip | ipv6} nhrp holdtime 600{ip | ipv6} nhrp registration timeout 200{ip | ipv6} nhrp shortcut{ip | ipv6} nhrp registration no-unique{ip | ipv6} nhrp max-send 10000 every 10

Изменения 16.3(1)

• В версии IOS-XE 16.3(1) изменились значения по умолчанию


Раньше 100 / 10, т.е. 100 сообщений за 10 сек., что явно недостаточно для больших инсталяций DMVPN

Registration Timeout вычисляется автоматически как 1/3 от Holdtime

7200 сек. (2 часа) до версии 16.3(1)

Hub-1#show crypto isakmp sa…Hub-1#show crypto ipsec sa…Hub-1#show ip nhrp

10.1.1.2/32 via 10.1.1.2Tunnel1 created 00:04:12, expire 00:07:07Type: dynamic, Flags: registered nhopNBMA address: 2.2.29.2

10.1.1.3/32 via 10.1.1.3Tunnel1 created 18:04:20, expire 00:08:55Type: dynamic, Flags: registered nhopNBMA address: 3.3.39.3

Hub-1#show ip nhrp multicast

I/F NBMA addressTunnel1 3.3.39.3 Flags: dynamic (Enabled)Tunnel1 2.2.29.2 Flags: dynamic (Enabled)

Hub-1#show dmvpn [detail]

Interface: Tunnel1, IPv4 NHRP DetailsType:Hub, NHRP Peers:2,

# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb----- --------------- --------------- ----- -------- -----

1 2.2.29.2 10.1.1.2 UP 00:05:54 D1 3.3.39.3 10.1.1.3 UP 18:06:02 D

Диагностика в DMVPN Phase2

• Hub: ISAKMP, IPSec, NHRP unicast & multicast mappings, EIGRP


Hub-1#show ip route eigrp

Gateway of last resort is 1.1.19.9 to network 0.0.0.0

D 192.168.2.0/24 [90/284160] via 10.1.1.2, 00:17:54, Tunnel1D 192.168.3.0/24 [90/281856] via 10.1.1.3, 00:17:39, Tunnel1

Spoke-2#show crypto isakmp sa…Spoke-2#show crypto ipsec sa…Spoke-2#show ip nhrp

10.1.1.1/32 via 10.1.1.1Tunnel1 created 18:42:09, never expireType: static, Flags: usedNBMA address: 1.1.19.1

Spoke-2#show ip nhrp nhs detail

Legend: E=Expecting replies, R=Responding, W=WaitingTunnel1:10.1.1.1 RE NBMA Address: 1.1.19.1 priority = 0 cluster = 0 req-sent 371 req-failed 0 repl-recv 333 (00:02:14 ago)

Spoke-2#show dmvpn

Interface: Tunnel1, IPv4 NHRP DetailsType:Spoke, NHRP Peers:1,


1 1.1.19.1 10.1.1.1 UP 00:07:47 S

Диагностика в DMVPN Phase2

• Spoke: ISAKMP, IPSec, NHRP, EIGRP


Spoke-2#show ip route eigrp

Gateway of last resort is 2.2.29.9 to network 0.0.0.0

D 192.168.1.0/24 [90/281856] via 10.1.1.1, 00:20:38, Tunnel1D 192.168.3.0/24 [90/307456] via 10.1.1.3, 00:20:38, Tunnel1

Spoke-2#show crypto isakmp sa

IPv4 Crypto ISAKMP SAdst src state conn-id status3.3.39.3 2.2.29.2 QM_IDLE 2009 ACTIVE2.2.29.2 3.3.39.3 QM_IDLE 2008 ACTIVE1.1.19.1 2.2.29.2 QM_IDLE 2007 ACTIVE

Spoke-2#show crypto ipsec sa peer 3.3.39.3…interface: Tunnel1

Crypto map tag: Tunnel1-head-0, local addr 2.2.29.2

protected vrf: (none)local ident (addr/mask/prot/port): (2.2.29.2/255.255.255.255/47/0)remote ident (addr/mask/prot/port): (3.3.39.3/255.255.255.255/47/0)current_peer 3.3.39.3 port 500

PERMIT, flags={origin_is_acl,}#pkts encaps: 1, #pkts encrypt: 1, #pkts digest: 1#pkts decaps: 1, #pkts decrypt: 1, #pkts verify: 1

…inbound esp sas:

spi: 0x32E72B77(854010743)spi: 0x27FB02FD(670761725)

outbound esp sas:spi: 0xC45892F1(3294139121)spi: 0xC8991AE3(3365477091)

После установления туннеля Spoke – Spoke

• Типичная ситуация: дубликаты сессий ISAKMP & IPSec


Spoke-2#show ip nhrp


10.1.1.2/32 via 10.1.1.2Tunnel1 created 00:01:56, expire 00:08:03Type: dynamic, Flags: router unique localNBMA address: 2.2.29.2(no-socket)

10.1.1.3/32 via 10.1.1.3Tunnel1 created 00:01:57, expire 00:08:02Type: dynamic, Flags: router nhopNBMA address: 3.3.39.3

Дубликаты будут удалены после rekey(если, конечно, туннель не будет удаленраньше из-за истечения NHRP holdtimeпри отсутствии трафика)

Таблица маршрутизации не меняется

DMVPN Phase3


! Hub

interface Tunnel1ip next-hop-self eigrp 1ip nhrp redirect

! Spoke-2 & Spoke-3

interface Tunnel1ip nhrp shortcut

• Приведены только изменения конфигурации по ср. с Phase2

• На Spoke-3 сеть 192.168.3.0/24 разбита на несколько подсетей



Значение по умолчанию во всех версиях

Значение по умолчанию начиная с 16.3(1)

interface Tunnel1ip summary-address eigrp 1 192.168.3.0 255.255.255.0 Spoke-2 получит суммарный маршрут

На Hub суммаризация не настроена

D 192.168.3.0/24 is a summary, 00:51:35, Null0D 192.168.3.4/30

[90/28416] via 192.168.3.2, 15:08:54, GigabitEthernet0/0/1.75D 192.168.3.32/27

[90/130816] via 192.168.3.2, 14:58:32, GigabitEthernet0/0/1.75D 192.168.3.128/25

[90/130816] via 192.168.3.2, 14:58:32, GigabitEthernet0/0/1.75


• Трафик посылается с 192.168.2.22 на 192.168.3.33


! Spoke-2



10.1.1.3/32 via 10.1.1.3Tunnel1 created 00:00:33, expire 00:09:27Type: dynamic, Flags: router nhop ribNBMA address: 3.3.39.3

192.168.2.0/24 via 10.1.1.2Tunnel1 created 00:00:32, expire 00:09:27Type: dynamic, Flags: router unique localNBMA address: 2.2.29.2(no-socket)

192.168.3.32/27 via 10.1.1.3Tunnel1 created 00:00:32, expire 00:09:27Type: dynamic, Flags: router ribNBMA address: 3.3.39.3

! Spoke-2

Spoke-2#show ip route…H 10.1.1.3/32 is directly connected, 00:00:38, Tunnel1D 192.168.3.0/24 [90/307456] via 10.1.1.1, 00:03:11, Tunnel1H 192.168.3.32/27 [250/255] via 10.1.1.3, 00:00:38, Tunnel1

Запись об удаленной сети 192.168.3.32/27

Запись о next-hop (Spoke-3)

Маршруты, добавленные NHRP (‘H’):Родительский маршрут EIGRP через Hub (‘D’)Дочерний маршрут 192.168.3.32/27 через Spoke-3


• Трафик посылается с 192.168.2.22 на 192.168.3.33


! Spoke-3


10.1.1.1/32 (isp1) via 10.1.1.1Tunnel1 created 00:53:49, never expireType: static, Flags: usedNBMA address: 1.1.19.1

10.1.1.2/32 (isp1) via 10.1.1.2Tunnel1 created 00:01:43, expire 00:08:15Type: dynamic, Flags: router nhop ribNBMA address: 2.2.29.2

192.168.2.0/24 (isp1) via 10.1.1.2Tunnel1 created 00:01:43, expire 00:08:15Type: dynamic, Flags: router rib nhoNBMA address: 2.2.29.2

192.168.3.32/27 (isp1) via 10.1.1.3Tunnel1 created 00:01:43, expire 00:08:16Type: dynamic, Flags: router unique localNBMA address: 3.3.39.3(no-socket)

! Spoke-3

Spoke-3#show ip route…H 10.1.1.2/32 is directly connected, 00:01:55, Tunnel1D % 192.168.2.0/24 [90/309760] via 10.1.1.1, 00:04:29, Tunnel1

Spoke-3#show ip route next-hop-override…H 10.1.1.2/32 is directly connected, 00:02:05, Tunnel1D % 192.168.2.0/24 [90/309760] via 10.1.1.1, 00:04:39, Tunnel1

[NHO][90/255] via 10.1.1.2, 00:02:05, Tunnel1

Признак NHO (Next-Hop Override)

NHRP переопределил next-hop маршрута EIGRP


• Если послать трафик на 192.168.3.133, то создастся новый маршрут


! Spoke-2

Spoke-2#show ip nhrp…192.168.3.32/27 via 10.1.1.3

Tunnel1 created 00:04:15, expire 00:05:44Type: dynamic, Flags: router ribNBMA address: 3.3.39.3

192.168.3.128/25 via 10.1.1.3Tunnel1 created 00:00:09, expire 00:09:50Type: dynamic, Flags: router ribNBMA address: 3.3.39.3

! Spoke-2

Spoke-2#show ip route…H 10.1.1.3/32 is directly connected, 00:04:20, Tunnel1D 192.168.3.0/24 [90/307456] via 10.1.1.1, 00:06:53, Tunnel1H 192.168.3.32/27 [250/255] via 10.1.1.3, 00:04:20, Tunnel1H 192.168.3.128/25 [250/255] via 10.1.1.3, 00:00:14, Tunnel1

! Spoke-3

interface Tunnel1ip nhrp summary-map 192.168.3.0/24

• Чтобы предотвратить создание на Spoke-2 нового маршрута NHRP на каждую подсеть можно суммировать их на Spoke-3

• В результате, на Spoke-2 получим

Суммаризация в NHRP


Появилось в 15.5(3)M, 15.5(3)S

Spoke-2#show ip nhrp…192.168.3.0/24 via 10.1.1.3

Tunnel1 created 00:00:10, expire 00:09:49Type: dynamic, Flags: router rib nhoNBMA address: 3.3.39.3

Spoke-2#show ip route next-hop-override…H 10.1.1.3/32 is directly connected, 00:00:18, Tunnel1D % 192.168.3.0/24 [90/307456] via 10.1.1.1, 01:25:38, Tunnel1

[NHO][90/255] via 10.1.1.3, 00:00:18, Tunnel1

Базовые варианты дизайна


Основные варианты дизайна DMVPN

© 2017 Cisco and/or its affiliates. All rights reserved. 045

=DynamicSpoke-to-spoke

DualHub,SingleCloud DualHub,DualCloud

SingleHub,DualCloud

А для чего это все?• Распределение нагрузки на Hubs• Масштабируемость• Отказоустойчивость• Подключение к нескольким ISP

Dual Hub, Single Cloud

• Один туннельный интерфейс• Два NHS прописаны на каждом Spoke• Hub’ы являются NHS друг для друга (“крест-накрест”)• Hub’ы обмениваются маршрутами через туннельный интерфейс• Гарантированно работают туннели Spoke – Spoke• Поддержка схемы Active/Backup

• Но туннельный интерфейс один• Поэтому придется на Backup Hub увеличить EIGRP “delay”• И применить EIGRP “offset-list … out”

• В сл. схемы Active/Active на Spokes будут параллельные пути• Основной недостаток: для подключения к двум ISP необходим

провайдеро-независимый адрес на loopback и “tunnel source loopback X”


DualHub,SingleCloud

Dual Hub, Dual Cloud

• Два туннельных интерфейса на Spokes• Используется в 90% инсталяций• Легче подключить Spokes к двум ISP

• Не требуется провайдеро-независимый адрес

• Поддержка схемы Active/Backup• Элементарно реализуется увеличением EIGRP “delay”

• В сл. схемы Active/Active на Spokes будут параллельные пути• Туннели Spoke – Spoke работают

• За исключением случая, когда из-за проблем провайдеров Spoke-1 может общаться только с Hub-1, а Spoke-2 – только с Hub-2

• Но могут создаться два туннеля Spoke – Spoke (в сл. Active/Active)• Более того, возможна асимметричная маршрутизация


DualHub,DualCloud

Single Hub, Dual Cloud

• Самый сложный вариант• Два туннельных интерфейса• Не рекомендуется, т.к. создает точку отказа (Hub)• Каждый роутер м.б. подключен к двум ISP• Поддержка схемы Active/Backup

• Элементарно реализуется увеличением EIGRP “delay”

• В сл. Active/Active будут параллельные пути на Spokes и Hub• Туннели Spoke – Spoke могут не работать в сл. Active/Active

• В этом сл. трафик будет передаваться через Hub• Частично (но не полностью!) проблема решена в 16.4(1) - Multiple

Tunnel Termination (MTT) Feature (aka Multipath Support on Transit Nodes)


SingleHub,DualCloud

Подключение к двум провайдерам


Вопросы, на которые необходимо ответить

• С какого адреса инициировать туннель (“tunnel source …”)?• 1) Использовать провайдеро-независимый адрес на loopback• 2) Для “tunnel 1” использовать адрес ISP1, для “tunnel 2” – ISP2

• Как обеспечить то, что трафик “tunnel 1” пойдет через ISP1?• Команда “tunnel source <ISP1>” всего лишь задает SrcIP• Трафик же легко может уйти через ISP2• Необходимо “прибить” “tunnel 1” к <ISP1>

• Как обеспечить то, что IKEv1 (или IKEv2) будет устанавливать туннель через нужный нам физический интерфейс через соответствующего ISP?

• Что делать на тех роутерах, где один ISP, но туннельных интерфейсов два?


interface Tunnel1ip address 10.1.1.2 255.255.255.0ip nhrp network-id 1ip nhrp nhs 10.1.1.1 nbma 1.1.19.1 multicastip nhrp shortcuttunnel source GigabitEthernet0.26tunnel mode gre multipointtunnel key 1tunnel route-via GigabitEthernet0.26 mandatorytunnel protection ipsec profile DMVPN

interface Tunnel2ip address 10.2.2.2 255.255.255.0ip nhrp network-id 2ip nhrp nhs 10.2.2.1 nbma 1.1.19.1 multicastip nhrp shortcuttunnel source GigabitEthernet0.27tunnel mode gre multipointtunnel key 2tunnel route-via GigabitEthernet0.27 mandatorytunnel protection ipsec profile DMVPN

interface GigabitEthernet0.26encapsulation dot1Q 26ip address 2.2.29.2 255.255.255.0

interface GigabitEthernet0.27encapsulation dot1Q 27ip address 22.22.29.2 255.255.255.0

Пример настройки Spoke-2 (IOS)

• В IOS рекомендуется применять “tunnel route-via”


Предписывает рассматривать только маршруты через Gi0.26 для маршрутизации транзитного трфика

ip route 0.0.0.0 0.0.0.0 2.2.29.9ip route 0.0.0.0 0.0.0.0 22.22.29.9

access-list 1 permit 2.2.29.2access-list 2 permit 22.22.29.2

route-map Local-PBR permit 10match ip address 1set ip next-hop 2.2.29.9

route-map Local-PBR permit 20match ip address 2set ip next-hop 22.22.29.9

ip local policy route-map Local-PBR

Необходимо для установления туннеля через “правильный” интерфейс

SingleHub,DualCloud

Пример настройки Spoke-3 (IOS-XE)

• В IOS-XE “tunnel route-via” пока не реализовано• Это приводит к крайне замысловатой настройке, которая ниже

приведена практически полностью• Мы “пилим” роутер на два VRF “isp1” и “isp2” и затем

“склеиваем” их на внутреннем L3-коммутаторе• Маршрутизация DMVPN реализуется с помощью EIGRP• Маршрутизация в Internet реализуется с помощью статических

маршрутов по умолчанию в каждом из VRF• Для отказоустойчивого выхода в Internet используется IP SLA и

tracking на внутреннем L3-коммутаторе


SingleHub,DualCloud

ip vrf isp1

ip vrf isp2

crypto keyring isp1 vrf isp1pre-shared-key address 0.0.0.0 0.0.0.0 key cisco

crypto keyring isp2 vrf isp2pre-shared-key address 0.0.0.0 0.0.0.0 key cisco

crypto logging session

crypto isakmp policy 10encr aesauthentication pre-sharegroup 2

crypto isakmp keepalive 10 3

crypto ipsec transform-set DMVPN esp-aes esp-sha-hmacmode transport

crypto ipsec profile DMVPNset transform-set DMVPN

crypto call admission limit ike in-negotiation-sa 20


• В IOS-XE приходится применять VRF-Lite


Поиск PSK производится в VRF, т.к. внешние физические интерфейсы будут назначены в VRF’ы

SingleHub,DualCloud

Spoke-2

192.168.2.2/24

Spoke-3


192.168.1.1/24

Hub-1

Physical: 33.33.39.3Tunnel2: 10.2.2.3

interface Tunnel1bandwidth 10000ip vrf forwarding isp1ip address 10.1.1.3 255.255.255.0no ip redirectsip mtu 1400ip nhrp authentication Secretip nhrp summary-map 192.168.3.0/24ip nhrp network-id 1ip nhrp nhs 10.1.1.1 nbma 1.1.19.1 multicastno ip nhrp recordip summary-address eigrp 1 192.168.3.0 255.255.255.0ip tcp adjust-mss 1360delay 100tunnel source GigabitEthernet0/0/0.98tunnel mode gre multipointtunnel key 1tunnel vrf isp1tunnel protection ipsec profile DMVPN

interface GigabitEthernet0/0/0.98encapsulation dot1Q 98ip vrf forwarding isp1ip address 3.3.39.3 255.255.255.0ip nat outside




interface Tunnel2bandwidth 10000ip vrf forwarding isp2ip address 10.2.2.3 255.255.255.0no ip redirectsip mtu 1400ip nhrp authentication Secretip nhrp summary-map 192.168.3.0/24ip nhrp network-id 2ip nhrp nhs 10.2.2.1 nbma 1.1.19.1 multicastno ip nhrp recordip summary-address eigrp 1 192.168.3.0 255.255.255.0ip tcp adjust-mss 1360delay 100tunnel source GigabitEthernet0/0/0.99tunnel mode gre multipointtunnel key 2tunnel vrf isp2tunnel protection ipsec profile DMVPN

interface GigabitEthernet0/0/0.99encapsulation dot1Q 99ip vrf forwarding isp2ip address 33.33.39.3 255.255.255.0ip nat outside

SingleHub,DualCloud

“ip nhrp shortcut” и “ip nhrp holdtime 600” – это значения по умолчанию в данной версии IOS-XE

interface GigabitEthernet0/0/1.75encapsulation dot1Q 75ip vrf forwarding isp1ip address 192.168.3.1 255.255.255.252ip nat inside

interface GigabitEthernet0/0/1.76encapsulation dot1Q 76ip vrf forwarding isp2ip address 192.168.3.5 255.255.255.252ip nat inside

router eigrp 100!address-family ipv4 vrf isp1 autonomous-system 1network 10.1.1.0 0.0.0.255network 192.168.3.0 0.0.0.3exit-address-family!address-family ipv4 vrf isp2 autonomous-system 1network 10.2.2.0 0.0.0.255network 192.168.3.4 0.0.0.3exit-address-family

ip route vrf isp1 0.0.0.0 0.0.0.0 3.3.39.9ip route vrf isp2 0.0.0.0 0.0.0.0 33.33.39.9




ip nat inside source route-map nat1 interfaceGigabitEthernet0/0/0.98 vrf isp1 overload

ip nat inside source route-map nat2 interfaceGigabitEthernet0/0/0.99 vrf isp2 overload

access-list 100 permit ip 192.168.3.0 0.0.0.255 any

route-map nat2 permit 10match ip address 100match interface GigabitEthernet0/0/0.99

route-map nat1 permit 10match ip address 100match interface GigabitEthernet0/0/0.98

Это транзитные интерфейсы, подключающие Spoke-3 к внутреннему L3-коммутатору

SingleHub,DualCloud

interface …ip address 192.168.3.2 255.255.255.252

interface …ip address 192.168.3.6 255.255.255.252

router eigrp 1network 192.168.3.0eigrp stub connected

ip sla 1icmp-echo 3.3.39.9 source-ip 192.168.3.33threshold 1000timeout 1500frequency 5ip sla schedule 1 life forever start-time now

ip sla 2icmp-echo 33.33.39.9 source-ip 192.168.3.33threshold 1000timeout 1500frequency 5ip sla schedule 2 life forever start-time now

Пример настройки L3 Switch



track 1 ip sla 1 reachabilitydelay down 20 up 20

track 2 ip sla 2 reachabilitydelay down 20 up 20

ip route 0.0.0.0 0.0.0.0 192.168.3.1 track 1ip route 0.0.0.0 0.0.0.0 192.168.3.5 track 2

ip route 3.3.39.0 255.255.255.0 192.168.3.1ip route 33.33.39.0 255.255.255.0 192.168.3.5

Если оба провайдера работают, то будет два маршрута по умолчанию и трафик будет распределяться CEF по хешу от пары SrcIP + DstIP

SingleHub,DualCloud

interface Tunnel1bandwidth 10000ip address 10.1.1.1 255.255.255.0no ip redirectsip mtu 1400no ip split-horizon eigrp 1ip nhrp authentication Secretip nhrp network-id 1ip nhrp redirectip summary-address eigrp 1 192.168.0.0 255.255.252.0ip tcp adjust-mss 1360delay 100tunnel source GigabitEthernet0/0/0tunnel mode gre multipointtunnel key 1tunnel protection ipsec profile DMVPN shared

interface GigabitEthernet0/0/0ip address 1.1.19.1 255.255.255.0

router eigrp 1network 10.1.1.0 0.0.0.255network 10.2.2.0 0.0.0.255network 192.168.1.0

Пример настройки Hub

• Наш Hub подключен только к одному провайдеру!


SingleHub,DualCloud

interface Tunnel2bandwidth 10000ip address 10.2.2.1 255.255.255.0no ip redirectsip mtu 1400no ip split-horizon eigrp 1ip nhrp authentication Secretip nhrp network-id 2ip nhrp redirectip summary-address eigrp 1 192.168.0.0 255.255.252.0ip tcp adjust-mss 1360delay 100tunnel source GigabitEthernet0/0/0tunnel mode gre multipointtunnel key 2tunnel protection ipsec profile DMVPN shared

Shared Tunnel Protection создает общую Security Policy Database (SPD) на два интерфейса, что устраняет неоднозначность в момент установления туннеля из-за использования общего “tunnel source”.Tunnel key устраняет неоднозначность, возникающую при демультиплексировании принятого трафика после его дешифрации и декапсуляции.Правила использования описаны в документации!

Hub-1#show crypto ipsec sa peer 2.2.29.2

interface: Tunnel1…


…inbound esp sas:spi: 0xA1FDC2AF(2717762223)outbound esp sas:spi: 0xD85986E(226859118)

…interface: Tunnel2…


…inbound esp sas:spi: 0xA1FDC2AF(2717762223)outbound esp sas:spi: 0xD85986E(226859118)


• В сл. Shared TP IPSec SA выглядят так:


SingleHub,DualCloud

Inbound & Outbound SPI перечисляются как под интерфейсом Tunnel1, так и под Tunnel2

Hub-1#show crypto sockets

Number of Crypto Socket connections 4

Shd Peers (local/remote): 1.1.19.1/2.2.29.2Local Ident (addr/mask/port/prot): (1.1.19.1/255.255.255.255/0/47)Remote Ident (addr/mask/port/prot): (2.2.29.2/255.255.255.255/0/47)Flags: sharedIPSec Profile: "DMVPN"Socket State: OpenClient: "TUNNEL SEC" (Client State: Active)



Shd Peers (local/remote): 1.1.19.1/33.33.39.3Local Ident (addr/mask/port/prot): (1.1.19.1/255.255.255.255/0/47)


• Следующий вывод еще более красноречив:


SingleHub,DualCloud

Проблемы Single Hub, Dual Cloud

• Эти проблемы связаны не с наличием двух ISP ине с использованием Shared Tunnel Protection

• В сл. DMVPN Phase3 проблемы возникают из-за наличия параллельных путей на Hub и Spokes (схема Active/Active)

• Не гарантируется, что CEF на Hub отбалансирует пакет, пришедший по tunnel1 от Spoke-2, в тот же самый tunnel1

• Если пакет отбалансируется в tunnel2, не будет NHRP Redirect• С ответом от Spoke-3 может возникнуть та же проблема и тогда

динамический туннель Spoke – Spoke не будет установлен• Либо может быть создан симплексный туннель и трафик пойдет:

Spoke-2 -> Hub -> Spoke-3 -> Spoke-2• На сегодняшний день код CEF switching не отдает приоритет

интерфейсу с тем же самым NHRP network-id при наличии параллельных путей!

• Phase2 гарантирует, что трафик не пойдет через Hub, но и в сл. Phase2 могут быть созданы два симплексных туннеля Spoke –Spoke


SingleHub,DualCloud

Per-Tunnel QoS for DMVPN



• Версии• Hub -> Spoke QoS: IOS 12.4(22)T, IOS-XE 15.2(2)S• Spoke -> Hub, Spoke <-> Spoke: IOS 15.5(2)T, IOS-XE 15.5(2)S• Adaptive QoS (AQOS): IOS 15.5(1)T, IOS-XE 15.5(1)S

• Как работает• Иерархическая политика QoS применяется к IPSec SA на output• Parent policy – shaping, child policy – bandwidth / priority / WRED /…• Классификация выполняется до инкапсуляции в GRE• Следовательно, не требуется “qos pre-classify”• Очередизация выполняется после инкапсуляции и шифрования• И следовательно после увеличения размера пакета• Окончательная иерархия планировщиков строится как бы на

внешнем физическом интерфейсе• На физическом интерфейсе допускается своя политика QoS, но

только с class-default shaper (т.н. MPoL – 15.2(2)T, 15.2(2)S)



• Как устроена сигнализация (control plane)• Peer сообщает символическое групповое имя по NHRP• С помощью Cisco Vendor Private Extension• Мы по этому имени находим в конфигурации service-policy• Настройка вступает в силу после прихода следующего сообщения

NHRP Registration Request или Registration Reply


! Spoke-2

interface Tunnel1nhrp group spokes

! Hub

interface Tunnel1nhrp map group spokes service-policy output to_spokes

От префикса “ip” отказались в 15.4(1)T, 15.4(1)S из-за реализации IPv6 per-tunnel DMVPN QoS.IPv6 в роли протокола-пассажира использует ту же самую политику QoS, что и IPv4.Т.е. суммарный трафик IPv4 и IPv6 попадает в общий shaper в parent policy.


• Основные ограничения• Вдвое уменьшает поддерживаемое число Spokes на платформах,

работающих под управлением IOS-XE (для IOS нет данных)• Может приводить к значительному увеличению загрузки CPU на тех

платформах, где QoS выполняется на том же процессоре (ядре), что и др. функции

• Не совместимо с др. типами QoS на том же физическом интерфейсе (например, с service-policy на point-to-point tunnel, если этот туннель пролегает через тот же физический интерфейс или один из его саб-интерфейсов)

• Не поддерживается в IOS и IOS-XE на ISR 4300/4400, если туннель пролегает через port-channel

• Требует IOS-XE 15.5(1)S для функционирования на ASR1k на туннелях, пролегающих через port-channel, при условии, что port-channel настроен в агрегированном режиме QoS (официально поддерживается с версии 16.4(1))



• Начиная с IOS 15.5(2)T, IOS-XE 15.5(2)S настройка Hub и Spoke стала полностью симметричной


! Hub

interface Tunnel1nhrp group hubnhrp map group spokes service-policy output to_spokes

! Spoke-2 & Spoke-3

interface Tunnel1nhrp group spokesnhrp map group hub service-policy output to_hubnhrp map group spokes service-policy output to_spokes

class-map match-any internetwork_controlmatch ip precedence 6 match access-group 150

class-map match-any VoIPmatch ip precedence 5 match ip precedence 3

class-map match-any business_criticalmatch access-group 151

policy-map test_innerclass internetwork_controlpriority percent 10class VoIPpriority percent 10class business_criticalbandwidth percent 50

policy-map to_spokesclass class-defaultshape average 1000000 service-policy test_inner

policy-map to_hubclass class-defaultshape average 2000000 service-policy test_inner

Как-то так...


• Основные диагностические команды (control plane)



10.1.1.1/32 via 10.1.1.1Tunnel1 created 00:06:33, never expire Type: static, Flags: used NBMA address: 1.1.19.1 Group: hub

Spoke-2#show ip nhrp group-map

Interface: Tunnel1NHRP group: hubQoS policy: to_hubTransport endpoints using the qos policy:1.1.19.1

NHRP group: spokesQoS policy: to_spokesTransport endpoints using the qos policy: None

Spoke-2#show dmvpn detail…# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb Target Network----- --------------- --------------- ----- -------- ----- -----------------

1 1.1.19.1 10.1.1.1 UP 00:06:18 S 10.1.1.1/32NHRP group: hubOutput QoS service-policy applied: to_hub


• Основные диагностические команды (data plane)


Spoke-3#show policy-map multipoint Tunnel2 1.1.19.1

Interface Tunnel2 <--> 1.1.19.1

Service-policy output: to_hub

Class-map: class-default (match-any) 89058 packets, 33641884 bytes30 second offered rate 2305000 bps, drop rate 541000 bpsMatch: any Queueingqueue limit 64 packets(queue depth/total drops/no-buffer drops) 0/24725/0(pkts output/bytes output) 64332/28412856shape (average) cir 2000000, bc 8000, be 8000target shape rate 2000000

Service-policy : test_inner

queue stats for all priority classes:Queueingqueue limit 512 packets(queue depth/total drops/no-buffer drops) 512/24725/0(pkts output/bytes output) 64332/28412856

…

Пример: При посылке большого объема трафика с Prec=5 из LAN Spoke3 в сторону Hubначинают расти дропы в priority queue

Текущая длина очереди = queue-limit


• Где еще отображаются дропы в IOS-XE в случае mGRE


Spoke-3#show interfaces tunnel2 | i rate|packets input|packets output|queue

Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 0Queueing strategy: fifoOutput queue: 0/0 (size/max)30 second input rate 1462000 bits/sec, 484 packets/sec30 second output rate 2248000 bits/sec, 744 packets/sec

58512 packets input, 22094508 bytes, 0 no buffer95622 packets output, 36121870 bytes, 0 underruns

Spoke-3#show interfaces summary…Interface IHQ IQD OHQ OQD RXBS RXPS TXBS TXPS TRTL

-----------------------------------------------------------------------------------------------------------------* GigabitEthernet0/0/0 0 0 0 26450 1671000 475 1962000 557 0* Gi0/0/0.98 - - - - - - - - -* Gi0/0/0.99 - - - - - - - - -* Tunnel1 0 0 0 0 0 0 0 0 0* Tunnel2 0 0 0 0 1462000 484 2248000 744 0

Spoke-3#show platform hardware qfp active statistics drop

-------------------------------------------------------------------------Global Drop Stats Packets Octets -------------------------------------------------------------------------TailDrop 26450 12228814

Total output drops отсутствуют на Tunnel2

Общесистемные счетчики дропов IOS-XE в разрезе дроп-кодов

Output drops отображаются на G0/0/0. При этом они агрегируются со всех сабинтерфейсов и туннелей


• Где еще отображаются дропы в IOS-XE в случае mGRE


Spoke-3#debug platform hardware qfp active interface if-stats int-name DmvpnSpoke4210707CPP Interface Stats debugging is on

Spoke-3#show platform hardware qfp active interface platform DmvpnSpoke4210707 statistics…----------------------------------------------------------------Input Drop Stats Packets Octets ----------------------------------------------------------------The Ingress drop stats were all zero

----------------------------------------------------------------Output Drop Stats Packets Octets ---------------------------------------------------------------TailDrop 1263 558246 …

Spoke-3#show platform software interface fp active brief…

Поинтерфейсная статистика дропов в разрезе различных дроп-кодов м.б. собрана только при включении debug

Spoke-3#show platform hardware qfp active interface all statistics drop_summary subinterface…Interface Rx Pkts Tx Pkts---------------------------------------------------------------------------GigabitEthernet0/0/0.99 0 26450DmvpnSpoke4210707 0 26450

IOS-XE 15.3(3)S2: per-SA статистика по дропам QoS на динамически создаваемом интерфейсе DMVPN

Такой интерфейс создается для каждого подключения, к которому была применена политика per-tunnel DMVPN QoS

Список всех интерфейсов IOS-XE, включая служебные и созданные динамически

EtherChannel QoS

• Пример настройки IOS-XE при использовании EtherChannel• Для выполнения QoS в иерархии планировщиков создается

логический узел, соответствующий port-channel interface• После QoS выполняется рециркуляция пакетов через

процессорный комплекс, их распределение в физические интерфейсы, образующие EtherChannel, и очередизация


platform qos port-channel-aggregate <port-channel-number>

interface Port-channel <port-channel-number>

interface GigabitEthernet0/0/0channel-group <port-channel-number>

interface GigabitEthernet0/0/1channel-group <port-channel-number>

interface Tunnel1tunnel source Port-channel <port-channel-number>

15.5(1)S – поддержка на p-to-p tunnels15.5(1)S – неофициальная поддержка для DMVPN16.4(1) – официальная поддержка для DMVPNПоддерживается только на платформе ASR1k

Адаптивный QoS

• Поддерживается с 15.5(1)T, 15.5(1)S• Стороны обмениваются информацией о числе переданных и

принятых пакетов (UDP/19000 -> UDP/18999, вычисляют drop rate и адаптируют параметры shaping (не чаще, чем раз в 60сек.)


policy-map <name>class class-defaultshape adaptive upper-bound 768000 lower-bound 320000

interface tunnel …nhrp map group <group-name> service-policy output <name>

show policy-map multipoint

Interface Tunnel1 <--> 1.1.19.1

Service-policy output: <name>

Class-map: class-default (match-any)...target shape rate 768000

Меняется динамически в зависимости от процента потерь

Адаптивный QoS – результаты симуляции


QoS и IPSec anti-replay

• Очередизация отрабатывает после инкапсуляции в IPSec• Поэтому приоритетный трафик, “забежавший” вперед

неприоритетного, может слишком далеко продвинуть скользящее окно механизма anti-replay на получателе

• В результате, “хвост”, не попавший в окно, будет отброшен получателем


Feb 25 14:49:45.149: %IOSXE-3-PLATFORM: SIP0: cpp_cp: QFP:0.0 Thread:004TS:00000163735728593182 %IPSEC-3-REPLAY_ERROR: IPSec SA receives anti-replayerror, DP Handle 6, src_addr 33.33.39.3, dest_addr 1.1.19.1, SPI 0xccb16dc5

Feb 25 14:50:45.635: %IOSXE-3-PLATFORM: SIP0: cpp_cp: QFP:0.0 Thread:003TS:00000163796210270459 %IPSEC-3-REPLAY_ERROR: IPSec SA receives anti-replayerror, DP Handle 6, src_addr 33.33.39.3, dest_addr 1.1.19.1, SPI 0xccb16dc5

Hub-1#show platform hardware qfp active feature ipsec datapath drops

------------------------------------------------------------------------Drop Type Name Packets ------------------------------------------------------------------------

19 IN_OCT_ANTI_REPLAY_FAIL 691

Эти сообщения выдаются не чаще, чем раз в минуту, но дропов обычно намного больше

Hub-1(config)#crypto ipsec security-association replay window-size 1024! OrHub-1(config)#crypto ipsec security-association replay disable

Настраивается на получателе, где эти сообщения выдаются.Значение window-size по умолчанию – 64 пакета.

BGP и BFD


BGP и BFD

• Почему BGP?• Лучшая масштабируемость и стабильность, чем у EIGRP

• Почему BFD?• Большие значения таймеров BGP HELLO/HOLD, медленное

обнаружение отказов и перестроение маршрутов• Без IPSec DMVPN Hub не может понять, что Spoke мертв, пока не

истечет время жизни записи в NHRP-кеше (NHRP holdtime)• Без IPSec DMVPN Spoke не может понять, что Hub мертв, пока не

придет время следующей перерегистрации NHRP + retransmits• С IPSec помогает механизм Dead Peer Detection (“crypto isakmp

keepalive”), но он тестирует не data path внутри туннеля, а достижимость процесса IKEv1/IKEv2 удаленного IPSec peer


Сравнение протоколов маршрутизации

• Какой протокол маршрутизации лучше?• EIGRP

• Наилучшим образом соответствует топологии Hub and Spoke• Быстрая сходимость (feasible successor)• Неплохая масштабируемость (“eigrp stub” на нетранзитных Spokes)• Легкость и гибкость в управлении метрикой• Управление next-hop (Self / Originating Spoke) – 15.2(3)T при ECMP

• BGP• Наилучшая масштабируемость• Достаточно медленная сходимость, большие таймеры• Сложнее конфигурируется• Более сложное, ручное управление метрикой (MED)• BGP Dynamic Neighbors – 15.1(2)T, IPv6 Dynamic Neighbors – 16.3

• OSPF• Плохая масштабируемость, очень большая area 0


BFD

• IOS-XE 16.3(1), до 4095 сессий BFD на ASR1k• BFD в сл. DMVPN запускается на mGRE-интерфейсе

• Интерфейсы point-to-point GRE также поддерживаются• Необходимо прописать NHS на p-to-p интерфейсе Spoke

• BFD проверяет data path внутри туннеля• Поддерживается обычный asynchronous mode и echo function• Работает на туннелях Spoke – Hub и Spoke – Spoke

• Интегрируется с NHRP• NHRP является клиентом BFD (как и EIGRP или BGP)• BFD уведомляет NHRP о недоступности tunnel endpoint (“down event”)• NHRP уведомляет др. модули (например, IPSec)

• NHRP не получает “up event” от BFD• За восстановление после разрыва связи отвечает IKEv1/IKEv2 и их

таймеры повторных передач


Пример: потеря связи между Spoke и Hub

• BFD уведомляет BGP• BGP neighbor reset

• BFD уведомляет NHRP• Set retransmit delay 2 и тут же посылает Registration Request на NHS• Через 2 сек, если ответ не получен, set retransmit delay 4 и пос. RR• Если опять ответ не получен, то NHS-DOWN• Т.е. 2 попытки и 6 сек. на проверку достижимости NHS• Set retransmit delay 8 и послать Registration Request• Set retransmit delay 16 и послать Registration Request• Примерно в это время NHRP уведомляет IPSec о недостижимости• IPSec SA и IKEv1/IKEv2 SA удаляются (т.е. IPSec падает за ~15 сек)• Set retransmit delay 32, затем 64, 64, … и послать RR• В это время IKEv1/IKEv2 пытается переустановить туннель в

соответствии со своими таймерами повторных передач


Пример настройки BGP и BFD

• Пример для Hub (DMVPN Phase3)


bfd-template single-hop DMVPNinterval min-tx 2000 min-rx 2000 multiplier 3echo

interface Tunnel1bandwidth 10000ip address 10.1.1.1 255.255.255.0no ip redirectsip mtu 1400ip nhrp authentication Secretip nhrp network-id 1ip nhrp redirectip tcp adjust-mss 1360load-interval 30delay 100nhrp group hubnhrp map group spokes service-policy output to_spokesbfd template DMVPNtunnel source GigabitEthernet0/0/0tunnel mode gre multipointtunnel key 1tunnel protection ipsec profile DMVPN shared

interface Tunnel2…

router bgp 65000bgp log-neighbor-changesbgp listen range 10.0.0.0/8 peer-group spokesneighbor spokes peer-groupneighbor spokes remote-as 65000neighbor spokes timers 20 60neighbor spokes fall-over bfd!address-family ipv4network 192.168.1.0aggregate-address 192.168.0.0 255.255.252.0 summary-onlyneighbor spokes activateneighbor spokes route-reflector-clientneighbor spokes next-hop-self allmaximum-paths ibgp 2exit-address-family

Как обсуждалось ранее, параллельные пути приводят к проблемам с туннелями Spoke-Spoke в DMVPN Phase3 Single-Hub, Dual-Cloud.Для реализации схемы Active/Backup можно использовать BGP MED.

“all” необходимо на Route Reflector, хотя настраивать Hub как Route Reflector было необязательно, т.к. он заявляет суммарный маршрут

BGP Dynamic Peers

BGP – клиент BFD


• Пример для Spoke-3


ip vrf isp1rd 1:1

ip vrf isp2rd 2:2

bfd-template single-hop DMVPNinterval min-tx 2000 min-rx 2000 multiplier 3echo

interface Tunnel1bandwidth 10000ip vrf forwarding isp1ip address 10.1.1.3 255.255.255.0no ip redirectsip mtu 1400ip nhrp authentication Secretip nhrp summary-map 192.168.3.0/24ip nhrp network-id 1ip nhrp nhs 10.1.1.1 nbma 1.1.19.1 multicastno ip nhrp recordip tcp adjust-mss 1360load-interval 30delay 100nhrp group spokesnhrp map group hub service-policy output to_hubnhrp map group spokes service-policy output to_spokes

interface Tunnel1 ! (cont.)bfd template DMVPNtunnel source GigabitEthernet0/0/0.98tunnel mode gre multipointtunnel key 1tunnel vrf isp1tunnel protection ipsec profile DMVPN

interface Tunnel2bandwidth 10000ip vrf forwarding isp2ip address 10.2.2.3 255.255.255.0…

“ip nhrp shortcut” и “ip nhrp holdtime 600” – это значения по умолчанию в данной версии IOS-XE


• Пример для Spoke-3


router eigrp 100!address-family ipv4 vrf isp1 autonomous-system 1redistribute bgp 65000 route-map bgp-eigrpnetwork 192.168.3.0 0.0.0.3exit-address-family!address-family ipv4 vrf isp2 autonomous-system 1redistribute bgp 65000 route-map bgp-eigrpnetwork 192.168.3.4 0.0.0.3exit-address-family

ip prefix-list b-e seq 5 permit 192.168.0.0/22 le 23

route-map bgp-eigrp permit 10match ip address prefix-list b-eset metric 10000 100 255 1 1500

router bgp 65000bgp router-id 192.168.3.3bgp log-neighbor-changes!address-family ipv4 vrf isp1aggregate-address 192.168.3.0 255.255.255.0 summary-onlyredistribute eigrp 1 route-map eigrp-bgpneighbor 10.1.1.1 remote-as 65000neighbor 10.1.1.1 timers 20 60neighbor 10.1.1.1 fall-over bfdneighbor 10.1.1.1 activateexit-address-family!address-family ipv4 vrf isp2aggregate-address 192.168.3.0 255.255.255.0 summary-onlyredistribute eigrp 1 route-map eigrp-bgpneighbor 10.2.2.1 remote-as 65000neighbor 10.2.2.1 timers 20 60neighbor 10.2.2.1 fall-over bfdneighbor 10.2.2.1 activateexit-address-family

ip prefix-list e-b seq 5 permit 192.168.3.0/24 ge 25

route-map eigrp-bgp permit 10match ip address prefix-list e-b


• Что получилось на Hub


Hub-1#show bfd neighbors

IPv4 SessionsNeighAddr LD/RD RH/RS State Int10.1.1.2 4099/0 Down Down Tu110.1.1.3 4098/4098 Up Up Tu110.2.2.2 4100/0 Down Down Tu210.2.2.3 4097/4097 Up Up Tu2

Hub-1#show bfd neighbors ipv4 10.1.1.3 details

IPv4 SessionsNeighAddr LD/RD RH/RS State Int10.1.1.3 4098/4098 Up Up Tu1Session state is UP and using echo function with 2000 ms interval.Session Host: SoftwareOurAddr: 10.1.1.1Handle: 2Local Diag: 0, Demand mode: 0, Poll bit: 0MinTxInt: 1000000, MinRxInt: 1000000, Multiplier: 3Received MinRxInt: 1000000, Received Multiplier: 3Holddown (hits): 0(0), Hello (hits): 1000(1158)Rx Count: 1155, Rx Interval (ms) min/max/avg: 1/1003/875 last: 359 ms agoTx Count: 1160, Tx Interval (ms) min/max/avg: 1/1001/872 last: 555 ms agoElapsed time watermarks: 0 0 (last: 0)Registered protocols: NHRP CEF BGPTemplate: DMVPNUptime: 00:16:51

IOS на Spoke-2 не поддерживает BFD. Поддержка будет реализована в одной из следующих версий IOS


• Что получилось на Hub (IOS на Spoke-2 не поддерживает BFD)


Hub-1#show dmvpn…Interface: Tunnel1, IPv4 NHRP DetailsType:Hub, NHRP Peers:2,


1 2.2.29.2 10.1.1.2 BFD 14:21:36 D1 3.3.39.3 10.1.1.3 UP 00:19:54 D

Interface: Tunnel2, IPv4 NHRP DetailsType:Hub, NHRP Peers:2,


1 22.22.29.2 10.2.2.2 BFD 14:21:29 D1 33.33.39.3 10.2.2.3 UP 00:20:04 D

Hub-1#show ip nhrp

10.1.1.2/32 via 10.1.1.2Tunnel1 created 14:23:12, expire 00:06:53Type: dynamic, Flags: registered nhop bfdNBMA address: 2.2.29.2Group: spokes

State BFD: UP с т.зр. IKE/IPSec, но DOWN с т.зр. BFDТ.е. “состояние” здесь – это имя самого нижнего уровня, где все плохо, например, IKE или BFD

Есть сессия BFD с этим роутером, но она м.б. как в состоянии UP, так и в состоянии DOWN

Рекомендации по масштабируемости


Базовые рекомендации

• IPSec Transport Mode• “ip mtu 1400”, “ipv6 mtu 1380”• “ip tcp adjust-mss 1360”, “ipv6 tcp adjust-mss 1320”• Не используйте periodic DPD (“crypto isakmp keepalive … periodic”)• Таймер рассылок DPD д.б. > Hello-таймера IGP/BGP• Не конфигурируйте DPD на Hub в очень большой сети• CAC: “crypto call admission limit ike in-negotiation-sa 20-60”• Не настраивайте “crypto isakmp invalid-spi-recovery” на Hub• Задайте осмысленный “{ip | ipv6} nhrp holdtime”

• Обычно 300-600 сек. в сл. использования туннелей spoke – spoke

• Используйте “{ip | ipv6} nhrp registration no-unique”• В старых версиях: “{ip | ipv6} nhrp max-send … every …”


Базовые рекомендации

• В очень больших сетях полезно увеличение hold-queue на туннельных и физических интерфейсах

• “hold-queue <1024-4096> in”• “hold-queue <1024-4096> out”

• Дальнейшая настройка для IGP / BGP может потребовать изменения параметров Selective Packet Discard (SPD)

• Звоните в TAC

• Используйте “crypto logging session”• Не используйте “logging dmvpn”• Настройте CPU Threshold Notifications

• “process cpu threshold type {interrupt | process | total} rising <1-100> interval <5-x> [falling <1-100> interval <5-x>]”

• Используйте syslog, SNMP, EEM, etc. для мониторинга


Рекомендации для EIGRP

• Не забудьте прописать “bandwidth …” на туннельном интерфейсе• Управляйте метрикой с помощью “delay …”• Используйте суммаризацию на Spokes• Используйте суммаризацию на Hub (DMVPN Phase3)• Используйте суммаризацию DMVPN <-> CORE• Используйте команду “summary-metric” для снижения загрузки CPU• Применяйте “eigrp stub” на нетранзитных Spokes• Увеличьте таймеры Hello/Hold в большой сети



Сообщество Технической поддержки Cisco

https://supportforums.cisco.com

http://russiansupportforum.cisco.com

email:[email protected]

#CiscoConnectRu#CiscoConnectRu

Спасибо за внимание!Оцените данную сессию в мобильном приложении конференции

© 2017 Cisco and/or its affiliates. All rights reserved.

Контакты:

Тел.: +7 495 9611410www.cisco.com

www.facebook.com/CiscoRu

www.vk.com/cisco

www.instagram.com/ciscoru

www.youtube.com/user/CiscoRussiaMedia

12 35-13 35-Олег Типисов-Как настроить DMVPN и избежать ... ·...

Documents

Transcript of 12 35-13 35-Олег Типисов-Как настроить DMVPN и избежать ... ·...