IP SLA ROUTE PROBLEM VRF

[dmbnex]

Hi All,

Im trying to get a very basic operation of ip sla with reachibility tracking to trigger route decision between two links.

Link 1 - Primary ISP vlan201- is a dhcp link - I need to be able to track an address on internet

Link 2 - Backup LTE link - vlan31 - static ip addressing

both links are terminated in a vrf "inet", there is aslo basic bgp in use locally on the router

what happens is that ip sla comes up with default gw over Link1 but when it goes down the default route is not removed

when I manually remove the default route ip route vrf inet 0.0.0.0 0.0.0.0 Vlan201 dhcp 251 the link 2 route takes over, enabling the link 1 does nothing and when manually pinging the 1.1.1.1 it does not answer when it should.

I have tried removing interface from primary route without it helping.

it may seem that bgp has something to do with this but I'm no sure

ip sla configuration:

track 1 ip sla 1 reachability
ip sla 1
icmp-echo 1.1.1.1 source-interface Vlan201
vrf inet
frequency 15

ip route vrf inet 0.0.0.0 0.0.0.0 10.11.12.2 253

ip route vrf inet 0.0.0.0 0.0.0.0 Vlan201 dhcp 251

interface Vlan201
vrf forwarding inet
ip dhcp client route track 1
ip address dhcp
end

bgp config:

address-family ipv4 vrf inet
redistribute connected
redistribute static
default-information originate
exit-address-family

vrf:

vrf definition inet
rd 65000:1
route-target export 65000:1
route-target import 65000:1
route-target import 65000:2
!
address-family ipv4
route-target export 65000:1
route-target import 65000:1
route-target import 65000:2
exit-address-family
!

Have you guys seen same behavior, or am I just blind and cant see the obvious in front of me?

Thanks

Equipment in use is Cisco ISR C1100 router with IOS-XE 17.6.5

[paul driver]

Hello @MHM Cisco World 

run lab and spent 1 hours, there is no solution for track under interface and DHCP with VRF aware

can you elaborate- you saying dhcp client route track isn’t applicable when the interface is within a vrf?

[MHM Cisco World]

Yes Correct, 
the track never become UP always it down. 

first I suspect with 
ip sla auto discovery <<- command add for track under interface 
but even with this command the track is Down always. 

@dmbnex 
please add ip sla auto discovery <<- and check again 

[paul driver]

Hello
2 probable reasons for that

- you have to always apply the dhcp client route track BEFORE you enable dhcp on the interface 

- your simulation software isn’t applicable 

Last you should not require ipsla auto discovery 

[dmbnex]

there is no ip sla auto discovery command in ios-xe 17.6.5

[dmbnex]

I have this applied already

ip dhcp client request route <- is default behavior and is not necessary with ip address dhcp command in my case

[MHM Cisco World]

ip address dhcp is different than ip dhcp client, 
the ip dhcp clinet will automatic add defautl route toward next-hop, this next-hop is the default-router you config in dhcp server local pool.
this default route will add with 254 and it to high.
so with ip add dhcp client default-route distance  we can change this value. 

[dmbnex]

Yes, and thanks,

I'm aware of this but the problem with this dhcp link(which I do not have control over) is that sometimes interface stays UP(and thus the ip/gw) but upstream router actually is not forwarding traffic.

in this case the route will still have higher priority and backup will never take over.

I will test more tomorrow, Im also thinking about scripts, maybe there is something may be automated when a log log entry is created.

[MHM Cisco World]

You are right, totally right.
but we face issue of static route with egress interface without next-hop 
the router refuse this static route. 
so as you mention EEM, I have one solution BUT this need more work. 
my solution is using track in global mode and make VRF leaking between global-VRF and then use this track in EEM to shut no shut the DHCP interface.

[dmbnex · Accepted solution]

Hi again,
After moving ip sla to global, importing routes to/from vrf/global this worked with both ip sla tracking and route failover from another vrf.

I will probably use some kind of firewall with policy based routing/probe to achieve this as Cisco is way to unpredictable for me as ip sla sometimes works and sometime does not(even i global)