From: Chris Lewis \(chrlewis\) (chrlewis@cisco.com)
Date: Wed Jun 29 2005 - 17:08:47 GMT-3
Depends what you are trying to achieve, marking down instead of dropping
excess traffc would form a queue if there is congestion on the
interface. Settign random detect on the interface would do it also if
the interface itself got congested, which depending on what else had to
be done would need a hierarchical policy.
The basic technicque for a queue to form is more traffic coming in to
something (either a constrained class or a physical interface) than it
can transmit :) I know this is too obvious, but that's what it is!
Chris
-----Original Message-----
From: ccie2be [mailto:ccie2be@nyc.rr.com]
Sent: Wednesday, June 29, 2005 3:01 PM
To: Chris Lewis (chrlewis); 'Rajib Khan'; ccielab@groupstudy.com
Subject: RE: Police with random detect
Thanks Chris for getting back to me.
Given Rajib config, what techniques are available to allow a queue to
form?
Tim
-----Original Message-----
From: Chris Lewis (chrlewis) [mailto:chrlewis@cisco.com]
Sent: Wednesday, June 29, 2005 3:47 PM
To: ccie2be; Rajib Khan; ccielab@groupstudy.com
Subject: RE: Police with random detect
Police and bandwidth for the same class do not appear in commonly
deployed service provider QoS models, so it would not be considered a
best practice, however as we know, lab questions can ask anything they
want :)
Any technique that allows a queue to form, gives WRED the opportunity to
function.
Chris
-----Original Message-----
From: ccie2be [mailto:ccie2be@nyc.rr.com]
Sent: Wednesday, June 29, 2005 2:02 PM
To: Chris Lewis (chrlewis); 'Rajib Khan'; ccielab@groupstudy.com
Subject: RE: Police with random detect
Hey Chris,
Is it appropriate to configure both BANDWIDTH and POLICE under one
policy map and would it be considered a best practice?
I know that bandwidth guarantees a minimum and police sets a maximum but
I wonder if this would be redundant.
Also, you point out that for WRED to have any affect, there's needs to
be a queue for it to work on. How should Rajib's config be modified so
that a queue can form?
My guess is if the exceed-action didn't drop packets, a queue would
form.
Do you agree?
TIA, Tim
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Chris Lewis (chrlewis)
Sent: Wednesday, June 29, 2005 2:45 PM
To: Rajib Khan; ccielab@groupstudy.com
Subject: RE: Police with random detect
Hi Rajib,
Looking at your policy-map, the first entry is a bandwdith command that
says that under interface congestion, give class smtp 1 Mbits/sec. This
implies to me that there is other traffic on this interface.
Then you specify random detect, so far so good, so that if other traffic
contributes to congestion and more than 1Mbit/sec of classs smtp traffic
comes in, a queue will form for traffic from this class and random
detect will take effect on that queue.
Next however, policing is configured with no burst above the committed
rate of 1 Meg allowed, and excess traffic is dropped. Random detect
needs a queue to form for it to do anything. If you are policing to the
rate at which you start to form a queue (as is done here when the
policed rate is the same as the bandwidth assured rate) no queue is
formed for this class and hence random detect has nothing to work upon.
Chris
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Rajib Khan
Sent: Wednesday, June 29, 2005 1:19 PM
To: ccielab@groupstudy.com
Subject: Police with random detect
Hi
I want to police smtp traffic to 1mb and no burst allowed, with policing
can I configure random detect or not. Would following config achive my
goal. Your help will be highly appreciated
class-map smtp
match access-group 120
access-list 120 permit tcp any any eq smtp
Policy-map smtp
class smtp
bandwidth 1000
random-detect
police cir 1000000 bc 187500 be 187500
conform-action transmit
exceed-action drop
Int s0
service-policy input smtp
Thanks is advance
Rajib
This archive was generated by hypermail 2.1.4 : Wed Jul 06 2005 - 14:43:45 GMT-3