DMVPN Phase 1,2 et 3

DMVPN peut être déployé en 3 différentes phases (Elle correspondent plus particulièrement aux phases NHRP, et n’ont rien à voir avec les phases 1 et 2 de l’IPsec). En DMVPN, le tunnel mGRE utilise NHRP pour mapper l’adresse IP du tunnel (privée) à l’adresse IP physique NBMA (publique).

Les effets des ces différentes phases NHRP sont multiples:
– Le comportement du trafic entre les Spokes est différent pour chacune des phases.
– Les design de routages supportés par les différentes phases ne sont pas les mêmes.
– L’évolutivité du réseau est impactée par ces différentes phases.

DMVPN Phase 1 (Aujourd’hui obsolète)

Hub & Spoke (un Hub mGRE, et les Spokes en P2P GRE).

Les Spokes peuvent seulement joindre le Hub, et seulement joindre les autres Spokes via le Hub. La configuration du Hub est ici simplifiée, car il n’a pas besoin de mapper le NHRP pour chacun des nouveaux Spokes.
Cette phase n’utilise pas les tunnels Spoke-to-spokes. Les Spokes sont configurés pour du point-to-point GRE vers le Hub et enregistrent leurs IP logiques (Tunnel0) avec l’adresse NBMA (E0/1.100) sur le NHS (Hub) afin qu’il sache les joindre dynamiquement.
Le protocole de routage envoi un minimum d’informations depuis le Hub vers les Spokes (Route par défaut).
Les Spokes annoncent leurs réseaux (directement connectés) au Hub.

Le Hub à donc simplement besoin d’envoyer une route par défaut aux Spokes, étant donnée que le trafic doit forcément remonter au Hub.

Pour ce qui est des best-practices pour le routage Overlay dans cette phase:
– Avec EIGRP, il suffit de summarizer tous les subnets en 0.0.0.0/0 et les envoyer aux Hub, et configurer les Spokes en tant que Stubs et annoncer leurs réseaux locaux. Sans oublier de désactiver le split-horizon sur le Hub.
– Avec RIP, même fonctionnement, les Tunnel0 des spokes peuvent être configurés en passive-interface.
– Avec OSPF, le choix optimal serait de configurer les interfaces Tunnel0 en mode P2M + ip ospf database filter-all out sur le Hub et envoi d’une route statique aux Spokes.

Exemple de configuration
R5 (Hub)

router eigrp 123
 no auto-summary
 network 155.1.0.0 0.0.255.255
 network 150.1.0.0 0.0.255.255
!
! Tunnel source
!
interface E0/1.100
 ip address 169.254.100.5 255.255.255.0
!
! VPN network
!
interface Loopback 0
 ip address 155.1.5.5 255.255.255.255
!
! mGRE tunnel
!
interface Tunnel0
 ip address 150.1.0.5 255.255.255.0
 no ip redirects
 ip nhrp authentication cisco     
 ip nhrp map multicast dynamic                     
 ip nhrp network-id 123      
 no ip split-horizon eigrp 123                    // Desactivation du split-horizon
 ip summary-address eigrp 123 0.0.0.0 0.0.0.0 5   // Envoi une default-route aux Spokes
 tunnel source E0/1.100
 tunnel mode gre multipoint             // Seul le Hub utilise du mGRE
 tunnel key 123                         // Clé obligatoire

R1 (Spoke)

router eigrp 123
 no auto-summary
 network 155.1.0.0 0.0.255.255
 network 150.1.0.0 0.0.255.255
 eigrp stub connected
!
interface E0/1.100
 ip address 169.254.100.1 255.255.255.0
!
interface Loopback 0
 ip address 155.1.1.1 255.255.255.0
!
! GRE tunnel
!
interface Tunnel0
 ip address 150.1.0.1 255.255.255.0
 ip nhrp authentication cisco
 ip nhrp map multicast 169.254.100.5
 ip nhrp map 150.1.0.5 169.254.100.5    // map [locical] [NBMA] - Mapping statique.
 ip nhrp nhs 150.1.0.5                  // Configuration du serveur NHRP.
 ip nhrp network-id 123
 ip nhrp registration timeout 30
 tunnel source E0/1.100
 tunnel destination 169.254.100.5        // C'est cette commande qui fait que nous sommes en Phase 1
 tunnel key 123

Pour les désavantages du NHRP Phase 1, l’impossibilité d’établir des tunnels Spoke-to-spokes “shortcut” (on verra le détail de ce type de tunnels plus loin dans l’article). La Phase 2 résous ce problème et permet les tunnels Spoke-to-spokes.

Pour mieux comprendre la Phase 2, il faut comprendre comment NHRP interagis avec CEF (Cisco Express Forwarding).

DMVPN Phase 2 (obsolète aussi)

Hub & Spoke avec des tunnels Spoke-to-spoke.

