Solutions de dépannage DMVPN les plus fréquentes

Introduction

Ce document contient les solutions les plus courantes aux problèmes liés au protocole Dynamic Multipoint VPN (DMVPN). Plusieurs de ces solutions peuvent être mises en application avant de procéder au dépannage approfondi de la connexion DMVPN. Ce document est présenté comme une liste de contrôle des procédures communes pour essayer avant que vous commenciez à effectuer le dépannage d'une connexion et appeller le support technique de Cisco.

Si vous avez besoin de documents présentant des exemples de configuration de DMVPN, reportez-vous à Exemples et notes techniques de configuration de DMVPN.

Remarque : Reportez-vous à Dépannage IPsec - Compréhension et utilisation des commandes de débogage pour fournir une explication des commandes de débogage courantes utilisées pour résoudre les problèmes IPsec.

Conditions préalables

Conditions requises

Cisco recommande que vous ayez des connaissances sur la configuration de DMVPN sur les routeurs Cisco IOS® .

Components Used

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• Cisco IOS

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

La configuration DMVPN ne fonctionne pas

Problème

Une solution DMVPN récemment configurée ou modifiée ne fonctionne pas.

Une configuration actuelle de DMVPN ne fonctionne plus.

Solutions

Cette section contient des solutions aux problèmes de DMVPN les plus courants.

Ces solutions peuvent faire figure de liste de vérification des éléments à vérifier ou à essayer (sans ordre particulier) avant de vous engager dans une démarche de dépannage approfondie :

• Problèmes courants

• Vérifiez si les paquets ISAKMP sont bloqués à ISP

• Vérifiez si GRE fonctionne correctement en supprimant la protection de tunnel

• L'enregistrement NHRP est défaillant.

• Vérifiez si les durées de vie sont configurées correctement

• Vérifiez si le trafic est acheminé dans une seule direction

• Vérifiez que le protocole de routage voisin est établi

Remarque : Avant de commencer, vérifiez les points suivants :

1. Synchronisez l’horodatage entre les éléments du réseau en étoile

2. Activez msec debug and log timestamps :

   Router(config)#service timestamps debug datetime msec

   Router(config)#service timestamps log datetime msec

3. Activez terminal exec prompt timestamp pour les sessions de débogage :

   Router#terminal exec prompt timestamp

Remarque : De cette façon, vous pouvez facilement corréler la sortie de débogage avec la sortie de la commande show.

Problèmes courants

Vérifiez la connectivité de base

1. Effectuez un ping depuis le réseau en étoile au moyen d’adresses NBMA et vice-versa.

   Ces pings doivent être émis directement de l’interface physique plutôt que par le tunnel DMVPN. Avec un peu de chance, il n’y a pas de pare-feu qui bloque les paquets ping. Si cette option ne fonctionne pas, vérifiez le routage et les pare-feu qui se trouvent entre les routeurs du réseau en étoile.

2. Aussi, utilisez la fonction traceroutepour vérifier le trajet qu’empruntent les paquets de tunnels qui sont chiffrés.

3. Utilisez les commandes debug (déboguer) et show (afficher) pour vérifier s’il n’y a aucune connectivité :

   • debug ip icmp

   • debug ip packet

     Remarque : La commande debug ip packet génère une quantité substantielle de sortie et utilise une quantité substantielle de ressources système. Cette commande doit être utilisée avec précaution dans les réseaux de production. Toujours utiliser avec la commande access-list (liste d’accès).

     Remarque : Pour plus d'informations sur l'utilisation de la liste d'accès avec debug ip packet, référez-vous à Dépanner avec les listes d'accès IP.

Vérifiez si la politique ISAKMP est incompatible

Si les stratégies ISAKMP configurées ne correspondent pas à la stratégie proposée par l'homologue distant, le routeur essaye la stratégie par défaut 65535. S’il n’y a pas de correspondance, la négociation ISAKMP échoue.

La commande show crypto isakmp sa permet d’afficher le SA ISAKMP sous forme de MM_NO_STATE, c’est-à-dire pour le principal mode d’échec.

Vérifiez s’il y a des secrets de clés partagées qui sont inexacts

Si les secrets partagés ne sont pas identiques des deux côtés, la négociation échouera.

Le routeur renvoie le message « sanity check failed » pour signaler l’échec d’intégrité.

Vérifiez l’ensemble de transformation IPsec pour une incompatibilité

Si l’ensemble de transformation de l’IPsec n’est pas compatible ou est discordant sur les deux appareils IPsec, la négociation IPsec échouera.

Le routeur émet le message « atts not acceptable » au sujet de la proposition IPsec.

