In which configuration mode is debug crypto isakmp used?

The debug crypto isakmp command is entered in Privileged EXEC mode on Cisco IOS devices.

DebugPrivileged EXEC

debug crypto isakmp

Enables debugging of ISAKMP (Internet Security Association and Key Management Protocol) packets to troubleshoot IKE phase 1 issues in IPsec VPNs.

Definition: debug crypto isakmp is a Cisco IOS privileged exec command. Enables debugging of ISAKMP (Internet Security Association and Key Management Protocol) packets to troubleshoot IKE phase 1 issues in IPsec VPNs.

Overview

The `debug crypto isakmp` command is a powerful diagnostic tool used in Cisco IOS to monitor and troubleshoot Internet Security Association and Key Management Protocol (ISAKMP) exchanges during IKE phase 1 of IPsec VPN establishment. ISAKMP, defined in RFC 2408, provides a framework for authentication and key exchange, and is the foundation of IKE (Internet Key Exchange). This command enables real-time logging of ISAKMP packets, including Main Mode or Aggressive Mode negotiations, pre-shared key authentication, certificate exchanges, and Diffie-Hellman key generation.

It is indispensable when a VPN tunnel fails to come up, as it reveals the exact point of failure—whether due to mismatched policies, authentication errors, or proposal mismatches. Unlike `debug ipsec` (which focuses on IKE phase 2 and IPsec SA establishment), `debug crypto isakmp` targets the initial phase where peers authenticate and establish a secure channel. Network engineers reach for this command when a VPN tunnel remains in a down state despite correct configuration, or when intermittent connectivity issues suggest IKE negotiation problems.

It fits into a broader troubleshooting workflow: after verifying basic connectivity (ping, routing) and checking crypto maps and ISAKMP policies with `show crypto isakmp sa` and `show crypto isakmp policy`, enabling this debug provides granular insight. Important IOS behaviors: debug output is sent to the console by default and can overwhelm the router's CPU; it is recommended to use `logging buffered` and `terminal monitor` for remote sessions. The command requires privileged EXEC mode (enable level 15).

It does not affect the running configuration but can impact performance, so it should be disabled with `undebug all` or `no debug crypto isakmp` after troubleshooting. The output includes timestamps, peer IP addresses, phase identifiers, and status messages like 'ISAKMP: received peer proposal' or 'ISAKMP: SA not acceptable!' which directly indicate negotiation progress or failure. Understanding this output is critical for CCNA and CCNP candidates to master IPsec VPN troubleshooting.

Syntax·Privileged EXEC

debug crypto isakmp

When to Use This Command

Troubleshooting why an IPsec tunnel fails to establish during IKE phase 1.
Verifying that ISAKMP proposals, pre-shared keys, or authentication methods match between peers.
Diagnosing issues with ISAKMP SA lifetime or aggressive mode negotiation.
Monitoring ISAKMP exchange details during initial VPN setup or after configuration changes.

Parameters

Parameter	Syntax	Required	Description
no parameter	debug crypto isakmp	Optional	The command has no optional parameters. It enables all ISAKMP debug messages. To limit output, use conditional debugging with `debug crypto condition` or filter by peer IP using `debug crypto isakmp <peer-ip>` (available in some IOS versions). Common mistake: forgetting to disable debugging after use, which can cause high CPU and log flooding.

Command Examples

Basic ISAKMP debug output

debug crypto isakmp

