Hi All,
I was trying to find some tracking code on Google when I dropped into this thread. Figured I could through in some general information. IP SLA and Tracking code vary a bit between IOS but they are somewhat consistent, look up the specific configurations for the code you are using though.
To answer the one question, if you are using OSPF on two different routers and pointing those to two different ISPs, most likely you are injecting a default route from both routers into OSPF. If you are doing this, the redistribution from static to OSPF only occurs if the static route is present in the routing table. IP SLA and tracking can remove that static route from existing in the routing table, so doing so, deletes the redistributed route into OSPF. Therefore traffic should flow to the other router which, presumably, still has the other ISP connection up. The same principle applies to a single router and multiple static default routes. You can remove the static route and send traffic out the other ISP.
First thing we do is configure the IP SLA. I would recommend always pointing that to your next hop address, the other end of your Public /30 IPs for example or if you are running something like DHCP or PPPoE finding out the next hop IP address and configuring your IP SLA to point to that.
config t
ip sla 500
icmp-echo 10.10.13.1 source-ip 10.10.13.3
frequency 5
ip sla schedule 500 life forever start-time now
end
wr
The 10.10.13.1 in this case is just my upstream router in a lab I'm running, my interface is .3, the interconnect is a /24. This would never happen in real life but this is the lab. This SLA is fairly basic, it just says, ping this IP address (10.10.13.1) every 5 seconds (frequency). Then, start this IP SLA now, and run it forever.
R3#show ip sla summary
*500 icmp-echo 10.10.13.1 RTT=16 OK 2 seconds ago
You can run the above commands and see that the IP SLA is in operation. And that you can ping the specified interface. So more or less this shows that we have Layer 3 connectivity to our upstream ISP. Another helpful command is the show ip sla configuration command:
R3#show ip sla configuration 500
IP SLAs Infrastructure Engine-III
Entry number: 500
Owner:
Tag:
Operation timeout (milliseconds): 5000
Type of operation to perform: icmp-echo
Target address/Source address: 10.10.13.1/10.10.13.3
Type Of Service parameter: 0x0
Request size (ARR data portion): 28
Verify data: No
Vrf Name:
Schedule:
Operation frequency (seconds): 5 (not considered if randomly scheduled)
Next Scheduled Start Time: Start Time already passed
Group Scheduled : FALSE
Randomly Scheduled : FALSE
Life (seconds): Forever
Entry Ageout (seconds): never
Recurring (Starting Everyday): FALSE
Status of entry (SNMP RowStatus): Active
Threshold (milliseconds): 5000
Distribution Statistics:
Number of statistic hours kept: 2
Number of statistic distribution buckets kept: 1
Statistic distribution interval (milliseconds): 20
Enhanced History:
History Statistics:
Number of history Lives kept: 0
Number of history Buckets kept: 15
History Filter Type: None
So now we have the IP SLA in operation. Now we need to track when it is working and when it isn't working. In comes the tracking objet. I used IP SLA 500, so I'll use the tracking 500 as well to keep it consistant in the configurations.
config t
track 500 ip sla 500 reachability
default-state up
delay down 2 up 90
end
wr
Assign track 500, to IP SLA 500. The default state is up, I'm doing that because I don't want to kill connectivity if there's a questionable situation where the IP SLA might be up or might not be up. I'm then saying delay by 2 seconds before taking the action on down, and delay by 90 seconds before taking action on up. This is mostly to prevent any kind of flapping on the ISP part from bringing up traffic too soon on the link. I only want to start sending traffic over my primary ISP, if I'm sure the primary ISP is stable.
R3#show track 500
Track 500
IP SLA 500 reachability
Reachability is Up
3 changes, last change 00:08:48
Delay up 90 secs, down 2 secs
Latest operation return code: OK
Latest RTT (millisecs) 20
Tracked by:
STATIC-IP-ROUTING 0
When this is applied and you are watching the console or have terminal monitoring enable you should also see the log message of the tracking session coming up:
*Nov 19 20:04:38.791: %TRACKING-5-STATE: 500 ip sla 500 reachability Down->Up
Now we have the IP SLA monitoring the next hop interface, and we have created a tracking 'session' relating to that IP SLA. We are actively monitoring ("tracking") when we have upstream connectivity to our upstream next hop. Now we apply that to our routes.
config t
ip route 0.0.0.0 0.0.0.0 10.10.13.1 track 500
ip route 0.0.0.0 0.0.0.0 10.10.35.3 250
end
wr
So the above sample code is very basic. We are putting two default routes into the routing table. One has the default static route Administrative Distance of 1, while the other I've configured for an AD of 250. The 250 default static route is usually refered to as a floating default route. Which is to say, it doesn't show up in the routing table as long as their is a better default route (with a lower Administrative Distance) in the routing table. That more prefered route is the first route entered. The first default route though is associated with tracking object 500. It only gets entered into the routing table if the tracking object is up, which is based on the IP SLA pinging the upstream next-hop. If the next-hop isn't reachable this route gets pulled out of the routing table. Then the floating static gets inserted into the routing table.
Generally I wouldn't roll something this simple out entirely. I would have 2 IP SLAs for both upstream ISPs, and a tracking object for each IP SLA. I would associate both default routes with a tracking object. If for no other reason as I want logs for when my ISPs are going up and down with appropiate time-stamps.
Doing this same thing in multiple router environments is just adding the redistribution into your IGP of choice.
