When using IP SLA operations on a large scale, a specific CoPP configuration to allow the IP SLA packets to pass through might be needed. Since IP SLA uses user defined UDP ports, there is no way to allow all IP SLA packets to the control plane. However, you can specify each destination/source port that IP SLA can use.

For more information about the verified scalability of the number of IP SLA probes, see the Cisco Nexus 3000 Series NX-OS Verified Scalability Guide.

The following shows an example of a CoPP configuration that allows IP SLA packets to pass through. It assumes destination ports and source ports in the range of 6500-7000.

ip access-list copp-system-sla-allow
  10 remark ### ALLOW SLA control packets from 1.1.1.0/24
  20 permit udp 1.1.1.0/24 any eq 1967
  30 remark ### ALLOW SLA data packets from 1.1.1.0/24 using ports 6500-7000
  40 permit udp 1.1.1.0/24 any range 6500 7000
  statistics per-entry
ip access-list copp-system-sla-deny
  10 remark ### this is a catch-all to match any other traffic
  20 permit ip any any
  statistics  per-entry
class-map type control-plane match-any copp-system-class-management-allow
  match access-group name copp-system-sla-allow
class-map type control-plane match-any copp-system-class-management-deny
  match access-group name copp-system-sla-deny
policy-map type control-plane copp-system-policy
    class copp-system-class-management-allow
    set cos 7
    police cir 4500 kbps bc 250 ms conform transmit violate drop
    class copp-system-class-management-deny
    police cir 4500 kbps bc 250 ms conform drop violate drop
control-plane
  service-policy input copp-system-policy

IP SLA only accepts ports within the local netstack port range. The source and destination ports used in the probe's configuration must match the supported netstack ports on the SLA sender and the SLA responder.

You can use the show sockets local-port-range command to view the port range on the sender/responder.

The following is an example of viewing the netstack port range:

switch# show sockets local-port-range 

Kstack local port range (15001 - 22002)
Netstack local port range (22003 – 65535)

One of the key metrics in measuring voice and video quality over an IP network is jitter. Jitter indicates the variation in delay between arriving packets (inter-packet delay variance). Jitter affects voice quality by causing uneven gaps in the speech pattern of the person talking. Other key performance parameters for voice and video transmission over IP networks include latency (delay) and packet loss. IP SLAs allow you to simulate and measure these parameters in order to ensure your network is meeting or exceeding service-level agreements with your users.

IP SLAs provide a UDP jitter operation, which consists of UDP probe packets sent across the network from an origin device to a specific destination (called the operational target). This synthetic traffic is used to record the amount of jitter for the connection, as well as the round-trip time, per-direction packet loss, and one-way delay time (one-way latency). (Synthetic traffic indicates that the network traffic is simulated; that is, the traffic is generated by IP SLAs.) Data, in the form of collected statistics, can be displayed for multiple tests over a user-defined period of time, allowing you to see, for example, how the network performs at different times of the day or over the course of a week. The jitter probe can use the IP SLAs Responder to provide minimal latency at the receiving end.

The IP SLAs VoIP UDP jitter operation modifies the standard UDP jitter operation by adding the capability to return MOS and ICPIF scores in the data collected by the operation, in addition to the metrics already gathered by the UDP jitter operation. This VoIP-specific implementation allows you to determine the performance of your VoIP network.

The IP SLAs VoIP UDP jitter operation computes statistics by sending n UDP packets, each of size s, sent t milliseconds apart, from a given source switch to a given target switch, at a given frequency f. The target switch must be running the IP SLAs Responder in order to process the probe operations.

To generate MOS and ICPIF scores, you specify the codec type used for the connection when configuring the VoIP UDP jitter operation. Based on the type of codec that you configure for the operation, the number of packets (n), the size of each payload (s), the inter-packet time interval (t), and the operational frequency (f) are automatically configured with default values. However, you are given the option, if needed, to manually configure these parameters in the syntax of the udp-jitter command.

The following table shows the default parameters that are configured for the operation by codec.

For example, if you configure the VoIP UDP jitter operation to use the characteristics for the g711ulaw codec, by default a probe operation is sent once a minute (f). Each probe operation consists of 1000 packets (n), each packet containing 180 bytes of synthetic data (s), sent 20 milliseconds apart (t).

ICPIF value computation with the Cisco NX-OS software is based primarily on the two main factors that can impair voice quality: delayed packets and lost packets. Because packet delay and packet loss can be measured by IP SLAs, the ICPIF formula, Icpif=Io+Iq+Idte+Idd+Ie-A, is simplified by assuming that the values of Io, Iq, and Idte are zero, as follows:

Total Impairment Factor (Icpif) = Delay Impairment Factor (Idd) + Equipment Impairment Factor (Ie) — Expectation/Advantage Factor (A)

The ICPIF value is computed by adding a Delay Impairment Factor, which is based on a measurement of delayed packets, and an Equipment Impairment Factor, which is based on a measurement of lost packets. From this sum of the total impairments measured in the network, an impairment variable (the Expectation Factor) is subtracted to yield the ICPIF.

Cisco gateways use this formula to calculate the ICPIF for received VoIP data streams.

IP SLAs use an observed correspondence between ICPIF and MOS values to estimate an MOS value.

Note	The abbreviation MOS represents MOSCQE (Mean Opinion Score; Conversational Quality, Estimated).

The E model, as defined in G.107 (03/2003), predicts the subjective quality that is experienced by an average listener by combining the impairment caused by transmission parameters (such as loss and delay) into a single rating, the transmission rating factor R (the R Factor). This rating, expressed in a scale of 0 (worst) to 100 (best), can be used to predict subjective user reactions, such as the MOS. Specifically, the MOS can be obtained from the R Factor with a converting formula. Conversely, a modified inverted form can be used to calculate R Factors from MOS values.

There is also a relationship between the ICPIF value and the R Factor. IP SLAs takes advantage of this correspondence by deriving the approximate MOS score from an estimated R Factor, which, in turn, is derived from the ICPIF score.

The following table shows the MOS values that are generated for corresponding ICPIF values.

IP SLAs always express the estimated MOS value as a number in the range of 1 to 5, with 5 being the best quality. A MOS value of 0 (zero) indicates that MOS data could not be generated for the operation.

Note

Currently, IP SLAs supports only the following speech codecs (compression methods): G.711 A Law (g711alaw: 64 kbps PCM compression method) G.711 mu Law (g711ulaw: 64 kbps PCM compression method) G.729A (g729a: 8 kbps CS-ACELP compression method) The following commands, available in UDP jitter configuration mode, are not valid for UDP jitter (codec) operations: history distributions-of-statistics-kept history statistics-distribution-interval request-data-size Specifying the codec-type will configure the appropriate default values for the codec-interval, codec-size, and codec-numpacket options. You should not specify values for the interval, size, and number of packet options unless you have a specific reason to override the defaults (for example, approximating a different codec). The show ip sla configuration command will list the values for the number of statistic distribution buckets kept and statistic distribution interval (microseconds), but these values do not apply to jitter (codec) operations.

Tip

If the IP SLAs operation is not running and generating statistics, add the verify-data command to the configuration of the operation (while configuring in IP SLA configuration mode) to enable data verification. When enabled, each operation response is checked for corruption. Use the verify-data command with caution during normal operations because it generates unnecessary overhead. Use the debug ip sla trace and debug ip sla error commands to help troubleshoot issues with an IP SLAs operation.

switch> enable

switch# configure terminal

switch(config)# feature sla sender

switch(config)# ip sla 10 

switch(config-ip-sla)# udp-jitter 209.165.200.225 16384 codec g711alaw advantage-factor 10

switch(config-ip-sla-jitter)# history enhanced interval 900 buckets 100

switch(config-ip-sla-jitter)# frequency 30

switch(config-ip-sla-jitter)# history hours-of-statistics-kept 4

switch(config-ip-sla-jitter)# owner admin 

switch(config-ip-sla-jitter)# tag TelnetPollServer1 

switch(config-ip-sla-jitter)# threshold 10000

switch(config-ip-sla-jitter)# timeout 10000 

switch(config-ip-sla-jitter)# tos 160 

switch(config-ip-sla-jitter)# verify-data

switch(config-ip-sla-jitter)# vrf vpn-A 

switch(config-ip-sla-jitter)# exit

switch(config)# ip sla schedule 5 start-time now life forever

switch(config)# exit

switch# show ip sla configuration 10

To add proactive threshold conditions and reactive triggering for generating traps or for starting another operation, see the Configuring Proactive Threshold Monitoring section.

To view and interpret the results of an IP SLAs operation use the show ip sla statistics command. Checking the output for fields that correspond to criteria in your service level agreement will help you determine whether the service metrics are acceptable.