ISAKMP (0:0): received packet from 192.168.1.2 dport 500 sport 500 Global (N) NEW SA
ISAKMP (0:0): processing SA payload. message ID = 0
ISAKMP (0:0): Checking ISAKMP transform 1 against priority 1 policy
ISAKMP (0:0): encryption DES-CBC
ISAKMP (0:0): hash SHA
ISAKMP (0:0): auth pre-share
ISAKMP (0:0): group 2
ISAKMP (0:0): lifetime 86400 seconds
ISAKMP (0:0): atts are acceptable. Next payload is 0
ISAKMP (0:0): processing KE payload. message ID = 0
ISAKMP (0:0): processing NONCE payload. message ID = 0
ISAKMP (0:0): processing ID payload. message ID = 0
ISAKMP (0:0): peer is part of isakmp profile default
ISAKMP (0:0): processing HASH payload. message ID = 0
ISAKMP (0:0): SA has been authenticated
ISAKMP (0:0): beginning Quick Mode exchange, M-ID of -123456789
ISAKMP (0:0): sending packet to 192.168.1.2 (I) QM_IDLE
ISAKMP (0:0): received packet from 192.168.1.2 dport 500 sport 500 Global (I) QM_IDLE
ISAKMP (0:0): processing ID payload. message ID = -123456789
ISAKMP (0:0): processing HASH payload. message ID = -123456789
ISAKMP (0:0): Loading all IPSEC SAs
ISAKMP (0:0): Generating IPSEC SAs
ISAKMP (0:0): sending packet to 192.168.1.2 (I) QM_IDLE
ISAKMP (0:0): received packet from 192.168.1.2 dport 500 sport 500 Global (I) QM_IDLE
ISAKMP (0:0): deleting node -123456789 error FALSE reason "quick mode done"
ISAKMP (0:0): Input = IKE_MESG_FROM_IPSEC, IKE_SA_REAP_INIT
ISAKMP (0:0): Old State = IKE_P1_COMPLETE  New State = IKE_DONE

Line 1: Received a new SA request from peer 192.168.1.2. Line 2-3: Processing SA payload and checking transform set. Lines 4-8: Displaying the proposed transform details (encryption, hash, auth, DH group, lifetime). Line 9: Transform is acceptable. Lines 10-12: Processing key exchange, nonce, and identity payloads. Line 13: Peer matched to default ISAKMP profile. Line 14: Hash verification successful, SA authenticated. Lines 15-16: Beginning Quick Mode (IKE phase 2) with a message ID. Lines 17-22: Quick Mode exchange completing. Line 23: Node deleted indicating successful QM. Lines 24-25: State transition to IKE_DONE, meaning phase 1 and phase 2 complete.

Debug with errors - pre-shared key mismatch

debug crypto isakmp

ISAKMP (0:0): received packet from 10.0.0.1 dport 500 sport 500 Global (N) NEW SA
ISAKMP (0:0): processing SA payload. message ID = 0
ISAKMP (0:0): Checking ISAKMP transform 1 against priority 1 policy
ISAKMP (0:0): encryption AES-CBC
ISAKMP (0:0): hash SHA256
ISAKMP (0:0): auth pre-share
ISAKMP (0:0): group 5
ISAKMP (0:0): lifetime 86400 seconds
ISAKMP (0:0): atts are acceptable. Next payload is 0
ISAKMP (0:0): processing KE payload. message ID = 0
ISAKMP (0:0): processing NONCE payload. message ID = 0
ISAKMP (0:0): processing ID payload. message ID = 0
ISAKMP (0:0): peer is part of isakmp profile default
ISAKMP (0:0): processing HASH payload. message ID = 0
ISAKMP (0:0): SA authentication failed
ISAKMP (0:0): sending packet to 10.0.0.1 (R) MM_KEY_EXCH
ISAKMP (0:0): peer matches default profile
ISAKMP (0:0): deleting SA with 10.0.0.1
ISAKMP (0:0): Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
ISAKMP (0:0): Old State = IKE_READY  New State = IKE_DEST_SA

Lines 1-8: Similar to first example, transform is acceptable. Lines 9-12: Processing KE, nonce, ID. Line 13: Peer matched to default profile. Line 14: Hash verification failed, meaning pre-shared keys do not match or authentication failed. Line 15: Router sends notification back to peer. Line 16: Peer matches profile again. Line 17: SA is deleted. Lines 18-19: State transitions to IKE_DEST_SA, indicating the SA is destroyed. This output indicates a pre-shared key mismatch or authentication issue.

