GTS with Qos LLC

Answered Question
Sep 24th, 2007
User Badges:

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.

Correct Answer by Joseph W. Doherty about 9 years 10 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
User Badges:
  • Bronze, 100 points or more

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
User Badges:
  • Super Bronze, 10000 points or more

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
User Badges:

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
User Badges:

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

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

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
User Badges:
  • Super Bronze, 10000 points or more

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
User Badges:
  • Super Bronze, 10000 points or more

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
User Badges:

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