ASA peer reset clears IPsec SAs, not IKE state or sessions
One peer-scoped clear only tears down the IPsec data path. See what survives, why the tunnel rebuilds in seconds, and which layer to clear instead.
The tunnel drops for a single application, someone runs a peer-scoped IPsec clear, and the ticket gets closed because the command was accepted. Nothing in that sequence shows the fault was repaired. On an ASA the word reset covers three separate scopes, and the peer-scoped clear touches exactly one of them, which is why the same tunnel is often back up before the operator has finished reading the output.
Three scopes hide behind one word
An IPsec SA pair is the data path itself, one association per direction, with sequence numbers and counters. An IKE SA is the negotiation channel that produced those associations and is still holding the peer relationship together. A VPN session is the record in the session database for a user, a site-to-site peer or a clientless connection.
| Scope | What a clear removes | What usually survives |
|---|---|---|
| IPsec SA | Data-path associations for the matching peer or selector | IKE SA, session records, crypto-map or tunnel-group config |
| IKE SA | Negotiation channel and the IPsec children derived from it | Session records until they age out or are cleared |
| VPN session | Session-database entry for that user or peer type | Configuration, and any SA that is not tied to the session |
The scopes are independent enough that clearing one leaves the others working, and that independence produces most of the confusion. Clear the IPsec SAs while the IKE SA is healthy and traffic triggers fresh associations within seconds, so the tunnel appears to have healed itself. The underlying proposal mismatch, route gap or authentication failure is still there.
If the fault lives at negotiation, an IPsec clear changes nothing you can observe.
Read the state while it still exists
Record the peer address, the IKE version in use, the protected networks and the directional counters before touching anything. The supported views differ by release, but the shapes are stable: show crypto ipsec sa peer, show crypto ikev2 sa detailed or the IKEv1 equivalent, and show vpn-sessiondb for the session layer.
Write down the timestamp and the exact user-visible failure next to that output. One peer commonly carries several protected networks, so the blast radius of a peer-scoped clear is every selector on that peer, not the single application in the ticket. A reset without a before-picture cannot be diagnosed afterwards, because the clear deletes the very counters you would have compared against.
Capture the evidence first. The clear removes it, and a screenshot taken afterwards tells you what rebuilt, not what was broken.
What the peer-scoped clear actually does
Cisco's clear-command reference documents the peer-scoped IPsec form. With a documentation address substituted, it looks like this:
clear crypto ipsec sa peer 198.51.100.42That command tears down the IPsec associations matching the peer. It does not remove the IKE SA, does not delete configuration, and does not reset the session database. Run it from a management path that does not depend on the tunnel you are changing, because an SSH session carried inside that tunnel will die with it and may not come back on its own. Everything else on the device keeps running, which is exactly why the command feels harmless.
When target lookup is uncertain, do not fall back to an unqualified clear. The broader form reaches every peer on the device, and the outage you create will be larger than the one you were called about.
Verify the layer you meant to fix
After the clear, confirm that associations came back with fresh counters rather than assuming the reset worked because the peer list repopulated. Then test the application the ticket named, since a successful ping says nothing about a service permission or an expired session.
If the associations rebuild and the application still fails, the remaining candidates are the IKE layer and the session layer. Pick the one whose state you can still inspect. Use the targeted operation for the version actually running, whether that is an IKEv2 clear, an IKEv1 clear or a session-database clear scoped to the right session type. Deleting and recreating persistent crypto-map configuration to force a rebuild is guesswork with a longer rollback.
Escalate with both pictures, before and after, instead of clearing again.
When the reset makes the outage longer
Repeated clears hide the faults that a reset cannot fix: a missing route, a selector that no longer matches the new subnet, a pre-shared key changed on one side, or a rekey that keeps failing on a proposal the peer will not accept. Each clear interrupts healthy traffic on every selector of that peer while the real cause stays untouched. That is how a five-minute investigation turns into a change window.
A bounded reset is still useful. The useful version is scoped, recorded and followed by an inspection of the layer it was supposed to repair.
Order of work: capture peer, version, selectors and counters; confirm which scope the fault belongs to; run the narrowest clear that matches; verify associations and the application; escalate with evidence if the layer recovers but the symptom does not.