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

Cisco
Connect
Москва, 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.1
Tunnel1: 10.1.1.1
Tunnel2: 10.2.2.1
Spoke-3
Physical: 2.2.29.2
Tunnel1: 10.1.1.2
Physical: 3.3.39.3
Tunnel1: 10.1.1.3
192.168.1.1/24
Hub-1
192.168.3.32/27
Physical: 22.22.29.2
Tunnel2: 10.2.2.2
Tunnel2: 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
Dynamic Spoke-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.1
Tunnel1: 10.1.1.1
Physical: 2.2.29.2
Tunnel1: 10.1.1.2
Physical: 3.3.39.3
Tunnel1: 10.1.1.3
Static Spoke-to-hub tunnels
Static known
IP address
Can have
dynamic or
unknown IPs
LANs can have
private addressing

Протокол 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 Peer
Detection (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-2
192.168.2.2/24
= Permanent IPsec tunnels
192.168.3.3/24
Physical: 1.1.19.1
Tunnel1: 10.1.1.1
Spoke-3
Physical: 2.2.29.2
Tunnel1: 10.1.1.2
Physical: 3.3.39.3
Tunnel1: 10.1.1.3
10.1.1.1 à 1.1.19.1 10.1.1.1 à 1.1.19.1
10.1.1.2 à 2.2.29.2
10.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.
NHRP mapping
Routing Table
NHRP Registration

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-2
192.168.2.2/24
192.168.3.3/24
Physical: 1.1.19.1
Tunnel1: 10.1.1.1
Spoke-3
Physical: 2.2.29.2
Tunnel1: 10.1.1.2
Physical: 3.3.39.3
Tunnel1: 10.1.1.3
10.1.1.2 à 2.2.29.2192.168.1.1/24
192.168.2.0/24 à 10.1.1.2
192.168.3.0/24 à 10.1.1.3
192.168.1.0/24 à Conn.
192.168.1.0/24 à 10.1.1.1
192.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.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.1 10.1.1.1 à 1.1.19.1
10.1.1.3 à incomplete 10.1.1.2 à incomplete
10.1.1.2 à 2.2.29.2
CEF FIB Table
NHRP mapping
CEF Adjacency
Data packet
NHRP Resolution
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-2
192.168.2.2/24
192.168.3.3/24
Physical: 1.1.19.1
Tunnel1: 10.1.1.1
Spoke-3
Physical: 2.2.29.2
Tunnel1: 10.1.1.2
Physical: 3.3.39.3
Tunnel1: 10.1.1.3
192.168.1.1/24
192.168.2.0/24 à 10.1.1.2
192.168.3.0/24 à 10.1.1.3
192.168.1.0/24 à Conn.
192.168.1.0/24 à 10.1.1.1
192.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.2
10.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.1
10.1.1.1 à 1.1.19.1
10.1.1.3 à incomplete10.1.1.3 à 3.3.39.3
10.1.1.2 à incomplete 10.1.1.2 à 2.2.29.2
10.1.1.2 à 2.2.29.2
10.1.1.3 à 3.3.39.3
CEF FIB Table
NHRP mapping
CEF Adjacency
Data packet
NHRP Resolution
10.1.1.3 à 3.3.39.3
10.1.1.2 à 2.2.29.2
10.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-2
192.168.2.2/24
192.168.3.3/24
Physical: 1.1.19.1
Tunnel1: 10.1.1.1
Spoke-3
Physical: 2.2.29.2
Tunnel1: 10.1.1.2
Physical: 3.3.39.3
Tunnel1: 10.1.1.3
10.1.1.1 à 1.1.19.1 10.1.1.1 à 1.1.19.1
= Permanent IPsec tunnels
10.1.1.2 à 2.2.29.2
10.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.2
192.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.
NHRP mapping
Routing Table
Routing packet
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-2
192.168.2.2/24
192.168.3.3/24
Physical: 1.1.19.1
Tunnel1: 10.1.1.1
Spoke-3
Physical: 2.2.29.2
Tunnel1: 10.1.1.2
Physical: 3.3.39.3
Tunnel1: 10.1.1.3
10.1.1.2 à 2.2.29.2
10.1.1.3 à 3.3.39.3
192.168.1.1/24
192.168.2.0/24 à 10.1.1.2
192.168.3.0/24 à 10.1.1.3
192.168.1.0/24 à Conn.
CEF FIB Table
NHRP mapping
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.1
192.168.0.0/16 à 10.1.1.1
CEF Adjacency
10.1.1.1 à 1.1.19.1
10.1.1.2 à 2.2.29.2
Data packet
NHRP Redirect
NHRP Resolution
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-2
192.168.2.2/24
192.168.3.3/24
Physical: 1.1.19.1
Tunnel1: 10.1.1.1
Spoke-3
Physical: 2.2.29.2
Tunnel1: 10.1.1.2
Physical: 3.3.39.3
Tunnel1: 10.1.1.3
10.1.1.2 à 2.2.29.2
10.1.1.3 à 3.3.39.3
192.168.1.1/24
192.168.2.0/24 à 10.1.1.2
192.168.3.0/24 à 10.1.1.3
192.168.1.0/24 à Conn.
CEF FIB Table
NHRP mapping
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.1
192.168.0.0/16 à 10.1.1.1
CEF Adjacency
10.1.1.1 à 1.1.19.1
10.1.1.2 à 2.2.29.2
10.1.1.2 à 2.2.29.2
10.1.1.2 à 2.2.29.2
Data packet
NHRP Redirect
NHRP Resolution
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-2
192.168.2.2/24
192.168.3.3/24
Physical: 1.1.19.1
Tunnel1: 10.1.1.1
Spoke-3
Physical: 2.2.29.2
Tunnel1: 10.1.1.2
Physical: 3.3.39.3
Tunnel1: 10.1.1.3
10.1.1.2 à 2.2.29.2
10.1.1.3 à 3.3.39.3
192.168.1.1/24
192.168.2.0/24 à 10.1.1.2
192.168.3.0/24 à 10.1.1.3
192.168.1.0/24 à Conn.
CEF FIB Table
NHRP mapping
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
CEF Adjacency
10.1.1.1 à 1.1.19.1
10.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.3
10.1.1.2 à 2.2.29.2
Data packet
NHRP Redirect
NHRP Resolution
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.3
192.168.2.0/24 à 2.2.29.2
192.168.3.0/24 à 10.1.1.3
192.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 10
encr aes
authentication pre-share
group 2
crypto isakmp key cisco address 0.0.0.0
crypto isakmp keepalive 10 3
crypto ipsec transform-set DMVPN esp-aes esp-sha-hmac
mode transport
crypto ipsec profile DMVPN
set transform-set DMVPN
crypto call admission limit ike in-negotiation-sa 20
interface Tunnel1
ip mtu 1400
ip tcp adjust-mss 1360
tunnel source GigabitEthernet0/0/0
tunnel 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 Tunnel1
bandwidth 10000
delay 100
ip address 10.1.1.1 255.255.255.0
no ip redirects
no ip next-hop-self eigrp 1
no ip split-horizon eigrp 1
ip nhrp authentication Secret
ip nhrp network-id 1
ip nhrp map multicast dynamic
! Spoke-2
interface Tunnel1
bandwidth 10000
delay 100
ip address 10.1.1.2 255.255.255.0
no ip redirects
ip nhrp holdtime 600
ip nhrp nhs 10.1.1.1 nbma 1.1.19.1 multicast
ip nhrp registration no-unique
ПараметрыEIGRP
В больших сетях необходимоувеличитьтаймеры
Значение по умолчаниюначинаяс 16.3(1)
Используйте “showrun all | sec interface Tunnel1”
Используйте “showrun all | sec interface Tunnel1”
Синтаксис, совмещающий:
ip nhrp nhs 10.1.1.1
ip nhrp map 10.1.1.1 1.1.19.1
ip nhrp map multicast 1.1.19.1
Необходимо, если NBMA-адрес Spoke может
меняться

! Hub
router eigrp 1
network 10.1.1.0 0.0.0.255
network 192.168.1.0
ip route 0.0.0.0 0.0.0.0 1.1.19.9
! Spoke-2
router eigrp 1
network 10.1.1.0 0.0.0.255
network 192.168.2.0
eigrp stub connected
ip route 0.0.0.0 0.0.0.0 2.2.29.9
• Маршрутизация
Используйте stubmode на нетранзитных узлах для
лучшей масштабируемости 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
RegistrationTimeout вычисляетсяавтоматическикак
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.2
Tunnel1 created 00:04:12, expire 00:07:07
Type: dynamic, Flags: registered nhop
NBMA address: 2.2.29.2
10.1.1.3/32 via 10.1.1.3
Type: dynamic, Flags: registered nhop
Hub-1#show ip nhrp multicast
I/F NBMA address
Tunnel1 3.3.39.3 Flags: dynamic (Enabled)
Tunnel1 2.2.29.2 Flags: dynamic (Enabled)
Hub-1#show dmvpn [detail]
Interface: Tunnel1, IPv4 NHRP Details
Type: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 D
1 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, Tunnel1
D 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.1
Tunnel1 created 18:42:09, never expire
Type: static, Flags: used
Spoke-2#show ip nhrp nhs detail
Legend: E=Expecting replies, R=Responding, W=Waiting
Tunnel1:
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
Type: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, Tunnel1
D 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 SA
dst src state conn-id status
3.3.39.3 2.2.29.2 QM_IDLE 2009 ACTIVE
2.2.29.2 3.3.39.3 QM_IDLE 2008 ACTIVE
1.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
10.1.1.1/32 via 10.1.1.1
10.1.1.2/32 via 10.1.1.2
Type: dynamic, Flags: router unique local
(no-socket)
10.1.1.3/32 via 10.1.1.3
Type: dynamic, Flags: router nhop
Дубликатыбудутудаленыпосле rekey
(если, конечно, туннельне будетудален
раньше из-за истеченияNHRP holdtime
при отсутствии трафика)
Таблица маршрутизациине меняется

DMVPN Phase3

! Hub
interface Tunnel1
ip next-hop-self eigrp 1
ip nhrp redirect
! Spoke-2 & Spoke-3
interface Tunnel1
ip nhrp shortcut
• Приведены только изменения конфигурации по ср. с Phase2
• На Spoke-3 сеть 192.168.3.0/24 разбита на несколько подсетей
Значение по умолчаниювовсех версиях
interface Tunnel1
ip 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, Null0
D 192.168.3.4/30
[90/28416] via 192.168.3.2, 15:08:54, GigabitEthernet0/0/1.75
D 192.168.3.32/27
D 192.168.3.128/25

• Трафик посылается с 192.168.2.22 на 192.168.3.33
! Spoke-2
10.1.1.1/32 via 10.1.1.1
10.1.1.3/32 via 10.1.1.3
Type: dynamic, Flags: router nhop rib
192.168.2.0/24 via 10.1.1.2
(no-socket)
192.168.3.32/27 via 10.1.1.3
Type: dynamic, Flags: router rib
! Spoke-2
Spoke-2#show ip route
…
H 10.1.1.3/32 is directly connected, 00:00:38, Tunnel1
D 192.168.3.0/24 [90/307456] via 10.1.1.1, 00:03:11, Tunnel1
H 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.1
10.1.1.2/32 (isp1) via 10.1.1.2
Type: dynamic, Flags: router nhop rib
192.168.2.0/24 (isp1) via 10.1.1.2
Type: dynamic, Flags: router rib nho
192.168.3.32/27 (isp1) via 10.1.1.3
(no-socket)
! Spoke-3
…
D % 192.168.2.0/24 [90/309760] via 10.1.1.1, 00:04:29, Tunnel1
Spoke-3#show ip route next-hop-override
…
D % 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
…
192.168.3.32/27 via 10.1.1.3
192.168.3.128/25 via 10.1.1.3
! Spoke-2
…
D 192.168.3.0/24 [90/307456] via 10.1.1.1, 00:06:53, Tunnel1
H 192.168.3.32/27 [250/255] via 10.1.1.3, 00:04:20, Tunnel1
H 192.168.3.128/25 [250/255] via 10.1.1.3, 00:00:14, Tunnel1

! Spoke-3
interface Tunnel1
ip nhrp summary-map 192.168.3.0/24
• Чтобы предотвратить создание на Spoke-2 нового маршрута
NHRP на каждую подсеть можно суммировать их на Spoke-3
• В результате, на Spoke-2 получим
Суммаризация в NHRP
Появилосьв 15.5(3)M, 15.5(3)S
…
192.168.3.0/24 via 10.1.1.3
Type: dynamic, Flags: router rib nho
Spoke-2#show ip route next-hop-override
…
D % 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
= Dynamic Spoke-to-spoke
Dual Hub, Single Cloud Dual Hub, Dual Cloud
Single Hub, Dual Cloud
А длячего это все?
• Распределение нагрузки на 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”
Dual Hub, Single Cloud

Dual Hub, Dual Cloud
• Два туннельных интерфейса на Spokes
• Используется в 90% инсталяций
• Легче подключить Spokes к двум ISP
• Не требуется провайдеро-независимый адрес
• Элементарно реализуется увеличением EIGRP “delay”
• В сл. схемы Active/Active на Spokes будут параллельные пути
• Туннели Spoke – Spoke работают
• За исключением случая, когда из-за проблем провайдеров Spoke-1
может общаться только с Hub-1, а Spoke-2 – только с Hub-2
• Но могут создаться два туннеля Spoke – Spoke (в сл. Active/Active)
• Более того, возможна асимметричная маршрутизация
Dual Hub, Dual Cloud

• Самый сложный вариант
• Два туннельных интерфейса
• Не рекомендуется, т.к. создает точку отказа (Hub)
• Каждый роутер м.б. подключен к двум ISP
• Элементарно реализуется увеличением 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)

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

