Solved: GTS with Qos LLC

bowser · ‎09-24-2007

Can anyone tell me what is considered best practice when traffic shaping is required due to a fast ethernet carrier handoff, shaped to 20mb?

traffic-shape rate 20000000 200000 0 1000

I currently have voice calls traversing over the 20mb link that experience issues which correspond with times of heavy usage.

show policy-map output doesn't display any drops for any queue, although show traffic-shape queue fa0/0

does:

Queueing Stats: 19/1000/64/354701 (size/max total/threshold/drops)

Can anyone suggested an improvement? I suspect traffic shaping might be causing the call quality to suffer.

Joseph W. Doherty · ‎09-26-2007

You don't want to have both a traffic shape command and service policy on the same interface, you want to have a service policy that does the shaping.

If you have both, the GTS shaper is queuing traffic and most (or all?) of it isn't overflowing into your service policy queues including the LLQ. You might be able to see this by looking at the service policy stats. I.e. packets queued in the GTS shaper, as you noted, and none or little matches within the service policy. Or, besides not seeing tail or WRED drops, do you see queues also form in your service policy or what's the match ratio to packets that match the service policy class?

Actually, I believe something similar even happens when you use "standard" hierarchal service policy. I.e. Still might have two levels of queues. This is why I also provided an example of a non-hierarchal service policy with a high level LLQ and shaping in the default class.

Something else to be aware of, physical interfaces usually maintain their own hardware FIFO queue, especially ATM interfaces. This can be a problem for voice since LLQ doesn't apply until after the hardware FIFO queue overflows into the software queues. This can be reconfigured use tx-ring-limit.

Didn't know what version of IOS you're using or your allocation for voice. You could either use 12% directly with 12.4 or 1.7 MB.

PS:

Again, another option is to only use GTS, but to insure the voice packets get a much higher ratio of the shaped bandwidth via their weight.

View solution in original post

a.cruea1980 · ‎09-25-2007

Well, just off the top of my head, with the limited information you've given, the only idea I can come up with is that your VoIP is getting put in with bulk traffic and getting dropped.

If you didn't do it, try setting up a priority queue for your VoIP. You might also post up your config, as that may help us diagnose better what could be happening.

Joseph W. Doherty · ‎09-25-2007

You need to prioritize voice. If you're using ordinary GTS, believe it uses WFQ.

You could tag your voice packets either with IP prec 5 or DSCP EF. This might provide enough extra weight to the voice flows, but it might not too.

Otherwise you'll need to CBWFQ such as:

(pseudo config)

policy-map split-bw

class voice

priority 2 mb

class class-default

shape 18 mb

or

policy-map parent

class class-default

shape 20 mb

service policy child

policy-map child

class voice

priority 2 mb

class class-default

fq

bowser · ‎09-26-2007

Hi, thanks both for the response.

I should have made myself clearer in the original post. My config currently shapes traffic to 20mb on the physical fa0/0 interface. This is via the traffic-shape command.

Also applied to the same interface is a service-policy which inludes 12% allocated to voice, in the priority LLC queue.

With all this config I don't see any tail drops or WRED within the 'show policy map interface fa0/0'. However if I enter 'show traffic-shape queue fa0/0', drops increment during peak traffic periods.

traffic shape config listed above.

ariesc_33 · ‎09-26-2007

12 percent may not be enough for your voice traffic during peak hours.

bowser · ‎09-26-2007

If it wasn't enough I would see drops under the voice class, and an offered rate reading at the priority class limit. I don't see either.

Joseph W. Doherty · ‎09-26-2007

If you're not seeing a offered load to your LLQ class, either you're not matching correctly or packets aren't overflowing from GTS into CBWFQ, as described in my other post.

Joseph W. Doherty · ‎09-26-2007

You don't want to have both a traffic shape command and service policy on the same interface, you want to have a service policy that does the shaping.

If you have both, the GTS shaper is queuing traffic and most (or all?) of it isn't overflowing into your service policy queues including the LLQ. You might be able to see this by looking at the service policy stats. I.e. packets queued in the GTS shaper, as you noted, and none or little matches within the service policy. Or, besides not seeing tail or WRED drops, do you see queues also form in your service policy or what's the match ratio to packets that match the service policy class?

Actually, I believe something similar even happens when you use "standard" hierarchal service policy. I.e. Still might have two levels of queues. This is why I also provided an example of a non-hierarchal service policy with a high level LLQ and shaping in the default class.

Something else to be aware of, physical interfaces usually maintain their own hardware FIFO queue, especially ATM interfaces. This can be a problem for voice since LLQ doesn't apply until after the hardware FIFO queue overflows into the software queues. This can be reconfigured use tx-ring-limit.

Didn't know what version of IOS you're using or your allocation for voice. You could either use 12% directly with 12.4 or 1.7 MB.

PS:

Again, another option is to only use GTS, but to insure the voice packets get a much higher ratio of the shaped bandwidth via their weight.

bowser · ‎09-26-2007

Thanks Joseph, I think that I might remove GTS and shape within my policy map. Hopefully the results will be more consistant.