SLA Tracked Static Route removed from route table / CEF, but never brought back in

[David Anderson]

I configured IP SLA tracking to ping between two directly connected routers and were pinging fine, and as an experiment on how a tracked route would react, I shutdown the interface that was being pinged / tracked.

So the route was removed from the IP Route Table / CEF, and after awhile I did a no shut on that interface, but IP SLA continues to show the failures incrementing, because this static route tracking is not bringing the route back into the routing table.

Is there a command that I missed here to make it bring the route back into the route table, so IP SLA can continue to track it now that its available again?

Below is the show run, if I delete the route and re-configure it with tracking again I'm sure it will work, but I'd like to know how to make the tracking object bring it back into the route table (if possible) once the interface comes back up and is reachable again.

Thanks!!

R4#sh run
Building configuration...


Current configuration : 1668 bytes
!
! Last configuration change at 01:20:22 UTC Mon May 22 2017
! NVRAM config last updated at 21:53:34 UTC Sun May 21 2017
! NVRAM config last updated at 21:53:34 UTC Sun May 21 2017
version 15.1
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R4
!
boot-start-marker
boot-end-marker
!
!
enable secret 4 0prw5hJ/sM6J5gz.6A0QVcouzLXCkcFPP8b/RvuonWY
!
no aaa new-model
!
no network-clock-participate wic 0
dot11 syslog
ip source-route
!
!
!
!
!
ip cef
no ip domain lookup
no ipv6 cef
!
multilink bundle-name authenticated
!
!
!
!
!
!
!
!
!
!
!
voice-card 0
!
crypto pki token default removal timeout 0
!
!
!
!
license udi pid CISCO2801 sn FTX1115W1FS
!
redundancy
!
!
controller T1 0/0/0
!
!
track 5 ip sla 1
 delay down 30 up 5
!
!
!
!
!
!
!
!
interface Loopback4
 ip address 4.4.4.4 255.255.255.255
!
interface Loopback55
 ip address 172.12.55.4 255.255.255.0
!
interface FastEthernet0/0
 ip address 172.12.45.4 255.255.255.0
 duplex auto
 speed auto
!
interface FastEthernet0/1
 ip address 172.12.14.4 255.255.255.0
 duplex auto
 speed auto
!
ip forward-protocol nd
no ip http server
no ip http secure-server
!
!
ip route 5.5.5.5 255.255.255.255 172.12.45.5 track 5
ip route 1.1.1.1 255.255.255.255 172.12.14.1
!
ip sla 1
 icmp-echo 5.5.5.5 source-ip 4.4.4.4
 frequency 10
ip sla schedule 1 life forever start-time now
disable-eadi
!
!
!
!
!
!
control-plane
!
!
!
!
mgcp profile default
!
!
!
!
!
!
line con 0
 exec-timeout 0 0
 logging synchronous
line aux 0
line vty 0 4
 password CCNP
 logging synchronous
 login
 transport input all
!
scheduler allocate 20000 1000
ntp server 172.12.14.1
end

R4#

[YuJie Lim]

The destination of IP SLA should always have a route installed in routing table. If this case, route going to 5.5.5.5 is not installed in routing table after you bounced the interface, so IP SLA will not coming back up.

[David Anderson]

I am maybe missing the purpose of static IP route tracking, I would have to assume if you have a backup gateway to another ISP, this works to remove the route to the Primary ISP's gateway if it becomes unreachable so the floating (less preferred) default route out to the Backup ISP's gateway can be placed into the IP route table?

That is how I have seen it work with customers many times, I just thought there would be some way to fail it back over without having to do it manually?

Like usually there is a default route configured to the Primary ISP gateway, then another configured to the backup with a slightly higher weight so it's a "floating static default route", but I've never seen a mechanism for it to dynamically fail back to the Primary ISP once it becomes reachable again.

Is there any way to configure this?

[a.alekseev · Accepted solution]

just think how it works...

suppose for some reason ip sla is down.

In this situation do you have a route to 5.5.5.5? :)

this route is needed for "ip sla" works.

example

router with 2 ISP connected.  There are two static default routes. And you want check if google dns (8.8.8.8) is accessible through ISP1 on so ISP1  is working

track 1 ip sla 1
 delay down 30 up 5
!
int e1
 desc ## ISP1 ##
 ip address 10.1.1.0 255.255.255.254
!
int e2
 desc ## ISP2 ##
 ip address 10.2.1.0 255.255.255.254
!
ip sla 1
 icmp-echo 8.8.8.8 souce 10.1.1.0
 frequency 10
ip sla schedule 1 life forever start-time now
!
ip route 8.8.8.8 255.255.255.255 10.1.1.1 name GOOGLE-DNS
ip route 0.0.0.0 0.0.0.0 10.1.1.1 track 1 10 name ISP1
ip route 0.0.0.0 0.0.0.0 10.2.1.1 20 name ISP2

[Jon Marshall]

I may be misunderstanding your point but IP SLA is the mechanism to fall back dynamically, that is it's purpose and it works fine.

The problem with your example is that the route you are tracking is for the IP you are pinging with IP SLA. So when you shut the interface the route is removed but when you bring the interface back up IP SLA does not have a route to that interface so it can never successfully ping.

In other words to reinstall the route IP SLA already needs that route in the routing table to be able to ping successfully.

If you see the example given below you can see that the default routes are independent of the IP being pinged which is why that example would work.

Jon

[David Anderson]

Thanks for putting your answer in a configuration format, that makes it much easier to interpret, and I see how you are showing the configuration.

That looks like what I was probably seeing without that clear of an explanation, thank you again for that!