GTS with Qos LLC

Answered Question
Sep 24th, 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.

I have this problem too.
0 votes
Correct Answer by Joseph W. Doherty about 9 years 2 months ago

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
a.cruea1980 Tue, 09/25/2007 - 06:49

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 Tue, 09/25/2007 - 16:49

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 Wed, 09/26/2007 - 02:17

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 Wed, 09/26/2007 - 02:36

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

bowser Wed, 09/26/2007 - 03:12

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 Wed, 09/26/2007 - 03:43

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.

Correct Answer
Joseph W. Doherty Wed, 09/26/2007 - 03:41

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 Wed, 09/26/2007 - 03:57

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

Actions

This Discussion