Static Routes with IP SLA and Object Tracking


This small lab uses IP SLA to track the reachability of a remote IP. That IP SLA event is associated with a tracked object. Then a static route can be conditionally inserted into the routing table, using the tracked object. If the object is “up”, then the static route should appear in the table. If the object is down, the static route will be withdrawn.

Just for fun, I added a couple tracked objects tied to a couple of static routes with different administrative distances.

You could test my scenario with this topology. The code for the exercise follows.


! Create an IP SLA object that pings host The IP SLA
! event fires once a second, and considers down if there
! is no response in 900ms. Start the IP SLA task immediately, and
! run it indefinitely. We’ll reference the IP SLA objects later in
! a tracking object.

rtr 1
type echo protocol ipIcmpEcho
timeout 900
frequency 1
rtr schedule 1 life forever start-time now
! Create a second IP SLA object.

rtr 2
type echo protocol ipIcmpEcho
timeout 900
frequency 1
rtr schedule 2 life forever start-time now
! Create tracking objects that reference the IP SLA objects we created
! above.

track 101 rtr 1 reachability
track 102 rtr 2 reachability
! Create 2 static routes with administrative distances of 10 & 15
! respectively. These static routes are tied to the tracking objects.
! If the tracked object is down, the static route will not be present
! in the RIB.

ip route 10 track 101
ip route 15 track 102
! The net result of this configuration is as follows:
! (1) If both and are “UP” as reported by IP SLA,
! then both static routes are eligible to go into the RIB. Since
! -> has a lower administrative distance
! it be present in the routing table.
! (2) If tracking object 101 goes down, -> will
! fall out of the table. Assuming tracked object 102 is still up,
! -> will now be in the table, but with an
! AD of 15 instead of 10

Test by downing interfaces on R2 and R3 one at a time, and monitor the effect on R1’s routing table.

Also see this cisco.com article “Configuring Reliable Static Routing Backup Using Object Tracking“.

About the author

Ethan Banks

Most people know me because I write & podcast about IT on the Packet Pushers network. I also co-authored "Computer Networks Problems & Solutions" with Russ White.

Find out more on my about page.


  • I had a bit of time on Friday at the bootcamp, yes. I completed all of Narbik’s advanced lab workbooks, so I opted to breathe a bit between lectures by posting.

    The IP SLA thing had come up in an offline discussion, so I decided to blog it. I found a useful little tool called NetworkNotepad to make the diagram. The interface is a little clunky, but it’s a free alternative to Visio. Not great, but the price is right, and it’s fast once you get the hang of it.


  • im from argentina. I need to know if i can route HSRP with RIP. I mean, i can route HSRP with RIP but the thing is i need to Publish only the ACTIVE route as the gateway in the outbound trafic. Because when a router goes down the other router becomes the active router and send packets to their reciver but when the reciver router reply, takes the route it has in his ROUTE table. And takes a few minutes to add the new route, when hsrp takes a few seconds to designate a new Gateway.
    Plz Answer

  • Sebastian, what you’re describing sounds like an issue between two routers, not between a router and a host. HSRP is a first-hop redundancy protocol for use with hosts, not for transit in between routers. It would help to see a network diagram, because I might not clearly understand the problem you’re trying to solve. In any case, a router won’t advertise his HSRP address as a next hop to a neighbor. He’s only going to advertise his locally assigned address.

    Here’s a couple of options to consider:

    (1) Replace RIP with a routing protocol that converges more quickly. If you’re surviving with RIP today, then EIGRP is a likely replacement. I’m making assumptions about what you’re dealing with since I don’t know your network topology. However, EIGRP would take care of the issue you have of the blackhole while you wait for the dead route to expire. Why? EIGRP maintains a neighbor adjacency, meaning that if you lose a router, the remaining routers on the segment know that the neighbor is gone. When that happens, they update their routing tables.

    On the other hand, a RIP router has no idea that his neighbor is gone…he only knows that he hasn’t heard about a particular route so that he marks the route as suspect, and eventually drops it from his routing table. That’s a slow process, especially with default RIP timers.

    (2) Tighten up your RIP timers to force the bad route to be expelled from the routing table faster. Check this link for more information.



  • I don’t believe IOS will add a static route to the table when the tracked object goes down – only up, that I could find. Perhaps I missed an option in reviewing the available commands. But there are other ways to achieve the same result.

    (1) Add 2 static routes. The first one uses tracking, and uses the default administrative distance of 1. The second static route does not use tracking, and has an administrative distance of some larger value, let’s say 200 for this example. What will happen? As long as the tracked object is up, the first static route will be in the routing table. The second static route will not, because the administrative distance of 200 is greater than 1. What if the tracked object goes down? Then the first static route will be removed from the table. The second static route will then be entered into the routing table, as there will be no other equivalent route with a lower administrative distance.

    (2) What I outlined above could also be accomplished using a dynamic routing protocol instead of a static route with tracking, and is in fact the basis for demand dial routing (DDR) solutions, where a dial line is being used to backup a leased line.


    (3) You could forego static routes completely, and use policy-based routing with “verify-availability”. In this scenario, a packet that matches the PBR criteria will be forwarded to a next-hop that is verified to be available using a tracked object. If the first next-hop is not available, then the second next-hop will be used. This is a complicated and not terribly elegant solution, but might be an appropriate fit depending on the topology you’re working with.




Most people know me because I write & podcast about IT on the Packet Pushers network. I also co-authored "Computer Networks Problems & Solutions" with Russ White.

Find out more on my about page.

Subscribe via Email

Receive complete, ad-free posts in your inbox as I publish them here.