Cette phase permet donc d’avoir des tunnels dynamiques Spoke-to-spoke. Tous les routeurs sont configurés avec des tunnels mGRE, et les Spokes ont le hub NHS configuré en statique. Quand un spoke à besoin d’envoyer un paquet via un Next-Hop sur le cloud mGRE, il envoi un paquet NHRP Resolution Request au Hub/NHS. Le Hub lui réponds avec un paquet NHRP Resolution Reply depuis son cache et le Spoke peut alors connaitre l’adresse NBMA d’un autre Spoke et le contacter directement.

Configuration de la Phase 2
R5 (Hub)

router eigrp 123
 no auto-summary
 network 150.1.0.0 0.0.255.255
 network 155.1.0.0 0.0.255.255
!
interface E0/1.100
 ip address 169.254.100.5 255.255.255.0
!
interface Loopback 0
 ip address 155.1.5.5 255.255.255.0
!
interface Tunnel0
 ip address 150.1.0.5 255.255.255.0
 no ip redirects
 ip nhrp authentication cisco
 ip nhrp map multicast dynamic
 ip nhrp network-id 123
 no ip split-horizon eigrp 123
 no ip next-hop-self eigrp 123
 tunnel source E0/1.100
 tunnel mode gre multipoint
 tunnel key 123

R1 (Spoke)

router eigrp 123
 no auto-summary
 network 150.1.0.0 0.0.255.255
 network 155.1.0.0 0.0.255.255
 eigrp stub connected
!
interface E0/1.100
 ip address 169.254.100.1 255.255.255.0
!
interface Loopback 0
 ip address 155.1.1.1 255.255.255.0
!
interface Tunnel0
 ip address 150.1.0.1 255.255.255.0
 ip nhrp authentication cisco
 ip nhrp map multicast 169.254.100.5
 ip nhrp map 150.1.0.5 169.254.100.5
 ip nhrp nhs 150.1.0.5
 ip nhrp network-id 123
 ip nhrp registration timeout 30
 ip nhrp holdtime 60
 tunnel source E0/1.100
 tunnel mode gre multipoint
 tunnel key 123

Les Spokes utilisent donc maintenant le mode d’encapsulation mGRE pour les Tunnels, et le Hub ajoute le Next-Hop d’origine dans les updates EIGRP (Plus de Next-Hop=0.0.0.0 comme en Phase 1).
Le subnet “150.1.0.0/24” sur R1 arrive sur R3 avec le Next-Hop “150.1.0.1” (R1). C’est important que R3 apprenne 150.1.0.0/24 avec R1 en Next-Hop. On va le voir, cela permet de déclencher la résolution du next-hop pour CEF. L’encapsulation mGRE des Spokes déclenche la résolution NHRP.

Maintenant, lorsque le trafic ne passe pas encore entre R1 et R3, voici l’état de la table de routage:

R3#sh ip route 155.1.1.1
Routing entry for 155.1.1.0/24
  Known via "eigrp 123", distance 90, metric 28288000, type internal
  Redistributing via eigrp 123
  Last update from 150.1.0.1 on Tunnel0, 00:06:13 ago
  Routing Descriptor Blocks:
  * 150.1.0.1, from 150.1.0.5, 00:06:13 ago, via Tunnel0
      Route metric is 28288000, traffic share count is 1
      Total delay is 105000 microseconds, minimum bandwidth is 100 Kbit
      Reliability 255/255, minimum MTU 1472 bytes
      Loading 1/255, Hops 2
 
R3#sh ip cef 155.1.1.1
155.1.1.0/24, version 65, epoch 0, connected
0 packets, 0 bytes
  via 150.1.0.1, Tunnel0, 0 dependencies
    next hop 150.1.0.1, Tunnel0
    invalid adjacency     <-----------------

Ensuite on déclenche le tunnel dynamique entre R3 et R1

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

Un nouveau tunnel dynamique (D) fait son apparition:

R3#sh dmvpn
Interface: Tunnel0, IPv4 NHRP Details
Type:Spoke, NHRP Peers:2,
 
 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 169.254.100.1         150.1.0.1    UP 00:07:24     D   <----------
     1 169.254.100.5         150.1.0.5    UP 00:08:26     S

Et le NHRP à résolu l’adresse NBMA de R1 sur R3:

R3#sh ip nhrp
150.1.0.1/32 via 150.1.0.1
   Tunnel0 created 00:00:06, expire 00:00:56
   Type: dynamic, Flags: router nhop
   NBMA address: 169.254.100.1
150.1.0.3/32 via 150.1.0.3
   Tunnel0 created 00:00:06, expire 00:00:58
   Type: dynamic, Flags: router unique local
   NBMA address: 169.254.100.3
    (no-socket)
150.1.0.5/32 via 150.1.0.5
   Tunnel0 created 00:01:19, never expire
   Type: static, Flags: used
   NBMA address: 169.254.100.5

La même commande NHRP sur R1 nous montre que les valeurs sont symétriques:

R1(config-if)#do sh ip nhrp
150.1.0.1/32 via 150.1.0.1
   Tunnel0 created 00:01:25, expire 00:00:59
   Type: dynamic, Flags: router unique local
   NBMA address: 169.254.100.1
    (no-socket)
150.1.0.3/32 via 150.1.0.3
   Tunnel0 created 00:01:25, expire 00:00:59
   Type: dynamic, Flags: router used nhop
   NBMA address: 169.254.100.3
150.1.0.5/32 via 150.1.0.5
   Tunnel0 created 00:09:43, never expire
   Type: static, Flags: used
   NBMA address: 169.254.100.5

Maintenant on regarde l’entrée CEF pour le R1 next-hop sur R3:

R3#sh ip cef 155.1.1.1
155.1.1.0/24, version 65, epoch 0, connected
0 packets, 0 bytes
  via 150.1.0.1, Tunnel0, 0 dependencies
    next hop 150.1.0.1, Tunnel0
    valid adjacency     <-----------------

L’entrée CEF pour “150.1.1.1” est maintenant valide, vu qu’une entrée NHRP est présente. Si le next-hop pour le préfix “150.1.1.1” pointait vers le Hub (Si le hub utilisais #default ip next-hop-self eigrp 123) alors le NHRP Lookup ne serait pas déclenché, et l’entrée NHRP ‘cut-through’ ne serait pas installée.

Autre façon de voir le fonctionnement de la Phase 2, lorsque aucune entrée NHRP n’est présente dans un des spokes (e.g. aucun paquet n’est encore passé vers un autre spoke), et que l’on fait un traceroute vers un autre Spoke, le premier traceroute passe par le hub, puis le deuxième passe directement vers la destination:

R2(config-if)#do trace 155.1.3.3
Type escape sequence to abort.
Tracing the route to 155.1.3.3
VRF info: (vrf in name/id, vrf out name/id)
  1 150.1.0.5 0 msec 2 msec 0 msec    <----- Ici on commence par passer sur le Hub.
  2 150.1.0.3 1 msec *  1 msec
R2(config-if)#do trace 155.1.3.3
Type escape sequence to abort.
Tracing the route to 155.1.3.3
VRF info: (vrf in name/id, vrf out name/id)
  1 150.1.0.3 0 msec *  5 msec

Le CEF résous donc les informations de Next-hop via NHRP. Aussi, comme on peut le voir ci-dessus, chaque entrée NHRP à un compteur qui expire, il commence lorsque l’entrée est enregistrée. Chaque 60 secondes, le process NHRP global démarre sur le routeur et vérifie les timers de toutes les entrées. Si le timer est >120 secondes, rien n’est fait sur les entrées CEF, dans le cas contraire, l’entrée est désignée “stale” (dépassée) mais toujours utilisable.
Dès que le routeur envoi un paquet utilisant l’entrée “stale”, il déclenche une nouvelle demande NHRP Resolution Request et rafraichis l’entrée NHRP correspondante et l’entrée CEF.
Si aucun paquet n’utilise l’entrée CEF “stale”, le NHRP mapping va expirer et l’entrée CEF deviens invalide, ce qui à pour effet de faire tomber le tunnel dynamique.

Récapitulatif sur le NHRP Phase 2
1 – Les spokes doivent avoir une vision complète des autres spokes via le routage (Préservation du Next-hop).
2 – CEF résous les informations sur les Next-Hop via NHRP, pas via la table de routage.
3 – Le plus gros problème : le #no ip next-hop-self eigrp 123 est requis pour faire fonctionner les tunnels avec CEF en phase 2, afin que le Hub fournisse l’information sur les Spokes dans ses updates, et cette commande ne fonctionne qu’en IOS 12.3 minimum. Apparemment, on peut faire fonctionner le tout sans CEF, le NHRP utiliserait alors le Process Switching, mais ce sera pour un autre jour (ou alors suivez le lien INE en bas de page) ;)

Ce problème de next-hop-self entraine la nécessité de n’avoir qu’un seul niveau de Hubs. On peut avoir plusieurs Hubs, mais ils devront forcément être reliés en mode “daisy-chain”, en NHS serveur les uns avec les autres. Ces configurations “statiques” réduisent la fiabilité du réseau.

Chaque Spoke doit avoir un maximum d’informations sur la topologie pour le routage (pas de summarization) afin que les autre spokes soient capables d’établir les tunnels Spoke-to-spoke. Cela limite l’évolution du réseau, et le paquet initial doit être process switché car l’entrée CEF n’est pas complète au début des opérations.

DMVPN Phase 3

Comme en phase 2, des tunnels mGRE sur le hub ET sur les Spokes, mais on ajoute une redirection NHRP qui permet au Data-Plane des conversations Spoke-to-spoke de joindre directement les Spoke sans passer par le Hub (sans avoir besoin de la résolution CEF).

NRHP Phase 3 utilise les spokes qui répondent maintenant aux NHRP Resolution Requests. Ce qui fait que le Hub n’est plus le seul à détenir les infors NHRP.

Voici comment ça fonctionne:
Etape 1
Les Spokes enregistrent leurs mappings Tunnel/NBMA avec le/les Hub. Cela permet au Hub de découvrir dynamiquement les spokes et d’établir les adjacences de routage. Ensuite les infos de routage sont échangées. Cependant, le Hub n’est pas obligé de préserver les informations, on peut summarizer les routes, étant donnée qu’elles sont envoyées aux spokes. On peut même renvoyer une default-route aux Spokes, cela améliore l’évolutivité du réseau.

Etape 2
Les spokes reçoivent les informations de routage, et remplissent leurs tables CEF. Plus d’entrée CEF invalide, elles sont toutes “complete”. Elles pointent toute vers l’IP NBMA du Hub, ce qui fait que tous les premiers paquets sont CEF switchés vers le Hub; et que l’invalid CEF ne déclenche plus la résolution NHRP.
Dorénavant, les spokes s’appuient sur le paquet NHRP Redirect message.

Etape 3
Un Tunnel mGRE est configuré pour les NHRP Redirects (1e commande importante pour la Phase 3). Fonctionnement similaire aux IP ICMP redirect. Quand un routeur reçoit un paquet IP en entrée de sont tunnel mGRE, et le renvoi sur la même interface, il envoi à la source un NHRP Redirect. Ce message demande à la source que le chemin n’est pas optimal, et qu’il devrait plutôt trouver un meilleur chemin via la NHRP Resolution. Ce premier paquet est toujours routé via la RIB.

Etape 4
Maintenant, le Spoke reçoit le NHRP Redirect. Le router envoi donc une NHRP Request vers la même IP de destination, qui n’est plus le NHS (bien que le paquet passe toujours par là). La NHRP Request voyage sur tous les Spokes jusqu’à ce qu’elle trouve la cible. C’est le fonctionnement normal du NHRP Request Forwarding, hop by hop.

Etape 5
Maintenant le Spoke (pas le NHS) répond à la résolution. Basé sur l’IP source présente dans le playload du paquet, il trouve le Spoke correspondant dans sa table de routage. Il utilise l’IP NBMA du routeur source et renvoi un NHRP Reply directement (sans re-traverser le Hub). La réponse arrive sur le routeur source et il connait alors l’IP NBMA de sa destination. Maintenant, en plus de réecrire la table NHRP, le routeur ré-ecrit l’entrée CEF.

La Ré-ecriture du CEF s’appel NHRP Shortcut. Au lieu d’avoir une adjacence CEF qui déclenche le NHRP Request, on ré-ecrit l’entrée CEF quand on reçoit la réponse NHRP. Simple :)
Le trafic est CEF switché tout le temps, et les réponses NHRP mettent à jour la table d’entrées CEF du routeur.

