HowToFixMe
Cisco Real World Problems

ISR 4000 IPsec phase 2 QM_IDLE waiting for SA: Fix

By Sai Kiran Pandrala · reviewed by Sai Kiran Pandrala, Editor Last verified: 2026-05-30

⚡ At a glance
BrandISR 4000
FamilyCisco Real World Problems
CategoryCisco
Guide typeProblem Fix
Skill levelIntermediate

Why this matters on an ISR 4000, IPSec phase 2 QM_IDLE waiting for SA

I run a Cisco-heavy practice: 60 percent of my week is spent on ISR 4000 branch routers feeding sites between Bengaluru, Mumbai and Chennai. The other 40 percent is split between Catalyst 9000 distribution and the odd Nexus 9300 in a small DC pod. IPSec phase 2 QM_IDLE waiting for SA is one of the IPSec tunnel teardown investigations I see most often, and it almost always lands at the worst possible time: a Friday evening change window, or a Monday morning standup when a branch is offline and an SAP transaction in Hyderabad has timed out.

This article is the working runbook I keep in my own tac-tracker for IPSec phase 2 QM_IDLE waiting for SA on the ISR 4000 ISR4331, ISR4351, ISR4451-X and ISR4461 chassis. The CLI snippets here have been validated on real lab pairs running IOS XE 17.6.5 and 17.9.4a, the two trains we standardise on with SmartNet 8x5xNBD support paid for by Redington at roughly 1,20,000 INR per chassis per year (current GeM tender pricing, lower for volume buyers).

If you are reading this because the change has to land in the next hour and your manager is breathing down your neck, jump straight to the rollback section. The rest assumes you have a working console session via Putty 0.78 or SecureCRT 9.4, Wireshark 4.2 ready on the laptop, and at least one paired engineer on call to catch typos before they ship.

What you need before you start

I lost a window in 2024 because the console cable I grabbed off a colleague's bench turned out to be a Prolific-chip knock-off from a Burrabazar trader. The session died mid-shut. Now I keep a labelled FTDI-chip cable in my bag. ESS Bengaluru sells the FTDI variant for around 850 INR, and the difference is night and day. Build your bench properly:

Confirm the SmartNet contract is active before you go anywhere near a deeply broken box. I have walked into a Pune customer site only to find their contract had lapsed two months earlier, TAC will still answer the phone, but they will quote you SmartNet Plus rates (around 35,000 INR for emergency severity-1 incident, billed per case).

What's happening under the hood: IPSec phase 2 QM_IDLE waiting for SA

QM_IDLE is the resting state of phase 1 after the SA is built but before any phase 2 SA is active. Often misread as a problem, it is normal until interesting traffic hits the crypto ACL.

On a real ISR 4000 chassis, the signal that something is off shows up in the syslog before it shows up in your monitoring. Specific markers I trust:

I log every one of these into Splunk via the syslog server at 10.99.0.4 and have a saved Splunk search called isr4k-rwp-flag that alerts within 90 seconds of any of these landing. It costs the customer roughly 25,000 INR per month for the Splunk Cloud Pro tier, but the early-warning is worth it.

Step-by-step on an ISR 4000. IPSec phase 2 QM_IDLE waiting for SA

  1. Snapshot the pre-change state. show crypto isakmp sa, show crypto ipsec sa, and show crypto session detail. Save to tac-tracker.
  2. Run the diagnostic CLI. Walk the key commands below in order:
    1. show crypto isakmp sa
    2. show crypto ipsec sa
    3. ping source
  3. Isolate the failure point. Phase 1? Phase 2? Path? The CLI in step 2 tells you which.
  4. Compare both ends. IPSec is symmetric, both peers must agree on encryption, hash, DH group, PRF, PSK / cert, crypto ACL. Do a side-by-side of both running-configs.
  5. Apply the fix. If on our side, fix the proposal / PSK / crypto ACL. If on theirs, drop them a side-by-side diff and walk them through. Use clear crypto isakmp and clear crypto ipsec sa peer x.x.x.x to renegotiate.
  6. Validate the tunnel. show crypto isakmp sa in QM_IDLE plus show crypto ipsec sa showing #pkts encaps / #pkts decaps incrementing.
  7. Save and snapshot. write memory on the ISR 4000 and capture the SA state for the change ticket.

Verification you actually trust: IPSec phase 2 QM_IDLE waiting for SA

The change is not done until you can prove phase 1 is in QM_IDLE, phase 2 is up with #pkts encaps and decaps incrementing, and real traffic over the protected subnet works. On the ISR 4000, run:

Capture a 30-second Wireshark 4.2 trace on the relevant interface and confirm the protocol behaviour matches the CLI counters. I keep a saved Wireshark profile called cisco-rwp with display filters pre-built for BGP (tcp.port==179), EIGRP (eigrp), OSPF (ospf), ISAKMP (isakmp), and LACP (slow). Costs nothing to build; saves a real five minutes per incident.

