From: Dennis J. Hartmann (dennisjhartmann@hotmail.com)
Date: Mon Sep 19 2005 - 02:17:23 GMT-3
Policing is supported on both Ingress and Egress interfaces.
Congestion CAN occur on an ingress interface, although it is far less likely
than congestion on an egress interface. Congestion occurs on an ingress
interface when the router is busy (high CPU) or when the switching fabric
(backplane) is oversubscribed. To my knowledge, WRED is supported on both
ingress and egress.
I agree that Shaping is an EGRESS-ONLY QoS mechanism.
I also agree that a candidate must be VERY careful in the wording of
the question, because policing and shaping can be very close to each other.
I disagree that congestion could never occur on the interface. I do
agree that congestion would NEVER occur for that particular SMTP traffic
class if it's being guaranteed 1Mbps and being policed to 1Mbps.
The scenario is not redundant by including the bandwidth command and
the policing command. It make sense. We want to guarantee SMTP 1Mbps
during periods of contention for bandwidth, but we also want to limit SMTP
to 1Mbps when there is no contention (1.544 Mbps available).
Sincerely,
Dennis Hartmann
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Tom
Lijnse
Sent: Thursday, June 30, 2005 4:04 AM
To: Chris Lewis (chrlewis); ccie2be; Rajib Khan; ccielab@groupstudy.com
Subject: RE: Police with random detect
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 : Sun Oct 02 2005 - 14:40:15 GMT-3