07-08-2008 03:52 AM - edited 02-21-2020 03:48 PM
Does "pkts no sa (send)" mean that SA's are timing out too quickly? How can I mitigate this problem?
Router#sh crypto ipsec sa detail
interface: GigabitEthernet0/0
Crypto map tag: lajesvpn, local addr 208.4.63.99
protected vrf: (none)
local ident (addr/mask/prot/port): (192.168.62.61/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (192.168.62.60/255.255.255.255/47/0)
current_peer 132.30.100.20 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 11924940, #pkts encrypt: 11924940, #pkts digest: 11924940
#pkts decaps: 11268741, #pkts decrypt: 11268741, #pkts verify: 11268741
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#pkts no sa (send) 31986, #pkts invalid sa (rcv) 0 <==
#pkts encaps failed (send) 0, #pkts decaps failed (rcv) 0
#pkts invalid prot (recv) 0, #pkts verify failed: 0
#pkts invalid identity (recv) 0, #pkts invalid len (rcv) 0
#pkts replay rollover (send): 0, #pkts replay rollover (rcv) 0
##pkts replay failed (rcv): 0
#pkts internal err (send): 0, #pkts internal err (recv) 0
local crypto endpt.: 208.4.63.99, remote crypto endpt.: 132.30.100.20
path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/0
current outbound spi: 0xF7E734A3(4159124643)
inbound esp sas:
spi: 0x535C185(87409029)
transform: esp-3des esp-md5-hmac ,
in use settings ={Tunnel, }
conn id: 3010, flow_id: Onboard VPN:10, crypto map: lajesvpn
sa timing: remaining key lifetime (k/sec): (4376668/1083)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xF7E734A3(4159124643)
transform: esp-3des esp-md5-hmac ,
in use settings ={Tunnel, }
conn id: 3021, flow_id: Onboard VPN:21, crypto map: lajesvpn
sa timing: remaining key lifetime (k/sec): (4373069/1083)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
07-14-2008 08:35 AM
Use the following two commands and reinitiate the connection.
clear crypto isakmp-Clears the Phase 1 security associations.
clear crypto sa-Clears the Phase 2 security associations
07-16-2008 07:16 AM
Interestingly, the IPSec tunnel went down by itself and came back up. The statement in question no longer appears in the "sh crypto ipsec sa" command.
07-16-2008 07:17 AM
Do you know what was the cause of this message?
07-29-2008 02:17 AM
we have a had the same issues since deploying a new code. ( 12.4-19.18T6) where GRE IPsec restarts tunnels after a random time period. Generating a lot of the no SA send messages.
Did you manage to get a response or fix ?
07-29-2008 03:19 AM
No, I did not get further response or fix on this issue. However, I use 12.4(17a) on the IPSec hub router and have a separate hub for GRE tunnels. I also experience the same problem where GRE tunnels restart after a random period due to EIGRP hello expired. I am currently looking into applying IP MTU and IP TCP MSS-Adjust on the Tunnel interface. I will monitor the results.
07-29-2008 03:27 AM
have a look at bug ID CSCsm93047 that might explain it.
07-29-2008 03:33 AM
Currently, I have hub-and-spoke setup for both IPSec VPN and GRE Tunnel. I am not certain if this bug applies to my current setup. However, I will definitely keep this in mind when I migrate to DMVPN setup.
07-29-2008 03:43 AM
yeah only applies if your using tunnel protection on your GRE i think.
07-29-2008 03:45 AM
Correct.
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