取消
显示结果 
搜索替代 
您的意思是: 
cancel
2777
查看次数
0
有帮助
4
回复

IPsec TUNNEL EXPERIENCING HUGE PACKET LOSS (FLAPPING LINK

Jesutofunmi O
Level 1
Level 1

Hello Guys, 

 

I have an IPsec VPN between a Cisco ASA 5515x and a Cisco 4331K9. The tunnel has been fine for a couple of months but suddenly started flapping and experiencing huge packet drops. I had thought it was an interface duplex config issue from my ISP. I adjusted settings but issue persisted. Attached are three files. One consists only the IPsec config on both routers (433K9 and ASA), the second one has the config for only the ASA and the last one has the config for only the iOS 4331K9. 

 

Kindly help!!!

1 个已接受解答

已接受的解答

no matching crypto map entry for remote proxy 172.16.130.0/255.255.254.100/0/0 local proxy 0.0.0.0/0.0.0.0/0/0 on interface outside

Looking at your configs, I can see an extra crypto ACL side on the ISR :

ip access-list extended Abuja-IV
 permit ip 172.16.130.0 0.0.0.255 192.168.0.0 0.0.0.255
 permit ip 172.16.130.0 0.0.0.255 172.16.120.0 0.0.7.255
 permit ip 172.16.130.0 0.0.1.155 any

 

Keep the ACL's the same on both sides. What might be happening is that there is some traffic triggering the Phase 2 tunnel from the ISR side. Since it cannot establish completely, it might be tearing down Phase 1 as well. 

在原帖中查看解决方案

4 条回复4

Rahul Govindan
VIP Alumni
VIP Alumni

Run debugs on both the ASA and ISR. Since it is flapping constantly, there should be some log as to why this is happening. Also, do you see any logs on the ASA or ISR when the tunnel flaps?

 

On the ASA, run these debugs:

 

debug crypto ikev1 127

debug crypto ipsec 127

 

On the ISR:

 

debug crypto isakmp

debug crypto ipsec

Hello @Rahul Govindan

 

Please find attached.

no matching crypto map entry for remote proxy 172.16.130.0/255.255.254.100/0/0 local proxy 0.0.0.0/0.0.0.0/0/0 on interface outside

Looking at your configs, I can see an extra crypto ACL side on the ISR :

ip access-list extended Abuja-IV
 permit ip 172.16.130.0 0.0.0.255 192.168.0.0 0.0.0.255
 permit ip 172.16.130.0 0.0.0.255 172.16.120.0 0.0.7.255
 permit ip 172.16.130.0 0.0.1.155 any

 

Keep the ACL's the same on both sides. What might be happening is that there is some traffic triggering the Phase 2 tunnel from the ISR side. Since it cannot establish completely, it might be tearing down Phase 1 as well. 

Hey Rahul, 

 

Thanks so much for spotting that out. I noticed the alien ACL in the debugs, searched for the affected subnet in my config but couldn't find it for odd reasons. I was apparently focused on the numbered ACLs (100, 101, 102...especially the ones with deny statements) but then forgot to look through the most important one (permit ACL). ACLs were obviously conflicting. 

 

You're helpful, thank you!