Quality of Service question

[WStoffel1]

I have a cisco 2800 router that I have to set up quality of service for a new voip system coming over a leased line.

My question boils down to more procedural than looking for the actual answers.

I have an existing config for an old VoIP system that I can use to reverse engineer.

But how do you know what are acceptable values for dscp?  Since it's voice is it just assumed to be match ip dscp ef?

Or what about setting TOS values instead?

Also on the policy map how do you know what priority to set?

The issue I have is the original config I'm looking at was for a 2800 with Cisco IP phones.  This new setup is with Bicom, and they are using Yealink T22 SIP phones.  And I haven't turned up much info from the manufacturers as of yet.

Thanks.

[John Blakley · Accepted solution]

It's generally accepted that phones will mark their voice traffic with dscp ef (46) or cos 5. If you're sending your traffic through a router and you have CoS configured on your switch, the CoS marking will be mapped to a dscp value using a cos-dscp map. The dscp value is what's sent through the cloud. Your priority values are basically what you want to set them to. Keep in mind that when you use priority to create an LLQ, it's going to take that amount of bandwidth off of the total useable when something gets placed into the queue.

For example, if you did "priority percent 10" on a 10Mb circuit, the voice queue will automatically get 1Mb of bandwidth. That would leave 9mb for the rest of your traffic. You may not need that much. I believe you can calculate how much bandwidth you need by multiplying the codec bandwidth that you're using by the amount of phones that you have in order to get a good value.

http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a0080094ae2.shtml

The values in the above link are globally recognized for G711 and G729. If you're using either one of these, then you should be good to go.

HTH,
John

*** Please rate all useful posts ***

[WStoffel1]

exactly what i was looking for..thank you.

any idea (from an old config that I didnt' create) that the voip control ports (1719 and 1720) would have a value of af31?

[Joseph W. Doherty]

Disclaimer

The   Author of this posting offers the information contained within this   posting without consideration and with the reader's understanding that   there's no implied or expressed suitability or fitness for any purpose.   Information provided is for informational purposes only and should not   be construed as rendering professional advice of any kind. Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

Keep in mind that when you use priority to create an LLQ, it's going to take that amount of bandwidth off of the total useable when something gets placed into the queue.
For example, if you did "priority percent 10" on a 10Mb circuit, the voice queue will automatically get 1Mb of bandwidth. That would leave 9mb for the rest of your traffic.

Not exactly, LLQ expected behavior is somewhat surprising.

When you define a LLQ (or PQ on switches), queued elements have absolute priority over any other queued element.  I.e. they will be transmitted next.

For LLQ (unlike a switch's PQ), to avoid total bandwidth starvation of the non-LLQ queues, there's an implicit policer that caps LLQs bandwidth consumption but only when there's congestion.

For your example, on a 10 Mbps port, it's possible to transmit up to 10 Mbps in the LLQ class.  However, if the combination of LLQ and non-LLQ traffic exceeds 10 Mbps, in your example of priority percent 10, the LLQ traffic would be policed to 1 Mbps during congestion.

Basically, if the LLQ queues, queued elements are subject to the LLQ bandwidth cap.

The reason understanding this is important, is so you're not surprised when you might see LLQ exceeding its "limit".  The danger, though, if this is happening, your VoIP will work fine until other traffic forces LLQ policing to happen.

BTW, conversely, bandwidth not being used by LLQ can be used by other traffic, i.e. you see FTP using 10 Mbps in John's example.  Again, so you understand when you set aside 1 Mbps for LLQ, it's not set aside all the time.

[Joseph W. Doherty]

Disclaimer

The   Author of this posting offers the information contained within this   posting without consideration and with the reader's understanding that   there's no implied or expressed suitability or fitness for any purpose.   Information provided is for informational purposes only and should not   be construed as rendering professional advice of any kind. Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

But how do you know what are acceptable values for dscp?  Since it's voice is it just assumed to be match ip dscp ef?
Or what about setting TOS values instead?
Also on the policy map how do you know what priority to set?

Acceptable values for DSCP are whatever you want, however both Cisco and RFC recommend certain markings for certain purposes.  Marking is only  used to "color" packets so they can easiliy be identified so they can be treated differently.

When using DSCP, general recommendation for marking VoIP bearer traffic is DSCP EF.  There are different recommendations for marking VoIP signaling traffic.  Cisco currently recommends DSCP CS3 (previously AF31), current RFC recommends DSCP CS5.  (Note: often VoIP vendors recommend marking all VoIP traffic DSCP EF.  [They don't often really understand QoS on data networks.]  Fortunately, signaling bandwidth consumption is usually light, so doing this isn't often harmful.)

Setting DSCP values sets the first 6 bits of the ToS; the last two bits are set aside for other usage.  (Setting IPPrec sets the first 3 bits.)

For VoIP bearer traffic, LLQ or PQ is used (i.e. they go first).  LLQ limits are set such that there's sufficient bandwidth for the expected traffic.  (Ideally, call admission insures these limits are not exceeded.)  For VoIP signaling traffic, they are often in an ordinary queue that has enough bandwidth guarantee that their packets won't be dropped.

If you're working with L2 CoS, you would use the DSCP class selector that "covers" the more discreet DSCP value.  E.g. CoS 5 (or IPPrec 5) would be used for DSCP EF.