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.
Definition: show crypto isakmp sa is a Cisco IOS privileged exec command. Displays the current state of Internet Key Exchange (IKE) Security Associations (SAs) used for IPsec VPN tunnels, allowing verification of Phase 1 tunnel establishment.
Overview
The `show crypto isakmp sa` command is a critical diagnostic tool for any network engineer working with IPsec VPNs on Cisco IOS devices. It displays the current state of Internet Key Exchange (IKE) Security Associations (SAs), which are the Phase 1 tunnels that establish a secure control channel between two VPN peers. Understanding this command is essential for CCNA and CCNP candidates because it directly verifies the first step of IPsec tunnel establishment: IKE Phase 1. Without a successful Phase 1, no IPsec (Phase 2) SAs can be created, and the VPN will not pass traffic.
The networking concept behind this command is the IKE protocol, which uses UDP port 500 (or 4500 for NAT traversal) to negotiate cryptographic parameters, authenticate peers, and generate shared keys. The output shows each IKE SA with its peer IP, state, encryption/hash algorithms, and lifetime. The most important field is the state, which should be "MM_ACTIVE" (Main Mode) or "QM_IDLE" (Quick Mode) for a healthy Phase 1. Common problem states include "MM_NO_STATE" (no negotiation started), "MM_WAIT_MSG2" (waiting for peer response), or "MM_KEY_EXCH" (key exchange in progress).
You would reach for this command when a VPN tunnel is not coming up, traffic is not encrypted, or you need to verify that both peers have completed IKE negotiation. It is the first command in any IPsec troubleshooting workflow, before checking Phase 2 with `show crypto ipsec sa`. Alternatives like `debug crypto isakmp` provide real-time negotiation details but are more intrusive and can overwhelm the console. The `show crypto isakmp sa` command is lightweight and safe to run on production devices.
Important IOS behaviors: The output is buffered and may not update in real-time; use the `clear crypto isakmp sa` command to reset SAs if needed. Privilege level 15 (enable) is required. The command does not affect the running configuration. In newer IOS versions (15.x+), the output may include additional fields like "status" (ACTIVE or DELETED) and "initiator" or "responder" flags. The command can also be filtered by peer IP or connection ID using the `| include` pipe, but there is no direct parameter for filtering in the base command.
show crypto isakmp saWhen to Use This Command
- Verify that an IPsec VPN peer has successfully established Phase 1 (IKE) after configuring a site-to-site VPN.
- Troubleshoot a VPN that is not coming up by checking if IKE SAs are in MM_ACTIVE state.
- Monitor active VPN tunnels to ensure they are still established and not idle or deleted.
- Check the encryption and authentication algorithms negotiated with a remote peer.
Command Examples
Basic show crypto isakmp sa output
show crypto isakmp saIPv4 Crypto ISAKMP SA dst src state conn-id slot status 192.168.1.1 10.0.0.1 MM_ACTIVE 1001 0 ACTIVE 10.0.0.1 192.168.1.1 MM_ACTIVE 1002 0 ACTIVE
Line 1: Header for IPv4 IKE SAs. Line 2: dst=remote peer IP, src=local IP, state=MM_ACTIVE (Phase 1 complete), conn-id=unique SA ID, slot=hardware slot (0 for software), status=ACTIVE (SA is usable). Line 3: Reverse direction SA (bidirectional).
Troubleshooting a failed IKE SA
show crypto isakmp saIPv4 Crypto ISAKMP SA dst src state conn-id slot status 192.168.1.1 10.0.0.1 MM_NO_STATE 1001 0 DELETED
state=MM_NO_STATE indicates Phase 1 negotiation failed or never started. status=DELETED means the SA was removed. This output suggests a configuration mismatch (e.g., pre-shared key, encryption algorithm) or connectivity issue.
Understanding the Output
The command output lists all IKE SAs (Phase 1) that the router has negotiated. Each row represents a unidirectional SA; typically two rows appear for a bidirectional tunnel. The 'dst' column shows the remote peer IP, 'src' the local IP.
The 'state' column is critical: 'MM_ACTIVE' means Phase 1 is complete and the SA is ready for Phase 2 (IPsec). Other states like 'MM_NO_STATE', 'MM_KEY_EXCH', or 'MM_WAIT_MSG' indicate negotiation is in progress or failed. 'conn-id' is a local identifier for the SA.
'slot' is usually 0 for software-based crypto. 'status' shows 'ACTIVE' if the SA is usable, or 'DELETED' if it has been removed. In a healthy VPN, you should see at least one pair of SAs in MM_ACTIVE and ACTIVE status.
If you see DELETED or non-ACTIVE states, check IKE configuration (pre-shared keys, algorithms, peer reachability).
Configuration Scenarios
Verify IKE Phase 1 after configuring a site-to-site VPN between two routers
After configuring a site-to-site IPsec VPN between R1 and R2, you need to confirm that IKE Phase 1 has completed successfully before checking Phase 2.
Topology
R1(Gi0/0)---10.0.12.0/30---(Gi0/0)R2Steps
- 1.Step 1: On R1, enter privileged EXEC mode: R1> enable
- 2.Step 2: Run the command: R1# show crypto isakmp sa
- 3.Step 3: Verify that the state is MM_ACTIVE for the peer IP 10.0.12.2
- 4.Step 4: Repeat on R2 to confirm symmetric output
! On R1: crypto isakmp policy 10 encryption aes 256 hash sha256 authentication pre-share group 14 lifetime 86400 crypto isakmp key cisco123 address 10.0.12.2 ! ! On R2: crypto isakmp policy 10 encryption aes 256 hash sha256 authentication pre-share group 14 lifetime 86400 crypto isakmp key cisco123 address 10.0.12.1
Verify: R1# show crypto isakmp sa dst src state conn-id slot status 10.0.12.2 10.0.12.1 MM_ACTIVE 1 0 ACTIVE Expected: state = MM_ACTIVE, status = ACTIVE
Watch out: If the state shows MM_NO_STATE, check that the ISAKMP key matches on both sides and that UDP port 500 is not blocked by an ACL.
Troubleshoot IKE Phase 1 failure due to mismatched policies
A remote site VPN is not establishing. You suspect the IKE policies (encryption, hash, DH group) are mismatched between peers.
Topology
HQ-Router(Gi0/0)---172.16.0.0/30---(Gi0/0)Branch-RouterSteps
- 1.Step 1: On HQ-Router, run: HQ-Router# show crypto isakmp sa
- 2.Step 2: Observe the state; if it shows MM_WAIT_MSG2 or MM_NO_STATE, there is a negotiation problem.
- 3.Step 3: Check the configured IKE policies on both routers using: show crypto isakmp policy
- 4.Step 4: Compare the policies; ensure at least one matching proposal exists (same encryption, hash, auth, DH group, lifetime).
- 5.Step 5: Correct the mismatch and re-initiate the tunnel by clearing SAs: clear crypto isakmp sa
! On HQ-Router (correct policy): crypto isakmp policy 10 encryption aes 256 hash sha256 authentication pre-share group 14 lifetime 86400 ! ! On Branch-Router (incorrect policy): crypto isakmp policy 10 encryption aes 128 hash md5 authentication pre-share group 2 lifetime 3600
Verify: HQ-Router# show crypto isakmp sa dst src state conn-id slot status 172.16.0.2 172.16.0.1 MM_WAIT_MSG2 1 0 ACTIVE After fixing policy on Branch-Router: dst src state conn-id slot status 172.16.0.2 172.16.0.1 MM_ACTIVE 1 0 ACTIVE
Watch out: Lifetime mismatch is often overlooked; the responder will accept the initiator's lifetime if it is within the configured range, but if the initiator's lifetime is shorter than the responder's minimum, negotiation fails.
Troubleshooting with This Command
When troubleshooting IPsec VPN issues, the `show crypto isakmp sa` command is your first stop. A healthy Phase 1 SA shows a state of "MM_ACTIVE" (Main Mode) or "QM_IDLE" (Aggressive Mode). The status should be "ACTIVE". If the state is anything else, Phase 1 has not completed.
Key fields to focus on: - **dst**: Destination IP (peer). Ensure this matches the peer's public IP. - **src**: Source IP (local). Should be the local interface IP used for VPN. - **state**: The IKE negotiation state. Common states: - MM_NO_STATE: No negotiation has started. Check connectivity and ACLs. - MM_WAIT_MSG2: Waiting for the peer's first response. Usually indicates a firewall blocking UDP 500 or a mismatched pre-shared key. - MM_KEY_EXCH: Key exchange in progress. If stuck, check DH group mismatch. - MM_ACTIVE: Successful Phase 1. - **conn-id**: Connection ID; useful for correlating with debug output. - **slot**: Always 0 for software-based encryption. - **status**: ACTIVE or DELETED. DELETED means the SA is being torn down.
Common symptoms and their meanings: - **No output at all**: No IKE SAs exist. Either the tunnel has never been initiated, or all SAs have been cleared. - **Multiple SAs to the same peer**: Could indicate multiple Phase 1 negotiations; clear them with `clear crypto isakmp sa`. - **State stuck in MM_WAIT_MSG2**: Pre-shared key mismatch or ACL blocking UDP 500/4500. - **State stuck in MM_KEY_EXCH**: DH group mismatch or certificate issues.
Diagnostic flow: 1. Run `show crypto isakmp sa` on both peers. 2. If state is not MM_ACTIVE, check connectivity with `ping` to the peer IP. 3. Verify ACLs on the outside interface: `show access-lists` to ensure UDP 500/4500 is permitted. 4. Check IKE policies: `show crypto isakmp policy` on both sides. 5. If using pre-shared keys, verify they match: `show running-config | include crypto isakmp key`. 6. If still failing, enable debug: `debug crypto isakmp` (caution: can flood console). 7. Correlate debug output with the SA state; for example, "no acceptable proposal" indicates policy mismatch.
Correlating with other commands: - `show crypto ipsec sa` shows Phase 2 SAs; if Phase 1 is down, Phase 2 will be empty or show "IPSEC_INVALID_SPI". - `show crypto session` provides a summary of both IKE and IPsec sessions. - `debug crypto isakmp` gives real-time negotiation details but should be used sparingly.
CCNA Exam Tips
CCNA exam tip: The state 'MM_ACTIVE' confirms Phase 1 is complete; if you see 'MM_NO_STATE', the IKE negotiation hasn't started or failed.
CCNA exam tip: Two SAs (one for each direction) are normal for a single VPN tunnel; don't be alarmed by duplicate entries.
CCNA exam tip: If the status is 'DELETED', the SA was removed due to timeout or manual clear; check crypto isakmp policy and pre-shared keys.
CCNA exam tip: The command does not show Phase 2 (IPsec) SAs; use 'show crypto ipsec sa' for that.
Common Mistakes
Mistake 1: Assuming a single SA is enough; forgetting that IKE creates two unidirectional SAs (one for each direction).
Mistake 2: Misinterpreting 'MM_NO_STATE' as a temporary state; it often indicates a configuration error that prevents negotiation.
Mistake 3: Not checking the 'status' column; a SA in 'ACTIVE' state but with 'DELETED' status is not usable.
show crypto isakmp sa vs show crypto ipsec sa
Both commands are used to troubleshoot IPsec VPNs, but they monitor different phases of tunnel establishment. show crypto isakmp sa checks IKE Phase 1 SAs, while show crypto ipsec sa checks IPsec Phase 2 SAs. They are often confused because both involve 'crypto sa' and are used consecutively during troubleshooting.
| Aspect | show crypto isakmp sa | show crypto ipsec sa |
|---|---|---|
| Phase | IKE Phase 1 (ISAKMP) | IPsec Phase 2 (IPsec) |
| Information | Peer IP, state (MM_NO_STATE, MM_ACTIVE), encryption/hash proposals | SPI, transform set, lifetime (sec/bytes), encaps, packet count |
| Typical Use | Verify peer reachability and Phase 1 completion | Verify traffic encryption and SA lifetime expiry |
| Clear Command | clear crypto isakmp (clears IKE SAs) | clear crypto ipsec sa (clears IPsec SAs) |
| Output Example | IPv4 Crypto ISAKMP SA dst src state conn-id slot status | interface: ... path MTU ... inbound esp sas spi: 0x... |
Use show crypto isakmp sa when you need to verify that IKE Phase 1 negotiation has completed and check the status of the IKE SA with the remote peer.
Use show crypto ipsec sa when you need to verify that IPsec Phase 2 SAs are established, inspect encryption parameters, or monitor packet statistics for troubleshooting.
Platform Notes
On Cisco IOS-XE (e.g., CSR1000v, ISR 4000 series), the `show crypto isakmp sa` command syntax and output are nearly identical to classic IOS. However, IOS-XE may show additional fields like "IKEv1" or "IKEv2" in the output if both versions are configured. The command is also available in IOS-XR, but the output format differs significantly; IOS-XR uses `show crypto ikev1 sa` or `show crypto ikev2 sa` for IKE SAs.
On NX-OS (Nexus switches), the equivalent command is `show crypto ikev1 sa` (for IKEv1) or `show crypto ikev2 sa` (for IKEv2). The NX-OS output includes similar fields but uses different terminology (e.g., "IKE SA" instead of "ISAKMP SA"). On Cisco ASA firewalls, the command is `show crypto isakmp sa` and behaves similarly, but the output includes additional fields like "encr" and "hash" in a different layout.
For IOS versions: In 12.x, the output is simpler with fewer columns; 15.x and 16.x added the "status" column and sometimes a "enc" (encryption) column. The command is not available on IOS-XR in the same form; instead, use `show crypto ikev1 sa detail` for detailed IKE SA information. Always check the specific platform documentation, as the command may be deprecated in favor of IKEv2 commands in newer releases.
Related Commands
Practice for the CCNA 200-301
Test your knowledge with practice questions covering all CCNA 200-301 exam domains.
Practice CCNA 200-301 Questions