Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages wha2tsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
well , indeed I'm willing to be Wred master because i want the congestion when occurs to occur only my side not on the ISP provider side .
Right - good.
However, then, first thing to understand WRED doesn't create congestion, it's a drop management approach when there is congestion. Best, when possible, is to have the congestion form at the physical interface, but when you're have a logical rate limit, less than the interface bandwidth, you need to shape for the logical restriction. Logically, your second posted policy (syntax correct) would accomplish that.
Now, you did mention wanting to use WRED on TCP traffic, which makes sense, because it's really intended for rate adaptive traffic. Your policy, though, does not single out TCP traffic. So, you might want policies more like:
Policy Map isp
Class class-default
shape average 16000000
service-policy internet
Policy Map internet
Class tcp
random-detect
class class-default
Unsure what defaults an ASR uses for WRED, and/or whether your traffic has ToS markings, but by default, WRED generally has different defaults based on IPPrec.
You may want/need to adjust WRED min, max settings. What those settings should be depends on multiple factors.
Again, as I written, I consider getting WRED "right" is very difficult. So difficult, I cannot easily describe all the consideration here. Suggest you read several books that explain RED, then after that, research the Internet for articles on issues using RED. A good source of such information is all the other "improved" versions of RED that address (or try to) RED issues. Of course, Cisco's WRED implementation doesn't offer any of those "improvements" (well perhaps excluding Cisco's FRED, available on 4500s), but you'll better understand what you're dealing with, when trying to optimize RED performance.
BTW, personally, I find per-flow FQ tail-drop often a better technique for managing drops. Bandwidth hogs get dropped first, where with WRED, any flow in the WRED queue might be dropped (although statistically proportional to its bandwidth usage). Additionally, WRED works against queue averages, where FQ works against actual queue depths.
