- IP SLA
- Allows tracking of IP service levels by using active traffic monitoring
- Router generates packets to check service levels.
- Used to measure and verify service levels.
- QoS as example.
- Uses different types of probes depending on app being monitored.
- ICMP
- TCP
- UDP
- Can be tied with object tracking to take actions.
- Reliable static routes.
- Allows tracking of IP service levels by using active traffic monitoring
We’re running IP SLA examples between R5 and R4. R5 has a loopback with IP address 5.5.5.5 and R4 has loopback 4.4.4.4. The transit subnet is 10.30.1.0/24. R4 with .4 and R5 with .5. A backup path from R5 to R4 is through R3.
First config will just be ICMP from R5 to R4.
The only non-default configuration was changing the Threshold to a ping every 5 seconds. Next we need to schedule the ping for now and let it run forever. Then assign the SLA to a process for tracking.
The current reachability between the devices is completed with OSPF. What we can do though is add a static route that will take precedence over the OSPF AD of 110 and make the static depend on the IP SLA.
Once that is completed, the static route will be added or removed from the route table depending on the track succeeding.
After this we can add a floating static to R5 as well that has a higher administrative distance than our static with the track statement.
After shutting down the interface connecting R4 to R5, we see that the main static leaves the routing table and we have our alternate path with an AD of 15.
Next example is going to use TCP probes instead of just ping.
On R5 we created a tcp connect IP SLA and enabled forever. On R4 we had to create an IP SLA tcp responder for the IP and port we’re trying to hit. Now on R5 we can see the tcp connect is successful.
Same exact logic as the ping. We can change the tracking statement from IP SLA 1 to IP SLA 2, and now the tracking with the static route is taken care of.
mickx009.org 