ASA 上的 peer reset 只清除 IPsec SA，不动 IKE 状态与会话

某个应用断了隧道，有人执行了一条限定 peer 的 IPsec clear，工单因为命令被接受就关掉了。整个过程没有任何一步证明故障被修复。在 ASA 上，reset 一词涵盖三个彼此独立的范围，而限定 peer 的 clear 只触及其中一个，所以同一条隧道常常在运维人员读完输出之前就已经重新建立。

一个词背后的三个范围

一对 IPsec SA 就是数据通道本身，每个方向一条关联，带序列号和计数器。IKE SA 是产生这些关联、并且仍然维持对端关系的协商通道。VPN 会话是会话数据库中某个用户、某个站点到站点对端或无客户端接入的记录。

三个范围彼此足够独立，清掉一个，其他仍然工作，而这种独立正是大部分混乱的来源。在 IKE SA 健康时清掉 IPsec SA，流量会在几秒内触发新的关联，于是隧道看起来不治而愈。但底层的提案不匹配、路由缺口或身份验证失败依然存在。

如果故障出在协商层，IPsec clear 不会改变任何可观测的结果。

趁状态还在的时候读出来

动手之前先记录对端地址、使用的 IKE 版本、受保护的网段以及双向计数器。可用的查看命令随版本不同，但形态稳定：show crypto ipsec sa peer、show crypto ikev2 sa detailed 或 IKEv1 的对应命令，以及会话层的 show vpn-sessiondb。

把时间戳和用户看到的准确故障写在那份输出旁边。一个对端通常承载多个受保护网段，所以限定 peer 的 clear 影响范围是该对端上的每一个选择器，而不是工单里的那一个应用。没有事前快照的 reset 事后无法诊断，因为 clear 删掉的正是你要拿来比较的计数器。

先留证据。clear 会把它抹掉，事后补的截图只能说明什么被重建，说明不了什么坏了。

限定 peer 的 clear 到底做了什么

Cisco 的 clear 命令参考 记录了限定 peer 的 IPsec 形式。换成文档地址后，它长这样：

clear crypto ipsec sa peer 198.51.100.42

这条命令拆掉与该对端匹配的 IPsec 关联。它不移除 IKE SA，不删除配置，也不重置会话数据库。请从不依赖这条隧道的管理路径执行，因为走在这条隧道里的 SSH 会话会随之断开，而且未必能自己回来。设备上其他一切照常运行，这正是这条命令显得无害的原因。

找不到确定目标时，不要退回不带限定的 clear。更宽的形式会波及设备上的每一个对端，你造成的故障会比被叫来处理的那个更大。

验证你本来想修的那一层

clear 之后，确认关联是带着新计数器回来的，而不是因为对端列表又满了就认定重置生效。然后测试工单点名的应用，因为 ping 通并不能说明服务权限或会话过期的问题。

如果关联重建了而应用仍然失败，剩下的候选就是 IKE 层和会话层。选那个你还能看状态的一层。按实际运行的版本使用对应的定点操作：IKEv2 clear、IKEv1 clear，或限定正确会话类型的会话数据库 clear。为了让隧道重建而删除并重建持久 crypto-map 配置，是代价更大的猜测。

带着前后两张快照上报，而不是再清一次。

当 reset 反而拉长故障时

反复 clear 会掩盖 reset 根本修不了的故障：路由缺失、选择器与新网段不再匹配、单侧改过的预共享密钥，或是在对端不会接受的提案上反复失败的重协商。每一次 clear 都会打断该对端所有选择器上的正常流量，而真正的根因原地未动。五分钟的排查就这样变成一次变更窗口。

有边界的 reset 仍然有用。有用的版本是有目标、有记录，并且跟着检查它本该修好的那一层。

工作顺序：记录对端、版本、选择器和计数器；确认故障属于哪个范围；执行最窄的匹配 clear；验证关联与应用；如果该层恢复但症状仍在，带着证据上报。