In any enterprise environment, there is one thing that comes up a lot, and that is redundancy. Take the healthcare industry for instance. When you have patients needing medical care, you can’t afford the downtime if a circuit goes down. Having a backup plan and in this case, a backup circuit for instance, is very important. So if you’ve never done something like this before, you might ask how you configure a redundancy plan such as this. This post will cover a very basic method of using a failover circuit.
Cisco IP SLA Test Topology
Take a look at the topology above. Between R1 and R2, there is a dedicated circuit of some sort that is the primary path of communication between these two locations. In these event this circuit would go down, each site should route traffic through their firewalls which are configured with a Lan to Lan VPN tunnel. This VPN tunnel is the redundant path for the traffic between 192.168.1.0/24 and 172.16.1.0/24.
Cisco IP SLA Configuration
Each of the routers connects to the hypothetical dedicated circuit on interface e0/3. Their interfaces are configured with the IP addresses:
R1 – 10.0.0.1/30
R2 – 10.0.0.2/30
I will take care of the configuration on R1. This will be the same, with just a small couple of edits, when you configure R2. Here is the configuration that we will apply to R1:
ip sla 2 icmp-echo 10.0.0.2 source-ip 10.0.0.1 frequency 15 ip sla schedule 2 life forever start-time now track 2 ip sla 2 reachability ! ip route 172.16.1.0 255.255.255.0 10.0.0.2 track 2
So here’s what we are looking at, line by line:
This line creates of SLA instance:
ip sla 2
This line sets the Cisco IP SLA parameters. In this case, we are using a simple ICMP echo to ping the other side just to see if we get a reply. We will specify the source address on the same subnet as the port we are pinging on the other side. This way it does not rely on any other routes, etc. It’s simply a connected subnet:
icmp-echo 10.0.0.2 source-ip 10.0.0.1
Next, we set the frequency that the packets, in our case the ICMP echoes, are sent.
Lastly, we set the schedule. In this case, we want the Cisco IP SLA to run forever:
ip sla schedule 2 life forever start-time now
At this point, the Cisco IP SLA is complete. It will run, send its ICMP echo traffic and report back accordingly. But we aren’t DOING anything with this info. That’s where the second half comes into play: the Track Statements:
track 2 ip sla 2 reachability
This creates a tracking scope with an instance number of 2 that monitors the Cisco IP SLA number 2. There is one more step and that concerns our static route directing traffic over the dedicated circuit:
ip route 172.16.1.0 255.255.255.0 10.0.0.2 track 2
By adding the statement “track 2” at the end of the static route, you are saying that as long as the track statement is valid (in our case, the ICMP echo is successful) then the static route will be used. Should the track statement fail, the static route will be removed from the routing table. In the case of our topology, the traffic would follow the default route to the firewall and over the Lan to Lan VPN tunnel.
This is the most basic, simplest form of a Cisco IP SLA. There are many more options and types that can be used. For more information you can use links like this one. One in particular that I like to use is the delay when I an using ICMP echo in my SLA. I wait until 3-4 echoes fail before calling a circuit down for instance. Little things like that are extremely useful based on the network you are working with.