Vérifiez si les paquets ISAKMP sont bloqués à ISP

Router#show crypto isakmp sa


IPv4 Crypto ISAKMP SA
Dst	            src	               state	   conn-id	  slot	   status
172.17.0.1	  172.16.1.1	    MM_NO_STATE	     0	           0	   ACTIVE
172.17.0.1	  172.16.1.1	    MM_NO_STATE	     0	           0	   ACTIVE (deleted)
172.17.0.5        172.16.1.1        MM_NO_STATE      0             0	   ACTIVE
172.17.0.5        172.16.1.1        MM_NO_STATE      0             0	   ACTIVE (deleted)

L’image ci-dessus illustre le basculement du tunnel VPN.

En outre, vérifiez debug crypto isakmp afin voir si le routeur Spoke envoie des paquets UDP 500 :

Router#debug crypto isakmp

04:14:44.450: ISAKMP:(0):Old State = IKE_READY  
                       New State = IKE_I_MM1
04:14:44.450: ISAKMP:(0): beginning Main Mode exchange
04:14:44.450: ISAKMP:(0): sending packet to 172.17.0.1 
              my_port 500 peer_port 500 (I) MM_NO_STATE
04:14:44.450: ISAKMP:(0):Sending an IKE IPv4 Packet.
04:14:54.450: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...
04:14:54.450: ISAKMP (0:0): incrementing error counter on sa, 
              attempt 1 of 5: retransmit phase 1
04:14:54.450: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE
04:14:54.450: ISAKMP:(0): sending packet to 172.17.0.1 
              my_port 500 peer_port 500 (I) MM_NO_STATE
04:14:54.450: ISAKMP:(0):Sending an IKE IPv4 Packet.
04:15:04.450: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...
04:15:04.450: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE...
04:15:04.450: ISAKMP (0:0): incrementing error counter on sa, 
              attempt 2 of 5: retransmit phase 1
04:15:04.450: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE

Ci-dessus la sortie de débogage montre que le routeur Spoke envoie un paquet UDP 500 toutes les dix secondes.

Vérifiez avec ISP pour voir si le routeur Spoke est directement relié au routeur ISP pour vous assurer qu’il autorise le trafic UDP 500.

Une fois qu’ISP autorise UDP 500, ajoutez ACL entrant dans l’interface de sortie, qui est un tunnel source pour permettre UDP 500, afin de vous assurer que le trafic UDP 500 est acheminé vers le routeur. Utilisez la commande d’affichage show access-list command pour vérifier si les nombres d’occurrences augmentent :

Router#show access-lists 101

Extended IP access list 101
    10 permit udp host 172.17.0.1 host 172.16.1.1 eq isakmp log (4 matches)
    20 permit udp host 172.17.0.5 host 172.16.1.1 eq isakmp log (4 matches)
    30 permit ip any any (295 matches)

Attention : Assurez-vous d'avoir ip any any any any autorisé dans votre liste d'accès. Sinon, tous les autres trafics seront bloqués pour ce qui concerne la listes d’accès appliquée l'arrivée sur l'interface de sortie.

Vérifiez si GRE fonctionne en supprimant la protection de tunnel

Lorsque DMVPN ne fonctionne pas, avant de procéder au dépannage avec IPsec, vérifiez que le tunnels GRE fonctionnent correctement, sans chiffrement IPsec.

Pour en savoir plus, reportez-vous au document Configuration d’un Tunnel GRE.

L'enregistrement NHRP est défaillant.

Le tunnel VPN entre les éléments du réseau en étoile est en fonction, mais il est impossible de faire passer le trafic de données :

Router#show crypto isakmp sa
        dst             src             state          conn-id  slot   status
        172.17.0.1      172.16.1.1      QM_IDLE           1082    0    ACTIVE

