Cisco IOS IP SLA (Service Level Agreements) Tool
December 12th, 2007 neteng
In today’s workplace, it’s no longer enough to throw up a couple of routers and switches, establish connectivity and declare that the network is complete. Managed services have become a hot item and Cisco has provided some tools to help us better manage the network and alert us to problems as they arise. In a world of VoIP and video conferencing, the Cisco IOS IP SLA service is indeed a powerful tool to add to your network monitoring toolkit.
Topic
Cisco IOS IP SLAs
Definition
Cisco’s SLA tool allows you to proactively monitor network conditions by generating traffic on a device and responding to that traffic from another device. It makes it easier to do such things as verify your QoS policy is working and make sure you’re meeting uptime agreements. When set up in an end-to-end manner, you can simulate the experience of a user and get a truer picture of their network performance. The SLA feature set is huge and results can be pulled up from the command line or via SNMP.
When configuring SLA entries, we need to have both a transmitter and a responder. The responder setup is very basic. To begin communications, the transmitter sends control messages to the responder. These control messages inform the responder as to what port it should listen on for transmitter requests (UDP or TCP). Enabling the responder service itself may not be necessary for some operations if the device is already listening on ports being tested (i.e. HTTP services).
Once an SLA operation has been configured on the transmitter, it’s operation needs to be scheduled. Statistics will only be gathered when the configuration is operational. Operations can be scheduled to start immediately, at a pre-determined date/time and they can even be triggered to start by certain events.
Instead of reinventing the wheel, I’ll refer you to Cisco’s awesome table of SLA capabilities.
Example
Because of the depth of the SLA tool, I’m going to just restrict myself to a very basic configuration. This will give you just a small glimpse into the possibilities the lie ahead. I recommend reading the references at the end of this article to go a little more in-depth. Here is our three-router topology:
We have OSPF running in a single area for these three routers, providing full end-to-end connectivity. Let’s go ahead and turn on the responder service on R3:
R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#ip sla responder
Let’s verify the service now:
R3#show ip sla responder
IP SLAs Responder is: Enabled
Number of control message received: 0 Number of errors: 0
Recent sources:
Recent error sources:
As you can see, we’re up and running on one end of our network. We have not received any control messages or data from our transmitter though. We’re going to have R1 act as our transmitter and perform the UDP Echo operation. This will measure the end-to-end response time for UDP traffic. First, we’ll configure our operation:
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#ip sla monitor 1
R1(config-ip-sla)#udp-echo 150.1.3.3 1234
R1(config-ip-sla-udp)#frequency 30
R1(config-ip-sla-udp)#exit
R1(config)#
What we’ve done here is configure an operation with an ID of 1, and within that operation, configured the router to send a UDP packet to R3’s Loopback0 address on port 1234. We’ve also set it to send a packet every 30 seconds (versus the default of 60 seconds). After this has been created, we need to schedule it to run:
R1(config)#ip sla schedule 1 life forever start-time now
The operation is scheduled to run immediately and never expire. Let’s take a look at the configuration we’ve just created:
R1#show ip sla configuration 1
IP SLAs, Infrastructure Engine-II.
Entry number: 1
Owner:
Tag:
Type of operation to perform: udp-echo
Target address/Source address: 150.1.3.3/0.0.0.0
Target port/Source port: 1234/0
Request size (ARR data portion): 16
Operation timeout (milliseconds): 5000
Type Of Service parameters: 0×0
Verify data: No
Data pattern:
Vrf Name:
Control Packets: enabled
Schedule:
Operation frequency (seconds): 30 (not considered if randomly scheduled)
Next Scheduled Start Time: Start Time already passed
Group Scheduled : FALSE
Randomly Scheduled : FALSE
Life (seconds): Forever
Entry Ageout (seconds): never
Recurring (Starting Everyday): FALSE
Status of entry (SNMP RowStatus): Active
Threshold (milliseconds): 5000
Distribution Statistics:
Number of statistic hours kept: 2
Number of statistic distribution buckets kept: 1
Statistic distribution interval (milliseconds): 20
Enhanced History:
History Statistics:
Number of history Lives kept: 0
Number of history Buckets kept: 15
History Filter Type: None
I’ve highlighted the pertinent parts of our configuration. Now that we’ve let this run for a bit, lets check the results on both routers:
R1#show ip sla statistics 1
Round Trip Time (RTT) for Index 1
Latest RTT: 68 milliseconds
Latest operation start time: *13:35:48.015 UTC Wed Dec 12 2007
Latest operation return code: OK
Number of successes: 9
Number of failures: 0
Operation time to live: ForeverR3#show ip sla responder
IP SLAs Responder is: Enabled
Number of control message received: 9 Number of errors: 0
Recent sources:
192.168.12.1 [13:36:17.971 UTC Wed Dec 12 2007]
192.168.12.1 [13:35:47.971 UTC Wed Dec 12 2007]
192.168.12.1 [13:35:17.959 UTC Wed Dec 12 2007]
192.168.12.1 [13:34:47.951 UTC Wed Dec 12 2007]
192.168.12.1 [13:34:17.999 UTC Wed Dec 12 2007]
Recent error sources:
Pretty cool, huh? Now you should be asking yourself, “How can I make this information useful?” Good question. One thing we can do is use this SLA entry as an object that can be tracked by other commands. Let’s create a static route that will only be available if the SLA operation we created is successful:
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#track 1 rtr 1
R1(config-track)#exit
R1(config)#ip route 123.123.123.0 255.255.255.0 192.168.12.2 track 1
As a side note, you’ll notice that the track statement refers to rtr. This is the old name Cisco used for the SLA tool in previous IOS versions. It stands for Response Time Reporter. As you can see, it’s legacy lives on in the current IOS. We can verify that our static route is currently in R1’s routing table:
R1#sh ip route static
123.0.0.0/24 is subnetted, 1 subnets
S 123.123.123.0 [1/0] via 192.168.12.2
Now let’s shut down our Loopback0 interface on R3 (remember that it’s the target of our SLA operation):
R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#int lo0
R3(config-if)#shut
This should effectively kill our UDP echo operation:
R1#sh ip sla statistics 1
Round Trip Time (RTT) for Index 1
Latest RTT: NoConnection/Busy/Timeout
Latest operation start time: *13:48:17.903 UTC Wed Dec 12 2007
Latest operation return code: No connection
Number of successes: 32
Number of failures: 1
Operation time to live: Forever
Interesting! Now let’s see if we still have our static route:
R1#sh ip route 123.123.123.0
% Network not in table
Cool! As you can see, we can really take more control of how our networks behave by utilizing the SLA tool. Once we turn R3’s Loopback0 interface back up, we will see the static route reappear in our routing table after the next UDP echo interval.
References
Cisco IOS IP SLAs Configuration Guide, Release 12.4
Service Assurance Agent (SAA) and the Management Engine
Well folks, that’s just the beginning of what this wonderful tool can do. Be sure to scour the references I’ve linked to and see how you can put it to use in your networks.
neteng
Buy Me a Beer! Help me keep my sanity as I write more articles.
Posted in HOWTO, Networking, Routing, Tools | 1 Comment »
I finished up this lab and decided to go ahead and post it today. We’re using our familiar topology but we’ll be moving away from static RP assignments and using Cisco’s Auto-RP:
