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 ipbasek9security None None Noneuc None None Nonedata None None NoneWhen 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 configurationWhen 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 ipbasek9security None None Noneuc None None Nonedata None None datak9Here 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 10.1.0.1 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 10.1.0.1
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 error sources:
Hub IP Address Group ClientID Status
10.1.0.1 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 10.1.0.1 16384 source-ip 10.2.0.2 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.
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
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
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.