Network Performance Testing with IPSLA, Latency Graphs, QOS and ICMP
Network Performance Testing with Cisco's IPSLA technology
IPSLA is a set of functionality built into the Cisco IOS. It allows network administrators to send IPSLA probes from a router that emulate different network traffic types. The response times are measured and recorded giving the network administrator a snapshot of the network performance. Here are some significant points about IPSLA.
- Can measure services such as DCHP, DNS, Voice and HTTP
- Can provide a single number (MOS Score) indicating the level of impairment on the network
- Includes latency, S-D and D-S jitter, and packet loss in impairment calculation
- Can set DSCP markings to monitor different QOS classes
To date IPSLA is the best network performance protocol that I have come across because of the detailed information that it returns. I have found that the UDP jitter (VOIP emulation packet) to be particularly useful in measuring impairment accross provider MPLS clouds. Ciscoworks IPM can also be configured to control and capture the results from the probes giving the network administrator a long term snapshot of network performance.
There are many different services IPSLA can emulate, DNS queries, DHCP requests and UDP Voice packets to name a few. But the IPSLA UDP Jitter operation in particular captures detailed measurements such as latency, source to destination jitter, destination to source jitter and packet loss. This operation is also capable of summarizing all these measurements into a MOS (Mean Opinion Score).
MOS scores are normally used as a VOIP quality indicator score, however, some innovative Cisco customers (yours truly!) also use this score to determine the quality of normal data for performance monitoring of client-server applications.In fact, because IPSLA probes can be sent with different QOS markings, the levels of impairment suffered by different QOS classes can also be captured and used to fine tune the QOS policy.
One of the most exciting things about producing a MOS score is that it captures line impairment levels throughout the day, in other words it captures periods when the link had to delay, queue or drop packets. Furthermore it presents those results in one easy to read number! So it is a much more accurate performance indicator than a utilization graph that is simply graphing transmission averages.
Presenting to Management
If you have worked with VOIP you know that different CODECs produce different theoretical MOS maximums. In other words, some CODECs sound better than others - but there is always a trade-off with bandwidth utilization.
The IPSLA emulated codecs are no different. Implementations that I have seen have always had a theoretical maximum of 4.06 of a possible 5. This means that if a MOS score of 4.06 is returned the probes experienced very little or no impairment accross the network.
But this is a difficult concept to explain to management. In order to get around this I have modified the common Standard Deviation formula to find the standard deviation from the theoretical maximum instead of from the average. The result is a neat and tidy score of 0 when there is no impairment and any number greater than 0 represents the standard deviation away from perfection. Here is the modified formula for those who would like to use it.
If you would like more help with this formula please feel free to email me (Andres) at support@it-pathways.com. I will try to respond in a timely manner.
How Will the Standard Deviation Highlight Poor Network Performance
Standard Deviation from Max-MOS (formula to the right) values will fall within the range of 0 to 4.06. A value of 0 indicates that there was no deviation from the maximum MOS (the best performance).
Experience has shown that a standard deviation of >0.6 or higher indicates that users experienced a noticeable and frustrating level of impairment from the network link.
Latency Graphs
- Useful for recording impairment variations on the network
- Useful for baselining round trip latency
Many network monitoring tools also provide latency statistics on their graphs. Latency is a better indicator of impairment on the network than utilization. A poor quality network link, for example, may show low utilization but high latency. Generally speaking latency should have some correlation with bandwidth utilization, when utilization is low latency should also be low, and vice versa. It is important to note that latency should be used as an alerting system of a possible network problem, there are many legitimate reasons why latency might increase so once high latency is discovered further analysis is required to determine the cause.
Quality of Service
- Useful for determining congestion hotspots
- With the right QOS policy - a lot of information can be gathered about application performance under load
- Very important Voice over IP (VOIP) enabling technology
- Counters are useful as network capacity management input
QOS (Quality of Service) on a router displays a great deal of information about the capacity of the link to forward packets without impairment.Statistics such as packet delays, drops, maximum queue size and average queue size can give a strong indication about whether network performance problems are caused due to insufficient capacity on the link. SNMP tools can be used to graph key QOS indicators on a network interface in order to build an accurate historical account of the link performance.
PING - ICMP
- Can identify delay variations indicating possible temporary congestion
- Can identify packet loss indicating congestion, policing, rate limiting or shaping along the data path
- Works with all network devices
- Only displays round trip time between source and destination
Good old trusted ping can help in the high level diagnosis of some network performance problems. Packet loss, for example is captured nicely by ping - as are high delays in the round trip time. The Latency information captured in Figure 3. is usually achieved by graphing Ping response times.
C:\Documents and Settings\it-pathways>ping 192.168.1.254
Pinging 192.168.1.254 with 32 bytes of data:
Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
Request timed out.
Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
Figure 4. Packet loss catured by ping
Diagrams
- Understanding the data path between the network monitoring system (NMS) and the destination is essential
- Help to identify aggregation points and congestion points to monitor
- Help to identify transparent technologies in the data path such as MPLS
- Phyiscal and logical data paths are not always the same - a diagram should distinguish between the two
Interpreting the output from a network monitoring tool is somewhat a specialized skill. Understanding how all the components fit together is a key tool in isolating a network performance fault. MPLS clouds, Frame Relay clouds, Packet Analysers, IPS/IDS and Layer 2 switches for example will generally not appear in Network Monitoring displays. The output above in figure 4, for example, may have well traversed other network equipment, we cannot tell.
Custom Search
