reset ike sa

Function

The reset ike sa command clears information about SAs established through IKE negotiation.

Format

reset ike sa [ conn-id conn-id | remote { ipv4-address | ipv6-address } ] [ slot slot-id cpu cpu-id ]

Parameters

Parameter	Description	Value
conn-id conn-id	Specifies the connection ID of an SA.	The value is an integer that ranges from 1 to 4294967295.
remote ipv4-address	Specifies the IPv4 address of the remote end.	The value is in dotted decimal notation.
remote ipv6-address	Specifies the IPv6 address of the remote end.	The value is in colon hexadecimal notation.
slot slot-id cpu cpu-id	Specifies information about SAs with the specified slot ID and CPU ID. Only the USG6635E/6655E, USG6680E and USG6712E/6716E support this parameter.	The values of slot-id and cpu-id are integers and must be set according to the device configuration.

Views

User view

Default Level

3: Management level

Usage Guidelines

Usage Scenario

To clear an IPSec tunnel established through IKE negotiation, run the reset ike sa command to clear the IKE SA that is used to negotiate the IPSec tunnel.

There are two types of SAs established through IKE negotiation. The IKE SA in phase 1 is used for IKE negotiation, and the IPSec SA in phase 2 is established under the protection of the IKE SA in phase 1 to protect data flows.

If the specified conn-id corresponds to an IKE SA in phase 1, the IKE SA and associated IPSec SA are deleted. In this case, the following situations may occur:
- If the device establishes an IPSec tunnel in site-to-multisite mode, the device does not automatically negotiate and re-establish an IKE SA. Instead, the peer device triggers IPSec tunnel negotiation.
- If the device establishes an IPSec tunnel in site-to-site mode and the IPSec SA is in automatic triggering mode, the device automatically negotiates and re-establishes an IKE SA. The IPSec SA is automatically established after the IKE SA is established.
- If the device establishes an IPSec tunnel in site-to-site mode and the IPSec SA is in traffic-based triggering mode, the device does not automatically negotiate and re-establish an IKE SA. The device negotiates and re-establishes an IKE SA only when the data flow matches the ACL referenced in the IPSec policy again. In addition, the device establishes an IPSec SA based on the ACL matched by the data flow.
If the specified conn-id corresponds to an IPSec SA in phase 2, the IPSec SA is deleted. In this case, the following situations may occur:
- If the device establishes an IPSec tunnel in site-to-multisite mode, the device does not automatically negotiate and re-establish an IPSec SA. Instead, the peer device triggers IPSec tunnel negotiation.
- If the device establishes an IPSec tunnel in site-to-site mode and the IPSec SA is in automatic triggering mode, the device automatically negotiates and re-establishes the IPSec SA in phase 2 under the protection of the IKE SA in phase 1.
- If the device establishes an IPSec tunnel in site-to-site mode and the IPSec SA is in traffic-based triggering mode, the device does not automatically negotiate and re-establish an IPSec SA. The device negotiates and re-establishes an IPSec SA in phase 2 only when data flows match the ACL referenced in the IPSec policy again.
If conn-id is not specified, all SAs are deleted. The SA re-establishment is the same as that when "the specified conn-id corresponds to an IKE SA in phase 1".

Precautions

After dependency between IPSec SA and IKE SA during IKEv1 negotiation is disabled using the undo ikev1 phase1-phase2 sa dependent command, running the reset ike sa conn-id command to delete an IKE SA will also delete the corresponding IPSec SA.

Example

# Clear IKE SAs in both phases.

<sysname> reset ike sa