Hi Everyone,

OK so you've got some IP voice calls running over your WAN circuit and everything (as my Indian friends say) is maja. Now maybe historically everything has been good but today you are getting some complaints about voice quality. The calls are dropped or the remote side is gettgin big delay and blips on voice calls that sound like popcorn cooking (or a fried MP3 encoding). Maybe also the remote phones are a few hundred or thousand km away so you have no way to test this yourself. What you need is some remote testing tools....

Cisco brought us IP SLA or IP Service Level Agreements to do this  and now pretty much most decent network platforms have some sort of SLA support and you should look around for your own particular vendor support. This article is all about Cisco IP SLA and particularly VOICE Jitter. there will be another article on here regarding IP SLA for normal traffic - have a look a round.

Here is the dealio:

So the customer phone is on one side of the WAN. We've got the circuit terminating into a switch and there is a router at each end foign what they do best (routing and QoS management). The customer voice calls are being effected so we need a way to simulate that voice call. So welcome IP SLA and the SLA RESPONDER and REQUESTOR.

SLA can take many forms from ICMP ECHO to UDP and TCP requests such as HTTP GETs. We're going to configure a UDP Jitter test to simulate a voice call. So lets get down to it. The first thing I like to do is to setup the RESPONDER. This is the box which will RECEIVE and REPLY to the SLA requests. Most write-ups I've seen neglect to mention the RESPONDER. Indeed for ICMP reply SLA objects you do not need to configure a responder...but we do! There are some pre-requisities on newer Cisco platforms to support IP SLA. There are also many flavours and version of SLA depending upon which platform you need to run it on.

On a 2900/3900 devices will need a license upgrade to minimum datak9 to support the SLA feature. In this example I'm running the ipbase license set:

Technology    Technology-package           Technology-package
              Current       Type           Next reboot 
ipbase        ipbasek9      Permanent      ipbasek9
security      None          None           None
uc            None          None           None
data          None          None           None

When I try to use the IP SLA feature you'll see that I have very mimimal options:

RTR-01(config)#ip sla ?
  key-chain  Use MD5 Authentication for IP SLAs Control Messages
  responder  Enable IP SLAs Responder
  server     IPPM server configuration

When I add the data license I get a whole new set of options. Here is the license:

Technology    Technology-package           Technology-package
              Current       Type           Next reboot 
ipbase        ipbasek9      Permanent      ipbasek9
security      None          None           None
uc            None          None           None
data          None          None           datak9

Here are the features:

 RTR-01(config)#ip sla ?
  <1-2147483647>          Entry Number
  auto                    IP SLAs Auto Configuration
  enable                  Enable Event Notifications
  ethernet-monitor        IP SLAs Auto Ethernet Configuration
  group                   Group Configuration or Group Scheduling
  key-chain               Use MD5 Authentication for IP SLAs Control
  logging                 Enable Syslog
  low-memory              Configure Low Water Memory Mark
  reaction-configuration  IP SLAs Reaction-Configuration
  reaction-trigger        IP SLAs Trigger Assignment
  reset                   IP SLAs Reset
  responder               Enable IP SLAs Responder
  restart                 Restart An Active Entry
  schedule                Entry Scheduling
  server                  IPPM server configuration

So we've wasted a little time there but just in case you don't see the sla options now you know what it might be because of - licensing.

Lets configure the RESPONDER that we can POLL against for our VoIP test SLA. There is an IP address required here and this will become the 'HUB' address for our probes. I will choose the address which is a valid IP address on the RESPONDER router. Furthermore this HUB IP address must be reachable from the REQUESTOR so be sure you can ping this address from your remote router or your SLA will never work. On the responder router I configure simply:

ip sla responder auto-register

The auto-register feature simply allows the responder to add incoming SLA requests into it's allowed pool. You can customise this and the security of your SLA objects. I'm not going into detail here. We can confirm our SLA responder is running using the 'show ip sla responder' command in EXEC mode.

RTR-01#show ip sla responder
IP SLAs Responder is: Enabled
Number of control message received: 0 Number of errors: 0
Recent sources:
Recent error sources:

 Hub IP Address         Group           ClientID        Status            default         FCZ1111110      wait for ACK

OK great! we're all set to probe against our RESPONDER client. Note that when we receive remote SLA probes here the 'message receieved' counter will increment and you will be able to see the remote sources of the probes under the 'Recent sources:' statement.

OK now onto the REQUESTOR router. Here I need to build the SLA statement so lets create the UDP Jitter object. Before we start let me just explain that older versions of IOS and different platforms within the same version each have different SLA commands and ways of implementation. It's often never the same.

So first things first decide on a number for the SLA object. I chose 184 because I'm going to send these packets out with Type of Service (TOS) values of 184.

RTR-01#(config)ip sla 184

The first thing you have to do once you've been dropped into the IP SLA config sub-section is configure the 'type'. Now we're concentrating on voice jitter so thats our config but if you have a look at the context help you'll see other options.  So we'll configure a udp-jitter probe. We'll also make sure to set a source and destination IP and port (16384 - 32766 are the defaults and it has to be an even port btw). BUT here is a crucial bit - you MUST set the codec. If you miss out the codec then your SLA will not be able to build an MOS value and you will see '0' everytime in the results.
RTR-01(config-ip-sla)udp-jitter 16384 source-ip codec g711alaw

Now I'll set the TOS value for the outgoing packets to TOS 184 or DSCP 46 / IP Prec 5. Setting TOS to 184 means the bits look the same and DSCP 46 or EF. So my QoS config in the routers will think the SLA looks like voice packets and be expedited out.
RTR-01(config-ip-sla) tos 184

I'm gonna be running my SLA inside a VRF - you don't need this if you are not running VRF.

RTR-01(config-ip-sla) vrf MY_VRF

Most people will be polling an SLA from some sort of NMS like Orion or CiscoWorks or Cacti etc. If you are then you'd better put a label on your SLA.

RTR-01(config-ip-sla) tag IPSLA_VoIP_Jitter

Lastly you can set frequency of poll, timeout and thresholds but these are up to you. Your threshold should be below your timeout and the frequency should be more than the timeout. For example in my SLA I'm calling my probe every 5minutes (you need to state this is seconds). If the problem takes longer than 1500ms to respond then I want to raise an SNMP alarm on that (threshold) and if it breaks 2.5seconds (2500ms) then I want the SLA to fail.

RTR-01(config-ip-sla)frequency 300
RTR-01(config-ip-sla)timeout 2500
RTR-01(config-ip-sla)threshold 1500

Right thats all my configuration done so I'll exit out of the sub-prompt. The configuration for the SLA is now in place but there is one last step required and that's to TURN IT ON! Without making the SLA run it won't be doing anything. I'm going to tell the SLA to start running right away and never stop (unless I shutdown the router of course).

ip sla schedule 184 life forever start-time now

OK so thats that - exit back into EXEC mode and run a few show commands to see what is going on. The key result here for us is the MOS value at the end. Looking at this article from Cisco I expect a MOS value of around 4.1 for my G711 traffic.
RTR-01#sh ip sla statistics 184
IPSLAs Latest Operation Statistics

IPSLA operation id: 184
Type of operation: udp-jitter
        Latest RTT: 569 milliseconds
Latest operation start time: 12:03:22 GMT Mon Feb 27 2012
Latest operation return code: OK
RTT Values:
        Number Of RTT: 1000             RTT Min/Avg/Max: 542/569/634 milliseconds
Latency one-way time:
        Number of Latency one-way Samples: 745
        Source to Destination Latency one way Min/Avg/Max: 268/280/307 milliseconds
        Destination to Source Latency one way Min/Avg/Max: 270/281/292 milliseconds
Jitter Time:
        Number of SD Jitter Samples: 489
        Number of DS Jitter Samples: 493
        Source to Destination Jitter Min/Avg/Max: 0/12/34 milliseconds
        Destination to Source Jitter Min/Avg/Max: 0/5/16 milliseconds
Packet Loss Values:
        Loss Source to Destination: 0
        Source to Destination Loss Periods Number: 0
        Source to Destination Loss Period Length Min/Max: 0/0
        Source to Destination Inter Loss Period Length Min/Max: 0/0
        Loss Destination to Source: 0
        Destination to Source Loss Periods Number: 0
        Destination to Source Loss Period Length Min/Max: 0/0
        Destination to Source Inter Loss Period Length Min/Max: 0/0
        Out Of Sequence: 255    Tail Drop: 0
        Packet Late Arrival: 0  Packet Skipped: 0
Voice Score Values:
        Calculated Planning Impairment Factor (ICPIF): 21
        MOS score: 3.68
Number of successes: 9
Number of failures: 0
Operation time to live: Forever

I see I got a MOS score of 3.68. This is because I am receiving jitter on average of 5ms and 12ms for source/destination. I'm made up with that to be honest. The distance between my phone and call manager is across a satellite.

I hope this helped you guys.

Have fun
© 2011 defaultrouteuk.com

Cisco, IOS, CCNA, CCNP, CCIE are trademarks of Cisco Systems Inc.
JunOS, JNCIA, JNCIP, JNCIE are registered trademark of Juniper Networks Inc.