Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Where to apply random-detect for WAN interface

Hi everyone,

My network team has been having a discussion lately on where 'random-detect' should be placed.  For a long time we had it in the scavenger class and the default class.  I've personally never heard of it being in more than one class.  I think it should be in the default-class only. 

So this raised more questions:

1. can it be in both classes? If yes, Are there any problems with this?'

2. Should it only be in one class?

3. should it be in the Parent policy TEST_ETH10000 under class-default so it applies random-detect to all classes in the child policy TEST-MPLS-QoS ??

How are other enterprises implementing random-detect?

! Configure child policy

policy-map TEST-MPLS-QoS

class Voice

priority 1000

class Video

bandwidth remaining percent 40

class VVSignaling

bandwidth remaining percent 24

set ip dscp cs3

class NetworkSupport

bandwidth remaining percent 5

class Scavenger

bandwidth remaining percent 1

set ip dscp cs1

police rate percent 40

random-detect ??????

class class-default

bandwidth remaining percent 30

set ip dscp default

random-detect ??????

! Configure Parent policy

policy-map TEST_ETH10000

class class-default

  random-detect ??????

  shape average 9500000

   service-policy TEST-MPLS-QoS

! Apply to WAN interface

interface Gig1/1

description connection to MPLS ISP

service-policy output TEST_ETH100000

! Class-maps

class-map match-any Voice

match ip dscp ef

class-map match-any Video

match ip dscp af41 af42

class-map match-any VVSignaling

match ip dscp cs3

match ip dscp af31

class-map match-any NetworkSupport

match ip dscp cs6

match ip dscp cs2

match access-group name NetworkControl

class-map match-any Scavenger

match ip dscp cs1

match access-group name Scavenger-Protocols

thanks,
Dan

CCIE RS 34827       

CCIE RS 34827
1 REPLY
Super Bronze

Re: Where to apply random-detect for WAN interface

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 whatsoever (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

1. can it be in both classes? If yes, Are there any problems with this?'

2. Should it only be in one class?

3. should it be in the Parent policy TEST_ETH10000 under class-default so it applies random-detect to all classes in the child policy TEST-MPLS-QoS ??

How are other enterprises implementing random-detect?

#1 Sure, it can be used in both classes or multiple classes.  Possible problems, sure too - it's an "it depends" kind of answer.

#2 Another "it depends".  Doesn't have to be.  If FQ is supported on the platform I recommend that over RED.

#3 No, as parent policy is pushing queuing to child policy.

Re: other Enterprises

Don't know, but most, I think, don't really understand how to use RED effectively, which can be surprising difficult to accomplish (except for tiered drop points).  For example, RED was designed to interact with (equal valued) flow rate adaptive traffic, such as TCP.  If your class-default or scavenger has other than flow adaptive traffic, you're probably suboptimally using RED.  Or, for example, do you allow RED to target non-piggy-backed ACK packets?  If so, are you doing that by design or just allowing RED to target all class traffic?  If the latter, again, you're probably suboptimally using RED.

Besides many not really understanding RED, many don't, I also think, understand the finer nuisances of QoS.  For example, your scavenger class is provided 1% remaining bandwidth but is also policed at 40%.  Why the policer if the scheduler effectively is providing this class available bandwidth.  I.e. why limit available bandwidth, unless you pay extra for exceeding 40% bandwidth.  But if if you did, why use a policer and not a shaper?

131
Views
0
Helpful
1
Replies
CreatePlease login to create content