IKEv2 SA Resetting every minute or so.

[Daniel Smith]

We have an encrypted tunnel that is using ikev2 and ipsec. Those processes appear to be configured correctly, as the link comes up. However, the IGP over that link shows resetting every 30-70 seconds. Pings across the underlying transport have been solid during these times when IKEv2 resets as I have run 30000 pings from one end to the other, while watching the syslog from the far device and seeing the EIGRP down/up event. Further investigation shows that the Active time of the Ikev2 session is resetting:

r500s0u1wara#show crypto ikev2 sa remote 172.16.0.250
Tunnel-id Local Remote fvrf/ivrf Status
5 172.16.0.249/500 172.16.0.250/500 none/vrf-vida READY
Encr: AES-CBC, keysize: 256, PRF: SHA512, Hash: SHA512, DH Grp:14, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 86400/10 sec   <<<<<<<<<<<<<<<<<<<<

I have reviewed configurations as much as I know how, but unable to determine cause of the issue above. I have avoided debugging crypto on one device or the other at this time due to the nature of the devices at each end. Suggestions would be great!

[MHM Cisco World]

As I know IPsec not support multicast, you need GRE over IPsec. or other VPN to allow multicast between two IGP peer.

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/17-11/configuration_guide/sec/b_1711_sec_9300_cg/m9-1711-configuring-gre-over-ipsec.pdf

Thanks A Lot
MHM

[Daniel Smith]

Here is the tunnel configuration:

interface Tunnel501
description Tunnel_to_r500s0u1wara
ip address 10.36.13.250 255.255.255.252
no ip redirects
no ip unreachables
no ip proxy-arp
ip mtu 1400
ip authentication mode eigrp 1 md5
ip authentication key-chain eigrp 1 kc-eigrp-auth
ip hello-interval eigrp 1 1
ip hold-time eigrp 1 3
ip summary-address eigrp 1 10.32.0.0 255.255.128.0
ip tcp adjust-mss 1360
qos pre-classify
keepalive 3 3
tunnel source GigabitEthernet0/2/0.11
tunnel mode ipsec ipv4
tunnel destination 172.16.0.249
tunnel protection ipsec profile cip-flexvpn-5 shared

[MHM Cisco World]

this is IPsec IPV4 so it SVTI and must allow multicast pass through.
you use shared are you use tunnel source for other tunnel ?
if Yes then add 
tunnel key to this config 

[MHM Cisco World]

If not use tunnel source for other then remove shared keyword.

[Daniel Smith]

both ends of the same tunnel are configured with 'shared' keyword.

[Daniel Smith]

The G0/2/0.11 is only used by the tunnel501 and the ipsec profile cip-flexvpn-5 is only used on this tunnel. This is a turn key network that we have inherited.

[balaji.bandi]

What is the use case for EIGRP over Tunnel is this must ? most case if you have alternative path IGP is good use case, if this is only one exit you can consider static routing to fix the issue.

then look for GRE over IPSEC with IGP should solve the issue.

http://ithitman.blogspot.com/2015/11/configuring-gre-over-ipsec-w-routing.html

or try VTI

https://www.rekha.com/ipsec-vti-site-to-site-vpn.html

[Daniel Smith]

dynamic routing needed in support of multiple connections to the device.

[tvotna]

Is it possible that your EIGRP announces tunnel endpoint's (tunnel source / tunnel destination) subnets over the tunnel so that they become unreachable and tunnel goes down? If you don't want to run debugs, you can at least configure "crypto logging session" and check syslogs. Also, do you use DPD (crypto ikev2 dpd) or keepalives (keepalive CLI, which is a GRE-only feature)? They can bring down tunnel too.

[Daniel Smith]

You speak of 'recursive routing' which generates a syslog when it happens. I do not see that in this case.

[tvotna]

Right. But you should see line protocol down/up events. Do you? Can you share syslog? Do you see that IKEv2 SA and IPSec SAs come up when the tunnel is established *on both sides*? Do encrypt/decrypt counters increment on both sides when IPSec SA is UP? Does EIGRP adj. come up initially? Can you share respective outputs?

@MHM Cisco World, The "shared" keyword is ignored on SVTIs, because the whole concept of shared tunnel protection doesn't apply to this encapsulation type. @Daniel Smith , "keepalive" keyword ideally should be removed too, because this doesn't apply to SVTIs and is ignored too (its presence cannot cause the issue like this).