OK Jim,
Here we go. My configuration example is below. I've changed certain arguments for security. However I have explained the parameters for your understanding.
!-----this is the track-------
track 123 rtr 1 reachability
delay down 180 up 2
!-----route map to route the ICMP echos------
ip local policy route-map CHECK_STABILITY
!------Static router (which is what I am using)------
ip route 0.0.0.0 0.0.0.0 10.1.1.1 track 123
ip route 0.0.0.0 0.0.0.0 200.1.1.1 254
!------The tracked object-----------
rtr 1
type echo protocol ipIcmpEcho 198.133.219.25 source-ipaddr 10.1.1.2
timeout 10000
threshold 180000
lives-of-history-kept 2
buckets-of-history-kept 10
filter-for-history failures
!------Scheduling the object tracking-------
rtr schedule 1 life forever start-time now
!------route map sends ICMP echos to the favorite IP down the primary line out-----
route-map CHECK_STABILITY permit 10
match ip address 104
set ip next-hop 10.1.1.1
access-list 104 permit icmp any host 198.133.219.25 echo
Explanation:
The tacked object defines what needs to be checked. In our case, we are sending ICMP echos down our primary line to a "favorite IP", in our case the cisco.com web sever (198.133.219.25). This means that as long as a reply is received, the object is in a "UP" state and the line is good. If a reply is not received, then the object goes down, triggering the track to declare the primary line as down. This will in turn trigger the router to inject the secondary floating route into the routing table.
However, because in the real world, there are several occassion when an ICMP echo may time out. We do not want the router to failover if just one odd ping, once in a while times out. The track therefore tells the router that the delay time allowed before declaring a line down is 180 seconds (my configuration). However, I have told the router that if the primary link comes back up, the fail-back should happen in 2 seconds.
The first static route has the track associated with it. That is the primary default route. The second static route has a high metric. This is the secondary floating route that points down my backup link (2nd ISP).
If you look at the routing table when the primary link is up, you will see the next hop on the default route as 10.1.1.1.
When a failover happens, if you look at the routing table, you will see that the default route is pointing down the secondary link (200.1.1.1).
The 10.1.1.3 IP that you see in the rtr configuration is the interface of my router that connects to the primary line out.
I hope this configuration assists you. I have 2 VPN tunnels doing a failover and fail-back over it like a charm. I've tested it several times.
Now, there are bugs (VRF-related) associated with certain IOS versions, but they do not pertain to this feature. However, you may need to upgrade your IOS to a later version to be able to configure this feature. I had to upgrade my router 3 times before I could run without issues. I am running 12.3(9.8)T and this was posted specially by TAC as it is not available for download. DO NOT GO FOR 12.3(9)T!!!
Have a nice day!
Paras