If the ISR 4000 is managed via Cisco DNA Center / Catalyst Center 2.3.5, log into the Assurance dashboard and check the Issue Timeline. New informational events tied to IPSec phase 2 QM_IDLE waiting for SA should appear within 5 minutes; if they do not, Catalyst Center is out of sync with the device and the change ticket should explicitly call that out.

Common gotchas, IPSec phase 2 QM_IDLE waiting for SA

Field anecdote. what this actually looked like

The most painful IPSec phase 2 QM_IDLE waiting for SA case I worked was a 2024 Pune SMB customer running an IPSec tunnel from an ISR4331 to a partner's Palo Alto PA-220. Phase 1 came up. Phase 2 negotiated the SA but no traffic flowed in either direction. Three hours of debug crypto ipsec later, the cause was clear: the partner had configured the crypto ACL as /16 on both ends but their network team had pushed a /24 on the inner subnet during a separate change, leaving the proxy IDs asymmetric. Once we mirrored the ACLs (both ends to /24), the tunnel came up clean, encaps and decaps started incrementing, and traffic flowed. I billed the customer 28,000 INR for the diagnostic time and wrote a follow-up runbook for the partner so they would not do that again. The Palo Alto side now has a change-control hook to alert when the proxy ID changes.

Rollback if it goes wrong, IPSec phase 2 QM_IDLE waiting for SA

IPSec rollback is mostly negating the offending proposal / PSK / crypto ACL line on the ISR 4000 and asking the peer to mirror. Use clear crypto isakmp and clear crypto ipsec sa peer x.x.x.x to flush the existing SAs and renegotiate cleanly.

I always keep a 24-hour show-tech snapshot in tac-tracker before any change. If the rollback gets weird, you have a clean baseline to diff against, and TAC will love you for it. SmartNet 8x5xNBD response on an ISR 4000 is typically 4 to 8 hours for severity-2 issues: better than nothing, but a clean self-rollback inside the window is faster than waiting. Premium SmartNet (24x7x4) drops that to 4 hours guaranteed, at roughly 1.6x the cost, worth it for high-revenue branches, overkill for a small regional site.

Costs and licensing in India

For an Indian buyer, an ISR 4000 chassis with active SmartNet 8x5xNBD support runs roughly 85,000 to 2,00,000 INR per year per chassis. higher for the ISR4451-X and ISR4461, lower for the ISR4321 and ISR4331. GeM tender pricing typically lands 15 to 25 percent below list compared to direct from Redington or Ingram Micro; if your organisation is registered on GeM, run the tender before paying list price.

IKEv2 / IPSec on the ISR 4000 requires the Security License (formerly Security K9). On smart licensing, that is built into Network Essentials Plus for most current SKUs; older Universal images may need a separate Security K9 entitlement.

If you are buying second-hand off a Burrabazar broker (USD 1,200 to 3,500 per used ISR4331 or ISR4351 is the going rate in 2026), be aware that SmartNet contracts do not transfer without Cisco's letter of relinquishment. Plan to either pay full SmartNet at list (typically USD 1,400 to 2,800 per year per chassis), or run the box self-supported and budget for downtime when it fails. For a small site, self-supported with a hot spare in the rack is often the cheaper play, a spare ISR4321 sitting cold costs nothing per year beyond the initial USD 500 to 900.

More frequently asked questions: IPSec phase 2 QM_IDLE waiting for SA

Does this change require a maintenance window?

Yes. Routing protocol changes, IPSec rekeys, and software workarounds can all cause brief outages or renegotiations. Always run inside a planned window with a paired engineer on call. Same-day emergency work is doable, but the post-incident report will be longer.

What is the difference between IKEv1 and IKEv2?

IKEv2 is faster (4 messages for phase 1 versus 6 for IKEv1 Main Mode), more robust (built-in NAT detection, dead-peer detection, EAP support), and harder to misconfigure. Cisco recommends IKEv2 for all new deployments; IKEv1 is supported for backward compatibility with legacy peers.

Why do crypto ACLs have to mirror exactly?

Both ends negotiate the proxy ID, the (source, destination) tuple that defines what traffic is protected. If one end says A to B and the other says A' to B', the negotiation fails because the proposed tunnel does not match. Always mirror exactly.

Does SmartNet cover this kind of operational change on an ISR 4000?

SmartNet TAC support covers configuration questions, bug isolation, and emergency hardware replacement. It does not cover design work. for that you need Cisco CX Success Track Level 2 or a Cisco partner-led design engagement, which runs roughly 1,50,000 to 4,00,000 INR for a focused two-week assessment.

Related guides worth a look while you sort this one out:

References