Doubt regarding WRED with Shaping

mohindersingh · ‎06-14-2008

Hi Fellow Networkers,

I am having a doubt regarding use of WRED with shaping..

policy-map Mahi

class Mahi1

priority percent 30

class Mahi2

bandwidth percent 35

random-detect

class Mahi3

bandwidth percent 1

random-detect

class class-default

bandwidth percent 30

random-detect

policy-map Mahi-WAN

class class-default

shape average 1536000

service-policy Mahi

int serial0

bandwidth 1536

service policy out Mahi-Wan

Here in the above mentioned policy, I am allocating 30% of bandwidth to class-default with WRED.

According to me if we apply WRED to a class, it means that class-default traffic will never reach to allocated 30% bandwidth because WRED will drop the packet randomly..

So if the traffic will never reach to 30% so what is the meaning to add shaping to same class with 1536K value?

Thanks in advance for replying...

Regards

Mahi

Joseph W. Doherty · ‎06-14-2008

Your child class-default, even with WRED, could obtain 100% of the available bandwidth. The class bandwidth sets a minimum guarantee for bandwidth in non-LLQ classes. Also, the purpose of WRED it to actually improve TCP goodput over a single queue using FIFO.

An item that appears odd in your example, assuming the serial is a T-1, there's not much point to use a shaper at the link's capacity.

mohindersingh · ‎06-16-2008

Hi Joseph,

I understood your point, but my query is mentioned below.

WRED as well as shaping will come in effect when there is congestion on the link.

WRED will not allow traffic to go above the configured bandwidth by dropping the packets so when the bandwidth in a default class is not reaching to configured bandwidth, then what is the point to shape the traffic at bandwidth level of interface?

Regards

Mahi

Wilson Samuel · ‎06-16-2008

Hi Mahi,

I guess your answer is in your question itself.

What is the point of shaping the traffic at a higher level, when you have already configured it to WRED it at a lower level. However as far I think, Shaping does apply to all kinds of traffic where as WRED is applicable to TCP traffic only. Hence though WRED will work perfectly for TCP, if your load is more UDP, shaping should do the rest.

Finally, to check it I guess I would do a lab and see what really happens.

All the best

HTH,

Kind Regards,

Wilson Samuel

Joseph W. Doherty · ‎06-16-2008

"WRED as well as shaping will come in effect when there is congestion on the link. "

Actually depends on configuration. WRED applies to congestion within the queue it's attached to. It's possible the interface could be congested, but not the queue WRED is attached to.

"WRED will not allow traffic to go above the configured bandwidth by dropping the packets so when the bandwidth in a default class is not reaching to configured bandwidth, then what is the point to shape the traffic at bandwidth level of interface?"

WRED has nothing to do with configured bandwidth, it monitors the average queue size and drops packets based on the average queue size vs. its settings.

WRED may (e.g. TCP), or may not (e.g. most non-TCP), have any impact as to limiting offered bandwidth. Since WRED settings are usually based on a running average queue size, the output tied to the queue will often burst to or even sustain 100%.

As to why shape to the bandwidth level of the physical interface, doesn't make much sense as I noted in my original post.