217
got NOTIFY of type INVALID_ID_INFORMATION
Or
drop message from A.B.C.D due to notification type INVALID_ID_INFORMATION
Solution
Verify that the ACLs in the IPsec policies configured on the interfaces at both ends are compatible.
Configure the ACLs to mirror each other. For more information about ACL mirroring, see
"Configuring IPsec."
Proposal mismatch
Symptom
The proposals mismatch.
Analysis
The following is the debugging information:
got NOTIFY of type NO_PROPOSAL_CHOSEN
Or
drop message from A.B.C.D due to notification type NO_PROPOSAL_CHOSEN
The two parties in the negotiation have no matched proposals.
Solution
For the negotiation in phase 1, look up the IKE proposals for a match.
For the negotiation in phase 2, verify that the parameters of the IPsec policies applied on the
interfaces are matched, and that the referred IPsec transform sets have a match in protocol,
encryption and authentication algorithms.
Failed to establish an IPsec tunnel
Symptom
The expected IPsec tunnel cannot be established.
Analysis
Sometimes this might happen if an IPsec tunnel cannot be established or there is no way to
communicate in the presence of an IPsec tunnel in an unstable network.
If ACLs of both parties are configured correctly, and proposals are also matched, the problem is
usually caused by the reboot of one router after the IPsec tunnel is established.
Solution
• Use the display ike sa command to verify that both parties have established an SA in phase 1.
• Use the display ipsec sa policy command to verify that the IPsec policy on the interface has
established IPsec SA.
• If the two commands show that one party has an SA but the other does not, use the reset ipsec
sa command to clear the IPsec SA that has no corresponding SA, use the reset ike sa
command to clear the IKE SA that has no corresponding IKE SA, and trigger SA re-negotiation.
To Next Page
Loading...
Need help?
General
