06-05-2013 11:01 AM
We are experiencing random communication failures between two sites over our VPN tunnel. Both sites have the same hardware specs (5585) and software version (8.4(3)9). Both sides have matching cryptomap ACLs, just mirror images of each other.
The problem is that over a random period of time, both sides will not be able to ping specific networks that are allowed to cross the tunnel. The issue is cleared by resetting the tunnel (clear crypto ipsec sa peer x.x.x.x). It doesn't matter what side the tunnel is cleared, to fix the problem. The problem I have is what is causing this behavior to occur? Has anyone experiencing this behavior before? If so, please share.
What is interesting as well is that say for example one time 10.10.10.1/24 (site A) can't ping 10.20.10.1/24 (site B) (this has worked before. Say on site A firewall I then reset the tunnel and now host 10.10.10.1 can ping 10.20.10.1. Now say another instance, 10.10.100.1 (site A) can't ping 10.20.100.1 (site B). This has also worked before. But what is interesting is that even though 10.10.100.1 can't see 10.20.100.1, 10.10.10.1 can ping 10.20.10.1. Again to clear the issue the site to site tunnel needs to be reset. If this were related to tunnel problems you would think all the networks allowed to pass the tunnel would be affected but they are not.
And yes, all settings have been verified to match on both ends.
07-17-2013 08:55 AM
I'm surprised this issue has not occured to other folks who use L2L tunnels.
07-17-2013 09:09 AM
can you get both sides configuration?
Sent from Cisco Technical Support iPad App
07-17-2013 01:22 PM
I had similar problems occasionaly on 5520's running 8.2(2); some subnets would in effect drop out of the IPsec L2L tunnel. This happened every 3-10 weeks for months. I had not tried your "clear crypto ipsec sa peer xxxx" fix; we were using a more brute force approach and reloading. It was a different pair of non-communicating subnets each time, always one on each side of the tunnel. I never did resolve it, but I haven't seen it recur so far since I upgraded to 9.0(2) two months ago.
-- Jim Leinweber, WI State Lab of Hygiene
07-17-2013 01:36 PM
Yeah reloading is not ideal in my production environment.
Do you know of any useful troubleshooting commands? I tried packet-tracer, but that was not useful for Cisco tac since they didn't find anything of the root cause.
They recommended running the following debug cmds next time this occurs:
deb cry cond peer
deb cry isa 200
deb cry ipse 200
The problem is I don't want this to occur again. Tech also recommended upgrading to 8.4.6. However, I'm contemplating upgrading to 9 based on what James mentioned earlier.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide