cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2271
Views
1
Helpful
2
Replies

Router IKEv2 mismatched lifetime in profile works okay

NeverOutofTune
Level 1
Level 1

I configured two routers in Cisco Modeling Labs (CML) with IKEv2 IPSEC tunnels using SVTIs.

I purposely mismatched the lifetime timers in the IKEv2 profile.  r1 will use the default 86400 and r2 is set to 82800.  The tunnel works fine. Is this normal behavior for IKEv2 to work with mismatched lifetime timers?

r1:
crypto ikev2 profile r2_PROFILE
match identity remote address yy.yy.yy.4 255.255.255.255
identity local address xx.xx.xx.111
authentication remote pre-share
authentication local pre-share
keyring local r2_KEYRING

r2:
crypto ikev2 profile r1_PROFILE
match identity remote address xx.xx.xx.111 255.255.255.255
identity local address yy.yy.yy.4
authentication remote pre-share
authentication local pre-share
keyring local r1_KEYRING
lifetime 82800

r1#sho cry ikev2 sess
IPv4 Crypto IKEv2 Session

Session-id:2, Status:UP-ACTIVE, IKE count:1, CHILD count:1

Tunnel-id Local Remote fvrf/ivrf Status
2 xx.xx.xx.111/500 yy.yy.yy.4/500 none/none READY
Encr: AES-CBC, keysize: 256, PRF: SHA256, Hash: SHA256, DH Grp:14, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 86400/54 sec
Child sa: local selector 0.0.0.0/0 - 255.255.255.255/65535
remote selector 0.0.0.0/0 - 255.255.255.255/65535
ESP spi in/out: 0x1AC550DB/0xD172D15E

IPv6 Crypto IKEv2 Session


r2#sho cry ikev2 sess
IPv4 Crypto IKEv2 Session

Session-id:2, Status:UP-ACTIVE, IKE count:1, CHILD count:1

Tunnel-id Local Remote fvrf/ivrf Status
2 yy.yy.yy.4/500 xx.xx.xx.111/500 none/none READY
Encr: AES-CBC, keysize: 256, PRF: SHA256, Hash: SHA256, DH Grp:14, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 82800/38 sec
Child sa: local selector 0.0.0.0/0 - 255.255.255.255/65535
remote selector 0.0.0.0/0 - 255.255.255.255/65535
ESP spi in/out: 0xD172D15E/0x1AC550DB

IPv6 Crypto IKEv2 Session

r2#

 

 

1 Accepted Solution

Accepted Solutions

@NeverOutofTune As per the IKEv2 RFC - If the two ends have different lifetime policies, the end with the shorter lifetime will end up always being the one to request the rekeying. https://datatracker.ietf.org/doc/html/rfc5996

 

View solution in original post

2 Replies 2

Yes it normal behave of IKEv2

@NeverOutofTune As per the IKEv2 RFC - If the two ends have different lifetime policies, the end with the shorter lifetime will end up always being the one to request the rekeying. https://datatracker.ietf.org/doc/html/rfc5996