From: Tom Lijnse (Tom.Lijnse@globalknowledge.nl)
Date: Thu Jun 30 2005 - 05:03:33 GMT-3
Hi all,
Let's try to summarize and clarify this.
To start with I am not 100% sure what the intention of the original
question was, but I'm assuming the following:
- SMTP must be strictly limited to 1 Mbps. No burst is allowed.
- Any SMTP traffic above 1 Mbps must be acted on by RED (random-detect).
- Other traffic is not to be affected.
Obviously, if the question is different we'll arrive at a different
answer.
As has been mentioned before RED can only be used as an add-on to a
queuing mechanism. It replaces the normal tail-dropping for a queue with
the RED random-drop mechanism. Therefore you need some queuing
mechanism.
This immediately rules out Rajib's original example, as queues can only
be formed at egress. Rajib's example has 'service-policy input' which
does not allow for any form of queuing and therefore does not allow for
RED to be used.
Now let's suppose we can move the service-policy to the outbound
interface. (If this is a valid assumption again depends on the wording
of the original question).
On the egress interface a queue can be created in two different ways.
As Chris remarked this could be the queuing on the physical interface,
but in order for that to kick in, the interface needs to be congested.
Only when there's enough non-SMTP traffic to load the interface up to
100% the RED mechanism will be used.
In this example though I want the queuing to kick in when the 1 Mbps
limit for SMTP is reached. The key to this is to use shaping instead of
policing. Policing simply throws away any packets above a certain
threshold, whereas shaping delays the packets above a certain threshold.
This creates a queue where all the delayed packets are waiting to be
sent, so now we have a queue that random-detect could act on: the
shaping queue.
Now how do we translate this into IOS code?
Basically we need to set up a service-policy that shapes SMTP to 1 Mbps
and then apply a queuing policy (using RED as a dropping mechanism) to
the shaping queue. This is accomplished by setting up a hierarchical
policy.
I'd say the following will do what's required:
policy-map SHAPE-SMTP
class SMTP
shape average 1000000 10000 0
service-policy RANDOM-DETECT
This sets the shaping to 1 Mbps, no burst and a 10 msec Tc interval.
policy-map RANDOM-DETECT
class SMTP
bandwidth 1000
random-detect
This specifies the queuing for the shaping queue. The bandwidth setting
is pretty irrelevant, as we only have one class anyway, but 1 Mbps is
the most intuitive setting. The shaping queue for SMTP will use RED as
the dropping mechanism.
interface Serial0
service-policy output SHAPE-SMTP
This applies the shaping to the outbound interface.
I think that the key to this question is to really understand the
difference between policing and shaping.
I hope this helps,
Tom Lijnse
CCIE #11031
Global Knowledge
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Chris Lewis (chrlewis)
Sent: woensdag 29 juni 2005 22:09
To: ccie2be; Rajib Khan; ccielab@groupstudy.com
Subject: RE: Police with random detect
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:46 GMT-3