Every example I see and what we have deployed is WRED "Random detect dscp-based" on our "class class-default"
Why is it, that you wouldnt stick "random-detect" on the other classes you have defined OR would you? Shouldnt RED and the Tail-drop (WeightedRed) only work on class-default so then the only traffic would be marked DSCP0 anyways? Or am i missing something??
There is no such restriction to use WRED
in the default class only. In fact you can
use it in any class within your policy and
even in the multiple classes at the same
* Please rate all useful posts
I know you CAN but Im just wondering why would you?
I guess the real question is:
If I am trying to drop things first in the default queue randomly, I apply "random detect" there. If then I want to drop things randomly when queues are exahasted, (it is 40 default not 60 with WRED though), then i put it in other classes.
I guess the confusion is, If i use "Dscp-based" Wred in one class say class-default..what does that even do? Its only going to see things with DSCP0 in that class anyways so why is that even relevant at all to use? Kinda makes no sense really to me.
I know im missing something
When you use WRED in default-class it is
used for the rest of non classified traffic
so in example above it is actually as if
you run WRED in a non class-based configuration. Even though it is not used
for classified by DCSP values traffic it still
performs congestion-avoidance for non the
rest of the traffic.
I thought you can't configure bandwidth commands in way that the total sum exceeds 75% (if default values are used) or 100% (if max-reserv band command is set to 100%.)
Your configuration configures the bandwidth to 108% even without the default class. My Q is - what is the router going to do if every class asks for the BW at the same time?
WRED is also used with other classes. You just need to foresee effect of it if traffic in that class is non-TCP - sometimes it will work good sometimes not really. By the way, tail-drop is not weighted RED.
The only major difference between class-default and other classes is that you can enable fair-queue within class-default, but not in other classes (so traffic within other classes is always FIFO). Other features you can configure in any class, including WRED.
You can have non-DSCP0 traffic in class-default and you can have DSCP0 traffic in class other than class-default, as well as multiple DSCP within any class. Class-default actually does not automagically remark traffic to DSCP0 unless you explicitly configure it to do so.
Hope this helps.
Thank you itya, it does help
Let me ask one followup.
I mark with DSCP on either a 6509 switch or the Fastethernet on the wanrouter, for the particular class ie:
set dscp ef
set dscp cs4
set dscp af21
set dscp af31
set dscp cs2
set dscp cs1
set dscp default
So all DSCPs are "reset" before they get output to the Wan.
Here is what, by default I will use on the outbound nested policy for many sites:
bandwidth percent 2
priority percent 5
bandwidth percent 32
bandwidth percent 10
police 768000 129046 conform-action transmit exceed-action drop
police 2753000 516187 conform-action transmit exceed-action drop
bandwidth percent 3
bandwidth percent 1
police 8000 2000 conform-action transmit exceed-action drop
bandwidth percent 25
In a couple situations, I changed class-default to "fair-queue" without a bandwidth and it does seem to work better.
Would you suggest I add WRED to each of the other classes just so things will drop based on DSCP kinda in order of "worst to best"...because right now it looks like im only dropping the worst traffic with WRED if another class became congested, right?
I'd first suggest you to profile your traffic to see what you actually have there and how much. At least add following command to each of your clases:
and after about a week look at 'sh policy-map interface'.
After that you can consider adding policer to each class that will pass conforming traffic unchanged, but for excessive traffic it will increase loss-priority (e.g. from AF31 to AF32 for exceeding and to AF33 for violating), then WRED you could enable WRED and watch if it does good or bad. In you current configuration WRED will work just like ordinary RED.
By the way, you configure both VIDEO and VOICE with priority command with intent to have them different queues with priority higher than the rest. In reality they're both directed into the same queue (you could see in 'sh policy-map interface'). VIDEO packets being not so small may impact your VOICE traffic (since both are in the same queue).
Another problem is that your use 'bandwidth' with percentage, but 'priority' with absolute value, that won't be accepted - you need to use either percentage in all classes or absolute value in all classes but not mixture.
Thats a good idea I didnt think of that.
Yah the Video is just multicast outbound protected--you actually can put in now a mix of percentage based and hard-bandwidth (12.3(10e code)... The Voice in that particular class is just some call-signaling stuff, for "real-voice" it is totally separate not shown in that example.
One question though, This really is to address the Citrix ICA Print killin the Interactive class---the print usually causes drops (tail drops) because it bursts the class (and link) to its max...so the normal ica drops.. We are trying to move to NBAR in hardware (6509s w/sup720s) to support the Citrix PDLM and have our Citrix folks "mark" the ICA Sessions so we can then break apart the Print.
But, until then, if I add the WRED to the interactive, remark, police the remarked like you said that would help i think ?
Is "Estimate bandwidth" you have to turn on Nbar collection correct?
WRED should generally help, so yes I'd suggest you to give it a try (together with remarking policer) but watch out the result at least first few days.
You don't have to turn on Nbar to get estimate bandwidth to work.