Bobby,

Obviously there are several ways to skin a cat. That can also be said of QoS and applying it.

I haven't played around on a 7200 before but the basic principals of QoS are the same I would think.

Firstly, classifying the traffic (be that voice or data or whatever), which you have done with your class maps etc. btw, if you're using cisco phones and end-to-end qos, you need only match on the dscp value that the phones mark the packets with. Also, the voice service usually consists of signaling traffic and voice traffic. There isn't a class for signaling traffic in your config which you may want to add in.

Anyway, moving along: the next step is to perform an action on those packets. The policy-map command does this.

In your config, you have the policy map just setting an IPP value to voice packets, and a different IPP to data packets, but you aren't giving voice packets priority, nor are you using the class-default - which I think is advised.

You could try this:

policy-map QoS

class VOICE

priority percent 25

set ip dscp ef

class DATA

set ip dscp cs3

bandwidth remaining percent 75

class class-default

fair-queue

It is inadvisable to use IPP 7 as that is reserved for network functions like heartbeats and the like, so is IPP 6 which I think is used for routing etc. Precedence values of 0-5 are the range in which a Network Admin is advised to use.

The priority command in the class VOICE specifies to the router to use the priority queue; ie put any VOICE packets to the front of the queue! the percentage is based on the bandwidth statement in the actual interface. If the bandwidth statement on the interface is 120, then 25% of that means 30kilobits, usually okay for one on-net call (using G729).

Ip DSCP ef if the 'expedited forwarding' class, the kind of norm for voice traffic classification.

The class-default is used for sundry traffic like network overheads etc.

CS3 is the DSCP equivalnet to IPP 3.

As you've applied the policy to the interface, you should be good to go.

Personally I wouldn't have the rate limit configured on the internal interface though. The buffers will more than likely taildrop non-VOICE packets on the outgoing interface as the voice packets get priority.

Have a read of this:

http://tools.cisco.com/search/JSP/search-results.get?strQueryText=QoS+%22configuration+guides%22&strDocsPerPage=10&strStartDoc=1&strSortBy=&strqueryid=6&websessionid=zzjtggAuJHP_YA2UIf3Z2Y9&country=US&language=en&profile=enushomesppublished

there will be some helpful information on that page.

Also, it will be worth your while to classify the signaling traffic and give it higher precedence than data.

Good luck with it!

Brad

"Am I mistaken in thinking that if QOS is set up properly, the VOICE traffic should get put to the front of the line when it comes in? Even if there is a burst of DATA traffic, shouldn't the VOICE always get through with the higher priority? "

No you're not mistaken, that's what we want QoS to do for us.

"Is there a way to achieve my goal some other way?"

Perhaps, but only 120 Kbps!? Doesn't leave room for much voice, let alone anything else.

You don't actually need to classify inbound, since you can also do that outbound on router platforms (later) IOSs.

You also don't need to set ToS, unless you expect to use it later on further along the path and/or you want to influence WFQ or WRED.

A minimum policy to be used outbound, would be similar to this:

policy-map outboundSample

class voice

priority percent #

(optional - w/o it there's still an implict class-default which usually uses FQ, for most IOSs, but to make sure I suggest making it explicit)

class class-default

fair-queue

The value for bandwidth in the voice class would depend on how much bandwidth your voice will need. This depends on the codec and number of conservations.

For only 128 Kbps, you'll also need to use LFI or perhaps reduce the MTU, otherwise a non-voice large packet could introduce too much serialization delay (even though you have tx-ring-limit set to 1).

As Brad notes in his post, you might want to break out voice signally into its own class. However, the class-default FQ might suffice.

Edison's post uses WRED in class-default, but without tunning its parameters, and with all other traffic in class-default, I suggest just allow WFQ to tail-drop against its flow queues.

Like Edison, I suggest you verify your class map match criteria for voice. If your IOS is one of the later versions, you might also check whether NBAR will match your voice traffic.

Also like both Edison and Brad, suggest you don't rate limit the inbound side.

Sorry for replying to myself, but I wanted to thank everyone for their valuable input. I will try out the suggestions you have provided.

A little background for this setup: I work in a test lab, and we are evaluating how well IP traffic traverses RF signals. We are tasked to perform baseline tests for lowest rates (120k) all the way to 6Mbps. I have no problem with 6Mbps, but the 120k is where all the concerns are.

The voice data is actually a one-way point-to-point stream using G729 codec. No signaling needed. (NOT a a standard VoIP scenario!)

The port number is what will be used to differentiate between voice and data traffic.

As I said earlier - it is crucial that voice get through, while it is ok if some of the data is delayed.

Again thanks for the input. I will report back with results.