Router#show crypto IPSEC sa
local  ident (addr/mask/prot/port): (172.16.1.1/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (172.17.0.1/255.255.255.255/47/0)
#pkts encaps: 154, #pkts encrypt: 154, #pkts digest: 154
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
inbound esp sas:
spi: 0xF830FC95(4163959957)
outbound esp sas:
spi: 0xD65A7865(3596253285)

!--- !--- Output is truncated !---

Cela montre que le retour du trafic ne revient pas de l’autre extrémité du tunnel.

Vérifiez l’entrée NHS dans le routeur Spoke :

Router#show  ip nhrp nhs detail
Legend: E=Expecting replies, R=Responding
Tunnel0: 172.17.0.1  E  req-sent 0  req-failed 30 repl-recv 0
Pending Registration Requests:
Registration Request: Reqid 4371, Ret 64  NHS 172.17.0.1

Cela montre que la demande de NHS est défaillante. Pour résoudre ce problème, assurez-vous que la configuration de l’interface de tunnel de routeur Spoke est exacte.

Exemple de configuration :

interface Tunnel0
 ip address 10.0.0.9 255.255.255.0
 ip nhrp map 10.0.0.1 172.17.0.1
 ip nhrp map multicast 172.17.0.1
 ip nhrp nhs 172.17.0.1

!--- !--- Output is truncated !---

Exemple de configuration avec l’entrée correcte pour le serveur NHS :

interface Tunnel0
 ip address 10.0.0.9 255.255.255.0
 ip nhrp map 10.0.0.1 172.17.0.1
 ip nhrp map multicast 172.17.0.1
 ip nhrp nhs 10.0.0.1

!--- !--- Output is truncated !---

Maintenant, vérifiez l’entrée de NHS et les compteurs de chiffrement/déchiffrement IPsec :

Router#show ip nhrp nhs detail
Legend: E=Expecting replies, R=Responding
Tunnel0:        10.0.0.1 RE  req-sent 4  req-failed 0  repl-recv 3 (00:01:04 ago)

Router#show crypto IPSec sa 
local  ident (addr/mask/prot/port): (172.16.1.1/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (172.17.0.1/255.255.255.255/47/0)
#pkts encaps: 121, #pkts encrypt: 121, #pkts digest: 121
#pkts decaps: 118, #pkts decrypt: 118, #pkts verify: 118
inbound esp sas:
spi: 0x1B7670FC(460747004)
outbound esp sas:
spi: 0x3B31AA86(993110662)

!--- !--- Output is truncated !---

Vérifiez si les durées de vie sont configurées correctement

Utilisez ces commandes pour vérifier la durée de vie de SA actuelle et le moment de la prochaine renégociation :

• show crypto isakmp sa detail

• show crypto ipsec sa peer <NBMA-address-peer>

Observez les valeurs de durée de vie de la SA. S’il s’agit de valeurs semblables aux durées de vie configurées (les valeurs par défaut sont 24 heures pour ISAKMP et 1 heure pour IPsec), cela signifie que ces SA ont été négociées récemment. Si vous cherchez un peu plus tard et qu’elles ont été renégociées de nouveau, ISAKMP ou IPsec pourraient fluctuer dans tous les sens.

Router#show crypto ipsec security-assoc lifetime
Security association lifetime: 4608000 kilobytes/3600 seconds

Router#show crypto isakmp policy
Global IKE policy
Protection suite of priority 1
Encryption algorithm: DES-Data Encryption Standard (65 bit keys)
Hash algorithm: Message Digest 5
Authentication method: Pre-Shared Key
Diffie-Hellman group: #1 (768 bit)
Lifetime: 86400 seconds, no volume limit
Default protection suite
 Encryption algorithm: DES- Data Encryption Standard (56 bit keys)
 Hash algorithm: Secure Hash Standard
 Authentication method: Rivest-Shamir-Adleman Signature
 Diffie-Hellman group: #1 (768 bit)
 Lifetime: 86400 seconds, no volume limit

Router# show crypto ipsec sa
interface: Ethernet0/3
    Crypto map tag: vpn, local addr. 172.17.0.1
   local  ident (addr/mask/prot/port): (172.16.1.1/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (172.17.0.1/255.255.255.255/47/0)
   current_peer: 172.17.0.1:500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 19, #pkts encrypt: 19, #pkts digest 19
    #pkts decaps: 19, #pkts decrypt: 19, #pkts verify 19
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0
    #send errors 1, #recv errors 0
     local crypto endpt.: 172.16.1.1, remote crypto endpt.: 172.17.0.1
     path mtu 1500, media mtu 1500
     current outbound spi: 8E1CB77A

 inbound esp sas:
      spi: 0x4579753B(1165587771)
        transform: esp-3des esp-md5-hmac ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 2000, flow_id: 1, crypto map: vpn
        sa timing: remaining key lifetime (k/sec): (4456885/3531)
        IV size: 8 bytes
        replay detection support: Y
outbound esp sas:
      spi: 0x8E1CB77A(2384246650)
        transform: esp-3des esp-md5-hmac ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 2001, flow_id: 2, crypto map: vpn
        sa timing: remaining key lifetime (k/sec): (4456885/3531)
        IV size: 8 bytes
        replay detection support: Y  

Vérifiez si le trafic est acheminé dans une seule direction

Le tunnel VPN entre les éléments de la configuration de routage Spoke-à-Spoke est en fonction, mais il est impossible de faire passer le trafic de données :

Spoke1# show crypto ipsec sa peer 172.16.2.11
   local  ident (addr/mask/prot/port): (172.16.1.1/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (172.16.2.11/255.255.255.255/47/0)
    #pkts encaps: 110, #pkts encrypt: 110
    #pkts decaps: 0, #pkts decrypt: 0, 
local crypto endpt.: 172.16.1.1, 
remote crypto endpt.: 172.16.2.11
      inbound esp sas:
      spi: 0x4C36F4AF(1278669999)
      outbound esp sas:
      spi: 0x6AC801F4(1791492596)

!--- !--- Output is truncated !---


Spoke2#sh crypto ipsec sa peer 172.16.1.1
   local  ident (addr/mask/prot/port): (172.16.2.11/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (172.16.1.1/255.255.255.255/47/0)
   #pkts encaps: 116, #pkts encrypt: 116,             
   #pkts decaps: 110, #pkts decrypt: 110,  
local crypto endpt.: 172.16.2.11, 
remote crypto endpt.: 172.16.1.1
     inbound esp sas:
     spi: 0x6AC801F4(1791492596)
     outbound esp sas:
     spi: 0x4C36F4AF(1278669999

!--- !--- Output is truncated !---

Il n’y a aucun paquet de decap au niveau du routeur Spoke1. Cela signifie que les paquets esp sont perdus sur le trajet du retour du routeur Spoke2 au routeur Spoke1.

Le routeur Spoke2 présente des paquets encap et decap, ce qui signifie que le trafic ESP est filtré avant d’atteindre le routeur Spoke2. Cela peut se produire au bout ISP au routeur Spoke2 ou à n’importe quel pare-feu dans le trajet entre le routeur Spoke2 et le routeur Spoke1. Après avoir autorisé ESP (protocole IP 50), les routeurs Spoke1 et Spoke2 présentent tous les deux des compteurs d’encap et de decap en progression.

spoke1# show crypto ipsec sa peer 172.16.2.11
   local  ident (addr/mask/prot/port): (172.16.1.1/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (172.16.2.11/255.255.255.255/47/0)
    #pkts encaps: 300, #pkts encrypt: 300
    #pkts decaps: 200, #pkts decrypt: 200

!--- !--- Output is truncated !---

spoke2#sh crypto ipsec sa peer 172.16.1.1
   local  ident (addr/mask/prot/port): (172.16.2.11/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (172.16.1.1/255.255.255.255/47/0)
   #pkts encaps: 316, #pkts encrypt: 316,             
   #pkts decaps: 300, #pkts decrypt: 310

!--- !--- Output is truncated !---

Vérifiez que le protocole de routage voisin est établi

Les routeurs Spoke ne prviennent pas à établir la relation voisin de protocole de routage :

Hub# show ip eigrp neighbors
H   Address     Interface   Hold Uptime     SRTT    RTO  	 Q  	Seq
                                  (sec)             (ms)  Cnt 	Num
2   10.0.0.9     Tu0         13  00:00:37     1    5000  	 1  	0
0   10.0.0.5     Tu0         11	 00:00:47   1587   5000  	 0 	1483
1   10.0.0.11    Tu0         13	 00:00:56     1    5000  	 1  	0
Syslog message: 
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 10: 
Neighbor 10.0.0.9 (Tunnel0) is down: retry limit exceeded

Hub# show ip route eigrp
	172.17.0.0/24 is subnetted, 1 subnets
C       172.17.0.0 is directly connected, FastEthernet0/0
     10.0.0.0/24 is subnetted, 1 subnets
C       10.0.0.0 is directly connected, Tunnel0
C    192.168.0.0/24 is directly connected, FastEthernet0/1
S*   0.0.0.0/0 [1/0] via 172.17.0.100

Vérifiez si la multidiffusion de NHRP est correctement configurée dans le concentrateur.

Dans le concentrateur, il faut que la mise en correspondance de la multidiffusion de nhrp dynamique soit configurée dans l’interface de tunnel du concentrateur.

Exemple de configuration :

interface Tunnel0
 ip address 10.0.0.1 255.255.255.0
 ip mtu 1400
 no ip next-hop-self eigrp 10
 ip nhrp authentication test
 ip nhrp network-id 10
 no ip split-horizon eigrp 10
 tunnel mode gre multipoint

!--- !--- Output is truncated !---

Exemple de configuration avec l’entrée correcte pour la mise en correspondance de la multidiffusion nhrp dynamique :

interface Tunnel0
 ip address 10.0.0.1 255.255.255.0
 ip mtu 1400
 no ip next-hop-self eigrp 10
 ip nhrp authentication test
 ip nhrp map multicast dynamic
 ip nhrp network-id 10
 no ip split-horizon eigrp 10
 tunnel mode gre multipoint

!--- !--- Output is truncated !---

Cela permet au NHRP d’ajouter automatiquement les routeurs Spoke pour la mise en correspondance de NHRP de multidiffusion.

Pour en savoir plus, reportez-vous à la section « ip nhrp map multicast dynamic »des commandes NHRP .

Hub#show ip eigrp neighbors
IP-EIGRP neighbors for process 10
H   Address     Interface   Hold   Uptime   SRTT    RTO     Q     Seq
                                           (sec)    (ms)   Cnt    Num
2   10.0.0.9     Tu0         12   00:16:48   13     200     0     334
1   10.0.0.11    Tu0         13   00:17:10   11     200     0     258
0   10.0.0.5     Tu0         12   00:48:44  1017    5000    0     1495

Hub#show ip route

     172.17.0.0/24 is subnetted, 1 subnets
C       172.17.0.0 is directly connected, FastEthernet0/0
D    192.168.11.0/24 [90/2944000] via 10.0.0.11, 00:16:12, Tunnel0
     10.0.0.0/24 is subnetted, 1 subnets
C       10.0.0.0 is directly connected, Tunnel0
C    192.168.0.0/24 is directly connected, FastEthernet0/1
D    192.168.2.0/24 [90/2818560] via 10.0.0.9, 00:15:45, Tunnel0
S*   0.0.0.0/0 [1/0] via 172.17.0.100

Le routage vers les routeurs Spokes est décrit dans le protocole eigrp.

Problème avec l’intégration de VPN d’accès à distance avec DMVPN

Problème

DMVPN fonctionne bien, mais ne parvient pas à établir le RAVPN.

Solution

Utilisez des profils ISAKMP et des profils IPsec pour y parvenir.

Créez des profils distincts pour DMVPN et pour RAVPN.

Pour en savoir plus, consultez l’exemple de configuration de DMVPN et Easy VPN avec des profils ISAKMP.

Problème lié à dual-hub-dual-dmvpn.

Problème

Problème lié à dual-hub-dual-dmvpn. Plus précisément, les tunnels cessent de fonctionner et ne parviennent plus à renégocier.

Solution

Utilisez le mot-clé partagé de la protection IPsec de tunnel, dans les deux interfaces de tunnel du concentrateur, ainsi que sur le routeur Spoke.

Exemple de configuration :

interface Tunnel43
 description <<tunnel to primary cloud>>
 tunnel source interface vlan10
 tunnel protection IPSec profile myprofile shared

!--- !--- Output is truncated !---

interface Tunnel44
 description <<tunnel to secondary cloud>>
 tunnel source interface vlan10
 tunnel protection IPSec profile myprofile shared

!--- !--- Output is truncated !---

Pour en savoir plus, consultez la section sur la protection de tunnel dans le document de référence sur les commandes de sécurité de Cisco IOS.

Difficultés à se connecter à un serveur au moyen de DMVPN

Problème

Problème à accéder à un serveur par le biais du réseau DMVPN.

Solution

Le problème pourrait être lié à la taille de MTU et de MSS du paquet qui utilise GRE et IPsec.

Maintenant, la taille de paquet pourrait créer un problème, dans le contexte de la fragmentation. Pour éliminer ce problème, utilisez ces commandes :

ip mtu 1400
ip tcp adjust-mss 1360
crypto IPSec fragmentation after-encryption (global)

Vous pouvez également configurer la commande path-mtu-discovery du tunnel pour qu’elle détecte de manière dynamique la taille de MTU.

Pour obtenir une explication plus détaillée, reportez-vous à la section sur la résolution des enjeux liés à la fragmentation d’IP, à MTU, à MSS et à PMTUD avec GRE et IPSEC.

Impossible d’accéder aux serveurs sur DMVPN par l’entremise de certains ports

Problème

Impossible d’accéder aux serveurs sur DMVPN par l’entremise de ports en particulier.

Solution

Vérifiez au moyen de la désactivation de l’ensemble de fonctionnalités du pare-feu IOS pour voir si cela fonctionne ensuite.

Si cela fonctionne bien, cela signifie que le problème est lié à la configuration du pare-feu IOS, pas au DMVPN.

Informations connexes

• VPN multipoint dynamique (DMVPN)
• Négociation IPSec/Protocoles IKE
• Support et documentation techniques - Cisco Systems

Historique de révision