While it is possible to put two routes in place with the secondary having a higher metric, this may not always work. In the event of a failure that does not bring down the physical interface on the router the primary route is not removed. There is also the situation where the primary interface takes too long to change status. The way around these limitations is simple; IP SLA
Here's how to do it
ip sla 1 < The number 1 here is arbitrary, used only to identify this sla. It is otherwise knows as the operation number>
icmp-echo 4.2.2.2 < 4.2.2.2 is a DNS server that responds to pings out on the internet>
timeout 500 < This is how long to wait for a response from the ping>
frequency 3 < This is the repeat rate for the SLA>
ip sla schedule 1 start-time now life forever < This command says "start SLA 1 now and keep it running forever>
track 1 rtr 1 reachability < This comand creates the track object "1" and monitors the SLA 1>
now for the routing, we need to change the default route and associate it with the tracker
no ip route 0.0.0.0 0.0.0.0 1.1.1.1
and then put it back with the tracking
ip route 0.0.0.0 0.0.0.0 1.1.1.1 track 1
Then we need to add our secondary route
ip route 0.0.0.0 0.0.0.0 1.1.1.2 10 <we set this route with a higher metric than the tracked route>
Now when the ping to 4.2.2.2 fails the primary route is removed and the secondary route with the higher metric becomes the default. The route will be reinstated when the connectivity is restored.
With the 12.4 and higher releases the commands have changed slightly but the "?" is your friend. If I receive requests for the syntax I will post it as well, but it is pretty easy to convert.
Here is the reference to the Cisco IP SLA documentation
http://www.cisco.com/en/US
Here's how to do it
ip sla 1 < The number 1 here is arbitrary, used only to identify this sla. It is otherwise knows as the operation number>
icmp-echo 4.2.2.2 < 4.2.2.2 is a DNS server that responds to pings out on the internet>
timeout 500 < This is how long to wait for a response from the ping>
frequency 3 < This is the repeat rate for the SLA>
ip sla schedule 1 start-time now life forever < This command says "start SLA 1 now and keep it running forever>
track 1 rtr 1 reachability < This comand creates the track object "1" and monitors the SLA 1>
now for the routing, we need to change the default route and associate it with the tracker
no ip route 0.0.0.0 0.0.0.0 1.1.1.1
and then put it back with the tracking
ip route 0.0.0.0 0.0.0.0 1.1.1.1 track 1
Then we need to add our secondary route
ip route 0.0.0.0 0.0.0.0 1.1.1.2 10 <we set this route with a higher metric than the tracked route>
Now when the ping to 4.2.2.2 fails the primary route is removed and the secondary route with the higher metric becomes the default. The route will be reinstated when the connectivity is restored.
With the 12.4 and higher releases the commands have changed slightly but the "?" is your friend. If I receive requests for the syntax I will post it as well, but it is pretty easy to convert.
Here is the reference to the Cisco IP SLA documentation
http://www.cisco.com/en/US
by: DevilWAH on 2009-08-05 at 10:56:11ID: 2527
If you have HSRP set up for not only route redundancy, but also router redundancy.
You can use the same IP SLA commands, to set up a tracking object that HSRP can be set to monitor.
Like wingatesl says normally you can only see if links are up that are directly connected. the IP SLA gives you a way to test the entire link end to end.
however one thing to be careful of!! when the second route becomes active, the IP SLA will be able to see 4.2.2.2!!! so will straight away reinstate the primary link as you have restored connectivity via the back up route!
to get around this you need to add a static route for 4.2.2.2 to force it to always use the primary router.. or insure the IPS SLA traffic is only sent to the primary route. if not you can end up with links flapping!