From: simon hart (simon@harttel.com)
Date: Thu Sep 29 2005 - 07:59:02 GMT-3
Richard,
No it will take the configured bandwidth - see below
interface Serial0
bandwidth 64
ip address 158.1.123.1 255.255.255.0
end
Rack1R1(config)#int s0
Rack1R1(config-if)#service-policy out QOS
I/f Serial0 class TEST requested bandwidth 512 (kbps), available only 48
(kbps)
Rack1R1#sh policy-map
Policy Map QOS
Class TEST
Bandwidth 512 (kbps) Max Threshold 64 (packets)
HTH
Simon
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
richard.harvey@nbs.nhs.uk
Sent: 29 September 2005 10:02
To: bmcgahan@internetworkexpert.com; andrew.m.edwards@boeing.com;
ccielab@groupstudy.com
Subject: RE: MQC bandwidth
Just going back to the configured bandwidth of the interface.
I was under the impression the only time the *configured* interface
bandwidth was referenced by any QOS policy is when you use the "bandwidth
percent" policy-map command. Otherwise CBWFQ works within an imposed
bandwidth limit - either from the physical interface access-rate, the
frame-relay shaping rate, or a parent service-policy shaping rate.
Is this correct?
Richard
-----Original Message-----
From: MIME :bmcgahan@internetworkexpert.com Sent: 29 September 2005 01:03
To: andrew.m.edwards@boeing.com; ccielab@groupstudy.com
Subject: RE: MQC bandwidth
Yes and no. The feature described in that link is fragmentation
at the interface level without FRTS enabled. When FRTS is disabled all
VCs share the same output queue, whether they're on the main or
subinterface. Specifically it says:
"This new feature simplifies the configuration of low-latency,
low-jitter quality of service (QoS) by enabling the queueing policy and
fragmentation configured on the main interface to apply to all permanent
virtual circuits (PVCs) and subinterfaces under that interface." The
reason why it applies to all VCs is because all VCs share
the same output queue when FRTS is disabled, onto which the
fragmentation is applied.
"Before the introduction of this feature, queueing and fragmentation had
to be configured on each individual PVC."
This is true because previously fragmentation could only be
applied through FRTS, which implies per VC queueing.
"For interleaving to work, both fragmentation and the low-latency
queueing policy must be configured with shaping disabled"
This is also true because interface level fragmentation requires
the usage of a single output queue for all VCs, which FRTS does not
have.
For fragmentation to be supported in conjunction with shaping
the fragmentation parameters need to be defined inside a "frame-relay
map-class" in which legacy or MQC based FRTS is applied.
HTH,
Brian McGahan, CCIE #8593
bmcgahan@internetworkexpert.com Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987 x 705
Outside US: 775-826-4344 x 705
24/7 Support: http://forum.internetworkexpert.com
Live Chat: http://www.internetworkexpert.com/chat/
> -----Original Message-----
> From: Edwards, Andrew M [mailto:andrew.m.edwards@boeing.com]
> Sent: Wednesday, September 28, 2005 5:58 PM
> To: Brian McGahan
> Subject: RE: MQC bandwidth
> > Well, I was reading on doccd that when shaping is enabled and FRF.12
is
> enabled, interleaving does not occur.
> > "Subrate shaping can also be applied to the interface, but
interleaving
> of high-priority frames will not work when shaping is configured. If
> shaping is not configured, each PVC will be allowed to send bursts of
> traffic up to the physical line rate.
> > When shaping is configured and traffic exceeds the rate at which the
> shaper can send frames, the traffic is queued at the shaping layer
using
> fair queueing. After a frame passes through the shaper, the frame is
> queued at the interface using whatever queueing method is configured.
If
> shaping is not configured, then queueing occurs only at the interface.
> > > >
------------------------------------------------------------------------
> --------
> > Note For interleaving to work, both fragmentation and the low-latency
> queueing policy must be configured with shaping disabled."
> > >
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft
> /122t/122t13/frfrintq.htm
> > Yes....?
> > -----Original Message-----
> From: Brian McGahan [mailto:bmcgahan@internetworkexpert.com]
> Sent: Wednesday, September 28, 2005 4:55 PM
> To: Edwards, Andrew M
> Subject: RE: MQC bandwidth
> > What exactly do you mean that it doesn't support interleaving?
> > Brian McGahan, CCIE #8593
> bmcgahan@internetworkexpert.com
> > Internetwork Expert, Inc.
> http://www.InternetworkExpert.com
> Toll Free: 877-224-8987 x 705
> Outside US: 775-826-4344 x 705
> 24/7 Support: http://forum.internetworkexpert.com
> Live Chat: http://www.internetworkexpert.com/chat/
> > > > -----Original Message-----
> > From: Edwards, Andrew M [mailto:andrew.m.edwards@boeing.com]
> > Sent: Wednesday, September 28, 2005 5:54 PM
> > To: Brian McGahan
> > Subject: RE: MQC bandwidth
> >
> > Does the fact that the IOS can maintain multiple shaping queues
> explain
> > why FRF.12 doesn't support interleaving?
> >
> > Thanks,
> >
> > Andy
> >
> > -----Original Message-----
> > From: Brian McGahan [mailto:bmcgahan@internetworkexpert.com]
> > Sent: Wednesday, September 28, 2005 2:18 PM
> > To: Stefan Grey; ccielab@groupstudy.com
> > Subject: RE: MQC bandwidth
> >
> > Stefan,
> >
> > Assuming you are referring to Frame Relay QoS it depends if you
> are
> > doing per-VC queueing or not. By default there is one shared
> output
> > queue for the interface regardless of how many VCs or subinterfaces
> you
> > have. In this case QoS is applied to the main interface since there
> is
> > only one output queue, and hence only one "bandwidth" value that is
> > significant.
> >
> > With legacy and MQC based Frame Relay Traffic Shaping each VC is
> > > assigned a separate output queue that in turn contends for the
> transmit
> > ring of the interface. Since there are separate output queues you
can
> > > apply separate QoS attributes onto then, either at the main
interface,
> > > subinterface, or VC level. In this case the available bandwidth for
a
> > > particular queue is based on the "mincir" value, either as defined
by
> > the "frame-relay mincir" command in legacy FRTS or the "shape
> adaptive"
> > command in the MQC. By default this value is half of the configured
> > "cir" or "average" rate.
> >
> > If you have a specific practice lab task that you want more
> > information about for QoS feel free to post it, otherwise check here
> for
> > more information:
> >
> >
>
http://www.cisco.com/en/US/tech/tk543/tk544/technologies_tech_note09186a
> > 00800a4754.shtml
> >
> > HTH,
> >
> > Brian McGahan, CCIE #8593
> > bmcgahan@internetworkexpert.com
> >
> > Internetwork Expert, Inc.
> > http://www.InternetworkExpert.com
> > Toll Free: 877-224-8987 x 705
> > Outside US: 775-826-4344 x 705
> > 24/7 Support: http://forum.internetworkexpert.com
> > Live Chat: http://www.internetworkexpert.com/chat/
> >
> >
> > > -----Original Message-----
> > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
Behalf
> > Of
> > > Stefan Grey
> > > Sent: Wednesday, September 28, 2005 11:25 AM
> > > To: ccielab@groupstudy.com
> > > Subject: MQC bandwidth
> >
> > >
> > > Hello group,
> > >
> > > Question:
> > >
> > > "Output queue calculations for the MQC are based on the configured
> > > bandwidth value of the interface and not the speed the interface
is
> > > clocked at.
> > Be
> > > sure to set the appropriate bandwidth value when configuring the
MQC
> > on an
> > > interface."
> > >
> > > When we configure CBWFQ on the subinterface should we configure
the
> > > reference bandwidth on the subinterface itself or on the physical
> > > interface.
> > > Where does router look for reference??
> > >
> > > _________________________________________________________________
> > > Browse smarter with tabs - get the all-new MSN Toolbar!
> > > http://toolbar.msn.ie
> > >
> > >
> >
>
This archive was generated by hypermail 2.1.4 : Sun Oct 02 2005 - 14:40:17 GMT-3