WRED and classes
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-28-2007 11:02 AM - edited 03-03-2019 04:20 PM
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??
- Labels:
-
Other Routing
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-29-2007 06:50 AM
Afilandro,
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
time.
Example:
--------------------------------------------
policy-map queue-on-dscp
class dscp-ef
bandwidth 58
class dscp-af41
bandwidth 22
class dscp-af21
bandwidth 20
random-detect dscp-based
class dscp-af23
bandwidth 8
random-detect dscp-based
class class-default
fair-queue
random-detect dscp-based
-------------------------------------------
HTH,
OW
* Please rate all useful posts
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-29-2007 07:11 AM
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-29-2007 07:29 AM
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.
HTH,
OW
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-04-2007 10:56 PM
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-29-2007 07:34 AM
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-29-2007 07:44 AM
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:
policy-map Fastein
class voice-in
set dscp ef
class video-in
set dscp cs4
class interactive-in
set dscp af21
class gold-in
set dscp af31
class network-in
set dscp cs2
class scavenger-in
set dscp cs1
class class-default
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:
policy-map pol-default
class ROUTING
bandwidth percent 2
class VOICE
priority percent 5
class VIDEO
priority 200
class INTERACTIVE
bandwidth percent 32
class GOLD
bandwidth percent 10
class BULK-DAY
police 768000 129046 conform-action transmit exceed-action drop
class BULK-NIGHT
police 2753000 516187 conform-action transmit exceed-action drop
class NETWORK
bandwidth percent 3
class SCAVENGER
bandwidth percent 1
police 8000 2000 conform-action transmit exceed-action drop
class class-default
bandwidth percent 25
random-detect dscp-based
random-detect ecn
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?
Thanks again
Alan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-29-2007 01:29 PM
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:
estimate bandwidth
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.
Cheers,
iLya
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
03-30-2007 01:11 PM
Thanks Ilya.
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?
Thanks again!
Alan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-03-2007 01:44 PM
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.
Cheers,
iLya
