cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
928
Views
3
Helpful
8
Replies

Cisco FlexVPN Client query

25139581
Level 1
Level 1

Hi community,

I'm struggling with a flexvpn client I have configured on some remote spoke routers and was wondering if anyone had any better suggestions or alternatives.

A typical deployment would see a spoke router connected to a fixed line private network via Gi0/0/0 and tunnel back to a Cisco Flex VPN Head end router (10.0.100.1 or 10.0.200.1) in DC1 or 2.

In the event of a failure of fixed line infrastructure, the spoke router will fail over to a private cellular APN (192.168.100.1 or 192.168.200.1)

Failover to cellular works seamlessly if the fixed line fails (Gi0/0/0 goes down, IP SLA 1 and 2 (track 100) times out etc.) and restores itself as soon as the IP SLA/track 100 restores itself

If both Fixed line (gi0/0/0) and cellular interfaces are UP and SLAs are responding, when the spoke router clears the crypto SA, it will round robin to the next peer. This works fine for peer 1 and peer 2 ie. gi0/0/0 to 10.0.100.1 or 10.0.200.1)

If however the crypto SA is cleared again the flexvpn client will round robin to APN peers 3 & 4 (192.168.100.1 and 192.168.200.1 via Gi0/0/0)

This connection from the fixed line interface to APN is not routable however. Gi0/0/0 can only connect to peer 1 and peer 2, Cellular 0/1/0 can only connect to peer 3 and 4.

This behaviour results in a loss of service of approximately 5 minutes whilst the spoke waits for the connections to peer 3 and 4 to timeout and returns back to peer1.

Please see configs below, any advice would be greatly appreciated, thank you.


crypto ikev2 client flexvpn CLIENT_FLEX
peer 1 10.0.100.1 track 1
peer 2 10.0.200.1 track 2
peer 3 192.168.100.1 track 3
peer 4 192.168.200.1 track 4
peer reactivate
source 1 GigabitEthernet0/0/0 track 100
source 2 Cellular0/1/0 track 110
client connect Tunnel0


track 1 ip sla 1 reachability
track 2 ip sla 2 reachability
track 3 ip sla 3 reachability
track 4 ip sla 4 reachability

track 100 list Boolean or
object 1
object 2

track 110 list Boolean or
object 3
object 4


ip sla 1
icmp-echo 10.0.100.1
ip sla schedule 1 life forever start-time now

ip sla 2
icmp-echo 10.0.200.1
ip sla schedule 2 life forever start-time now

ip sla 3
icmp-echo 192.168.100.1
ip sla schedule 3 life forever start-time now

ip sla 4
icmp-echo 192.168.200.1
ip sla schedule 4 life forever start-time now



1 Accepted Solution

Accepted Solutions

@25139581 I put some further thought in to your particular scenario.

You could create another track object that checks to see the peers in track object 110 are UP AND track object 100 is NOT UP, apply this track to peer 3/4 and source 2.

track 300 list boolean and
 object 100 not
 object 110
!
crypto ikev2 client flexvpn CLIENT_FLEX
 peer 1 10.0.100.1 track 1
 peer 2 10.0.200.1 track 2
 peer 3 192.168.100.1 track 300
 peer 4 192.168.200.1 track 300
 peer reactivate
 source 1 GigabitEthernet0/0/0 track 100
 source 2 Cellular0/1/0 track 300

Under normal circumstances track 300 would be down, when both peer 1 and 2 are down will track object 300 be up and only then will the tunnel failover to peer 3/4 on Cellular0/1/0.

You may wish to tune your SLA's frequency down from the default of 60 seconds.

ip sla 1
icmp-echo 10.0.100.1
frequency 5

 

View solution in original post

8 Replies 8

Try use 

Connect track <> 

Under client profile 

MHM

Hi @MHM Cisco World , thank you for the suggestion. Please can you just clarify what track group should I track - 100 (Fixed line) or 110 (Cellular) 

Thank you

Hi @MHM Cisco World , I've just tested this command 'Connect track 100' then 'Connect track 110' and unfortunately it hasn't made a difference - there is still a 5 min failover time.

Thank you for the suggestion

you use two types of track 
track for multi hubs
other for ISP 
are you sure you use correct source in ip sla of track, as I see you dont use source in SLA 
MHM

Screenshot (253).pngScreenshot (254).png

@25139581 you could use an EEM script, detect when track 100 is back UP and then take an action such as "clear crypto sa" which would then re-establish the tunnel or shut/no shut the Cellular0/1/0, forcing failover to peer 1.

Alternatively configure two tunnels, one per wan interface (Cellular0/1/0/Gig0/0/0), each with their own flexvpn client profile. Configure routing to prefer the tunnel with Gi0/0/0 as the tunnel source, if that tunnel is down, traffic will be routed over the second tunnel using Cellular0/1/0. When Gi0/0/0 is back up and the tunnel is automatically re-established, traffic would be re-routed over that tunnel.

25139581
Level 1
Level 1

Hi @Rob Ingram , thanks for your suggestions.

I did think about writing an EEM script that would start / stop the cellular sla's (3 &4) based on the state of track 100.

ie. if track 100 is up, then stop cellular sla's 3 & 4, avoiding the flex vpn client attempting to connect to those peers when the crypto session is restarted

if track 100 is down, then re-start cellular sla's 3 & 4, allowing the flexvpn client to fail over to cellular

Will give it a go on Monday when i'm back in the office. 

@25139581 I put some further thought in to your particular scenario.

You could create another track object that checks to see the peers in track object 110 are UP AND track object 100 is NOT UP, apply this track to peer 3/4 and source 2.

track 300 list boolean and
 object 100 not
 object 110
!
crypto ikev2 client flexvpn CLIENT_FLEX
 peer 1 10.0.100.1 track 1
 peer 2 10.0.200.1 track 2
 peer 3 192.168.100.1 track 300
 peer 4 192.168.200.1 track 300
 peer reactivate
 source 1 GigabitEthernet0/0/0 track 100
 source 2 Cellular0/1/0 track 300

Under normal circumstances track 300 would be down, when both peer 1 and 2 are down will track object 300 be up and only then will the tunnel failover to peer 3/4 on Cellular0/1/0.

You may wish to tune your SLA's frequency down from the default of 60 seconds.

ip sla 1
icmp-echo 10.0.100.1
frequency 5

 

Hi @Rob Ingram , just to confirm I tested your suggestion today and it works seamlessly. I had to fine tune the sla’s as suggested to reduce the failover.

thanks again for your and everyone else’s help regarding this