Introduction au DMVPN

On 14 octobre 2014 by Benoit With 2 Comments - CCIE, Protocoles

C’est l’une des grandes nouveautés du CCIE v5, le DMVPN (pour Dynamic Multipoint VPN) remplace la partie Frame-Relay, donc voici quelques notes personnelles prises en regardant les vidéos INE, et en synthétisant un peu le contenu.

DMVPN – Qu’est-ce que c’est?

D’un point de vue High-level, il s’agit de “Point to Multipoint overlay VPN Tunneling” ou Overlay veut dire que le DMVPN fonctionne au dessus d’autres protocoles (GRE / IPsec).
D’un point de vue Low-level, il s’agit de tunnels GRE over IPsec site-to-site tunnels – Gérables dynamiquement et évolutifs.

High-level design & operations
– Les sites distants (spokes) montent des tunnels statiques vers un central (Hub & spoke).
– Les Spokes échangent des informations de routage avec les hub au travers du tunnel statique (EIGRP, OSPF, RIP…).
– Le trafic Spoke to hub est routé directement dans le tunnel statique.
– Le trafic Spoke to Spoke est routé dynamiquement avec des tunnels à la demande.

Pourquoi le DMVPN ?

La gestion de la configuration est simple (les spokes utilisent un template standard) et celà facilite le provisioning (Aucune configuration supplémentaire sur le Hub quand on ajoute d’autres spokes).
Le DMVPN supporte le transport de nombreux protocoles (IPv4, v6, unicast, multicast, static & dynamic routing) et utilise n’importe quel transport IP (DSL, Cable, Différents ISPs..). Il fonctionne aussi au travers du NAT.

DMVPN vs Others

IPsec statique
L’IPsec statique est difficile à faire évoluer d’un point de vue “management”, ajouter des nouveaux sites requière beaucoup de configuration. Ce type de VPN ne supporte pas le routage dynamique ou le Multicast (de base).
MPLS L3 VPN
Ajoute une complexité de routage supplémentaire, ils ne supportent pas forcément IPv6 or IPv4/v6 Multicast.
L’Interopérabilité avec les fournisseurs d’accès pour le MPLS L3VPN est difficile à mettre en place, et besoin de circuits séparés pour l’accès internet.

Fonctionnement du DMVPN

Il s’agit d’un réseau Full mesh de tunnels IPsec à la demande, avec un minimum de configuration grâce aux protocoles suivants :
– Multipoint GRE Tunnels (mGRE)
– NHRP (Permet au Hub de retrouver les adresses IP des Hub dynamiquement).
– IPsec crypto profiles (Encryption).
– Routage (underlay/overlay)

La technologie DMVPN réduit le besoin de configurer un full mesh (n*(n-1)/2) de tunnels statiques, ici nous n’avons qu’un seul tunnel mGRE sur le Hub pour tous. Les tunnels sont ensuite montés à la demande entre les différents nœuds, selon le trafic, entre les spokes. Le chiffrement via IPsec est optionnel.

Voici le schéma que nous utiliseront en exemple dans cet article:

Deux IGP sont requis:
Underlying: Pour la connectivité IP publique et monter les tunnels GRE.
Overlay: Pour s’échanger des routes privées une fois le tunnel monté.

Ici les adresses IP Underlay, dans un réseau directement connecté, mais qui pourrait très bien être un réseau publique internet, en IPv4 ou en IPv6 car les deux protocoles sont supportés. Ce sont des IP “Publiques”.
dmvpn-archi-underlay

Ici les adresses IP Overlay, qui sont en fait les adresses IP que l’on donne aux tunnels GRE. Ce sont des IP Privées.
dmvpn-archi-overlay

Fonctionnement – Hub to spoke
2 composants:
– DMVPN Hub / NHRP Servers (NHS).
– DMVPN Spokes / NHRP Clients (NHC).

Les Spokes (Clients) s’enregistrent avec le Hub (Serveur).
– Ils spécifient manuellement l’adresse du Hub dans le Tunnel GRE (tunnel destination…).
– Ils envoient cela via le NHRP Registration Request
– Les Hub apprennent dynamiquement les adresses VPN (Privées) et adresses NBMA (Publiques).
Les Spokes établissent les tunnels vers les Hub, puis ils échangent ensuite les infos de routage IGP au travers du Tunnel.

Fonctionnement – Spoke to Spoke
Le Spoke 1 connait les routes du Spoke 2 via un IGP.
– Les routes sont connues via le tunnel vers le hub.
– Le Next-hop est l’adresse VPN du Spoke 2 pour le DMVPN Phase 2.
– Le Next-hop est l’adresse VPN du Hub pour le DMVPN Phase 3.

Le Spoke 1 demande l’adresse IP réelle du Spoke 2
– Il mappe l’IP du next-hop (VPN) à l’IP source du tunnel (NBMA).
– Adresse demandée via le NHRP resolution request

Le Spoke to Spoke tunnel est enfin formé
– Le Hub effectue le control-plane seulement.
– Le Spoke to spoke data plane peut aussi passer par le hub dans certains cas, mais la plupart du temps, les data ne passent plus par le Hub pour le trafic Spoke to Spoke.

NHRP Important messages

1- NHRP Registration Request
– Les Spokes enregistrent leurs IP NBMA et VPN au NHS (Hub)
– Requis pour construire le spoke-to-hub tunnels
2- NHRP Resolution REquest
– Les Spokes demandent les mappings NBMA-to-VPN des autres spokes
– Requis pour construire les spoke-to-spokes tunnels
3- NHRP Redirect
– NHS (hub) répond à un spoke-to-spoke data plane packet via ce message.
– Similaire aux IP redirect
– Utilisé seulement en phase 3 pour construire les spoke-to-spoke tunnels.

DMVPN Basic Configuration

Emplacement dans le DOC CD: Cisco.com > Support > Products > IOS 15.3(1)T > Config Guide > Security, Services, and VPN > Secure Connectivity > Dynamic Multipoint VPN Configuration Guide.

Voici la topologie utilisée pour cet exemple:
dmvpn-archi

Hub Config
Le routeur R5 fait office de Hub pour cette architecture.
Voici la configuration la plus basique qu’il est nécessaire de mettre en place pour configurer un Hub DMVPN.

interface Tunnel0
 ip address 10.1.0.5 255.255.255.0  // IP "overlay" / Privée du tunnel DMVPN.
 !
 ip nhrp authentication P@ssw0rd   // Authentification du NHRP
 ip nhrp map multicast dynamic     // Multipoint tunnel
 ip nhrp network-id 99            
 !
 tunnel source Ethernet0/1.100       // Source
 tunnel mode gre multipoint          // Tunnel GRE Multipoint
 tunnel key 10000                    // Clé du Tunnel GRE
end

L’interface e0/1.100 est configurée de la façon suivante, et fait office d’interface “Publique”. Dans cette architecture elle est directement connectée dans le même VLAN avec les interfaces des routeurs R1, R2 et R3, mais dans un scénario réel, cette interface pourrait être celle de votre routeur public avec une IP en “88.34.2.173” par exemple.

int e0/1.100
     ip add 169.254.100.5 255.255.255.0     // IP "underlay" ou Publique.
     encapsulation dot1Q 100
     no sh

Tests
Deux commandes les plus utiles pour vérifier rapidement le fonctionnement de notre configuration:
#show ip nhrp afin de voir les IP dynamiquement mappées sur le Hub (addresses NBMA et et VPN).
#show dmvpn afin de visualiser l’état des peers VPN

R5#sh ip nhrp
10.1.0.1/32 via 10.1.0.1
Tunnel0 created 00:22:37, expire 00:03:35
Type: dynamic, Flags: unique registered used nhop
NBMA address: 169.254.100.1
10.1.0.2/32 via 10.1.0.2
Tunnel0 created 00:01:21, expire 00:04:26
Type: dynamic, Flags: unique registered used nhop
NBMA address: 169.254.100.2
10.1.0.3/32 via 10.1.0.3
Tunnel0 created 00:05:01, expire 00:04:03
Type: dynamic, Flags: unique registered used nhop
NBMA address: 169.254.100.3
R5#sh dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
N - NATed, L - Local, X - No Socket
# Ent --> Number of NHRP entries with same NBMA peer
NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
UpDn Time --> Up or Down Time for a Tunnel
==========================================================================
 
Interface: Tunnel0, IPv4 NHRP Details
Type:Hub, NHRP Peers:4,
 
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 169.254.100.1       10.1.0.1        UP    00:21:56  D
1 169.254.100.2       10.1.0.2        UP    00:00:32  D
1 169.254.100.3       10.1.0.3        UP    00:01:55  D
1 169.254.100.4       10.1.0.4        UP    00:01:00  D

Spokes Config
La configuration la plus basique des spokes est la suivante. Pour chacun des Spoke, elle sera identique, excepté pour les IP publique et privée (dans notre exemple 169.254.100.5 et 10.1.0.1) qui seront elles uniques pour chaque site distant.

interface Tunnel0
 ip address 10.1.0.1 255.255.255.0   // IP Privée du Tunnel GRE
 !
 ip nhrp authentication P@ssw0rd     // Clé authentification NHRP
 ip nhrp map multicast 169.254.100.5 // Les paquets Multicast seront mappés au Tunnel GRE
 ip nhrp map 10.1.0.5 169.254.100.5  // ip nhrp map (private) (public)
 !                                   // Pour joindre 10.1.0.5, on passe par 169.254.100.5
 ip nhrp network-id 99
 ip nhrp nhs 10.1.0.5                // Next-hop server
 !
 tunnel source Ethernet0/1.100        // Source du Tunnel GRE
 tunnel destination 169.254.100.5     // Destination du Tunnel GRE
 !
 tunnel key 10000                     // Clé d'identification du Tunnel GRE
