Blog CCIE

« Ce qu'on obtient en atteignant nos objectifs n'est pas aussi important que ce que l'on devient en les atteignant. » - Zig Ziglar

DMVPN : les tunnels à la demande!

with 21 comments

Introduction

Bonjour à tous,

Après avoir changé de travail depuis maintenant 15 jours et rejoint la société Econocom, les missions qui me sont affectées me permettent de monter en compétence et de pratiquer sur une technologie Cisco que je ne connaissais que de nom, DMVPN!

A l’époque où j’avais préparé la CCNA Security, je me souviens en avoir entendu parler mais rien de bien concret. Le scope à l’époque restait tout de même très concentré sur les VPNs IPsec site-à-site ou accès distant.

Je vous propose de commencer par un peu de théorie avant d’aborder la question de l’implémentation en elle-même.

DMVPN c’est quoi?

Dynamic Multipoint VPN. Rien que l’acronyme est accrocheur!

Il s’agit d’un mécanisme qui vous permet d’établir les tunnels IPsec+GRE directement entre les routeurs qui veulent dialoguer ensemble avec une simplicité et une scalabilité déconcertante et surtout de façon totalement dynamique!

Il utilise un mécanisme Hub & Spoke où un routeur est défini comme jouant le rôle d’hub. Le reste des routeurs opèrent en mode spoke.

On peut facilement imaginer comment un spoke peut contacter un autre spoke directement sans passer obligatoirement par un hub et comment par ce biais, rediriger tout le data plane de la session. L’utilisation de la bande passante peut-être donc optimisée et conservée pour ne pas saturer les liens du hub par exemple.

Par exemple, une fois le routeur hub configuré, vous pourrez implémenter une configuration quasi-générique sur les spokes sans changer la configuration du hub!

Un composant est crucial dans le mécanisme, NHRP ou Next-Hop Resolution Protocol.

Vous verrez pourquoi quand je parlerais plus en détail de la procédure d’établissement des tunnels.

Mécanisme d’établissement

Pour comprendre au mieux à quoi sert NHRP et le reste, prenons un exemple concret avec une topologie example qui nous servira également pour l’implémentation.

La partie colorée en rose, même si elle utilise un adressage privé représente la partie publique des routeurs. Vous voyez que chaque routeur possède de façon classique son propre LAN.

Imaginez qu’un PC dans le LAN de R3 décide de vouloir envoyer un paquet à un membre du LAN de R2 par exemple. Le routeur R3 possède effectivement une route vers ce subnet mais pas directement. En réalité, la route locale est accessible via un tunnel comme vous pouvez le voir :

R3#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2
 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
 ia - IS-IS inter area, * - candidate default, U - per-user static route
 o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
172.16.0.0/24 is subnetted, 1 subnets
C 172.16.1.0 is directly connected, FastEthernet0/0
 10.0.0.0/24 is subnetted, 1 subnets
C 10.0.0.0 is directly connected, Tunnel0
D 192.168.1.0/24 [90/297372416] via 10.0.0.1, 00:01:13, Tunnel0
D 192.168.2.0/24 [90/310172416] via 10.0.0.2, 00:01:14, Tunnel0
C 192.168.3.0/24 is directly connected, Loopback0
R3#

L’intêret? Il se trouve dans la nécéssité de pouvoir résoudre dynamiquement l’IP publique à laquelle R3 devra faire appel pour former un tunnel lui aussi dynamique, ce qui est effectué par le biais de NHRP. Les étapes sont assez simples :

  1. R3 regarde dans la table NHRP locale si il possède déja l’adresse IP publique qui correspond à l’adresse de tunnel virtuel entre le hub et le spoke. En l’occurence, R3 regardera si il a une correspondance entre 10.0.0.2 sur l’adresse publique de R2 qui est 172.16.1.2.
  2. Si R3 ne trouve pas de correspondance dans sa table NHRP locale, il va tout simplement envoyer une requête NHRP au hub pour lui demander « Quelle est l’adresse IP publique qui correspond à cette adresse de tunnel virtuel? ». R1, le hub, ayant en permanence un circuit virtuel associé avec tous les spokes connait cette réponse et va donc répondre à R3, 172.16.1.2.
  3. Une fois que R3 à cette adresse publique, il peut maintenant directement négocier un tunnel dynamique avec R2 sans passer par R1. Notez qu’une fois le processus terminé localement sur R3, elle n’est pour le moment qu’à sens unique. Pour la rendre bi-directionelle, il suffit que l’hôte contacté dans le LAN de R2 envoie une réponse pour déclencher de la part de R2, le processus de résolution et d’établissement, contenant les mêmes étapes que celles décrites précédemment.

La force de ce genre de mécanisme est d’établir des tunnels de façon totalement dynamique et temporaire. Si au bout d’un certain temps, plus aucun traffic ne transite plus via ce tunnel temporaire, il sera déconnecté et renégocié au besoin.

Assez parlé de théorie, passons désormais à la pratique!

Implémentation type

Comme d’habitude, on se servira de la topologie décrite plus haut en découpant en étapes l’implémentation.

Quelques petites précisions avant de commencer :
– La partie rose du schéma représente comme précisé plus haut la partie publique
– Les LANs sont émulés sur les routeurs avec l’aide d’interfaces de Loopback.

Configuration du hub R1

Premier point, on configure l’interface publique ainsi que cette de loopback pour émuler le LAN.

int FastEthernet0/0
description Interface WAN
ip add 172.16.1.1 255.255.255.0
no sh
!
int Loopback0
description Interface LAN
ip add 192.168.1.254 255.255.255.0

Une fois ces paramètres basiques configurés, on peut passer à la configuration de l’interface Tunnel0 pour le NHRP.

interface Tunnel0
 ! Adresse IP du tunnel
 ip address 10.0.0.1 255.255.255.0
 ! Configuration du NHRP
 ip nhrp map multicast dynamic
 ip nhrp network-id 1
 ! Configuration du tunnel GRE
 tunnel source 172.16.1.1
 tunnel mode gre multipoint
!

Une fois cette configuration effectuée, on passe à la configuration des spokes.

Configuration du spoke R2

Comme pour la configuration du hub, on s’occupe de l’adressage et de la configuration du tunnel.

interface FastEthernet0/0
 description Interface WAN
 ip address 172.16.1.2 255.255.255.0
 duplex auto
 speed auto
!
interface Loopback0
 description Interface LAN
 ip address 192.168.2.254 255.255.255.0
!
interface Tunnel0
 ip address 10.0.0.2 255.255.255.0
 ! On mappe de façon manuelle en NHRP l'adresse publique du hub 
 ! pour l'établissement du tunnel permanent entre le spoke et le hub.
 ip nhrp map 10.0.0.1 172.16.1.1
 ip nhrp map multicast 172.16.1.1
 ip nhrp network-id 1
 ! On identifie l'agent résolveur NHRP qui sera le hub R1.
 ip nhrp nhs 10.0.0.1
 ! Configuration du tunnel GRE
 tunnel source 172.16.1.2
 tunnel mode gre multipoint

Abordons enfin la configuration du dernier spoke, R3.

Configuration du spoke R3

Voici la configuration pour le spoke R3.

interface FastEthernet0/0
 description Interface WAN
 ip address 172.16.1.3 255.255.255.0
 duplex auto
 speed auto
!
interface Loopback0
 description Interface LAN
 ip address 192.168.3.254 255.255.255.0
!
interface Tunnel0
 ip address 10.0.0.3 255.255.255.0
 ! On mappe de façon manuelle en NHRP l'adresse publique du hub 
 ! pour l'établissement du tunnel permanent entre le spoke et le hub.
 ip nhrp map 10.0.0.1 172.16.1.1
 ip nhrp map multicast 172.16.1.1
 ip nhrp network-id 1
 ! On identifie l'agent résolveur NHRP qui sera le hub R1.
 ip nhrp nhs 10.0.0.1
 ! Configuration du tunnel GRE
 tunnel source 172.16.1.3
 tunnel mode gre multipoint

Vous remarquerez à quel point, excepté pour l’adressage, la configuration est similaire. Cela vous montre à quel point un nouveau spoke venant s’intégrer à votre topologie DMVPN existante peut-être facilement intégré.

Avant de pouvoir tester notre installation, il nous manque encore un élément, le protocole de routage. J’ai choisi ici, comme à mon habitude EIGRP.

Configuration d’EIGRP

Vous pouvez penser que la configuration sera aisée pour EIGRP, oui et non. Vous allez voir pourquoi.

EIGRP doit pouvoir nous aider à propager les routes des subnets respectifs de LAN de chaque routeur et de les partager à travers le tunnel virtuel. Néanmoins, EIGRP a besoin d’être paramétré d’une façon spécifique.

La configuration qui suit s’applique encore une fois de façon similaire sur l’ensemble des routeurs(hub et spokes).

router eigrp 1
! Activation et partage EIGRP dans le tunnel
network 10.0.0.0
! Activation et partage EIGRP pour le LAN
network 192.168.1.0
!
int Tunnel0
! On désactive le mécanisme Split-Horizon
no ip split-horizon eigrp 1
! On demande à EIGRP de ne pas réecrire l'adresse de next-hop avec celle du
! routeur qui annonce puisque que cela sert directement pour l'établissement
! de lien dynamique avec l'aide d'NHRP.
no ip next-hop-self eigrp 1

Pour rappel, le mécanisme de split-horizon empêche un routeur qui a reçu une annonce sur une interface donnée de la diffuser à nouveau sur la même interface. C’est un mécanisme connu et hérité des protocoles de routage à vecteurs de distances pour éviter les boucles de routage. Souvenez-vous de l’anecdote sur les rumeurs qui vous permet de bien assimiler ce concept:

Si un voisin vous raconte une rumeur, vous n’allez probablement pas lui répéter à nouveau celle-ci, vu qu’il l’a connait déjà.

Une fois toute cette configuration effectuée, on va pouvoir tester tout cela!

Premiers tests

Pour tester le bon fonctionnement de ce mécanisme, on va tout simplement lancer un ping du LAN de R2 au LAN de R3.

Juste avant, remarquez l’output de la commande show dmvpn:

R2#sh dmvpn
*Oct 17 15:46:29.895: %SYS-5-CONFIG_I: Configured from console by consolen
Legend: Attrb --> S - Static, D - Dynamic, I - Incompletea
 N - NATed, L - Local, X - No Socket
 # Ent --> Number of NHRP entries with same NBMA peer
Tunnel0, Type:Spoke, NHRP Peers:1,
 # Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
 1 172.16.1.1 10.0.0.1 UP 01:38:07 S

R2 nous signale que le tunnel permanent NHRP est établi entre le hub R1 et le spoke R2. C’est déjà bon signe. La même commande exécutée sur R3 nous donnerait un résultat similaire.

Notez également que grâce à ce tunnel, R2 a appris par le biais d’EIGRP une route vers le subnet LAN de R3 comme le montre les lignes suivantes :

R2#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
 D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
 N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
 E1 - OSPF external type 1, E2 - OSPF external type 2
 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
 ia - IS-IS inter area, * - candidate default, U - per-user static route
 o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
172.16.0.0/24 is subnetted, 1 subnets
C 172.16.1.0 is directly connected, FastEthernet0/0
 10.0.0.0/24 is subnetted, 1 subnets
C 10.0.0.0 is directly connected, Tunnel0
D 192.168.1.0/24 [90/297372416] via 10.0.0.1, 00:05:56, Tunnel0
C 192.168.2.0/24 is directly connected, Loopback0
D 192.168.3.0/24 [90/310172416] via 10.0.0.3, 00:05:56, Tunnel0

On voit bien ici que R2 connait le chemin pour envoyer des informations au LAN de R3 via l’interface Tunnel0 et l’adresse 10.0.0.3. NHRP fera ensuite le reste.

Essayons maintenant de pinger et de déclencher la résolution NHRP et le tunnel dynamique.

R2#ping 192.168.3.254 source lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.3.254, timeout is 2 s
conds:
Packet sent with a source address of 192.168.2.254
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 84/
09/132 ms
R2#

On voit que ça ping sans aucun problème! Ré-exécutons maintenant la commande sh dmvpn:

R2#sh dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incompletea
 N - NATed, L - Local, X - No Socket
 # Ent --> Number of NHRP entries with same NBMA peer
Tunnel0, Type:Spoke, NHRP Peers:2,
 # Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
 1 172.16.1.1 10.0.0.1 UP 01:43:51 S
 1 172.16.1.3 10.0.0.3 UP never D

Vous voyez maintenant qu’un tunnel dynamique(désigné par D dans la colonne Attrb) a été établi directement pour faire passer le traffic directement de R2 à R3.
Cela nous confirme que la relation est bien directe entre les équipements et qu’excepté la résolution NHRP, le hub n’est pas utilisé dans le transfert de données, autrement dit le data plane, entre R2 et R3.

Avant de terminer cet article, abordons un dernier point crucial!

Et la sécurité dans tout ça?

Vous avez surement remarqué pour le moment que nous n’avons implémenté aucun mécanisme de sécurité. A proprement parler, nous avons uniquement réalisé pour le moment juste le côté GRE et pas IPsec de l’implémentation.

Vous allez voir néanmoins que la surcharge de configuration est classique, légère et similaire à appliquer à la fois sur le hub et les spokes.

! Création de la policy ISAKMP
crypto isakmp policy 10
authentication pre-share
!
! Configuration de la clé ISAKMP
crypto isakmp key Cisc0p@ss address 172.16.0.0 255.255.0.0
!
! Configuration du transform set IPsec
crypto ipsec transform-set DMVPN_TSET esp-aes esp-sha-hmac
!
! Configuration du profile IPSEC
crypto ipsec profile DMVPN_PROF
 set transform-set DMVPN_TSET
!
int Tunnel0
! Affectation du profile dans le tunnel.
tunnel protection ipsec profile DMVPN_PROF

Une fois cette configuration répliquée sur le hub et les spokes, vous serez capable de pouvoir faire du DMVPN avec IPsec et GRE combinés.

Pour pouvoir vérifier, on relance un ping de R2 à R3:

R2#ping 192.168.3.254 source lo0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.3.254, timeout is 2 seconds:
Packet sent with a source address of 192.168.2.254
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 88/100/116 ms
R2#

Le ping fonctionne, vérifions ce qui se passe au niveau ISAKMP et IPsec:

R2#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst src state conn-id slot status
172.16.1.1 172.16.1.2 QM_IDLE 1001 0 ACTIVE
172.16.1.3 172.16.1.2 QM_IDLE 1002 0 ACTIVE

On voit directement ici que nous avons deux connections IPsec actives à présent,celle concernant le tunnel permanent entre le hub et le router(1001) qui s’est renégociée à l’activation de nos nouveaux paramètres IPsec et le tunnel dynamique établi dynamiquement(1002) qui s’est également renégocié étant déja lui aussi établi lors de nos tests.

Comme d’habitude pour les curieux, je vous laisse à disposition les fichiers de configuration dans une archive.

N’hésitez pas à commenter l’article pour y apporter vos réflexions et vos suggestions d’améliorations.

Sources :

http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6635/ps6658/prod_presentation0900aecd80313c97.pdf

http://packetlife.net/blog/2008/jul/23/dynamic-multipoint-vpn-dmvpn/

— Julien

Written by Julien BERTON

octobre 17th, 2012 at 6:30 pm

Posted in Lab. time,Theory

Tagged with , ,

21 Responses to 'DMVPN : les tunnels à la demande!'

Subscribe to comments with RSS or TrackBack to 'DMVPN : les tunnels à la demande!'.

  1. encore une fois, je suis agréablement supris par la compréhension de tes articles. Merci pour ce partage de connaissance….et bravo pour ton écrie CCIE

    Buzzy

    23 Oct 12 at 17 h 38 min

  2. Merci pour tes compliments! Si cela peut servir au plus grand nombre, j’en suis heureux. Cette démarche me permet aussi de tester ma propre compréhension des technos et de me forcer à comprendre tout ce dont je parle. Et puis, ça me permet de tester un peu mes méthodes et ma pédagogie.

    Julien BERTON

    29 Oct 12 at 23 h 23 min

  3. Salut Julien
    as-tu testé avec RIP V2, ce protocole est économique en terme de CPU et doit pouvoir remplacer cette vieille carne d’EIGRP.

    🙂

    TonTon MaZ

    5 Nov 12 at 12 h 42 min

  4. Bonjour Vincent,

    Non, pas testé avec RIPv2 en déploiement concret.
    Maintenant, RIPv2 reste un IGP qui ressemble à EIGRP et qui fait lui aussi du multicast pour les adjacences, ça pourrait fonctionner, sous réserve de peut-être 2-3 changements dans la conf.

    En tout cas, si tu y arrives, tiens-moi au courant, c’est toujours bon à savoir 🙂

    Julien

  5. hello je suis tombe sur ton blogue par un heureux hasard , que je remercie d’ailleurs 🙂 , et en une semaine j’ai presque tout lu bref c’etait devenu mon livre de chevet 😉 ! merci de partager
    PS: tu intervertis juste les description des interfaces mais ca marche super bien !

    moi je trouve eigrp tres bien ,je le prefere a ripv2 car il offre des option de ouf en terme customisation !!

    chris

    14 Fév 13 at 1 h 08 min

  6. merci bien Julien pour cette formidable explication de technologie dmvpn . bn pour l’instant je suis au sein d’une entreprise pour une période de stage, j’ai choisi comme sujet de stage la technologie dmvpn . tu m’a bcp aidé pour bien comprendre le thème.
    c zahidi (maroc)

    mohammed zahidi

    28 Fév 14 at 12 h 06 min

  7. Merci pour ce tutoriel qui m’est très utile et qui me permet de comprendre le concept de DMVPN. j’ai néanmoins 2 questions à poser.
    A supposer qu’entre R1 et R3 il existe déjà un tunnel GREoIPSEC classique, et que je veux faire communiquer R2 et R1 (par exemple), sans fermer le tunnel entre R1 et R3;
    1- est ce que le DMVP s’applique?
    2- si oui est ce qu’il faut supprimer les config du tunnel entre R1 et R3?
    3- Ou bien comment procéder?

    En espérant que le blog ne soit pas encore fermé, j’attends impatiemment une réponse.

    Merci d’avance!!

    Priscille

    24 Avr 14 at 12 h 52 min

  8. Priscille,

    Si un tunnel GREoIPSEC existe déjà, il ne vaut mieux pas y toucher. Comme tu le sais, par défaut, les tunnels GRE sont de nature Point-to-Point. En DMVPN, nous faisons essentiellement du GRE mais multipoint pour utiliser les avantages de cette technologie.

    A moins que tu configure un nouveau tunnel GRE pour DMVPN en gardant l’autre et en faisant ce qu’il faut au niveau du routage 😉

    Julien BERTON

    27 Avr 14 at 2 h 27 min

  9. Bonjour,
    je tiens à vous remercier d’avance, c’est vraiment compréhensif.J’ai un projet à faire là dessus et je pense que votre « cours » m’aidera beaucoup. Mais mon problème est que je ne vois pas ou es ce que vous avez mentionné le réseau 10.0.0.0, 10.0.0.1 et 10.0.0.2. Merci de m’éclairer

    Diatou

    14 Mai 14 at 13 h 09 min

  10. Merci Julien, vraiment super Tuto !

    Elaouni

    16 Mai 14 at 12 h 22 min

  11. Mais vous avez configuré sur quelle IOS? Quel est l’IOS minimum nécessaire? Parce que je fais une simulation sur GNS3 mais j’arrive pas à utiliser la commande SHOW DMVPN.

    Diatou

    25 Mai 14 at 0 h 50 min

  12. Merci bcp!!!
    très jolie tuto!!!

    Merlin

    3 Juil 14 at 17 h 41 min

  13. Bonjour Julien,

    je découvre dmvpn avec toi et cela me passionne déjà.
    est ce qu’on peut déployer sur des sites éloignes avec des adresses publiques?
    Nous avons trois sites avec des adresses publiques suivantes:
    site 1 : 213.136.107.28
    site 2 : 154.68.48.151
    site 3 : 74.132.52.21
    et nous avons mis en place un vpn site to site.
    je voudrai le remplacer par le dmvpn.
    comment dois mis prendre pour le routage?

    Bosco

    23 Oct 14 at 18 h 08 min

  14. Bonjour Julien,

    Pourrais-tu nous préciser quels ont été les modèles d’équipements que tu as utilisé, ainsi que les versions d’IOS, s’il te plaît ?

    As-tu une liste des équipements compatibles ?

    Merci par avance :).

    Alexandre F.

    24 Déc 14 at 15 h 22 min

  15. Re-Bonjour,

    Je fais suite à mon précédent commentaire.

    Si tu as une liste des équipements compatibles, je suis preneur.
    Néanmoins, petit retour d’information :

    – A mon premier essai, j’ai tenté avec des 2691, et l’image « c2691-advipservicesk9-mz.123-24 ». Le routeur ne connaissait pas DMVPN.

    – En regardant les fichiers de config que tu nous as transmis, j’ai pu voir que tu utilisais des version 12.4. Je viens d’appliquer ton Tuto sur des 7200, avec une licence « c7200-advipservicesk9_li-mz.124-15.T14 ». Tout fonctionne parfaitement !

    Merci pour cet article :).

    Alexandre F.

    24 Déc 14 at 16 h 09 min

  16. Hello,

    Heureux de voir que ça a fonctionné pour toi 🙂

    Effectivement, les 26XX n’ont pas grand chose, en termes de fonctionalités…et comme nous n’avons pas les 28XX dans GNS3 non plus, le mieux est soit de partir sur des 7200 mais la stabilité aussi me posait soucis à l’époque. Ma meilleure expérience reste sur les 3825/3845 en 12.4T ADV Enterprises Services.

    Bonnes fêtes

    Julien BERTON

    24 Déc 14 at 23 h 51 min

  17. Merci pour ton retour d’information, j’en prends note.

    Meilleurs Voeux :).

    Alexandre F.

    2 Jan 15 at 17 h 13 min

  18. Bonjour Julien,

    Merci pour ce tuto et juste une question. comment faire si on ne veut pas la communication Spoke to Spoke?

    ADOUM

    3 Fév 15 at 11 h 51 min

  19. Bonjour Julien,

    Merci pour cette demonstraction facile de DMVPN, j’ai commencé dans IT par defaut, je suis géologue de formation. L’IT me passione depuis 2013 ou j’ai fais mes premiers pas avec Fujistu comme Helpdesk. je m’abonne dès a présent sur ton site. Ma force, je lis beaucoup et fait les pratiques avec packet tracer 6. Vous expliquez très facilement dans votre site. Surout Split- Horizon.

    chassepjoel@yahoo.fr

    5 Avr 16 at 10 h 58 min

  20. salut IT
    suis un étudiant congolais en réseaux et je travaille sur le DMVPN comme sujet de mémoir, mais suis en manque de documentation votre aide me sera utile

    lofete

    18 Mar 17 at 18 h 52 min

  21. bonjour julien

    merci pour la démonstration mais g sais vois pas la configuration du cloud sur vos paramétré ;ou comment on configure internet je veux dire ??

    merci

    willy

    11 Juin 17 at 8 h 23 min

Leave a Reply