01-21-2013 08:41 AM
Hi,
I have the following test setup:
3945 ------- 7600 ------- ASR1001
On the 3945 I have lots (~100 each) of FVRFs and IVRFs configured.
On the 7600 lots of subinterfaces facing the 3945 FVRFs and 1 subinterface towards the ASR, all in a single VRF - simulating an Internet connectivity.
On the ASR I have a single FVRF (connected to the 7600) and a single IVRF to terminate all these tunnels.
The 3945 is supposed to simulate lots of CPEs connected on the ASR which is acting as a hub.
I'm using IKEv2 for the IPSEC tunnels and the configuration works fine when I'm using SVTI on both sides or when using a non-vrf configuration on the 3945.
When I change the configuration on the ASR side and use a virtual-template and RADIUS, I get the following debug messages on the ASR:
Jan 21 16:10:49.103 gmt: IKEv2:(SA ID = 2):Session with IKE ID PAIR (vrf1.ipsec.net, PE-IKE) is UP
Jan 21 16:10:49.103 gmt: IKEv2:(SA ID = 2):Initializing DPD, configured for 60 seconds
Jan 21 16:10:49.103 gmt: IKEv2:IKEv2 MIB tunnel started, tunnel index 2
Jan 21 16:10:49.103 gmt: IKEv2:Store mib index ikev2 2, platform 1569
Jan 21 16:10:49.103 gmt: IKEv2:(SA ID = 2):SM Trace-> SA: I_SPI=492464320A36D53F R_SPI=E740D23964983C40 (R) MsgID = 00000001 CurState: AUTH_DONE Event: EV_CHECK_DUPE
Jan 21 16:10:49.103 gmt: IKEv2:(SA ID = 2):Checking for duplicate IKEv2 SA
Jan 21 16:10:49.103 gmt: IKEv2:(SA ID = 2):No duplicate IKEv2 SA found
Jan 21 16:10:49.112 gmt: IKEv2:IKEv2 tunnel 2 stop, platform index 1569 reason 4
And on the 3945:
*Jan 21 16:25:06.568 UTC: IKEv2:(SA ID = 1):Session with IKE ID PAIR (PE-IKE, vrf1.ipsec.easynet.net) is UP
*Jan 21 16:25:06.568 UTC: IKEv2:(SA ID = 1):Initializing DPD, configured for 30 seconds
*Jan 21 16:25:06.568 UTC: IKEv2:IKEv2 MIB tunnel started, tunnel index 1
*Jan 21 16:25:06.568 UTC: IKEv2:Store mib index ikev2 1, platform 38
*Jan 21 16:25:06.568 UTC: IKEv2:(SA ID = 1):SM Trace-> SA: I_SPI=492464320A36D53F R_SPI=E740D23964983C40 (I) MsgID = 00000001 CurState: AUTH_DONE Event: EV_CHECK_DUPE
*Jan 21 16:25:06.568 UTC: IKEv2:(SA ID = 1):Checking for duplicate IKEv2 SA
*Jan 21 16:25:06.568 UTC: IKEv2:(SA ID = 1):No duplicate IKEv2 SA found
*Jan 21 16:25:06.568 UTC: IKEv2:(SA ID = 1):SM Trace-> SA: I_SPI=492464320A36D53F R_SPI=E740D23964983C40 (I) MsgID = 00000001 CurState: AUTH_DONE Event: EV_CHK4_ROLE
*Jan 21 16:25:06.568 UTC: IKEv2:(SA ID = 1):SM Trace-> SA: I_SPI=492464320A36D53F R_SPI=E740D23964983C40 (I) MsgID = 00000001 CurState: READY Event: EV_CHK_IKE_ONLY
*Jan 21 16:25:06.568 UTC: IKEv2:(SA ID = 1):SM Trace-> SA: I_SPI=492464320A36D53F R_SPI=E740D23964983C40 (I) MsgID = 00000001 CurState: READY Event: EV_DEL_SA
*Jan 21 16:25:06.568 UTC: IKEv2:(SA ID = 1):Queuing IKE SA delete request reason: unknown
*Jan 21 16:25:06.568 UTC: IKEv2:(SA ID = 1):SM Trace-> SA: I_SPI=492464320A36D53F R_SPI=E740D23964983C40 (I) MsgID = 00000001 CurState: READY Event: EV_FREE_NEG
*Jan 21 16:25:06.568 UTC: IKEv2:(SA ID = 1):Deleting negotiation context for my message ID: 0x1
*Jan 21 16:25:06.568 UTC: IKEv2:(SA ID = 1):SM Trace-> SA: I_SPI=492464320A36D53F R_SPI=E740D23964983C40 (I) MsgID = 00000001 CurState: READY Event: EV_IPSEC_DEL
*Jan 21 16:25:06.568 UTC: IKEv2:(SA ID = 1):Action: Action_Null
*Jan 21 16:25:06.568 UTC: IKEv2:(SA ID = 1):SM Trace-> SA: I_SPI=492464320A36D53F R_SPI=E740D23964983C40 (I) MsgID = 00000001 CurState: INFO_I_BLD_INFO Event: EV_SND_IPSEC_DEL
*Jan 21 16:25:06.568 UTC: IKEv2:(SA ID = 1):Sending DELETE INFO message for IPsec SA [SPI: 0xB15D57D0]
So it looks it's passing IKE then - for an unknown reason - IKE SAs are deleted.
IOS wise, I'm using 3.7.2 on the ASR and 15.2(4)M2 on the 3945.
Configs are:
ASR:
crypto ikev2 profile IKE-SVTI
match fvrf FVRF-SVTI
match identity remote fqdn domain ipsec.net
identity local key-id PE-IKE
authentication remote pre-share
authentication local pre-share
keyring aaa IPSEC-AUTHOR
aaa authorization user psk cached
virtual-template 2
crypto ipsec transform-set TFS-AES256-SHA-HMAC esp-aes 256 esp-sha-hmac
mode tunnel
crypto ipsec profile IKE-SVTI
set transform-set TFS-AES256-SHA-HMAC
set ikev2-profile IKE-SVTI
responder-only
interface Virtual-Template2 type tunnel
vrf forwarding test-svti
no ip address
tunnel source GigabitEthernet0/0/2.611
tunnel mode ipsec ipv4
tunnel vrf FVRF-SVTI
tunnel protection ipsec profile IKE-SVTI
end
I've tried the following:
- removing the vrf config from the Virtual-Template inteface (my initial config)
- adding the VRF to the IKE profile
RADIUS:
vrf1.ipsec.net
Tunnel-Password = 3945,
Framed-IP-Address=192.168.40.2,
Framed-IP-Netmask=255.255.255.252,
cisco-avpair="ip:interface-config=vrf forwarding test-svti",
cisco-avpair="ip:interface-config=ip address 192.168.40.1 255.255.255.252",
3945:
crypto ikev2 keyring IKE-KEYRING
peer ASR.VRF1
address 213.201.141.3
pre-shared-key 3945
!
crypto ikev2 profile IKE-VRF1
match fvrf FVRF1
match identity remote key-id PE-IKE
identity local fqdn vrf1.net
authentication remote pre-share
authentication local pre-share
keyring local IKE-KEYRING
!
crypto ipsec profile IKE-VRF1
set transform-set TFS-AES256-SHA-HMAC
set ikev2-profile IKE-VRF1
!
interface Tunnel401
ip vrf forwarding VRF1
ip address 192.168.40.2 255.255.255.252
tunnel source GigabitEthernet0/1.401
tunnel mode ipsec ipv4
tunnel destination 213.201.141.3
tunnel vrf FVRF1
tunnel protection ipsec profile IKE-VRF1
I've tried using "ip address negotiated" on the SVTI interface on the 3945 (my initial setup).
If I configure the ASR part as SVTI, everything works fine. Also, the RADIUS part works fine, I used it for non-VRF setup on the CPE.
The only configuration that fails is with VRFs on the 3945 side.
So I'm wondering if there is a limitation for this setup in terms of terminating both ends inside VRFs?
From the debugs I'm not clear which side decides to cut the SA.
Thank you,
Radu
01-22-2013 02:36 AM
To add more information to this:
- SVTI to SVTI works fine in exactly the same setup explained above (with VRFs on the CPE).
When I change it to DVTI on the PE (just by adding the virtual-template command to the IKE profile) the IPSEC cannot be established, IKEv2 passes OK then it drops when IPSEC is negociated.
SVTI config on the PE:
crypto ikev2 profile IKE-SVTI
match fvrf FVRF-SVTI
match identity remote fqdn domain ipsec.net
identity local key-id PE-IKE
authentication remote pre-share
authentication local pre-share
keyring aaa IPSEC-AUTHOR
aaa authorization user psk cached
!
crypto ipsec profile IKE-SVTI
set transform-set TFS-AES256-SHA-HMAC
set ikev2-profile IKE-SVTI
responder-only
!
interface Tunnel401
vrf forwarding test-svti
ip address 192.168.40.1 255.255.255.252
tunnel source GigabitEthernet0/0/2.611
tunnel mode ipsec ipv4
tunnel destination 172.20.0.2
tunnel vrf FVRF-SVTI
tunnel protection ipsec profile IKE-SVTI
end
DVTI config on the PE:
crypto ikev2 profile IKE-DVTI
match fvrf FVRF-SVTI
match identity remote fqdn domain ipsec.net
identity local key-id PE-IKE
authentication remote pre-share
authentication local pre-share
keyring aaa IPSEC-AUTHOR
aaa authorization user psk cached
virtual-template 2
crypto ipsec profile IKE-DVTI
set transform-set TFS-AES256-SHA-HMAC
set ikev2-profile IKE-DVTI
interface Virtual-Template2 type tunnel
no ip address
tunnel source GigabitEthernet0/0/2.611
tunnel mode ipsec ipv4
tunnel vrf FVRF-SVTI
tunnel protection ipsec profile IKE-DVTI
end
RADIUS account:
vrf001.ipsec.net
Tunnel-Password = 3945,
cisco-avpair="ip:interface-config=vrf forwarding test-svti",
cisco-avpair="ip:interface-config=ip address 192.168.40.1 255.255.255.252",
CPE config is kept the same for either SVTI/DVTI tests on the ASR, RADIUS account is the same in both cases.
A "debug crypto ike error" shows the following on the ASR (PE), when DVTI is used:
Jan 22 10:15:49.278 gmt: %IKEV2-5-SA_UP: SA UP
Jan 22 10:15:49.288 gmt: IKEv2:(SA ID = 4):There was no IPSEC policy found for received TS
Jan 22 10:15:49.288 gmt: IKEv2:(SA ID = 4):
Jan 22 10:15:49.288 gmt: %IKEV2-5-SA_UP: SA UP
Jan 22 10:15:49.289 gmt: %IKEV2-5-SA_DOWN: SA DOWN
Any ideeas?
05-16-2014 06:33 AM
I had exactly the same issue in our lab environment. Try configuring the remote as DVTI as well.
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