Cisco IP SLA for Network
Performance Monitoring
Cisco Systems - IP SLA Overview
IP SLA (Service Level Agreements) is a Cisco Systems technology used to measure network performance and health. It works by generating synthetic traffic over the network and recording performance metrics such as latency, jitter and packet loss.
One of the strengths of this technology is its ability to measure different types of traffic. This way, application specific data can be obtained that includes Quality of Service markings if required. The different IP SLA operations available include UDP Jitter, TCP connection time, DNS lookup time, DHCP server response time, FTP, HTTP, ICMP and DLSw+.
Of these, I've found UDP jitter for VOIP the most useful in terms of providing multiple statistics on the quality of the network. In particular, this operation has the ability to produce a Mean Opinion Score (MOS) after every traffic interval. It works by sending a synthetic UDP voice packet from a router running IP SLA to a destination router running as an IP SLA responder.
Having a responder as a destination allows the protocol to provide much more accurate view of the packet's journey. This includes reporting on the Source to Destination jitter as well as the Destination to Source (return path) jitter independently.
Used in conjunction with a reporting tool such as Ciscowork Internetwork Performance Monitor (IPM) a historical view of the network performance can be maintained. This includes recording MOS scores that are very good for baselining network performance. Even though MOS scores were originally designed as a VOIP performance measurement tool, there is no reason why UDP Jitter tests and MOS cannot also be used to baseline regular network data. In fact, IP SLA's ability to set DSCP markings on the synthetic traffic means that you can measure and record any Quality of Service class you like.
Cisco Systems - IP SLA Implementation Decision Points
There are a number of decision points prior to setting up IP SLA;
- The first is what data or application do you want to monitor? This determines the operation type to be used.
- The second is what will the data be used for? If the answer is ad-hoc troubleshooting then a router configuration may suffice. If the answer is baselining as well as troubleshooting then you will need an application to collect and store historical data. Ciscowork IPM module will do this job well.
- The third question is where are the key strategic points in the network? Since you will be sending synthetic traffic from a router running IP SLA toward a destination you need to determine which points in the network will give you the best indicator of how the real user traffic is travelling. In other words, what data path will the IP SLA traffic take and does that path traverse key links and routers.
- The fourth question involves Quality of Service. Do you need to monitor different QOS classes? Depending on how you mark your IP SLA traffic it may be put into QOS classes that may not necessarily reflect the classes that your real data is matching. For example, your VOIP packets may be matched based on codec but the synthetic IP SLA packets are configured as a different codec and are therefore placed in the default queue rather than the priority queue. This will mean that the data you collect may show impairment that never existed in the priority queue and it may skew your view of how your application is performing.
- The fifth consideration is how will you use the data? Collecting all the right data means nothing unless you have a process in place to analyse and act on it. Suppose your data shows that one of your critical applications is dropping packets. In this case you may want to re-adjust your QOS policy to commit more bandwidth to your critical application, or it may be a sign that you need more bandwidth.
Related Information
