Cisco ISP Failover IP SLA Configuration Example
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 fail-over 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 configuration 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 custom application to use the T1 exclusively but in case there was a T1 internet access failure, they wanted to utilize the DSL as a failover. The custom application was critical to the business. The idea was simple, if the T1 fails, use the DSL for the custom application to connect to an online database source and server.There are some other mitigating factors that made this IP SLA configuration a little more challenging but I will not go into it at this time. It is not relevant 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 reason the line-code tracker in combination with the boolean 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 4.2.2.2 255.255.255.255 192.168.1.11 track 20 --> tracked main route
ip route 4.2.2.2 255.255.255.255 192.168.1.1 100 --> alternate route is used if T1 is down
ip sla 20 --> referenced in tracker 10
type echo protocol ipIcmpEcho 8.8.8.8 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 8.8.8.8 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
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 asynchronous 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.
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 asynchronous 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.
Enhance your Support Services with Software for Online Desktop Support.