end

L’interface physique qui correspond à la sortie publique du Spoke:

int e0/1.100
 ip add 169.254.100.1 255.255.255.0                    // IP "underlay" ou Publique.
 encapsulation dot1Q 100
 no sh

Tests
Sur le Spoke, on voit bien l’IP privée (VPN) et publique (NBMA) dans le show ip nhrp, et dans le show dmvpn nous ne voyons que le tunnel monté avec le Hub. Les adresses IP des autres Spokes sont ensuite apprises via un protocole de routage IGP.

R1#sh ip nhrp
10.1.0.5/32 via 10.1.0.5
Tunnel0 created 00:06:50, never expire
Type: static, Flags:
NBMA address: 169.254.100.5
R1#sh dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
N - NATed, L - Local, X - No Socket
# Ent --> Number of NHRP entries with same NBMA peer
NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
UpDn Time --> Up or Down Time for a Tunnel
==========================================================================
 
Interface: Tunnel0, IPv4 NHRP Details
Type:Spoke, NHRP Peers:1,
 
# Ent Peer NBMA Addr  Peer Tunnel Add State UpDn     Tm Attrb
----- --------------- --------------- ----- -------- -----
1     169.254.100.5   10.1.0.5        UP     00:06:46 S

Routage Overlay

Pour que les spokes puissent connaitre les adresses réseaux présentes sur les autres Spokes, il va falloir rajouter la couche de routage IGP, ici avec du RIP.
Sur chacun des hub/spokes :

conf t
 router rip
  version 2
  net 10.1.0.0           // Addresses des Tunnels GRE 
  net 150.1.0.0          // Loopback des Routeurs
  no auto-summary

Et on n’oublie pas le “no ip split-horizon” sur le Hub pour que R1 puisse recevoir des Update RIP de R3 et vice-versa.

R5(config-if)#int Tunnel 0
R5(config-if)#no ip split-horizon

On vérifie que notre tunnel DMVPN est bien monté sur le Spoke:

R1(config)#do sh dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
        N - NATed, L - Local, X - No Socket
        # Ent --> Number of NHRP entries with same NBMA peer
        NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
        UpDn Time --> Up or Down Time for a Tunnel
==========================================================================
 
Interface: Tunnel0, IPv4 NHRP Details
Type:Spoke, NHRP Peers:1,
 
 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 169.254.100.5          10.1.0.5    UP 00:26:11     S

On vérifie nos routes RIP apprises sur le Spoke R1 :

R1(config-router)#do sh ip route rip
Gateway of last resort is not set
      150.1.0.0/32 is subnetted, 4 subnets
R        150.1.2.2 [120/2] via 10.1.0.2, 00:00:04, Tunnel0
R        150.1.3.3 [120/2] via 10.1.0.3, 00:00:04, Tunnel0
R        150.1.5.5 [120/1] via 10.1.0.5, 00:00:04, Tunnel0

Et on tente de joindre ces nouveaux réseaux:

R1(config-router)#do ping 150.1.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
R1(config-router)#do ping 150.1.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

On peut aussi voir en tapant à nouveau la commande show dmvpn que deux nouveaux tunnels sont apparus sur le Spoke. Il s’agit des tunnels Spoke-to-spoke qui sont montés dynamiquement (D) contrairement au tunnel vers 169.254.100.5 qui lui est Statique (S) et permanent.

R1(config)#do sh dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
        N - NATed, L - Local, X - No Socket
        # Ent --> Number of NHRP entries with same NBMA peer
        NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
        UpDn Time --> Up or Down Time for a Tunnel
==========================================================================
 
Interface: Tunnel0, IPv4 NHRP Details
Type:Spoke, NHRP Peers:3,
 
 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 169.254.100.2          10.1.0.2    UP 00:00:07     D
     1 169.254.100.3          10.1.0.3    UP 00:00:03     D
     1 169.254.100.5          10.1.0.5    UP 00:27:09     S

C’est tout pour la configuration basique du DMVPN. Dans la vrai vie, on préférera utiliser IPsec avec nos tunnels afin de chiffrer le trafic entre nos spokes et notre/nos hubs, ce sera pour un autre article.

Benoit

Network engineer at CNS Communications. CCIE #47705, focused on R&S, Data Center, SD-WAN & Automation.

More Posts - Website

Follow Me:
TwitterLinkedIn

, , , , ,

2 Comments

  1. reda 5 décembre 2018

    bnjou,
    j’aimerai bien savoir les limites de la DMVPN, en point de vue de nombre de spoke? un seul hub peut , combien peut gérer de spoke ?

  2. Balde Amadou 20 août 2021

    Je tiens à vous remerciez pour le partage de vos connaissances car c’est une bonne chose en plus j’en avais vraiment besoin car c’est le DMVPN que j’aimerais utiliser pour ma soutenance de l’année prochaine si Dieu le veux bien
    J’aimerais que vous me donniez des guide pour mon projet de soutenance

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *