Blog CCIE

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