DMVPN Phase 1 Debugs Troubleshoot Guide
Available Languages
Contents
Introduction
This document describes the debug messages you would encounter on the hub and spoke of a Dynamic Multipoint Virtual Private Network (DMVPN) Phase 1 deployment.
Prerequisites
For the configuration and debug commands in this document, you will need two Cisco routers which run Cisco IOS® Release 12.4(9)T or later. In general, a basic DMVPN Phase 1 requires Cisco IOS Release 12.2(13)T or later or Release 12.2(33)XNC for the Aggregation Services Router (ASR), although the features and debugs seen in this document might not be supported.
Requirements
Cisco recommends that you have knowledge of these topics:
- Generic Routing Encapsulation (GRE)
- Next Hop Resolution Protocol (NHRP)
- Internet Security Association and Key Management Protocol (ISAKMP)
- Internet Key Exchange (IKE)
- Internet Protocol Security (IPSec)
- At least one of these routing protocols: Enhanced Interior Gateway Routing Protocol (EIGRP), Open Shortest Path First (OSPF), Routing Information Protocol (RIP), and Border Gateway Protocol (BGP)
Components Used
The information in this document is based on Cisco 2911 Integrated Services Routers (ISRs) which run Cisco IOS Release 15.1(4)M4.
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.
Significant Enhancements
These Cisco IOS versions introduced significant features or fixes for DMVPN Phase 1:
- Release 12.2(18)SXF5 - better support for ISAKMP when using Public Key Infrastructure (PKI)
- Release 12.2(33)XNE - ASR, IPSec Profiles, Tunnel Protection, IPSec Network Address Translation (NAT) Traversal
- Release 12.3(7)T - inside Virtual Routing and Forwarding (iVRF) support
- Release 12.3(11)T - front-door Virtual Routing and Forwarding (fVRF) support
- Release 12.4(9)T - support for various DMVPN related debugs and commands
- Release 12.4(15)T - Shared Tunnel Protection
- Release 12.4(20)T - IPv6 over DMVPN
- Release 15.0(1)M - NHRP Tunnel Health Monitoring
Conventions
Refer to Cisco Technical Tips Conventions for information on document conventions.
Relevant Configuration
Topology Overview
For this topology, two 2911 ISRs which run Release 15.1(4)M4 were configured for DMVPN Phase 1: one as a hub and one as a spoke. Ethernet0/0 was used as the "internet" interface on each router. The four loopback interfaces are configured to simulate local area networks that live at the hub or spoke site. As this is a DMVPN Phase 1 topology with only one spoke, the spoke is configured with a point-to-point GRE tunnel rather than a multipoint GRE tunnel. The same crypto configuraton (ISAKMP and IPSec) was used on each router to ensure they matched exactly.
Diagram 1
Crypto
This is the same on the hub and the spoke.
crypto isakmp policy 1
encr 3des
hash sha
authentication pre-share
crypto isakmp key cisco123 address 0.0.0.0 0.0.0.0
crypto ipsec transform-set DMVPN-TSET esp-3des esp-sha-hmac
mode transport
crypto ipsec profile DMVPN-IPSEC
set transform-set DMVPN-TSET
Hub
interface Tunnel0
ip address 10.1.1.254 255.255.255.0
no ip redirects
ip mtu 1400
ip nhrp authentication NHRPAUTH
ip nhrp map multicast dynamic
ip nhrp network-id 1
ip tcp adjust-mss 1360
no ip split-horizon eigrp 1
tunnel source Ethernet0/0
tunnel mode gre multipoint
tunnel key 1
tunnel protection ipsec profile DMVPN-IPSEC
end
interface Ethernet0/0
ip address 172.16.10.1 255.255.255.0
end
interface Loopback0
ip address 203.0.113.1 255.255.255.255
interface Loopback1
ip address 203.0.113.2 255.255.255.255
interface Loopback2
ip address 203.0.113.3 255.255.255.255
interface Loopback3
ip address 203.0.113.4 255.255.255.255
router eigrp 1
network 10.1.1.0 0.0.0.255
network 203.0.113.1 0.0.0.0
network 203.0.113.2 0.0.0.0
network 203.0.113.3 0.0.0.0
network 203.0.113.4 0.0.0.0
Spoke
interface Tunnel0
ip address 10.1.1.1 255.255.255.0
ip mtu 1400
ip nhrp authentication NHRPAUTH
ip nhrp map 10.1.1.254 172.16.10.1
ip nhrp network-id 1
ip nhrp nhs 10.1.1.254
ip tcp adjust-mss 1360
tunnel source Ethernet0/0
tunnel destination 172.16.10.1
tunnel key 1
tunnel protection ipsec profile DMVPN-IPSEC
end
interface Ethernet0/0
ip address 172.16.1.1 255.255.255.0
end
interface Loopback0
ip address 209.165.201.1 255.255.255.255
interface Loopback1
ip address 209.165.201.2 255.255.255.255
interface Loopback2
ip address 209.165.201.3 255.255.255.255
interface Loopback3
ip address 209.165.201.4 255.255.255.255
router eigrp 1
network 209.165.201.1 0.0.0.0
network 209.165.201.2 0.0.0.0
network 209.165.201.3 0.0.0.0
network 209.165.201.4 0.0.0.0
network 10.1.1.0 0.0.0.255
Debugs
Packet Flow Visualization
This is a visualization of the entire DMVPN packet flow as seen in this document. More detailed debugs that explain each of the steps are also included.
- When the Tunnel on the Spoke is “no shutdown” it generates a NHRP Registration Request, which starts the DMVPN process. As the Hub’s configuration is completely dynamic, the Spoke must be the endpoint which initiates the connection.
- The NHRP Registration Request is then encapsulated in GRE which triggers the crypto process to start.
- At this point, the first ISAKMP Main Mode message – ISAKMP MM1 – is sent from the Spoke to the Hub on port UDP500.
- The Hub receives and processes MM1 and responds with ISAKMP MM2, as it has a matching ISAKMP policy.
Diagram 2 - refers to steps 1 to 4
- Once the Spoke receives the MM2, it responds with MM3. As with MM1, the Spoke confirms the received ISAKMP policy is valid.
- The Hub receives MM3 and responds with MM4.
- At this point in the ISAKMP negotiation, the Spoke might respond on port UDP4500 if NAT is detected in the transit path. However, if no NAT is detected the Spoke continues and sends MM5 on UDP500. Lastly, the Hub responds with MM6 in order to complete the Main Mode exchange.
Diagram 3 - refers to steps 5 to 7
- Once the Spoke receives MM6 from the Hub, it sends QM1 to the Hub on UDP500 in order to begin Quick Mode.
- The Hub receives QM1 and responds with QM2, as all received attributes are accepted. At this point the Hub creates the Phase 2 SAs for this session.
- As the last step of the Quick Mode negotiation, QM2 is received by the Spoke. The Spoke then creates its Phase 2 SAs and sends QM3 in response. This completes the ISAKMP and IPSec negotiation. There is now an IPSec session which encrypts GRE traffic between these two peers.
Diagram 4 - refers to steps 8 to 10
- Now that the crypto session is up and able to pass traffic, these packets are encapsulated within the GRE over IPSec tunnel.
Diagram 5 - refers to step 11
- As was seen in the first steps, the Spoke generates an NHRP Registration Request which is sent across the GRE over IPSec tunnel.
- The Hub receives the NHRP Registration Requests and sends an NHRP Registration Reply once it confirms the Spoke has a valid Tunnel and Nonbroadcast Multiaccess (NBMA) address. The Spoke receives this NHRP Registration Reply which completes the registration process.
Diagram 6 - refers to steps 12 to 13
These debugs are the result when the debug dmvpn all all command is entered on the hub and spoke routers. This particular command enables this set of debugs:
Spoke1#debug dmvpn all all
DMVPN all level debugging is on
Spoke1#show debug
NHRP:
NHRP protocol debugging is on
NHRP activity debugging is on
NHRP extension processing debugging is on
NHRP cache operations debugging is on
NHRP routing debugging is on
NHRP rate limiting debugging is on
NHRP errors debugging is on
IKEV2:
IKEV2 error debugging is on
IKEV2 terse debugging is on
IKEV2 event debugging is on
IKEV2 packet debugging is on
IKEV2 detail debugging is on
Cryptographic Subsystem:
Crypto ISAKMP debugging is on
Crypto ISAKMP Error debugging is on
Crypto IPSEC debugging is on
Crypto IPSEC Error debugging is on
Crypto secure socket events debugging is on
Tunnel Protection Debugs:
Generic Tunnel Protection debugging is on
DMVPN:
DMVPN error debugging is on
DMVPN UP/DOWN event debugging is on
DMVPN detail debugging is on
DMVPN packet debugging is on
DMVPN all level debugging is on
Debugs with Explanation
As this is a configuraton where IPSec is implemented, the debugs show all of the ISAKMP and IPSec debugs. If no crypto is configured, ignore any debugs that start with "IPsec" or "ISAKMP."
|
HUB DEBUG EXPLANATION |
DEBUGS IN SEQUENCE |
SPOKE DEBUG EXPLANATION |
|
These first few debug messages are generated by a no shutdown command entered on the tunnel interface. Messages are generated by crypto, GRE, and NHRP services being initiated. An NHRP registration error is seen on hub because it does not have a Next Hop Server (NHS) configured (the hub is the NHS for our DMVPN cloud). This is expected. |
IPSEC-IFC MGRE/Tu0: Checking tunnel status. |
|
|
IPSEC-IFC GRE/Tu0: Checking tunnel status. |
These first few debug messages are generated by a no shutdown command entered on the tunnel interface. Messages are generated by crypto, GRE, and NHRP services that are initiated. Additionally, the spoke adds an entry to its own NHRP cache for its own NBMA and tunnel address. |
|
|
START OF ISAKMP (PHASE I) NEGOTIATION |
||
|
IPSEC(recalculate_mtu): reset sadb_root 94EFDC0 mtu to 1500 |
The first step once the tunnel is “no shutdown” is to start the crypto negotiation. Here the spoke creates an SA request, attempts to start Aggressive Mode and fails back to Main Mode. Since Aggressive Mode is not configured on either router, this is expected. The spoke begins Main Mode and sends the first ISAKMP message, MM_NO_STATE. ISAKMP state changes from IKE_READY to IKE_I_MM1. The NAT-T vendor ID messages are used in detection and traversal of NAT. These messages are expected during the negotiation of ISAKMP regardless of whether or not NAT is implemented. Like the Aggressive Mode messages, these are expected. |
|
|
After the spoke’s tunnel is “no shutdown,” the hub receives the IKE NEW SA (Main Mode 1) message on port 500. As the Responder, the hub creates an ISAKMP Security Association (SA). The ISAKMP state changes from IKE_READY to IKE_R_MM1. |
ISAKMP (0): received packet from 172.16.1.1 dport 500 sport 500 Global (N) NEW SA |
|
|
The received IKE Main Mode 1 message is processed. The hub determines that the peer has matching ISAKMP attributes and they are filled into the ISAKMP SA which was just created. The messages show that the peer uses 3DES-CBC for encryption, hashing of SHA, Diffie Hellman (DH) group 1, preshared key for authentication, and the default SA lifetime of 86400 seconds (0x0 0x1 0x51 0x80 = 0x15180 = 86400 seconds). The ISAKMP state is still IKE_R_MM1 since a reply has not be sent to the spoke. The NAT-T vendor ID messages are used in detection and traversal of NAT. These messages are expected during the negotiation of ISAKMP regardless of whether or not NAT is implemented. Similar messages are seen for Dead Peer Detection (DPD). |
ISAKMP:(0): processing SA payload. message ID = 0 |
|
|
MM_SA_SETUP (Main Mode 2) is sent to the spoke, which confirms that MM1 was received and accepted as a valid ISAKMP packet. ISAKMP state changes from IKE_R_MM1 to IKE_R_MM2. |
ISAKMP:(0): constructed NAT-T vendor-rfc3947 ID |
|
|
ISAKMP (0): received packet from 172.16.10.1 dport 500 sport 500 Global (I) MM_NO_STATE |
In response to the MM1 message sent to the hub, MM2 arrives which confims that MM1 was received. The received IKE Main Mode 2 message is processed. The spoke realizes that the peer hub has matching ISAKMP attributes and these attributes are filled into the ISAKMP SA that was created. This packet shows that the peer uses 3DES-CBC for encryption, hashing of SHA, Diffie Hellman (DH) group 1, preshared key for authentication, and the default SA lifetime of 86400 seconds (0x0 0x1 0x51 0x80 = 0x15180 = 86400 seconds). In addition to the NAT-T messages, there is an exchange to determine if the session will use DPD. The ISAKMP state changes from IKE_I_MM1 to IKE_I_MM2. |
|
|
ISAKMP:(0): sending packet to 172.16.10.1 my_port 500 peer_port 500 (I) MM_SA_SETUP |
MM_SA_SETUP (Main Mode 3) is sent to the hub, which confirms that the spoke received MM2 and would like to proceed. The ISAKMP state changes from IKE_I_MM2 to IKE_I_MM3. |
|
|
MM_SA_SETUP (Main Mode 3) is received by hub. The hub concludes that the peer is another Cisco IOS device and no NAT is detected for us or our peer. The ISAKMP state changes from IKE_R_MM2 to IKE_R_MM3. |
ISAKMP (0): received packet from 172.16.1.1 dport 500 sport 500 Global (R) MM_SA_SETUP |
|
|
MM_KEY_EXCH (Main Mode 4) is sent by the hub. ISAKMP state changes from IKE_R_MM3 to IKE_R_MM4. |
ISAKMP:(1002): sending packet to 172.16.1.1 my_port 500 peer_port 500 (R) MM_KEY_EXCH |
|
|
ISAKMP (0): received packet from 172.16.10.1 dport 500 sport 500 Global (I) MM_SA_SETUP |
MM_SA_SETUP (Main Mode 4) is received by spoke. The spoke concludes that the peer is another Cisco IOS device and no NAT is detected for us or our peer. The ISAKMP state changes from IKE_I_MM3 to IKE_I_MM4. |
|
|
ISAKMP:(1002):Send initial contact |
MM_KEY_EXCH (Main Mode 5) is sent by the spoke. The ISAKMP state changes from IKE_I_MM4 to IKE_I_MM5. |
|
|
MM_KEY_EXCH (Main Mode 5) is received by the hub. The ISAKMP state changes from IKE_R_MM4 to IKE_R_MM5. Additionally, the “peer matches *none* of the profiles” is seen due to the lack of an ISAKMP profile. Because this is the case, ISAKMP does not use a profile. |
ISAKMP (1002): received packet from 172.16.1.1 dport 500 sport 500 Global (R) MM_KEY_EXCH |
|
|
The final MM_KEY_EXCH packet (Main Mode 6) is sent by the hub. This completes the Phase 1 negotiation which signifies this device is ready for Phase 2 (IPSec Quick Mode). The ISAKMP state changes from IKE_R_MM5 to IKE_P1_COMPLETE. |
ISAKMP:(1002): sending packet to 172.16.1.1 my_port 500 peer_port 500 (R) MM_KEY_EXCH |
|
|
ISAKMP (1002): received packet from 172.16.10.1 dport 500 sport 500 Global (I) MM_KEY_EXCH |
The final MM_KEY_EXCH packet (Main Mode 6) is received by the spoke. This completes the Phase 1 negotiation which signifies this device is ready for Phase 2 (IPSec Quick Mode). The ISAKMP state changes from IKE_I_MM5 to IKE_I_MM6, and then immediately to IKE_P1_COMPLETE. Additionally, the “peer matches *none* of the profiles” is seen due to the lack of an ISAKMP profile. Because this is the case, ISAKMP does not use a profile. |
|
|
END OF ISAKMP (PHASE I) NEGOTATION, START OF IPSEC (PHASE II) NEGOTATION |
||
|
ISAKMP:(1002):beginning Quick Mode exchange, M-ID of 3464373979 |
The Quick Mode (Phase II, IPSec) exchange starts and the spoke send the first QM message to the hub. |
|
|
The hub receives the first Quick Mode (QM) packet which has the IPSec proposal. The attributes received specify that: encaps flag set to 2 (transport mode, flag of 1 would be tunnel mode), default SA lifetime of 3600 seconds and 4608000 kilobytes (0x465000 in hex), HMAC-SHA for authentication, and 3DES for encryption. As these are the same attributes set in the local configuration, the proposal is accepted and the shell of an IPSec SA is created. Since no Security Parameter Index (SPI) values are associated with these yet, this is just a shell of an SA that cannot be used to pass traffic yet. |
ISAKMP (1002): received packet from 172.16.1.1 dport 500 sport 500 Global (R) QM_IDLE |
|
|
These are just general IPSec service messages that say it works properly. |
IPSEC-IFC MGRE/Tu0(172.16.10.1/172.16.1.1): connection lookup returned 0 |
|
|
Pseudo-crypto map entry is created for IP protocol 47 (GRE) from 172.16.10.1 (hub public address) to 172.16.1.1 (spoke public address). An IPSec SA/SPI is created for both the inbound and outbound traffic with values from the accepted proposal. |
insert of map into mapdb AVL failed, map + ace pair already exists on the mapdb |
|
|
The second QM message sent by the hub. Message generated by IPSec service which confirms that tunnel protection is up on Tunnel0. Another SA creation message is seen which has the destination IPs, SPIs, transform set attributes, and lifetime in kilobytes and seconds remaining. |
ISAKMP:(1002): sending packet to 172.16.1.1 my_port 500 peer_port 500 (R) QM_IDLE |
|
|
ISAKMP (1002): received packet from 172.16.10.1 dport 500 sport 500 Global (I) QM_IDLE |
The spoke receives the second QM packet which has the IPSec proposal. This confirms that QM1 was received by the hub. The attributes received specify that: encaps flag set to 2 (transport mode, flag of 1 would be tunnel mode), default SA lifetime of 3600 seconds and 4608000 kilobytes (0x465000 in hex), HMAC-SHA for authentication, and DES for encryption. As these are the same attributes set in the local configuration, the proposal is accepted and the shell of an IPSec SA is created. Since no Security Parameter Index (SPI) values are associated with these yet, this is just a shell of an SA that cannot be used to pass traffic yet. The pseudo-crypto map entry is created for IP protocol 47 (GRE) from 172.16.10.1 (hub public address) to 172.16.1.1 (spoke public address). |
|
|
ISAKMP:(1002): processing NONCE payload. message ID = 3464373979 |
An IPSec SA/SPI is created for both the inbound and outbound traffic with values from the accepted proposal. |
|
|
ISAKMP:(1002): sending packet to 172.16.10.1 my_port 500 peer_port 500 (I) QM_IDLE |
The spoke sends the third and final QM message to the hub, which completes the QM exchange. Unlike ISAKMP where each peer goes through every state (MM1 through MM6/P1_COMPLETE), IPSec is a little different as there are only three messages rather than six. The Initiator (our spoke in this case, as signified by the “I” in the IKE_QM_I_QM1 message) goes from QM_READY, then to QM_I_QM1 directly to QM_PHASE2_COMPLETE. The Responder (hub) goes QM_READY, QM_SPI_STARVE, QM_R_QM2, QM_PHASE2_COMPLETE. Another SA creation message is seen which has the destination IPs, SPIs, transform set attributes, and lifetime in kilobytes and seconds remaining. |
|
|
These final QM messages confirm that Quick Mode is complete and IPSec is up on both sides of the tunnel. Unlike ISAKMP where each peer goes through every state (MM1 through MM6/P1_COMPLETE), IPSec is a little different as there are only three messages rather than six. The Responder (our hub in this case, as signified by the “R” in the IKE_QM_R_QM1 message) goes QM_READY, QM_SPI_STARVE, QM_R_QM2, QM_PHASE2_COMPLETE. The Initiator (spoke) goes from QM_READY, then to QM_I_QM1 directly to QM_PHASE2_COMPLETE. |
ISAKMP (1002): received packet from 172.16.1.1 dport 500 sport 500 Global (R) QM_IDLE |
|
|
NHRP: Send Registration Request via Tunnel0 vrf 0, packet size: 108 |
This is the NHRP registration requests sent to the hub in attempt to register to the NHS (the hub). It is normal to see multiples of these, as the spoke continues to attempt to register with the NHS until it receives a “registration reply.” src,dst: Tunnel source (spoke) and destination (hub) IP addresses. These are the source and destination of the GRE packet sent by the router src NBMA: the NBMA (internet) address of the spoke which sent this packet and tries to register with the NHS src protocol: tunnel address of the spoke which tries to register dst protocol: tunnel address of the NHS/hub Authentication Extension, data: NHRP authentication string client NBMA: NBMA address of the NHS/hub client protocol: tunnel address of the NHS/hub |
|
|
NHRP-RATE: Sending initial Registration Request for 10.1.1.254, reqid 65540 |
More NHRP service messages that say the initial Registration Request was sent to the NHS at 10.1.1.254. There is also a confirmation that a cache entry was added for tunnel IP 10.1.1.254/24 that lives at NBMA 172.16.10.1. The delayed message says the Tunnel has been “no shut” is seen here. |
|
|
IPSEC-IFC GRE/Tu0: tunnel coming up |
These are general IPSec service messages that say it works properly. Here is where it is finally seen that the Tunnel protocol is up. |
|
|
This is the NHRP registration requests received from the spoke in attempt to register to the NHS ( the hub). It is normal to see multiples of these, as the spoke continues to attempt to register with the NHS until it receives a “registration reply.” src NBMA: the NBMA (internet) address of the spoke which sent this packet and tries to register with the NHS src protocol: tunnel address of the spoke which tries to register dst protocol: tunnel address of the NHS/hub Authentication Extension, data: NHRP authentication string client NBMA: NBMA address of the NHS/hub client protocol: tunnel address of the NHS/hub |
NHRP: Receive Registration Request via Tunnel0 vrf 0, packet size: 108 |
|
|
NHRP debug packets adding target network 10.1.1.1/32 available via next hop of 10.1.1.1 at NHRP of 172.16.1.1. 172.16.1.1 is also added to the list of addresses which the hub forwards multicast traffic to. These messages confirm that the registration was successful, as was a resolution for the spokes Tunnel address. |
NHRP: netid_in = 1, to_us = 1 |
|
|
This is the NHRP Registration Reply sent by the hub to the spoke in response to the “NHRP Registration Request” received earlier. Like the other registration packets, the hub sends multiples of these in response to the multiple requests. src,dst: Tunnel source (hub) and destination (spoke) IP addresses. These are the source and destination of the GRE packet sent by the router src NBMA: NBMA (internet) address of the spoke src protocol: tunnel address of the spoke which tries to register dst protocol: tunnel address of the NHS/hub client NBMA: NBMA address of the NHS/hub client protocol: tunnel address of the NHS/hub Authentication Extension, data: NHRP authentication string |
NHRP: Send Registration Reply via Tunnel0 vrf 0, packet size: 128 |
|
|
NHRP: Receive Registration Reply via Tunnel0 vrf 0, packet size: 128 |
This is the NHRP Registration Reply sent by the hub to the spoke in response to the “NHRP Registration Request” received earlier. Like the other registration packets, the hub sends multiples of these in response to the multiple requests. src NBMA: NBMA (internet) address of the spoke src protocol: tunnel address of the spoke which tries to register dst protocol: tunnel address of the NHS/hub client NBMA: NBMA address of the NHS/hub client protocol: tunnel address of the NHS/hub Authentication Extension, data: NHRP authentication string |
|
|
More general IPSec service messages that say it works properly. |
IPSEC-IFC MGRE/Tu0: crypto_ss_listen_start already listening |
|
|
NHRP: NHS-UP: 10.1.1.254 |
NHRP service messages that say the NHS located at 10.1.1.254 is up. |
|
|
System message that states the EIGRP adjacency is up with the neighbor spoke at 10.1.1.1. |
%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.1.1.1 (Tunnel0) is up: new adjacency |
|
|
%DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.1.1.254 (Tunnel0) is up: new adjacency |
System message that states the EIGRP adjacency is up with the neighbor hub at 10.1.1.254. |
|
|
System message that confirms a successful NHRP resolution. |
NHRP: NHRP successfully resolved 10.1.1.1 to NBMA 172.16.1.1 |
|
Confirm Functionality and Troubleshoot
This section has some of the most useful show commands used to troubleshoot both the hub and spoke. In order to enable more specific debugs, use these debug conditionals:
-
debug dmvpn condition peer nbma NBMA_ADDRESS
-
debug dmvpn condition peer tunnel TUNNEL_ADDRESS
-
debug crypto condition peer ipv4 NBMA_ADDRESS
show crypto sockets
Spoke1#show crypto sockets
Number of Crypto Socket connections 1
Tu0 Peers (local/remote): 172.16.1.1/172.16.10.1
Local Ident (addr/mask/port/prot): (172.16.1.1/255.255.255.255/0/47)
Remote Ident (addr/mask/port/prot): (172.16.10.1/255.255.255.255/0/47)
IPSec Profile: "DMVPN-IPSEC"
Socket State: Open
Client: "TUNNEL SEC" (Client State: Active)
Crypto Sockets in Listen state:
Client: "TUNNEL SEC" Profile: "DMVPN-IPSEC" Map-name: "Tunnel0-head-0"
Hub#show crypto sockets
Number of Crypto Socket connections 1
Tu0 Peers (local/remote): 172.16.10.1/172.16.1.1
Local Ident (addr/mask/port/prot): (172.16.10.1/255.255.255.255/0/47)
Remote Ident (addr/mask/port/prot): (172.16.1.1/255.255.255.255/0/47)
IPSec Profile: "DMVPN-IPSEC"
Socket State: Open
Client: "TUNNEL SEC" (Client State: Active)
Crypto Sockets in Listen state:
Client: "TUNNEL SEC" Profile: "DMVPN-IPSEC" Map-name: "Tunnel0-head-0"
show crypto session detail
Spoke1#show crypto session detail
Crypto session current status
Code: C - IKE Configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal, T - cTCP encapsulation
X - IKE Extended Authentication, F - IKE Fragmentation
Interface: Tunnel0
Uptime: 00:01:01
Session status: UP-ACTIVE
Peer: 172.16.10.1 port 500 fvrf: (none) ivrf: (none)
Phase1_id: 172.16.10.1
Desc: (none)
IKEv1 SA: local 172.16.1.1/500 remote 172.16.10.1/500 Active
Capabilities:(none) connid:1001 lifetime:23:58:58
IPSEC FLOW: permit 47 host 172.16.1.1 host 172.16.10.1
Active SAs: 2, origin: crypto map
Inbound: #pkts dec'ed 25 drop 0 life (KB/Sec) 4596087/3538
Outbound: #pkts enc'ed 25 drop 3 life (KB/Sec) 4596087/3538
Hub#show crypto session detail
Crypto session current status
Code: C - IKE Configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal, T - cTCP encapsulation
X - IKE Extended Authentication, F - IKE Fragmentation
Interface: Tunnel0
Uptime: 00:01:47
Session status: UP-ACTIVE
Peer: 172.16.1.1 port 500 fvrf: (none)
ivrf: (none)
Phase1_id: 172.16.1.1
Desc: (none)
IKEv1 SA: local 172.16.10.1/500 remote 172.16.1.1/500 Active
Capabilities:(none) connid:1001 lifetime:23:58:12
IPSEC FLOW: permit 47 host 172.16.10.1 host 172.16.1.1
Active SAs: 2, origin: crypto map
Inbound: #pkts dec'ed 35 drop 0 life (KB/Sec) 4576682/3492
Outbound: #pkts enc'ed 35 drop 0 life (KB/Sec) 4576682/3492
show crypto isakmp sa detail
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.
1001 172.16.1.1 172.16.10.1 ACTIVE 3des sha psk 1 23:59:10
Engine-id:Conn-id = SW:1
IPv6 Crypto ISAKMP SA
Hub#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.
1001 172.16.10.1 172.16.1.1 ACTIVE 3des sha psk 1 23:58:20
Engine-id:Conn-id = SW:1
IPv6 Crypto ISAKMP SA
show crypto ipsec sa detail
Spoke1#show crypto ipsec sa detail
interface: Tunnel0
Crypto map tag: Tunnel0-head-0, local addr 172.16.1.1
protected vrf: (none)
local ident (addr/mask/prot/port): (172.16.1.1/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (172.16.10.1/255.255.255.255/47/0)
current_peer 172.16.10.1 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 24, #pkts encrypt: 24, #pkts digest: 24
#pkts decaps: 24, #pkts decrypt: 24, #pkts verify: 24
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#pkts no sa (send) 3, #pkts invalid sa (rcv) 0
#pkts encaps failed (send) 0, #pkts decaps failed (rcv) 0
#pkts invalid prot (recv) 0, #pkts verify failed: 0
#pkts invalid identity (recv) 0, #pkts invalid len (rcv) 0
#pkts replay rollover (send): 0, #pkts replay rollover (rcv) 0
##pkts replay failed (rcv): 0
#pkts internal err (send): 0, #pkts internal err (recv) 0
local crypto endpt.: 172.16.1.1, remote crypto endpt.: 172.16.10.1
path mtu 1500, ip mtu 1500, ip mtu idb Ethernet0/0
current outbound spi: 0xA259D71(170237297)
PFS (Y/N): N, DH group: none
inbound esp sas:
spi: 0x8D538D11(2371063057)
transform: esp-3des esp-sha-hmac ,
in use settings ={Transport,}
conn id: 1, flow_id: SW:1, sibling_flags 80000006,
crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4596087/3543)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xA259D71(170237297)
transform: esp-3des esp-sha-hmac ,
in use settings ={Transport, }
conn id: 2, flow_id: SW:2, sibling_flags 80000006,
crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4596087/3543)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
Hub#show crypto ipsec sa detail
interface: Tunnel0
Crypto map tag: Tunnel0-head-0, local addr 172.16.10.1
protected vrf: (none)
local ident (addr/mask/prot/port): (172.16.10.1/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (172.16.1.1/255.255.255.255/47/0)
current_peer 172.16.1.1 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 34, #pkts encrypt: 34, #pkts digest: 34
#pkts decaps: 34, #pkts decrypt: 34, #pkts verify: 34
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#pkts no sa (send) 0, #pkts invalid sa (rcv) 0
#pkts encaps failed (send) 0, #pkts decaps failed (rcv) 0
#pkts invalid prot (recv) 0, #pkts verify failed: 0
#pkts invalid identity (recv) 0, #pkts invalid len (rcv) 0
#pkts replay rollover (send): 0, #pkts replay rollover (rcv) 0
##pkts replay failed (rcv): 0
#pkts internal err (send): 0, #pkts internal err (recv) 0
local crypto endpt.: 172.16.10.1, remote crypto endpt.: 172.16.1.1
path mtu 1500, ip mtu 1500, ip mtu idb Ethernet0/0
current outbound spi: 0x8D538D11(2371063057)
PFS (Y/N): N, DH group: none
inbound esp sas:
spi: 0xA259D71(170237297)
transform: esp-3des esp-sha-hmac ,
in use settings ={Transport, }
conn id: 1, flow_id: SW:1, sibling_flags 80000006,
crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4576682/3497)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas: spi: 0x8D538D11(2371063057)
transform: esp-3des esp-sha-hmac ,
in use settings ={Transport, }
conn id: 2, flow_id: SW:2, sibling_flags 80000006,
crypto map: Tunnel0-head-0
sa timing: remaining key lifetime (k/sec): (4576682/3497)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
show ip nhrp
Spoke1#show ip nhrp
10.1.1.254/32 via 10.1.1.254
Tunnel0 created 00:00:55, never expire
Type: static, Flags:
NBMA address: 172.16.10.1
Hub#show ip nhrp
10.1.1.1/32 via 10.1.1.1
Tunnel0 created 00:01:26, expire 01:58:33
Type: dynamic, Flags: unique registered
NBMA address: 172.16.1.1
show ip nhs
Spoke1#show ip nhrp nhs
Legend: E=Expecting replies, R=Responding, W=Waiting
Tunnel0:
10.1.1.254 RE priority = 0 cluster = 0
Hub#show ip nhrp nhs (As the hub is the only NHS for this DMVPN cloud,
it does not have any servers configured)
show dmvpn [detail]
"show dmvpn detail" returns the output of show ip nhrp nhs, show dmvpn,
and show crypto session detail
Spoke1#show dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
N - NATed, L - Local, X - No Socket
# Ent --> Number of NHRP entries with same NBMA peer
NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
UpDn Time --> Up or Down Time for a Tunnel
==========================================================================
Interface: Tunnel0, IPv4 NHRP Details
Type:Spoke, NHRP Peers:1,
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 172.16.10.1 10.1.1.254 UP 00:00:39 S
Spoke1#show dmvpn detail
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
N - NATed, L - Local, X - No Socket
# Ent --> Number of NHRP entries with same NBMA peer
NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
UpDn Time --> Up or Down Time for a Tunnel
==========================================================================
Interface Tunnel0 is up/up, Addr. is 10.1.1.1, VRF ""
Tunnel Src./Dest. addr: 172.16.1.1/172.16.10.1, Tunnel VRF ""
Protocol/Transport: "GRE/IP", Protect "DMVPN-IPSEC"
Interface State Control: Disabled
IPv4 NHS:
10.1.1.254 RE priority = 0 cluster = 0
Type:Spoke, Total NBMA Peers (v4/v6): 1
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb Target Network
----- --------------- --------------- ----- -------- ----- -----------------
1 172.16.10.1 10.1.1.254 UP 00:00:41 S 10.1.1.254/32
Crypto Session Details:
--------------------------------------------------------------------------------
Interface: Tunnel0
Session: [0x08D513D0]
IKEv1 SA: local 172.16.1.1/500 remote 172.16.10.1/500 Active
Capabilities:(none) connid:1001 lifetime:23:59:18
Crypto Session Status: UP-ACTIVE
fvrf: (none), Phase1_id: 172.16.10.1
IPSEC FLOW: permit 47 host 172.16.1.1 host 172.16.10.1
Active SAs: 2, origin: crypto map
Inbound: #pkts dec'ed 21 drop 0 life (KB/Sec) 4596088/3558
Outbound: #pkts enc'ed 21 drop 3 life (KB/Sec) 4596088/3558
Outbound SPI : 0x A259D71, transform : esp-3des esp-sha-hmac
Socket State: Open
Pending DMVPN Sessions:
Hub#show dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
N - NATed, L - Local, X - No Socket
# Ent --> Number of NHRP entries with same NBMA peer
NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting
UpDn Time --> Up or Down Time for a Tunnel
==========================================================================
Interface: Tunnel0, IPv4 NHRP Details Type:Hub, NHRP Peers:1,
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb
----- --------------- --------------- ----- -------- -----
1 172.16.1.1 10.1.1.1 UP 00:01:30 D
Hub#show dmvpn detail
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
N - NATed, L - Local, X - No Socket # Ent --> Number of NHRP entries with same NBMA peer NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting UpDn Time --> Up or Down Time for a Tunnel ==========================================================================
Interface Tunnel0 is up/up, Addr. is 10.1.1.254, VRF "" Tunnel Src./Dest. addr: 172.16.10.1/MGRE, Tunnel VRF "" Protocol/Transport: "multi-GRE/IP", Protect "DMVPN-IPSEC" Interface State Control: Disabled Type:Hub, Total NBMA Peers (v4/v6): 1
# Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb Target Network ----- --------------- --------------- ----- -------- ----- ----------------- 1 172.16.1.1 10.1.1.1 UP 00:01:32 D 10.1.1.1/32
Crypto Session Details:
-------------------------------------------------------------------------------- Interface: Tunnel0
Session: [0x08A27858]
IKEv1 SA: local 172.16.10.1/500 remote 172.16.1.1/500 Active
Capabilities:(none) connid:1001 lifetime:23:58:26
Crypto Session Status: UP-ACTIVE
fvrf: (none), Phase1_id: 172.16.1.1
IPSEC FLOW: permit 47 host 172.16.10.1 host 172.16.1.1
Active SAs: 2, origin: crypto map
Inbound: #pkts dec'ed 32 drop 0 life (KB/Sec) 4576682/3507
Outbound: #pkts enc'ed 32 drop 0 life (KB/Sec) 4576682/3507
Outbound SPI : 0x8D538D11, transform : esp-3des esp-sha-hmac
Socket State: Open
Pending DMVPN Sessions:
Related Information
FeedbackContact Cisco
- Open a Support Case
- (Requires a Cisco Service Contract)