Un petit schéma pour récapituler tout ça:

Récapitulatif pour la Phase 3
1) Les NHRP requests ne sont plus déclenchés par les entrées CEF invalides. Ce qui fait que les entrées de routage peuvent être “simplifiées”.
2) Le Hub n’est plus la seule source d’informations NHRP. Tous les spokes participent aux échanges. Ce modèle n’est plus basé que sur le serveur, mais plutôt “peer-to-peer”.
3) Les réponses NHRP continennent tous les préfixes de routage, au lieu d’avoir seulement le Next-Hop.
4) Le paquet initial est CEF switché, et non plus process switché. Avec la Phase 3, on utilise CEF tout le temps.

Exemple de configuration pour DMVPN Phase 3
Les seuls changements à appliquer (par rapport à la phase 2) sont les suivants:
Hub:

int tun0
 ip nhrp redirect

Spoke’s:

int tun0
 ip nhrp shortcut

Conclusion
La phase 3 permet donc d’avoir un vrai design DMVPN évolutif. Plus besoin d’être restreint à une seule couche de Hubs, nous pouvons créer une hiérarchie de Hubs, simplifier les informations de routage où on le souhaite.

En espérant ne pas avoir fait trop de boulettes dans l’article, n’hésitez pas si vous en trouvez ;)

Articles très complets de chez INE:
– http://blog.ine.com/2008/08/02/dmvpn-explained/
– http://blog.ine.com/2008/12/23/dmvpn-phase-3/
– Migrating from Dynamic Multipoint VPN Phase 2 to Phase 3

Benoit

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

More Posts - Website

Follow Me: