Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

Any reason for this strange behaviour..?

Hi All,

SiteA & SiteB with Vpn tunnel. SiteA :ASA5510 and SiteB:2811 router with VPN s/w.

At siteB , we moved the DSL connection to Cable connection and changed the all the necessary IPs and ACLs and also peer IP information on SiteA.

The tunnel never came up at that time and syslog popped up with QM FSM error (P2 struct&04e40918,mess id 0xc85b22b2)!

Surprisingly, without doing any further t-shoot Tunnel came up by itself after couple of hours.The onyl reason Iam tinking at this time for this behaviour is, during the tunnel lifetime renewal/restart(86400),it is established with new peer.

Can somebody suggest any other reason for this..?

Thanks in advance.


Cisco Employee

Re: Any reason for this strange behaviour..?


Did you clear the ISAKMP and IPSEC SA's on the ASA5510 for the IPSEC Tunnel to SiteA. It looks like while you were moving cable and reconfiguring the router, the ASA was still thinking that the IPSEC SA's were active.

The error (QM FSM) means it received a packet out of order. For instance you were trying

to establish a tunnel, a packet for step five and a packet for step six were

receive out of order. (or one wasn't received at all.) This could be caused by something

like the packets taking different paths.

It seems that after the tunnel went down, it just needed to clear the SA's on both sides

of the tunnel, in order to bring the tunnel up again.

Below is an URL with some IP Security Troubleshooting Steps. I hope you find it useful.



** Please rate all helpful posts **

Re: Any reason for this strange behaviour..?

Hi Arul,

Good point. Thank you. I did not clear any SAs before moved to Cable. Also, I used 'no tunnel-group x.x.x.x ip-sec attributes' on ASA at SITEA to remove existing SITEB info and then added the new IP peer info. So that also might have caused the issue (clear .... - may be preferred command). Thank you for the reply.



Cisco Employee

Re: Any reason for this strange behaviour..?

Hi, Whenever you change the ip addressing scheme in you network, it is better to follow the steps mentioned below:

1.If possible remove the crypto map from the interface of both the devices.

2. Clear all the phase-1 and phase-2 settings for both firewall and router. The commands will be:

For Firewall:

clear crypto isakmp sa

clear crypto ipsec sa

For router:


clear crypto isakmp


clear crypto sa peer

Note: In the router, If you do:

sh crypto isakmp sa, it will give you the following columns:

dst src state conn-id slot status

So, whatever be the conn-id for a specific tunnel you have to delete that

3. After that reapply the crypto map's on both the devices and then try to initiate the interesting traffic across vpn and check the status.


Check link:

The 2nd paragraph states: "Binding a crypto map to an interface also initializes run-time data structures, such as the security association database and the security policy database. If the crypto map is modified in any way, reapplying the crypto map to the interface resynchronizes the various run-time data structures with the crypto map configuration. In addition, any existing connections are torn down and reestablished after the new crypto map is triggered.

Hope that helps!