Understanding the Output

The debug crypto isakmp command outputs real-time messages about ISAKMP (IKE phase 1) events. Each line begins with 'ISAKMP (0:0):' where the numbers represent the ISAKMP SA index and connection ID. Key fields to watch: 'received packet from' shows the peer IP and port; 'processing SA payload' indicates transform negotiation; 'atts are acceptable' means the transform matches; 'SA has been authenticated' means phase 1 succeeded; 'SA authentication failed' indicates a pre-shared key or certificate issue; 'deleting node' with 'quick mode done' means phase 2 completed; 'Old State' and 'New State' show state transitions.

Good values: 'atts are acceptable', 'SA has been authenticated', 'IKE_DONE'. Bad values: 'SA authentication failed', 'no acceptable proposal', 'deleting SA' without completion. Watch for repeated failures or timeouts.

Configuration Scenarios

Troubleshooting Site-to-Site VPN with Pre-Shared Key Mismatch

Two branch routers (R1 and R2) are configured for a site-to-site IPsec VPN using pre-shared keys. The tunnel fails to come up. The engineer suspects a key mismatch and uses debug crypto isakmp to identify the issue.

Topology

R1(Gi0/0)---10.0.12.0/30---(Gi0/0)R2

Steps

1.Step 1: On R1, enable ISAKMP debugging: R1# debug crypto isakmp
2.Step 2: Initiate the VPN from R1 by generating interesting traffic (e.g., ping from 192.168.1.1 to 192.168.2.1): R1# ping 192.168.2.1 source 192.168.1.1
3.Step 3: Observe the debug output. Look for messages like 'ISAKMP: SA not acceptable!' or 'ISAKMP: failure to validate pre-shared key'.
4.Step 4: Verify the ISAKMP policy and pre-shared key on both routers using show commands: R1# show crypto isakmp policy and R1# show crypto isakmp key
5.Step 5: Correct the pre-shared key on R2 to match R1's key: R2(config)# crypto isakmp key cisco123 address 10.0.12.1
6.Step 6: Clear the ISAKMP SA to force renegotiation: R1# clear crypto isakmp sa
7.Step 7: Re-initiate traffic and verify the tunnel comes up: R1# show crypto isakmp sa

Configuration

! R1 Configuration
crypto isakmp policy 10
 encryption aes 256
 hash sha256
 authentication pre-share
 group 14
 lifetime 86400
crypto isakmp key mykey address 10.0.12.2
!
! R2 Configuration (with wrong key initially)
crypto isakmp policy 10
 encryption aes 256
 hash sha256
 authentication pre-share
 group 14
 lifetime 86400
crypto isakmp key wrongkey address 10.0.12.1

Verify: R1# show crypto isakmp sa dst src state conn-id slot 10.0.12.2 10.0.12.1 QM_IDLE 1001 0 Expected state is QM_IDLE or MM_ACTIVE for phase 1 success.

Watch out: Ensure that the pre-shared key is configured with the correct peer IP address. A common mistake is using the wrong peer IP in the key statement, which causes authentication failure even if the key string matches.

Debugging IKE Phase 1 with Certificate Authentication Failure

A remote access VPN client (Cisco AnyConnect) fails to authenticate using certificates. The ASA (acting as headend) shows no phase 1 SA. Debug crypto isakmp on the ASA reveals certificate validation errors.

Topology

Client---Internet---ASA(Gi0/0)---Inside(192.168.1.0/24)

Steps

1.Step 1: On the ASA, enable ISAKMP debugging: asa# debug crypto isakmp 255
2.Step 2: Initiate VPN connection from the client.
3.Step 3: Look for 'ISAKMP: failed to verify certificate' or 'ISAKMP: certificate validation error' in the debug output.
4.Step 4: Check the certificate status on the ASA: asa# show crypto ca certificates
5.Step 5: Verify the client certificate is issued by a trusted CA and has not expired.
6.Step 6: If the CA certificate is missing, import it: asa(config)# crypto ca trustpoint MYCA asa(config-ca-trustpoint)# enrollment terminal asa(config-ca-trustpoint)# crypto ca authenticate MYCA
7.Step 7: Clear the ISAKMP SA and retry: asa# clear crypto isakmp sa

Configuration

! ASA Configuration
crypto ca trustpoint MYCA
 enrollment terminal
 revocation-check none
crypto ca certificate chain MYCA
 certificate ca 01
 308202... (base64 certificate)
 quit
crypto isakmp policy 10
 authentication rsa-sig
 encryption aes 256
 hash sha256
 group 14
 lifetime 86400
crypto ipsec transform-set AES256-SHA esp-aes-256 esp-sha-hmac
crypto dynamic-map DMAP 10 set transform-set AES256-SHA
crypto map CMAP 10 ipsec-isakmp dynamic DMAP
crypto map CMAP interface outside

Verify: asa# show crypto isakmp sa Active SA: 1 Rekey SA: 0 (A tunnel will report 1 Active SA) Expected state: MM_ACTIVE or QM_IDLE for phase 1 success.

Watch out: On ASA, the debug level (255) is required for verbose output. Also, ensure the ASA clock is accurate (NTP) because certificate validation depends on time. A common mistake is forgetting to configure 'revocation-check none' when OCSP or CRL is unavailable.

Troubleshooting with This Command

When troubleshooting IPsec VPN issues, `debug crypto isakmp` is the go-to command for IKE phase 1 problems. Healthy output shows a clear progression: 'ISAKMP: beginning Main Mode exchange', 'ISAKMP: SA is doing pre-shared key authentication', 'ISAKMP: SA has been established', and finally 'ISAKMP: sending notification to peer'. Problem indicators include 'ISAKMP: SA not acceptable!' (proposal mismatch), 'ISAKMP: failure to validate pre-shared key' (key mismatch), 'ISAKMP: no suitable policy found' (policy not configured), 'ISAKMP: peer does not support this proposal' (encryption/hash mismatch), and 'ISAKMP: failed to verify certificate' (certificate issues).

Focus on fields like 'transform set', 'hash algorithm', 'authentication method', and 'group' to identify mismatches. For example, if one side proposes AES-256 and the other only supports AES-128, the debug will show 'SA not acceptable'. A step-by-step diagnostic flow: 1) Verify basic connectivity (ping peer IP). 2) Check crypto isakmp policy with `show crypto isakmp policy`. 3) Enable `debug crypto isakmp` and initiate traffic. 4) Analyze the debug output for error messages. 5) If proposal mismatch, adjust policy on one side. 6) If authentication failure, verify pre-shared keys or certificates. 7) If no debug output appears, ensure the router is generating interesting traffic (ACL match).

Correlate with `show crypto isakmp sa` to see SA state (MM_NO_STATE, MM_SA_SETUP, etc.) and with `debug crypto ipsec` for phase 2 issues. Remember that debug output is CPU-intensive; use `logging buffered 1000000` and `terminal monitor` to capture output without flooding the console. Always disable debugging with `undebug all` after troubleshooting.

CCNA Exam Tips

CCNA exam may ask what debug command to use for IKE phase 1 issues; answer is 'debug crypto isakmp'.

Remember that 'debug crypto isakmp' can generate a lot of output; use 'terminal monitor' if accessing via Telnet/SSH.

The exam might show a debug output with 'SA authentication failed' and ask the cause; answer is usually pre-shared key mismatch.

Be aware that 'debug crypto isakmp' does not show IKE phase 2 details; use 'debug crypto ipsec' for that.

Common Mistakes

Leaving debug enabled on a production router, causing high CPU usage and log flooding.

Confusing 'debug crypto isakmp' with 'debug crypto ipsec'; the former is for IKE phase 1, the latter for phase 2.

Not using 'undebug all' or 'no debug crypto isakmp' to disable debugging after troubleshooting.

debug crypto isakmp vs debug crypto ipsec

The 'debug crypto isakmp' and 'debug crypto ipsec' commands are both used for troubleshooting IPsec VPNs but target different phases of the IKE and IPsec protocols. They are commonly confused because ISAKMP is the framework for key management in IKE, while IPsec debugging covers the actual data encryption; understanding their distinct scopes helps pinpoint issues efficiently.

Aspect	debug crypto isakmp	debug crypto ipsec
Protocol Layer	IKE (ISAKMP) - key management	IPsec - data encryption/decryption
IKE Phase	Phase 1 (main/aggressive mode)	Phase 2 (quick mode) and SA creation
Packet Types	UDP 500/4500 (ISAKMP headers)	ESP/AH packets (encrypted data)
Output Detail	Detailed authentication, key exchange, hash	SA parameters, SPI, encryption/decryption stats
Impact on Router	High CPU during debug; can crash router	Very high CPU; avoid on production
Typical Use	ISAKMP negotiation failures, pre-shared key issues	IPsec SA not established, traffic not encrypted

Use debug crypto isakmp when troubleshooting IKE phase 1 issues such as authentication failures, proposal mismatches, or dead peer detection problems.

Use debug crypto ipsec when troubleshooting IPsec phase 2 issues like SA negotiation failures, replay errors, or traffic that should be encrypted but is not.

Platform Notes

On IOS-XE (e.g., CSR1000v, ISR 4000), the `debug crypto isakmp` command syntax and output are largely identical to classic IOS. However, IOS-XE may support additional conditional debugging options like `debug crypto condition peer <ip>`. The output format is similar but may include additional fields like 'IKEv1' or 'IKEv2' depending on the version.

On NX-OS (e.g., Nexus 7000, 9000), the equivalent command is `debug crypto ike` (for IKEv1) or `debug crypto ikev2` (for IKEv2). NX-OS uses a different debug infrastructure; you must first enable the feature with `feature debug` and then use `debug crypto ike`. The output is more structured and includes timestamps by default.

On ASA (Cisco Adaptive Security Appliance), the command is `debug crypto isakmp [level]` where level 1-255 controls verbosity (255 is most verbose). ASA also supports `debug crypto ikev1` and `debug crypto ikev2` for newer code. The ASA output is similar but uses different state names (e.g., MM_WAIT_MSG2).

On IOS-XR (e.g., ASR 9000), the command is `debug crypto ike` (for IKEv1) or `debug crypto ikev2` (for IKEv2). IOS-XR requires the `crypto` feature to be enabled and uses a different debug filtering system. Note that in IOS 12.x and 15.x, the debug output may not include timestamps by default; use `service timestamps debug datetime msec` to enable them.

In IOS 16.x (IOS-XE), timestamps are often enabled by default. Always check the specific platform documentation for exact syntax.

Related Commands

crypto isakmp policy [priority]

Creates or modifies an ISAKMP (IKE) policy for IPsec VPN negotiations, defining encryption, authentication, and key exchange parameters.

debug crypto ipsec

Use this command to enable real-time debugging of IPsec security association (SA) negotiations and packet processing, typically for troubleshooting VPN connectivity issues.

show crypto ipsec sa

Displays the current state and statistics of IPsec security associations (SAs) to verify VPN tunnel establishment and monitor encrypted traffic.

show crypto isakmp sa

Displays the current state of Internet Key Exchange (IKE) Security Associations (SAs) used for IPsec VPN tunnels, allowing verification of Phase 1 tunnel establishment.

Practice for the CCNA 200-301

Test your knowledge with practice questions covering all CCNA 200-301 exam domains.

Practice CCNA 200-301 Questions