Cisco Tracking Route Reachability

“DSL Backup,” let’s assume the T1 is for Internet, and we’re using DSL as a backup.
Won’t the router only use the higher-metric DSL route if the T1 line is down
(interface down, or line protocol down)?

Isn’t the more likely scenario that the T1 is up, but no traffic is routing? Maybe the ISP is
having routing problems or their Internet connection got cut or something. Put another way,
which is more likely to happen: your T1 going down, or the ISP having Internet trouble? I venture
to guess that the T1 line is pretty stable, but the ISP is far more likely to have “issues.” And in that
case, the router will see the T1 as up, and it will keep trying to push traffic out the T1 and will not fail
over to the DSL, correct?

I’ve heard of “object tracking” to help in these scenarios, so it can test for something (like ping Google)
and then make routing decisions based on the results of those tests.

Now, on to your example :

You have a T1 and a DSL link both capable of your Internet routing and reachability.
You want to use the T1 as your primary path and then switch over if it’s not available.

Well, you’re correct that if the whole line is down, that’s a simple issue. Are you running any
routing with the ISP? If you’re multi-homed, typically you’ll run BGP and perhaps receive some
customer routes from that ISP directly. If so, you may have another simple answer — just look
for route reachability.

Let’s assume that we receive 192.168.100.0/24 from this ISP. (By the way, I always try to use private
addresses in my examples to protect the innocent!)

Track timer ip route 60
Track 1 ip route 192.168.100.0/24 reachability

This will simply look for the route in the routing table. Either it’s there or it’s not. In this case,
every 60 seconds your router will verify. The default is 15 seconds, but you can reconfigure it to
suit your own needs.

Now, even if the T1 goes down, you may still be able to reach this customer route
(a backup 0/0 route) but that specific route will not exist in your routing table.
So that’s the part we’re tracking.

Then on your route to the T1, we would simply put “track 1” at the end of it.

Ip route 0.0.0.0 0.0.0.0 (T1 intf) track 1
Ip route 0.0.0.0 0.0.0.0 (DSL intf) 100

And once we have a second route with higher AD value in place, when one goes away,
the other will come in.

If you aren’t learning any routes from your ISP, we may get into a little more complex scenario.
Check with your ISP (the T1 carrier) and see if there’s any particular IP address that you can reach
over the T1 that wouldn’t be reachable from non-customers (the rest of the Internet).
Something like a router’s loopback address would be good.

Now we’ll use the IP SLA features to test ICMP reachability to the address. When this ceases,
the route will go away. Now, this may take some working with the ISP because if they change
anything, suddenly it may appear as a failure when it really isn’t. But one thing at a time!

So if your ISP tells you that 10.234.100.15/32 is the loopback IP, we can set up ping tests.

ip sla monitor 6
type echo protocol ipIcmpEcho 10.234.100.15
frequency 300
ip sla monitor schedule 6 life forever start-time now
track 2 rtr 6 state
ip route 0.0.0.0 0.0.0.0 (T1 intf) track 2
ip route 0.0.0.0 0.0.0.0 (DSL intf) 100

The more complex our networks become, the more difficult it may be to design failover scenarios.
But the basic stuff we’ve had available for a while has been expanded to give us many more options
to deal with this complexity.

The tracking capability as an example was initially designed for HSRP/VRRP. But it’s been expanded
to use in static routes like we’re using here. The things we can track have also increased:

• line-protocol on an interface
• IP routing state of an interface
• specific IP route reachability
• route metric of a specific IP route
• IP SLA (ping, udp echo, tcp signon, http status, etc.) metrics
• logical combination in an and/or fashion of multiple single objects

Example :