cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
932
Views
0
Helpful
3
Replies

FLEXVPN dual hub dual cloud with HA issue

Kach
Level 1
Level 1

Hi all, 

PS: I am using

  • EVE-NG version: 2.0.3-59
  • QEMU version: 2.4.0
  • Cisco IOL 15.4 (cf.EVE_ROUTER file attached)

I am trying to build a flexvpn dual hub dual cloud architecture with BGP as the overlay routing protocol.

- Primary Hub (server) is RT-Auber (in France)

- Secondary Hub (server) is RT-Ashburn (in the USA). 

Both Hubs (or FlexVPN servers) are also BGP route reflectors.

- RT-BR1 and RT-SG1 are spoke sites.

 

The L2L tunnel is well created and everything is OK with the first Hub.

 

BR_LAN#traceroute 172.19.248.1 source loopback 0
Type escape sequence to abort.
Tracing the route to 172.19.248.1
VRF info: (vrf in name/id, vrf out name/id)
1 172.24.32.11 1 msec 0 msec 1 msec
2 192.168.200.17 0 msec 0 msec 1 msec
3 172.16.100.1 1 msec 1 msec 0 msec       <<<<<<<< RT-AUBER
4 172.16.100.42 1 msec 6 msec 1 msec
5 192.168.200.42 1 msec 1 msec 5 msec
6 172.19.43.12 7 msec * 2 msec
BR_LAN#
BR_LAN#
BR_LAN#traceroute 172.19.248.1 source loopback 0
Type escape sequence to abort.
Tracing the route to 172.19.248.1
VRF info: (vrf in name/id, vrf out name/id)
1 172.24.32.11 0 msec 0 msec 0 msec
2 192.168.200.17 0 msec 1 msec 0 msec
3 172.16.100.42 1 msec 1 msec 1 msec      <<<< Directly going to RT-SG1. No more RT-Auber IP @ 
4 192.168.200.42 1 msec 1 msec 1 msec
5 172.19.43.12 1 msec * 2 msec
BR_LAN#

 

 

RT-SG1#sh cry sess
Crypto session current status

Interface: Tunnel1
Profile: IKEV2-ZONE1
Session status: UP-ACTIVE
Peer: 145.40.40.2 port 500
Session ID: 1
IKEv2 SA: local 145.40.40.42/500 remote 145.40.40.2/500 Active
IPSEC FLOW: permit 47 host 145.40.40.42 host 145.40.40.2
Active SAs: 2, origin: crypto map

Interface: Virtual-Access1
Profile: IKEV2-ZONE1
Session status: UP-ACTIVE
Peer: 145.40.40.18 port 500
Session ID: 2
IKEv2 SA: local 145.40.40.42/500 remote 145.40.40.18/500 Active
IPSEC FLOW: permit 47 host 145.40.40.42 host 145.40.40.18
Active SAs: 2, origin: crypto map

RT-SG1#

 

 

But when i simulated the failover by shutting the primary hub WAN interface down, nothing goes through the virtual-access1 anymore. the ping reaches the destination going through the RT-Ashburn hub router.  

When I clear the dmvpn session on RT-BR1 & RT-SG1 routers, a new virtual-access 1 is created but its state is DOWN and the L2L traceroute still shows Ashburn router tunnel IP address

 

BR_LAN#traceroute 172.19.248.1 source loopback 0
Type escape sequence to abort.
Tracing the route to 172.19.248.1
VRF info: (vrf in name/id, vrf out name/id)
1 172.24.32.11 0 msec 0 msec 0 msec
2 192.168.200.17 1 msec 0 msec 1 msec
3 172.16.200.1 1 msec 1 msec 0 msec      <<<<<<<< RT-Ashburn
4 172.16.200.42 1 msec 1 msec 1 msec
5 192.168.200.42 2 msec 1 msec 1 msec
6 172.19.43.12 1 msec * 2 msec
BR_LAN#
BR_LAN#
BR_LAN#traceroute 172.19.248.1 source loopback 0
Type escape sequence to abort.
Tracing the route to 172.19.248.1
VRF info: (vrf in name/id, vrf out name/id)
1 172.24.32.11 1 msec 0 msec 0 msec
2 192.168.200.17 1 msec 0 msec 1 msec
3 172.16.200.1 1 msec 0 msec 0 msec             <<<<<<<<< RT-Ashburn 
4 172.16.200.42 2 msec 1 msec 2 msec
5 192.168.200.42 1 msec 1 msec 1 msec
6 172.19.43.12 1 msec * 2 msec
BR_LAN#

 

 

RT-BR1#sh crypto session interface virtual-access 1
Crypto session current status

Interface: Virtual-Access1
Profile: IKEV2-ZONE2
Session status: DOWN-NEGOTIATING
Peer: 145.40.40.42 port 500
Session ID: 12
IKEv2 SA: local 145.40.40.18/500 remote 145.40.40.42/500 Inactive
IPSEC FLOW: permit 47 host 145.40.40.18 host 145.40.40.42
Active SAs: 0, origin: crypto map

 

RT-SG1#sh crypto session interface virtual-access 1
Crypto session current status

Interface: Virtual-Access1
Profile: IKEV2-ZONE2
Session status: DOWN-NEGOTIATING
Peer: 145.40.40.18 port 500
Session ID: 14
IKEv2 SA: local 145.40.40.42/500 remote 145.40.40.18/500 Inactive
IPSEC FLOW: permit 47 host 145.40.40.42 host 145.40.40.18
Active SAs: 0, origin: crypto map

RT-SG1#

 

 

- A debug crypto ikev2 on RT-BR1 & RT-SG1 shows that the routers are pushing the crypto profile IKEV2-ZONE1 even when the router RT-AUBER is down. 

So my question is why the spokes routers are still pushing the crypto profile for IKEV2-ZONE1 while we did a failover on ZONE2 ? 

 

On RT-SG1 & RT-BR1

=================

Apr 28 20:11:15.692: IKEv2:% DVTI create request sent for profile IKEV2-ZONE1 with PSH index 2.

*Apr 28 20:11:15.692: IKEv2:(SESSION ID = 20,SA ID = 2):
*Apr 28 20:11:15.696: IKEv2:% DVTI Vi1 created for profile IKEV2-ZONE1 with PSH index 2.

*Apr 28 20:11:15.696: IKEv2:IPSec policy validate request sent for profile IKEV2-ZONE1 with psh index 2.

*Apr 28 20:11:15.696: IKEv2:(SA ID = 2):[IPsec -> IKEv2] Callback received for the validate proposal - FAILED.

*Apr 28 20:11:15.696: IKEv2:(SESSION ID = 20,SA ID = 2):: There was no IPSEC policy found for received TS

 

Thank you for your help!

3 Replies 3

Kach
Level 1
Level 1

Here are the config full config files and some debug files. 

Kach
Level 1
Level 1

Here are the config full config files and some debug files. 

Kach
Level 1
Level 1

Here are the config full config files and some debug files. 

Review Cisco Networking products for a $25 gift card