I have a situation where an inside lan is connected to our 7200 router via a GigE interface, but the outward facing link is 120k serial.
What I am trying to accomplish is apply QOS policies to the router to ALWAYS allow voice streams to have priority, and never drop packets, or build up latency. At the same time, there will be other data on the link, but it can be buffered or dropped depending on link congestion.
I am having problems implementing this. The only workable solution I found so far is to set up some ACL's which define VOICE, and DATA. I am rate-limiting the GigE inbound DATA rate, with a rate-limit statement. If it DATA conforms to the rate-limit, I pass the traffic, if not it is dropped.
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?
Is there a way to achieve my goal some other way? (the relevant part of the config is attached.)
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:
priority percent 25
set ip dscp ef
set ip dscp cs3
bandwidth remaining percent 75
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.
"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:
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)
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.
[toc:faq]The ProblemOn traditional switches whenever we have a trunk
interface we use the VLAN tag to demultiplex the VLANs. The switch needs
to determine which MAC Address table to look in for a forwarding
decision. To do this we require the switch to do...
[toc:faq]Introduction:Netdr is a tool available on a RSP720, Sup720 or
Sup32 that allows one to capture packets on the RP or SP inband. The
netdr command can be used to capture both Tx and Rx packets in the
software switching path. This is not a substitut...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...