Does bandwidth statement define allocation ratio in CBWFQ?

Unanswered Question
Oct 11th, 2007

A fundamental question on CBWFQ:

My understanding of ?bandwidth? statement on CBWFQ is: 1. Minimum bandwidth guarantee; 2. Weigh(ratio) for bandwidth allocation: For instance, bandwidth 20% to class A and 5% to class B, if there are only two classes traffic on the pipe and if the pipe is congested (means Queuing mechanism kicks in), IOS will start to allocate bandwidth based on weight, 20 to class A, 5 to class B with total weigh of 25. The end result of that is roughly 80% bandwidth will be used by A and 20% bandwidth will be used by B.

Is my understanding correct? I opened a TAC case, TAC engineer told me that bandwidth statement is only used for minimum bandwidth guarantee, after that, everything is evening located, so in above example it will be close to 50:50.

My testing on small pipes <4Mbps shows that IOS IS using bandwidth statement as allocation ratio quite closely, but on large pipe, like DS3, the ratio doesn't work any more. Any one has any idea? Is there anything I need to tune to make it work? I try to tune queue-limit, it works to certain extend (10%), but still far from "where it should be".

Any experience or insight info is appreciated.

Thanks,

Yatao

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
a.cruea1980 Fri, 10/12/2007 - 11:36

If the interface is congested, class A & B will have 25% of the total bandwidth, if and only if the pipe is congested.

If Class A needs more than 20% of the bandwidth in the pipe, it cannot be guaranteed to be expedited through the pipe. Likewise, Class B is only guaranteed 5%. . .anything over may or may not make it out quickly.

http://www.cisco.com/en/US/tech/tk543/tk757/technologies_tech_note09186a0080103eae.shtml

That might offer some insights into how bandwidth is allocated.

yatao Fri, 10/12/2007 - 11:45

Actually the link you sent just confirmed what my understanding. Look at those words from the link:

In the first example, policy-map foo guarantees 30 percent of the bandwidth to class bar and 60 percent of the bandwidth to class baz.

policy-map foo

class bar

bandwidth percent 30

class baz

bandwidth percent 60If you apply this policy to a 1 Mbps link, it means that 300 kbps is guaranteed to class bar, and 600 kbps is guaranteed to class baz. Importantly, 100 kbps is leftover for class-default. If class-default does not need it, the unused 100 kbps is available for use by class bar and class baz. If both classes need the bandwidth, they share it in proportion to the configured rates. In this configuration, the sharing ratio is 30:60 or 1:2.

Thank you very much for the link!

Yatao

Mohamed Sobair Fri, 10/12/2007 - 12:11

Hi,

In CB/WFQ the bandwidth gurantee the minimum bandwidth that a class could get when there is a congestion. Looking at ur example, when an Interface is congested, Class-A will be guranteed 20% of the interface bandwidth , and class-B will be guranteed 5% , the Bandwidth allocation for those are the lower Guranteed.

Then If there are more Traffic demanded by the same classes, it will be mapped to the Class-default (Fair-Queu) and the Weight isnot going to gurantee specific ratio for those , it just treated the same as the rest of the Traffic , so the Weight will be equally devided for all type of traffic.

HTH

Mohamed Sobair

Joseph W. Doherty Fri, 10/12/2007 - 18:14

My experience and understanding matches yours, in that setting bandwidths, besides setting minimum bandwidth guarantees, also defines the ratios between classes if the classes want more bandwidth.

What you might be bumping into on the DS3, especially if ATM, is the hardware interface FIFO queue. Only when the FIFO queue overflows does the software queues come into play. I read you've tried tuning "queue-limit", have your tried tuning tx-ring-limit?

Also, remember even if you don't explicitly define class-default, you have one. Any traffic falling into it that might impacting your other classes. (I will explicitly define it FIFO with a bandwidth setting so that I know how it will interact with other classes. FQ in class-default on non-7500s is a bit of a problem since each flows gets its own queue.)

yatao Sat, 10/13/2007 - 05:39

Joseph,

The ratio works great with T1 links. And yes, I did run into problem with higher bandwidth pipe. The ratio works great with T1 or a couple of T1s bundle, but with anything above 20M, it doesn't work any more. You are right again with ATM interface, I was able to tune tx-ring-limit on a 30M ATM pvc, the default valule is close to 1372 or something like that, once it changed to 120, ratio starts working again.

But with FrameRelay DS3, I don't have such luck, no matter what tx-ring-limit I change to, the ratio is not working. I had a TAC case open and is escalated to Design engineer.

Any one had any experience on this? Also what's guideline of tuning tx-ring-limit? I don't have voice traffic on my network, but I do want the ratio to work. Be glad to hear anyone sharing experience or documents on that: ATM or Frame Relay network with DS3 bandwidth.

Paolo Bevilacqua Sat, 10/13/2007 - 08:00

yatao,

do you have a CIR on this FR PVC? If yes, to wich value ? And what is the complete qos config for the serial interface ?

yatao Sat, 10/13/2007 - 09:22

Yes, 30M.

policy-map TRAFFIC-POLICY-WAN-OUT

class PRIORITY-OUT

priority 512 32000

class BESTEFFORT-OUT

bandwidth remaining percent 2

random-detect dscp-based

class BULK-OUT

bandwidth remaining percent 10

random-detect dscp-based

class CRITICAL-OUT

bandwidth remaining percent 35

random-detect dscp-based

class class-default

bandwidth remaining percent 25

random-detect

policy-map MQC-FRTS-T3

class class-default

shape average 30720000

service-policy TRAFFIC-POLICY-WAN-OUT

interface Serial1/0

description T3 VZB

mtu 1500

no ip address

encapsulation frame-relay IETF

logging event subif-link-status

logging event dlci-status-change

load-interval 30

dsu bandwidth 44210

frame-relay lmi-type ansi

!

interface Serial1/0.100 point-to-point

description 30M pvc

bandwidth 30720

ip address 10.1.9.1 255.255.255.252

frame-relay interface-dlci 100 IETF

class FR-MAP-CLASS-T3

map-class frame-relay FR-MAP-CLASS-T3

service-policy output MQC-FRTS-T3

Paolo Bevilacqua Sat, 10/13/2007 - 11:52

How is FR-MAP-CLASS-T3 configured ?

can you try "frame-relay class .." instead of "map-class frame-relay", as the latter is for SVC.

At that point, please use service-policy output TRAFFIC-POLICY-WAN-OUT directly under subif, as the FR code should take care of shaping on the PVC, and nested policy is not necessary.

yatao Sat, 10/13/2007 - 12:34

The config is at the bottom of the last message.

What you suggested is frame-relay traffic shaping, I am using Cisco current recommanded way:Class Based frame-relay traffic shaping.

Acutally I tried to change to frame-relay traffic shaping as well, the result is exactly the same as current config, ratio is not working.

Paolo Bevilacqua Sat, 10/13/2007 - 12:46

Well, with FR based shaping you would have FR-MAP-CLASS-T3 configured, that I don't see in the posted configuradion. How much traffic is the pvc delivering overall?

Actions

This Discussion