Policy based routing.....

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

PROBLEM/QUESTION.....

I have recently configured a VPN failover for our branch office using Policy Based Routing with the Set-Next-Hop Verify-availability.

Although this works like a dream when the CIsco Tunnel interface goes down i have a slight problem when it comes back in that the traffic that seems to still route over the failover route for a while (up to 5 minutes ish). So when the tunnel interface comes back up, a tracert from a client machine still routes over the failover routers (Drayteks) until a few minutes later. This normally wouldt be a problem but the backup link is shocking at the minute due to no QOS, very low bandwidth and lots of VPNS on one of the routers.


I am trying to figure out of this is some sort of default track object delay up time or tcp session staying active on the one route or something? I would ideally like to know how to increase the recovery time if anyone has any ideas.


This has been configured this way because i am using it as a case study to use PBR elesewhere (but need to showcase it to the bosses!)


This is a quick diagram of the setup:
View attachment 2577


A shortened config is also here, this includes the PBR configuration as well as some QOS and other bits:


version 12.4
!
hostname VPN
!
boot-start-marker
boot-end-marker
!
logging message-counter syslog
logging buffered 4096
!
no aaa new-model
!
!
dot11 syslog
ip source-route
!
!
!
!
ip cef
ip inspect name DIALER_OUT cuseeme
ip inspect name DIALER_OUT ftp
ip inspect name DIALER_OUT h323
ip inspect name DIALER_OUT icmp
ip inspect name DIALER_OUT netshow
ip inspect name DIALER_OUT rcmd
ip inspect name DIALER_OUT realaudio
ip inspect name DIALER_OUT rtsp
ip inspect name DIALER_OUT esmtp
ip inspect name DIALER_OUT sqlnet
ip inspect name DIALER_OUT streamworks
ip inspect name DIALER_OUT tftp
ip inspect name DIALER_OUT tcp router-traffic
ip inspect name DIALER_OUT udp router-traffic timeout 300
ip inspect name DIALER_OUT vdolive
ip inspect name DIALER_OUT dns
!
no ipv6 cef
multilink bundle-name authenticated
!
!
!
crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
crypto isakmp key yeehaa address 0.0.0.0 0.0.0.0
crypto isakmp keepalive 10 periodic
!
crypto ipsec security-association replay window-size 1024
!
crypto ipsec transform-set T1 esp-3des esp-sha-hmac
!
crypto ipsec profile P1
set transform-set T1
!
!
archive
log config
hidekeys
!
!
!
track 10 interface Tunnel0 line-protocol
delay up 5
!
track 11 ip sla 11 reachability
!
class-map match-any VOICE_TRAFFIC
match access-group name VOICE_TRAFFIC
class-map match-any FTP_INHOURS
match access-group name FTP_TO_MAGENTA
class-map match-any RDP_TRAFFIC
match access-group name RDP_TRAFFIC
!
!
policy-map QOS_OUT_OVER_VPN
class VOICE_TRAFFIC
set dscp ef
priority percent 38
class RDP_TRAFFIC
bandwidth remaining percent 65
class FTP_INHOURS
police rate 314500 bps peak-rate 314500 bps
conform-action transmit
exceed-action drop
violate-action drop
class class-default
fair-queue
policy-map PARENT_QOS
class class-default
shape average 2000000
service-policy QOS_OUT_OVER_VPN
!
!
!
!
interface Tunnel0
description VPN_TO_BW
bandwidth 1700
ip address 192.168.1.1 255.255.255.252
ip mtu 1400
ip flow ingress
ip tcp adjust-mss 1400
tunnel source Vlan5
tunnel destination x.x.x.x
tunnel mode ipsec ipv4
tunnel protection ipsec profile P1
service-policy output PARENT_QOS
!
interface ATM0
SHUTDOWN
!
interface FastEthernet0
description BG_SUBNET
switchport access vlan 210
!
interface FastEthernet1
description AVAYA
switchport access vlan 220
!
interface FastEthernet2
description WORKSHOP_INET
switchport access vlan 2
!
interface FastEthernet3
switchport access vlan 5
!
interface Vlan1
no ip address
ip nat inside
ip virtual-reassembly
!
interface Vlan5
ip address x.x.x.13 255.255.255.248
ip access-group BLOCK_ALL in
ip nat outside
ip virtual-reassembly
!
interface Vlan210
ip address 10.2.1.253 255.255.255.0
ip nat inside
ip virtual-reassembly
ip policy route-map VPN_FAILURE
!
interface Vlan220
ip address 192.168.201.1 255.255.255.0
ip nat inside
ip virtual-reassembly
ip policy route-map VPN_FAILURE
!
interface Dialer1
SHUTDOWN
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 x.x.x.14
!
ip nat inside source list NAT interface Dialer1 overload
!
ip access-list standard NAT
deny 10.2.1.0 0.0.0.255
!
ip access-list extended BLOCK_ALL
x
x
x
x

ip access-list extended FTP_TO_MAGENTA
permit ip host 10.2.1.2 host 10.1.1.23 time-range WORKING_HOURS
!
ip access-list extended RDP_TRAFFIC
permit tcp 10.2.1.0 0.0.0.255 10.1.1.0 0.0.0.255 eq 3389
!
ip access-list extended TRAFFIC_TO_FAILOVER
permit ip any 10.1.1.0 0.0.0.255
permit ip any 192.168.200.0 0.0.0.255
permit ip any 10.9.0.0 0.0.255.255

ip access-list extended VOICE_TRAFFIC
permit ip 192.168.201.0 0.0.0.255 192.168.200.0 0.0.0.255
!
ip sla 11
icmp-echo 10.2.1.252 source-interface Vlan210
timeout 10000
frequency 120
ip sla schedule 11 life forever start-time now
dialer-list 1 protocol ip permit
dialer-list 10 protocol ip permit
!
!
!
route-map VPN_FAILURE permit 10
match ip address TRAFFIC_TO_FAILOVER
set ip next-hop verify-availability 192.168.1.2 1 track 10
set ip next-hop verify-availability 10.2.1.252 2 track 11
!
time-range WORKING_HOURS
periodic weekdays 7:30 to 18:50
!
end

 

Oh man! Ad-blocking software has been detected! :'(

This website is run by the community, for the community... and it needs advertisements in order to keep running. Blocking our ads means your killing our stats!
Please disable your ad-block, or become a premium member to hide all advertisements and this notice.

 

NICE!

This is for the backup router (its just so i can use the "verify next hop track" command. so this should never really come into play....

The backup route is always available but the vpn contention on the draytek router at the BW side is quite high! so dont want to be using it unless we have to.

Thats what i was thinking with the established sessions but there is something in the back of my mind that is saying this cant be the case..... each packet will be destined for the default gateway because it is off the LAN so it should then get the policy applied and and route over the new link when it comes back up?

Have played with EEM a little bit and looks very VERY cool but havnt had much time to look further really. it would be quite cool to bounce the VPN with it thought.... (got me thinking now!)

If you have any other thoughts then let me know but i might just have to live with it....