Hi Rupesh,

I'm afraid you are wrong.

The default max-reserved-bandwidth value75% applies only to the bandwidth sum which can be reserved for particular classes, not the traffic passing the interface.

Also the class-default offered rate 157000 bps means the rate of packets coming in to the class, not the bandwidth available for the class.

@Colin:

IMHO, your config reserved 51 and 102 kbps for SCAVENGER and NET_MGMT_SERVICES classes, but nothing is reserved for the class-default.

I.e., in congestion time SCAVENGER and NET_MGMT_SERVICES traffic must get 51 and 102 kbps at least, the rest of bandwidth is shared between all classes in a ratio proportional to their bandwidth reserved.

It's not clear to me how is the class-default counted here (nothing reseved).

According to your output, there is no real congestion, nothing has been dropped yet.

(You are sending 286kbps in SCAVENGER and 157kbps in class-default).

But you can see there are 28 packets in the class-default queue, so it's being delayed.

It could be a good lab to reserve some bandwidth for the class-default and observe how the behaviour changes.

Last comment:

You should never show your passwords in config presented anywhere. The 7-encrypted passwords can be decrypted easily.

HTH,

Milan

Hi Milan,

Thanks for the suggestion, we will try it with the default bandwidth defined.

The idea is this: Traffic marked as going into Scavenger class is restricted if congestion occurs. Net_Mgmt (specifically SSH) gets dedicated bandwidth. This is because certain applications on the DSL sites are occasionally swamping the bandwidth.

What we are finding instead, is that Scavenger and Default classes appear to be sharing the bandwidth! The traffic is essentially Windows File Transfer, but as you can see from the output, there are packets queued, but none dropped.

Am I missing something fundamental?

Thanks

Colin

Hi Colin,

IMHO, what you are missing is the fact the Scavenger class is NOT restricted if congestion occurs.

You config resevers a minimal bandidth for it (51kbps).

In a congestiion time, if there is no NET_MGMT_SERVICES traffic running, the rest of bandwidth is shared between Scavenger and Default classes - this is what expected.

If you follow my discussin with Joseph, there are questions open HOW EXACTLY is the bandidth shared.

If you want to restrict the Scavenger to use ONLY a limited badwidth in a congestion time, you need to add a shaper or policer for Scavenger to your config.

BR,

Milan

Hi Joseph,

I agree with you.

(Only max-reserved-bandwidth 100 would be necessary in your config, too.)

But in a case of nothing reserved for the class-default, what happens if only NET_MGMT_SERVICES traffic (say a stream exceeding the interface bandwidth) plus some default-class traffic compete for the bandwidth?

"undefined bandwidth it's proportionally available to the other classes relative to their bandwidth allocations" - but class-default has nothing allocated, so NET_MGMT_SERVICES traffic will consume all the bandidth in this case?

I read somewhere this was the reason why the max-reserved-bandwidth=75% by default and 25% was reserved for the default-class then.

But I'm not able to find any document proving this.

What's your opinion?

BR,

Milan

"(Only max-reserved-bandwidth 100 would be necessary in your config, too.)"

Correct; good catch! Otherwise assuming the default 75% for defining CBWFQ bandwidth reservations, the class-default bandwidth statement should be 45%. In such case, the default 25% set aside would be available to the defined classes, if not otherwise used for other stuff.

The default of max-reserved-bandwidth of 75%, guarantees 25% of the link's bandwidth for other stuff; class-default w/o an explict bandwidth, whether undefined as a class as in implicit, or explicity defined with FQ, is able to obtain its bandwidth from this set aside bandwidth in addition to other bandwidth left non-reserved.

The 25% set aside by default is not the same as class class-default, although again, such a class-default will use the set aside bandwidth (as can other classes). If other other explict classes have reserved the max reserved, then class-default would implicitly get part of the 25% default set aside.

With default max reserved:

policies that should be "legal":

policy-map x

class x

bandwidth percent 75

or

policy-map x

class x

bandwidth percent 75

class class-default

or

policy-map x

class x

bandwidth percent 75

class class-default

fair-queue

or

policy-map x

class x

bandwidth percent 74

class class-default

bandwidth percent 1

Guess I might add:

policy-map x

class class-default

bandwidth percent 75

or

policy-map x

class x

bandwidth percent 1

class class-default

bandwidth percent 74

To demostrate the difference between class bandwidth reservations and the reserve bandwidth set aside.

Hi Joseph,

the core of my question is:

Let's say I've left the max-reserved-bandwidth=75

and configured:

policy-map x

class x

bandwidth percent 50

class class-default

bandwidth percent 25

In a case of congestion, class x will get 50%, class-default will get 25% as reserved.

The remaining 25% should be shared between class x and class-default in 2:1 ratio, so class x should get 66,7% and class-default should get 33,3% totally.

Correct?

What if I configure only

policy-map x

class x

bandwidth percent 50

class class-default

?

In a case of congestion class x should get 50% as reserved. The remaining 50% should be shared between class x and class-default.

But what will be the sharing ratio?

Thanks,

Milan

I too think there's 2:1 bandwidth split, as you believe in your first example. Although, I recall I may have read some Cisco documentation that noted available bandwidth is split between classes equally, not proportionally. Again, I believe it's proportional and also recall reading Cisco documentation to that effect too.

With your second example, I believe the answer is "none of the above". Without an explict bandwidth statement in class-default there should be an implicit FQ.

From my reading of "Understand Platform Differences" within http://www.cisco.com/en/US/tech/tk39/tk48/technologies_tech_note09186a00800fe2c1.shtml (although it discusses ATM interfaces, I believe the CBWFQ class-default FQ scheduling logic is likely independent of interface type), disrupts class guaranteed bandwidth percentages because of X number of FQ flows. In other words, in your second example, don't believe we can count on class x will always obtain at least 50% when there's congestion, or that it will obtain some predicted amount of available bandwidth, when there's class-default FQ. I don't think the question can be answered without knowing number of FQ flows, and if it's actually WFQ, you would also need to know IP Precedence for all the FQ flows too.

Hi Joseph,

I see I'll have to investigate the second case deeper in documenation and maybe build a lab.

Anyway, partial conclusion is:

I'll always us bandwidth settings for my class-default. It makes the behaviour predictable.

Thanks for your ideas,

Milan