Problemen met DMVPN oplossen

Inleiding

Dit document beschrijft de meest voorkomende oplossingen voor Dynamic Multipoint VPN (DMVPN) problemen.

---

Voorwaarden

Vereisten

Cisco raadt kennis van de volgende onderwerpen aan:

---

Gebruikte componenten

Dit document is niet beperkt tot specifieke software- en hardware-versies.

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

---

Conventies

Raadpleeg Cisco Technical Tips Conventions (Conventies voor technische tips van Cisco) voor meer informatie over documentconventies.

---

Achtergrondinformatie

In dit document worden algemene procedures beschreven voor het oplossen van problemen met DMVPN op Cisco IOS- en Cisco IOS XE-routers. Het is bedoeld om netwerktechnici te helpen bij het valideren van de belangrijkste DMVPN-besturings- en gegevensplancomponenten voordat ze diepere probleemoplossing uitvoeren of contact opnemen met de technische ondersteuning van Cisco.

Het document maakt gebruik van een gestructureerde workflow voor probleemoplossing die begint met basisbereikbaarheid van de ondervloer en vervolgens doorloopt via onderhandelingen via Internet Key Exchange (IKE) / Internet Security Association en Key Management Protocol (ISAKMP), IP Security (IPsec)-beleidsvalidatie, GRE-tunnelwerking (Generic Routing Encapsulation), NHRP-registratie (Next Hop Resolution Protocol), routeringsprotocolaansluitingen, versleuteld verkeer in één richting en maximale transmissie-eenheid (MTU), maximale segmentgrootte (MSS) of fragmentatieproblemen.

---

Veel DMVPN-problemen worden veroorzaakt door veelvoorkomende problemen zoals onbereikbare niet-broadcast multiaccess (NBMA)-adressen, niet-overeenkomende IKE- of IPsec-parameters, onjuiste vooraf gedeelde sleutels, geblokkeerde IKE / Network Address Translation Traversal (NAT-T) / Encapsulating Security Payload (ESP) -verkeer, onjuiste NHRP-toewijzingen, verkeerde configuratie van routeringsprotocollen of problemen met pakketgrootte veroorzaakt door GRE- en IPsec-overhead.

