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.
Cisco recommande que vous ayez des connaissances sur la configuration de DMVPN sur les routeurs Cisco IOS® .
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.
Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.
Une solution DMVPN récemment configurée ou modifiée ne fonctionne pas.
Une configuration actuelle de DMVPN ne fonctionne plus.
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 :
Remarque : Avant de commencer, vérifiez les points suivants :
Synchronisez l’horodatage entre les éléments du réseau en étoile
Activez msec debug and log timestamps :
Router(config)#service timestamps debug datetime msec
Router(config)#service timestamps log datetime msec
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.
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.
Aussi, utilisez la fonction traceroutepour vérifier le trajet qu’empruntent les paquets de tunnels qui sont chiffrés.
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.
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.
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é.
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.
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.
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.
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 !---
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
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 !---
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.
DMVPN fonctionne bien, mais ne parvient pas à établir le RAVPN.
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. Plus précisément, les tunnels cessent de fonctionner et ne parviennent plus à renégocier.
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.
Problème à accéder à un serveur par le biais du réseau DMVPN.
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 ports en particulier.
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.
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
06-May-2010 |
Première publication |