Cisco’s IP SLAs are one of the most versatile tools we have as network engineers. You can monitor various things from TCP connection times to device availability via ICMP ping. (See here for a more exhaustive list.)
With endless possibilities comes great fun! Let’s explore a real-world example of how SLA can be used.
Route Determination
The Topology: We have R1 and R2 both connected to customer 1’s router. R1 connects to customer 1 via a fiber connection and R2 connects to via T1. We also have a connection from R1 to R2. See diagram below.
R1 —- [Fiber] |
| | Customer 1 Router
R2 —- [T1] |
The Scenario:
- The customer is buying IP Telephony service from Provider A.
- The customer wants to use a T1 connection as backup to the fiber connection
- The provider provides the fiber connection from R1
- The provider provides the T1 connection from R2
The Setup: The first problem we need to solve is how to guarantee that the fiber is used for the complete forwarding path. That is, we need to make sure that the forwarding path is symmetrical across the fiber.
(You also need to be aware that R1 to Customer 1 is not a point-to-point connection. This means if the fiber interface on the customer’s router was to fail in any way, R1’s interface would stay up/up.)
For us to guarantee that the route is symmetrical across the fiber, both R1 AND R2 need to have a route pointing to the fiber interface for all traffic going to customer 1. In addition, the customer’s router needs to have a route that prefers the fiber path.
So the first thing we need to do is determine the type of sla. In this example we will use an icmp-echo test. This will allows us to determine if the fiber interface is up or down on the CPE. Next we want to determine the schedule for the sla. The configuration is straightforward.
ip sla 1
icmp-echo 10.10.10.1
timeout 300
frequency 3
ip sla schedule 1 life forever start-time now
(You’ll notice the timeout and frequency settings in the sla. You can fine tune how seconds are in between each test (frequency) and how long each test should wait (timeout) before moving on. Lastly, the schedule configured here will start now and run forever. )
Now that we have the sla defined, we want to create a tracked object and apply this to a static route.
First we create the track object:
track 1 rtr 1 reachability
This creates a track object that is tied to the ip sla instance “1”.
Next we apply the object to a static route.
ip route x.x.x.x x.x.x.x 10.10.10.1 track 1
This simply tells the router that as long as we have reachability to the fiber interface, install this route in the routing table. If the sla fails, that is it can no longer ping the fiber interface, then the tracked object informs the router to pull the route from the routing table.
We also need to make sure the route gets redistributed into your dynamic routing protocol. This way both R1 and R2 will know about the route. The goal is to have R2 think the best route to the customer’s networks is through R1.
Next on R2 we need to have a route established to the customer’s networks going through the T1 interface.
One very important point here is the route must have a higher (worse) administrative distance than the route through R1. We want the route through R2 only to be installed into the routing table when the route through R1 fails.
Once your route through R2 is established, the only thing left is to verify both R1 and R2 are routing to the customer’s network through R1. Next, shutdown the fiber interface and verify that the backup link through R2 gets installed in routing table on both R1 and R2.
The last thing to do is setup a floating static route on the CPE, making sure the route through the fiber is preferred. You can even take it one step further and create a sla on the CPE that monitors the SP fiber interface. Then have two static default routes, one pointing towards the fiber, and one towards the T1. Then have the tracked object assigned to the default route point towards the fiber.
That’s it! Make sense? That is one real world example for using Cisco’s IP SLAs.
Haha, anyone else have examples of using IP SLAs? Please…
—Reference from packetpushers.net written by cjinfantino
More Related Cisco IP SLA Tips:
