From: Petr Lapukhov (petr@internetworkexpert.com)
Date: Fri Jul 18 2008 - 12:05:35 ART
There is one significant difference, which is rooted in the fact that IOS
generic traffic-shaper implementation uses WFQ by default to service
delayed/queued packets. It's better be demonstrated using a simple example.
Consider R3 shaping traffic towards R2 using GTS per the following
configuration (R3 connects to R2 via Serial 1/3):
R3:
policy-map QUEUE
class class-default
bandwidth 64
!
policy-map SHAPE
class class-default
shape average 80000
service-policy QUEUE
!
interface Serial1/3
description == To R2
ip address 155.1.23.3 255.255.255.0
no fair-queue
service-policy output SHAPE
clockrate 128000
Next we generate traffic from R4, SW1 and R1 towards R2 (it does not matter
how those routers connect to R3) in such a way that all flows converge at
R3's Serial 1/3 interface . If the traffic rates are enough to make shaper
work (e.g. fast unconstrained ICMP flows) the following picture could be
observed:
Rack1R3#show traffic-shape queue
Traffic queued in shaping queue on Serial1/3
Traffic shape class: class-default
Queueing strategy: weighted fair
Queueing Stats: 64/1000/64/15626 (size/max total/threshold/drops)
Conversations 1/2/16 (active/max active/max total)
Reserved Conversations 1/1 (allocated/max allocated)
Available Bandwidth 16 kilobits/sec
(depth/weight/total drops/no-buffer drops/interleaves) 64/80/15627/0/0
Conversation 25, linktype: ip, length: 204
source: 155.1.146.4, destination: 150.1.2.2, id: 0x035A, ttl: 253, prot: 1
Even though we have 3 active flows only one "conversation" appers in the
shaper's queue. This is due to the fact that embedded, child policy
("QUEUE") specifies "bandwidht 64" which turns shaper's queue into a basic
FIFO, with just one fixed conversation. All flows effectively maps to this
conversation. Also note that "available bandwidth" is 16, which is naturally
80-64.
Let's change the configuration to the following (remove the "bandwidth"
keyword):
R3:
policy-map QUEUE
class class-default
no bandwidth 64
!
policy-map SHAPE
class class-default
shape average 80000
service-policy QUEUE
This will effectively turn shaper's queue into WFQ, which could be observed
using the following command output (the three flows are still active):
Rack1R3#show traffic-shape queue
Traffic queued in shaping queue on Serial1/3
Traffic shape class: class-default
Queueing strategy: weighted fair
Queueing Stats: 70/1000/64/24762 (size/max total/threshold/drops)
Conversations 3/3/16 (active/max active/max total)
Reserved Conversations 0/1 (allocated/max allocated)
Available Bandwidth 80 kilobits/sec
(depth/weight/total drops/no-buffer drops/interleaves) 14/32384/0/0/0
Conversation 14, linktype: ip, length: 204
source: 155.1.146.4, destination: 150.1.2.2, id: 0x7134, ttl: 253, prot: 1
(depth/weight/total drops/no-buffer drops/interleaves) 3/32384/0/0/0
Conversation 6, linktype: ip, length: 1404
source: 155.1.13.1, destination: 150.1.2.2, id: 0x6D30, ttl: 254, prot: 1
(depth/weight/total drops/no-buffer drops/interleaves) 53/32384/1233/0/0
Conversation 4, linktype: ip, length: 1404
source: 155.1.37.7, destination: 150.1.2.2, id: 0xEC49, ttl: 254, prot: 1
Now we see 3 converstaion out of 16 maximum permitted in the shaper's queue.
Therefore, the default shaper's queue is WFQ, with the number of flows based
on the configured shaping rate.
To summarize:
1) GTS by default uses WFQ for shaper's queue.
2) GTS queue could be changed by applying an embedded service-policy. This
effectively turns the queue into CBWFQ.
3) If "bandwidth" keyword is applied under "class-default" it will turn the
queuing policy into FIFO
Now back to the examples mentioned in the beginning of the thread. It makes
perfect sense to use "Method2", for this is how "oversubscribed" link could
be divided between two classes. Specifically, looking at:
class-map match-all PRE2
match ip precedence 2
class-map match-all PRE3
match ip precedence 3
!
policy-map PARENT
class PRE2
shape average 512000
bandwidth 256
class PRE3
shape average 1024000
bandwidth 512
We can say that class "PRE2" is limited to 512K maximum (upper bound) but is
always guaranteed 256Kbps of interface bandwidth(lower bound) when interface
is congested. The same goes to class "PRE3" with 1024Kbps and 512Kbps values
respectively. Note that both shapers will utilize WFQ queueing method, and
bandwidth weights only apply to the software queue of the physical
interface.
As for "Method1", it turns shaper queues (both) into FIFOs and applies the
"upper limit" on respective classes traffic rates. At the same time,
interface queue will remain FIFO or WFQ (depending on interface type and
speed) for all traffic flows, since no bandwidth weights are specified under
respective classes.
(Note that there is special behavior when "service-policy" with no
"bandwidth" or "fair-queue" settings in classes in applied to a physical
interface with FIFO queue ("no fair-queue" at physical interface). As soon
as any class in the policy-map is configured with "bandwidth" or
"class-default" is configured with "fair-queue" the interface queue will
turn into CBWFQ, and "no fair-queue" will disapper. Somewhat odd behavior).
HTH
-- Petr Lapukhov, CCIE #16379 (R&S/Security/SP/Voice) petr@internetworkexpert.comInternetwork Expert, Inc. http://www.InternetworkExpert.com Toll Free: 877-224-8987 Outside US: 775-826-4344 Online Community: http://www.IEOC.com CCIE Blog: http://blog.internetworkexpert.com
2008/7/18 <huan@huanlan.com>:
> Hmmm, > > In your example, you use MAIN INTERFACE, and I think the two configurations > do exactly the same. > > The difference exist if you try to apply the config on a sub-interface. The > second one can not be applied, because by default sub-interfaces do not > support queues. > > The first (hearachical) configuration creates queues by "shapping", and > therefore you can apply bandwidth reservation in the child policy. > > DOC CD has an example about this "work-arround". Do not remember the link > though. I am sure, you would easily find it in QoS section. > > > --- On Fri, 7/18/08, Huan Pham <pnhuan@yahoo.com> wrote: > From: Huan Pham <pnhuan@yahoo.com> > Subject: Re: Hierarchical QoS ! > To: "Cisco certification" <ccielab@groupstudy.com>, "Doan Dung Chi" < > dungchid@gmail.com> > Date: Friday, July 18, 2008, 9:14 PM > > Hi, > > I do not see any difference. Maybe I am color blind :-) > > Cheers, > > --- On Fri, 7/18/08, Doan Dung Chi <dungchid@gmail.com> wrote: > From: Doan Dung Chi <dungchid@gmail.com> > Subject: Hierarchical QoS ! > To: "Cisco certification" <ccielab@groupstudy.com> > Date: Friday, July 18, 2008, 8:19 PM > > Hi GS ! > > Please explain what is the deference btw 2 ways of QoS Configuration : > > Method 1: > > class-map match-all PRE2 > match ip precedence 2 > class-map match-all PRE3 > match ip precedence 3 > ! > policy-map PARENT > class PRE2 > shape average 512000 > service-policy CHILD-PRE2 > class PRE3 > shape average 1024000 > service-policy CHILD-PRE3 > ! > policy-map CHILD-PRE2 > class class-default > bandwidth 256 > policy-map CHILD-PRE3 > class class-default > bandwidth 512 > ! > interface serial 1/0 > service-policy output PARENT > > Method 2: > > class-map match-all PRE2 > match ip precedence 2 > class-map match-all PRE3 > match ip precedence 3 > ! > policy-map PARENT > class PRE2 > shape average 512000 > bandwidth 256 > class PRE3 > shape average 1024000 > bandwidth 512 > ! > > interface serial 1/0 > service-policy output PARENT > > In my understand, Interface will allocate bandwidth of 256kbps for Class > PRE2 > & 512kbpp for Class PRE3 when congestion occur in Method 1. However, In > Method > 2, I don't understand how Interface process queue. > Correct me if I am wrong ! > > Thanks > > > _______________________________________________________________________ > Subscription information may be found at: > http://www.groupstudy.com/list/CCIELab.html > > > _______________________________________________________________________ > Subscription information may be found at: > http://www.groupstudy.com/list/CCIELab.html > > > _______________________________________________________________________ > Subscription information may be found at: > http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Mon Aug 04 2008 - 06:11:55 ART