Thursday, November 24, 2011

Cisco ISP Failover IP SLA Configuration Example

On some Cisco routers there is the command IP SLA and on other routers it is IP SLA MONITOR. Without going into the reasons for the differences including IOS features and versions, this post will focus and show a working example of IP SLA. To view a similar post containing IP SLA MONITOR please visit the following link:

IP SLA Monitor Example for Fail-over Survivability of ISP .

That post will contain a similar configuration example to the following that uses the ip sla monitor configuration to accomplish the same task of redundancy/failover of an ISP link. Also similar to this post is that the primary interface or ISP for a custom application is a T! and the redundant or failover ISP is a DSL.

Configure ASA to allow traceroute responses

Below is a configuration example for IS SLA (no monitor in the command line interface):

Cisco IP SLA example configuration (not IP SLA MONITOR) also uses a track list and boolean operator condition. This was a working configuration so the IP addresses have been modified . The remote office this configuraiton was used for has a T1 connection to the internet (a "legacy" T1) and a DSL directly attached to the router. The interface for the T1 was 0/3/0:0.1 and the DSL was GigabitEthernet 0/1. they wanted a custome application to use the T1 exclusively but in case there was a T1 internet access failure, they wanted to ustilize the DSl as a failover. The custom application was cirtical to the business. The idea was simple, if the T1 fails, use the DSL for the custom applciation to connect to an online database source and server. There are some other mitigating factores that made this IP SLA configuration a little more challenging but I will not go into it at this time. It is not relevent actually to the commands used. The relevance came in to play in regards to what interfaces were to be used for sourcing the icmp ping used in the ip sla monitor. It is also the reaso nthe line-code tracker in combination with the bollean operator and track list.

There are two tracker objects in a tracker list. The list uses a boolean AND,

track 10 ip sla 20 reachability --> a ping to a target ip address for which there is ONLY a single static route to use the T1
track 11 interface Serial0/1/0:0 line-protocol --> Interface status

track 20 list boolean and --> boolean AND, two both conditions have to be met , almost seems redundant but TAC did this on another remote office router

object 10 --> tracker 10 shown above
object 11 --> tracker 11 shown above

ip route track 20 --> tracked main route
ip route 100 --> alternate route is used if T1 is down

ip sla 20 --> referenced in tracker 10

type echo protocol ipIcmpEcho source-interface GigabitEthernet0/0 --> had to use the interface as source, using the ip address did not work. This is the "inside" interface . Yes, I know "inside" is more (another

bug, perhaps) , there is a static route that says anny traffic for use the T1 interface. so if there is a problem with the T1 the pings will time out.

timeout 1000 --> max ping reply time allowed in milliseconds
threshold 2
tag 20
frequency 5 --> status is checked every five seconds

ip sla monitor schedule 20 life forever start-time now --> scheduler for monitor 20

Cisco IP SLA Example for ISP failover

Some Cisco routers have IP SLA without the command option of monitor and other Cisco routers have IP SLA MONITOR. The configurations vary slightly, just enough to throw you off just a little.
Another simple article (or post) on a tech support for computers, servers, and routers blog site. It describes an example of how IP SLA was used for redundancy and how fears of asyncronous routing were dismissed. From what I have seen and found, support for ip sla monitor started at about the 12.3 release of Cisco's IOS for routers. The two connections or paths to a destination or the internet as it is most often used for, don't even have to be directly connected to the router.