Gebruik dit document als een checklist om de falende DMVPN-component te isoleren en het verwachte gedrag te verifiëren met operationele opdrachten en tellers. Gebruik in productienetwerken disruptieve tests, zoals het verwijderen van IPsec-tunnelbescherming of het toepassen van tijdelijke toegangscontrolelijsten (ACL's), alleen tijdens een goedgekeurd onderhoudsvenster of in een gecontroleerde omgeving.

  

Raadpleeg Debug-opdrachten begrijpen en gebruiken om IPsec-problemen op te lossen om een uitleg te geven van veelvoorkomende foutopsporingsopdrachten die worden gebruikt om IPsec-problemen op te lossen.

---

Workflow voor probleemoplossing van DMVPN

eerste gegevensverzameling

1. Synchroniseer tijdstempels tussen de hub en de spaak.

---

2. Msec-foutopsporings- en logtijdstempels inschakelen op de DMVPN-apparaten:

Router(config)#service timestamps debug datetime msec
Router(config)#service timestamps log datetime msec

---

3. Schakel terminal exec prompt timestamp voor de debugging sessies:

Router#terminal exec prompt timestamp

Verifieer de basisconnectiviteit van de ondervloer

Voordat u problemen met DMVPN oplost, controleert u de basisconnectiviteit tussen de hub en gesproken NBMA-adressen. Ping van de hub NBMA adres naar de gesproken NBMA adres, dan ping van de gesproken NBMA adres naar de hub NBMA adres. Deze tests moeten de fysieke interface als bron gebruiken, niet de DMVPN-tunnelinterface.

---

Ondergrondse bereikbaarheid moet buiten de DMVPN-tunnel werken. Als de hub en de spaak elkaar niet kunnen bereiken via hun NBMA-adressen, kunnen DMVPN-besturingsvliegtuig en dataverkeer niet correct worden vastgesteld. Gebruik een uitgebreide ping om het juiste bronadres of de juiste broninterface op te geven.

HUB#ping  source 
SPOKE#ping  source 

---

Als de ping mislukt, controleert u:

• Standaard/statische routes of dynamische routering tussen de hub en gesproken NBMA-adressen
• Firewall- of ACL-regels tussen de hub en spraak

---

Voer ook traceroute uit vanaf het NBMA-bronadres om het onderliggende pad te verifiëren.

Router#traceroute  source 

---

Gebruik pakketvastlegging of voer foutopsporingsopdrachten uit om de basispakketstroom te bevestigen:

• Een ingesloten pakketopname (EPC) configureren
• Voer debug ip icmp of debug ip-pakket uit

---

IKEv1/ISAKMP-beleidscompatibiliteit controleren

Als het geconfigureerde ISAKMP-beleid niet overeenkomt met het voorgestelde beleid van de externe peer, kan de router het standaardbeleid van 65535 proberen. Als dat ook niet klopt, mislukt de ISAKMP-onderhandeling. 

---

De router kan ook het atts-bericht niet aanvaardbaar retourneren, waardoor een mismatch in het fase 1-beleid kan worden vastgesteld. Deze mismatches kunnen zijn:

• levensduur
• Hash (SHA, MD5)
• Diffie-Hellman-groep
• Codering (AES, 3DES)
• Authenticatie (vooraf gedeelde sleutel of certificaten)

---

De opdracht show crypto isakmp sa toont de ISAKMP SA in MM_NO_STATE, wat betekent dat de hoofdmodus is mislukt. In het volgende voorbeeld is er een mismatch met het hash-algoritme dat is geconfigureerd op het SPOKE-apparaat, dat kan worden gezien onder de debug-crypto isakmp-uitvoer:

SPOKE1#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
172.17.0.1 172.17.1.1 MM_NO_STATE 0 ACTIVE
172.17.0.1      172.17.1.1      MM_NO_STATE          0 ACTIVE (deleted)

HUB#debug crypto isakmp 
Crypto ISAKMP debugging is on
*Jul 15 00:45:13.007: ISAKMP-PAK: (0):received packet from 172.17.1.1 dport 500 sport 500 Global (R) MM_NO_STATE
*Jul 15 00:45:23.029: ISAKMP: (0):purging SA., sa=80007BE36567F040, delme=80007BE36567F040
*Jul 15 00:45:24.878: ISAKMP-PAK: (0):received packet from 172.17.1.1 dport 500 sport 500 Global (N) NEW SA
*Jul 15 00:45:24.879: ISAKMP: (0):Created a peer struct for 172.17.1.1, peer port 500
*Jul 15 00:45:24.879: ISAKMP: (0):New peer created peer = 0x80007BE3D73BBED0 peer_handle = 0x8000000040000008
*Jul 15 00:45:24.879: ISAKMP: (0):Locking peer struct 0x80007BE3D73BBED0, refcount 1 for crypto_isakmp_process_block
*Jul 15 00:45:24.879: ISAKMP: (0):local port 500, remote port 500
*Jul 15 00:45:24.879: ISAKMP: (0):insert sa successfully sa = 80007BE36567F040
*Jul 15 00:45:24.879: ISAKMP: (0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
*Jul 15 00:45:24.879: ISAKMP: (0):Old State = IKE_READY  New State = IKE_R_MM1 

*Jul 15 00:45:24.880: ISAKMP: (0):processing SA payload. message ID = 0
*Jul 15 00:45:24.880: ISAKMP: (0):processing vendor id payload
*Jul 15 00:45:24.880: ISAKMP: (0):vendor ID seems Unity/DPD but major 69 mismatch
*Jul 15 00:45:24.880: ISAKMP: (0):vendor ID is NAT-T RFC 3947
*Jul 15 00:45:24.880: ISAKMP: (0):processing vendor id payload
*Jul 15 00:45:24.880: ISAKMP: (0):vendor ID seems Unity/DPD but major 245 mismatch
*Jul 15 00:45:24.880: ISAKMP: (0):vendor ID is NAT-T v7
*Jul 15 00:45:24.880: ISAKMP: (0):processing vendor id payload
*Jul 15 00:45:24.880: ISAKMP: (0):vendor ID seems Unity/DPD but major 157 mismatch
*Jul 15 00:45:24.880: ISAKMP: (0):vendor ID is NAT-T v3
*Jul 15 00:45:24.880: ISAKMP: (0):processing vendor id payload
*Jul 15 00:45:24.880: ISAKMP: (0):vendor ID seems Unity/DPD but major 123 mismatch
*Jul 15 00:45:24.880: ISAKMP: (0):vendor ID is NAT-T v2
*Jul 15 00:45:24.880: ISAKMP: (0):found peer pre-shared key matching 172.17.1.1
*Jul 15 00:45:24.880: ISAKMP: (0):local preshared key found
*Jul 15 00:45:24.880: ISAKMP: (0):Scanning profiles for xauth ...
*Jul 15 00:45:24.880: ISAKMP: (0):Checking ISAKMP transform 1 against priority 10 policy
*Jul 15 00:45:24.880: ISAKMP: (0):      encryption AES-CBC
*Jul 15 00:45:24.880: ISAKMP: (0):      keylength of 128
*Jul 15 00:45:24.880: ISAKMP: (0):      hash SHA512
*Jul 15 00:45:24.881: ISAKMP: (0):      default group 19
*Jul 15 00:45:24.881: ISAKMP: (0):      auth pre-share
*Jul 15 00:45:24.881: ISAKMP: (0):      life type in seconds
*Jul 15 00:45:24.881: ISAKMP:      life duration (VPI) of  0x0 0x1 0x51 0x80 
*Jul 15 00:45:24.881: ISAKMP-ERROR: (0):Hash algorithm offered does not match policy!
*Jul 15 00:45:24.881: ISAKMP-ERROR: (0):atts are not acceptable. Next payload is 0
*Jul 15 00:45:24.881: ISAKMP-ERROR: (0):no offers accepted!
*Jul 15 00:45:24.884: ISAKMP-ERROR: (0):phase 1 SA policy not acceptable! (local 172.17.0.1 remote 172.17.1.1)
*Jul 15 00:45:24.884: ISAKMP: (0):: incrementing error counter on sa, attempt 1 of 5: construct_fail_ag_init
*Jul 15 00:45:24.884: ISAKMP-PAK: (0):sending packet to 172.17.1.1 my_port 500 peer_port 500 (R) MM_NO_STATE
*Jul 15 00:45:24.885: ISAKMP: (0):Sending an IKE IPv4 Packet.
*Jul 15 00:45:24.886: ISAKMP: (0):peer does not do paranoid keepalives.
*Jul 15 00:45:24.886: ISAKMP-ERROR: (0):deleting SA reason "Phase1 SA policy proposal not accepted" state (R) MM_NO_STATE (peer 172.17.1.1)

---

Configuratie van vooraf gedeelde sleutel controleren

Tijdens fase 1 van IKE gebruiken beide peers onafhankelijk van elkaar de geconfigureerde vooraf gedeelde sleutel, het gedeelde geheim van Diffie-Hellman en andere waarden die tijdens de onderhandeling zijn uitgewisseld om een cryptografische hash te berekenen; elke router verifieert vervolgens de hash die is ontvangen van zijn peer overeenkomt met zijn eigen berekening, waaruit blijkt dat beide partijen dezelfde vooraf gedeelde sleutel hebben zonder de sleutel zelf te verzenden.

---

Als vooraf gedeelde sleutels niet aan beide kanten hetzelfde zijn, mislukt de onderhandeling. De router retourneert vervolgens een mislukt bericht van de sanitaircontrole. Schakel de debugs (debug crypto isakmp en debug crypto ipsec) in om deze berichten te observeren:

HUB#debug crypto ipsec
Crypto IPSEC debugging is on

HUB#debug crypto isakmp 
Crypto ISAKMP debugging is on
*Jul 15 01:11:32.971: ISAKMP: (0):processing KE payload. message ID = 0
*Jul 15 01:11:32.986: ISAKMP: (0):processing NONCE payload. message ID = 0
*Jul 15 01:11:32.986: ISAKMP: (0):found peer pre-shared key matching 172.17.1.1
*Jul 15 01:11:32.987: ISAKMP: (1007):processing vendor id payload
*Jul 15 01:11:32.987: ISAKMP: (1007):vendor ID is DPD
*Jul 15 01:11:32.987: ISAKMP: (1007):processing vendor id payload
*Jul 15 01:11:32.987: ISAKMP: (1007):speaking to another IOS box!
*Jul 15 01:11:32.987: ISAKMP: (1007):processing vendor id payload
*Jul 15 01:11:32.987: ISAKMP: (1007):vendor ID seems Unity/DPD but major 40 mismatch
*Jul 15 01:11:32.987: ISAKMP: (1007):vendor ID is XAUTH
*Jul 15 01:11:32.987: ISAKMP: (1007):received payload type 20
*Jul 15 01:11:32.987: ISAKMP: (1007):His hash no match - this node outside NAT
*Jul 15 01:11:32.987: ISAKMP: (1007):received payload type 20
*Jul 15 01:11:32.987: ISAKMP: (1007):No NAT Found for self or peer
*Jul 15 01:11:32.987: ISAKMP: (1007):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
*Jul 15 01:11:32.987: ISAKMP: (1007):Old State = IKE_R_MM3  New State = IKE_R_MM3 

*Jul 15 01:11:32.987: ISAKMP-PAK: (1007):sending packet to 172.17.1.1 my_port 500 peer_port 500 (R) MM_KEY_EXCH
*Jul 15 01:11:32.987: ISAKMP: (1007):Sending an IKE IPv4 Packet.
*Jul 15 01:11:32.988: ISAKMP: (1007):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
*Jul 15 01:11:32.988: ISAKMP: (1007):Old State = IKE_R_MM3  New State = IKE_R_MM4 

*Jul 15 01:11:33.010: ISAKMP-PAK: (1007):received packet from 172.17.1.1 dport 500 sport 500 Global (R) MM_KEY_EXCH
*Jul 15 01:11:33.010: ISAKMP-PAK-ERROR: (1007):reserved not zero on ID payload!
*Jul 15 01:11:33.010: %CRYPTO-4-IKMP_BAD_MESSAGE: IKE message from 172.17.1.1 failed its sanity check or is malformed

---

De compatibiliteit van de IPsec-transformatieset controleren

Als de IPsec-transformatieset niet compatibel is of niet overeenkomt met de twee IPsec-apparaten, mislukt de IPsec-onderhandeling. Voer de debug crypto isakmp en debug crypto ipsec commando's om te helpen identificeren van het probleem:

HUB#debug crypto isakmp 
Crypto ISAKMP debugging is on
*Jul 14 23:41:24.341: ISAKMP: (1003):purging node 3041685630
*Jul 14 23:41:39.807: ISAKMP-PAK: (1003):received packet from 172.17.1.1 dport 500 sport 500 Global (R) QM_IDLE      
*Jul 14 23:41:39.807: ISAKMP: (1003):set new node 1354194457 to QM_IDLE      
*Jul 14 23:41:39.807: ISAKMP: (1003):processing HASH payload. message ID = 1354194457
*Jul 14 23:41:39.807: ISAKMP: (1003):processing SA payload. message ID = 1354194457
*Jul 14 23:41:39.807: ISAKMP: (1003):Checking IPSec proposal 1
*Jul 14 23:41:39.807: ISAKMP: (1003):transform 1, ESP_AES 
*Jul 14 23:41:39.807: ISAKMP: (1003):   attributes in transform:
*Jul 14 23:41:39.807: ISAKMP: (1003):      encaps is 1 (Tunnel)
*Jul 14 23:41:39.807: ISAKMP: (1003):      SA life type in seconds
*Jul 14 23:41:39.807: ISAKMP: (1003):      SA life duration (basic) of 3600
*Jul 14 23:41:39.807: ISAKMP: (1003):      SA life type in kilobytes
*Jul 14 23:41:39.807: ISAKMP:      SA life duration (VPI) of  0x0 0x46 0x50 0x0 
*Jul 14 23:41:39.813: ISAKMP: (1003):      authenticator is HMAC-SHA512
*Jul 14 23:41:39.813: ISAKMP: (1003):      key length is 128
*Jul 14 23:41:39.813: ISAKMP: (1003):atts are acceptable.
*Jul 14 23:41:39.813: ISAKMP-ERROR: (1003):IPSec policy invalidated proposal with error 256
*Jul 14 23:41:39.815: ISAKMP-ERROR: (1003):phase 2 SA policy not acceptable! (local 172.17.0.1 remote 172.17.1.1)
*Jul 14 23:41:39.815: ISAKMP: (1003):set new node 460336619 to QM_IDLE      
*Jul 14 23:41:39.815: ISAKMP: (1003):Sending NOTIFY PROPOSAL_NOT_CHOSEN protocol 3
        spi 9223508253390078112, message ID = 460336619
*Jul 14 23:41:39.815: ISAKMP-PAK: (1003):sending packet to 172.17.1.1 my_port 500 peer_port 500 (R) QM_IDLE      
*Jul 14 23:41:39.815: ISAKMP: (1003):Sending an IKE IPv4 Packet.
*Jul 14 23:41:39.816: ISAKMP: (1003):purging node 460336619
*Jul 14 23:41:39.816: ISAKMP-ERROR: (1003):deleting node 1354194457 error TRUE reason "QM rejected"

HUB#debug crypto ipsec 
Crypto IPSEC debugging is on
*Jul 14 23:43:48.909: IPSEC(validate_proposal_request): proposal part #1
*Jul 14 23:43:48.910: IPSEC(validate_proposal_request): proposal part #1,
  (key eng. msg.) INBOUND local= 172.17.0.1:0, remote= 172.17.1.1:0,
    local_proxy= 172.17.0.1/255.255.255.255/47/0,
    remote_proxy= 172.17.1.1/255.255.255.255/47/0,
    protocol= ESP, transform= esp-aes esp-sha512-hmac (Tunnel), esn= FALSE,
    lifedur= 0s and 0kb, 
    spi= 0x0(0), conn_id= 0, keysize= 128, flags= 0x0
*Jul 14 23:43:48.916: map_db_find_best did not find matching mapcrypto_mapdb_find_map Fail to find matching policy ivrf 0, fvrf 0, flags 1, ike_profile NULL, local_proxy 172.17.0.1, remote_proxy 172.17.1.1, km_local 172.17.0.1, km_remote 172.17.1.1, km_local_port 65535, km_remote_port 65535 
*Jul 14 23:43:48.916: IPSEC(ipsec_process_proposal): transform not supported: {esp-aes esp-sha512-hmac }
HUB#undebug all
All possible debugging has been turned off
HUB#

---

Voer de opdracht show crypto ipsec transform-set aan beide zijden van de tunnel uit om een mismatch te helpen identificeren. In dit voorbeeld stelt SPOKE AES-codering, SHA-512-integriteit en tunnelmodus voor, die verschilt van HUB-parameters:

HUB#show crypto ipsec transform-set
Transform set default: { esp-aes esp-sha-hmac  } 
   will negotiate = { Transport,  }, 
   
Transform set ESP: { esp-aes esp-sha-hmac } will negotiate = { Transport, }, 

SPOKE1#show crypto ipsec transform-set
Transform set default: { esp-aes esp-sha-hmac  } 
   will negotiate = { Transport,  }, 
   
Transform set ESP: { esp-aes esp-sha512-hmac } will negotiate = { Tunnel, },

---

ISAKMP-verkeersfiltering controleren

Het volgende voorbeeld toont het flapperen van de VPN-tunnel:

HUB#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
172.17.0.1      172.17.2.1      QM_IDLE           1042 ACTIVE
172.17.0.1      172.17.2.1      MM_NO_STATE       1040 ACTIVE (deleted)
172.17.0.1      172.17.1.1      QM_IDLE           1041 ACTIVE
172.17.0.1      172.17.1.1      MM_NO_STATE       1039 ACTIVE (deleted)

---

Voer de foutopsporingsopdracht crypto isakmp uit om te controleren of de gesproken router UDP 500-pakket verzendt:

SPOKE1#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

---

De vorige debug-uitvoer toont dat de spaakrouter het UDP 500-pakket elke 10 seconden verzendt.

Neem contact op met de ISP om te controleren of de spaakrouter rechtstreeks is aangesloten en zorg ervoor dat ze UDP 500-verkeer toestaan.

Nadat de ISP UDP 500 heeft toegestaan, kunt u een EPC gebruiken of een inkomende ACL toevoegen aan de hubrouter in de interface van de ISP. Om ervoor te zorgen dat UDP 500-verkeer de router binnenkomt, voert u de opdracht IP-toegangslijst tonen uit om te controleren of het aantal treffers toeneemt:

HUB#show ip access-lists 
Extended IP access list 101
    10 permit udp host 172.17.1.1 host 172.17.0.1 eq isakmp log (23 matches)
    20 permit udp host 172.17.2.1 host 172.17.0.1 eq isakmp log (21 matches)
    30 permit ip any any (350 matches)

De werking van de GRE-tunnel controleren

Wanneer DMVPN niet goed werkt, kan een probleemoplossingsscenario worden gebruikt om te controleren of de GRE-tunnels correct werken zonder IPsec-codering voordat problemen met IPsec worden opgelost.

---

Voordat u de tunnelbeveiliging verwijdert, slaat u de huidige tunnelconfiguratie (aan beide zijden van de tunnel) op door de opdracht show running-config interface Tunnel<interface-nummer> uit te voeren en de gebruikte IPsec-profielnaam te bevestigen:

HUB#show running-config interface tunnel0
Building configuration...

Current configuration : 332 bytes
!
interface Tunnel0
 ip address 10.0.0.1 255.255.255.0
 no ip redirects
 ip mtu 1400
 no ip split-horizon eigrp 100
 ip nhrp authentication CISCO
 ip nhrp network-id 100
 ip nhrp redirect
 ip tcp adjust-mss 1360
 tunnel source GigabitEthernet1
 tunnel mode gre multipoint
 tunnel key 100
 tunnel protection ipsec profile DMVPN
end

---

Aanbevolen validaties:

• Bevestig dat de tunnelinterface in de staat Up/Up is door de opdracht Show interface Tunnel<interface-number> uit te voeren.
• Ping het IP-adres van de externe tunnel
• Bevestig dat de spaken zijn geregistreerd bij de hub waarop de opdracht show ip nhrp wordt uitgevoerd.
• Valideer de hub ziet alle spaken en de peer state is UP met de opdracht show dmvpn.

---

Het tijdelijk verwijderen van tunnelbeveiliging kan helpen bij het isoleren of het probleem verband houdt met GRE/NHRP/routing of met IPsec-codering. Als GRE werkt zonder IPsec-bescherming, zijn het onderliggende pad en de tunnellogica waarschijnlijk functioneel en is het probleem waarschijnlijk gerelateerd aan IKE / IPsec-onderhandeling, transformatiesets, profielen, sleutels of gecodeerde verkeersfiltering. Om deze test geldig te laten zijn, moet tunnelbescherming worden verwijderd aan beide uiteinden van het DMVPN-pad dat wordt getest, inclusief de hub en de spaaktunnelinterface.

---

NHRP-registratie controleren

De VPN-tunnel tussen hub en spoke is omhoog, maar kan geen dataverkeer passeren:

SPOKE1#show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
172.17.0.1      172.17.1.1      QM_IDLE           1039 ACTIVE

SPOKE1#show crypto ipsec sa         

interface: Tunnel0
    Crypto map tag: Tunnel0-head-0, local addr 172.17.1.1

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (172.17.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 port 500
     PERMIT, flags={origin_is_acl,}
 #pkts encaps: 5, #pkts encrypt: 5, #pkts digest: 5 #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0

     local crypto endpt.: 172.17.1.1, remote crypto endpt.: 172.17.0.1
     plaintext mtu 1458, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet1
     current outbound spi: 0x9436DE5(155413989)
     PFS (Y/N): N, DH group: none

     inbound esp sas:
      spi: 0xA408C808(2752038920)

---

De uitvoer toont dat versleuteld verkeer wordt verzonden, maar retourverkeer wordt niet ontvangen van het andere uiteinde van de tunnel. Controleer de NHS-vermelding op de spaakrouter.

In dit voorbeeld is het NHS-registratieverzoek mislukt. Om het probleem op te lossen, controleert u of de spaaktunnelinterface het juiste IP-adres van de hubtunnel gebruikt als de NHS en het juiste NBMA-adres in de NHRP-kaart:

SPOKE1#show ip nhrp nhs detail 
Legend: E=Expecting replies, R=Responding, W=Waiting, D=Dynamic
Tunnel0:
172.17.0.1   E priority = 0 cluster = 0  req-sent 0  req-failed 23  repl-recv 0 


Pending Registration Requests:
Registration Request: Reqid 110, Ret 64  NHS 172.17.0.1 expired (Tu0)

---

De reden voor de storing was de spaakconfiguratie in het IP-adres van de NHS-server die naar de hub NBMA of het fysieke adres in plaats van het IP-adres van de hub-tunnel wees. De opdracht ip nhrp nhs op een spaak moet verwijzen naar het IP-adres van de hub DMVPN-tunnelinterface. Het configureren van de NHS met het hub NBMA-adres in plaats van het tunneladres voorkomt een succesvolle NHRP-registratie.

---

In DMVPN identificeert het uitvoeren van de opdracht ip nhrp nhs de NHRP Next Hop Server aan de hand van het IP-adres van de tunnel. De opdracht ip nhrp map wordt vervolgens gebruikt om dat IP-adres van de hubtunnel toe te wijzen aan het hub NBMA-adres, dat het bereikbare onderliggende of fysieke adres is:

SPOKE1#show running-config interface tunnel0
Building configuration...

Current configuration : 374 bytes
!
interface Tunnel0
 ip address 10.0.0.5 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip nhrp authentication CISCO
 ip nhrp map 10.0.0.1 172.17.0.1
 ip nhrp map multicast 172.17.0.1
 ip nhrp network-id 100
 ip nhrp nhs 172.17.0.1
 ip tcp adjust-mss 1360
 tunnel source GigabitEthernet1
 tunnel mode gre multipoint
 tunnel key 100
 tunnel protection ipsec profile DMVPN
end

---

De volgende uitvoer geeft het configuratievoorbeeld weer met de gecorrigeerde invoer voor de NHS-server:

SPOKE1#show running-config interface tunnel0
Building configuration...

Current configuration : 372 bytes
!
interface Tunnel0
 ip address 10.0.0.5 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip nhrp authentication CISCO
 ip nhrp map 10.0.0.1 172.17.0.1
 ip nhrp map multicast 172.17.0.1
 ip nhrp network-id 100
 ip nhrp nhs 10.0.0.1
 ip tcp adjust-mss 1360
 tunnel source GigabitEthernet1
 tunnel mode gre multipoint
 tunnel key 100
 tunnel protection ipsec profile DMVPN
end

---

Controleer nu de NHS-invoer en IPsec-codeer- / decoderingstellers:

SPOKE1#show ip nhrp nhs detail 
Legend: E=Expecting replies, R=Responding, W=Waiting, D=Dynamic
Tunnel0:
10.0.0.1  RE  priority = 0 cluster = 0  req-sent 4 req-failed 0 repl-recv 4 (00:01:08 ago)

SPOKE1#show crypto ipsec sa

interface: Tunnel0
    Crypto map tag: Tunnel0-head-0, local addr 172.17.1.1

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (172.17.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 port 500
     PERMIT, flags={origin_is_acl,}
 #pkts encaps: 231, #pkts encrypt: 231, #pkts digest: 231 #pkts decaps: 136, #pkts decrypt: 136, #pkts verify: 136
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0

     local crypto endpt.: 172.17.1.1, remote crypto endpt.: 172.17.0.1
     plaintext mtu 1458, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet1
     current outbound spi: 0xA2D1748A(2731635850)
     PFS (Y/N): N, DH group: none

     inbound esp sas:
      spi: 0x88246F16(2284089110)

---

Levensduur van de beveiligingsassociatie controleren

Voer deze opdrachten uit om de huidige levensduur van de IKE/IPsec Security Association (SA) en de resterende tijd voor de volgende heronderhandeling te verifiëren:

• Crypto ISAMPO-beleid weergeven

• Crypto ISKAMP SA-details weergeven
• Crypto IPSec Security-Association Lifetime weergeven

• Crypto IPSec SA weergeven

• Crypto IPSEC SA peer <peer-NBMA-adres> weergeven

---

De gebruikelijke standaardwaarden voor de SA-levensduur zijn 24 uur (86400 seconden) voor IKEv1/ISAKMP SA's en 1 uur (3600 seconden) voor IPsec SA's. Controleer echter altijd de geconfigureerde en overeengekomen levensduurwaarden op beide peers.

---

Controleer de resterende waarden voor de levensduur in de opdrachtuitvoer. Als de resterende levensduur dicht bij de geconfigureerde levensduur ligt, is onlangs onderhandeld over de SA. Dit kan normaal zijn nadat de tunnel voor het eerst omhoog komt of na een geplande sleutel. Om te bepalen of het gedrag normaal is of dat de tunnel stuitert, controleert u de SA-toestand en de levensduurwaarden in de loop van de tijd.

---

Verwacht gedrag toont meestal:

• De resterende levensduur neemt in de loop van de tijd af.
• De SA's komen in de buurt van de verwachte levensduur.
• Pakkettellers blijven stijgen voor en na het opnieuw invoeren.
• In de logboeken worden geen herhaalde berichten weergegeven voor Tunnel Down/Up.

---

Mogelijk stuiteren of herhaaldelijk falen kan laten zien:

• De SA-levensduur wordt herhaaldelijk teruggezet naar de volledige geconfigureerde waarde vóór de verwachte rekeytijd.
• De IKE of IPsec SA verdwijnt en wordt regelmatig opnieuw gemaakt.
• Toon crypto isakmp sa verandert herhaaldelijk de staat of keert terug naar onderhandelingsstaten.
• De IPsec-inkapseling en -decapsulatietellers nemen niet meer toe tijdens het evenement.
• Syslog-berichten tonen herhaalde IKE/IPsec-onderhandelingsfouten, verwijderingen of herverificatiegebeurtenissen.

SPOKE1#show crypto isakmp policy

Global IKE policy
Protection suite of priority 10
        encryption algorithm:   AES - Advanced Encryption Standard (128 bit keys).
        hash algorithm:         Secure Hash Standard
        authentication method:  Pre-Shared Key
        Diffie-Hellman group:   #14 (2048 bit)
        lifetime: 86400 seconds, no volume limit

SPOKE1#show crypto isakmp sa detail
Codes: C - IKE configuration mode, D - Dead Peer Detection
       K - Keepalives, N - NAT-traversal
       T - cTCP encapsulation, X - IKE Extended Authentication
       psk - Preshared key, rsig - RSA signature
       renc - RSA encryption
IPv4 Crypto ISAKMP SA

C-id  Local           Remote          I-VRF  Status Encr Hash   Auth DH Lifetime Cap.

1044  172.17.1.1      172.17.0.1                                       ACTIVE aes  sha    psk  14 23:57:09     
       Engine-id:Conn-id =  SW:44

IPv6 Crypto ISAKMP SA

SPOKE1#show crypto ipsec security-association lifetime
Security association lifetime: 4608000 kilobytes/3600 seconds
Multi SNS : Disabled 

SPOKE1#show crypto ipsec sa | i sa timing|ident|inbound esp|outbound esp 
   local  ident (addr/mask/prot/port): (172.17.1.1/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (172.17.0.1/255.255.255.255/47/0)
     inbound esp sas:
         sa timing: remaining key lifetime (k/sec): (4607994/3422)
     outbound esp sas:
         sa timing: remaining key lifetime (k/sec): (4607996/3422)

---

Eenrichtings-IPsec-verkeer verifiëren

Als de VPN-tunnel tussen een spraakgestuurde router is ingeschakeld, maar geen dataverkeer kan doorgeven. Gebruik de IPsec-tellers om de falende richting te identificeren:

• Als encaps/encrypt toeneemt maar decaps/decrypt niet toenemen, verstuurt de router versleuteld verkeer maar ontvangt geen geldig IPsec-retourverkeer.
• Als decaps / decrypt toeneemt, ontvangt en decodeert de router IPsec-verkeer.
• Vergelijk beide spaken om te bepalen welke richting faalt.

---

SPOKE1#show crypto ipsec sa peer 172.17.2.1

interface: Tunnel0
    Crypto map tag: Tunnel0-head-0, local addr 172.17.1.1

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (172.17.1.1/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (172.17.2.1/255.255.255.255/47/0)
   current_peer 172.17.2.1 port 500
     PERMIT, flags={origin_is_acl,}
 #pkts encaps: 6, #pkts encrypt: 6, #pkts digest: 6 #pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0

     local crypto endpt.: 172.17.1.1, remote crypto endpt.: 172.17.2.1
     plaintext mtu 1458, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet1
     current outbound spi: 0x140FA971(336570737)
     PFS (Y/N): N, DH group: none

SPOKE2#show crypto ipsec sa peer 172.17.1.1

interface: Tunnel0
    Crypto map tag: Tunnel0-head-0, local addr 172.17.2.1

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (172.17.2.1/255.255.255.255/47/0)
   remote ident (addr/mask/prot/port): (172.17.1.1/255.255.255.255/47/0)
   current_peer 172.17.1.1 port 500
     PERMIT, flags={origin_is_acl,}
 #pkts encaps: 11, #pkts encrypt: 11, #pkts digest: 11 #pkts decaps: 6, #pkts decrypt: 6, #pkts verify: 6
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0

     local crypto endpt.: 172.17.2.1, remote crypto endpt.: 172.17.1.1
     plaintext mtu 1458, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet1
     current outbound spi: 0x931B398E(2468034958)
     PFS (Y/N): N, DH group: none

---

Controleren van routeringsprotocolconfiguratie en -aansluitingen

Het routeringsgedrag van DMVPN is afhankelijk van de DMVPN-fase en het routeringsprotocol dat over de tunnel loopt. Het routeringsontwerp bepaalt of gesproken verkeer een directe dynamische tunnel kan vormen of dat het de hub blijft doorkruisen.

Als gevolg hiervan verschillen de routeringsaanbevelingen tussen DMVPN Fase 2 en DMVPN Fase 3. Een configuratie die geschikt is voor fase 2 kan het beoogde routeringsgedrag in fase 3 voorkomen. Hoewel een fase 3-implementatie standaard routering en routebeschrijving-samenvatting op de hubontwerpen kan ondersteunen, zijn deze over het algemeen niet geschikt voor fase 2.

---

DMVPN fase 2-routeringsgedrag

In fase 2 van DMVPN zijn gesproken tunnels sterk afhankelijk van de routeringstafel. Om directe spraak-tot-spraakcommunicatie te laten werken, moet elke spaak op afstand gesproken netwerken leren met het IP-adres van de externe spaaktunnel als de volgende stap.

---

Voorbeeld:

• Routes die worden geadverteerd vanaf een spaak moeten dat gesproken Tunnel IP-adres behouden als de volgende hop.
• Andere spaken moeten die routes ontvangen met het oorspronkelijke gesproken Tunnel IP-adres als de volgende hop.
• De hub mag de volgende hop niet herschrijven naar zijn eigen Tunnel IP-adres voor routes die zijn geleerd van spaken.

---

Door het remote spoke Tunnel IP-adres als de volgende hop te behouden, kan de spoke die Tunnel IP oplossen naar het bijbehorende NBMA-adres via NHRP en een directe spraak-naar-spraak-tunnel tot stand brengen. Spoke-to-spoke-connectiviteit is afhankelijk van het routeringsprotocol waarbij de oorspronkelijke spaak als de volgende hop wordt behouden (bijvoorbeeld in het geval van EIGRP door het commando no ip next-hop-self eigrp uit te voeren).

---

Essentiële vereisten voor fase 2

• NHRP is vereist voor spaakregistratie naar de hub.
• mGRE wordt gebruikt op de hub en spaken.
• NHRP is vereist voor gesproken resolutie.
• Spoke-to-spoke tunnels worden geïnitieerd door de oorspronkelijke spreker op basis van de routeringstabel naast de hop.
• De hub moet de oorspronkelijke spaakvolgende hop behouden voor spaakroutes op afstand.
• Samenvatting of standaardroutering van de hub naar de spaken is over het algemeen niet geschikt omdat de hub daardoor in het gegevenspad blijft.

---

EIGRP-overwegingen voor fase 2

Op de hub-tunnelinterface vereist EIGRP gewoonlijk:

HUB(config)#interface tunnel
HUB(config-if)#no ip next-hop-self eigrp 
HUB(config-if)#no ip split-horizon eigrp 

---

Met deze opdrachten kan de hub spaakroutes naar andere spaken adverteren zonder de volgende hop naar zichzelf te veranderen.

Vermijd het samenvatten van spaakroutes op de hub in een fase 2-ontwerp. Als de hub een samenvatting of standaardroute voor spaaknetwerken adverteert, wijzen de spaken naar de hub als de volgende hop, die het doel van fase 2 spraakgestuurd doorsturen verslaat.

---

OSPF-overwegingen voor fase 2

Voor OSPF over DMVPN Fase 2 moet het OSPF-netwerktype hub-and-spoke nabijheid ondersteunen met behoud van correct doorstuurgedrag.

Een gemeenschappelijk ontwerp is om het type OSPF-uitzendnetwerk op de tunnel te gebruiken voor zowel hub als spaken:

Router(config)#interface tunnel
Router(config-if)#ip ospf network broadcast

---

Configureer de spaken met OSPF-prioriteit 0 zodat ze niet de DR worden:

SPOKE(config)#interface tunnel
SPOKE(config-if)#ip ospf priority 0

Dit helpt ervoor te zorgen dat de hub de controle over de routeringsnabijheid behoudt, terwijl het routeringsontwerp nog steeds spraakgestuurd doorsturen ondersteunt.

---

DMVPN fase 3-routeringsgedrag

DMVPN fase 3 vereenvoudigt routering in vergelijking met fase 2. In fase 3 kunnen spaken naar de hub wijzen als de volgende stap voor externe netwerken, inclusief netwerken achter andere spaken. Hierdoor kan de hub samenvattende routes of standaardroutes naar de spaken adverteren.

Wanneer een spaak verkeer naar een andere spaak stuurt via de hub, stuurt de hub het eerste pakket door en stuurt een NHRP-omleidingsbericht terug naar de verzendende spaak. De redirect vertelt de spreker dat er een beter pad bestaat. De spreker stuurt vervolgens een NHRP-resolutieverzoek om het op afstand gesproken NBMA-adres te ontdekken en bouwt een directe spraak-naar-spraak-tunnel. Met andere woorden, fase 3 maakt vereenvoudigde routering mogelijk, terwijl het nog steeds mogelijk is om gesproken tunnels te gebruiken via NHRP-omleiding en sneltoetsgedrag.

---

Essentiële vereisten voor fase 3

• NHRP is vereist voor spaakregistratie naar de hub.
• mGRE wordt gebruikt op de hub en spaken.
• NHRP wordt gebruikt voor gesproken resolutie.
• De hub kan de routing volgende hop blijven.
• Ondersteunt het gebruik van routesamenvatting en standaardroutering op de hub.
• Spoke-to-spoke tunnels worden geïnitieerd nadat de Hub een NHRP-omleiding verzendt die aangeeft dat er een beter pad bestaat.
• Spokes gebruiken NHRP Shortcut om geoptimaliseerde forwarding-items naar externe spokes te installeren.

---

NHRP Shortcut en Redirect Vereisten

Schakel op de hub-tunnelinterface NHRP-omleiding in:

HUB(config)#interface tunnel
HUB(config-if)#ip nhrp redirect

---

Schakel op elke spaaktunnelinterface de NHRP-snelkoppeling in:

SPOKE(config)#interface tunnel
SPOKE(config-if)#ip nhrp shortcut

---

De hub gebruikt NHRP Redirect om de spreker op de hoogte te stellen van een beter pad, en de spoke gebruikt NHRP Shortcut om het geoptimaliseerde spraakgestuurde doorstuurpad te installeren.

---

EIGRP-overwegingen voor fase 3

Voor EIGRP in een fase 3-ontwerp kan de hub samenvattende routes of standaardroutes naar de spaken adverteren. In tegenstelling tot fase 2 hoeft de hub de oorspronkelijke spaak niet te behouden naast de hop.

---

Op de interface van de naaftunnel:

• Houd geen ip-gesplitste horizonteligram <as-nummer> zodat de hub routes kan adverteren die zijn geleerd van de ene spreker naar de andere spreker.
• Verwijder geen ip next-hop-self-eigrp <as-number> om de hub in staat te stellen de volgende hop te blijven routeren, wat het verwachte gedrag is in DMVPN Fase 3.
• Configureer de routebeschrijving die u nodig hebt om de routering te vereenvoudigen en de grootte van de routeringstabel te verkleinen.

---

OSPF-overwegingen voor fase 3

Voor OSPF in DMVPN fase 3 wordt het point-to-multipoint netwerktype gewoonlijk geconfigureerd op zowel de Hub als de spaken waarop de ip ospf network point-to-multipoint command wordt uitgevoerd. Dit netwerktype modelleert de hub als meerdere point-to-point buurrelaties, vermijdt DR / BDR-verkiezingen en sluit goed aan bij de fase 3-architectuur. Dit is waar OSPF adverteert routes door de hub, terwijl NHRP Redirects en Shortcuts dynamisch optimaliseren sprak-naar-spraak doorsturen. Dit netwerktype maakt het ook mogelijk om OSPF-prioriteit te verwijderen met de opdracht geen ip ospf-prioriteit.

---

Als spaken geen routeringsprotocol-buurrelatie met de hub kunnen vaststellen, controleert u of de NHRP-multicasttoewijzing correct is geconfigureerd op de hub-tunnelinterface.

Dynamische routeringsprotocollen zoals EIGRP en OSPF gebruiken multicast-pakketten om buren te ontdekken en te onderhouden. In een DMVPN-netwerk dat gebruikmaakt van multipoint GRE en IPsec, moet de hub multicast-verkeer dynamisch toewijzen aan geregistreerde spaken. Zonder de juiste multicast-toewijzing kan de hub niet correct routeringsprotocol multicast-pakketten doorsturen, wat kan voorkomen dat routeringsadjacencies zich vormen of ervoor zorgen dat ze flapperen.

HUB#show ip eigrp neighbors 
EIGRP-IPv4 Neighbors for AS(100)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                                   (sec)         (ms)       Cnt Num
1   10.0.0.9                Tu0                      13 00:00:24    1  5000  1  0
0   10.0.0.5                Tu0                      12 00:00:24    1  5000  1  0
HUB#
*Jul 17 01:17:42.102: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.0.0.5 (Tunnel0) is down: retry limit exceeded *Jul 17 01:17:42.380: %DUAL-5-NBRCHANGE: EIGRP-IPv4 100: Neighbor 10.0.0.9 (Tunnel0) is down: retry limit exceeded
HUB#

HUB#show ip route eigrp 
Codes: L - local, 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, m - OMP
       n - NAT, Ni - NAT inside, No - NAT outside, Nd - NAT DIA
       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
       H - NHRP, G - NHRP registered, g - NHRP registration summary
       o - ODR, P - periodic downloaded static route, l - LISP
       a - application route
       + - replicated route, % - next hop override, p - overrides from PfR
       & - replicated local route overrides by connected

Gateway of last resort is 172.17.0.2 to network 0.0.0.0

HUB#

---

Controleer als eerste stap of NHRP multicast mapping ip nhrp map multicast dynamic is geconfigureerd in de hub tunnel interface.

---

Als de opdracht this ontbreekt, configureert u deze als in het volgende voorbeeld:

HUB(config)#interface tunnel0
HUB(config-if)#ip nhrp map multicast dynamic

---

Zodra de hub de gesproken NHRP-registraties leert en dynamisch multicast-mappings maakt, kunnen de routeringsprotocolburen met succes vaststellen en worden routes naar de spaken geleerd:

HUB#show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(100)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                                   (sec)         (ms)       Cnt Num
1   10.0.0.5                Tu0                      12 00:00:17   19  1362  0  46
0   10.0.0.9                Tu0                      12 00:00:17    9  1362  0  39

HUB#show ip route eigrp
Codes: L - local, 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, m - OMP
       n - NAT, Ni - NAT inside, No - NAT outside, Nd - NAT DIA
       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
       H - NHRP, G - NHRP registered, g - NHRP registration summary
       o - ODR, P - periodic downloaded static route, l - LISP
       a - application route
       + - replicated route, % - next hop override, p - overrides from PfR
       & - replicated local route overrides by connected

Gateway of last resort is 172.17.0.2 to network 0.0.0.0

D 192.168.2.0/24 [90/27008000] via 10.0.0.5, 00:08:04, Tunnel0 D 192.168.11.0/24 [90/27008000] via 10.0.0.9, 00:08:05, Tunnel0

---

Wanneer routeringsprotocolburen zich niet vormen, controleert u het volgende:

• De opdracht ip nhrp map multicast dynamic is geconfigureerd onder de hub tunnel interface.
• Het routeringsprotocol is ingeschakeld op de tunnelinterface.
• De hello-pakketten van het routeringsprotocol worden niet geblokkeerd door ACL's of firewallbeleid.
• De tunnelinterfaces zijn omhoog/omhoog.
• IPsec SA's worden vastgesteld en pakkettellers nemen toe.
• De spaakconfiguratie bevat de juiste multicast-toewijzing naar de hub, zoals de opdracht ip nhrp map multicast <hub-nbma-adres>.

---

MTU-, MSS- en fragmentatieproblemen controleren

In scenario's waarin gebruikers het DMVPN-netwerk kunnen bereiken, maar toegang tot een server via de DMVPN-tunnel mislukt of zich inconsistent gedraagt. Aanmelden bij een server mislukt bijvoorbeeld, toepassingssessies worden opgehangen of bestandsoverdrachten worden niet voltooid.

---

Dit type probleem kan gerelateerd zijn aan MTU, MSS of fragmentatie omdat DMVPN-verkeer GRE- en IPsec-overhead toevoegt aan het oorspronkelijke pakket. Als het resulterende pakket groter is dan het ondersteunde pad MTU, kunnen pakketten worden gefragmenteerd of in het onderliggende netwerk worden gedropt.

---

Enkele van de meest voorkomende symptomen van MTU of MSS problemen zijn:

• Ping werkt, maar TCP-toepassingen werken niet.
• Kleine pakketten gaan voorbij, maar grote pakketten mislukken.
• De aanmelding bij de server wordt gestart, maar blijft hangen of loopt uit.
• Bestandsoverdrachten mislukken of lopen vast.
• Web-, Secure Shell- (SSH), Remote Desktop Protocol- (RDP) of databasesessies maken verbinding, maar geven gegevens niet op betrouwbare wijze door.
• Het probleem heeft betrekking op sommige toepassingen, maar niet op andere.
• Het probleem is duidelijker zichtbaar wanneer de DF-bit is ingesteld en fragmentatie niet is toegestaan.

---

Controleer eerst of het DMVPN-besturingsvlak stabiel is en controleer vervolgens of grote pakketten door de tunnel mislukken. Gebruik uitgebreide ping met de DF-bitset en varieer de pakketgrootte ping <remote-server-ip> grootte <packet-size> df-bitbron <interface|adres>. Test vanaf één DMVPN-eindpunt of LAN-subnet naar het externe server- of tunneleindpunt. Begin met een kleinere pakketgrootte en verhoog deze geleidelijk. Als kleinere pakketten succesvol zijn, maar grotere pakketten mislukken, kan het pad een MTU- of fragmentatieprobleem hebben.

---

Om fragmentatie voor TCP-verkeer te verminderen, configureert u de tunnelinterface met een lagere MTU en past u de TCP MSS aan.

Router#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#interface tunnel0
Router(config-if)#ip mtu 1400
Router(config-if)#ip tcp adjust-mss 1360

De opdracht ip mtu 1400 verlaagt de tunnelinterface MTU om rekening te houden met GRE- en IPsec-overhead en de opdracht ip tcp adjust-mss 1360 past de TCP MSS-waarde aan voor TCP-sessies die door de tunnel lopen, waardoor wordt voorkomen dat eindpunten TCP-segmenten verzenden die te groot zijn voor het pad.

Indien nodig kan IPsec-fragmentatie ook wereldwijd worden geconfigureerd met de opdracht crypto ipsec fragmentatie na codering. U kunt ook de opdracht tunnelpad-mtu-discovery configureren om de MTU-grootte dynamisch te detecteren.

---

---

Gerelateerde informatie

• Dynamic Multipoint VPN (DMVPN)
• IPsec-onderhandeling/IKE-protocollen

• Naslaggids voor Cisco VPN Technologies

   
• Cisco Technical Support en downloads

Revisiegeschiedenis

Revisie	Publicatiedatum	Opmerkingen
4.0	20-Jul-2026	Bijgewerkte spelling, grammatica, spatiëring, ingevoegde horizontale lijnen om secties te scheiden voor leesbaarheid.
3.0	29-Aug-2024	Gecorrigeerde koppelingen, gecorrigeerde CCW-waarschuwingen, hercertificering, hoofdletter.
2.0	24-Mar-2023	Gecorrigeerde koppelingen, gecorrigeerde CCW-waarschuwingen. Hercertificering.
1.0	27-Apr-2010	Eerste vrijgave