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.
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.
That might offer some insights into how bandwidth is allocated.
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.
bandwidth percent 30
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!
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.
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.)
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.
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 ?
priority 512 32000
bandwidth remaining percent 2
bandwidth remaining percent 10
bandwidth remaining percent 35
bandwidth remaining percent 25
shape average 30720000
description T3 VZB
no ip address
encapsulation frame-relay IETF
logging event subif-link-status
logging event dlci-status-change
dsu bandwidth 44210
frame-relay lmi-type ansi
interface Serial1/0.100 point-to-point
description 30M pvc
ip address 10.1.9.1 255.255.255.252
frame-relay interface-dlci 100 IETF
map-class frame-relay FR-MAP-CLASS-T3
service-policy output MQC-FRTS-T3
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.
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.
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?
Tech note on tuning ATM tx-ring-limit: http://www.cisco.com/en/US/tech/tk39/tk824/technologies_tech_note09186a00800fbafc.shtml
With regard to Frame-relay, I thought tx-ring-limit was supposed to impact it to. You might be able to verify by looking at tx-ring size via show controller command. If you have a TAC case open, hopefully Cisco will be able to explain.