Вопросы, на которые необходимо ответить
• С какого адреса инициировать туннель (“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 Tunnel1
ip address 10.1.1.2 255.255.255.0
ip nhrp shortcut
tunnel source GigabitEthernet0.26
tunnel key 1
tunnel route-via GigabitEthernet0.26 mandatory
tunnel protection ipsec profile DMVPN
interface Tunnel2
ip address 10.2.2.2 255.255.255.0
ip nhrp shortcut
tunnel source GigabitEthernet0.27
tunnel key 2
tunnel route-via GigabitEthernet0.27 mandatory
interface GigabitEthernet0.26
encapsulation dot1Q 26
ip address 2.2.29.2 255.255.255.0
interface GigabitEthernet0.27
ip 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.9
ip route 0.0.0.0 0.0.0.0 22.22.29.9
access-list 1 permit 2.2.29.2
access-list 2 permit 22.22.29.2
route-map Local-PBR permit 10
match ip address 1
set ip next-hop 2.2.29.9
route-map Local-PBR permit 20
match ip address 2
set ip next-hop 22.22.29.9
ip local policy route-map Local-PBR
Необходимодляустановлениятуннелячерез
“правильный”интерфейс

Пример настройки Spoke-3 (IOS-XE)
• В IOS-XE “tunnel route-via” пока не реализовано
• Это приводит к крайне замысловатой настройке, которая ниже
приведена практически полностью
• Мы “пилим” роутер на два VRF “isp1” и “isp2” и затем
“склеиваем” их на внутреннем L3-коммутаторе
• Маршрутизация DMVPN реализуется с помощью EIGRP
• Маршрутизация в Internet реализуется с помощью статических
маршрутов по умолчанию в каждом из VRF
• Для отказоустойчивого выхода в Internet используется IP SLA и
tracking на внутреннем L3-коммутаторе

ip vrf isp1
ip vrf isp2
crypto keyring isp1 vrf isp1
pre-shared-key address 0.0.0.0 0.0.0.0 key cisco
crypto keyring isp2 vrf isp2
pre-shared-key address 0.0.0.0 0.0.0.0 key cisco
crypto logging session
crypto isakmp policy 10
encr aes
authentication pre-share
group 2
crypto isakmp keepalive 10 3
crypto ipsec transform-set DMVPN esp-aes esp-sha-hmac
mode transport
crypto ipsec profile DMVPN
set transform-set DMVPN
crypto call admission limit ike in-negotiation-sa 20
• В IOS-XE приходится применять VRF-Lite
Поиск PSK производитсяв VRF, т.к. внешние
физические интерфейсыбудутназначеныв VRF’ы
Spoke-2
192.168.2.2/24
Spoke-3
Physical: 3.3.39.3
Tunnel1: 10.1.1.3
192.168.1.1/24
Hub-1
Tunnel2: 10.2.2.3

interface Tunnel1
bandwidth 10000
ip vrf forwarding isp1
ip address 10.1.1.3 255.255.255.0
no ip redirects
ip mtu 1400
no ip nhrp record
ip summary-address eigrp 1 192.168.3.0 255.255.255.0
delay 100
tunnel source GigabitEthernet0/0/0.98
tunnel key 1
tunnel vrf isp1
interface GigabitEthernet0/0/0.98
ip address 3.3.39.3 255.255.255.0
ip nat outside
interface Tunnel2
bandwidth 10000
ip address 10.2.2.3 255.255.255.0
no ip redirects
ip mtu 1400
no ip nhrp record
delay 100
tunnel key 2
tunnel vrf isp2
ip address 33.33.39.3 255.255.255.0
ip nat outside
“ip nhrp shortcut”и “ip nhrp holdtime 600” – это значенияпо
умолчаниюв данной версииIOS-XE

ip address 192.168.3.1 255.255.255.252
ip nat inside
ip address 192.168.3.5 255.255.255.252
ip nat inside
router eigrp 100
!
address-family ipv4 vrf isp1 autonomous-system 1
network 10.1.1.0 0.0.0.255
network 192.168.3.0 0.0.0.3
exit-address-family
!
network 10.2.2.0 0.0.0.255
network 192.168.3.4 0.0.0.3
exit-address-family
ip route vrf isp1 0.0.0.0 0.0.0.0 3.3.39.9
ip route vrf isp2 0.0.0.0 0.0.0.0 33.33.39.9
ip nat inside source route-map nat1 interface
GigabitEthernet0/0/0.98 vrf isp1 overload
ip nat inside source route-map nat2 interface
GigabitEthernet0/0/0.99 vrf isp2 overload
access-list 100 permit ip 192.168.3.0 0.0.0.255 any
route-map nat2 permit 10
match ip address 100
match interface GigabitEthernet0/0/0.99
route-map nat1 permit 10
match ip address 100
match interface GigabitEthernet0/0/0.98
Это транзитные интерфейсы, подключающие Spoke-3
к внутреннему L3-коммутатору

interface …
ip address 192.168.3.2 255.255.255.252
interface …
ip address 192.168.3.6 255.255.255.252
router eigrp 1
network 192.168.3.0
eigrp stub connected
ip sla 1
icmp-echo 3.3.39.9 source-ip 192.168.3.33
threshold 1000
timeout 1500
frequency 5
ip sla schedule 1 life forever start-time now
ip sla 2
icmp-echo 33.33.39.9 source-ip 192.168.3.33
threshold 1000
timeout 1500
frequency 5
ip sla schedule 2 life forever start-time now
Пример настройки L3 Switch
track 1 ip sla 1 reachability
delay down 20 up 20
track 2 ip sla 2 reachability
delay down 20 up 20
ip route 0.0.0.0 0.0.0.0 192.168.3.1 track 1
ip 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.1
ip route 33.33.39.0 255.255.255.0 192.168.3.5
Если оба провайдера работают, то будетдва
маршрута по умолчаниюи трафик будет
распределятьсяCEF похешу отпарыSrcIP +DstIP

interface Tunnel1
bandwidth 10000
ip address 10.1.1.1 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp redirect
delay 100
tunnel key 1
tunnel protection ipsec profile DMVPN shared
interface GigabitEthernet0/0/0
ip address 1.1.19.1 255.255.255.0
router eigrp 1
network 10.1.1.0 0.0.0.255
network 10.2.2.0 0.0.0.255
network 192.168.1.0
Пример настройки Hub
• Наш Hub подключен только к одному провайдеру!
interface Tunnel2
bandwidth 10000
ip address 10.2.2.1 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp redirect
delay 100
tunnel key 2
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 выглядят так:
Inbound& OutboundSPI перечисляютсякакпод
интерфейсом Tunnel1, так и под Tunnel2

Hub-1#show crypto sockets
Number of Crypto Socket connections 4
Shd Peers (local/remote): 1.1.19.1/2.2.29.2
Local 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: shared
IPSec Profile: "DMVPN"
Socket State: Open
Client: "TUNNEL SEC" (Client State: Active)
Flags: shared
Socket State: Open
Flags: shared
Socket State: Open
• Следующий вывод еще более красноречив:

Проблемы 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

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 Tunnel1
nhrp group spokes
! Hub
interface Tunnel1
nhrp 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 Tunnel1
nhrp group hub
! Spoke-2 & Spoke-3
interface Tunnel1
nhrp group spokes
nhrp map group hub service-policy output to_hub
class-map match-any internetwork_control
match ip precedence 6
match access-group 150
class-map match-any VoIP
class-map match-any business_critical
match access-group 151
policy-map test_inner
class internetwork_control
priority percent 10
class VoIP
priority percent 10
class business_critical
bandwidth percent 50
policy-map to_spokes
class class-default
shape average 1000000
service-policy test_inner
policy-map to_hub
class class-default
shape average 2000000
service-policy test_inner
Как-то так...

• Основные диагностические команды (control plane)
10.1.1.1/32 via 10.1.1.1
Group: hub
Spoke-2#show ip nhrp group-map
Interface: Tunnel1
NHRP group: hub
QoS policy: to_hub
Transport endpoints using the qos policy:
1.1.19.1
NHRP group: spokes
QoS policy: to_spokes
Transport 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/32
NHRP group: hub
Output 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 bytes
30 second offered rate 2305000 bps, drop rate 541000 bps
Match: any
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/24725/0
(pkts output/bytes output) 64332/28412856
shape (average) cir 2000000, bc 8000, be 8000
target shape rate 2000000
Service-policy : test_inner
queue stats for all priority classes:
Queueing
queue 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: 0
Queueing strategy: fifo
Output queue: 0/0 (size/max)
30 second input rate 1462000 bits/sec, 484 packets/sec
30 second output rate 2248000 bits/sec, 744 packets/sec
58512 packets input, 22094508 bytes, 0 no buffer
95622 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 outputdropsотсутствуютна Tunnel2
Общесистемные счетчики дроповIOS-XE в
разрезе дроп-кодов
Outputdrops отображаютсяна G0/0/0. При этом
они агрегируютсясо всех сабинтерфейсов и
туннелей

• Где еще отображаются дропы в IOS-XE в случае mGRE
Spoke-3#debug platform hardware qfp active interface if-stats int-name DmvpnSpoke4210707
CPP 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 26450
DmvpnSpoke4210707 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>
channel-group <port-channel-number>
channel-group <port-channel-number>
interface Tunnel1
tunnel source Port-channel <port-channel-number>
15.5(1)S – поддержка на p-to-p tunnels
15.5(1)S – неофициальнаяподдержка дляDMVPN
16.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-default
shape 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:004
TS:00000163735728593182 %IPSEC-3-REPLAY_ERROR: IPSec SA receives anti-replay
error, 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:003
TS:00000163796210270459 %IPSEC-3-REPLAY_ERROR: IPSec SA receives anti-replay
error, 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
! Or
Hub-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 DMVPN
interval min-tx 2000 min-rx 2000 multiplier 3
echo
interface Tunnel1
bandwidth 10000
ip address 10.1.1.1 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp redirect
load-interval 30
delay 100
nhrp group hub
bfd template DMVPN
tunnel key 1
interface Tunnel2
…
router bgp 65000
bgp log-neighbor-changes
bgp listen range 10.0.0.0/8 peer-group spokes
neighbor spokes peer-group
neighbor spokes remote-as 65000
neighbor spokes timers 20 60
neighbor spokes fall-over bfd
!
address-family ipv4
network 192.168.1.0
aggregate-address 192.168.0.0 255.255.252.0 summary-only
neighbor spokes activate
neighbor spokes route-reflector-client
neighbor spokes next-hop-self all
maximum-paths ibgp 2
exit-address-family
Как обсуждалосьранее, параллельныепути
приводятк проблемам с туннелями Spoke-
Spoke в DMVPN Phase3 Single-Hub, Dual-Cloud.
Дляреализации схемыActive/Backup можно
использовать BGP MED.
“all” необходимо на RouteReflector,
хотянастраивать Hub какRoute
Reflector было необязательно, т.к.
он заявляетсуммарный маршрут
BGP Dynamic Peers
BGP – клиентBFD

• Пример для Spoke-3
ip vrf isp1
rd 1:1
ip vrf isp2
rd 2:2
bfd-template single-hop DMVPN
interval min-tx 2000 min-rx 2000 multiplier 3
echo
interface Tunnel1
bandwidth 10000
ip address 10.1.1.3 255.255.255.0
no ip redirects
ip mtu 1400
no ip nhrp record
load-interval 30
delay 100
nhrp group spokes
nhrp map group hub service-policy output to_hub
interface Tunnel1 ! (cont.)
bfd template DMVPN
tunnel key 1
tunnel vrf isp1
interface Tunnel2
bandwidth 10000
ip address 10.2.2.3 255.255.255.0
…
“ip nhrp shortcut”и “ip nhrp holdtime 600” – это значенияпо
умолчаниюв данной версииIOS-XE

• Пример для Spoke-3
router eigrp 100
!
redistribute bgp 65000 route-map bgp-eigrp
network 192.168.3.0 0.0.0.3
exit-address-family
!
redistribute bgp 65000 route-map bgp-eigrp
network 192.168.3.4 0.0.0.3
exit-address-family
ip prefix-list b-e seq 5 permit 192.168.0.0/22 le 23
route-map bgp-eigrp permit 10
match ip address prefix-list b-e
set metric 10000 100 255 1 1500
router bgp 65000
bgp router-id 192.168.3.3
bgp log-neighbor-changes
!
address-family ipv4 vrf isp1
redistribute eigrp 1 route-map eigrp-bgp
neighbor 10.1.1.1 remote-as 65000
neighbor 10.1.1.1 timers 20 60
neighbor 10.1.1.1 fall-over bfd
neighbor 10.1.1.1 activate
exit-address-family
!
address-family ipv4 vrf isp2
redistribute eigrp 1 route-map eigrp-bgp
neighbor 10.2.2.1 remote-as 65000
neighbor 10.2.2.1 timers 20 60
neighbor 10.2.2.1 fall-over bfd
neighbor 10.2.2.1 activate
exit-address-family
ip prefix-list e-b seq 5 permit 192.168.3.0/24 ge 25
route-map eigrp-bgp permit 10
match ip address prefix-list e-b

• Что получилось на Hub
Hub-1#show bfd neighbors
IPv4 Sessions
NeighAddr LD/RD RH/RS State Int
10.1.1.2 4099/0 Down Down Tu1
10.1.1.3 4098/4098 Up Up Tu1
10.2.2.2 4100/0 Down Down Tu2
10.2.2.3 4097/4097 Up Up Tu2
Hub-1#show bfd neighbors ipv4 10.1.1.3 details
IPv4 Sessions
NeighAddr LD/RD RH/RS State Int
10.1.1.3 4098/4098 Up Up Tu1
Session state is UP and using echo function with 2000 ms interval.
Session Host: Software
OurAddr: 10.1.1.1
Handle: 2
Local Diag: 0, Demand mode: 0, Poll bit: 0
MinTxInt: 1000000, MinRxInt: 1000000, Multiplier: 3
Received MinRxInt: 1000000, Received Multiplier: 3
Holddown (hits): 0(0), Hello (hits): 1000(1158)
Rx Count: 1155, Rx Interval (ms) min/max/avg: 1/1003/875 last: 359 ms ago
Tx Count: 1160, Tx Interval (ms) min/max/avg: 1/1001/872 last: 555 ms ago
Elapsed time watermarks: 0 0 (last: 0)
Registered protocols: NHRP CEF BGP
Template: DMVPN
Uptime: 00:16:51
IOS на Spoke-2 не поддерживаетBFD. Поддержка
будетреализованав одной изследующих версийIOS

• Что получилось на Hub (IOS на Spoke-2 не поддерживает BFD)
Hub-1#show dmvpn
…
----- --------------- --------------- ----- -------- -----
1 2.2.29.2 10.1.1.2 BFD 14:21:36 D
1 3.3.39.3 10.1.1.3 UP 00:19:54 D
----- --------------- --------------- ----- -------- -----
1 22.22.29.2 10.2.2.2 BFD 14:21:29 D
1 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.2
Type: dynamic, Flags: registered nhop bfd
Group: 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:
csc-russian@external.cisco.com

#CiscoConnectRu#CiscoConnectRu
Спасибо за внимание!
Оцените данную сессию в мобильном приложении конференции
© 2017 Cisco and/or its affiliates. All rights reserved.
Контакты:
Тел.: +7 495 9611410
www.cisco.com
www.facebook.com/CiscoRu
www.vk.com/cisco
www.instagram.com/ciscoru
www.youtube.com/user/CiscoRussiaMedia

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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Как настроить DMVPN и избежать проблем

Similar to Как настроить DMVPN и избежать проблем (20)

More from Cisco Russia

More from Cisco Russia (20)

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